Re: ifupdown writes to /etc... a bug?
-----BEGIN PGP SIGNED MESSAGE-----
On 26 Mar 2003, Goswin Brederlow wrote:
> Arthur de Jong <email@example.com> writes:
> > I very much like the possibility of a ro-rootfs and would run all my
> > systems with ro-root if it would be easy to set up. But not at the
> > cost of having /run or /mem polluting my filesystem. Making tools more
> > ro-root friendly is a good idea but please keep my root directory
> > clean.
> Would /var/run be ok for you or /var/state? But then one would force the
> creation of another partition or do without a /var partition.
I think state and runtime files should be in /var as much as possible. A
problem occurs obviously at boot-time when /var may not be mounted
already. After mounting /var you may be able to reconstruct things like
mtab from /proc/mounts.
Note that I didn't read the entire thread but my problem was mainly with
adding another toplevel directory that is outside the FHS.
> > Also I don't think it's very easy to make a distinction between admin
> > related activity and "normal" activity done by unpriviliged users
> > (e.g. regularly update /etc/motd with news items, changing passwords,
> > adding a virtual host to apache config, etc). I don't think it's very
> > clear what should go in /run and what in /etc if you decide to make a
> > /run.
> The destinction should be between maschine writeable files, user and
> admin activity. The first must exist, the later two can be limited. Of
> cause the best solution would be to have the RO / system behave exactly
> as a RW / system does (for all alowed actions) but that won't happen. A
> RO / will have some advantages and some drawbacks.
> Every admin has to weight the two against each other and decide (and
> accept the punishment from his users if he's wrong :).
I like the current solution where patches are made to allow for the
"problem files" to be symlinks. I agree that having a RO / will always
cause some extra work for an admin and it is good to limit the amount of
work as much as possible. My only problem was adding a new toplevel
directory (ugly ugly) per default and noting that it is difficult to find
a generic solution for all the "problem files".
- -- arthur - firstname.lastname@example.org - http://tiefighter.et.tudelft.nl/~arthur --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
-----END PGP SIGNATURE-----