Pregunta Administrar cuentas de servicio en una especificación de RPM


Me han dado una especificación de RPM parcialmente completa para un servicio que estamos escribiendo. Llega hasta hacer los directorios necesarios, copiar archivos, establecer permisos, etc., pero no crea la cuenta del sistema requerida con la que se ejecutará el servicio. Me dijeron que es mejor que las RPM se encarguen de esto, así que agregué

Requires(pre): /usr/sbin/useradd

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

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

Mi problema actual es: a) si la cuenta de usuario ya existe, la instalación de RPM falla porque useradd falla (porque el usuario ya existe); yb) No sé cómo tener rpm -e myservice también elimina el usuario y grupo asociado.


14


origen


//, ¿Considerarías usar FPM? - Nathan Basanese


Respuestas:


En realidad, 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 limpie después de sí mismo", pero todavía ofrece la posibilidad de instalar incluso si la cuenta ya existe.


17



Aunque esto responde la pregunta, vale la pena leer la nota en el enlace de Fedora enlazar publicado por Ignacio acerca de por qué no es deseable eliminar al usuario / grupo. - CoverosGene
Existe 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
En mi CentOS 6.7 eliminé el comando / usr / sbin / groupadd ya que el comando useradd creará el grupo mismo. Además, useradd saldrá con un error cuando ya exista un grupo del mismo nombre. - Raffael
Informe rpmlint "W: dangerous-command-in% postun userdel" si lo usa - Rfraile


La respuesta de Coderer es buena, pero el segundo pre comando me da un error en Centos 7. Se debe especificar el grupo.

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 echos no deseados.


3





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

3