Re: boot ordering and resolvconf
Tollef Fog Heen wrote:
> I think changing /etc/resolv.conf automatically is broken at all.
What's the malfunction?
> We should have a generated /run/resolv.conf that's overridden by the
> settings in /etc/resolv.conf (if it exists). This allows you to have a
> consistent set of domains searched for matching hosts even when roaming
> to other networks. It also allows me to express the preference «I want
> to use localhost as a nameserver, always» without resorting to chattr to
> prevent dhclient, NetworkManager and other tools from auto-updating the
> resolv.conf file.
Those features are available in resolvconf.
Let's consider your idea. I like the aspect that /etc/resolv.conf
remains a static file and doesn't have to be symlinked to a generated
resolv.conf.
However, your idea requires that the glibc resolver be enhanced.
And once it is enhanced the logic is cast in binary stone:
/etc/resolv.conf always overrides /run/resolv.conf, period. With
resolvconf the logic is under the control of the administrator.
If the admin puts a static file at /etc/resolv.conf then resolv.conf
is static. If the admin puts a symlink at /etc/resolv.conf then the
target of that symlink is used.
With the resolvconf approach the resolver configuration is readable
in one file which has the familiar semantics, resolv.conf(5). If there
are two files then questions arise about how the one overrides the
other. If /run/resolv.conf contains nameserver options and so does
/etc/resolv.conf, then are both addresses tried, or just the latter, or
what? Also, you will need a third file, also static, to provide defaults
which get overridden by /run/resolv.conf. This will need to be
documented.
If it's the case that the mere existence of a file at /etc/resolv.conf
causes /run/resolv.conf to be completely ignored then there is not
so great a difference between your idea and resolvconf. With
resolvconf, the absence of a symlink at /etc/resolv.conf is what
causes the dynamic resolv.conf to be ignored.
What is missing from your idea so far is functionality to handle
multiple sources of nameserver information. What if the machine
runs both dhclient and a VPN client, or both ifup and pppd? In the
past each of these sorts of programs updated /etc/resolv.conf
and (sometimes) restored the file to the preceding state on exit
which left the file in an incorrect state if programs were stopped
in other than LIFO order.
Some packages make use of resolvconf hook scripts, a mechanism
whereby they get notified when the resolver configuration changes.
You could think about whether or not you want to implement that
too, and how.
Cheers,
- -
Thomas
Reply to: