Features/UsrMove/it

In other languages: English (en) italiano (it) [edit]

Spostamento di tutto in /usr

Sommario

Fornire una modalità per montare in sola lettura quasi l'intero sistema operativo installato, in modo da effettuare automaticamente snapshot, o condividerlo tra host multipli al fine di ridurre spazio e mauntenzione. Invece di diffondere il contenuto dei pacchetti RPM in tutto lo spazio del filesystem, ed artificialmente separare /bin da /usr/bin e /lib da /usr/lib, si sposta tutto il contenuto in /usr, fornendo soltanto link simbolici nel filesystem radice.

/usr nel proprio filesystem fornisce molte preziose opzioni per le impostazioni personalizzate. Per ragioni storiche, si sono separati molti strumenti da /usr e spostati in /. Ma, le caratteristiche avanzate nei sistemi attuali non possono realmente condurre ad una /usr vuota. Sempre più rientrano in modo labile in tali impostazioni.

Invece di spostare altri strumenti in /, allo stato attuale si richiede che /usr sia montata da initramfs, per essere disponibile prima dell'effettivo avvio di 'init'. La separazione del filesystem di root su /usr, in Linux, non serve ad alcun proposito ma complica o previene impostazioni semplici e più flessibili.

Manutentore

• Nome: Harald Hoyer
• Email: harald@redhat.com
• Nome: Kay Sievers
• Email: kay@redhat.com

Stato corrente

Consultare la versione originale.

Descrizione dettagliata

Non esiste un modo per allevare in modo affidabile un sistema moderno con una /usr vuota; le alternative sono due: copiare /usr nel rootfs o usare una initramfs che mascheri la separazione dal sistema.

Storicamente, /bin, /sbin, /lib avevano il proposito di contenere gli strumenti per montare /usr. Tale ruolo ora può essere conferito ad initramfs. Poichè l'initramfs sa dove trovare la partizione di root (che include /etc), esso può analizzare /etc/fstab ed altri file di configurazione e montare /usr prima di attivare la partizione di root ed eseguire /usr/bin/init. Da questo punto in poi, init monta le partizioni rimenenti in /etc/fstab ed il sistema si avvia come al solito.

Il piano di lungo periodo è di rimettere ordine nella confusione creata dall'attuale separazione tra / e /usr. Tutti gli strumenti ritorneranno in /usr dove essi appartengono, ed il rootfs conterrà soltanto link simbolici a /usr. Quasi l'intero sistema installato di pacchetti resiederà in /usr. Ciò separerà tutti i dati non host specifici in /usr. /usr può quindi essere vista come la partizione delle risorse di sistema Unix (/System), che definisce il sistema operativo di base (p.e. F18 o RHEL-7).

Questa nuova /usr, per impostazione predefinita, potrebbe essere montata in sola lettura, mentre la rootfs è montata in lettura-scrittura e contiene soltanto punti di montaggio vuoti, link simbolici a /usr e i dati host specifici come /etc, /root, /srv. Rispetto alle impostazioni attuali, il rootfs sarà molto piccolo. La nuova /usr potrebbe anche essere facilmente condivisa in sola lettura tra diversi sistemi, e potrebbe contenere quasi l'intero sistema. Tali impostazioni sono molto efficenti, in grado di fornire maggiore sicurezza, maggiore flessibilità, maggiori valide opzioni per impostazioni personalizzate, e risultano più semplici da configurare e mantenere.

Tutto ciò, lascia le seguenti directory ben definite, che compongono la base del sistema:

• /usr - sistema installato; condivisibile; possibilmente in sola lettura;
• /etc - dati di configurazione; non-condivisibile;
• /var - dati persistenti; non-condivisibile;
• /run - dati temporanei; non-condivisibile; filesystem tmpfs obbligatorio.

/
|-- etc
|-- usr
|   |-- bin
|   |-- sbin
|   |-- lib
|   `-- lib64
|-- run
|-- var
|-- bin -> usr/bin
|-- sbin -> usr/sbin
|-- lib -> usr/lib
`-- lib64 -> usr/lib64

Vantaggi per Fedora

• Layout di file system più semplice e pulito, con piena compatibilità
• Chiara separazione di risorse specifiche tra sistema operativo e host
• Migliore compatibilità possibile, nessuna confusione sulle locazioni degli strumenti di installazione, nessun $PATH fiddling, tutti i possibili path ad un binario funzioneranno sempre.

Scope

• La possibilità di condividere /usr è utile soprattutto a macchine virtuali e cluster.
• La possibilità di montare /usr in sola lettura (p.e. su supporti in sola lettura) può aggiungere sicurezza alla macchina.
• L'intera /usr può essere sicuramente snapshotted durante gli upgrade.

How To Test

• update a Fedora package with files in /bin, /sbin, /lib or /lib64 via yum

-> see symbolic links in /bin, /sbin, /lib or /lib64 pointing to the file /usr/bin /usr/sbin /usr/lib or /usr/lib64

or

• install a fresh F17

-> see symbolic toplevel links:

 /lib -> usr/lib
 /lib64 -> usr/lib64
 /sbin -> usr/sbin
 /bin -> usr/bin
 /usr/sbin -> bin

Ensure that basic shell operations work.

# /sbin/ifconfig |/bin/grep -i ip

User Experience

• less toplevel directories

Dependencies

• initramfs (dracut)
• changes in selinux policies
• repackaging of packages with content in /bin, /sbin, /lib*
• alternatives symlinks?
• filesystem rpm, toplevel symlinks

Roadmap

• Provide a shell script to move all content from /bin, /sbin, /lib, /lib64 to /usr.
• Add check to filesystem.rpm version 3, that refuses to install itself when /bin, /sbin, /lib, /lib64 is a directory. On new installation: create symlinks /bin -> usr/bin, /sbin -> usr/sbin, /lib -> usr/lib, /lib64 -> usr/lib64
• Change the ~260 RPM packages with files in /bin, /sbin, /lib, /lib64 to install into /usr, and add Conflicts: filesystem < 3.
• Change the SELinux policies.
• Make sure dracut is able to mount needed filesystems specifies in /etc/fstab before starting systemd.

Buildsystem Transition

• Disable mock root cache in buildsystem
• Step 1: Build without filesystem conflict

 acl
 attr
 db4
 findutils
 gawk
 gettext
 gzip
 nss-softokn
 policycoreutils

• Step 2: Build

 coreutils (without filesystem conflict)
 filesystem
 util-linux

• Step 3: Build

 udev
 systemd

• Step 4: Build

 alsa-utils
 blktool
 davfs2
 ethtool
 fuse
 gcc
 iputils
 isdn4k-utils
 kernel
 libdb
 libselinux
 mingw32-gcc
 nano
 ncpfs
 plymouth
 psacct
 rp-pppoe

• Step 5: Build with filesystem conflict

 acl
 attr
 db4
 findutils
 gawk
 gettext
 gzip
 nss-softokn
 policycoreutils
 coreutils 

• Turn root cache back in buildsystem mock

Contingency Plan

• We do not support to bootup with an empty /usr today, so moving things to /usr and have compat links in the rootfs should be low risk.

Documentazione

• Questa pagina è la fonte primaria di documentazione.
• Why /usr on a separate partition is broken currently
• Discussion on fedora-devel
• Proposal for openSUSE
• Discussion on debian-devel
• Discussion on gentoo-devel and several following threads about udev and /usr
• Discussion on slashdot
• Media
  • itworld.com
  • osnews.com
  • Heise
  • Heise - german only

Release Notes

• With this release, packages will not install files anymore in the following directories: /bin /sbin /lib /lib64 and /usr/sbin.
• Fresh installations of this release, will have the following symbolic links in the toplevel directory:

 /bin -> usr/bin
 /sbin -> usr/sbin
 /lib -> usr/lib

and for 64bit architectures

 /lib64 -> usr/lib64

Comments and Discussion

• See Talk:Features/UsrMove

FAQ

Quale problema si sta cecando di risolvere ?

Si vuole rendere /usr condivisibile in un modo sano.

Ulteriori benefici di questa caratteristica sono:

• minore confusione nel file system
• se si crea uno snapshot di /usr prima di un aggiornamento, si crea con un colpo solo lo snapshot del sistema operativo.

What is currently broken with having /usr as a separate partition?

http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

I don’t have /usr as a separate partition. What changes for me?

Nothing changes in functionality. All the old paths are reachable, because there a compat symlinks in place, which will not go away (at least not in the near future). All your scripts and binaries should work, like they did before. For the upgrade process to work, you will find /sbin, /bin, /lib and /lib64 mostly containing symbolic links. As soon, as these directories only contain symbolic links, the whole directory is replaced by only one symbolic link. These three or four toplevel symbolic links will stay there as long as the linux elf loader ABI is defined with “/lib/ld-linux.so.2” or their architecture specific counterpart like “/lib64/ld-linux-x86-64.so.2”, and as long as scripts use “#!/bin/sh”.

I have /usr as a separate partition. What changes for me?

Not sure, how you managed to do that. In general, having /usr as a separate partition does not really work right now. See http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken. But with this feature implemented, things will now come back to a sane and supported way of having a /usr mount point.

Why don’t you fix the /usr situation by putting all the relevant binaries in /bin /sbin /lib and /lib64?

and

So, why don’t you just mount /usr from the initramfs and leave the files where they are?

Ok, so imagine you have a /usr mounted from a network location and you want to update a package. So maybe you mount the master copy of /usr on your master machine and update /usr with your package manager. Then you provide a new copy of the master /usr to the other machines, when they reboot. They all have the new updated /usr now. But what about /sbin /bin /lib and /lib64? They still have the old binaries. No glibc security update for them. So, every machine has to update these directories via rsync or such (rpm will not work with a readonly /usr). This doubles the maintenance to keep both parts of the system in sync.

You are doing it wrong! /bin and /sbin are there to rescue a broken /usr!

The most critical filesystem is /boot, because the kernel lives there. So the purpose of having /bin and /sbin for /usr repairing relied on _two_ working filesystems ( / and /boot). If either of them was broken, you were not able to rescue /usr. The role of the rescue system can easily be fulfilled by a rescue initramfs. So having the rescue initramfs in /boot, which contains the fsck utils, is in the same danger of becoming corrupted as the kernel. Now you only have to pull out your rescue CD, if /boot is corrupted and not if / is corrupted.

Then, let’s share /bin /sbin /lib /lib64 and /usr and mount them all from the initramfs!

Now, you get a feeling, that moving everything to /usr might make things easier....

Why don’t you move all /usr contents to / and forget about /usr?

Because this introduces a lot of new toplevel directories, which all have to be mount points then to be shared across other hosts.

Ok, but what about a root filesystem on the network and mounting local filesystems only?

Then you would share the toplevel directory hierarchy among all hosts. Hosts would need to mount /etc and /var for host-only versions. Especially /etc/fstab is not accessible, without adding information to the initramfs on how to mount it. For every host-only additional top level directory like /opt and /srv, you would have to have a mountpoint.