Habilitación condicional de archivos systemd a través del paquete Debian


8

He creado un paquete deb que instala un servicio.

En nuestros dispositivos integrados, quiero que este paquete habilite automáticamente el servicio. En nuestras estaciones de trabajo para desarrolladores, quiero que los desarrolladores lo systemctl start foohagan manualmente (es un servicio pesado, por lo que solo consume recursos si se ejecuta todo el tiempo en un entorno de escritorio).

¿Cómo puedo solicitar al usuario su decisión durante el apt-getpaso? ¿Es esa la mejor solución?

Tenga en cuenta que he creado el paquete usando dh_makey debhelpery lo habilité con:

%:
    dh $@ --with=systemd

override_dh_systemd_enable:
    dh_systemd_enable --name=foo foo.service

Respuestas:


11

Puede usar los valores predeterminados de systemd para determinar si un servicio systemd se habilitará o deshabilitará de manera predeterminada en el momento de la instalación.

Los ajustes preestablecidos de Debian habilitan de manera predeterminada todos los servicios a medida que se instalan, por lo que solo necesita enviar un ajuste preestablecido a las estaciones de trabajo de desarrollo (el comportamiento predeterminado coincide con lo que desea que suceda en producción), enviando un archivo como que /etc/systemd/system-preset/80-foo.presetcontiene una línea que dice

disable foo.service

Si administra sus estaciones de trabajo de desarrollador utilizando un sistema como Puppet, Chef, Ansible, etc., puede usarlas para enviar dicha configuración predeterminada del sistema, eso debería facilitarle la aplicación de la política solo a estaciones de trabajo de desarrollador y no a producción máquinas.

Su paquete .deb debe usar el systemctl presetcomando para habilitar el servicio, ya que ese comando respetará la configuración preestablecida.

Como @JdeBP y @sourcejedi señalan, las macros de Debian en deb-helpers (como dh_systemd_enable) ya lo hacen, invocan deb-systemd-helperlo que usará systemctl presetpor defecto (con una pequeña advertencia que si elimina (pero no purga) el paquete, y luego vuelva a instalarlo, entonces no habilitará el servicio, incluso si elimina el archivo preestablecido.) Vea este comentario en deb-systemd-helperla enableoperación :

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

Para obtener más información sobre la función systemd de los presets, consulte la página de manual de los presets systemd y del comando systemctl presetque lo implementa.


1
Esto es exactamente lo que necesitaba. Implemento el entorno de desarrollo a través de un metapaquete y así puedo instalar estos *.presetarchivos como parte de ese paquete.
Stewart

44
Una peculiaridad importante es saber que los preajustes solo se consultan deb-systemd-helperla primera vez que se instala un paquete. Después de eso, se consulta la base de datos paralela mantenida por las herramientas de Debian, hasta que se purgue el paquete. news.ycombinator.com/item?id=18320131
JdeBP

1
Por lo deb-systemd-helperque parece usar los preajustes. Y esto debería funcionar sin necesidad de un comando preestablecido systemctl manual dentro del paquete .deb. La peculiaridad específica de Debian es lo que sucede si elimina (pero no purga) el paquete. Si luego vuelve a instalar el paquete, no habilitará el servicio, incluso si elimina el archivo preestablecido. salsa.debian.org/debian/init-system-helpers/blob/debian/1.56/…
sourcejedi

@sourcejedi incorporó sus comentarios y el enlace al comentario deb-systemd-helper en la respuesta. ¡Gracias!
filbranden

5

Si desea solicitar al usuario durante la instalación, debe usardebconf . Esto tiene una serie de ventajas, incluso si no se encuentra en un contexto en el que la Política de Debian es relevante: proporciona una experiencia consistente para el usuario final, con soporte para una variedad de interfaces; admite diferentes "niveles"; Es compatible con la siembra previa. La inicialización significa que el paquete se puede configurar previamente, en cuyo caso no se solicitará en absoluto. Los diferentes niveles significan que se puede configurar un aviso para que solo se muestre en ciertas circunstancias; entonces puede hacer que el paquete se instale sin solicitarlo de manera predeterminada (para sus objetivos incrustados), e indique a sus desarrolladores que configuren su interfaz de manera apropiada al instalar el paquete para que vean el mensaje.

Sin embargo, creo que es mejor evitar las indicaciones por completo cuando sea posible. Esto es especialmente cierto para los servicios que tienen otras formas de lidiar con las preferencias del usuario final, y donde lidiar con las preferencias del usuario complica las secuencias de comandos del mantenedor (vea las secuencias de comandos generadas en su paquete, ya abordan una serie de problemas sutiles, usando deb-systemd-helper- usted tendría que replicar todo eso, con su manejo de preferencias en la parte superior).

Si sus desarrolladores nunca necesitan ejecutar el servicio, pueden enmascararlo antes de instalar el paquete, y el servicio nunca estará habilitado:

sudo systemctl mask foo

Si sus desarrolladores a veces necesitan ejecutar el servicio, utilizando la unidad systemd, pueden deshabilitarlo después de instalar el paquete por primera vez, y las instalaciones posteriores lo recordarán:

sudo apt install foo
sudo systemctl disable --now foo

El valor predeterminado sería habilitar el servicio.


Buena respuesta. debconfse parece a lo que tenía en mente, pero estoy de acuerdo en que es mejor evitar avisos cuando sea posible. Sabía sobre esto systemctl disable, pero estaba tratando de ayudar al usuario a evitar "saltar un paso" durante la instalación. La *.presetssolución sugerida por Filippe resuelve esto.
Stewart

De hecho, los preajustes se ajustan perfectamente.
Stephen Kitt
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.