Hi Martin, Thank you for your reply and reference documentation.
On Wed, Oct 19, 2016 at 12:27 AM, Martin Pitt <martin.p...@ubuntu.com> wrote: > Hello Joe, > > Joe Barnett [2016-10-18 7:27 -0700]: > > Since upgrading to yakkety, I've noticed the following issues seemingly > > related to (a partial?) switch to systemd-resolved for DNS: > > Yes, it's partial still. See the blueprint [1] for detailled status. > > > 1) The first issue I noticed was that when connected to an openvpn VPN, > > firefox stopped being able to resolve DNS entries from the VPN's DNS > > server, while command line tools (host/ping) worked fine. Traced this > down > > to two things, both seemingly related to my former use of resolvconf not > > fully migrating over to use systemd-resolved: > > Note that we did not (and did not plan to) migrate away from > resolvconf -- too many packages hook into it which would need to get > changed first, so we continue to let /etc/resolv.conf be managed by > resolvconf for the time being. > > > a) Had to change my .ovpn file to point to > > /etc/openvpn/update-systemd-resolved > > instead of /etc/openvpn/update-resolv-conf > > b) Had to change my /etc/resolv.conf to point to > > /lib/systemd/resolv.conf instead of /run/resolvconf/resolv.conf > > So while trying that is appreciated, it *will* break resolv.conf > mangling integration with a lot of packages [2]. None of these should > affect a reasonably standard desktop, but you should be aware of it. > Ok, that mostly makes sense -- what's interesting here is that the resolv.conf mangling being done by the openvpn scripts was the first thing that I really noticed not working. Perhaps the dns fallback in nsswitch.conf you mention below isn't quite working right? my nsswitch.conf currently looks like: hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname Moving dns earlier in that line appeared to kind of mitigate the firefox vs/ commandline tool discrepancy, but I can't remember exactly to what extent it worked or didn't. Since I was tweaking that file, I'm not 100% confident I restored it to the exact previous state, but possibly the ordering in that file is causing most of my issues here? > > > 2) After a suspend/resume cycle, DNS queries stopped working unless I > > restarted network-manager: https://bugs.launchpad.net/ > ubuntu/+source/network-manager/+bug/1629620 > > a) After doing the fixes for problem #1, this appears to be working > > better now > > That's unrelated to resolved, as NM is still configuring dnsmasq (and > hence /etc/resolv.conf should have 127.0.1.1 only). I've heard reports > that a recent change in NM (https://launchpad.net/bugs/1592721) broke > split-horizon DNS for some people, and from a quick IRC debugging it > seemed that dnsmasq was in a weird state after (re)starting NM. > Killing the dnsmasq instances and re-connecting to the network (in > nm-applet) helped these folks -- does it work for you too? > > > 3) Steam was unable to see the network: https://bugs.launchpad.net/ > > ubuntu/+source/steam/+bug/1631980 > > a) After manually installing libnss-resolve:i386, this is now > resolved, > > but should this package have been installed automatically when > > libnss-resolve:amd64 was installed? > > No, that can't work. Ideally, libnss-resolve:i386 would be installed > automatically as soon as you install any :i386 package. However, > unlesss we make libc6:i386 Recommends: libnss-resolve, we don't have > any mechanics for that. > > For this we actually keep the "dns" fallback in /etc/nsswitch.conf, so > that foreign-architecture programs still use the plain old > /etc/resolv.conf for resolution if they don't have the corresponding > "resolve" NSS module installed. > > > Anyways, assuming there's eventually a fix found for #4, my real question > > is not so much that there were bugs, but rather are there still changes > > that should be made to make the solution for these issues more automatic > > (ie, automatically apply 1.b and 3.a)? Or at least to notify the user > more > > loudly that their configuration is not fully supported? > > In principle everything ought to work as before on a desktop with NM. > So we don't need notifications IMHO, we "just" need to debug and fix > the dnsmasq regression (see above) for 16.10. > > For 17.04 I'd actually like to finish the transition on the desktop as > well and move NM away from dnsmasq, so that we use the same solution > on servers and desktops. (Again see [1]). > Ok that sounds like a great plan, I'll so some more testing locally to restore the resolvconf managed /etc/resolv.conf and see if there are still problems given your explanation here. Thanks, -Joe > > Martin > > [1] https://blueprints.launchpad.net/ubuntu/+spec/foundations- > y-local-resolver > [2] http://people.canonical.com/~pitti/tmp/resolvconf-hooks.txt > > -- > Martin Pitt | http://www.piware.de > Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/ubuntu-devel-discuss >
-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss