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.
• Solaris (possiede lo stesso modello da anni)
• Why /usr on a separate partition is broken currently
• Discussion on fedora-devel
• Proposal for openSUSE
• Discussion on debian-devel
• Discussion on gentoo-devel e successivi thread su udev e /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.

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.

Perchè non risolvere la situazione attuale con /usr, ponendo tutti i binari rilevanti in /bin /sbin /lib e /lib64?

e

Quindi, perchè non montare proprio /usr dall'initramfs e lasciare i file dove sono?

Va bene, allora si immagini di avere una /usr montata da una locazione di rete e si desideri aggiornare un pacchetto. Probabilmente si monterà la copia principale di /usr sulla macchina principale e si aggiornerà /usr con il manutentore di pacchetti. Poi si provvede ad una nuova copia della /usr principale sulle altre macchine, in fase di reboot. Ora tutte hanno la nuova /usr aggiornata. Ma che si può dire di /sbin /bin /lib e /lib64? Esse contengono ancora i vecchi binari. Per loro non esiste nessun aggiornamento di sicurezza di glibc. Perciò ogni macchina deve aggiornare queste directory via rsync o simile (rpm non funziona con una /usr in sola lettura). Ciò duplica la manutenzione di tenere entrambe le parti in sync.

Si sta facendo la cosa sbagliata! /bin ed /sbin sono lì per ripristinare una /usr non funzionante!

Il filesystem più critico è /boot, perchè il kernel vive quì. Perciò il proposito di avere /bin ed /sbin per riparare /usr si basava su _due_ filesystem funzionanti (/ e /boot). Se entrambi erano non funzionanti, non si era capaci di recuperare la /usr. Il ruolo del sistema di ripristino può essere facilmente coperto da una iniramfs di ripristino. Perciò avere la iniramfs di ripristino in /boot, contenente gli strumenti di fsck, incorre nello stesso pericolo di diventare corrotta del kernel. In questo modo basta tirar fuori il CD di ripristino, se la /boot è corrotta e invece no se è corrotta la /.

Quindi, si condivide /bin /sbin /lib /lib64 e /usr e si montano tutti da initramfs!

Ora, inizi ad avere la sensazione che muovere ogni cosa in /usr potrebbe rendere le cose più semplici ...

Perchè non spostare tutto il contenuto di /usr in / e dimenticarsi di /usr?

Perchè ciò introduce un gran numero di nuove directory di alto livello, che devono essere punti di montaggio da essere condivisi con altri host.

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.

Ok, ma che si può dire di un root filesystem di rete e di un filesystem montato localmente?

In tal caso si vuole condividere la gerarchia di directory di livello superiore tra tutti gli host. Gli host moterebbero /etc e /var per le versioni solo host. In particolare /etc/fstab non è accessibile, senza aggiungere inormazione all'initramfs su come montarlo. Per ogni host con con directory addizionali come /opt ed /srv, si dovrebbe avere un punto di mount.