[02:24] <slangasek> smoser: hi, the cloud-init in the xenial SRU queue is a 'new upstream snapshot' - I'm not aware that there's been discussion with the SRU team of exempting cloud-init from the usual SRU rules?
[02:27] <slangasek> smoser: i.e., there are changes here that are not tied to bug reports with SRU test cases, and I have no reference to upstream CI having been done prior to upload.  As this is blocking lamont's somewhat urgent ipv6 support requirements, should I reupload with only the currently-SRUable changes?
[04:59] <slangasek> smoser: ugh - sorry, I didn't mean to reject your cloud-init upload just yet, I was only trying to reject lamont's; anyway, the preceding questions still apply before I could turn that into an 'accept'
[14:11] <tmus> the new resolvd based universal resolver in Yakkety seems to rely on changes to /etc/resolv.conf - at least sometimes... Unless I'm missing something, this will bring back resolver-issues for running (glibc) apps whet the DNS changes on the fly (VPN comes to mind). Is this true?
[14:12] <maxb> Yes, it's true, it has affected me already
[14:12] <tmus> hmmm
[14:12] <maxb> I had to change my VPN script to SIGUSR2 systemd-resolved on up/down
[14:14] <tmus> I believe resolvd actually listens on 127.0.0.53:53, so it seems to me we should just have 127.0.0.53 in resolv.conf and never change resolv.conf (exactly as with dnsmasq)?
[14:15] <maxb> Well, it gets even more complicated than that
[14:16] <maxb> Because systemd-resolved both obtains DNS servers for it to use FROM resolv.conf AND puts itself in resolv.conf
[14:16] <tmus> that sounds messy
[14:17] <maxb> yes
[14:17] <maxb> I'm thinking I'll probably disable systemd-resolved completely for my own use
[14:18] <tmus> especially when VPN's come along and modify the changed resolv.conf that resolvd will now have to parse and merge new resolvers to it's running config. And how does it keep track of removing them again?
[14:19] <maxb> Well hopefully you're using the resolvconf framework, otherwise it becomes complex beyond all sanity
[14:19] <tmus> this probably requires that network-manager can talk to resolvd directly and update DNS's directly - again, it'll need to leave resolv.conf alone
[14:20] <maxb> So right now on my yakkety laptop NetworkManager is providing a nameserver line it got from DHCP and systemd-resolved is providing 127.0.0.53 ... and presumably systemd-resolved is also reading the generated resolv.conf to get hold of the results of the DHCP
[14:21] <tmus> bad stuff
[14:21] <maxb> This seems to be yet another case of systemd coming up with features that overrule all historical configuration conventions
[14:22] <tmus> in this case at least, it seems we're missing some essential glue to make it usable in real life
[14:23] <tmus> every time resolv.conf is updated, we risk new applications won't have valid/consistent DNS resolution with the rest of the system
[14:23] <maxb> I feel it was an error to have systemd-resolved's 127.0.0.53 being injected into resolvconf
[14:24] <tmus> but if resolvconf could be made easily resolvd-aware, perhaps the problem is not too bad?
[14:24] <tmus> howcome?
[14:24] <maxb> It turns out that systemd-resolved(8) is actually fairly clear on three possible modes of operating resolv.conf, but what we seem to have in yakkety is a hybrid that is none of those three
[14:24] <tmus> (as long as that's the only nameserver in there, we should be golden, right?
[14:25] <tmus> makes sense
[14:25] <maxb> Quite. as long as that's the only nameserver in there. But that's just not happening the way the rest of Ubuntu is set up right now
[14:25] <tmus> agree... hopefully this can be fix'ed before release
[14:26] <tmus> is there a bug on this somewhere? do you know?
[14:26] <maxb> I don't, I've only started upgrading my machines to yakkety in the last few days and discovered this "fun" little detail
[14:27] <tmus> :)
[14:28] <maxb> I wonder if there's a list of everything that integrates with resolvconf anywhere
[14:28] <tmus> Alright - I need to run some errands, but I'll probably find the time to file a bug later - This seems broken enoug to warrant a fix before release
[14:29] <tmus> thanks for the ping-pong :)
[14:37] <maxb> I can see two possible ways forward: 1) everything that talks to resolvconf today to provide DNS server needs to talk to systemd-resolved directly, or resolvconf needs to parse interface-specific fragments handed to it and communicate the result to systemd-resolved.
[14:37] <maxb> Either sounds like a bit of a stretch this close to release
[18:18] <tmus> maxb, according to https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-local-resolver stuff should start to work soon... a change to nsswitch.conf should probably take care of the "forward to local resolver" thing, although I can't say i'm a big fan of the inherent confusion updating a historic configuration file with synthetic information just for kicks
[18:19] <tmus> i think i actually kind of hate that idea
[18:20] <tmus> to me the sanest solution is to use resolvd exactly as we use dnsmasq today - 127.0.0.53 in resolv.conf so admins KNOW that some sort of behind the scenes stuff is going on. systemd-resolv --status can then be used to get information
[20:25] <maxb> Ugh yes, I'm not at all convinced that putting anything other than 127.0.0.53 in resolv.conf when systemd-resolved is in use makes sense
[20:25] <maxb> Doing so is going to cause significantly confusing behaviour if the user is running any software which reads resolv.conf and tries to use the nameservers directly
[20:26] <maxb> So, anything that implements a non-glibc resolver