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

Re: /run and read-only /etc

Clearly what is needed here is an API for resolver updates that uses the
observer pattern.  Packages that wish to be informed of a resolver
change install a notifier-method script in a resov.d directory.  libc or
whatever includes one that updates the /etc/resolv.conf file.  named can
include one, etc, etc.

Whenever dhcp/ppp/whatever decides to change the info, it passes it in a
standard format (doesn't matter who changed it, or who is receiving the
update), hence the API.  It then does a run-parts on the resolv.d dir.

So each provider (dhcp/ppp/etc) doesn't have to "support" all the
different packages that are interested in the info, and neither do the
packages have to "support" specific interface autoconfig schemes

In Debian, there should possibly be a policy decided upon. (what the dir
is, what API is, etc)



On Wed, 2003-04-09 at 06:22, 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).
> 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?) Might a more strict format of theese files (as they
> are written/read by programs) useful?
> > /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?
> Hochachtungsvoll,
>   Bernhard R. Link
> -- 
> Sendmail is like emacs: A nice operating system, but missing
> an editor and a MTA.

Reply to: