Re: /run and read-only /etc
Can someone point me the message(s) discussing /run (and why not
/etc/run) - I would like to think that adding another directory off /
should be avoided. /etc/run sounds nice, unless you want to support
booting before /etc is mounted...
Cheers,
Jeremy
On Wed, 2003-04-09 at 14:17, Thomas Hood wrote:
> Here are:
> * an updated list of wishes,
> * an updated TODO suggestion for resolv.conf based on Emile's idea,
> * a brief rationale for adding /run/,
> * and a discussion of some FHS passages that present problems.
>
> We need to find more of the programs that routinely write to /etc.
> Russell might be of some help here. :)
>
> The read-only root effort
> =========================
>
> Wish reports filed or updated
> * sysvinit
> #150355: Please move motd to /var/lib/
> NEW: #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
> * 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 update-resolver
> * Create script /etc/ppp/ip-down.d/resolver to:
> * Delete /run/resolver/interfaces/$PPP_IFACE
> * Then call update-resolver
> * 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 update-resolver
> * Add script /etc/pump/down to:
> * Delete /run/resolver/interfaces/$IFACE
> * Then call update-resolver
> * 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 update-resolver
>
> TODO later
> * 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
> ===============================
>
> 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. "Software should 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. "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. "[/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.10 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 <jdthood0@yahoo.co.uk>
>
Reply to: