Le carnet du grincheux

Je fus l'un des premiers à installer un système Linux sur un ordinateur en France, avec une pile de disquettes, Internet n'étant pas encore ce qu'on connaît aujourd'hui. Je me souviens même du premier serveur installé dans mon laboratoire qui tournait avec un noyau 1.0.9, ce qui ne nous rajeunit pas vraiment et j'ai même participé au développement du noyau pour des architectures exotiques comme les Sparc (à l'époque en 32 bits) et les Alpha. J'ai arrêté de participer à ce développement au cours de la vie du noyau 2.4 puisqu'il était impossible de suivre les modifications internes, surtout les changements de mémoire virtuelle, et tous les bidouillages introduits pas un développement effectué principalement sur architecture x86. Néanmoins, entre les noyaux 1.0 et 2.2 inclus, l'évolution de ce système d'exploitation en faisait quelque chose de prometteur. Vingt-cinq ans plus tard, que peut-on en dire ?

Durant toute une période, j'ai migré mes serveurs d'Unix propriétaires (Ultrix, OSF/1, Solaris, HP-UX) vers Linux parce le système était efficace, carré. Aujourd'hui, je constate que j'effectue la démarche inverse. Je ne réinstalle pas des Unix propriétaires, non, mais des NetBSD (sur serveur) ou des FreeBSD (principalement sur station de travail). Je n'installe plus des système Linux que sur des machines qui utilisent des outils bien particuliers ou pour des besoins spécifiques comme des ordinateurs portables dont les paramètres réseau, par exemple, doivent pouvoir être changés facilement par l'utilisateur sans attaquer avec vi des fichiers de configuration.

Comment en suis-je arrivé là?

Il est bizarre de voir que ce que les développeurs de Linux reprochaient à Windows au tournant des années 2000 se retrouve aujourd'hui presque intégralement dans Linux. Le développement se faisant quasiment exclusivement sur architecture amd64, le code n'est pas réellement propre et des tas d'hypothèses sont faites, hypothèses qui se vérifient sur amd64 mais pas forcément sur d'autres architectures (voir pour cela les problèmes sur Sparc64). Et même sur architecture amd64, il est devenu bien difficile de faire fonctionner de manière fiable des machines dans des configurations particulière — typiquement, une machine diskless peut aujourd'hui gravement dysfonctionner, soit par plantages totaux en cas de fichier de swap sur un disque NFS (problème officiellement corrigé, mais mon noyau ne semble pas être au courant), soit par destruction du serveur X par systemd pour des raisons incompréhensibles lorsque la machine se met à swapper. Mais il y a bien pire, une partie des principes Unix comme KISS (Keep It Simple, Stupid) est de plus en plus bafouée. Un exemple parmi tant d'autres, l'inénarrable systemd.

Pour démarrer un système Unix, il existe principalement deux techniques :

• BSD : un fichier de configuration (généralement /etc/rc.conf et les fichiers inclus) indique quels sont les daemons qui doivent être démarrés avec le système. Les scripts de démarrage de ces daemons contiennent des dépendances et le daemon init (de PID 1) s'arrange alors pour les démarrer dans l'ordre nécessaire. C'est simple, efficace, sans surprise. C'est même économe en mémoire et en ressources diverses ;
• SysV : c'est encore plus trivial. Un répertoire contient une collection de scripts exécutés dans l'ordre alphabétique. C'est à l'utilisateur de régler les dépendance en réglant le nom des différents scripts. C'est encore plus économe. Sans doute trop, cela demande à l'utilisateur de réfléchir un peu.

Ces deux techniques sont trop simples et on a vu arriver un daemon à tout faire dans Linux pour, soi disant, simplifier le problème. Il s'agit de systemd. Systemd, c'est un truc qui fait tout, qui sert à tout, qui a une syntaxe délirante et des fichiers de configuration planqués un peu partout (/lib/systemd/system, /lib/systemd/user, /etc/systemd/system, /etc/systemd/user et peut-être même ailleurs). C'est une usine à gaz avec des fuites qui empêche un démarrage rapide de toute machine ayant moins de 1 Go de mémoire puisque pour des raisons de rapidité (sic), tous les services devant démarrer sont lancés en même temps jusqu'à ce que toutes les dépendances soient satisfaites. Sur les machines un peu courtes en mémoire, ça fait chauffer le dérouleur de pages, et ça peut le faire chauffer longtemps. Mais il paraît que c'est un progrès indéniable.

Vous allez me dire que les machines classiques actuelles ont plusieurs gigaoctets de mémoire, que cela n'est pas un problème. C'est pourtant un problème puisque Linux est malheureusement de plus en plus utilisé dans l'électronique embarquée où on n'a pas forcément une telle quantité de mémoire à disposition. Un autre problème de systemd est qu'il est associé à un noyau en particulier. Lorsqu'un noyau pose problème, il peut être aujourd'hui impossible de démarrer sur un noyau plus ancien qui n'aura pas la bonne version de systemd, celle-ci étant unique pour l'ensemble des noyaux. Mais le pire est tout de même les effets de bords de systemd avec les autres daemons du système comme udev. Le noyau Linux a eu la bonne idée depuis des lustres de nommer les interfaces Ethernet en eth. Premier problème, d'une version à une autre, l'énumération ne se faisait pas forcément dans le même sens. Pour madame Michu qui n'a qu'une seule interface réseau, ce n'est pas grave. Pour quelqu'un qui utilise des serveurs avec plusieurs cartes Ethernet, cela peut rapidement devenir compliqué. Plutôt que de fiabiliser l'ordre d'énumération puisqu'il n'y a aucune raison que d'un noyau à un autre, l'ordre d'énumération sur une même machine ne change, un cataplasme sur une jambe de bois a été rajouté. Deux si je veux être précis. Historiquement, udev peut renommer les interfaces en fonction de leur adresse Ethernet. Plus récemment, les noms de périphériques ont été changés et ce qui était eth0 a pu devenir au gré d'une mise à jour de noyau enp0s31f6, ce qui était très pratique pour les gens qui utilisaient un firewall bloquant tout par défaut sur une machine à distance. Mais encore, en lisant la documentation et en acceptant d'ouvrir un peu tous les ports le temps de la migration, il était possible de s'en tirer.

Or arrive sur ces entrefaites l'inénarrable systemd qui, lui aussi, veut avoir son mot à dire sur le nommage des interfaces. À titre personnel, les interfaces réseau de l'un de mes serveurs sont les suivantes :

Root rayleigh:[~] > ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1335
inet 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::c48a:96ff:fede:8a07 prefixlen 64 scopeid 0x20<link>
inet6 2001:7a8:a8ed:1::1 prefixlen 64 scopeid 0x0<global>
ether c6:8a:96:de:8a:07 txqueuelen 1000 (Ethernet)
RX packets 10316123 bytes 4301990769 (4.0 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10982367 bytes 9779960261 (9.1 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.1 netmask 255.255.255.0 broadcast 192.168.254.255
inet6 fe80::208:2ff:feaf:da70 prefixlen 64 scopeid 0x20<link>
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)
RX packets 8698421 bytes 1258112154 (1.1 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 7780169 bytes 2744108696 (2.5 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth1:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.81 netmask 255.255.255.0 broadcast 192.168.254.255
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)

eth1:2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.82 netmask 255.255.255.0 broadcast 192.168.254.255
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)

eth1:3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.83 netmask 255.255.255.0 broadcast 192.168.254.255
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)

eth1:4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.84 netmask 255.255.255.0 broadcast 192.168.254.255
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)

eth1:5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.85 netmask 255.255.255.0 broadcast 192.168.254.255
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)

eth1:6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1492
inet 192.168.254.86 netmask 255.255.255.0 broadcast 192.168.254.255
ether 00:08:02:af:da:70 txqueuelen 1000 (Ethernet)

eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.253.1 netmask 255.255.255.0 broadcast 192.168.253.255
inet6 2001:7a8:a8ed:253::1 prefixlen 64 scopeid 0x0<global>
inet6 fe80::208:2ff:feaf:da71 prefixlen 64 scopeid 0x20<link>
ether 00:08:02:af:da:71 txqueuelen 1000 (Ethernet)
RX packets 20477825 bytes 11652375271 (10.8 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 21845494 bytes 13687329761 (12.7 GiB)
TX errors 7 dropped 0 overruns 0 carrier 7 collisions 0

lan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.128 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::5246:5dff:fe72:efa2 prefixlen 64 scopeid 0x20<link>
ether 50:46:5d:72:ef:a2 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 9402 bytes 614631 (600.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 20 memory 0xf7e00000-f7e20000

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Boucle locale)
RX packets 17945139 bytes 6569208488 (6.1 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 17945139 bytes 6569208488 (6.1 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1336
inet 192.168.2.1 netmask 255.255.255.0 broadcast 192.168.2.255
inet6 fe80::6cb8:b3ff:fed0:235f prefixlen 64 scopeid 0x20<link>
ether 6e:b8:b3:d0:23:5f txqueuelen 100 (Ethernet)
RX packets 51661 bytes 18867944 (17.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 66902 bytes 4769816 (4.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tap1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1335
inet6 2001:7a8:a8ed:1::1 prefixlen 64 scopeid 0x0<global>
inet6 fe80::30f3:6dff:fe94:8c9b prefixlen 64 scopeid 0x20<link>
ether 32:f3:6d:94:8c:9b txqueuelen 100 (Ethernet)
RX packets 1545324 bytes 1307060028 (1.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1371546 bytes 810892202 (773.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tap2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1335
inet6 fe80::7807:ceff:fefe:4c12 prefixlen 64 scopeid 0x20<link>
ether 7a:07:ce:fe:4c:12 txqueuelen 100 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 35056 bytes 1824754 (1.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Il y a du monde. Vous noterez qu'il n'y a plus de eth0 mais un lan0. Pourquoi ? Parce que cette saleté de systemd a décidé depuis sa dernière mouture d'entrer en conflit avec le renommage des interfaces par udev et eth0 était renommé en je ne sais plus quoi. Heureusement que l'interface en question était une interface du LAN, ce qui ne m'empêchait pas de prendre la main à distance pour corriger le problème. Tout cela ne fait pas bien sérieux et n'est pas vraiment très sec. Cela me donne même l'impression d'essuyer du plâtre avec des briques.

Hier, j'ai installé sur un ordinateur portable tout neuf une Debian testing. Lors de l'installation, je me suis aperçu de la présence de liens étranges dans /. Typiquement, /bin était un lien vers /usr/bin, /sbin un lien vers /usr/sbin et /lib vers /usr/lib. Je me suis dit qu'il s'agissait de liens lors de l'installation. Non, ces liens restent sur le système final.

J'ai donc cherché un peu dans la documentation et je suis tombé sur des justifications totalement oiseuses :

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.

J'ai rarement lu un truc aussi bête. /bin et /sbin contiennent les binaires nécessaires du démarrage du système, /usr/bin et /usr/sbin les autres. C'est simple, carré. Par ailleurs, les scripts doivent utiliser une variable PATH, donc ce problème n'existe pas.

Mais ce n'est pas la seule justification puisque je peux lire aussi:

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.

J'utilise les autotools depuis vingt-cinq ans, je n'ai jamais constaté cela sauf si les scripts sont écrits par des pieds, mais dans ce cas, pourquoi mettre un cataplasme sur une jambe de bois ? On corrige en amont, on ne fait pas n'importe quoi en aval ! Les autotools sont justement faits pour gérer ce genre de problème. Quant à parler de la compatibilité Solaris, il y a un point que les gens oublient, c'est que Solaris est livré comme un tout et que, à l'instar des BSD, /usr concerne le seul système. La dernière fois que j'ai eu un Solaris entre les pattes (un 10, j'avoue), les programmes autres que ceux du système étaient dans /opt ou /usr/local. Chez Debian, ce n'est pas le cas, ils sont dans /usr/bin. J'attends donc avec une certaine impatience la conceté suivante, la fusion de /usr/bin avec /usr/sbin. Parce que les arguments que je lis pour la fusion de /bin avec /usr/bin et /sbin avec /usr/sbin s'appliquent de la même manière.

Un système Unix, un vrai, doit pouvoir démarrer avec une partition racine qui contient /etc, /bin, /sbin et /lib. Je sais qu'avec Linux, il est possible de bricoler avec initramfs, mais cela reste un bricolage qui ne devrait pas exister. /usr, /usr/local et /opt le cas échéant, doivent pouvoir être montés bien plus tard puisque ces partitions ne sont pas des partitions critiques. L'intérêt de la chose est de pouvoir démarrer sur une tout petite partition, même montée en utilisation normale en lecture seule. Cela permet de réparer un système endommagé, surtout lorsqu'on a les utilitaires de base compilés en statique.

Après avoir lancé cette argumentation, la réponse des développeurs de Debian fut laconique. Pour eux, dans une telle situation, il faut utiliser une image GRML appelée depuis le programme d'amorçage (grub2).

Là, j'avoue que les bras m'en tombent et je me demande pourquoi il faudrait faire simple quand on peut faire outrageusement compliqué. Comparons par exemple un NetBSD avec un système Debian/Linux. Je vais passer sous silence que le code du noyau NetBSD est un code qui est d'une qualité nettement supérieure au noyau Linux puisqu'une modification n'est poussée dans l'arborescence des sources que lorsqu'elle a été testée avec succès sur l'ensemble des architectures dites tier 1, ce qui n'est pas le cas avec Linux où elles sont poussées quand elles fonctionnent sous amd64 et advienne que pourra.

Il existe en particulier un répertoire /rescue dans NetBSD. Il contient tous les utilitaires nécessaires à la maintenance du système, compilés en statique et son contenu évolue avec le système. Ces utilitaires sont donc toujours à jour et il n'est pas nécessaire de maintenir à jour une image complète GRML.

La fusion de / avec /usr est une mauvaise idée parce que c'est une source de problèmes potentiels. Il faut que / (contenant /usr) soit en état d'être montée. Cette partition, dans un système Debian, fait plusieurs dizaines de gigaoctets puisque tous les paquets s'y trouvent. Si maintenant /usr est distincte de /, on se retrouve avec un initramfs qui doit monter / et /usr. Il faut donc que deux partitions soient en état d'être montées et que initramfs soit utilisable pour que le démarrage se passe correctement.
C'est bien pour cela que je trouve très bête (et je suis poli) le fait d'avoir ces liens de / vers /usr alors que le bon sens voudrait au contraire que l'on sépare bien ce qui est de l'ordre du mécanisme de démarrage de ce qui est de l'ordre de l'utilisation du système une fois celui-ci démarré. Certaines décisions me semblent prises sous l'effet de la mode — pour ne pas dire sous l'effet de la drogue — par des gens qui n'ont pas réfléchi plus que cela à ce qui se faisait par ailleurs. Si /bin, /sbin, /usr/bin et /usr/sbin ont été séparés depuis trente ans, il y a peut-être des raisons fondamentales, ceux qui ont fait ces choix n'étant pas plus bêtes que nous.

Dans un NetBSD, il n'y a typiquement pas besoin d'avoir une image GRML quelque part parce qu'il existe ce répertoire /rescue et que /bin, /lib et /sbin (et /etc) ne servent qu'au démarrage.

Exemple :

legendre:[~] > uname -a
NetBSD legendre.xxx.fr 9.0_STABLE NetBSD 9.0_STABLE (CUSTOM) #6:
Sat Jun  6 16:01:51 CEST 2020 root@grincheux.de-charybde-en-scylla.fr:/usr/src/netbsd-9/obj/sys/arch/amd64/compile/CUSTOM amd64
legendre:[~] > du -hs /bin
1.7M    .
legendre:[~] > du -hs /sbin
12M     /sbin
legendre:[~] > du -hs /lib
18M     /lib
legendre:[~] > du -hs /rescue
20M     /rescue
legendre:[~] > du -hs /stand/amd64/9.0
23M     /stand/amd64/9.0

Pour peu que / soit une partition séparée (en lecture seule), il est toujours redémarrer même en cas d'effacement d'une bibliothèque critique puisque /rescue est là pour cela. Ce répertoire permet de démarrer un NetBSD en single user tout en permettant de travailler sur le vrai système sans jouer du mount -o bind et autres joyeusetés qui sont assez rapidement plantogènes pour peu que le noyau de l'image ne soit pas celui en cours sur le système à dépanner. En mettant un lien de /sbin vers /usr/sbin, cette possibilité est interdite par construction puisque cela augmente les chances que cela se passe mal. En effet, lorsqu'on est contraint de travailler en single user, il y a souvent des partitions qui ne sont plus en état d'être montées, donc il y a beaucoup plus de chances que cela se passe mal.

Exemple sur un serveur Debian :

rayleigh:[~] > uname -a
Linux rayleigh 5.6.0-2-amd64 #1 SMP Debian 5.6.14-1 (2020-05-23) x86_64 GNU/Linux
rayleigh:[~] > du -hs /bin
12M     /bin
rayleigh:[~] > du -hs /lib
2,0G    /lib
rayleigh:[~] > du -hs /usr/lib
9,6G    /usr/lib
rayleigh:[~] > du -hs /usr/bin
1,1G    /usr/bin
rayleigh:[~] > du -hs /usr/sbin
64M     /usr/sbin
rayleigh:[~] > du -hs /sbin
17M     /sbin

Pour démarrer, le système doit accéder à une partition en forme (assez en forme pour être montée au moins en read only) de 13 Go, voire deux partitions en forme dans le cas où /usr est distinct et où on joue avec initramfs. Et si une bibliothèque cruciale est corrompue, on n'a que ses yeux pour pleurer, car il n'y a aucun utilitaire compilé en statique pour réparer. Quiconque a déjà essayé de recompiler un apt en statique verra de quoi je veux parler. Remarquez bien, pour démarrer correctement un Linux de nos jours, il faut aussi que l'initramfs soit correct. Encore un truc qui est une aberration sans nom puisque les scripts appelés ne sont pas forcément ceux de /etc, mais ceux qui ont été copiés dans l'initramfs. Je conçois qu'on embarque des modules dans un système de fichiers spécial pour contourner les problèmes d'initialisation liés au bios. Mais on peut faire largement mieux avec un système comme grub2 sans passer par cette horreur qu'est l'initramfs et qui est une source d'ennuis

Ce n'était pas forcément mieux avant. Mais certains choix qui ont été fait par les concepteurs des systèmes Unix l'ont été pour d'excellentes raisons. Abandonner ces concepts simples peut torpiller un système d'exploitation. Personnellement, je ne suis pas plus gêné que cela tant qu'il me restera des BSD restant dans la philosophie Unix.