Un des soucis non résolu de sysvinit etait le fait que tout etait dans /etc/init.d, marqué (dans les distributions rpms) comme fichier de configuration. Et donc, la moindre modif impliquait de perdre le nouveau fichier à l'update et donc de passer à coté de corrections de bugs ( parfois ).
Avec l'utilisation d'un fichier declaratif à la place d'un fichier qui est un script, on peut mettre au point un algo de fusion de 1 ou plusieurs fichiers servent à décrire une unité de ta configuration ( genre un service, etc, unité au sens large, pas au sens systemd )
Du coup, on peut faire la chose suivante. Dans un repertoire, tu as le fichier fourni par upstream ( distribution, etc ) et dans un autre, tu as le fichier modifié par l'admin. Tu peux faire ça en ecrasant le fichier ( cad toto.service dans les 2 ) et on prends que le fichier de l'admin. Ou on peut utiliser la drop-in configuration, cad faire un repertoire toto.service.d/ avec un fichier foo.conf qui contient un fragment du fichier, et on fusionne les 2 clés par clé, en donnant la priorité à la clé dans le repertoire pour l'admin. Par exemple, je veux rajouter PrivateTmp=yes sur un service, je peux, et de tel sorte que ça soit résistant à l'upgrade, visible ( cad via ls, ou juste via les commandes comme systemctl ) et "config management friendly" ( vu qu'il s'agit juste de déposer un fichier dans un repertoire ).
Du coup, tu as /etc/systemd/system , /usr/lib/systemd/system et /run/systemd/system/ . La section "Unit Load path" de la page de man systemd.unit(5) explique les régles de priorités.
[^] # Re: Par curiosité
Posté par Misc (site web personnel) . En réponse à la dépêche systemd pour les administrateurs, partie 1 et 2. Évalué à 10.
En fait, c'est assez simple.
Un des soucis non résolu de sysvinit etait le fait que tout etait dans /etc/init.d, marqué (dans les distributions rpms) comme fichier de configuration. Et donc, la moindre modif impliquait de perdre le nouveau fichier à l'update et donc de passer à coté de corrections de bugs ( parfois ).
Avec l'utilisation d'un fichier declaratif à la place d'un fichier qui est un script, on peut mettre au point un algo de fusion de 1 ou plusieurs fichiers servent à décrire une unité de ta configuration ( genre un service, etc, unité au sens large, pas au sens systemd )
Du coup, on peut faire la chose suivante. Dans un repertoire, tu as le fichier fourni par upstream ( distribution, etc ) et dans un autre, tu as le fichier modifié par l'admin. Tu peux faire ça en ecrasant le fichier ( cad toto.service dans les 2 ) et on prends que le fichier de l'admin. Ou on peut utiliser la drop-in configuration, cad faire un repertoire toto.service.d/ avec un fichier foo.conf qui contient un fragment du fichier, et on fusionne les 2 clés par clé, en donnant la priorité à la clé dans le repertoire pour l'admin. Par exemple, je veux rajouter PrivateTmp=yes sur un service, je peux, et de tel sorte que ça soit résistant à l'upgrade, visible ( cad via ls, ou juste via les commandes comme systemctl ) et "config management friendly" ( vu qu'il s'agit juste de déposer un fichier dans un repertoire ).
Du coup, tu as /etc/systemd/system , /usr/lib/systemd/system et /run/systemd/system/ . La section "Unit Load path" de la page de man systemd.unit(5) explique les régles de priorités.