Filepath pour les scripts et les units systemd généré par l'utilisateur
Bonjour la liste, J'aimerai avoir vos avis concernant l'endroit où vous mettez les scripts que vous écrivez et les units systemd que vous écrivez lorsqu'ils doivent être accessible pour tout le système. Mon avis est que les scripts perso devraient être installés dans /usr/local/bin. De la même façon, les units systemd perso devraient être installés dans /usr/local/lib/systemd/system, et pas dans /etc/systemd/system, comme c'est le cas actuellement, qui devrait uniquement être utilisé pour des fichiers de configurations selon FHS <https://refspecs.linuxfoundation.org/FHS_3.0/>(la question est alors: les units systemd sont-ils des fichiers de configurations ?). PS: Je suis actuellement en train d'essayer de modifier la documentation de systemd sur le sujet (https://github.com/systemd/systemd/pull/11388). Selon certains, /usr/local/lib/systemd serait pour les units installés pour des programmes installés par l'utilisateur. Cordialement, Jonas DOREL
Bonsoir, On 1/16/19 8:54 PM, Jonas DOREL via FRsAG wrote:
J'aimerai avoir vos avis concernant l'endroit où vous mettez les scripts que vous écrivez et les units systemd que vous écrivez lorsqu'ils doivent être accessible pour tout le système.
Mon avis est que les scripts perso devraient être installés dans /usr/local/bin. De la même façon, les units systemd perso devraient être installés dans /usr/local/lib/systemd/system, et pas dans /etc/systemd/system, comme c'est le cas actuellement, qui devrait uniquement être utilisé pour des fichiers de configurations selon FHS <https://refspecs.linuxfoundation.org/FHS_3.0/>(la question est alors: les units systemd sont-ils des fichiers de configurations ?).
PS: Je suis actuellement en train d'essayer de modifier la documentation de systemd sur le sujet (https://github.com/systemd/systemd/pull/11388). Selon certains, /usr/local/lib/systemd serait pour les units installés pour des programmes installés par l'utilisateur.
En fait, d'après moi, la réponse dépend : - de la distribution, - et du fait que l'exécutable et l'unit systemd soient fournis ou non par un package (officiel ou non) de la distribution. Je vais me limiter à Debian/Ubuntu que je connais un peu. Sous Debian/Ubuntu donc il me semble que la bonne pratique respectueuse de la Debian Policy (qu'on peut toujours ne pas respecter) est la suivante : 1. Si ton exécutable et ton unit systemd proviennent d'un package alors leur place est respectivement dans /usr/(s)bin/ et /lib/systemd/system/. 2. Sinon (ie fichiers installés hors packaging), leur place est respectivement dans /usr/local/(s)bin/ et /usr/local/lib/systemd/system/ Et dans les deux cas, si ton service est activé, tu auras un symlink qui pointera dessus quelque part dans le répertoire /etc/systemd/system/. Mes 2 centimes. N'hésitez pas à me rectifier si j'ai dis des bêtises car je ne suis pas sûr de moi à 200%. ;) -- François Lafont
Bonjour, Le 16 janvier 2019 20:54:06 GMT+01:00, Jonas DOREL via FRsAG <frsag@frsag.org> a écrit :
Bonjour la liste,
J'aimerai avoir vos avis concernant l'endroit où vous mettez les scripts que vous écrivez et les units systemd que vous écrivez lorsqu'ils doivent être accessible pour tout le système.
Mon avis est que les scripts perso devraient être installés dans /usr/local/bin. De la même façon, les units systemd perso devraient être installés dans /usr/local/lib/systemd/system, et pas dans /etc/systemd/system, comme c'est le cas actuellement, qui devrait uniquement être utilisé pour des fichiers de configurations selon FHS <https://refspecs.linuxfoundation.org/FHS_3.0/>(la question est alors: les units systemd sont-ils des fichiers de configurations ?).
PS: Je suis actuellement en train d'essayer de modifier la documentation de systemd sur le sujet (https://github.com/systemd/systemd/pull/11388). Selon certains, /usr/local/lib/systemd serait pour les units installés pour des programmes installés par l'utilisateur.
Et ils ont raison pour autant que je saches. /usr/lib/systemd/system, c’est pour les paquets installés via la distribution. /usr/local/lib/systemd/system, c’est pour les paquets installés localement. /etc/systemd/system, c’est pour les ajouts d’units locaux. Par exemple pour un programme qui ne fournit pas d’unit. Globalement, tu peux retenir que tu n’es jamais censé toucher à /usr/* à la main, que dans /usr, le seul dossier où tu peux faire des modifs sans le gestionnaire de paquet de ta distro, c’est /usr/local (via des make install, pip, node, etc.) mais encore une fois normalement tu n’y touches pas toi-même directement, et qu’enfin tout ce qui est configuration d’un système par un admin (et les units systemd en font partie), ça se passe dans /etc. Je regarderai la PR quand je serais sur un ordi. Bruno
Le jeu. 17 janv. 2019 à 09:49, Bruno Pagani <bruno.pagani@ens-lyon.org> a écrit :
Et ils ont raison pour autant que je saches. [...]
C'est mon avis également, et je suis d'accord avec les explications de Bruno. -- Jonathan Leroy.
Coucou, Le Thu, 17 Jan 2019 09:48:19 +0100, Bruno Pagani <bruno.pagani@ens-lyon.org> a écrit :
/etc/systemd/system, c’est pour les ajouts d’units locaux. Par exemple pour un programme qui ne fournit pas d’unit.
C'est aussi pour les surcharges locales obtenues par systemctl edit. Cf https://www.freedesktop.org/software/systemd/man/systemctl.html#edit%20UNIT%... Elles atterrisses dans /etc/systemd/system/<unit>/override.conf François -- François Poulain <fpoulain@metrodore.fr>
Bonsoir, Le 17/01/2019 à 15:49, François Poulain a écrit :
Coucou,
Le Thu, 17 Jan 2019 09:48:19 +0100, Bruno Pagani <bruno.pagani@ens-lyon.org> a écrit :
/etc/systemd/system, c’est pour les ajouts d’units locaux. Par exemple pour un programme qui ne fournit pas d’unit. C'est aussi pour les surcharges locales obtenues par systemctl edit. Cf https://www.freedesktop.org/software/systemd/man/systemctl.html#edit%20UNIT%...
Elles atterrisses dans /etc/systemd/system/<unit>/override.conf
François
Oui tout à fait (je ne donnais qu’un exemple). De même que les remplacements complets, qui se font en plaçant un fichier <unit> directement dans /etc/systemd/system/. Bruno
Et ils ont raison pour autant que je saches.> > /usr/lib/systemd/system, c’est pour les paquets installés via la distribution.> > /usr/local/lib/systemd/system, c’est pour les paquets installés localement.> > /etc/systemd/system, c’est pour les ajouts d’units locaux. Par exemple pour un programme qui ne fournit pas d’unit.
Je suis d'accord que c'est le système qui fait consensus (même si la documentation n'est pas très explicite actuellement). Ma question vise également à questionner les habitutes prises par la communauté jusque là.
Globalement, tu peux retenir que tu n’es jamais censé toucher à /usr/* à la main, que dans /usr, le seul dossier où tu peux faire des modifs sans le gestionnaire de paquet de ta distro, c’est /usr/local (via des make install, pip, node, etc.) mais encore une fois normalement tu n’y touches pas toi-même directement, et qu’enfin tout ce qui est configuration d’un système par un admin (et les units systemd en font partie), ça se passe dans /etc.
Quid des scripts créés par l'administrateur ?
Je regarderai la PR quand je serais sur un ordi.> > Bruno
Il est évident que mon avis est biaisé sur la question, mais je ne comprends pas la raison initial qui fait que des fichiers qui se trouvent initialement dans /usr/lib se retrouve dans /etc, mis à part le fait historique que les scripts init.d y étaient précédemment. Il existe à mon sens une raison seule raison logique d'utiliser /etc, qui est que les units de ce dossier ont précédence sur les autres, mais ma question vise à mettre en place la meilleur pratique possible en prenant en compte l'architecture des fichiers Linux. A mon sens l'utilisation de /usr/local fait sens, ne nécessite pas de changement de code, et la mise en place de d'une documentation spécifiant cette utilisation serait un premier pas vers cette utilisation. Jonas
Bonsoir, Le 17/01/2019 à 17:37, jonas.dorel--- via FRsAG a écrit :
Et ils ont raison pour autant que je saches.
/usr/lib/systemd/system, c’est pour les paquets installés via la distribution. /usr/local/lib/systemd/system, c’est pour les paquets installés localement. /etc/systemd/system, c’est pour les ajouts d’units locaux. Par exemple pour un programme qui ne fournit pas d’unit. Je suis d'accord que c'est le système qui fait consensus (même si la documentation n'est pas très explicite actuellement). Ma question vise également à questionner les habitutes prises par la communauté jusque là.
Ah, là je suis biaisé alors, je suis « développeur » pour une distribution Linux, donc mes habitudes correspondent à nos règles, qui sont celles sus-citées.
Globalement, tu peux retenir que tu n’es jamais censé toucher à /usr/* à la main, que dans /usr, le seul dossier où tu peux faire des modifs sans le gestionnaire de paquet de ta distro, c’est /usr/local (via des make install, pip, node, etc.) mais encore une fois normalement tu n’y touches pas toi-même directement, et qu’enfin tout ce qui est configuration d’un système par un admin (et les units systemd en font partie), ça se passe dans /etc. Quid des scripts créés par l'administrateur ?
Ça dépend, mais potentiellement à déployer dans /usr/local/. Mais quand même pas à la main, tu te fais un outil qui prend tes sources et les mets en place proprement.
Je regarderai la PR quand je serais sur un ordi.
Bruno Il est évident que mon avis est biaisé sur la question, mais je ne comprends pas la raison initial qui fait que des fichiers qui se trouvent initialement dans /usr/lib se retrouve dans /etc, mis à part le fait historique que les scripts init.d y étaient précédemment.
Parce que ce sont des fichiers de configurations, et que la règle pour les fichiers de configurations est que ceux fournis par les paquets sont censés être dans /usr/* (où *!=local), et tout ce qui est configuration locale par l’administrateur se passe dans /etc. Et donc non, ce n’est pas “legacy”.
Il existe à mon sens une raison seule raison logique d'utiliser /etc, qui est que les units de ce dossier ont précédence sur les autres, mais ma question vise à mettre en place la meilleur pratique possible en prenant en compte l'architecture des fichiers Linux. A mon sens l'utilisation de /usr/local fait sens, ne nécessite pas de changement de code, et la mise en place de d'une documentation spécifiant cette utilisation serait un premier pas vers cette utilisation.
Les personnes qui t’ont répondu sur GitHub ont tout très bien expliqué je trouve, particulièrement le résumé de Lennart. ;) Bruno
Le jeudi 17 janvier 2019 à 18:35 +0100, Bruno Pagani a écrit :
Les personnes qui t’ont répondu sur GitHub ont tout très bien expliqué je trouve, particulièrement le résumé de Lennart. ;)
Bruno
Tu peux nous donner le lien, STP ? Merci Franck
Date: Sun, 20 Jan 2019 08:52:15 From: "Franck Routier (perso)" <alci@mecadu.org> To: Bruno Pagani <bruno.pagani@ens-lyon.org>, jonas.dorel@laposte.net, frsag@frsag.org Subject: Re: [FRsAG] Re : Re: Filepath pour les scripts et les units systemd généré par l'utilisateur
Le jeudi 17 janvier 2019 à 18:35 +0100, Bruno Pagani a écrit :
Les personnes qui t’ont répondu sur GitHub ont tout très bien expliqué je trouve, particulièrement le résumé de Lennart. ;)
Bruno
Tu peux nous donner le lien, STP ?
Merci Franck
Salut, Je suppose qu'il parle du lien dans le message original :
Date: Wed, 16 Jan 2019 20:54:06 From: Jonas DOREL via FRsAG <frsag@frsag.org> Reply-To: Jonas DOREL <jonas.dorel@laposte.net> To: French SysAdmin Group <frsag@frsag.org> Subject: [FRsAG] Filepath pour les scripts et les units systemd généré par l'utilisateur ...
PS: Je suis actuellement en train d'essayer de modifier la documentation de systemd sur le sujet (https://github.com/systemd/systemd/pull/11388). Selon certains, /usr/local/lib/systemd serait pour les units installés pour des programmes installés par l'utilisateur.
Vu~
participants (8)
-
Bruno Pagani -
Franck Routier (perso) -
Francois Lafont -
François Poulain -
Jonas DOREL -
jonas.dorel＠laposte.net
-
Jonathan Leroy -
Vu Ngoc VU