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

Re: deprecating /usr as a standalone filesystem?

Roger Leigh wrote:
On Thu, May 14, 2009 at 03:53:23PM +0200, Giacomo A. Catenazzi wrote:
Gabor Gombas wrote:
On Wed, May 13, 2009 at 12:38:45PM -0500, Manoj Srivastava wrote:

        it is the principle of the thing. /root is the home directory
 for the  root user.  Home directories are mutable, programs may store
 configuration files there, as may the user, by themselves. The root
 user should not be more constrained than other users on the machine are;
 making wirking as root irritating, less customizable, and harder does
 not help the end user admin any.

        Ideally, we should map /root somewhere persistent, writable, and
 also a location available in single user mode; and there are few
 pleasing solutions that meet that criteria; though less than perfect
 solutions exist.
I fail to see how root is different to any other random user in this
regard. If you want / to be read-only, then you should ensure that /home
points to something writable. The same thing holds for /root. You can
make /home and /root to be separate filesystems, or bind mounts or
symlinks pointing to a writable location. If you can handle /home today
then you can also handle /root exactly the same way.
No, /root cannot be a separate filesystem.
/root is part of very basic system, and it is required for super user
when he/she is restoring the systems or doing some kind of administration
(e.g. moving filesystems, etc.).

Why do these tasks require a writable (or even present) /root?

Interesting question. I think none, but:
- someone pointed they would like .bash_history (but this is a sysadmin
- On my system I've data from aptitude, vim, less, mc , but I think
  I these program can works also without root (BTW all in /usr)
- mysql puts admin password in /root , so maybe it is required to
  to mysql maintenance (I expect: existence, but shoudl be ok for read-only)
- ssh/scp: not sure, (but they are in /usr)


Reply to: