Gestione degli account di servizio in una specifica RPM

16

Mi è stata data una specifica RPM parzialmente completa per un servizio che stiamo scrivendo. Arriva fino a creare le directory richieste, copiare i file, impostare le autorizzazioni, ecc., Ma non crea l'account di sistema richiesto con cui verrà eseguito il servizio. Mi è stato detto che è meglio che gli RPM si occupino di questo, quindi ho aggiunto

Requires(pre): /usr/sbin/useradd

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

Questo riesce a creare l'account utente (e il gruppo associato), quindi in seguito quando tenta di impostare la proprietà / autorizzazioni sui file del servizio, anche quello riesce.

Il mio problema attuale è, a) se l'account utente esiste già, l'installazione RPM non riesce perché useraddnon riesce (perché l'utente esiste già); e b) non so come rpm -e myservicerimuovere anche l'utente e il gruppo associati.

user-accounts services rpm

— Coderer
fonte

//, prenderesti in considerazione l'utilizzo di FPM?

— Nathan Basanese,

18

In realtà l'ho risolto in modo indipendente, guardando altre specifiche RPM che hanno fatto cose simili. Se vuoi solo aggiungere un utente (in modo condizionale), usa il link di Ignacio. L'ho fatto:

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

Questo si assicura che l'RPM "ripulisca dopo se stesso" ma fornisca comunque la possibilità di installare anche se l'account esiste già.

— Coderer
fonte

13

Anche se questo risponde alla domanda, vale la pena leggere la nota nel link del link Fedora pubblicato da Ignacio sul perché non è desiderabile rimuovere l'utente / gruppo.

— CoverosGene,

1

Esiste un problema di riutilizzo di UID e GID (quando l'utente eliminato ha il più alto UID / GID), che rende una cattiva idea qualsiasi uso automatizzato di userdel.

— Bruno9779,

1

Sul mio CentOS 6.7 ho rimosso il comando / usr / sbin / groupadd poiché il comando useradd creerà il gruppo stesso. Anche useradd uscirà con un errore quando esiste già un gruppo con lo stesso nome.

— Raffael,

rpmlint segnala "W: dangerous-command-in% postun userdel" se lo usi

— Rfraile,

5

Una delle due risposte precedenti è pronta per la produzione poiché tali metodi elimineranno l'utente se il pacchetto viene aggiornato. Yum installa il nuovo pacchetto quindi rimuove il vecchio pacchetto. Questo ti lascerà senza un utente. Non fico!

Utilizzare invece questo metodo:

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

— Steven
fonte

4

La risposta di Coderer è buona, ma il secondo pre-comando mi dà un errore su Centos 7. Il gruppo deve essere specificato.

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

Ho aggiunto anche il reindirizzamento a / dev / null per ignorare gli echi indesiderati.

— Tabinol
fonte