| 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:24 |
|---|---|---|
| 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? | 02:27 |
| === ]reed[ is now known as [reed] | ||
| === philroche_ is now known as philroche | ||
| === nobuto_ is now known as nobuto | ||
| === JanC_ is now known as JanC | ||
| === Zic is now known as Guest96445 | ||
| === semiosis_ is now known as semiosis | ||
| === johnlage_ is now known as johnlage | ||
| === Elimin8r is now known as Elimin8er | ||
| === Serge is now known as Guest68038 | ||
| === beisner- is now known as beisner | ||
| === tsimonq2alt is now known as tsimonq2 | ||
| === Guest77571 is now known as karstensrage | ||
| === Cimi_ is now known as cimi | ||
| === ivoks_ is now known as ivoks | ||
| === Bluefoxicy_ is now known as Bluefoxicy | ||
| === tai271828_ is now known as tai271828 | ||
| 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' | 04:59 |
| === lilstevie_ is now known as lilstevie | ||
| === sarnold_ is now known as sarnold | ||
| === enrico_ is now known as enrico | ||
| === lan3y is now known as Laney | ||
| 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:11 |
| 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:12 |
| 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:14 |
| maxb | Well, it gets even more complicated than that | 14:15 |
| 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:16 |
| maxb | yes | 14:17 |
| maxb | I'm thinking I'll probably disable systemd-resolved completely for my own use | 14:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| tmus | in this case at least, it seems we're missing some essential glue to make it usable in real life | 14:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| tmus | :) | 14:27 |
| 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:28 |
| tmus | thanks for the ping-pong :) | 14:29 |
| 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 | 14:37 |
| 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:18 |
| tmus | i think i actually kind of hate that idea | 18:19 |
| 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 | 18:20 |
| === NCommander is now known as Guest20045 | ||
| === lynxman_ is now known as lynxman | ||
| === nobuto_ is now known as nobuto | ||
| === juliank_ is now known as juliank | ||
| === xnrand is now known as grumble | ||
| === mapreri_ is now known as mapreri | ||
| === Logan_ is now known as Logan | ||
| === Beret- is now known as Beret | ||
| === BenC_ is now known as BenC | ||
| === Spads_ is now known as Spads | ||
| === ]reed[ is now known as [reed] | ||
| === NCommander is now known as Guest93566 | ||
| === Sir_Gallantmon is now known as Pharaoh_Atem | ||
| === _salem` is now known as _salem | ||
| === johnlage_ is now known as johnlage | ||
| === tumbleweed_ is now known as tumbleweed | ||
| === nobuto_ is now known as nobuto | ||
| === Cimi_ is now known as cimi | ||
| === xnox_ is now known as xnox | ||
| === mapreri_ is now known as mapreri | ||
| === dasjoe_ is now known as dasjoe | ||
| === tsimonq2alt is now known as tsimonq2 | ||
| === Eleventh_Doctor is now known as Pharaoh_Atem | ||
| === tvoss_ is now known as tvoss | ||
| === Beret- is now known as Beret | ||
| === DrKranz is now known as DktrKranz | ||
| 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:25 |
| maxb | So, anything that implements a non-glibc resolver | 20:26 |
| === iahmad_ is now known as iahmad | ||
| === tumbleweed_ is now known as tumbleweed | ||
| === underyx_ is now known as underyx | ||
| === josepht is now known as josepht` | ||
| === stokachu_ is now known as stokachu | ||
| === jbicha_ is now known as jbicha | ||
| === JanC_ is now known as JanC | ||
| === tych0- is now known as tych0 | ||
| === lool- is now known as lool | ||
| === DalekSec_ is now known as DalekSec | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!