Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Development (http://www.linux-archive.org/fedora-development/)
-   -   UsrMove continued (http://www.linux-archive.org/fedora-development/710682-usrmove-continued.html)

Serge 10-08-2012 11:18 PM

UsrMove continued
 
Hello.

Modern Fedora had 14 non-empty root directories:
/boot
/bin
/dev
/etc
/home
/lib
/proc
/root
/run
/sbin
/sys
/tmp
/usr
/var
Original UsrMove had "fixed" just 3 of them. But the rest are still there.
What do you think about fixing them all?

Instead of all these directories we can have it as simple as:
/os -- OS, kernel-space
/usr -- user-space, shareable, possibly read-only,
/var -- variable system data, read-write, non-shareable
/home -- variable user data, read-write, shareable
And nothing else.

Changes in depth:
/os:
/os/boot
/os/dev
/os/proc
/os/sys
/usr:
/usr/etc
/usr/bin
/usr/lib
/usr/root
/usr/sbin
/var:
/var/run
/var/tmp
/home remains unchanged

Details
=======
* /dev, /proc and /sys are used for talking to kernel, they go to /os.

* /boot contains the kernel itself, so /os is also a good place for it.

* /root was initially on a root partition because 'root' user should be
able to login even when all other FS (including /usr) are not mounted.
Since now it can't do anything without /usr anyway, /root dir don't have
to be in /.

* /etc contains data and configs for userspace programs, it's useless
without them, and don't have to be separated. After all GNU autotools
have never been aware of such split in the first place.

* /tmp is not really needed any more. Single /var/tmp temporary directory
is enough, it can be automatically cleaned by tmpwatch as usual
(this also solves the problem of large files not fitting in small /tmp)

* As long as initramfs is able to mount /usr it can certainly mount /var.
There's no need for a separate /run in that case, it just pollutes root
directory, so it can be moved back to /var, it's a variable data directory
after all.

User Experience
===============
* fewer toplevel directories

Benefits to Fedora
==================
* Simpler and cleaner overall file system layout, with full compatibility.
* Clear separation of kernel-space, user-space and files of regular users.
* Improved compatibility with build systems such as GNU autotools who never
have been aware of the /usr split in the first place
* Minimize difference to other *nix systems, such as Android and Solaris,
which already use similar approach
* Isolate the vendor-supplied mostly read-only operating system resources
from the rest, thus allow snapshotting of the OS, and easy lightweight
container OS duplication

This is not a new feature. It has same reasons and same benefits as
original UsrMove. But there're more:

* Dedicated root partition is not necessary any more

* which gives unique ability for NFS-booted diskless stations: initramfs
only mounts /home (rw, shared), /usr (ro, shared) and /var (rw, dedicated)
directly to the initramfs layout.

* In some distant future it may be possible to have multiple operating
systems installed in subdirectories of a single partition. I.e. user
would have /F21, /F22 and /F23 dirs, and initramfs just binds /usr, /var
and /home to /F2*/subdirs. No more partitioning, resizing and moving
disks around. If you're an Ubuntu user and want to try Fedora you just
install it on top of the same partition. If you don't like it, you
only need to remove the /Fedora dir.

* Compat-symlinks would still remain there for a long time, but they can
probably be hidden from non-root users (UID!=0) with some eyecandy
kernel module. Alternatively (probably not, but still) they can be
completely replaced with a special redirecting compat-kernel module.

Obviously this won't go in F18. But it mostly works, you can test it:
0. Get Fedora17 LiveCD
1. Boot it with additional kernel params:
selinux=0 systemd.log_level=debug systemd.log_target=console init=/bin/bash
2. When you get the shell:
# mkdir /os /os/proc /os/sys /os/dev
# mount --move /proc /os/proc; rm -rf /proc; ln -s os/proc /
# mount --move /sys /os/sys; rm -rf /sys; ln -s os/sys /
# mount --move /dev /os/dev; rm -rf /dev; ln -s os/dev /
# mv /boot /os/; ln -s os/boot /
# rm -f /var/run; mkdir /var/run
# mount -n --move /run /var/run; rm -rf /run; ln -s var/run /
# mv -f /root /etc /usr/; ln -s usr/root usr/etc /
# mount --bind /var/tmp /tmp
# exec /sbin/init
and it should work as usual.

PS: Actually only "selinux=0 init=/bin/bash" is needed in kernel params.
The "systemd.log..." part is there just as a workaround. F17 Live can be
booted without it. F18 works fine for me without it in QEMU, but freezes
on real hardware. Not sure why, it happens with regular F18Alpha too.
Some race condition systemd bug?

--
Serge
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Jochen Schmitt 10-09-2012 06:33 AM

UsrMove continued
 
On Tue, Oct 09, 2012 at 02:18:10AM +0300, Serge wrote:
> * /root was initially on a root partition because 'root' user should be
> able to login even when all other FS (including /usr) are not mounted.
> Since now it can't do anything without /usr anyway, /root dir don't have
> to be in /.

I want to disagree with your suggestion. /root is the home directory of
the superuser and should not be placed on a network device in opposite
of the home directories of the ordinary users. The user root should be
able to logon without a network connection to do any rescue work on
the system.

> * /etc contains data and configs for userspace programs, it's useless
> without them, and don't have to be separated. After all GNU autotools
> have never been aware of such split in the first place.

I want to consider, that /etc should be mounted on a writeable partition
in opposite of /usr to allow changes without remounting.

Best Regards:

Jochen Schmitt
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Jochen Schmitt 10-09-2012 06:41 AM

UsrMove continued
 
On Tue, Oct 09, 2012 at 02:18:10AM +0300, Serge wrote:

> Obviously this won't go in F18. But it mostly works, you can test it:
> 0. Get Fedora17 LiveCD
> 1. Boot it with additional kernel params:
> selinux=0 systemd.log_level=debug systemd.log_target=console init=/bin/bash
> 2. When you get the shell:
> # mkdir /os /os/proc /os/sys /os/dev
> # mount --move /proc /os/proc; rm -rf /proc; ln -s os/proc /
> # mount --move /sys /os/sys; rm -rf /sys; ln -s os/sys /
> # mount --move /dev /os/dev; rm -rf /dev; ln -s os/dev /
> # mv /boot /os/; ln -s os/boot /
> # rm -f /var/run; mkdir /var/run
> # mount -n --move /run /var/run; rm -rf /run; ln -s var/run /
> # mv -f /root /etc /usr/; ln -s usr/root usr/etc /
> # mount --bind /var/tmp /tmp
> # exec /sbin/init
> and it should work as usual.

your test case didn't hit your suggestion of remove the /etc
directory. I think you have put any more love to workout
your suggestion on this topic.

Best Regards:

Jochen Schmitt
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

"Richard W.M. Jones" 10-09-2012 07:40 AM

UsrMove continued
 
So you make your system incompatible with every other Linux distro out
there, and with all existing documentation, but to what end? Tidyness?

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

"tim.lauridsen@gmail.com" 10-09-2012 08:13 AM

UsrMove continued
 
On Tue, Oct 9, 2012 at 9:40 AM, Richard W.M. Jones <rjones@redhat.com> wrote:

So you make your system incompatible with every other Linux distro out

there, and with all existing documentation, but to what end? Tidyness?



Rich.



--

Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones

New in Fedora 11: Fedora Windows cross-compiler. Compile Windows

programs, test, and build Windows installers. Over 70 libraries supprt'd

http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw

--

devel mailing list

devel@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/devel
+1 to Richard, I really don't see the purpose, why does it matter that number of dirs in /.
Lot of apps will break if you move /proc or /dev, and if you replace them with symlink in the next 10 years you still have the same number of dirs under /, you have even more because you have added some new ones.
I can understand you want to merge dirs there have the same function /bin -> /usr/bin, but this has no benefits at all.
Tim


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

"Richard W.M. Jones" 10-09-2012 08:40 AM

UsrMove continued
 
On Tue, Oct 09, 2012 at 10:13:03AM +0200, tim.lauridsen@gmail.com wrote:
> On Tue, Oct 9, 2012 at 9:40 AM, Richard W.M. Jones <rjones@redhat.com>wrote:
>
> > So you make your system incompatible with every other Linux distro out
> > there, and with all existing documentation, but to what end? Tidyness?
> >
> > Rich.
> >
> > --
> > Richard Jones, Virtualization Group, Red Hat
> > http://people.redhat.com/~rjones
> > New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
> > programs, test, and build Windows installers. Over 70 libraries supprt'd
> > http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
> > --
> > devel mailing list
> > devel@lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
> >
>
> +1 to Richard, I really don't see the purpose, why does it matter that
> number of dirs in /.
> Lot of apps will break if you move /proc or /dev, and if you replace them
> with symlink in the next 10 years you still have the same number of dirs
> under /, you have even more because you have added some new ones.
> I can understand you want to merge dirs there have the same function /bin
> -> /usr/bin, but this has no benefits at all.

Plus, this proposal makes no attempt whatsoever to investigate other
schemes. People have already "fixed" the Unix filesystem, with
varying degrees of success. Take a look at Plan9 for a positive
example, or OS X for a negative example.

"Those who cannot learn from history are doomed to repeat it".
Unfortunately this phrase is never truer than when talking about
computer programmers.

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Tomas Radej 10-09-2012 11:18 AM

UsrMove continued
 
On 10/09/2012 10:13 AM, tim.lauridsen@gmail.com wrote:


I can understand you want to merge dirs there have the same function
/bin -> /usr/bin, but this has no benefits at all.




I am not sure if this has no benefits whatsoever, but I do agree that if
you want to keep the compatibility (which you IMHO should), you need to
keep the symlinks, indeed making the "tidiness" argument invalid.
Compatibility between distros is also a big thing for me, because quite
often I look for solutions to Fedora problems in Arch or Debian forums,
and I do find them.


So +1 to status quo.

TR

--
FAS, IRC nick tradej
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Konstantin Ryabitsev 10-09-2012 02:01 PM

UsrMove continued
 
On Tue, Oct 9, 2012 at 4:13 AM, tim.lauridsen@gmail.com
<tim.lauridsen@gmail.com> wrote:
> +1 to Richard, I really don't see the purpose, why does it matter that
> number of dirs in /.
> Lot of apps will break if you move /proc or /dev, and if you replace them
> with symlink in the next 10 years you still have the same number of dirs
> under /, you have even more because you have added some new ones.
> I can understand you want to merge dirs there have the same function /bin
> -> /usr/bin, but this has no benefits at all.

Symlinks also dramatically complicate SELinux policies, since you then
have to allow read_lnk_files in addition to plain filesystem access.
Allowing read_lnk_files is undesirable, as there is a number of
security vulnerabilities that make use of symbolic links, so this will
be a net negative to the security of the system.

Regards,
--
Konstantin Ryabitsev
LinuxFoundation.org
Montréal, Québec
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

DJ Delorie 10-09-2012 05:08 PM

UsrMove continued
 
> * /root was initially on a root partition because 'root' user should be
> able to login even when all other FS (including /usr) are not mounted.
> Since now it can't do anything without /usr anyway, /root dir don't have
> to be in /.

As an example of why this is a bad idea...

I have a file server that, until recently, had /usr on an LVM so it
could be dynamically resized. Sometimes, the machine would
unexpectedly reboot and be unable to bring the VGs up. The repair
scripts were in ~root. I would boot the rescue disk, ro-mount /, and
run the repair scripts.

If ~root were in the VG somewhere I would not have been able to repair
the system.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Daniel J Walsh 10-09-2012 06:39 PM

UsrMove continued
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/09/2012 04:01 PM, Konstantin Ryabitsev wrote:
> On Tue, Oct 9, 2012 at 4:13 AM, tim.lauridsen@gmail.com
> <tim.lauridsen@gmail.com> wrote:
>> +1 to Richard, I really don't see the purpose, why does it matter that
>> number of dirs in /. Lot of apps will break if you move /proc or /dev,
>> and if you replace them with symlink in the next 10 years you still have
>> the same number of dirs under /, you have even more because you have
>> added some new ones. I can understand you want to merge dirs there have
>> the same function /bin -> /usr/bin, but this has no benefits at all.
>
> Symlinks also dramatically complicate SELinux policies, since you then have
> to allow read_lnk_files in addition to plain filesystem access. Allowing
> read_lnk_files is undesirable, as there is a number of security
> vulnerabilities that make use of symbolic links, so this will be a net
> negative to the security of the system.
>
> Regards, -- Konstantin Ryabitsev LinuxFoundation.org Montréal, Québec
>
I think drastic might be an exagerations. In this case most apps will be just
reading links to var_t, usr_t and other system defaults, which almost all
domains can currently do.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlB0b2sACgkQrlYvE4MpobNwPgCdHBMP4YoVOf SDoKNlGVCYTYR8
/04An0Lw69Mp5BI+ArequUsc6c8PJB/Y
=JLRH
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


All times are GMT. The time now is 06:34 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.