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 <[EMAIL PROTECTED]>