On Sun, 2003-04-13 at 19:25, Jeremie Koenig wrote: >> * 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.
In my proposal, "/etc/init.d/resolver reload" generates /run/resolv.conf, so this isn't an problem. Sending the resolv.conf data through a pipe makes it only slightly (if at all) easier to write the update script, and it elides information (viz., the interface with which the nameserver is associated) for which the script could have some use. > [...] the idea > was not just putting everything into the ifupdown package, but > integrating it to the ifupdown mechanism. Yes, it is a good idea to integrate resolver updating closely with ifupdown. I am not sure it is appropriate to use ifupdown directories, though, as if we were extending ifupdown proper. The resolver is not part of ifupdown. > Having the nameserver list as a part of each interface's configuration > may be useful/handy/logical. I think this part of your proposal can be regarded as a wish for ifupdown to be extended so that one can specify nameservers for each logical interface. Listed nameservers would be added through the resolver update mechanism that we will be providing. Good idea for the future; I've added it to the TODO list. > 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. OK, comprendo. > 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. Yes, ifupdown should handle interface-up failures better than it does. There are several bug reports open about this already, e.g., #82339 and those merged with it. And yes, in order to check for ppp's success ifup would have to wait for some signal from ppp. You might want to file a wish for this, including your SIGHUP idea or a patch if you have one. Perhaps a wish should be filed against ppp too, because the basic problem is that pon doesn't wait to see if the interface comes up successfully. In any case, this functionality is absent from the present ppp and ifupdown and may continue to be absent for a long time. Therefore, we have to make the resolver update stuff work with ifupdown in its present form. That means adding scripts to the /etc/ppp/ip-(up|down).d/ and /etc/network/if-(up|down).d/ dirs. If ifupdown is enhanced so that (as mentioned above) it * waits to see if pppd succeeds, and * handles nameserver addition on ifup, deletion on ifdown, then the scripts can be eliminated. -- Thomas Hood <[EMAIL PROTECTED]>