Features/UsrMove/it

From FedoraProject

< Features | UsrMove(Difference between revisions)
Jump to: navigation, search
Line 204: Line 204:
 
Ma con l'implementazione di questa caratteristica, le cose ritorneranno ad un modo sano e supportato di avere un punto di mount /usr.
 
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? ====
+
==== Perchè non risolvere la situazione attuale con /usr, ponendo tutti i binari rilevanti in /bin /sbin /lib e /lib64? ====
and
+
e
==== So, why don’t you just mount /usr from the initramfs and leave the files where they are? ====
+
==== Quindi, perchè non montare proprio /usr dall'initramfs e lasciare i file dove sono? ====
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.
+
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.  
  
==== You are doing it wrong! /bin and /sbin are there to rescue a broken /usr! ====
+
==== Si sta facendo la cosa sbagliata! /bin ed /sbin sono lì per ripristinare una /usr non funzionante! ====
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.   
+
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 ...
  
==== Then, let’s share /bin /sbin /lib /lib64 and /usr and mount them all from the initramfs! ====
+
==== Perchè non spostare tutto il contenuto di /usr in / e dimenticarsi di /usr? ====
Now, you get a feeling, that moving everything to /usr might make things easier....
+
Perchè ciò introduce un gran numero di nuove directory di alto livello, che devono essere punti di montaggio da essere condivisi con altri host.
 
+
==== 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? ====
 
==== 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.
 
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.
 +
 +
==== Non si può cercare di essere più chiari nei documenti? ====
  
 
[[Category:FeatureAcceptedF17]]
 
[[Category:FeatureAcceptedF17]]

Revision as of 15:26, 16 December 2011

Contents

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

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

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.

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.

Non si può cercare di essere più chiari nei documenti?