Le code que tu est censé mettre dans ce fichier, ce n'est pas le code du programme. Si tu veux avoir un script qui garde la compatibilité des paramètres et que tu veux pouvoir mettre à jour séparément, tu le met dans un fichier séparé dans /bin ou /usr/bin, et tu planque l'exécutable réel.
Le code que tu met dans le script upstart sert uniquement à permettre à l'administrateur de modifier comment le programme est lancé, par exemple, en lui spécifiant une configuration générée dynamiquement. Là le script est un peu un mauvais exemple: le système d'init pourrai regarder si l'exécutable existe, /etc/default/ssh est clairement une fainéantise de conversion, et le répertoire de séparation des privileges est spécifié à la compilation, donc aucun intérêt à vouloir modifier ça. Le seul cas véridique, c'est la bidouille du PermitRootLogin. Et étant donné l'importance de l'option, c'est une bonne idée de la laisser là. Tu peux toujours le mettre ailleurs, si tu pense que tu va vouloir mettre ça à jour sans rien casser, et que tu à envie de penser au cas ou l'administrateur ne veut pas de ça.
Le script de démarrage sert à être modifié par l'administrateur, tout comme les paramètres. S'il y a des choses que la distribution veut mettre à jour et qui ne pètent rien, alors ça n'a rien à faire là. Si les modifications de la distribution peut péter des configurations, alors c'est que c'était de la configuration, et il faut l'intervention de l'admin.
Et si upstart n'intégrai pas la possibilité pour l'admin de scripter, ça serait une grande régression par rapport aux scripts d'init BSD.
[^] # Re: Et pour en remettre une couche
Posté par Batchyx . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Le code que tu est censé mettre dans ce fichier, ce n'est pas le code du programme. Si tu veux avoir un script qui garde la compatibilité des paramètres et que tu veux pouvoir mettre à jour séparément, tu le met dans un fichier séparé dans /bin ou /usr/bin, et tu planque l'exécutable réel.
Le code que tu met dans le script upstart sert uniquement à permettre à l'administrateur de modifier comment le programme est lancé, par exemple, en lui spécifiant une configuration générée dynamiquement. Là le script est un peu un mauvais exemple: le système d'init pourrai regarder si l'exécutable existe, /etc/default/ssh est clairement une fainéantise de conversion, et le répertoire de séparation des privileges est spécifié à la compilation, donc aucun intérêt à vouloir modifier ça. Le seul cas véridique, c'est la bidouille du PermitRootLogin. Et étant donné l'importance de l'option, c'est une bonne idée de la laisser là. Tu peux toujours le mettre ailleurs, si tu pense que tu va vouloir mettre ça à jour sans rien casser, et que tu à envie de penser au cas ou l'administrateur ne veut pas de ça.
Le script de démarrage sert à être modifié par l'administrateur, tout comme les paramètres. S'il y a des choses que la distribution veut mettre à jour et qui ne pètent rien, alors ça n'a rien à faire là. Si les modifications de la distribution peut péter des configurations, alors c'est que c'était de la configuration, et il faut l'intervention de l'admin.
Et si upstart n'intégrai pas la possibilité pour l'admin de scripter, ça serait une grande régression par rapport aux scripts d'init BSD.