Rolinh

Rolinh' release

Sbin, C'est *has Been*?

Oui, je sais, le jeu de mot du titre de l’article est pourri mais tant pis. :-P En consultant les articles de mes flux RSS hier soir, je suis tombé sur quelque chose que j’ai trouvé particulièrement intéressant. En effet, les développeurs de la distribution Linux Fedora songent à déplacer tous les binaires dans /usr/bin pour Fedora 17 qui devrait sortir l’année prochaine. Si cela vous parait un changement mineur, sachez qu’il n’en est rien puisque l’on touche à la hiérarchie des systèmes de fichiers. La proposition a d’ailleurs engendré une longue discussion conclue par Lennart Poettering qui résume les points abordés.

Je vais tenter de résumer sans trop d’erreurs ce qu’il en est concernant la hiérarchie des fichiers des systèmes d’exploitation de type Unix.

Peu après le milieu des années 90, une première version de la FHS (Filesystem Hierarchy Standard) a été établie. En premier lieu nommé FSSTND (Filesystem Standard) et visant uniquement les systèmes d’exploitation Linux, le standard s’est élargit aux systèmes de type Unix lors du changement de nom. Il s’agit en fait d’une formalisation étendue de la hiérarchie traditionnelle trouvée dans BSD. La version actuelle du standard date de 2004 et peut se trouver ici.

Aujourd’hui, il est relativement bien suivit par les différentes distributions bien que l’on peut voir quelques exceptions. Je pense notamment à Debian et dérivés qui placent le serveur web dans /var/www alors qu’il devrait se trouver, comme chez Archlinux par exemple, dans /srv/http. Chez les BSD aussi on peut constater des différences. La hiérarchie de Freebsd place par exemple concrètement les home utilisateurs dans /usr/home bien qu’un lien symbolique /home existe à la racine. Il existe également des systèmes Unix-like qui ne respectent absolument pas cette hiérarchie. Je pense à Gobolinux par exemple mais ce genre de cas est plutôt marginal.

Selon FHS, /usr ne devrait pas contenir de binaires ou librairies vitales au fonctionnement du système et ce dernier devrait donc être capable de démarrer sans. Or, ce n’est plus le cas avec systemd, écrit principalement par Lennart Poettering justement, qui est utilisé par défaut dans Fedora depuis la version 15 en remplacement de upstart. Ceci me permet de revenir au sujet principal de ce billet puisque les développeurs derrière Fedora veulent déplacer TOUS les fichiers binaires dans /usr et ainsi le principe évoqué en début de paragraphe ne sera pas respecté. Le but recherché par cette manœuvre est de pouvoir facilement partager /usr, en lecture seule notamment, afin de faciliter les “snapshots”. Ceci concerne donc principalement les machines virtuelles et les clusters.

Qu’en penser? Pour ma part, je ne suis pas contre le fait que les choses changent et évoluent. En revanche, j’ai l’impression que ce changement majeur s’opère de façon unilatérale chez Fedora et cela me déplaît passablement. A quoi cela sert-il d’essayer d’établir des standards si au final on en fait sa propre sauce?

Je vais quand même résumer les principaux points que Lennart Poettering a relevés afin de clore la discussion des développeurs:

  • Il est très difficile pour les développeurs de faire la distinction entre ce qui doit aller /bin et dans /sbin.
  • La définition originale de sbin est devenue obsolète (le “s” tient pour binaires “statiques”).
  • La séparation entre /bin et /sbin n’a rien à voir avec une question de sécurité et ne l’a d’ailleurs jamais été. Le fait de le faire dans ce but serait suivre le principe de “sécurité par l’obscurité” et cela est plutôt stupide.
  • La séparation de /bin et /sbin n’est pertinente que pour $PATH et $PATH ne sert qu’à faciliter l’accès aux outils pour les utilisateurs des shells.
  • Cette séparation est superflue car tous deux sont listés dans $PATH au sein de Fedora.
  • Cette séparation complique les choses. On ne peut justifier cela que si elle est faite pour une bonne raison or il est préférable de privilégier la simplicité.
  • Les différentes distributions Linux ne placent pas forcément les binaires aux mêmes endroits chacune et donc le regroupement serait bénéfique de ce point de vue.
  • L’idée de séparer /usr et / servait principalement pour le début du lancement du système. Le système minimal se trouvant dans / était juste suffisant pour trouver tout le reste de l’OS dans /usr. Cela n’est plus d’actualité.
  • C’est effectivement devenu obsolète en raison d’initrd.
  • Tout avoir dans /usr simplifie radicalement les choses dans le but d’avoir une configuration en lecture seule.
  • Cela rend les snapshots plus facile. En effet, dans le cas de btrfs, faire 5 snapshots de /lib, /lib64, /bin/sbin et /usr est bien moins efficace que de faire simplement un snapshot de /usr.
  • Avoir une séparation claire entre les données partageables (/usr) est préférable pour les configurations réseaux notamment.
  • Cela simplifie les scripts de construction (? –> “build scripts”) en amont dès lors que autoconf ne connaît pas la séparation entre / et /usr.
  • Harald a fait des tests et a constaté que c’était parfaitement viable.
  • Quelqu’un est d’accord de se charger de cette tâche.

Il détaille plus ces points et en conclu qu’il y est donc très favorable, surtout en raison du fait que cela rendra beaucoup de choses plus faciles. Il souligne notamment le fait que cela rendra la tâche plus facile pour les développeurs mais également pour les packageurs et les administrateurs système qui pourront bénéficier d’une atomisation des snapshots de btrfs.

Je vous ai également brièvement évoqué mon point de vue mais ce qui m’intéresserais grandement, c’est d’avoir votre avis sur le sujet. Alors, qu’en pensez-vous?