please remove 'resolvconf' from ubuntu-minimal Depends

[Martin-Éric Racine]

The addition of 'resolvconf' to ubuntu-minimal's Depends introduces too many problems, mostly because it replaces /etc/resolv.conf with a symbolic link to content in the /run hierarchy. This is particularly undesirable within a chroot. Additionally, resolvconf is generally known as a seriously broken piece of software, and so it needs to be removed from ubuntu-minimal's Depends.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: ubuntu-minimal 1.258
ProcVersionSignature: Ubuntu 3.2.0-10.18-generic 3.2.1
Uname: Linux 3.2.0-10-generic i586
ApportVersion: 1.91-0ubuntu1
Architecture: i386
Date: Fri Jan 27 15:15:11 2012
SourcePackage: ubuntu-meta
UpgradeStatus: No upgrade log present (probably fresh install)

[Stéphane Graber (stgraber)]

The resolvconf we promoted to main for Precise is pretty different from the resolvconf we used to have in the past.

This has been done after discussion with the various teams as part of: https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns-resolving
The corresponding MIR can be found at: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/921135

We don't plan on moving resolvconf out of ubuntu-minimal but will investigate cases that break because of it and fix them instead.

One of the known way to disable it (and the reason why we didn't make it a Recommends rather than a Depends) is to simply remove the symlink and replace it by a regular resolv.conf file.

[Martin-Éric Racine (q-funk)]

That work-around won't allow dhclient to update the content for as long as resolvconf is installed, so it's not a solution.

[Martin-Éric Racine (q-funk)]

The MIR itself looks quite promising, but I'll emphasize that the current implementation still breaks DNS in a chroot.

[Stéphane Graber (stgraber)]

Oh, indeed, the dhclient hook is broken, it should only trigger if /etc/resolv.conf is a link. I'll be uploading a fixed resolvconf shortly.

[Martin-Éric Racine (q-funk)]

Should there also be a fix to NOT update /etc/resolv.conf with a symbolic link to /run/resolvconf/resolv.conf if we are in a chroot?

[Launchpad Janitor (janitor)]

This bug was fixed in the package resolvconf - 1.63ubuntu5

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

  [ Stéphane Graber ]
  * Instead of creating the symlink in debian/postinst, create a flag
    at /var/lib/resolvconf/convert and create the symlink in the upstart
    or sysvinit job. On regular machines this will convert it immediately
    but on chroots that'll keep the old resolv.conf file. (LP: #922578)

  [ Steve Langasek ]
  * Call dh_installinit with -r, to not stop/start resolvconf on upgrade;
    that just leaves a window when updates aren't happening, which doesn't
    benefit us.
 -- Stephane Graber <email address hidden> Fri, 27 Jan 2012 14:19:22 -0500

[Thomas Hood (jdthood)]

> Additionally, resolvconf is generally known as a seriously broken piece of software

Resolvconf was seriously broken *in Ubuntu universe* for a long time because no one bothered to port it to upstart. In Debian the package has been in good shape for many years.
--
Thomas Hood

[Martin-Éric Racine (q-funk)]

This still doesn't resolve the issue. In order to function, a chroot needs /etc/resolv.conf copied from the host's normal /etc/resolv.conf, but because of the current implementation, the host's /etc/resolv.conf content will always be "nameserver 127.0.0.1" which is entirely useless inside the chroot.

[Stéphane Graber (stgraber)]

Last I checked, a chroot was still in the same network namespace as the host, meaning that "nameserver 127.0.0.1" reaches the dnsmasq running outside of the chroot and will resolve just fine.

Besides the fact that /etc/resolv.conf contains 127.0.0.1 is in no way a result of the change to resolvconf, that's the switch to dnsmasq by default in Network Manager (and only affects desktop machines).

[Martin-Éric Racine (q-funk)]

I just noticed another issue with this: until now, the /etc/resolv.conf generated by network-manager would contain both "domain" and "search" stanzas. Now, it only contains "search".

[Martin-Éric Racine (q-funk)]

Speeding up DNS search did not require adding resolvconf to ubuntu-minimal. Instead, enabling dhclient's option to always prepend 127.0.0.1 to /etc/resolv.conf does the trick quite nicely. Heck, I even filed a bug against dhclient, asking for this to be enabled by standard, a while back.

[Steve Langasek (vorlon)]

> I just noticed another issue with this: until now, the /etc/resolv.conf
> generated by network-manager would contain both "domain" and "search"
> stanzas. Now, it only contains "search".

I have noticed this as well, but I haven't been able to determine that this makes a difference functionally. If you know of one, let us know and I'll look at getting resolvconf fixed.

> Speeding up DNS search did not require adding resolvconf to ubuntu-
> minimal.

That's correct, but this is not the reason it was added. The reasons include:

 - nothing should be writing to /etc at runtime; it's a bug that causes Ubuntu to not work out of the box with a read-only rootfs
 - even when not booting with a read-only rootfs, there is a race condition between mounting / rw and running dhclient, the latter being triggered as soon as a network device is found by udev. (This was worked around last cycle in dhclient, but it works by making the boot slower than it should be.)
 - there are half a dozen different packages in the archive that all have support for updating /etc/resolv.conf directly under various circumstances. This is unnecessary duplication of code, they probably all have different bugs, they certainly don't coordinate with one another, and they generally don't do the right thing in the case of multiple network devices.

This is a deliberate architectural change in Ubuntu that was discussed and agreed at UDS. If there are specific technical problems with this behavior, please report them as bugs and we will fix them; but the dependency isn't going to be dropped.

[Thomas Hood (jdthood)]

Martin-Éric wrote:
>> I just noticed another issue with this: until now, the /etc/resolv.conf
>> generated by network-manager would contain both "domain" and
>> "search" stanzas. Now, it only contains "search".

Steve wrote:
> I have noticed this as well, but I haven't been able to determine
> that this makes a difference functionally. If you know of one,
> let us know and I'll look at getting resolvconf fixed.

resolv.conf(5) says:

    The domain and search keywords are mutually
    exclusive. If more than one instance of these
    keywords is present, the last instance wins.

Because "search" is more versatile than "domain", resolvconf only writes a "search" line, not a "domain" line. Any "domain" information supplied to resolvconf is included on the "search" line.

Resolvconf, with thousands of popcon-reported instances installed, has worked this way for many years without anyone reporting a functional problem. If there is a third-party tool out there that reads resolv.conf and treats "domain" specially then we'll have to look into that.

--
Thomas

[Thomas Hood (jdthood)]

> Speeding up DNS search did not require adding resolvconf
> to ubuntu-minimal.
> Instead, enabling dhclient's option to always prepend
> 127.0.0.1 to /etc/resolv.conf does the trick quite nicely.

If you only have one interface configurer (e.g., dhclient) then there is no problem having that configurer control /etc/resolv.conf. If you have only one interface configurer and you always have a caching nameserver then /etc/resolv.conf can statically contain 127.0.0.1 and the interface configurer can convey its nameserver addresses to the caching nameserver. (If the caching nameserver is dnsmasq, one way to convey the information is to write the addresses to /etc/resolv.conf and dnsmasq will read them from there.) Resolvconf doesn't offer any benefits under these circumstances. (Nor should it bring disbenefits.)

Resolvconf is only really beneficial when the system has multiple interface configurers. Then it, or something like it, is needed in order to keep track of which addresses and search paths come from where.

[Thomas Hood (jdthood)]

Just read what Steve wrote in #13:
> - nothing should be writing to /etc at runtime;
> it's a bug that causes Ubuntu to not work out
> of the box with a read-only rootfs
> - even when not booting with a read-only rootfs,
> there is a race condition between mounting /
> rw and running dhclient, the latter being triggered
> as soon as a network device is found by udev.
> (This was worked around last cycle in dhclient,
> but it works by making the boot slower than
> it should be.)
> - there are half a dozen different packages in the
> archive that all have support for updating
> /etc/resolv.conf directly under various circumstances.
> This is unnecessary duplication of code, they probably
> all have different bugs, they certainly don't coordinate
> with one another, and they generally don't do
> the right thing in the case of multiple network devices.

What he said!

Resolvconf is really a very simple bit of script glue. After years of use in Debian it can be characterized as mature. The package still has some significant shortcomings but almost all of these are related to the fact that resolvconf is an optional package in Debian. E.g., it gets installed on a system with network interfaces already configured and won't have correct nameserver information until the next reboot. (Installing the package should trigger the "System needs restarting" indicator. I'll file a report about that.) E.g., because it's optional it has to guess what it should do with the old resolv.conf file on installation, and has to guess whether it's appropriate to restore this file on removal. It has to ask debconf questions which then have to be translated into all the world's natural languages. That kind of thing. If the package is part of the base system then these sorts of problems don't arise.

Other issues perhaps worth discussing are
* compatibility with chroots
* compatibility with nameserver-information suppliers not running as root --- they run /sbin/resolvconf as non-root and thus run resolvconf hook scripts as non-root... hmm...

If anyone sees problems in these areas then please open separate, specific bug reports, preferably including details of failure cases.
--
Thomas

[Jérôme Poulin (jeromepoulin)]

On my side, I just want to use what is already bundled with Ubuntu, systemd-resolved.service(8). I symlinked /run/systemd/resolve/resolv.conf to /etc/resolv.conf but now I'm stuck with this ubuntu-minimal dependency.