Re: Nameserver-pushing mechanism
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 <jdthood0@yahoo.co.uk>
Reply to: