On Tue, Jun 25, 2002 at 09:01:32AM +0200, Andreas Metzler wrote:
> Then you can move /etc/mtab, /lib/modules/*/modules.dep
> /etc/modules.conf, /etc/network/ifstate, /etc/nologin,
> /etc/adjtime, etc. ;-) to that directory and live happily ever after
> with readonly /etc/.
/etc/mtab is only touched if /'s mounted rw, so is a non-issue. (Although
S55bootmisc.sh seems to rely on it having been touched when cleaning up
/var/lock and such, which might be a bug)
/etc/modules.conf is only generated when you run update-modules, which
is when /etc is rw anyway.
/etc/network/ifstate is only needed after local fses have been mounted.
/etc/nologin and /etc/adjtime aren't used until after network fses have
been mounted.
/lib/modules/*/modules.dep is less dismissable, but in practice, if
you're trying to mount /lib/modules readonly, then you will need to be
pretty careful about running depmod -a by hand anyway. AFAICT, it's not
reasonable to move modules.dep anywhere else in any event. There isn't
any value in protecting it for modifications by the sysadmin.
> But _pretty pretty pretty please_ don't choose /var/somedir/ because
> it is is common, (until now) sensible and recommended by the usual
> Howtos and installation-instructions to place it on a separate
> partition.
Again, please read my other messages in this thread. There are six cases:
(a) needs to be available, and modifiable when only / is mounted
(b) needs to be available when only / is mounted
(c) needs to be available and modifiable when only local fses are mounted
(d) needs to be available when only local fses are mounted
(e) needs to be available and modifiable after network fses are mounted
(f) needs to be available after network fses are mounted
(a) shouldn't be supported, and (e) and (f) should be and can be placed
in /var on all systems. Further (f) alone covers the *vast* majority of
configuration files.
For systems where / is mounted ro, and /var is on the network, a
/site-var mount is required if your system has any files of type (c).
This is a pretty rare situation, though: /var isn't particularly sharable,
unlike /usr. Further, it means you require access to a particular server
to be able to use your machine, which gives you good odds that you've
probably mounted / over the network rather than /var and you can already
do whatever you want.
(b) and (d) can be placed under /etc, without any concerns.
On systems where /var is on some local partition -- and it can be on
its own partition, or it could be a symlink to /usr/var or anywhere --
(c) and (d) can be placed under /var, along with almost all the rest of
the configuration files in Debian.
On systems where / is mounted rw, there's no particular harm in putting
(c) somewhere under /etc, alongside (b) and (d).
The question is whether you want to introduce a new, non-standard,
toplevel directory on hundreds of thousands of systems that don't need
it because there are other existing toplevel directories that are already
required by the FHS for the particular purpose you have in mind.
I'd think you'd want a stronger argument than "I might forget how I set
my system up, and accidently break something when making major changes
to it" to justify something like that.
Note that the only major change that would break things in a default
configuration would be trying to setup /var as an NFS mounted drive.
Another possibility (even more symlinks!) would be something like:
/etc/managed-directories/
atboot-access/
local-modify -> /var/lib/managed-directories
local-access -> /var/lib/managed-directories
/etc/network/ifstate ->
/etc/managed-directories/local-modify/ifupdown/ifstate
which would mean that if you wanted to make /var a network drive, that
you could find all the files in /var/lib/managed-directories referenced
via a local-modify or local-access symlink and move them somewhere
more appropriate. Something like:
find /etc -printf '%i %l\n' |
sed -n 's, /etc/managed-directories/local-modify/.*$,,p' |
while read inode; do
find /etc -inum $inode -printf '%f -> %l\n'
done
would give you a list of files you have to worry about, in such a case.
Food for thought: would we be better or worse off if dpkg conffiles
suffered a similar fate (say, /etc/managed/dpkg/squid.conf)?
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:
pgpgokIpPTDnk.pgp
Description: PGP signature