Chaque script d'init s'occupe d'une seule chose et s'exécute
dans un ordre bien précis.
Ce qui est bien, c'est que comme tu restes dans le vague, on peut pas te contredire. Donc je vais arbitrairement prendre Debian comme exemple en partant du principe qu'il y a que Debian ou Ubuntu avec /etc/default, et parce tout mes autres serveurs sont en systemd ( en fait, la Debian aussi, mais y a pas d'unité sauf les miennes ). et te montrer que non, si ta distrib est Debian, alors les scripts font plus que "juste une chose" et qu'en fait, ils font des tas de trucs pour "juste une chose" qui est "lancer un programme".
On va prendre par exemple bind9. Dans le script de bind9, le script fait :
- l'ajout de localhost dans /etc/resolv.conf de façon conditionnel
- le chargement d'un module ( capabilities )
- la creation de /var/run/named
- vérifie que le réseau est configuré avant de lancer bind
Une chose et une seule ? Le chargement du module, c'est le script kmod qui doit le faire, pas lui. La creation d'un repertoire, c'est l'ordre du paquet. Et la vérification du réseau, c'est pas pour ça qu'on a les dependances LSB et que "tout se lance dans l'ordre" ?
On peut voir dbus. Il fait :
- création du repertoire pour le pid
- vérification si /proc est monté
- génere un fichier /etc/machine-id si absent
On retrouve le même pattern, vérification que tout est en place ( le reseau, /proc ) pour palier à des dépendances qu'on peut pas exprimer avec la LSB ( genre le fait d'avoir /proc ). Et la création des fichiers, chose qui devrait être fait par le paquet ou en postinst.
Ok, un autre script au hasard, celui de saslauthd. 400 lignes.
Une grande partie de la complexité vient du fait que ce script gère le fait de lancer plusieurs instances du serveur ( stop_instance, start_instance ), qu'il duplique la logique de création de répertoire avec les autres scripts, fonction createdir ( en prenant en compte selinux, contrairement aux 2 autres, ce qui fait qu'il y a soit du code en trop dans le dernier, soit des bugs dans mes 2 autres exemples ).
Il refait aussi son propre oneliner pour parser la ligne de commande de saslauthd, qui est fourni par la configuration en bash:
Code copier coller entre le start et le stop, au passage.
Donc ça fait un chouia plus que "juste lancer le daemon". Comme les scripts d'init ont leur propre logique et configuration ( cad les fichiers /etc/default de Debian ), chacun requiert sa propre logique dans le script, sa propre doc et donc entraine l'apparition de ses propres idiosyncrasies, avec ce que ça entraine en terme de formation.
Un autre exemple pour la route ?
Le script de postfix fait une vérification de la config de postfix pour voir si tu n'a pas mis "ubuntu.com ou debian.org" ( le commentaire dit "c'est pas bon, et ça fait chier les admins des domaines" ).
Il gère aussi la création du chroot pour postfix. La création du chroot implique d'analyser le fichier de config pour savoir ce qu'il faut copier, mais il y a postconf pour ça. Il y a aussi besoin de savoir si il faut un chroot ou pas, via ce morceau si claire d'awk ( car bon, faire ça en bash tu peux pas, faut faire appel à un outil externe ) :
Sinon, si tu as une Debian, tes scripts font plus qu'une chose. En fait, ils font le café. Ils gèrent chacun à leur façon la gestion de plusieurs instances en même temps, ils préparent le FS plus ou moins bien, chargent les modules, lisent la config des serveurs, avec leur propre config. C'est des programmes à part avec beaucoup de redondances.
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Misc (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 10.
Ce qui est bien, c'est que comme tu restes dans le vague, on peut pas te contredire. Donc je vais arbitrairement prendre Debian comme exemple en partant du principe qu'il y a que Debian ou Ubuntu avec /etc/default, et parce tout mes autres serveurs sont en systemd ( en fait, la Debian aussi, mais y a pas d'unité sauf les miennes ). et te montrer que non, si ta distrib est Debian, alors les scripts font plus que "juste une chose" et qu'en fait, ils font des tas de trucs pour "juste une chose" qui est "lancer un programme".
On va prendre par exemple bind9. Dans le script de bind9, le script fait :
- l'ajout de localhost dans /etc/resolv.conf de façon conditionnel
- le chargement d'un module ( capabilities )
- la creation de /var/run/named
- vérifie que le réseau est configuré avant de lancer bind
Une chose et une seule ? Le chargement du module, c'est le script kmod qui doit le faire, pas lui. La creation d'un repertoire, c'est l'ordre du paquet. Et la vérification du réseau, c'est pas pour ça qu'on a les dependances LSB et que "tout se lance dans l'ordre" ?
On peut voir dbus. Il fait :
- création du repertoire pour le pid
- vérification si /proc est monté
- génere un fichier /etc/machine-id si absent
On retrouve le même pattern, vérification que tout est en place ( le reseau, /proc ) pour palier à des dépendances qu'on peut pas exprimer avec la LSB ( genre le fait d'avoir /proc ). Et la création des fichiers, chose qui devrait être fait par le paquet ou en postinst.
Ok, un autre script au hasard, celui de saslauthd. 400 lignes.
Une grande partie de la complexité vient du fait que ce script gère le fait de lancer plusieurs instances du serveur ( stop_instance, start_instance ), qu'il duplique la logique de création de répertoire avec les autres scripts, fonction createdir ( en prenant en compte selinux, contrairement aux 2 autres, ce qui fait qu'il y a soit du code en trop dans le dernier, soit des bugs dans mes 2 autres exemples ).
Il refait aussi son propre oneliner pour parser la ligne de commande de saslauthd, qui est fourni par la configuration en bash:
Code copier coller entre le start et le stop, au passage.
Donc ça fait un chouia plus que "juste lancer le daemon". Comme les scripts d'init ont leur propre logique et configuration ( cad les fichiers /etc/default de Debian ), chacun requiert sa propre logique dans le script, sa propre doc et donc entraine l'apparition de ses propres idiosyncrasies, avec ce que ça entraine en terme de formation.
Un autre exemple pour la route ?
Le script de postfix fait une vérification de la config de postfix pour voir si tu n'a pas mis "ubuntu.com ou debian.org" ( le commentaire dit "c'est pas bon, et ça fait chier les admins des domaines" ).
Il gère aussi la création du chroot pour postfix. La création du chroot implique d'analyser le fichier de config pour savoir ce qu'il faut copier, mais il y a postconf pour ça. Il y a aussi besoin de savoir si il faut un chroot ou pas, via ce morceau si claire d'awk ( car bon, faire ça en bash tu peux pas, faut faire appel à un outil externe ) :
Sinon, si tu as une Debian, tes scripts font plus qu'une chose. En fait, ils font le café. Ils gèrent chacun à leur façon la gestion de plusieurs instances en même temps, ils préparent le FS plus ou moins bien, chargent les modules, lisent la config des serveurs, avec leur propre config. C'est des programmes à part avec beaucoup de redondances.