Activation conditionnelle des fichiers systemd via le package Debian

J'ai créé un paquet deb qui installe un service.

Sur nos appareils embarqués, je souhaite que ce package active automatiquement le service. Sur nos postes de travail de développeur, je veux que les développeurs le fassent systemctl start foomanuellement (c'est un service lourd, et donc il consomme juste des ressources s'il est exécuté tout le temps sur un environnement de bureau).

Comment puis-je demander à l'utilisateur de prendre sa décision au cours de l' apt-getétape? Est-ce la meilleure solution?

Remarque, j'ai créé le package à l'aide dh_makeet je l'ai debhelperactivé avec:

%:
    dh $@ --with=systemd

override_dh_systemd_enable:
    dh_systemd_enable --name=foo foo.service

Vous pouvez utiliser les préréglages systemd pour déterminer si un service systemd sera activé ou désactivé par défaut au moment de l'installation.

Les préréglages Debian activent par défaut tous les services au fur et à mesure de leur installation, vous n'avez donc qu'à expédier un préréglage aux postes de travail de développement (le comportement par défaut correspond à ce que vous voulez faire en production), en expédiant un fichier tel que /etc/systemd/system-preset/80-foo.presetcontenant une ligne qui dit

disable foo.service

Si vous gérez vos postes de travail de développeur à l'aide d'un système tel que Puppet, Chef, Ansible, etc., vous pouvez les utiliser pour expédier une telle configuration prédéfinie systemd, ce qui devrait vous permettre d'appliquer facilement la stratégie aux postes de travail de développeur uniquement et non à la production. Machines.

Votre package .deb doit utiliser la systemctl presetcommande pour activer le service, car cette commande respectera la configuration prédéfinie.

Comme le soulignent @JdeBP et @sourcejedi , les macros Debian dans deb-helpers (telles que dh_systemd_enable) le font déjà, elles invoquent deb-systemd-helperce qui utilisera systemctl presetpar défaut (avec une petite mise en garde que si vous supprimez (mais ne purgez pas) le paquet, et le réinstaller plus tard, il n'activera alors pas le service, même si vous supprimez le fichier prédéfini.) Voir ce commentaire dans deb-systemd-helperl' enableopération de :

    # We use 'systemctl preset' on the initial installation only.
    # On upgrade, we manually add the missing symlinks only if the
    # service already has some links installed. Using 'systemctl
    # preset' allows administrators and downstreams to alter the
    # enable policy using systemd-native tools.

Pour plus d'informations sur la fonction systemd des préréglages, consultez la page de manuel des préréglages systemd et de la commande systemctl presetqui l'implémente.

Si vous souhaitez inviter l'utilisateur lors de l'installation, vous devez utiliserdebconf . Cela présente un certain nombre d'avantages, même si vous n'êtes pas dans un contexte où la politique Debian est pertinente: elle fournit une expérience utilisateur cohérente, avec la prise en charge d'une variété de frontends; il prend en charge différents «niveaux»; il prend en charge le pré-ensemencement. Le pré-amorçage signifie que le package peut être préconfiguré, auquel cas il ne demandera pas du tout. Les différents niveaux signifient qu'une invite peut être configurée pour s'afficher uniquement dans certaines circonstances; vous pouvez alors installer le package sans invite par défaut (pour vos cibles intégrées) et demander à vos développeurs de configurer correctement leur frontend lors de l'installation du package afin qu'ils voient l'invite.

Cependant, je pense qu'il vaut mieux éviter de demander tout à fait lorsque cela est possible. Cela est particulièrement vrai pour les services qui ont d'autres façons de gérer les préférences de l'utilisateur final et où le traitement des préférences de l'utilisateur complique les scripts du responsable (voir les scripts générés dans votre package, ils traitent déjà un certain nombre de problèmes subtils, en utilisant deb-systemd-helper- vous je devrais répliquer tout cela, avec votre gestion des préférences en haut).

Si vos développeurs n'ont jamais besoin d'exécuter le service, ils peuvent le masquer avant d'installer le package, et le service ne sera jamais activé:

sudo systemctl mask foo

Si vos développeurs ont parfois besoin d'exécuter le service à l'aide de l'unité systemd, ils peuvent le désactiver après avoir installé le package pour la première fois, et les installations suivantes s'en souviendront:

sudo apt install foo
sudo systemctl disable --now foo

La valeur par défaut serait alors d'activer le service.