about mtab symlink
dagmar at speakeasy.net
Sun Nov 10 12:13:07 PST 2002
On Sun, 2002-11-10 at 12:30, Tushar T wrote:
> Dagmar d'Surreal wrote:
> >Alright, I'll grant you that I misinterpreted the ugly little table in
> >section 2 and that /etc is described as static, but that only means that
> >it should be a symlink to the interface in /proc/mounts, not that you
> >should be trying to relocate it to someplace less functional in /var.
> >...and frankly, I think they should have put a little more thought into
> >this decision. I mean, c'mon... "mtab does not fit the static nature of
> >/etc", but /etc/passwd does? The existance of footnote 6 makes me
> >wonder what they were thinking.
> I interpret the static data as configuration data that should be backed
> up and variable data as something that doesn't need to be backed up.
> /etc/passwd falls in the former while /etc/mtab certainly doesn't. These
> distinctions do matter, that is the reason we hack the scripts to put
> some binaries in /usr/bin instead of /usr/libexec.
This reply isn't making any sense to me at all. What did this have to
do with whether or not /etc/mtab should be pointing to /proc/mounts?
Furthermore, what exactly does /usr/libexec have to do with this? I was
under the impression that the files were being redirected from
/usr/libexec to /usr/bin because the FHS doesn't mention any
> >The major problem I have with making /etc read-only, or at least
> >designing it that way, is that unless you're going to have a system that
> >requires most of the filesystem be non-writeable for technical reasons
> >(such as booting from a CD) there's _no benefit_ to moving those files
> >out of /etc and making symlinks that point to the other location. More
> >complexity + no added value == bad. For a normal system, it should be
> >enough that everything will be looking for those files in the places
> >that they actually happen to be in. I would n_ever_ recommend a normal
> >system be designed in such a manner as to actually use those as
> A normal system should not hard code file locations unless it is
> absolutely guaranteed by the standard. The standards says that /etc/mtab
> can be a symlink and if I write a script, I have to take that fact into
OKay, that's nice but it has nothing to do with the files that now must
be symlinks that are _not_ mtab. Mtab being a symlink should be the
least of your worries, since you don't actually have to write to it, you
can simply use open() to read it and let the system resolve the
symlinks. Making most of these symlinks _now_ after them being actually
present in /etc since the beginning of time will _break_ a large number
of shell scripts used for administrative tasks.
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev