Avec les systemes d'init classique, c'était tout simple :
Hé hé !
tu places tes scripts dans /etc/rcx.d et tu t'arranges pour qu'ils traitent les paramètres start, stop, reload, etc ...
Bien sûr... Tu as regardé comment le skeleton de Debian par exemple ? Tu espère que le script prennent correctement en compte les paramètres, mais en faite euh... Ben pas forcément... Tu as vu combien de scripts qui ne sont trop dépendant de l'environnement ? (lancé par le mauvais utilisateur, variable d'environnement en trop,...)
Je pense bien connaître le scripting shell et il est vraiment rare que je ne vois un script sans me dire "là on peut le faire péter". Pour faire un bon script shell il faut être très défensif. Donc le shell c'est bien, mais c'est bien de limiter fortement le contexte dans le quel on l'utilise.
Bref je connais suffisamment le shell pour vouloir simplifier au maximum ce qu'on en fait et toujours me méfier des scripts shell.
Et si tu veux savoir comment ça marche, tu lis le code.
C'est insupportable à lire, les distributions font différemment (ma distribution utilise un binaire compilé qui s'appelle "start-stop-daemon".
Et sur ur xBSD c'est encore plus simple.
Non c'est encore différent pas simple. Simple quand tout se passe bien. Valider que tout est fiable est encore une complexité en plus.
Avec systemd, si tu as un problème de démarrage, t'es obligé d'attendre que ta distrib (ou l'upstream) corrige avant de pouvoir démarrer. Avec les scripts init classiques, tu peux corriger de suite et démarrer ton serveur en attendant que les correctifs te soient fournis.
Tu es entrain de nous présenter le scénario de la bombe à retardement version système d'init. Les faits montrent que ça ne semble pas si invivable (Note : quand tu fais quelque chose qui pète ton init quelque soit ton système d'init tu pourra le corriger => je n'ai pas de doute que tu sache faire l'action inverse de ce que tu as fais).
[^] # Re: Les données du /home sont souvent les moins protégées
Posté par barmic . En réponse au journal [MaVie] La grosse gaffe du jour ..... Évalué à 3.
Hé hé !
Bien sûr... Tu as regardé comment le skeleton de Debian par exemple ? Tu espère que le script prennent correctement en compte les paramètres, mais en faite euh... Ben pas forcément... Tu as vu combien de scripts qui ne sont trop dépendant de l'environnement ? (lancé par le mauvais utilisateur, variable d'environnement en trop,...)
Je pense bien connaître le scripting shell et il est vraiment rare que je ne vois un script sans me dire "là on peut le faire péter". Pour faire un bon script shell il faut être très défensif. Donc le shell c'est bien, mais c'est bien de limiter fortement le contexte dans le quel on l'utilise.
Bref je connais suffisamment le shell pour vouloir simplifier au maximum ce qu'on en fait et toujours me méfier des scripts shell.
C'est insupportable à lire, les distributions font différemment (ma distribution utilise un binaire compilé qui s'appelle "start-stop-daemon".
Non c'est encore différent pas simple. Simple quand tout se passe bien. Valider que tout est fiable est encore une complexité en plus.
Tu es entrain de nous présenter le scénario de la bombe à retardement version système d'init. Les faits montrent que ça ne semble pas si invivable (Note : quand tu fais quelque chose qui pète ton init quelque soit ton système d'init tu pourra le corriger => je n'ai pas de doute que tu sache faire l'action inverse de ce que tu as fais).