[00:07] <torriz> test
[00:07] <sarnold> torriz: test
[00:07] <sarnold> test torriz
[00:07] <sarnold> test
[00:09] <genii> !test | torriz
[00:09] <torriz> :D
[00:14] <patdk-lap> sarnold, you want to look at my interfaces file?
[00:14] <patdk-lap> did several more tests
[00:14] <sarnold> patdk-lap: sure
[00:14] <patdk-lap> still cannot get the gateway to turn up no matter what
[00:15] <patdk-lap> even had a problem when it was a single static ip
[00:15] <patdk-lap> or interface
[00:16] <patdk-lap> http://apaste.info/ePt
[00:17] <patdk-lap> it's worked on all ubuntu systems I have had, including 16.04, except on these two new ones I setup a few weeks ago
[00:18] <patdk-lap> I even attempted to add an, up route add default gw 10.1.0.1
[00:18] <patdk-lap> but that didn't work
[00:18] <patdk-lap> though running it on the cli manually, works fine
[00:19] <patdk-lap> removing everything except bond0, still doesn't make it work
[00:20] <sarnold> patdk-lap: "iface bond0 inet manual"  -- not 'static'? bond2 is set static
[00:20] <patdk-lap> it has no ip
[00:20] <sarnold> ahh
[00:21] <patdk-lap> atleast it works fine on my system here at home :)
[00:29] <sarnold> patdk-lap: no idea :/ it's the single most complicated one I've seen :) but it all makes sense.
[00:30] <patdk-lap> well, even with just the two entries, to make bond0 and bond0.4 work, gateway won't come up
[00:31] <patdk-lap> that is far from complicated :)
[00:31]  * sarnold shudders
[00:31] <patdk-lap> that is just a simple storage server :)
[00:31] <patdk-lap> you should look at the router/firewall ones
[02:06] <Tarifa> I just installed an Ubuntu server.  Was having a heckuva time getting ssh to reliably startup.  STarted to poke around, and find there are TWO init scripts -- /etc/init.d/ssh (for upstart) and /lib/systemd/system/ssh.service (for systemd).  I discovered that enabling one, seems to cause the other to try to start.  Screws up startup dependencies it seems.  As a test, I simply moved /etc/init.d/ssh out of the way, and restarted.
[02:06] <Tarifa> Everything works perfectly.
[02:07] <Tarifa> I'm not sure WHY there are both an upstart ssh and a systemd ssh installed; though Ubuntu had moved.
[02:07] <Tarifa> ANyway, is that the right way to DISABLE the /etc/init.d/ssh -- just move it?
[02:09] <sarnold> hah, even better than that, there's _three_ different sshd init systems -- /etc/init.d/ssh /etc/init/ssh.conf and /lib/.../ssh.service. *sigh*
[02:09] <RoyK> Tarifa: I stick to debian
[02:09] <sarnold> if you move the initscript it'll probably come back on future package upgrades
[02:09] <patdk-lap> just use the update-rc.d or whatever these days
[02:09] <RoyK> Tarifa: for servers
[02:09] <patdk-lap> or systemctl disable/mask/...
[02:10] <sarnold> Tarifa: please file a bug, 'ubuntu-bug openssh' and tag it with systemd-boot, I think that's how it'll get to the right people
[02:10] <patdk-lap> sarnold, no, only if you use rpm :)
[02:10] <sarnold> lol
[02:10] <Tarifa> patdk-lap: disable/mask to disable the init.d upstart service?
[02:10] <patdk-lap> why I left rhel, cause all the files kept coming back endlessly
[02:10] <patdk-lap> no to disable systemd service
[02:10] <patdk-lap> systemd will normally filter it down to upstart if needed though
[02:11] <Tarifa> patdk-lap: Ah.  I want the "other way"  --  ENable systemd, but DISable upstart
[02:11] <patdk-lap> normally systemd service just calls the upstart service
[02:11] <patdk-lap> systemd likes to be in-charge
[02:12] <Tarifa> patdk-lap: yeah, and I'm happy with systemd.  Just trying to figure out how to get the upstart stuff to "leave me alone" ....
[02:15] <Tarifa> sarnold: If I can figure it out enough to post more that "It don't work!", I will
[02:17] <sarnold> Tarifa: I've gotten the impression that one common reason why sshd doesn't come up reliably is that it binds to specific IP addresses withuot using IP_FREEBIND -- and that some network interfaces take too long to come up, so their addresses don't exist, so *boom*
[02:17] <sarnold> Tarifa: I wonder if fiddling with the sysv-init symlink causes it to run at a vastly different time..
[02:22] <Tarifa> sarnold: Yeah, I set specific IP addresses to listen.  That's easily taken care of by adding network-online.target dependency to a Unit file override.   Eventually I'll also have ssh use an nfs-mounted /etc/ssh, and add a 'RequiresMountsFor=' clause in a Unit file.  That delays ssh nicely until the network's up.
[02:23] <Tarifa> systemd makes it easy.  Trick *here* is to get Ubuntu to stop futzing around with upstart ssh.  Really, no clue why the /etc/init.d/ssh is still even installed.
[02:29] <sarnold> Tarifa: I think it was just a matter of running out of time to remove all the system upstart configs before release
[02:29] <sarnold> to do it Right would probably mean submitting patches to debian for the packages there with upstart configs, etc., and all that takes time.
[02:31] <Tarifa> sarnold: So even the Ubu init system is heavily dependent on Debian?  As you can guess, I'm new to this env.  systemd on Opensuse is very clean and pretty much legacy free at this point.
[02:31] <sarnold> Tarifa: yes, they've had several more years to clean it up, and only the one distribution to worry about :)
[02:33] <sarnold> Tarifa: funny thing is, debian didn't get rid of their N different inits.. it just switched The Default. we may not be able to get rid of the upstart configuration files, we may be stuck with keeping around config files for all three major inits :(
[02:33] <Tarifa> Well, more than one.  Suse != Opensuse.  And now Opensuse Leap != Opensuse Tumbleweed.
[02:33] <Tarifa> That's part of the problem I'm seeing these days.
[02:34] <Tarifa> sarnold: Hm.  Hadn't realized that.  Rolling these out in this 'shape' is gonna cause some problems it appears.
[02:35] <sarnold> Tarifa: well, that's what made me suggest the bug report -- this really should Just Work, even if it is bloody annoying on sysadmins to figure out which tool to use to disable a service. But sshd should start everywhere without trouble, and it mostly does (modulo those non-existant interfaces I mentioned a little while ago)
[02:36] <Tarifa> agree on the JustWork(tm)
[02:37] <Tarifa> In my experience so far, the distros don't do a particularly good job of either SSH or NFS startup.  Lots of sloppy, poorly thought out Unit files out there.
[02:38] <Tarifa> aaaaaand, of course, getting the maintainers to actually respond is like pulling teeth.
[02:38]  * Tarifa sighs
[02:38] <sarnold> I haven't noticed any issues with my NFS setup -- what went wrong for you there?
[02:41] <Tarifa> sarnold: It's working now.  But lots of mess with waiting for network interfaces to come up, drives to spin up, and static port deployments.  To 'amplify' the problem, try a big server with a dozen interfaces and 40+ drives in raid arrays.
[02:41] <Tarifa> Lots of fun.
[02:42] <sarnold> Tarifa: aha :) I've only got the one interface and ~dozen drives. heh.
[02:42] <Tarifa> Thank the stars for systemd's flexibility, imo!
[02:42] <Tarifa> Throw a KVM or Xen server in there, and watch the sparks fly differently for each distro.
[02:43] <Tarifa> sarnold: Then file a bug, and get back "Can't reproduce here, therefore not a bug".
[02:44] <Tarifa> Some of those folks need to upgrade their RPi's if you ask me ;-)
[02:44] <patdk-lap> just mark it invalid or won'tfix :)
[02:44] <patdk-lap> can't upgrade
[02:44] <patdk-lap> linux kernel has bugs, that make it unusable for me
[02:44] <sarnold> haha
[02:44] <Tarifa> heh
[02:45] <patdk-lap> they added in new network code for min packet header length
[02:45] <patdk-lap> but the min length is set to the max size
[02:45] <patdk-lap> and for variable sized header protocols, well, that doesn't work out well
[02:46] <patdk-lap> first people to start complaining where the rpi users
[02:48] <Tarifa> Ah, just got a ping from a friend.  Secret sauce seems to be: "systemctl disable ssh; update-rc.d ssh disable; systemctl enable ssh".  Apparently all 3 are needed.  Then add both Wants=network-online.target & Requires=network-online.target in an ssh service override.
[02:48] <Tarifa> Just tried it -- works a charm.
[02:49] <Tarifa> i really wish the devs would stop & RTFM on systemd network dependencies.  Specifically 'network' vs 'network-online'.
[02:50] <sarnold> Tarifa: please do file a bug.
[02:50] <patdk-lap> you just want to mark it, won't fix
[02:50] <sarnold> patdk-lap: not me, pitti :)
[02:51] <sarnold> I'm still new enuogh with systemd that I'm basically fish out of water .. he knows what's going on and is in a much better position to figure out what needs to be done about it :)
[02:51] <Tarifa> fwiw, @ https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/: "network.target has very little meaning during start-up" & "network-online.target is a target that actively waits until the nework is "up""
[02:51] <Tarifa> Guess which one is used in Ubu's ssh.service?
[02:52] <patdk-lap> haven't looked :)
[02:52] <patdk-lap> wonder what is in my ssh package
[02:52] <Tarifa> patdk-lap: Don't.  Be Happy.
[02:53] <Tarifa> Wow. The kitchen sink's in here.  ssh@.service & ssh.socket too.
[02:59] <Tarifa> Anyway. TT4N.
[04:14] <k2gremlin> Hello all, I was wondering the best approach to setup 2 hard drive for my media server. The OS drive I would like to have say 25GB. The "Storage" drive would be on the same datastore and maybe around 400gb.
[04:16] <sarnold> k2gremlin: i've got to run, here's a nice series of blog post about zfs that may interest you :)  https://pthree.org/2012/12/04/zfs-administration-part-i-vdevs/
[04:16] <k2gremlin> The reason for this is if I ever mess up my OS.. I would like to rebuilt it and add the storage vmdk as a secondary
[04:17] <sarnold> (fwiw I think it's still too much trouble to use zfs on root; simple ext4 or something is a lot easier there)
[04:18] <patdk-lap> btrfs for root?
[04:19] <sarnold> well if you want reasons to rebuild it.. hehe
[04:19] <patdk-lap> weekly?
[04:21] <sarnold> hey, the front page of their wiki no longer says "don't use this in production". it might be worth a look soon then.
[04:21] <patdk-lap> doubtful
[04:22] <sarnold> true, I'd rather have easy zfs on root (where easy means not having to read a howto :)
[04:23] <patdk-lap> it's always a nightmare for me to do encrypted root
[04:23] <patdk-lap> this last time to go encrypted, grub encrypted + EFI grub, took awhile
[04:25] <sarnold> hmm I thuoght the installer would do that if you wanted.
[04:25]  * sarnold blames patdk-lap and runs for dinner
[04:26] <patdk-lap> it doesn't really like encrypted /boot
[04:26] <sarnold> ahhhhh. /boot is getting harder to do these days.
[04:27] <sarnold> I gave in, I think none of my systems have a separate /boot any longer
[04:27] <patdk-lap> but as I learned about EFI
[04:27] <patdk-lap> heh, that is just a whole vaun point
[04:27] <patdk-lap> as I see it
[05:34] <stephanbuys> hi all, anyone here from canonical to chat about commercial support/troubleshooting of a failing system? (tried the web form a couple of weeks ago but got no reply)
[05:55] <M4R4B4> !help
[05:55] <M4R4B4> I need a scan like this someone has ??? http://prnt.sc/bmwh00
[13:18] <EmilienM> §b rdo-ci
[13:42] <cpaelzer> nacc: the step of "usd-importer/usd-merge reconstruct old/ubuntu" usually fails for me
[13:43] <cpaelzer> nacc: reason is that it has no local representation of debian/sid at this stage
[13:43] <cpaelzer> nacc: usd-merge: debian/sid is not a defined object in this git repository.
[13:43] <cpaelzer> nacc: a simple "git checkout debian/sid" gets it going again
[13:43] <rbasak> cpaelzer: try "git branch debian/sid origin/debian/sid", assuming your remote is "origin".
[13:44] <cpaelzer> rbasak: yeah the branch achieves likely the same as my checkout
[13:44] <rbasak> cpaelzer: this is bug 1595298
[13:44] <cpaelzer> thanks for the pointer rbasak
[14:28] <pulsar12> when i create a file on a file-ACL enabled system, the mask applied is rw-. but i have the group set to rwx. i was expecting to see mask=rwx, since documentation states that ACL mask is the union of all group and user permissions
[15:27] <nacc> cpaelzer: yes, or do `usd-merge reconstruct old/ubuntu origin/debian/sid`
[15:27] <nacc> cpaelzer: will fix on the bug
[15:33] <cpaelzer> nacc: now we have three workarounds :-)
[15:33] <cpaelzer> nacc: thanks for fixing it somewhen
[15:35] <nacc> cpaelzer: either today or tmrw, i hope