Issues related to the yakkety switch to systemd-resolved

[Joe Barnett]

Hi Martin,

Thank you for your reply and reference documentation.

On Wed, Oct 19, 2016 at 12:27 AM, Martin Pitt <martin.pitt at 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 at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/ubuntu-devel-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20161019/8547916d/attachment.html>