Control: clone -1 -2
Control: retitle -1 NetworkManager and rdnssd do not play well together
Control: retitle -2 rdnssd drops non-nameserver settings from /etc/resolv.conf
when overwriting it
Control: severity -2 important
[ Ccing debian-boot, and in particular Colin Watson and Philipp Kern
due to their involvment in netcfg ]
On Mon, 27 Oct 2014, Rémi Denis-Courmont wrote:
> > Right now, this package got installed by default on a Jessie GNOME
> > desktop and it really interacts badly with NetworkManager which
> > was handling the file perfectly fine (i.e. it included already the
> > IPv6 DNS servers identified by rdnsd).
>
> That *is* a problem. Indeed NetworkManager has gained support for RDNSS for a
> long time already, and thus made completely rdnssd redundant if not counter-
> productive on a system with NetworkManager.
>
> But as far as I know, whatever caused this default is not rdnssd itself.
Yeah, I was wondering how the package got installed, but I found no
obvious explanation (no reference in tasksel, the package is not
priority >= standard, no reverse dep in any other package). So I'm
assuming that it's debian-installer that decided to install this package
because it detected IPv6 connectivity.
A quick grep seems to confirm this:
netcfg-1.122/autoconfig.c: di_exec_shell_log("apt-install
rdnssd");
> > I believe that it should do something saner instead of overwriting.
>
> I must disagree. If resolvconf is absent, overwriting is the most sane, or
> least insane thing to do. There just is not a lot that can be done without
> mediation for writing the resolver configuration.
Maybe the presence of NetworkManager should be considered enough of a hint
that rdnssd should do nothing ?
Or maybe you want to check that it's running with "service network-manager
status" ?
Without such safeguards, assuming that you're entitled to manage
/etc/resolv.conf is not really acceptable as a default. The other alternative is
to use a low priority debconf questions "Shall I manage /etc/resolv.conf?" with
a default of "no".
> > It should verify if the file contains the DNS servers it detected
> > and add them if they are missing. But it should definitely not blindly
> > overwrite the file...
>
> There are currently no ways to know which entries were inserted by rdnssd
> (possibly by a previous incantation of it) and which by other tools.
You could store the former list of nameservers returned by rdnssd if you wanted,
and make a comparision.
> Furthermore, I doubt we can safely assume that all resolv.conf tools remove
> their entries when uninstalled. I think this suggestion is worse than the bug
> from a reliability perspective.
What other tools are you referring to?
I know of three sane cases:
- the admin manages /etc/resolv.conf manually
- a full-featured network manager tool handles the file alone
- specialised tools update the file by way of resolvconf
Having each specialised tool handle the file alone is not really a good option.
> Really, any pair of two tools writing resolv.conf will screw stuff up without
> resolvconf present and supported by both tools. That problem affects ppp,
> dhcp-
> client3, network-manager, wicd, connman, systemd(-networkd) just to name a
> few. And I don´t dare mention most if not all VPN clients.
connman/network-manager/wicd are in conflict with each other to avoid this
problem.
For the other tools, they are not daemons that are started automatically without
any intervention of the administrator. If they screw up /etc/resolv.conf
when you start them, you have a clear idea of what happened. Here I was rather
annoyed by the fact that the file was correct after NetworkManager started my
connection
but that the file went bad a bit later without any clear indication of what
happened
(thus a comment line saying that rdnssd generated the file is a good
idea too).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141028091628.gb9...@home.ouaza.com
