resolvconf should only convert /etc/resolv.conf to a symlink at initial installation time

This bug was fixed in the package resolvconf - 1.63ubuntu4

---------------
resolvconf (1.63ubuntu4) precise; urgency=low

  * dhclient hook: Only trigger if /etc/resolv.conf is a symlink.
  * postinst: Set resolvconf/linkify-resolvconf to false after initial
    conversion, ensuring upgrades won't convert /etc/resolv.conf to
    a symlink if the user manually converted it back to plain text.
    (LP: #922677)
  * Make resolvconf exit 0 when /etc/resolv.conf isn't a symlink
    (instead of exit 1) and update the error message.
 -- Stephane Graber <email address hidden> Fri, 27 Jan 2012 12:23:34 -0500

> * dhclient hook: Only trigger if /etc/resolv.conf is a symlink.
> * Make resolvconf exit 0 when /etc/resolv.conf isn't a symlink

In the Debian version of resolvconf, interface-configurer hook scripts always run /sbin/resolvconf if it's present, whether or not /etc/resolv.conf is a symlink. That way resolvconf is always provided with all available information. It's also important to keep in mind that resolvconf may have "subscribers" other than libc. Thus even if the admin --- for whatever reason --- has decided to put a static file at /etc/resolv.conf or to link /etc/resolv.conf to some other target generated by some other tool, /sbin/resolvconf still gets run and it, in turn, still calls its hook scripts so that its subscribers (perhaps dnsmasq, perhaps...) are made aware that there is new information.

Some time ago some Ubuntu developer added

    [ -L /etc/resolv.conf ] || exit 1

to the beginning of Ubuntu /sbin/resolvconf so that Ubuntu resolvconf does nothing if /etc/resolv.conf isn't a symlink, the consequence of the nonzero exit code being that NetworkManager will fall back to another way of updating /etc/resolv.conf. (That wasn't a clean solution from my point of view, as author of resolvconf. The clean solution would have been (1) not to change /sbin/resolvconf, but (2) to change NetworkManager so that it both calls resolvconf and writes /etc/resolv.conf if the latter isn't a symlink. But the Ubuntu broth has enough other cooks.)

If /sbin/resolvconf exits with 0 when /etc/resolv.conf isn't a symlink then, in that case, NetworkManager will no longer write /etc/resolv.conf. Is this what was intended?
--
Thomas Hood

> * postinst: Set resolvconf/linkify-resolvconf to false after initial

Is this (i.e., maintainer scripts changing the answers to debconf questions) a recommended practice?

Yeah, I later discovered that changing to exit 0 will break resolv.conf with Network Manager.
Matt Trudel is aware of it and the Network Manager code will be changed to a logic similar to that of the dhclient hook (check for resolvconf and for /etc/resolv.conf being a symlink).

As for the debconf change, that was on the recommendation of Steve, so I assume that's fine. Maybe not the recommended way but certainly not the worst way of doing it either :)

So what rule is Ubuntu adopting which suppliers of nameserver information are supposed to follow?

In Debian the rule is: "If /sbin/resolvconf is present then send the information to /sbin/resolvconf" (regardless of whether or not /etc/resolv.conf is a symlink).

Is Ubuntu's rule the following? "If /sbin/resolvconf is present and /etc/resolv.conf is a symlink to /run/resolvconf/resolv.conf then send the information to /sbin/resolvconf."

> As for the debconf change, that was on the
> recommendation of Steve, so I assume that's
> fine. Maybe not the recommended way but
> certainly not the worst way of doing it either :)

I worry that doing this violates the principle that debconf is not a registry. Debconf is a way for the administrator to make her preferences known and that is all. To change the answer to a debconf question to record the fact that a maintainer script has run is to use debconf as a record of system state.

In Debian there are already a couple of ways of preventing the resolvconf package from replacing /etc/resolv.conf with a symlink on upgrade.
* Remove the resolvconf package
* Manually change the answer to the linkify-resolvconf question, using dpkg-reconfigure
* Make the file immutable

(The last case is currently treated as an error if the answer to linkify-resolvconf is true, but we could decide to treat it as a valid condition instead.)

--
Thomas Hood

Yeah, currently Ubuntu's rule is "/sbin/resolvconf exists" and "/etc/resolv.conf is a symlink". We don't really check where the symlink points to even though I guess we should :)

We made resolvconf a hard depend of ubuntu-minimal which means it gets on any system we can call an Ubuntu system and is part of the basic set of packages that get installed by debootstrap. So removing it isn't really an option as that'd mean uninstall ubuntu-minimal which is usually a bad idea.

Manually changing the answer in debconf would work, though the current priority makes it an invisible option that won't prompt at install (we don't want it to prompt anyway).
So people would have to replace /etc/resolv.conf by a file and make sure they change the debconf value, which would work but isn't necessarily obvious to our users.

Making it immutable would very likely cause a few more problems from other tools trying to touch /etc/resolv.conf so that doesn't really sound like a solution either.

Thomas,

Making files immutable is absolutely the wrong way to go. In chatting with Stéphane about this bug, I think the long term correct solution would be to drop the debconf question altogether and adjust the package to only linkify on initial install, but that's a change I wanted to talk with you about before pushing into Ubuntu :)

On Fri, Jan 27, 2012 at 22:04, Steve Langasek <email address hidden> wrote:
> Making files immutable is absolutely the wrong way to go.

Agreed.

> I think the long term correct solution would be
> to drop the debconf question altogether and
> adjust the package to only linkify on initial install,

You mean that the postinst refrains from linkifying if the argument of "configure" is non-null? In that case the postinst refrains from linkifying in the case where the package is being installed after having been removed; only installing after a purge counts again as an initial install. Sounds OK.
--
Thomas

On Sat, Jan 28, 2012 at 12:49:32PM -0000, Thomas Hood wrote:
> > I think the long term correct solution would be
> > to drop the debconf question altogether and
> > adjust the package to only linkify on initial install,

> You mean that the postinst refrains from linkifying if the argument of
> "configure" is non-null? In that case the postinst refrains from
> linkifying in the case where the package is being installed after having
> been removed; only installing after a purge counts again as an initial
> install. Sounds OK.

Ah, I didn't actually consider the remove-without-purge->install case. I
think having install->remove->install result in /etc/resolv.conf being a
file rather than a symlink is actually a pretty bad outcome. More thinking
is needed here.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

I need this package in Oneiric, and have installed the (precise) deb manually. ..is it possible to release this newer version for oneiric?

Unfortunately, the side effect of this "fix" is that now resolv.conf is never updated by NM, causing anyone who upgraded to 12.04 to have broken DNS.

Cerin: Can you please elaborate? On a properly configured system NM and resolvconf work together correctly. If name resolution is not working on your system then let's find out why.

Please send the output of:
    ls -l /etc/resolv.conf
    lsattr /etc/resolv.conf
    ls -l /run/resolvconf
    ls -l /run/resolvconf/interface
    for F in /run/resolvconf/interface/* ; do echo === $F === ; cat $F ; done

I'm seeing this issue from a clean Ubuntu precise amd64 AMI (http://cloud.ubuntu.com/ami/).

With nothing but vpnc installed, I did some of the following:

ubuntu@ip-10-116-125-233:~$ sudo vpnc myvpnc.conf
sudo vpnc myvpn.conf
resolvconf: Error: /etc/resolv.conf isn't a symlink, not doing anything.
VPNC started in background (pid: 12101)...

(but it's not actually connected)

Upgrading resolvconf package:
Unpacking replacement resolvconf ...
Processing triggers for ureadahead ...
Processing triggers for man-db ...
Setting up resolvconf (1.63ubuntu14) ...
Processing triggers for resolvconf ...
resolvconf: Error: /etc/resolv.conf isn't a symlink, not doing anything.

Here's some information:
ubuntu@ip-10-116-125-233:~$ ls -l /etc/resolv.conf
-r--r--r-- 1 root root 63 May 29 13:42 /etc/resolv.conf
ubuntu@ip-10-116-125-233:~$ lsattr /etc/resolv.conf
-------------e- /etc/resolv.conf
ubuntu@ip-10-116-125-233:~$ ls -l /run/resolvconf
total 0
drwxr-xr-x 2 root root 40 May 29 13:42 interface
-rw-r--r-- 1 root root 0 May 29 13:42 postponed-update
ubuntu@ip-10-116-125-233:~$ ls -l /run/resolvconf/interface/
total 0
ubuntu@ip-10-116-125-233:~$ for F in /run/resolvconf/interface/*; do echo === $F ===; cat $F; done
=== /run/resolvconf/interface/* ===
cat: /run/resolvconf/interface/*: No such file or directory

Louis Li: Your problem looks like bug #1003842, not this one. Please follow up at #1003842.

https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1003842

(Argh. That should have been #1000244, not #1003842.)

Louis Li: Your problem looks like bug #1000244, not this one. Please follow up at #1000244.

https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1000244.