Debian / migration "usrmerge"


#1

Bonsoir à tous,

Ça fait quelques jours que je suis tombé sur l’info et que je suis entrain de lire un peu de tout à ce sujet sur le net, et comme ça me parait important j’ai décidé d’ouvrir un fil de discussion ici à ce sujet pour toutes celles et ceux qui seraient intéressés…

Le sujet est donc la migration prochaine des fichiers contenus dans les répertoires {/bin, /lib, /sbin} vers leurs homologues correspondants dans /usr/… ; et un symlink des ces premiers répertoires vers les seconds : le projet usrmerge.

L’objectif de cette migration

(traduction succinte de la page https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ ) :

  • Amélioration de la compatibilité avec les autres Unix / Linux dans le comportement. Après la fusion avec /usr, tous les binaires deviennent disponibles respectivement dans : _
    _ “/bin <–> /usr/bin”

    _"/sbin <–> /usr/sbin _
    "/lib <–> /usr/lib"
    _simplement parce que /bin devient un lien symbolique vers /usr/bin, resp /sbin vers /usr/sbin… _
    Cela signifie que les scripts/programmes écrits pour d’autres Unix ou d’autres Linux et portés à la distribution courante n’auront plus besoin de correction pour les chemins de système de fichiers des binaires appelés, ce qui est par ailleurs une source majeure de frustration. /usr/bin et /bin (resp. /Usr/sbin et /sbin, …) deviennent tout à fait équivalents.

  • Amélioration de la compatibilité avec d’autres Unix (en particulier Solaris) en apparence : la première implémentation commerciale Unix est aujourd’hui Oracle Solaris. Solaris a déjà réalisé la même fusion dans Solaris 11. En opérant le même changement dans Linux, il s’agit de minimiser la différence par rapport à l’implémentation primaire d’Unix, facilitant ainsi la portabilité de Solaris.

  • Amélioration de la compatibilité avec les systèmes de compilation GNU: la majeure partie du logiciel Linux est construite avec GNU autoconf / automake (c’est-à-dire GNU autotools), qui ignorent la division /usr spécifique à Linux. Le maintien de la division /usr nécessite une gestion non triviale du projet dans le système de génération en amont et dans les packages de votre distribution. Avec la fusion /usr, ce travail devient inutile et le portage des paquets vers Linux devient plus simple.

  • Amélioration de la compatibilité avec le développement en amont actuel: Afin de minimiser l’écart entre votre distribution Linux et le développement en amont, la fusion / usr est essentielle.

  • Un schéma de système de fichiers unifié (résultant de la fusion / usr) est plus compatible avec UNIX que le partitionnement traditionnel de Linux de / bin vs. / usr / bin. Les Unix diffèrent de par le chemin où les outils sont installés, leurs emplacements dans de nombreux cas ne sont pas définis du tout et diffèrent dans les différentes distributions Linux. La fusion / usr supprime cette différence dans son intégralité et fournit une compatibilité totale avec les emplacements des outils de n’importe quel Unix via le lien symbolique de / bin vers / usr / bin.

Bon je n’ai pas traduit tout le document, mais je pense que l’essentiel est posé ici.

Ce qu’il faut retenir c’est que cette migration se fera à terme, et que Debian semble être le dernier à passer le cap.
En effet comme cité dans le document pratiquement toutes les autres distributions ont franchi le pas : Solaris depuis environ 15 ans, Fedora est, me semble t-il, la 1ère distrib a avoir complètement emboîté le pas également (à noter une petite digression, pour ceux qui veulent tester, que la dernière version de Fedora est également la 1ère à passer totalement sur Wayland out-of-the-box)…

En ce qui concerne Debian, il était prévu que cette migration se fasse lors de la sortie de Debian Stretch, mais elle a été reportée pour le moment ( source : https://www.phoronix.com/scan.php?page=news_item&px=Debian-Installer-Stretch-RC1 ), apparemment des bugs encore subsistants…

Enfin, malgré le fait que la transition officielle ait été repoussée, il existe d’ores et déjà dans les dépôts des branches Testing et Sid un paquet nommé “usrmerge” :

gogi@blabla:~$ acpol usrmerge
usrmerge:
  Installé : (aucun)
  Candidat : 13
 Table de version :
     13 520
        520 https://deb.debian.org/debian sid/main amd64 Packages
        510 https://deb.debian.org/debian testing/main amd64 Packages

Ce paquet convertira automatiquement le système dans une disposition de répertoires fusionnés dans /usr, mais attention il n’existe pas de méthode automatique pour revenir à la précédente configuration, aussi aucun retour en arrière n’est possible une fois que ce paquet est installé.

Pour vous donner un petit retour d’expérience, j’ai bien sûr déjà essayé la manip sur une machine Debian Sid en VM sous virtualbox, et la migration se fait instantanément, et ce sans soucis par la suite en utilisation…
Néanmoins si vous vous lancez dans l’opération sur votre système principal je ne peux que conseiller de faire une sauvegarde préalable de celui-ci, car on ne sait jamais ce qui peut arriver, et comme il n’y a pas de retour en arrière…

Voilà pour l’intro du sujet.


#2

Voilà donc pour introduire la discussion sur cette migration, maintenant viennent les questions…

Cette migration sera sans doute insignifiante et transparente pour un utilisateur lambda du point de vue “usage classique” (hormis ceux qui concotent quelques binaires locaux etc…, quoique à cet effet il est normalement prévu de placer ceux-ci dans /usr/local/ ou /opt si on suit scrupuleusement la FHS…), elle est de loini plus intéressante pour les développeurs et mainteneurs de paquets, le portage de ceux-ci, etc…

Néanmoins qu’en est-il des réels avantages/inconvénients de cette manoeuvre? J’ai moi même du mal à saisir l’impact réel et donc ma question s’adresse en particulier aux personnes du forum plus expérimentées en la matière (en même temps c’est pas difficile… :joy: ) afin qu’elles eclairent nos lanternes…

Toutes autres questions sont les bienvenues également bien sûr… :smiley:


#3

Le sujet n’est pas nouveau. J’en ai déjà parlé plusieurs fois dans ce forum (ou une autre). J’avais même réalisé la fusion sur une installation de Wheezy ou Jessie il y a plus d’un an, en détectant et résolvant manuellement les conflits.

Du côté des inconvénients, on peut citer :

  • Ça casse quelques configurations très particulières. Si /usr est séparé, il faut obligatoirement utiliser un initrd/initramfs capable de monter /usr. Dans Debian ce n’est pas un problème si on utilise un noyau précompilé standard, qui a besoin d’un initramfs de toute façon, et le générateur d’initramfs par défaut initramfs-tools, qui crée un initramfs capable de monter /usr depuis la version de Jessie. Je ne sais pas ce qu’il en est des autres générateurs d’initramfs disponibles comme dracut et tiny-initramfs.

Du côté des avantages, on peut citer :

  • Pour les développeurs des logiciels amont et des distributions, la fin du casse-tête consistant à se demander si tel binaire doit être placé sur la racine ou dans /usr selon qu’il est susceptible d’être utilisé ou non par le système d’init avant que /usr soit monté (ce qui peut changer via le jeu des dépendances, donc c’est quasiment insoluble).
  • Pour les utilisateurs, plus besoin de se demander si tel binaire est dans /bin ou /usr/bin, etc., ils sont dans les deux.
  • Le montage de /usr en lecture seule protège tous les binaires sans exclure ceux qui sont dans /bin, /lib* et /sbin (en attendant de pouvoir monter la racine en lecture seule, ce qui viendra un jour je pense).

#4

Petite digression : j’ai jamais saisi le réel intérêt de séparer /usr…, quels peut/peuvent être le/s cas d’application utile/s?

Je suis entrain de tester Fedora sur ma machine, et je ferai le test à l’occasion, mais pour l’instant j’ai quelques soucis avec l’installateur de celle-ci, qui n’est absolument pas du tout aussi flexible que celui de Debian, et c’est une vraie bouse pour faire une installation personnalisée (comme ce qu’on peut faire avec Debian en mode expert…).

Deuxième digression : j’ai déjà entendu parler vaguement de monter /usr en lecture seule en lisant ça et là des docs, tutos, forums sur le net.

Pareil, quel est/serait l’intérêt de monter /usr (voir comme tu dis un jour la racine) en lecture seule, en dehors du fait que le système serait évidemment protégé contre toute manipulation accidentelle qui pourrait entraîner la modification/suppression de fichiers/dossiers importants…?
Et dans ce cas lors de mises à jour il faudrait obligatoirement que le gestionnaire de paquets passe d’abord par un remontage de /usr (ou la racine entière) en “rw” avant de procéder à la MàJ?
Enfin je vois vaguement l’objectif de cette manip dans mon esprit mais c’est confus pour ma modeste compréhension, donc si tu peux m’éclairer…


#5

Monter /usr en lecture seule.
Utiliser des types de systèmes de fichiers différents pour la racine et /usr.
Limiter l’étendue d’une corruption d’un système de fichiers.
Limiter la taille de la racine.
Faciliter la sauvegarde et la maintenance.
A vrai dire, un certain nombre des intérêts de la séparation de /usr a disparu avec l’augmentation des capacités de stockage et la généralisation de l’initrd/initramfs qui est devenu une véritable racine minimale. Mais si tes points de supensions voulaient dire “et autres répertoires système comme /boot, /home, /tmp ou /var”, alors l’intérêt demeure de les isoler dans des systèmes de fichiers adaptés aux spécificités de leur usage.

Ça ne te paraît pas suffisant comme intérêt ?
Le montage en lecture seule limite aussi les risques de corruption du système de fichiers en cas de plantage du système ou de coupure d’alimentation.
Cela ne concerne pas seulement /usr mais tout ce qui est utilisé en lecture seule la plupart du temps comme /boot.

Oui, bien sûr. C’est l’affaire de quelques lignes à ajouter dans la configuration d’APT ou de dpkg.


#6

Salut
ça devient le règle dans Debian 10 Buster:

https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.fr.html#merged-usr

https://packages.debian.org/buster/usrmerge

En cas de mise à niveau depuis Debian 9 Stretch

sudo apt install usrmerge

Capture%20d%E2%80%99%C3%A9cran%20du%202019-08-06%2020-31-41

root@debian:~# ls -alrt /
total 80
drwxr-xr-x   2 root root  4096 janv. 24  2016 srv
drwxr-xr-x   2 root root  4096 janv. 24  2016 live-build
drwx------   2 root root 16384 avril  5  2016 lost+found
drwxr-xr-x   4 root root  4096 avril  9  2016 media
drwxr-xr-x   3 root root  4096 sept. 20  2017 mnt
drwxr-xr-x   3 root root  4096 janv. 19  2018 Phoenix
drwxr-xr-x  11 root root  4096 juin  20  2018 var
-rw-r--r--   1 root root     0 avril 24 08:45 0
drwxr-xr-x   7 root root  4096 juil. 23 13:46 home
lrwxrwxrwx   1 root root    26 juil. 27 10:13 vmlinuz -> boot/vmlinuz-5.2.3-xanmod4
lrwxrwxrwx   1 root root    29 juil. 27 10:13 initrd.img -> boot/initrd.img-5.2.3-xanmod4
lrwxrwxrwx   1 root root    27 juil. 27 11:23 vmlinuz.old -> boot/vmlinuz-4.19.0-5-amd64
lrwxrwxrwx   1 root root    30 juil. 27 11:23 initrd.img.old -> boot/initrd.img-4.19.0-5-amd64
drwxr-xr-x   3 root root  4096 août   5 11:24 boot
drwxr-xr-x   7 root root  4096 août   6 08:25 opt
drwx------  35 root root  4096 août   6 18:30 root
dr-xr-xr-x 201 root root     0 août   6 20:03 proc
dr-xr-xr-x  13 root root     0 août   6 20:03 sys
drwxr-xr-x  21 root root  4700 août   6 20:04 dev
drwxr-xr-x  31 root root   880 août   6 20:31 run
drwxr-xr-x  15 root root  4096 août   6 20:32 usr
lrwxrwxrwx   1 root root     7 août   6 20:32 bin -> usr/bin
lrwxrwxrwx   1 root root     8 août   6 20:32 sbin -> usr/sbin
lrwxrwxrwx   1 root root     7 août   6 20:32 lib -> usr/lib
lrwxrwxrwx   1 root root     9 août   6 20:32 lib32 -> usr/lib32
lrwxrwxrwx   1 root root    10 août   6 20:32 libx32 -> usr/libx32
lrwxrwxrwx   1 root root     9 août   6 20:32 lib64 -> usr/lib64
drwxr-xr-x  20 root root  4096 août   6 20:32 ..
drwxr-xr-x  20 root root  4096 août   6 20:32 .
drwxr-xr-x 155 root root 12288 août   6 20:32 etc
drwxrwxrwt  13 root root   320 août   6 20:33 tmp
```

Installation debian buster