Re: Nameserver-pushing mechanism
On Sun, Apr 13, 2003 at 03:54:58PM +0200, Thomas Hood wrote:
> In the following, where you write '/etc/resolv-update.d' I guess you
> meant to say '/etc/network/resolv-update.d' since /etc/network is
> where ifupdown stores its configuration files.
Sure.
> > Underlying programs to configure interfaces (dhcpcd, pppd, ...) would
> > put their resolv.conf data in /run/network/resolv.d/<interface>. They
> > have no need to call any script to do the update, ifupdown manages it
> > itself.
> > [...]
>
> To change my suggestion into yours:
My suggestion was meant to improve your proposal (on the few points that
still didn't fully convinced me), not to replace it.
> * Move files from /run/resolver/interfaces/ to /run/network/resolv.d/
> * Move files from /etc/resolver/update.d to /etc/network/resolv-update.d
> * Make the latter scripts get their resolv.conf data from stdin
> instead of from the /run/network/resolv.d/* files
This is important. It must be possible to control which nameservers go
to which recipient script. For instance bind mustn't be fed with
himself, but must be fed to others.
> * Rename "/etc/init.d/resolver reload" to "push-resolvers"
And make its usage more exceptional.
> * Make ifupdown call push-resolvers instead of using a script in
> /etc/network/if-up.d.
>
> The only significant difference is that you would put everything in
> the ifupdown package.
Quite true. But IMHO ifupdown is a better place than glibc. And the idea
was not just putting everything into the ifupdown package, but
integrating it to the ifupdown mechanism.
> Why do that?
Bringing one interface up makes some nameservers available. In a way,
these nameservers belong to the interface. Making the set of available
nameservers managed by ifupdown is a logical consequence of this.
Your proposal adresses the following problem : the list of nameservers
is no more static, and resolv.conf is no more fitting. On the other
hand, ifupdown handles mixing static and dynamic configuration of
interfaces quite gracefully. Extending ifupdown to integrate the changes
you are proposing seems appropriate.
Having the nameserver list as a part of each interface's configuration
may be useful/handy/logical.
> > We will also need that ifupdown waits until ppp/dhcp has finished before
> > exiting. This has to be done someday, anyway. /run makes it possible,
> > since we can create, for instance, a /run/network/pid.ppp0 file to be
> > killed -HUP from /etc/ppp/ip(up|down).d/0ifupdown.
>
> I don't understand this. Why do you want ifupdown not to exit
> until while ppp or dhclient are running?
>
> if(up|down) wasn't designed to run as a daemon.
Sorry, I was unclear. I meant that ifup should wait until the interface
is effectively brought up before exiting. In the case of ppp (I don't
know about dhcp), ifupdown just launches pppd, then exit.
Ifup should wait for success (SIGHUP) or failure (pppd dies). This way
it can know the status of the interface better, and full configuration
or failure to configure is made when ifup exits.
I hope i've been a bit more clear.
--
Jeremie Koenig <sprite@sprite.fr.eu.org>
Reply to: