Re: boot ordering and resolvconf
]] Thomas Hood
> Tollef Fog Heen wrote:
> > I think changing /etc/resolv.conf automatically is broken at all.
>
> What's the malfunction?
Automatic processes overwrite explicit admin setups.
> > 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.
It seems resolvconf wants to get its name servers from
/etc/network/interfaces? If so, that won't work particularly well with
NetworkManager, unless I'm mistaken. Also, I don't think updating files
in /etc at runtime is a sensible idea, it should be possible to run with
/ read-only if you want to.
> With the resolvconf approach the resolver configuration is readable
> in one file which has the familiar semantics, resolv.conf(5).
I find resolvconf's behaviour confusing enough that I generally purge it
from all my machines. It is, to me, an abstraction layer that seems to
randomly overwrite my settings. Having it write to /run and having apps
fall back to settings there if there's no setting in /etc/resolv.conf
would ease that confusion, I think.
> 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?
I specified that: settings are overridden, the file in /run is not
masked. Whether you want to append the nameserver list or override the
one from /run should probably be specified. I'd say override, since
appending can easily lead to security breaches.
> 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.
You don't need a third file the defaults are «an empty file», just like
today.
[...]
> 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.
In that case, feel free to provide a framework for packages to
coordinate updates to /run/resolv.conf and have stacking and
whatnot. (They could write to /run/resolv.conf.d/$num_$basename and
resolvconf or a similar tool could build a /run/resolv.conf from that.)
> 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.
I think any packages needing such hooks should just be fixed, since
they're buggy. Adding a lot of infrastructure to work around bugginess
is, IMO, not a good idea.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: