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

Re: /run and read-only /etc

(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
          * /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 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 <jdthood0@yahoo.co.uk>

Reply to: