On Mon, Jun 24, 2002 at 08:35:26PM -0500, Steve Langasek wrote:
> > We could always ask a debconf question about it...
> But even /var being mounted locally is not sufficient for modules.conf.
Yick. There's evidently a reason why I avoid looking at those files.
> You may have multiple SCSI hosts in a machine, and /var may be on a
> drive attached to one that's loaded as a module after boot. It almost
> seems necessary to me that /var-local exist on all systems, if this
> solution is going to be entertained.
Well, I wouldn't actually go so far as to say that. Loading a module
before you're able to get at a module seems reasonably unusual to me:
(a) because most people will have /var on the same sort of disk as /,
(b) because, aiui, most people prefer to avoid having their core systems
be modular, and (c) because most of the rest probably prefer to use the
fancy initrd stuff. But even so, that doesn't let us move S20modutils
to be after S35mountall.sh. :-/
So, evidently there really are three stages that're important:
(a) / is mounted
(b) local filesystems are mounted
(c) network filesystems are mounted
/var is always available after (c), and usually available after
(b). However some autogenerated config files are needed between (a) and
(b).
An easy solution would be just to make an exception for those config
files. Except the particular conffile under discussion is reference before
S35mountall.sh (in S30setserial), which would pretty much miss the point.
Is there any reason why it's done quite so early?
Perhaps a better idea would be to use something like
/etc/managed/debconf/*, rather than using /var. That'd ensure they're
available at the right time, and presumably wouldn't be too annoying since
managed config files shouldn't change any more often than regular ones.
Although, really, that's only true of debconf; things like dhclient can
cause config files like /etc/resolv.conf to change much more frequently
than that. Using DHCP and mounting /etc read-only shouldn't be mutually
exclusive things. But DHCP may need to be running before /var is mounted,
and if we're not allowed to use /etc because we want to mount it ro,
then we're forced to use somewhere else.
(I don't really like the idea of creating a new top level directory for
this in general. As a hack for weird people, sure, but on every Debian
system? Ugh)
I guess what would be /ideal/ would be to have /var/lib/something
or /var/run/something be available immediately upon boot, and have
some fancy munging happen to ensure it's still available in the same
place when /var gets mounted properly. But having something available
immediately upon boot doesn't work since it'd have to be on /, which we
want to mount read-only. So forget that.
Ramdisks are probably out of the question since people are almost
certainly running systems that don't support them. Likewise putting it
on another real filesystem is probably out of the question, since that
just gives us all the problems of /var.
So much for that idea. Evidently we need different areas:
(a) Somewhere for /etc/modutils.conf, which is on /
(b) Somewhere for ipchains rules, which is on a local fs
(c) Somewhere for /etc/resolv.conf, and /etc/network/ifstate, which
is a local fs and mounted rw
(d) (Somehwere for other stuff)
Which gives you two orthogonal requirements:
Available (a) on boot, (b) on a local filesystem, (c) at all
and Can be changed (x) automatically, or (y) by the sysadmin running some
tool.
So:
(cx) and (cy) are covered by /var/lib and /var/run
(bx) and (by) can *usually*, but not always, be in /var too.
(ay) could be /etc/managed/ or /etc-managed or similar
(ax) probably isn't going to be supported
That would let us say:
(cx) always goes in /var/lib or /var/run (depending on whether it's
relevant across reboots)
(cy) always goes in /var/lib
(bx) and (by) need to respect the contents of /etc/somethingorother,
which will tell them to either use /var, or /local-var, or some
other directory.
(ay) will always go in /etc/managed/
Your worst case scenario is then something like this:
/etc mounted read-only
modular network card
roaming network configured by DHCP (ie, different /etc/resolv.confs)
/var mounted remotely (you only roam within your building, say)
which would be handled by:
/etc/managed/
modutils/modules.conf
debconf/serial.conf
webmin/network-interfaces
/fungible/
dhclient/resolv.conf
ifupdown/ifstate
/etc/
network/interfaces -> /etc/managed/webmin/network-interfaces
network/ifstate -> /fungible/ifupdown/ifstate
resolv.conf -> /fungible/dhclient/resolv.conf
serial.conf -> /etc/managed/debconf/serial.conf
modutils.conf -> /etc/managed/modutils/modules.conf
and you'd have:
/fungible mounted locally, rw (possibly a RAM disk)
/var NFS mounted
with /etc/managed-configs.conf containing:
BOOTTIME_MANAGED_CONFIGS=/etc/managed
PRENET_MANAGED_CONFIGS=/etc/managed
PRENET_VARIABLE_DATA=/fungible
. Alternately you could set those to be {/etc/managed,/var/lib,/var/lib}
if /var was a local fs, or {/var/lib,/var/lib,/var/lib} if
/var was guaranteed to always be on your root partition, or
{/fungible,/fungible,/fungible} if you wanted it kept nicely separate.
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:
pgpChk2oOaFAp.pgp
Description: PGP signature