From Fedora Project Wiki
(Created page with "{{autolang}} = Spostamento di tutto in /usr = == Sommario == Provide a simple way of mounting almost the entire installed operating system read-only, atomically snapshot it, or...")
 
 
(9 intermediate revisions by 2 users not shown)
Line 4: Line 4:


== Sommario ==
== Sommario ==
Provide a simple way of mounting almost the entire installed operating system read-only, atomically snapshot it, or share it between multiple hosts to save maintenance and space. Instead of spreading RPM package content all over the place in the filesystem, and artificially separate /bin from /usr/bin and /lib from /usr/lib, move all content to /usr and provide only symlinks in the root filesystem.
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 manutenzione. 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 on its own filesystem provides a lot of valuable options in custom setups. For historic reasons, we split-off more and more tools from /usr and put them in /. But, advanced features in today's systems can not really bootup with an empty /usr anymore. More and more fails in subtle ways in such setups.
''/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.


Instead of moving more tools to /, we today already require /usr to be mounted from inside the initramfs, to be available before the real 'init' starts. The split of the root filesystem an /usr serves no purpose in Linux anymore and only complicates or prevents simple and more flexible setups.
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.


== Owner ==
== Manutentore ==
* Name: [[User:Harald| Harald Hoyer]]
* Nome: [[User:Harald| Harald Hoyer]]
* Email: harald@redhat.com
* Email: harald@redhat.com
* Name: [[User:kay| Kay Sievers]]
* Nome: [[User:kay| Kay Sievers]]
* Email: kay@redhat.com
* Email: kay@redhat.com


== Current status ==
== Stato corrente ==
* Targeted release: [[Releases/17 | Fedora 17 ]]
Consultare la [[Features/UsrMove#Current_status| versione originale]].
* Last updated: 2011-11-22
* Percentage of completion: 50%


== Detailed Description ==
There is no way to reliably bring up a modern system with an empty /usr, there are two alternatives to fix it: copy /usr back to the rootfs or use an initramfs which can hide the split-off from the system.
== 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.  


Historically /bin, /sbin, /lib had the purpose to contain the utilities to mount /usr. This role can now be taken by the initramfs. Because the initramfs knows, where to find the root partition (which includes /etc), it can parse /etc/fstab and other configuration files and mount /usr before it finally switches the root partition and executes /usr/bin/init. From this point on init mounts the remaining partitions in /etc/fstab and the system starts as usual.
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 rimanenti in /etc/fstab ed il sistema si avvia come al solito.


The long-term plan is to clean up the mess and confusion the current split of / vs. /usr has created. All tools will move back to /usr where they belong, and the rootfs will only contain compat-symlinks into /usr. Almost the entire system installed by packages will reside in /usr. This will split all non-host specific data to /usr. /usr can then be seen as the Unix System Resources partition (/System), which defines the base operating system (e.g. F18 or RHEL-7).
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 risiederà 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).  


This new /usr could be mounted read-only by default, while the rootfs is read-write and contains only empty mount points, compat-symlinks to /usr and the host-specific data like /etc, /root, /srv. Compared to today's setups, the rootfs will be very small. The new /usr could also easily be shared read-only across several systems, and it would contain almost the entire system. Such setups are more efficient, can optionally provide a lot more security, are more flexible, provide more sane options for custom setups, and are much simpler to setup and maintain.
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 efficienti, in grado di fornire maggiore sicurezza, maggiore flessibilità, maggiori valide opzioni per impostazioni personalizzate, e risultano più semplici da configurare e mantenere.  


This leaves us with the following well-defined directories, which compose the base of the system:
Tutto ciò, lascia le seguenti directory ben definite, che compongono la base del sistema:


* /usr - installed system; shareable; possibly read-only
* /usr - sistema installato; condivisibile; possibilmente in sola lettura;
* /etc - config data; non-shareable
* /etc - dati di configurazione; non-condivisibile;
* /var - persistent data; non-shareable;
* /var - dati persistenti; non-condivisibile;
* /run - volatile data; non-shareable; mandatory tmpfs filesystem
* /run - dati temporanei; non-condivisibile; filesystem tmpfs obbligatorio.


<pre>
<pre>
Line 53: Line 52:
</pre>
</pre>


== Benefit to Fedora ==
== Vantaggi per Fedora ==
* Simpler and cleaner overall file system layout, with full compatibility.
* Layout di file system più semplice e pulito, con piena compatibilità
* Clear separation of operating system and host specific resources.
* Chiara separazione di risorse specifiche tra sistema operativo e host
* Best possible compatibility, no confusion about tools install locations, no $PATH fiddling, all possible paths to a binary will always work.
* Migliore compatibilità possibile, nessuna confusione sulle locazioni degli strumenti di installazione, nessun $PATH fiddling, tutti i possibili path ad un binario funzioneranno sempre.  


== Scope ==
== Scope ==
* The ability to share /usr is especially useful for clusters and virtual machines.
* La possibilità di condividere /usr è utile soprattutto a macchine virtuali e cluster.
* The ability to mount /usr read-only (e.g. on read-only media) can add to the security of the machine.
* La possibilità di montare /usr in sola lettura (p.e. su supporti in sola lettura) può aggiungere sicurezza alla macchina.
* The entire /usr can safely be snapshotted during upgrades.
* L'intera /usr può essere sicuramente fotografata durante gli upgrade.  


== How To Test ==
== How To Test ==
* update a Fedora package with files in /bin, /sbin, /lib or /lib64 via yum
Fare riferimento alla [[Features/UsrMove#How To Test |versione originale di questo documento]].
-> see symbolic links in /bin, /sbin, /lib or /lib64 pointing to the file /usr/bin /usr/sbin /usr/lib or /usr/lib64


or
== Esperienza utente ==
 
* install a fresh F17
-> see symbolic toplevel links:
<pre>
/lib -> usr/lib
/lib64 -> usr/lib64
/sbin -> usr/sbin
/bin -> usr/bin
/usr/sbin -> bin
</pre>
 
Ensure that basic shell operations work.
# /sbin/ifconfig |/bin/grep -i ip
 
== User Experience ==
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
* less toplevel directories
Fare riferimento alla [[Features/UsrMove#User Experience |versione originale di questo documento]].


== Dependencies ==
== Dipendenze ==
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel feature)? -->
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel feature)? -->
 
Fare riferimento alla [[Features/UsrMove#Dependencies |versione originale di questo documento]].
* initramfs (dracut)
* changes in selinux policies
* repackaging of packages with content in /bin, /sbin, /lib*
* alternatives symlinks?
* filesystem rpm, toplevel symlinks


== Roadmap ==
== Roadmap ==
* Provide a shell script to move all content from /bin, /sbin, /lib, /lib64 to /usr.
Fare riferimento alla [[Features/UsrMove#Roadmap |versione originale di questo documento]].
* 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 ===
=== Buildsystem Transition ===
* Disable mock root cache in buildsystem
Fare riferimento alla [[Features/UsrMove#Buildsystem Transition |versione originale di questo documento]].
* 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 ==
== Contingency Plan ==
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->


* 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.
Fare riferimento alla [[Features/UsrMove#Contingency Plan |versione originale di questo documento]].


== Documentation ==
== Documentazione ==
<!-- Is there upstream documentation on this feature, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
* Questa pagina è la fonte primaria di documentazione.
* This page is the primary source of documentation
* [http://docs.oracle.com/cd/E23824_01/html/E24456/userenv-1.html Solaris] (possiede lo stesso modello da anni)
* [http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken Why /usr on a separate partition is broken currently ]
* [http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken Why /usr on a separate partition is broken currently ]
* [http://thread.gmane.org/gmane.linux.redhat.fedora.devel/155511/focus=155547 Discussion on fedora-devel]
* [http://thread.gmane.org/gmane.linux.redhat.fedora.devel/155511/focus=155547 Discussion on fedora-devel]
* [http://lists.opensuse.org/opensuse-factory/2011-11/msg01431.html Proposal for openSUSE]
* [http://lists.opensuse.org/opensuse-factory/2011-11/msg01431.html Proposal for openSUSE]
* [http://thread.gmane.org/gmane.linux.debian.devel.general/165785 Discussion on debian-devel]
* [http://thread.gmane.org/gmane.linux.debian.devel.general/165785 Discussion on debian-devel]
* [http://thread.gmane.org/gmane.linux.gentoo.devel/72128 Discussion on gentoo-devel] and several following threads about udev and /usr
* [http://thread.gmane.org/gmane.linux.gentoo.devel/72128 Discussion on gentoo-devel] e successivi thread su udev e /usr
* [http://linux.slashdot.org/story/11/11/02/2129237/fedora-aims-to-simplify-linux-filesystem Discussion on slashdot]
* [http://linux.slashdot.org/story/11/11/02/2129237/fedora-aims-to-simplify-linux-filesystem Discussion on slashdot]
* Media
* Media
Line 172: Line 99:
** [http://heise.de/-1371441 Heise - german only]
** [http://heise.de/-1371441 Heise - german only]


== Release Notes ==
== Note di rilascio ==
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
* 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 ==
Fare riferimento alla [[Features/UsrMove#Release Notes |versione originale di questo documento]].
 
== Commenti and Discussioni ==
* See [[Talk:Features/UsrMove]]
* See [[Talk:Features/UsrMove]]


=== FAQ ===
=== FAQ ===


==== What problem are you trying to solve? ====
==== Quale problema si sta cercando di risolvere? ====
We want to make /usr shareable in a sane way.
Si vuole rendere /usr condivisibile in un modo sano.


Additional benefits of this feature are:
Ulteriori benefici di questa caratteristica sono:
* less clutter across the filesystem
* minore confusione nel file system
* if you snapshot /usr before updating, you have snapshotted the OS at once.
* 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? ====
==== Cos'è che attualmente non funziona con l'avere una partizione separata di /usr? ====
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken


==== I don’t have /usr as a separate partition. What changes for me? ====
==== Non ho una partizione separata di /usr. Cosa cambia per 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”.
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 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? ====
In quel caso si condividerebbe la gerarchia delle directory top-level presso tutit gli host. Essi dovrebbero montare /etc e /var per veriosni host-only. SOprattutto /etc/fstab non sarebbe accessibile senza l'aggiunta di informazioni aggiuntive in initramfs. Per ogni directory top-level host-only, come /opt oppure /srv, si necessiterebbe di un mount point.


==== I have /usr as a separate partition. What changes for me? ====
==== Quindi, perché non montare proprio /usr dall'initramfs e lasciare i file dove sono? ====
Not sure, how you managed to do that. In general, having /usr as a separate partition does not really work right now.
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.  
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? ====
==== Si sta facendo la cosa sbagliata! /bin ed /sbin sono lì per ripristinare una /usr non funzionante! ====
and
Il filesystem più critico è /boot, perché il kernel vive qui. 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 /.
==== 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.
==== 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 ...


==== You are doing it wrong! /bin and /sbin are there to rescue a broken /usr! ====
==== Perché non spostare tutto il contenuto di /usr in / e dimenticarsi di /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.
Perché ciò introduce un gran numero di nuove directory di alto livello, che devono essere punti di montaggio da essere condivisi con altri host.


==== Then, let’s share /bin /sbin /lib /lib64 and /usr and mount them all from the initramfs! ====
==== Ok, ma che si può dire di un root filesystem di rete e di un filesystem montato localmente? ====  
Now, you get a feeling, that moving everything to /usr might make things easier....
In tal caso si vuole condividere la gerarchia di directory di livello superiore tra tutti gli host. Gli host monterebbero /etc e /var per le versioni solo host. In particolare /etc/fstab non è accessibile, senza aggiungere informazione all'initramfs su come montarlo. Per ogni host con con directory addizionali come /opt ed /srv, si dovrebbe avere un punto di mount.


==== 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.


[[Category:FeatureAcceptedF17]]
[[Category:FeatureAcceptedF17]]
[[Category:Italiano]]  
<!-- When your feature page is completed and ready for review -->
<!-- When your feature page is completed and ready for review -->
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->

Latest revision as of 14:23, 20 January 2016

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 manutenzione. 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 rimanenti 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 risiederà 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 efficienti, 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 fotografata durante gli upgrade.

How To Test

Fare riferimento alla versione originale di questo documento.

Esperienza utente

Fare riferimento alla versione originale di questo documento.

Dipendenze

Fare riferimento alla versione originale di questo documento.

Roadmap

Fare riferimento alla versione originale di questo documento.

Buildsystem Transition

Fare riferimento alla versione originale di questo documento.

Contingency Plan

Fare riferimento alla versione originale di questo documento.

Documentazione

Note di rilascio

Fare riferimento alla versione originale di questo documento.

Commenti and Discussioni

FAQ

Quale problema si sta cercando 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 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?

In quel caso si condividerebbe la gerarchia delle directory top-level presso tutit gli host. Essi dovrebbero montare /etc e /var per veriosni host-only. SOprattutto /etc/fstab non sarebbe accessibile senza l'aggiunta di informazioni aggiuntive in initramfs. Per ogni directory top-level host-only, come /opt oppure /srv, si necessiterebbe di un mount point.

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 qui. 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, 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 monterebbero /etc e /var per le versioni solo host. In particolare /etc/fstab non è accessibile, senza aggiungere informazione all'initramfs su come montarlo. Per ogni host con con directory addizionali come /opt ed /srv, si dovrebbe avere un punto di mount.