/usr unifié

[lol]

Salut,
J'avais vu passer ça il y a quelques jours, sans trop y prêter attention, mais je pense que ça mérite tout de même une petite discussion histoire d'éclaircir un peu le sujet.

Debian putting everything on the /usr
Et une discussion sur la mailing list
En Clair (et en Français): Debian met tout dans /usr

/bin et /sbin vont devenir des liens symboliques vers /usr/bin and /usr/sbin
J'ai pas trop compris ce que va devenir /lib mais appartement le répertoire va aussi bouger!

Je trouve que c'est une bonne idée, je ne vois pas à quoi ça pouvait encore servir d'avoir des répertoires séparés.

C'est une discussion ouverte, pas vraiment du support, mais je pense que c'est intéressant que ce soit facilement accessible (Dans PC c'est invisible pour les non inscrits).

[PascalHambourg]

Excellent.
Pour le sport j'avais déjà réalisé cette fusion manuellement sur une installation test de Wheezy ou Jessie dont les paquets n'étaient pas prêts pour cela car il existait des doublons, c'est-à-dire des paires de fichiers de même nom (ou bien un fichier et un lien symbolique) par exemple dans /bin et /usr/bin. J'avais recensé ces doublons avec apt-file, puis créé des "diversions" avec dpkg-divert pour l'un des deux éléments de chaque paire. Au départ j'avais essayé de le faire dès l'installation mais ce n'était pas possible car il y avait des doublons (un fichier et son symlink) dans un paquet de base, et pas de bol le lien symbolique était extrait après le vrai fichier et l'écrasait, rendant le système non fonctionnel.

J'ai pas trop compris ce que va devenir /lib

Pareil : un lien symbolique qui pointe vers /usr/lib.

Je trouve que c'est une bonne idée, je ne vois pas à quoi ça pouvait encore servir d'avoir des répertoires séparés.

A l'origine, l'idée était d'avoir une racine aussi petite que possible, et donc de déporter dans /usr tout ce qui n'était pas strictement nécessaire avant le montage des systèmes de fichiers définis dans /etc/fstab.

A l'heure actuelle, cette distinction est devenue floue notamment car les actions déclenchées par udev, donc potentiellement très tôt lors de l'initialisation, peuvent faire appel à des ressources situées dans /usr. D'autre part l'utilisation d'un initrd/initramfs (racine initiale), qui joue le rôle de fait de la racine minimale, s'est généralisé. Depuis Jessie, l'initramfs prend en charge le montage de /usr, donc un /usr séparé de la racine n'est plus un obstacle à la fusion.

Pour ma part je trouve que cette fusion est intéressante pour deux raisons :
- elle met fin au dilemme de savoir si on doit mettre tel fichier dans la racine ou dans /usr ;
- le fait de monter /usr en lecture seule protège tous les binaires, sans exclure ceux qui sont dans /bin, /sbin et /lib.

Alors oui, il y en quand même qui râlent parce que ça casse un cas particulier qui était la règle il y a fort longtemps : /usr séparé et pas d'initramfs. Déjà, pour se retrouver dans un cas pareil avec Debian, il faut compiler son propre noyau car les noyaux précompilés fournis par Debian ont besoin d'un initramfs. Ensuite, l'absence d'initramfs exclut la possibilité de mettre la racine dans un volume logique LVM, un ensemble RAID logiciel ou un volume chiffré... et, non des moindres, d'identifier la racine à monter par un identifiant persistant de type UUID, ce qui est devenu quasiment indispensable puisque le nommage des périphériques de stockage ATA/SCSI/USB n'est pas toujours déterministe. (Pour être honnête, le format de table de partition GPT définit des UUID de partitions qui peuvent être utilisés par le noyau sans initramfs, contrairement aux UUID traditionnels liés au contenu des partitions.)

[lol]

Salut,
Super explication, merci.
Donc si j'ai bien compris: ce n'est pas pour demain matin, et se lancer dans l'aventure alors qu'il reste une tonne de paquets à ré-écrire reste hasardeux...

Par contre je n'ai pas trouvé de date officielle (ou de version) pour la mise en place. A cause du nombre de paquets à refaire ?

[piratebab]

Perso, je trouvais plus cohérent de mettre d'un coté tout ce qui est strictement systeme, de ce qui est "pas systeme". En gros , ce qu'il ne faut surtout pas toucher, et ce qu'on peux toucher sans risque de casse compliquée à résoudre ..
Mais ma vision est évidement extrêmement simpliste, l'explication de Pascal est plus argumentée ...:)

[Mimoza]

Si l'idée est de mettre tout le système dans «/usr», pourquoi ne pas mettre aussi «/etc» ?

[funkygoby]

N'y a t'il pas un problème à déplacer toute cette complexité de plus en plus tôt? Si je comprends bien l'initramfs est un OS à part entière. Où est ce qu'il loge?
Ça me fait penser aux puces qui embarquent des JVM ou des minis OSes.

Perso, je trouvais plus cohérent de mettre d'un coté tout ce qui est strictement systeme, de ce qui est "pas systeme".

"pas système" ça veut dire installé par la suite? Ça se trouve trouve normalement dans /usr/local (sur OBSD en tout cas). En tout cas, /usr unifié veut dire que /bin va dans /usr/bin, /sbin va dans /usr/sbin, etc...(selon modalités, voir au dos du paquet) mais /usr/local ne bougera pas.

[PascalHambourg]

Donc si j'ai bien compris: ce n'est pas pour demain matin, et se lancer dans l'aventure alors qu'il reste une tonne de paquets à ré-écrire reste hasardeux...

D'après la liste des bugs liés à usrmerge, il n'en reste pas beaucoup d'identifiés et non corrigés.

Perso, je trouvais plus cohérent de mettre d'un coté tout ce qui est strictement systeme, de ce qui est "pas systeme".

Le problème est de définir la frontière entre les deux. Les discussions pointées sur la liste debian-devel en témoignent. Par exemple une bibliothèque peut se retrouver du côté "système" parce qu'une nouvelle version d'un outil système en dépend. Et un programme quelconque peut se retrouver du côté système parce qu'une règle udev y fait appel. En résumé, cette approche a été jugée irréalisable en pratique.

Si l'idée est de mettre tout le système dans «/usr», pourquoi ne pas mettre aussi «/etc» ?

Il n'a jamais été question de mettre tout le système dans /usr, mais de fusionner le contenu de /bin, /sbin et /lib* dans les sous-répertoires correspondants de /usr.

D'autre part, une particularité du contenu de ces répertoires est que
1) Il provient exclusivement des paquets installés
2) il est utilisé en lecture seule la plupart du temps (sauf lors de l'installation, mise à jour ou suppression de paquets), à quelques très rares exceptions près (la base d'identifiants PCI de lspci, qui peut être mise à jour avec la commande update-pciids, est la seule que je connais ; la base d'identifiants USB de lsusb qui peut également être mise à jour avec update-usbids est stockée dans /var, avec un lien symbolique dans /usr qui pointe dessus).

Le contenu de /etc ne correspond pas ces critères. Il n'existe pas de /usr/etc. Certes on y trouve des scripts d'init (jusqu'à ce que le support des scripts d'init traditionnels soit abandonné par systemd) et des fichiers de configuration installés par des paquets, mais ils sont gérés en conffiles par dpkg et modifiables par l'administrateur ou divers processus (exemple : /etc/resolv.conf ; cependant lui aussi tend à devenir un lien symbolique pointant ailleurs).

D'autre part, /etc contient le fichier /etc/fstab. Après avoir monté la racine, l'initramfs actuel lit ce fichier pour déterminer si /usr est un système de fichiers distinct de la racine et le monter le cas échéant. Ceci dit, ce ne serait pas la seule façon de monter /usr ; on pourrait aussi bien utiliser un paramètre de la ligne de commande du noyau comme on le fait pour la racine (root=).

Si je comprends bien l'initramfs est un OS à part entière. Où est ce qu'il loge?

Oui, combiné au noyau l'initramfs peut être un véritable système et pas seulement une racine initiale transitoire. Un exemple est l'installateur Debian. L'initramfs peut être situé n'importe où pourvu qu'il puisse être chargé par le chargeur d'amorçage, mais sur les architectures "classiques" (non embarquées) il est traditionnellement situé dans /boot comme le noyau. Il peut aussi être intégré au noyau, ce qui est utile dans le cas où on ne veut pas s'embarrasser d'un initramfs séparé ou si le chargeur d'amorçage ne permet pas d'utiliser un initramfs.

"pas système" ça veut dire installé par la suite?

Par la suite de quoi ? De l'installation initiale ? De l'installation du système de base ? Les paquets installés lors de ces phases sont variables. Un même programme serait donc "système" s'il a été installé lors de l'installation initiale (exemple : LVM si le système est en LVM) mais "non système" s'il est installé ultérieurement ? Compliqué à gérer.

Ça se trouve trouve normalement dans /usr/local (sur OBSD en tout cas)

La plupart du temps, /usr/local contient les logiciels qui ne font pas partie de la distribution, installés en dehors du gestionnaire de paquets et généralement compilés localement.

[lol]

Salut,

D'après la liste des bugs liés à usrmerge, il n'en reste pas beaucoup d'identifiés et non corrigés.

Top, je pensais qu'il y en avait beaucoup plus!
C'est une bonne nouvelle, je suis content de ce changement. Ça simplifie l'architecture et la lecture de l'arborescence.

[piratebab]

Merci Pascal, la lecture de tes posts est toujours aussi passionante.Le fait que /usr soit monté en lecture seule m’amène une question. Ne faudrait il pas se poser la question de l'utilisateur root. D'aprés ce que j'ai compris en te lisant, il y a maintenant une distinction de faite entre un exécutable et son fichier de conf. L'un est en lecture seule, l'autre non.
Donc ils sont considérés avec des niveaux de sécurité différents. Ils devraient donc étre gérés par des utilisateurs avec des pouvoirs différents ...
bien je ne vois pas trop l’intérêt de mettre un applicatif en lecture seule, et pas son fichier de conf. en modifiant un fichier de conf, on peux fortement augmenter le pouvoir de nuisance d'u applicatif!

[PascalHambourg]

Je me suis sans doute mal exprimé : l'unification de /usr n'entraîne pas de facto le montage de /usr en lecture seule. Le montage en lecture est une possibilité qui a existé de tous temps lorsque le contenu de /usr est dans un système de fichiers distinct du système de fichiers racine, ce dernier ne pouvant pas (du moins pas encore) être monté en lecture seule. Simplement, l'unification de /usr accroît l'intérêt du montage en lecture seule puisque cela protège aussi les programmes, bibliothèques, modules du noyau... contenus dans /bin, /sbin et /lib*, ce qui n'était pas le cas lorsqu'ils étaient dans le système de fichiers racine.

L'intêret de mettre la partie statique du système de fichiers (/boot, /bin, /sbin, /lib*, /usr) en lecture seule, c'est de réduire le risque d'altération accidentelle. Un système de fichiers monté en lecture seule ne peut pas être modifié par erreur et ne risque pas (ou beaucoup moins) d'être corrompu en cas de plantage, reboot forcé, coupure d'alimentation... Ce n'est pas contre la malveillance, puisque même en lecture-écriture il faut être root pour modifier ces fichiers et si on est root on peut aussi bien remonter un système de fichiers en lecture-écriture.

Les fichiers de configuration et scripts d'init dans /etc restent vulnérables à une altération accidentelle puisqu'en lecture-écriture, mais leur volume est très réduit donc il est facile d'en faire des sauvegardes.

[piratebab]

OK, c'est clair, merci.