[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
and alerting.

Thomas Hood <jdthood0@yahoo.co.uk>

Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

Reply to: