Ce post de blog est extrêmement intéressant.
Hélas, il est floué peu après le début.
C’est amusant de lire qu’une « demi-vérité est pire qu’un mensonge » (sophisme, puisqu’une demi-vérité est un mensonge, mais bon), et de lire ensuite « modern BSD systems continue to manage just fine by way of incremental improvements to the pre-existing components », alors que FreeBSD (il me semble, ou est-ce OpenBSD ?) a annoncé la nécessité de développer son propre systemd car les systèmes ne sont plus gérables en l’état.
Ceci dit, l’analyse est intéressante, parce que les points indiqués sont vrais. Mais le premier point est parfaitement connu, et la volonté est bien d’utiliser un script shell pour les cas à la marge, comme les daemons qui se comportent mal. Et AMHA ce sera une réelle avancée pour tout le monde, parce que tous les daemons qui se comportent mal seront immédiatement visibles par tous les sysadmins. La volonté n’est surtout pas d’ajouter des fonctions spécifiques pour ces daemons, mais de faire en sortent que leurs développeurs les corrigent. Et on a déjà commencé à voir de nombreuses améliorations depuis la naissance de systemd, donc c’est un point extrêmement positif. J’ai vu des améliorations dans gdm, mysql/mariadb, apache, les process pour NFS entre autres.
L’assistance des utilisateurs (en général des mainteneurs de distribution ou des sysadmins) est une bonne chose selon moi. Rien n’empêche d’utiliser d’autres moyens plus sioux si on en a l’habitude ou l’envie, mais gueuler sur « systemctl edit » parce que ça assiste le sysadmin n’a aucun sens.
Mais c’est normal puisque l’auteur n’a absolument pas compris les nombreuses bonnes raisons pour l’utilisation de « systemctl edit », des raisons qui sont essentiellement liées au déploiement de distributions. Ce n’est pas non plus la panacée évidemment.
Hélas, l’auteur commence à tomber ensuite dans le déraisonnable et même carrément le mensonge, lorsque l’auteur dit qu’avec sysvinit, il était capable de dire exactement quels services allaient être démarrés. Je n’ai jamais vu le moindre sysadmin capable de prédire cela avec sysvinit, c’est même spécifiquement la raison pour laquelle tout sysadmin sain d’esprit rebootait le serveur au moins une fois lorsqu’il modifiait la séquence de démarrage, pour être sûr que ça allait bien exécuter les scripts jusqu’au bout. Et je n’ai pas dit « lancer les services » mais « exécuter les scripts ». Parce qu’avec sysvinit, ce n’est pas parce que le script d’init était lancé et renvoyait un code retour OK (voire un bel OK vert à l’écran) que le service était vraiment lancé ou n’avait pas planté après coup.
L’auteur parle de sécurité, mais ensuite ose venir se demander pourquoi systemd ne veut plus lancer de shell (/bin/sh) avant de lancer chaque daemon. Cet argument est d’une telle mauvaise foi : un daemon n’a absolument pas besoin d’un shell pour être lancé, c’est complètement contre-productif. L’auteur sera incapable de justifier pourquoi il faudrait lancer un shell, surtout qu’avec sysvinit, les daemon sont censés être lancés dans l’inittab, sans aucun shell. Donc il renverse la question pour dire que systemd est pas bien parce qu’il ne veut pas lancer de process inutiles. Et souvent ce n’est pas que /bin/sh, mais beaucoup d’autres process lancés (augmentant la surface d’attaque de tout script init), juste pour un daemon qui n’en a que faire. Le pire, c’est que sur son BSD, ça ressemble plus à systemd qu’à sysvinit.
Bref, il y a des critiques valides, mais rien qui ne soit pas déjà connu ou pris en compte par les dévs de systemd. Il est triste aussi de constater que ce qui est le plus critiqué et le plus critiquable, c’est que systemd écoute les utilisateurs et rajoute des options qu’ils demandent, lorsqu’ils estiment que c’est un cas pertinent (suffisamment répandu pour ajouter une option).
[^] # Re: systemd, le nouveau Multics
Posté par ookaze . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 2.
Ce post de blog est extrêmement intéressant.
Hélas, il est floué peu après le début.
C’est amusant de lire qu’une « demi-vérité est pire qu’un mensonge » (sophisme, puisqu’une demi-vérité est un mensonge, mais bon), et de lire ensuite « modern BSD systems continue to manage just fine by way of incremental improvements to the pre-existing components », alors que FreeBSD (il me semble, ou est-ce OpenBSD ?) a annoncé la nécessité de développer son propre systemd car les systèmes ne sont plus gérables en l’état.
Ceci dit, l’analyse est intéressante, parce que les points indiqués sont vrais. Mais le premier point est parfaitement connu, et la volonté est bien d’utiliser un script shell pour les cas à la marge, comme les daemons qui se comportent mal. Et AMHA ce sera une réelle avancée pour tout le monde, parce que tous les daemons qui se comportent mal seront immédiatement visibles par tous les sysadmins. La volonté n’est surtout pas d’ajouter des fonctions spécifiques pour ces daemons, mais de faire en sortent que leurs développeurs les corrigent. Et on a déjà commencé à voir de nombreuses améliorations depuis la naissance de systemd, donc c’est un point extrêmement positif. J’ai vu des améliorations dans gdm, mysql/mariadb, apache, les process pour NFS entre autres.
L’assistance des utilisateurs (en général des mainteneurs de distribution ou des sysadmins) est une bonne chose selon moi. Rien n’empêche d’utiliser d’autres moyens plus sioux si on en a l’habitude ou l’envie, mais gueuler sur « systemctl edit » parce que ça assiste le sysadmin n’a aucun sens.
Mais c’est normal puisque l’auteur n’a absolument pas compris les nombreuses bonnes raisons pour l’utilisation de « systemctl edit », des raisons qui sont essentiellement liées au déploiement de distributions. Ce n’est pas non plus la panacée évidemment.
Hélas, l’auteur commence à tomber ensuite dans le déraisonnable et même carrément le mensonge, lorsque l’auteur dit qu’avec sysvinit, il était capable de dire exactement quels services allaient être démarrés. Je n’ai jamais vu le moindre sysadmin capable de prédire cela avec sysvinit, c’est même spécifiquement la raison pour laquelle tout sysadmin sain d’esprit rebootait le serveur au moins une fois lorsqu’il modifiait la séquence de démarrage, pour être sûr que ça allait bien exécuter les scripts jusqu’au bout. Et je n’ai pas dit « lancer les services » mais « exécuter les scripts ». Parce qu’avec sysvinit, ce n’est pas parce que le script d’init était lancé et renvoyait un code retour OK (voire un bel OK vert à l’écran) que le service était vraiment lancé ou n’avait pas planté après coup.
L’auteur parle de sécurité, mais ensuite ose venir se demander pourquoi systemd ne veut plus lancer de shell (/bin/sh) avant de lancer chaque daemon. Cet argument est d’une telle mauvaise foi : un daemon n’a absolument pas besoin d’un shell pour être lancé, c’est complètement contre-productif. L’auteur sera incapable de justifier pourquoi il faudrait lancer un shell, surtout qu’avec sysvinit, les daemon sont censés être lancés dans l’inittab, sans aucun shell. Donc il renverse la question pour dire que systemd est pas bien parce qu’il ne veut pas lancer de process inutiles. Et souvent ce n’est pas que /bin/sh, mais beaucoup d’autres process lancés (augmentant la surface d’attaque de tout script init), juste pour un daemon qui n’en a que faire. Le pire, c’est que sur son BSD, ça ressemble plus à systemd qu’à sysvinit.
Bref, il y a des critiques valides, mais rien qui ne soit pas déjà connu ou pris en compte par les dévs de systemd. Il est triste aussi de constater que ce qui est le plus critiqué et le plus critiquable, c’est que systemd écoute les utilisateurs et rajoute des options qu’ils demandent, lorsqu’ils estiment que c’est un cas pertinent (suffisamment répandu pour ajouter une option).