Re: ifupdown writes to /etc... a bug?
On Fri, 2003-03-14 at 23:11, Anthony Towns wrote:
> Munging around with /var/run is unnecessarily complicated, buys us
> _nothing_ but pain, and is probably impossible to do reliably. "/run"
> is a solution that's easy to handle, easy to convert all existing systems
> to, easy to describe, reliable, and easily adaptible for admins who want
> to run their systems differently.
Continuing to use /var/run as the only path to runtime state files
would be convenient. I haven't seen the argument that shows that
symlinks /var/run -> /run would be unreliable.
However, the analogy with /bin versus /usr/bin, etc., is persuasive.
We partition programs into those required to boot and those not
required to boot, so there is a precedent for partitioning state
files likewise. Indeed, it is likely to be common that programs
in /bin and /sbin will use state files in /run, while those in
/usr/bin and /usr/sbin will use state files in /var/run.
How to implement this? The easiest way is to do nothing. Currently,
ifupdown writes its state files in /etc, which works fine on many
systems. If an individual admin wants to make /etc readonly then
he can do:
mkdir /run /run/network
mv /etc/network/ifstate /run/network/ifstate
ln -s /run/network/ifstate /etc/network/ifstate
If his root filesystem is also readonly then he can do the same,
making /run the mount point of a tmpfs. (Or if his kernel doesn't
support tmpfs then he can make /run/network/ifstate a fifo and
run a daemon that makes it behave like a file.)
Things become trickier if it is decided that ifupdown's state
file should become /run/network/ifstate proper. The ifupdown
release that makes the change will have to do some checking
Thomas Hood <email@example.com>
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts