Gestion des comptes de service dans une spécification RPM

16

J'ai reçu une spécification RPM partiellement complète pour un service que nous écrivons. Il va jusqu'à créer les répertoires requis, copier des fichiers, définir des autorisations, etc., mais il ne crée pas le compte système requis sous lequel le service s'exécutera. On m'a dit qu'il était préférable que le RPM s'en occupe, alors j'ai ajouté

Requires(pre): /usr/sbin/useradd

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

Cela réussit à créer le compte d'utilisateur (et le groupe associé), donc plus tard lorsqu'il essaie de définir la propriété / les autorisations sur les fichiers du service, cela réussit également.

Mon problème actuel est: a) si le compte d'utilisateur existe déjà, l'installation de RPM échoue car useraddéchoue (car l'utilisateur existe déjà); et b) Je ne sais pas comment rpm -e myservicesupprimer également l'utilisateur et le groupe associés.

user-accounts services rpm

— Coderer
source

//, envisageriez-vous d'utiliser FPM?

— Nathan Basanese

18

En fait, j'ai résolu cela indépendamment, en examinant d'autres spécifications RPM qui ont fait des choses similaires. Si vous souhaitez simplement ajouter un utilisateur (conditionnellement), utilisez le lien Ignacio. J'ai fait ça:

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

Cela garantit que le RPM "se nettoie après lui-même" mais offre toujours la possibilité d'installer même si le compte existe déjà.

— Coderer
source

13

Bien que cela réponde à la question, il vaut la peine de lire la note dans le lien du lien Fedora publié par Ignacio expliquant pourquoi la suppression de l'utilisateur / groupe n'est pas souhaitable.

— CoverosGene

1

Il existe un problème de réutilisation de l'UID et du GID (lorsque l'utilisateur supprimé a le UID / GID le plus élevé), ce qui rend toute utilisation automatisée de userdel une mauvaise idée.

— Bruno9779

1

Sur mon CentOS 6.7, j'ai supprimé la commande / usr / sbin / groupadd car la commande useradd créera le groupe lui-même. L'utilisateur s'affichera également avec une erreur lorsqu'un groupe du même nom existe déjà.

— Raffael

rapport rpmlint "W: dangereux-commande-dans% postun userdel" si vous l'utilisez

— Rfraile

5

L'une ou l'autre des deux réponses précédentes est prête pour la production car ces méthodes supprimeront l'utilisateur si le package est mis à niveau. Yum installe le nouveau package puis supprime l'ancien package. Cela vous laissera sans utilisateur. Pas cool!

Utilisez plutôt cette méthode:

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

— Steven
source

4

La réponse de Coderer est bonne mais la deuxième pré-commande me donne une erreur sur Centos 7. Le groupe doit être spécifié.

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

J'ai également ajouté une redirection vers / dev / null pour ignorer les échos indésirables.

— Tabinol
source