On Tue, Jun 25, 2002 at 12:27:50PM -0500, Manoj Srivastava wrote:
> >>"Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:
> Anthony> (a) needs to be available, and modifiable when only / is mounted
> Anthony> (b) needs to be available when only / is mounted
> Anthony> (c) needs to be available and modifiable when only local
> Anthony> fses are mounted
> Anthony> (d) needs to be available when only local fses are mounted
> Anthony> (e) needs to be available and modifiable after network
> Anthony> fses are mounted
> Anthony> (f) needs to be available after network fses are mounted
> Anthony> (a) shouldn't be supported, and (e) and (f) should be and
> Anthony> can be placed in /var on all systems. Further (f) alone
> Anthony> covers the *vast* majority of configuration files.
> /etc/auto/ would meet these guidelines, except possibly a, if
> / is initially mounted ro.
Right: (a) might work for some people, but it's impossible to make it
work for everyone, so _no_ package should _ever_ rely on it.
> The reason I am pluggin /etc. and why I think this is distinct
> from the run time varying files in /var, is that /etc/auto files
> ought to be only modified during installs; we do not expect files to
> be popping up in /etc/auto.
Actually we do: that's cases (c) and (e). /etc/network/ifstate is an
example (although not a particularly good one, since it shouldn't really
be in /etc anyway), /etc/resolv.conf when you're using DHCP is probably
a better one. One some setups /etc/fstab is also an example; IIRC, I
know someone who likes to have /etc/fstab adjusted so that he can easily
mount the network shares that're available wherever he happens to be.
If / is mounted ro, then (b) and (c,e) need to be on different partitions,
and therefore in different directories (the former needs to be on /,
the latter needs to be rw). I think there's a good argument for putting
(c,e) under /var: I mean, the whole point about them is that they change
at times other than when the admin deliberately makes them change (with
"vi", or "apt-get install" or "update-modules" or webmin or similar). And
if they're being regenerated semi-regularly anyway, then there's no great
need to back them up, either.
> Anthony> Another possibility (even more symlinks!) would be something like:
> Anthony> /etc/managed-directories/
> Anthony> atboot-access/
> Anthony> local-modify -> /var/lib/managed-directories
> Anthony> local-access -> /var/lib/managed-directories
> Anthony> /etc/network/ifstate ->
> Anthony> /etc/managed-directories/local-modify/ifupdown/ifstate
> Anthony> which would mean that if you wanted to make /var a network
> Anthony> drive, that you could find all the files in
> Anthony> /var/lib/managed-directories referenced via a local-modify
> Anthony> or local-access symlink and move them somewhere more
> Anthony> appropriate. Something like:
> I would prefer if this variant also was under /etc somewhere,
> but otherwise me like-um.
Well, that's trivially achievable by pointing the symlinks elsewhere. It's
not entirely clear to me what level of granularity is actually desirable.
We could set things up so that:
(a) not supported
(b,d,f) all under /etc/auto/{debconf,webmin,...}
(c) under /etc/automod-local/{dhclient,ifupdown,...}
(e) under /var/{run,lib,..}
and make /etc/auto-modified a symlink that points at /var/lib/automod/
by default, or /site-var/lib/automod if /var is NFS mounted.
Actually, there is one reason not to put (b,d,f) under "/etc": it'd
suggest that we might have some intention of preserving changes made to
those files, which is what we're aiming to avoid.
> Anthony> Food for thought: would we be better or worse off if dpkg conffiles
> Anthony> suffered a similar fate (say, /etc/managed/dpkg/squid.conf)?
> If it works for some configuration files, it should work for
> others, even if they happen to be conffiles.
I mean more that files marked as conffiles could get put in
/etc/auto/dpkg/squid.conf, and a symlink added as /etc/squid.conf. Then
dpkg could automatically update /etc/auto/dpkg/squid.conf without having
to prompt ever...
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif
Attachment:
pgpo81xGni9ym.pgp
Description: PGP signature