[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


> 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: