L’histoire de Systemd et de Debian est une saga qui agite le monde de l’open-source depuis quelques années, et qui durera encore probablement quelque temps, même si les choses commencent à se calmer.
S’y intéresser permet de comprendre beaucoup de choses sur l’architecture logicielle, le fonctionnement des communautés et la manière dont les technologies sont adoptées.
Debian
Debian est une système d’exploitation libre qui se veut “universel”, c’est-à-dire qu’il s’agit d’un assemblage de logiciels qui se veut adapté à tous les usages.
Il suit un fonctionnement communautaire où les décisions sont prises démocratiquement et où le travail est quasi-exclusivement effectué par des personnes volontaires.
Cela signifie que les personnes travaillent sur les tâches de leur choix, et qu’il n’y a jamais assez de monde pour faire tout le travail nécessaire.
OS universel
Au croisement de sa mission de “système d’exploitation universel” et de son fonctionnement communautaire, Debian se veut très accueillant vis-à-vis des logiciels (tant qu’ils sont libres).
Cela signifie essayer de limiter les contraintes techniques qui pourraient bloquer le fait d’inclure de nouveaux programmes, et permettre d’avoir plusieurs manières de faire la même chose, tant que cela ne met pas en cause le fonctionnement du système (à la fois le système technique et l’organisation).
Packaging
La majorité du travail à fournir pour faire vivre Debian est un travail de packaging, c’est-à-dire d’inclure des logiciels dans l’écosystème Debian pour qu’ils puissent être installés et fonctionner ensemble.
Cela peut signifier de simplement copier une application sur un serveur pour la rendre disponible, mais peut aussi nécessiter d’avoir à modifier le logiciel pour le rendre compatible, qu’il s’agisse de son code source ou de fichiers de configuration.
Assembler et pas créer
Par rapport à d’autres distributions comme Linux Mint, l’objectif de Debian est de développer le moins possible de logiciels spécifiques pour elle seule mais de se concentrer sur le packaging de choses existantes.
Cela signifie que les personnes utilisant Debian et qui voudraient créer de nouveaux composants sont encouragées à participer à des projets existants, ou à créer de nouveaux projets mais qui ne soient pas spécifiques à Debian.
Systemd
Gérer des programmes
Les systèmes d’exploitations comme les distributions ont besoin de gérer les programmes. Par exemple quand vous démarrez votre ordinateur, il va lancer des programmes permettant de se connecter à internet, peut-être d’imprimer des documents, de lancer des mises à jour. Ensuite vous allez peut-être lancer un navigateur internet, ou un traitement de texte.
Tout cela peut sembler simple mais, en fonction des perfectionnements dont on a besoin cela peut devenir très complexe.
Un programme peut avoir besoin d’en démarrer un autre pour pouvoir s’exécuter, il peut écrire des fichiers de logs qu’il faut purger, il peut vouloir utiliser une gestion de droits d’accès pour limiter les dégâts possibles en cas de problèmes…
System V init
Historiquement les systèmes Unix et Linux utilisent pour cela un système appelé “System V init” parce qu’il tire son origine de la version 5 d’Unix datant de 1983.
La version utilisée par la majorité des systèmes Linux est une réimplémentation de l’original (pour des raisons de licence) mais qui lui reste largement compatible.
(Certaines distributions Linux utilisent des systèmes différents, par exemple Gentoo utilise OpenRC.)
Avec ce système la gestion des programmes se fait avec des scripts “standards” utilisant les fonctionnalités proposées par la distribution utilisée, c’est-à-dire l’ensemble des programmes disponibles.
Il est donc possible de tout faire, mais il faut tout faire à la main.
Cela va donc signifier que les comportements avancés peuvent devenir très complexes à mettre en œuvre, et que chaque logiciel a besoin de recoder les mêmes comportements (ou de les copier sur son voisin ou sa voisine).
Voici par exemple le script apachectl de gestion du serveur HTTP Apache, accrochez-vous.
ERROR=0
ARGV="$@"
if [ "x$ARGV" = "x" ] ; then
ARGS="help"
fi
for ARG in $@ $ARGS
do
# check for pidfile
if [ -f $PIDFILE ] ; then
PID=`cat $PIDFILE`
if [ "x$PID" != "x" ] && kill -0 $PID 2>/dev/null ; then
STATUS="httpd (pid $PID) running"
RUNNING=1
else
STATUS="httpd (pid $PID?) not running"
RUNNING=0
fi
else
STATUS="httpd (no pid file) not running"
RUNNING=0
fi
case $ARG in
start)
if [ $RUNNING -eq 1 ]; then
echo "$0 $ARG: httpd (pid $PID) already running"
continue
fi
if $HTTPD ; then
echo "$0 $ARG: httpd started"
else
echo "$0 $ARG: httpd could not be started"
ERROR=3
fi
;;
stop)
if [ $RUNNING -eq 0 ]; then
echo "$0 $ARG: $STATUS"
continue
fi
if kill $PID ; then
echo "$0 $ARG: httpd stopped"
else
echo "$0 $ARG: httpd could not be stopped"
ERROR=4
fi
;;
restart)
if [ $RUNNING -eq 0 ]; then
echo "$0 $ARG: httpd not running, trying to start"
if $HTTPD ; then
echo "$0 $ARG: httpd started"
else
echo "$0 $ARG: httpd could not be started"
ERROR=5
fi
else
if $HTTPD -t >/dev/null 2>&1; then
if kill -HUP $PID ; then
echo "$0 $ARG: httpd restarted"
else
echo "$0 $ARG: httpd could not be restarted"
ERROR=6
fi
else
echo "$0 $ARG: configuration broken, ignoring restart"
echo "$0 $ARG: (run 'apachectl configtest' for details)"
ERROR=6
fi
fi
;;
graceful)
if [ $RUNNING -eq 0 ]; then
echo "$0 $ARG: httpd not running, trying to start"
if $HTTPD ; then
echo "$0 $ARG: httpd started"
else
echo "$0 $ARG: httpd could not be started"
ERROR=5
fi
else
if $HTTPD -t >/dev/null 2>&1; then
if kill -WINCH $PID ; then
echo "$0 $ARG: httpd gracefully restarted"
else
echo "$0 $ARG: httpd could not be restarted"
ERROR=7
fi
else
echo "$0 $ARG: configuration broken, ignoring restart"
echo "$0 $ARG: (run 'apachectl configtest' for details)"
ERROR=7
fi
fi
;;
status)
$LYNX $STATUSURL | awk ' /process$/ { print; exit } { print } '
;;
fullstatus)
$LYNX $STATUSURL
;;
configtest)
if $HTTPD -t; then
:
else
ERROR=8
fi
;;
*)
echo "usage: $0 (start|stop|restart|fullstatus|status|graceful|configtest|help)"
cat <<EOF
start - start httpd
stop - stop httpd
restart - restart httpd if running by sending a SIGHUP or start if
not running
fullstatus - dump a full status screen; requires lynx and mod_status enabled
status - dump a short status screen; requires lynx and mod_status enabled
graceful - do a graceful restart by sending a SIGWINCH or start if not running
configtest - do a configuration syntax test
help - this screen
EOF
ERROR=2
;;
esac
done
exit $ERRORDu fait de la standardisation de System V init, ces scripts peuvent être compatibles avec un nombre très important de systèmes ayant chacun leur implémentation : UNIX, Linux, et d’autres.
Cela signifie qu’un logiciel utilisant ce système peut fonctionner théoriquement tel quel sous Debian même s’il n’a pas été pensé pour fonctionner sous Debian et donc que le travail de packaging demandera très peu d’effort.
Ce système représente grosso-modo l’état de l’art de 1983, et est une sorte de plus petit multiple de ce qu’il est possible de faire aujourd’hui. Du fait des limites de ce système, certaines distributions modifient ces scripts pour utiliser des fonctionnalités plus avancées, par exemple pour améliorer la fiabilité du système ou améliorer la compatibilité entre les différents composants.
Bien entendu, un niveau de customisation plus élevé signifie plus de bénéfices, mais aussi plus d’efforts de packaging à fournir de la part des personnes qui participent à la distribution.
Systemd
Systemd est un remplacement de System V init qui propose une approche très différente : celle de fournir l’ensemble des fonctionnalités nécessaires à l’exécution des logiciels sous une forme intégrée et configurable.
Cela signifie non seulement la gestion du lancement et de l’arrêt comme System V init mais aussi la gestion des logs, la restriction des accès…
Il s’agit d’une redéfinition du rôle du système d’initialisation.
L’idée sous-jacente est qu’une approche intégrée, c’est-à-dire un ensemble de logiciels développés ensemble vaut mieux qu’une composition de briques plus indépendantes, car cela simplifie le développement, et donc l’ajout de nouvelles fonctionnalités, et permet d’avoir une configuration unique plutôt que des morceaux à droite et à gauche et donc plus lisible, et d’éviter les bugs causés par des incohérences entre composants.
Le fait d’utiliser des fichiers de configuration permet de factoriser les comportements par défaut correspondant aux bonnes pratiques, et donc à ne devoir préciser que ce qui est spécifique à chaque programme.
Un exemple de fichier de configuration Systemd du serveur HTTP Apache.
[Unit]
Description=Apache 2 HTTP Web Server
After=network.target
[Service]
Type=forking
EnvironmentFile=/etc/conf.d/apache2
ExecStart=/usr/sbin/apache2 -k start $APACHE2_OPTS
ExecStop=/usr/sbin/apache2 -k graceful-stop $APACHE2_OPTS
ExecReload=/usr/sbin/apache2 -k graceful $APACHE2_OPTS
PIDFile=/var/run/apache2.pid
StandardOutput=syslog
StandardError=syslog
Restart=always
ProtectHome=yes
ProtectSystem=full
[Install]
WantedBy=multi-user.target
WantedBy=http-daemon.targetLes avantages de Systemd
Systemd a donc deux avantages, suivant le rôle qu’on occupe :
-
pour les personnes qui développent des logiciels et qui veulent fournir des scripts permettant de les exécuter, Systemd permet de faire plus facilement certaines choses basiques, et de rendre abordables les choses complexes ;
-
pour les personnes qui contribuent à des distributions Linux, Systemd propose un standard “sur étagère”, qui permet de baisser fortement les chances qu’il y ait besoin d’adapter un logiciel à leur distribution, réduisant la quantité de travail à fournir.
Les critiques
Là où les choses se corsent, c’est que Systemd ne fait pas l’unanimité mais au contraire fait l’objet de nombreuses critiques.
C’est différent
La première est de changer les choses alors qu’on avait une solution qui fonctionnait acceptablement bien et qui était connue.
Il ne s’agit pas (seulement) de râler par principe parce que les choses changent : modifier la manière dont les programmes sont gérés demande du temps (pour apprendre à utiliser le nouveau système, et pour migrer les scripts existants), et est facteur de risque (même si la nouvelle approche devrait aboutir à des résultats plus fiables).
Pour les personnes pour qui l’approche historique donnait satisfaction ce changement n’est donc pas le bienvenu.
Il faut noter que la complexité des scripts System V init demandait un certain niveau d’expertise et donc un certain temps d’apprentissage et cette compétence était reconnue. Remplacer ces scripts par des fichiers de configuration souvent beaucoup plus simples fait perdre de la valeur à cette compétence, et donc diminue le statut des personnes qui la maîtrisent.
La philosophie d’Unix
La seconde critique est que son approche ne correspond pas à la philosophie d’Unix, qui préconise d’avoir plutôt des “programmes qui effectuent une seule chose et qui le font bien`”.
Au-delà de l’aspect philosophique, cette approche permet en théorie de pouvoir facilement remplacer un composant par un autre tant que les deux sont compatibles, ou de tenter une nouvelle approche car le coût du changement sera faible, et donc de pouvoir permettre une forme de concurrence ou de sélection naturelle. Des composants plus petits devraient plus facilement être remplacés, et donc avoir un écosystème qui évolue plus rapidement, il s’agit d’un modèle favorisant le couplage faible.
L’avis des personnes qui ont créé Systemd est que — si la philosophie d’Unix peut être pertinente pour la conception de certains types d’applications — elle ne l’est pas pour tous les types de programmes, et notamment pour les systèmes en charge de gérer d’autres programmes.
Les applications qui se prêtent bien à une approche à la Unix, sont celles pour lesquelles les frontières sont limitées, bien délimitées, et assez fixes. L’exemple type est celui de nombreux outils en ligne de commande qui communiquent par des flux de textes séparés par des sauts de lignes et qu’on peut chaîner les uns avec les autres pour mettre en place des flux de traitements.
Ce modèle trouve ses limites lorsque les échanges entre les composants deviennent plus complexes ou que l’exigence en termes de service rendu augmente, car cela signifie devoir dépenser plus d’effort pour faire fonctionner les différentes briques comme un tout cohérent.
Dans ce cas un système intégré permet de faciliter la cohérence du tout. Il permet aussi de simplifier les évolutions lorsqu’elles touchent plusieurs éléments à la fois car le système est développé en un bloc, plutôt que d’avoir à synchroniser plusieurs projets.
Linux et rien d’autre
Ensuite, pour limiter la taille et la complexité du projet, Systemd fonctionne uniquement avec le noyau Linux.
Ce choix permet deux choses :
-
pouvoir utiliser toutes les fonctionnalités fournies par ce système alors que d’autres ne sont pas forcément aussi riches (ce qui évite soit de ne pas pouvoir faire certaines choses, soit de devoir les réimplémenter) ;
-
avoir à gérer la compatibilité avec plusieurs soubassements différents.
Cela signifie que si une application veut fournir des outils permettant de la piloter et qu’elle vise d’autres systèmes que Linux, elle peut avoir à les fournir en version Systemd et en version System V init.
De même pour les OS comme Debian qui veulent être compatibles avec plusieurs noyaux.
Trois choix sont possibles :
-
Se passer de Systemd et de ses fonctionnalités avancées pour les systèmes Linux
-
Se passer des systèmes hors Linux
-
Augmenter la quantité de travail de maintenance
Suivant les cas le meilleur choix n’est pas toujours le même, par exemple pour certains programmes Systemd peut avoir une valeur ajoutée plus faible, d’autres peuvent de toutes façons ne pas être compatibles avec autre chose que Linux.
Il y a eu et il y a encore des discussions sur le fait de rendre les autres systèmes, par exemples les BSD compatibles avec Systemd. L’ampleur du travail à fournir, et le fait que le projet Systemd continue à évoluer, et donc présente une cible mouvante a, pour le moment en tout cas, découragé les initiatives.
Les choix faits
La quatrième critique porte sur les choix faits par Systemd.
Pour rendre les fichiers de configuration le plus simple possible, Systemd a fait des choix sur la manière dont les composants devraient se comporter par défaut. Du coup, même s’il est possible de faire différemment, le chemin de moindre résistance proposé par la configuration par défaut fait que les systèmes ont tendance à l’utiliser.
Cette uniformisation de configuration peut être vue comme un avantage car elle signifie une uniformisation des comportements, et donc des systèmes plus simples à comprendre.
Mais pour les personnes qui avaient l’habitude d’autres choix, cela peut être un inconvénient, surtout si par rapport aux scripts initiaux, Systemd rend plus difficile de customiser les choses à leur manière.
Lennart Poettering
La figure de proue de Systemd laisse peu de monde indifférent dans le monde Linux.
Je pense qu’il possède quatre caractéristiques qui ensemble sont assez explosives :
-
Il a beaucoup d’opinions sur un tas de sujets et il aime s’exprimer, il a par exemple la conviction que la philosophie Unix n’est pas adaptée à tous les outils.
-
Il a un bon niveau technique.
-
Il sait identifier dans un projet ce qui est nécessaire et ce qu’il ne l’est pas et se tenir à ses choix pour ne pas se disperser.
-
Il a de l’énergie à revendre quand il s’agit de convaincre les bonnes personnes d’utiliser ses projets, c’est-à-dire les personnes qui peuvent faire en sorte que ses projets réussissent.
Il s’agit d’une approche qui a fait ses preuves, mais qui fâche des gens car elle n’est pas consensuelle : il ne vise pas à satisfaire tout le monde ou tous les besoins.
PulseAudio, son principal projet avant Systemd était dans ce modèle, et il est devenu un quasi-standard sur Linux.
Du coup dès que les personnes ont commencé à entendre parler de Systemd, sa personne a cristallisé des mécontentements même s’il n’était pas la seule personne à travailler sur le projet.
Dans les fils d’échanges sur Systemd, au milieu des arguments décris plus haut, on trouve souvent une ou deux phrases du genre “Lennart Poettering est l’antéchrist incarné et cela devrait suffire à disqualifier Systemd”.
Mon humble avis c’est que, dès qu’elles l’ont vu arriver en connaissant sa réputation et ses capacités, et ayant compris qu’effectivement sur ce type d’outil il y avait une place à prendre, une partie des personnes a dû réaliser que la partie était probablement perdue d’avance et que son projet allait faire place nette. Je pense que cela a pu créer de la rage chez certain·e·s.
Les alternatives
Même avant Systemd d’autres systèmes alternatifs avaient été développés pour répondre à certaines critiques de System V init, par exemple OpenRC.
Malheureusement ces alternatives avaient deux inconvénients :
-
Elles ne supportaient pas les choses les plus avancées qui sont dans Systemd, du coup l’incitation à migrer n’étaient pas aussi forte.
-
Les personnes qui les développaient ou qui les promouvaient n’avaient pas l’énergie (et/ou la mégalomanie) de l’équipe de Systemd, ce qui fait que même si certaines distributions Linux avaient adoptées l’une ou l’autre de ces alternatives, aucune équipe ne s’était lancé sérieusement dans le chantier de devenir LA solution Linux.
Quand Systemd est arrivé, il y a eu des discussions pour savoir s’il ne valait pas mieux utiliser plutôt tel ou tel autre outil, potentiellement déjà plus mature et plus utilisé. Malheureusement par manque d’énergie, et dispersion des forces entre les alternatives, ces approches n’ont pas abouti.
Même si la généralisation de Systemd n’a pas signé la fin de ces autres projets, il y a de grandes chances qu’une partie d’entre eux s’arrêtent à moyen terme, Systemd ayant répondu à une partie des douleurs qui justifient leur existence. Il en restera forcément quelques-unes, pour des besoins spécifiques, ou simplement par esprit de contradiction pour pouvoir utiliser autre chose que Systemd.
Comment ça s’est passé chez Debian
Systemd est un exemple parfait du type de question que les organisations comme Debian ont du mal à traiter : un sous-groupe basé sur le consensus qui doit faire face à une décision clivante prise par le groupe plus large dont il fait partie (celui de la communauté Linux).
En effet en 2013, plusieurs distributions Linux d’importance avaient choisi Systemd. Pour Debian était venu le moment de faire un choix pour sa prochaine version : fallait-il passer sur Systemd, rester sur System V init, permettre une coexistence entre les deux, voir choisir un système tiers ?
Le débat a été houleux, avec son lot d’insultes et de personnes qui claquent la porte. Cela a été le cas avec d’autres distributions, mais l’organisation de Debian a rendu le sujet encore plus compliqué qu’ailleurs.
En effet le fonctionnement démocratique permet que toute la communauté s’exprime, alors que les conséquences du choix ne sont pas les mêmes pour tout le monde.
Ainsi, rester sur System V init aurait permis à Debian de conserver un très grande compatibilité, par exemple avec des noyaux non Linux, ce qui plaisait aux personnes qui participent à Debian pour expérimenter avec ce type de constructions exotiques. Mais par ailleurs, rester sur System V init aurait pu augmenter la quantité des travail des bénévoles qui s’occupent du packaging de programmes et qui permettent que Debian soient utilisée et utile.
Cette opposition entre les demandes d’une partie d’une communauté et les volontaires qui produisent le logiciel utilisé par cette communauté est une situation classique dans l’open-source, même si souvent on préfère ne pas en parler de cette manière, mais la taille de Debian lui a donné une ampleur inédite.
Au final, c’est Systemd qui a été choisi comme système officiel, mais tout en permettant aux autres systèmes, dont System V init, d’être toujours utilisé. Cela a permis de ne pas couper les ponts avec les personnes qui voulaient utiliser des systèmes alternatifs et qui n’étaient pas frontalement opposées à Systemd
Certaines des personnes pour qui Systemd est une question de principe ont monté un projet concurrent appelé Devuan.
La décision de coexistence est parfaitement en ligne avec la vision du monde Debian, mais elle a l’inconvénient d’être sujette à interprétation. En effet certaines personnes expliquent que, pour qu’il soit réellement possible d’avoir des systèmes alternatifs, il faut interdire d’utiliser les fonctions de Systemd qui ne sont pas disponibles dans les autres systèmes, alors que ce sont ces mêmes fonctions qui lui donnent sa valeur.
Pendant quelques années, la communauté a choisi de ne pas officiellement ouvrir cette question, alors qu’elle se remettait du débat précédent.
Mais, comme de plus en plus d’applications fournissent des configurations Systemd prêtes à l’emploi, et qui de fait cassent la compatibilité avec les autres systèmes, l’ambiguïté devient intenable.
Près de six ans plus tard, un nouveau vote est en préparation pour clarifier la situation, on n’en est donc pas encore sorti.
Conclusion
Depuis bientôt dix ans Systemd sème la discorde dans le monde Linux.
Il a donné lieu à des discussions techniques passionnantes et a aussi permis de mettre en lumière beaucoup de non-dits sur le fonctionnement de cette communauté : quels sont les arguments valides, comment les décisions sont prises, et comment se faire entendre quand on est minoritaire dans une organisation mais que tout repose sur vous.
Même si l’écosystème Linux et l’open-source en général a ses particularités, je pense que les leçons à en tirer peuvent s’appliquer dans bien d’autres contextes IT, y compris celui des entreprises.
Si ce genre de discussions vous intéresse, LWN.net est selon moi le site de référence auquel il faut s’abonner.