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

Re: /run and read-only /etc


On Wed, Apr 09, 2003 at 12:22:56PM +0200, Bernhard R. Link wrote:

> > An example
> > =---------
> > /run/resolvers/eth0     Created by the DHCP client process that
> >                         has configured interface eth0.
> >                         "resolv.conf"-formatted info for eth0
> > /run/resolvers/ppp0     Created by the pppd process that has
> >                         created ppp0.
> >                         "resolv.conf"-formatted info for ppp0
> > ...
> > /etc/resolvers/default  Included in base-files
> >                         Generates /run/resolv.conf which is a
> >                         composite of the above files.  The local
> >                         admin can link /etc/resolv.conf to that file
> >                         if s/he doesn't run a local DNS cache.
> Hm, I never worked with anything dynamic like dhcp or ppp or even
> several of them. So I wanted to ask why there are entries for
> several configurations. (When I remember correct a program resolving
> an address has no way to specify an interface for doing so).

The advantage is that a system managing a single interface, does not
need to 'edit' a shared file; each has a file of its own. That is an
aspect of directories that's generally underused IMHO.

> I'm also curious, why the parts should be "resolv.conf" formatted.
> Nameserver entries can easily be combined, but domain or search
> statements seem a bit more tricky. (are they transported by dhcp or 
> ppp at all?) 

They are, at least by PPP.

> Might a more strict format of theese files (as they
> are written/read by programs) useful?

It might, but using resolv.conf as the format allows you to implement it
trivially by having pppd/dhcp write their existing file to
/run/resolvers/<interface> and symlinking /etc/resolv.conf to eg.
/run/resolvers/eth0. IOW, it makes implementation smooth and ensures
good backwards compatibility.

> > /etc/resolvers/named    Included in bind package
> >                         Generates /run/bind/named.conf.forwarders
> >                         which is a "forwarders { ... }" statement 
> >                         listing all nameserver addresses listed in
> >                         in the files above.  Then reloads named.
> >                         The admin can include this file inside the
> >                         "options { ... }" statement in named.conf.
> > /etc/resolvers/dnscache Included in djbdns package
> >                         Does appropriate stuff to configure and
> >                         notify dnscache.
> > ...
> > /sbin/update-resolvers  Does a run-parts on /etc/resolvers
> >                         Is called by ifup/ifdown, pon/poff.
> Are multiple "forward-provider" reasonable? Or would an alternative
> link be better?

I personally think a single update-resolvers script provided by each
local cache / resolving library, possibly through the alternatives
mechanism is enough; I see little advantage in doing a full blown

A default version would concatenate (with due care to concatenate
'search' and 'domain' entries into 'search' lists, for sure), the
various resolv.confs into a single one to which /etc/resolv.conf could
be a symlink. Or, as said, you could initially skip this and just have
the admin choose an interface to link his /etc/resolv.conf to.

I'd definitely to put the scripts outside /etc/resolvers though; I'd
expect them to be fairly static, not conffiles.



E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)70 3906153           http://www.e-advies.nl    

Attachment: pgpXfbg_FemEO.pgp
Description: PGP signature

Reply to: