Re: /run and read-only /etc
On Wed, 2003-04-09 at 12:46, Emile van Bergen wrote:
[... lots of stuff with which I entirely agree omitted ...]
> I personally think a single update-resolvers script provided by each
> local cache / resolving library, possibly through the alternatives
> mechanism is enough; I see little advantage in doing a full blown
> run-parts.
Reasons: simplicity, flexibility.
update-resolvers should be owned by libc6 so that it is there
even if no "resolver" packages are installed. It ought to be
a conffile and a shell script so that it is easily modifiable.
Yet it ought to work reasonably well in its default state.
It has to call programs belonging to the individual resolver
packages which know how to configure the resolver programs.
Using run-parts is an easy way to set this up. Bind, for
example, simply includes its named.conf update script as
/etc/resolvers/bind and this will be run by subsequent
invocations of update-resolvers (unless the admin has removed
the run-parts line, of course).
Remember that one might want to futz with both resolv.conf
*and* named.conf when a new interface comes up. E.g., one
might want to list additional nameservers after 127.0.0.1 in
resolv.conf even if a local nameserver is running.
It is true that update-resolvers could call a single "update"
program selected by the alternatives mechanism. That way is
slightly harder to implement, and it builds in the assumption
that only one package at a time needs to be informed of
resolver updates. That's a questionable assumption.
> I'd definitely to put the scripts outside /etc/resolvers though;
> I'd expect them to be fairly static, not conffiles.
On the contrary, I think they should be easily customizable.
John Hasler <john@dhh.gt.org> wrote:
> update-resolvers options:
> --activate <filename> Move the symlink to <filename>.
> --deactivate <filename> Move the symlink back where it was
>
> update-resolvers and /etc/resolvers/update would have more options
> and logic that I'm not ready to write up right now. There also
> needs to be policy on how the various packages that want to futz
> with resolv.conf cooperate.
It shouldn't be that complicated. I don't envision
update-resolvers having any options. It will simply run scripts
which generate configuration file fragments and then reload
services.
> Nameserver entries aren't that easy either. See bug #111670 for a
> discussion of the problems of merging versions of resolv.conf.
This is one reason why all these have to be conffile scripts.
--
Thomas Hood <jdthood0@yahoo.co.uk>
Reply to: