Administrar cuentas de servicio en una especificación RPM

16

Me dieron una especificación RPM parcialmente completa para un servicio que estamos escribiendo. Llega tan lejos como hacer los directorios requeridos, copiar archivos, configurar permisos, etc., pero no establece la cuenta del sistema requerida bajo la cual se ejecutará el servicio. Me dijeron que es mejor que el RPM se encargue de esto, así que agregué

Requires(pre): /usr/sbin/useradd

%pre
useradd -r -d /path/to/program -s /bin/false myservice

Esto tiene éxito en crear la cuenta de usuario (y el grupo asociado), por lo que más adelante, cuando intenta establecer la propiedad / permisos en los archivos del servicio, también tiene éxito.

Mi problema actual es, a) si la cuenta de usuario ya existe, la instalación de RPM falla porque useraddfalla (porque el usuario ya existe); y b) No sé cómo rpm -e myserviceeliminar también el usuario y el grupo asociados.

user-accounts services rpm

— Coderer
fuente

//, ¿Considerarías usar FPM?

— Nathan Basanese

18

De hecho, resolví esto de forma independiente, mirando otras especificaciones de RPM que hicieron cosas similares. Si solo desea agregar un usuario (condicionalmente), use el enlace de Ignacio. Hice esto:

Requires(pre): /usr/sbin/useradd, /usr/bin/getent
Requires(postun): /usr/sbin/userdel

%pre
/usr/bin/getent group myservice || /usr/sbin/groupadd -r myservice
/usr/bin/getent passwd myservice || /usr/sbin/useradd -r -d /path/to/program -s /sbin/nologin myservice

%postun
/usr/sbin/userdel myservice

Esto asegura que el RPM "se limpia después de sí mismo", pero aún ofrece la posibilidad de instalar incluso si la cuenta ya existe.

— Coderer
fuente

13

Aunque esto responde a la pregunta, vale la pena leer la nota en el enlace del enlace de Fedora publicado por Ignacio sobre por qué no es deseable eliminar el usuario / grupo.

— CoverosGene

1

Hay un problema de reutilización de UID y GID (cuando el usuario eliminado tiene el UID / GID más alto), lo que hace que cualquier uso automatizado de userdel sea una mala idea.

— Bruno9779

1

En mi CentOS 6.7 eliminé el comando / usr / sbin / groupadd ya que el comando useradd creará el grupo en sí. Además, useradd saldrá con un error cuando ya exista un grupo del mismo nombre.

— Raffael

informe rpmlint "W: peligroso-comando-en% postun userdel" si lo usa

— Rfraile

5

Cualquiera de las dos respuestas anteriores está lista para producción, ya que esos métodos eliminarán al usuario si el paquete se actualiza. Yum instala el nuevo paquete y luego elimina el paquete anterior. Esto te dejará sin un usuario. ¡No es genial!

Use este método en su lugar:

%postun
case "$1" in
   0) # This is a yum remove.
      /usr/sbin/userdel myservice
   ;;
   1) # This is a yum upgrade.
      # do nothing
   ;;
 esac

— Steven
fuente

4

La respuesta de Coderer es buena, pero el segundo comando previo me da un error en Centos 7. El grupo debe especificarse.

Requires(pre): /usr/sbin/useradd, /usr/bin/getent
Requires(postun): /usr/sbin/userdel

%pre
/usr/bin/getent group myservice > /dev/null || /usr/sbin/groupadd -r myservice
/usr/bin/getent passwd myservice > /dev/null || /usr/sbin/useradd -r -d /path/to/program -s /sbin/nologin -g myservice myservice

%postun
/usr/sbin/userdel myservice

Agregué también redirigir a / dev / null para ignorar los ecos no deseados.

— Tabinol
fuente