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
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
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.
Cos'è che attualmente non funziona con l'avere una partizione separata di /usr?
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
Non ho una partizione separata di /usr. Cosa cambia per me?
Non cambia nessuna funzionalità. Tutti i vecchi path sono raggiungibili, poichè esistono symlink compatibili che non sono stati rimossi (almeno per il momento). Tutti gli script e i binari dovrebbero funzionare come prima. Per il processo di aggiornamento, si troveranno /sbin, /bin, /lib e /lib64 contenenti soprattutto link simbolici. Nel breve, poichè queste directory contengono soltanto link simbolici, l'intera directory verrà sostituita da un solo link simbolico. Questi tre o quattro link simbolici di alto livello resteranno lì fintanto che l'ABI di elf loader di linux è definito da “/lib/ld-linux.so.2” o dalla controparte di architettura specifica come “/lib64/ld-linux-x86-64.so.2” e fintanto che gli script usano “#!/bin/sh”.
Ho una partizione separata di /usr. Cosa cambia per me?
Non si è sicuri di come sia stato fatto ciò. In generale, avere una una partizione /usr separata non funziona per il momento. Consultare http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken. Ma con l'implementazione di questa caratteristica, le cose ritorneranno ad un modo sano e supportato di avere un punto di mount /usr.
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.
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.