Add manual options for administrators

[HeinMueck]

Currently - trusty LTS - there is no way to turn off the regeneration of /etc/resolv.conf that would survive a package upgrade.

- you cannot remove resolvconf as it is needed by minimal
- you cannot disable-upgrades as this flag is removed by reboots
- if you disable the resolvconf job in upstart package upgrade will reset the disable-upgrade flags
- if you hack the scripts - it will only last until the next upgrade

There are two ways to ensure that admins willing to turn it off can do so:

First solution: add a run=no to /etc/default/resolvconf and bail out if it is set.

The second solution is more subtile. In /etc/network/if-up.d/000resolvconf you will find this line:

[ -x /sbin/resolvconf ] || exit 0

While in /etc/dhcp/dhclient-enter-hooks.d/resolvconf it says

if [ -x /sbin/resolvconf ] && [ -L /etc/resolv.conf ]; then

Way more clever! So if you do not want to implement the default option, why not check if its a link all the way? So at least a conf gets not overwritten once the admin wrote his own.

[Thomas Hood (jdthood)]

The proper way for the admin to stop /etc/resolv.conf from being updated by resolvconf is for him or her to remove the symbolic link /etc/resolv.conf -> ../run/resolvconf/resolv.conf. The resolvconf program only ever writes to the target of that symlink. Thus, in the absence of that link, resolvconf has no effect on resolv.conf.

Yes, Ubuntu's dhclient-enter-hooks.d/resolvconf checks /etc/resolv.conf and stomps on it if no symbolic link is there. That is different from what the Debian version of the script does and is a departure from the Debian convention. That has been complained about in bug #1385010.

Can you please describe more fully what you perceive to be the problem? That's not clear to me yet.

In advance I will say that it is supposed to be the case that if the admin has removed the symlink at /etc/resolv.conf then upgrading the package does not restore the symlink.

[HeinMueck (cperz)]

Thomas,

what you describe as the proper way will not work at all - take a look at /etc/network/if-up.d/000resolvconf. It only checks if /sbin/resolvconf exists and if it is executable. As it does not check for resolv.conf being a symlink it will never stop if it is not. If it is supposed to be like you said, than this is definitly a bug. I am trying to do this on a bunch of servers and it hits me painfully.

/etc/resolvconf/update.d/libc for instance checks if resolv.conf is a symlink and gives a warning or not - you can configure if the warning should pop up, but not tell it to stop doing its thing :)) What the heck?

bug #1385010 was a very good hint - he convinced me that just checking the link existance is too focused on resolvconf. It needs to be a system variable, that is respected by all packages that have the ability to rewrite resolv.conf.

export UPDATE_RESOLVCONF=no in /etc/environment is the big hammer. Where else could we have it? "resolvconf manual" in /etc/network/interfaces?

done.

[Thomas Hood (jdthood)]

I wrote:
> The proper way for the admin to stop /etc/resolv.conf from
> being updated by resolvconf is for him or her to remove the
> symbolic link /etc/resolv.conf -> ../run/resolvconf/resolv.conf.

HeinMueck wrote:
> what you describe as the proper way will not work at all
>- take a look at /etc/network/if-up.d/000resolvconf.
> It only checks if /sbin/resolvconf exists and if it is executable.
> As it does not check for resolv.conf being a symlink it will
> never stop if it is not.

It checks if /sbin/resolvconf exists and is executable and if so it goes ahead and sends information to resolvconf, otherwise aborting. Resolvconf will process the information that has been sent to it and will generally write out a new /run/resolvconf/resolv.conf. However, if /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf then the latter file will not be accessible via the path /etc/resolv.conf and changes to it will therefore have no effect on the resolver. Thus, removing the symbolic link /etc/resolv.conf -> ../run/resolvconf/resolv.conf stops resolvconf from updating /etc/resolv.conf, just as I said.

Furthermore, the mere presence of /sbin/resolvconf stops most other programs from updating resolv.conf directly because they check for the presence of /sbin/resolvconf and refrain from stomping on /etc/resolv.conf if it is present. (The exception to this rule is dhclient, which updates /etc/resolv.conf even if /sbin/resolvconf is present, if the aforementioned symlink is missing; but I consider that to be an undesirable exception: see bug #1385010.) So the correct way to prevent /etc/resolv.conf from being updated is to leave the resolvconf package installed and to remove the symbolic link /etc/resolv.conf -> ../run/resolvconf/resolv.conf. (And (in Ubuntu) to do something additional to stop dhclient from updating the file, e.g., removing the isc-dhcp-client package... but now we are getting off topic.)

If this explanation isn't clear to you then it's possible that you are confused about how resolvconf works. In that case I suggest you read the resolvconf package README file at /usr/share/doc/resolvconf/README.gz.

If you have a question about how correctly to configure your system(s) in order to obtain a certain desired behavior then please contact me directly.

[HeinMueck (cperz)]

Uuh, Thomas - did not know I am stepping on your toe here. Pardon!

So, your hints where quite helpful as I did not notice the file being updated was the one in /run/resolvconf.

My situation is this:
- 4 Racks of boxes with 1 to 3 networks each
- network 1 is static, the other 2 dhcp
- resolver configuration depends on the existance of networks
- had to take care of this, so I generate the resolv.conf from a package - no link anymore
- once you ifdown/ifup one of the dhcp interfaces, the resolv.conf got overwritten

It was bug #1385010 you led me to that caused this.

As this might help others, here is my workaround.
- create /etc/dhcp/dhclient-enter-hooks.d/000nomk_resolv_conf whith these few lines:

if [ -x /sbin/resolvconf ] && [ ! -L /etc/resolv.conf ]; then
        make_resolv_conf() { : ; }
fi

For me its okay, as I need to run this from a package and make sure that once updates to official packages are installed my resolv.conf will not be overwritten. This is not a solution.

[Thomas Hood (jdthood)]

> did not know I am stepping on your toe here

No toes being stepped on here.

> had to take care of this, so I generate the resolv.conf from a package - no link anymore

OK. Leave the resolvconf package installed; remove the symlink.

> once you ifdown/ifup one of the dhcp interfaces, the resolv.conf got overwritten

It's not resolvconf doing that.

> It was bug #1385010 ... that caused this.

Ah, glad you figured it out. I'll merge this report with that one.