Re: Cleaning up the config files in /etc (Re: As 2.0 looms) (fwd)

Bernd Eckenfels (
20 May 1996 23:58:08 GMT

Dan Merillat ( wrote:
: No. / and /etc is a GOOD thing. Unusual, yes, but good. The goal is
: that I will have 3 read-write areas, /tmp, /home and /var.

Yes, especiall on Server Systems (Internet Servers, Modem Servers,
Point-of-sales terminals, Firewalls) this is very important for stability
and security. Since sysVinit supports named pipes instead of flagfiles and
the linux kernels provides /proc/mtab I dont see much more problems. The
biggest problem is the /dev. The easiest Way (but not the most secure) is to
mount a small ramdisk over /dev after the System has booted. IFS or userfs
can do a good job here, too.

: No, it isn't. That's where you got it wrong.
: My order of operations is:
: 1) Root is mounted (kernel)
: 2) mount -n /var -o rw
: 3) mount -o remount /var
: 4) rm -f /var/run/* (to clean out old pid's, etc.)
: 4) mount -o remount / (still read-only)
: then mount the rest of the system.
: Of course, this only worked once mtab and the locks were in /var/run.

You dont need to write to mtab anyway, just link it to /proc/mounts. /proc
can be mounted as the first filesystem (after the kernel has mounted /) and
then provides an up-todate mounts. If /proc can't be mounted there is no big
problem, your system wont run very well in any case. You sttill can mount
and unmount with "-n".

: Much better then depending on /proc. It would be a VERY nice system call
: to have. Perhaps returning a linked-list of a mtab structure? (one for
: each mounted FS)
: I'd mess with that if I had the need right now. Just moving mtab to var
: has solved a lot of problems.

I realy dont think its a problem to mount /proc and everything is fine. If
mounting /proc fails you are in trouble anyway, no need for another
Kernel-bloat. And the folks who dont run with /proc in kernel for
minimalized systems dount need a /etc/mtab at all. They can simply hardcode
mount and unmount (with -n) in the boot/shutdown scripts.


  (OO)      -- --
 ( .. )  ecki@lina.{,}
  o--o     *plush*  2048/93600EFD  eckes@irc  +4972573817  *plush*
(O____O)       If privacy is outlawed only Outlaws have privacy