#77 consider moving cmtab back to /etc

[Till Maas]

cmtab is now in /var/run instead of /etc, which probably makes it imposible to cleanly mount /var using mount.crypt, because umount of /var at powerdown will not work, because /var/run/cmtab won't contain an entry for /var. An alternative would be to store the loop device and open crypto mapping as a mount option in /etc/mtab (did mount.crypt maybe do this in a previous version?), so that cmtab is not needed at all. A problem with using /etc/cmtab is that it won't be purged at boot and might contain old entries if the devices are not umounted.

[Jan Engelhardt]

Moving it out of /etc was an idea from Jörg Sommer on bugs.debian.org.
References: http://bugs.debian.org/551327
Discuss.

[Till Maas]

In the bug it is proposed to use /lib/pam-mount as runtime variable data space, but this is also not backed up by the FHS, because it says that /lib is for shared libraries and kernel modules:

| /lib : Essential shared libraries and kernel modules
| Purpose
|
| The /lib directory contains those shared library images needed to boot the system and run the commands in the
| root filesystem, ie. by binaries in /bin and /sbin.

IMHO the FHS is incomplete here, because it does not cover where to store dynamic data on the /etc. Since mtab is allowed to be on /etc and not proposed to be moved to some generic place on / to eventually make the FHS consistent it is imho ok for cmtab to be on /etc, too.

But I would also welcome to just get rid of cmtab and store the additional information just in /etc/mtab as options.