Systemd-Dateien über Debian-Verpackung bedingt aktivieren

Ich habe ein Deb- Paket erstellt, das einen Dienst installiert.

Auf unseren eingebetteten Geräten soll dieses Paket den Dienst automatisch aktivieren. Ich möchte, dass die Entwickler auf unseren Entwicklerarbeitsplätzen systemctl start foomanuell arbeiten (dies ist ein umfangreicher Dienst, der nur Ressourcen verbraucht, wenn er ständig in einer Desktop-Umgebung ausgeführt wird).

Wie kann ich den Benutzer während des apt-getSchritts zur Entscheidung auffordern ? Ist das die beste Lösung?

Hinweis: Ich habe das Paket mit dh_makeund erstellt debhelperund es aktiviert mit:

%:
    dh $@ --with=systemd

override_dh_systemd_enable:
    dh_systemd_enable --name=foo foo.service

Sie können systemd-Voreinstellungen verwenden, um zu beeinflussen, ob ein systemd-Dienst bei der Installation standardmäßig aktiviert oder deaktiviert wird.

Die Debian-Voreinstellungen aktivieren standardmäßig alle Dienste, während sie installiert sind. Sie müssen also nur eine Voreinstellung an die Entwicklungsarbeitsstationen senden (das Standardverhalten entspricht dem, was in der Produktion geschehen soll), indem Sie eine Datei versenden, /etc/systemd/system-preset/80-foo.presetdie beispielsweise eine Zeile enthält, die sagt

disable foo.service

Wenn Sie Ihre Entwicklerarbeitsstationen mit einem System wie Puppet, Chef, Ansible usw. verwalten, können Sie mit ihnen eine solche voreingestellte Systemkonfiguration ausliefern, die es Ihnen erleichtern sollte, die Richtlinie nur auf Entwicklerarbeitsstationen und nicht auf die Produktion anzuwenden Maschinen.

Ihr .deb-Paket sollte den systemctl presetBefehl verwenden, um den Dienst zu aktivieren, da dieser Befehl die voreingestellte Konfiguration berücksichtigt.

Wie @JdeBP und @sourcejedi hervorheben, rufen die Debian-Makros in Deb-Helfern (wie z. B. dh_systemd_enable) dies bereits auf. Diese deb-systemd-helperwerden systemctl presetstandardmäßig verwendet (mit einer kleinen Einschränkung, wenn Sie das Paket entfernen (aber nicht löschen), und Wenn Sie es später erneut installieren, wird der Dienst nicht aktiviert, selbst wenn Sie die voreingestellte Datei entfernen.) Siehe diesen Kommentar in deb-systemd-helperder enableOperation :

    # 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.

Weitere Informationen zur systemd-Funktion von Voreinstellungen finden Sie in der Manpage der systemd-Voreinstellungen und des Befehls, systemctl presetder sie implementiert.

Wenn Sie den Benutzer während der Installation auffordern möchten, sollten Sie verwendendebconf . Dies hat eine Reihe von Vorteilen, auch wenn Sie sich nicht in einem Kontext befinden, in dem die Debian-Richtlinie relevant ist: Es bietet eine konsistente Endbenutzererfahrung mit Unterstützung für eine Vielzahl von Frontends. es unterstützt verschiedene "Ebenen"; es unterstützt das Pre-Seeding. Pre-Seeding bedeutet, dass das Paket vorkonfiguriert werden kann. In diesem Fall wird es überhaupt nicht dazu aufgefordert. Aufgrund der verschiedenen Ebenen kann eine Eingabeaufforderung so eingerichtet werden, dass sie nur unter bestimmten Umständen angezeigt wird. Sie können das Paket dann ohne Aufforderung standardmäßig installieren lassen (für Ihre eingebetteten Ziele) und Ihre Entwickler anweisen, ihr Frontend bei der Installation des Pakets entsprechend einzurichten, damit sie die Eingabeaufforderung sehen.

Ich denke jedoch, dass es besser ist, wenn möglich keine Eingabeaufforderungen zu vermeiden. Dies gilt insbesondere für Dienste, die andere Möglichkeiten zum Umgang mit Endbenutzereinstellungen haben und bei denen der Umgang mit Benutzereinstellungen die Betreuerskripte kompliziert (siehe die generierten Skripte in Ihrem Paket, sie behandeln bereits eine Reihe subtiler Probleme, indem deb-systemd-helperSie - Sie verwenden Ich müsste all das replizieren, wobei Ihre Präferenzbehandlung an oberster Stelle steht.

Wenn Ihre Entwickler den Dienst niemals ausführen müssen, können sie ihn vor der Installation des Pakets maskieren, und der Dienst wird niemals aktiviert:

sudo systemctl mask foo

Wenn Ihre Entwickler den Dienst manchmal mithilfe der systemd-Einheit ausführen müssen, können sie ihn nach der ersten Installation des Pakets deaktivieren. Bei nachfolgenden Installationen wird Folgendes berücksichtigt:

sudo apt install foo
sudo systemctl disable --now foo

Die Standardeinstellung wäre dann, den Dienst zu aktivieren.