(I am resending this because the earlier version contained
a few minor errors. I suppose I should put this on the web
somewhere and post the link.)
(I repeat the call for people to look for files that are in
/etc/ but shouldn't be.)
Here are:
* an updated list of wishes filed,
* an updated TODO suggestion including a TODO for a resolv.conf
management scheme based on Emile's idea,
* a brief rationale for adding /run/,
* and a discussion of some FHS passages that present problems.
The read-only root effort
=========================
Wish reports filed or updated
* sysvinit
#150355: Please move motd to /var/lib/
#188087: Move ioctl.save out of /etc/
* util-linux
#156489: Please move adjtime out of /etc/
* ppp
#187756: Patch to allow /etc/ to be read-only
* pppconfig
#187810: Please support read-only /etc/
/etc/ppp/ip-up.d/0dns-up and /etc/ppp/ip-down.d/0dns-down
shouldn't create temporary files in /etc/
#187651: Please document how to keep resolv.conf static
* linuxlogo
#187953: Please do not store files in /etc/. Use /var/lib/.
* cupsys
#187954: Move /etc/printcap.cups under /var/
Wishes to be filed (by Jamie Wilkinson) after more testing
I think that the /run/ directory needs to be added before we
can do very much about the resolv.conf problem.
* base-files
Add /run/ directory
* pam, shadow
Allow either /etc/nologin or /run/nologin to prevent nonroot login
* sysvinit:
Touch /run/nologin (not /etc/nologin) when there is a delay
before a shutdown.
* util-linux
Use /run/mtab for mount's statefile
TODO for etc/resolv.conf
Overview
* /etc/resolv.conf -> /run/resolv.conf
* Networking daemon pidfiles go in /run/
* Resolv.conf-like files go in /run/resolver/interfaces/
* DNS cache configuration file fragments go in /run/<dnscch>/
* "/etc/init.d/resolver reload" regenerates /run/resolv.conf
and calls DNS cache update scripts in /etc/resolver/update.d/
* libc6
* Create /etc/init.d/resolver script to:
* Do "run-parts /etc/resolver/update.d"
* Write /run/resolv.conf which:
* lists 127.0.0.1 first if some local nameserver is running
* then lists other nameservers from /run/resolver/interfaces/*
* As B. Link and others have noted, this will have to be done
with some care.
* Change postinst to install symlink in rcS.d
* bind
* Create script /etc/resolver/update.d/bind to:
* Write a "forwarders { ... }" statement to
/run/bind/named.conf.options.forwarders containing
the nameserver adresses from /run/resolver/interfaces/*
* Then do "/etc/init.d/bind reload"
* Change the /etc/bind/named.conf.options file to include
/run/bind/named.conf.options.forwarders within the
"options { ... }" statement.
* dnscache
* Something similar
* ppp
* Change /usr/sbin/pppd to:
* Store PID in /run/, not in /var/run/
* Create script /etc/ppp/ip-up.d/resolver to:
* Write the lines:
nameserver $DNS1
nameserver $DNS2
to /run/resolver/interfaces/$PPP_IFACE
* Then call /etc/init.d/resolver reload
* Create script /etc/ppp/ip-down.d/resolver to:
* Delete /run/resolver/interfaces/$PPP_IFACE
* Then call /etc/init.d/resolver reload
* pump
* Add /etc/pump directory
* Change /sbin/pump to:
* Store PID in /run, not in /var/run
* By default, don't write /etc/resolv.conf
* Run /etc/pump/up after configuring interface, furnishing
$IFACE and nameserver addresses $DNS1 and $DNS2
* Add script /etc/pump/up to:
* Write the lines:
nameserver $DNS1
nameserver $DNS2
to /run/resolver/interfaces/$IFACE
* Then call /etc/init.d/resolver reload
* Add script /etc/pump/down to:
* Delete /run/resolver/interfaces/$IFACE
* Then call /etc/init.d/resolver reload
* Move pump.conf under /etc/pump
* dhcp3-client
* Change /sbin/dhclient to:
* By default, store PID in /run, not in /var/run
* Change /etc/dhcp3/dhclient-script to:
* Write resolv.conf information to
/run/resolver/interfaces/$interface not to /etc/resolv.conf
* Then call /etc/init.d/resolver reload
TODO later
* Fix diskless tools
* ifupdown
* Wish that ifstate be moved under /run/network/
* sysvinit
* Add support for mounting / read-only.
* Add support for mounting /run/ as a separate filesystem.
* The patches in #30446 and #186892 should be reviewed
in implementing this.
Rationale for adding /run directory
===================================
The /var/ hierarchy is for "variable" files -- i.e., files that vary
during normal system operation.
The /var/run/ hierarchy contains variable files that are "unshareable" --
i.e., usable only by one system.
The proposed new directory is for files similar to those in /var/run/
that are not just variable and unshareable but also local -- i.e., they
must be writable independently of network connectivity. Because /var/
is sometimes remote, the new directory will not be based in /var/;
instead it will be based in the root directory. Hence, '/run/'.
Problematic passages in the FHS v.2.2
=====================================
2. "Since / contains both variable and static data, it needs to be
mounted read-write."
Surely it isn't mandatory to mount / read-write. If there is no need
to write to / then / can be mounted read-only.
3.1 "Software must never create or require special files or sub-
directories in the root directory."
We are not software, so it might be that this restriction does not apply.
If the restriction does apply, then the argument is that adding /run is
technically justified and the FHS must be changed to allow it.
5.1 "Everything that once went into /usr/ that is written to during
system operation (as opposed to installation and software maintenance)
must be in /var/."
Nothing we are planning to put in /run/ was ever in /usr/.
5.2 "[/var/]run/ : Data relevant to running processes"
This seems to rule out using /var/run/ for storing state information
between invocations of a program. But we do want to store this sort of
state information in /run/; so this would seem to imply that 'run' is
not an appropriate name for the new directory. However, 5.13 says that
"This directory [viz., /var/run/] contains system information data
describing the system since it was booted." This is less restrictive
than the earlier description and is quite compatible with how we propose
to use /run/. I think we can assume that the important difference of
/var/run/ from /var/lib/ is not that it contains information relevant to
running processes, but that it is cleaned out at boot time and is not
necessarily backed up.
--
Thomas Hood <[EMAIL PROTECTED]>
