Abilitazione condizionale dei file systemd tramite il pacchetto Debian

Ho creato un pacchetto deb che installa un servizio.

Sui nostri dispositivi integrati, voglio che questo pacchetto abiliti automaticamente il servizio. Sulle nostre workstation per sviluppatori, voglio che gli sviluppatori systemctl start foolo facciano manualmente (è un servizio pesante e quindi consuma solo risorse se eseguito tutto il tempo su un ambiente desktop).

Come posso richiedere all'utente la decisione durante il apt-getpassaggio? È la soluzione migliore?

Nota, ho creato il pacchetto utilizzando dh_makeed debhelpere attivato con:

%:
    dh $@ --with=systemd

override_dh_systemd_enable:
    dh_systemd_enable --name=foo foo.service

È possibile utilizzare i preset di systemd per determinare se un servizio di systemd verrà abilitato o disabilitato per impostazione predefinita al momento dell'installazione.

Le preimpostazioni di Debian consentono di abilitare tutti i servizi mentre sono installati, quindi è necessario inviare un preset solo alle workstation di sviluppo (il comportamento predefinito corrisponde a ciò che si desidera che si verifichi in produzione), inviando un file come /etc/systemd/system-preset/80-foo.presetcontenente una riga che dice

disable foo.service

Se gestisci le tue stazioni di lavoro sviluppatore utilizzando un sistema come Puppet, Chef, Ansible, ecc., Puoi utilizzarle per spedire una tale configurazione preimpostata di sistema, che dovrebbe semplificare l'applicazione della politica solo alle workstation degli sviluppatori e non alla produzione macchinari.

Il pacchetto .deb dovrebbe usare il systemctl presetcomando per abilitare il servizio, poiché quel comando rispetterà la configurazione preimpostata.

Come sottolineato da @JdeBP e @sourcejedi , le macro Debian nei deb-helpers (come dh_systemd_enable) lo fanno già, invocano deb-systemd-helperche useranno systemctl presetdi default (con un piccolo avvertimento che se rimuovete (ma non eliminate) il pacchetto, e successivamente re-installarla, sarà poi non attivare il servizio, anche se si rimuove il file preimpostato) Cfr. questo commento a deb-systemd-helper's enablefunzionamento :

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

Per ulteriori informazioni sulla funzione systemd dei preset, consultare la pagina man dei preset systemd e del comando systemctl presetche lo implementa.

Se si desidera richiedere all'utente durante l'installazione, è necessario utilizzaredebconf . Ciò ha una serie di vantaggi, anche se non ci si trova in un contesto in cui la Debian Policy è rilevante: fornisce un'esperienza coerente per l'utente finale, con supporto per una varietà di frontend; supporta diversi "livelli"; supporta il pre-seeding. Pre-seeding significa che il pacchetto può essere preconfigurato, nel qual caso non verrà richiesto. I diversi livelli indicano che un prompt può essere impostato per mostrare solo in determinate circostanze; potresti quindi installare il pacchetto senza richiedere conferma per impostazione predefinita (per le destinazioni incorporate) e indicare ai tuoi sviluppatori di impostare il loro frontend in modo appropriato durante l'installazione del pacchetto in modo che visualizzino il prompt.

Tuttavia, penso che sia meglio evitare del tutto il suggerimento quando possibile. Ciò è particolarmente vero per i servizi che hanno altri modi di gestire le preferenze dell'utente finale e in cui la gestione delle preferenze dell'utente complica gli script del manutentore (vedi gli script generati nel tuo pacchetto, essi già affrontano una serie di problemi sottili, usando deb-systemd-helper- tu dovrei replicare tutto ciò, con la tua gestione delle preferenze in cima).

Se i tuoi sviluppatori non devono mai eseguire il servizio, possono mascherarlo prima di installare il pacchetto e il servizio non sarà mai abilitato:

sudo systemctl mask foo

Se i tuoi sviluppatori a volte hanno bisogno di eseguire il servizio, usando l'unità systemd, possono disabilitarlo dopo aver installato il pacchetto per la prima volta, e le installazioni successive ricorderanno questo:

sudo apt install foo
sudo systemctl disable --now foo

L'impostazione predefinita sarebbe quindi abilitare il servizio.