Zarządzanie kontami usług w specyfikacji RPM

16

Dostałem częściowo kompletną specyfikację RPM dla usługi, którą piszemy. Dochodzi do tworzenia wymaganych katalogów, kopiowania plików, ustawiania uprawnień itp., Ale nie tworzy wymaganego konta systemowego, pod którym usługa będzie działać. Powiedziano mi, że najlepiej zadbać o to RPM, więc dodałem

Requires(pre): /usr/sbin/useradd

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

Udaje się to utworzyć konto użytkownika (i powiązaną grupę), więc później, gdy próbuje ustawić własność / uprawnienia do plików usługi, również się to udaje.

Mój obecny problem to: a) jeśli konto użytkownika już istnieje, instalacja RPM kończy się niepowodzeniem, ponieważ useraddkończy się niepowodzeniem (ponieważ użytkownik już istnieje); oraz b) Nie wiem, jak rpm -e myserviceusunąć powiązanego użytkownika i grupę.

user-accounts services rpm

— Coderer
źródło

// Czy zastanawiasz się nad użyciem FPM?

— Nathan Basanese

18

Naprawdę rozwiązałem to samodzielnie, patrząc na inne specyfikacje RPM, które robiły podobne rzeczy. Jeśli chcesz tylko dodać użytkownika (warunkowo), skorzystaj z linku Ignacio. Ja to zrobiłem:

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

Zapewnia to, że RPM „czyści po sobie”, ale nadal zapewnia możliwość instalacji, nawet jeśli konto już istnieje.

— Coderer
źródło

13

Chociaż to odpowiada na pytanie, warto przeczytać notatkę w linku do łącza Fedory opublikowanym przez Ignacio o tym, dlaczego usunięcie użytkownika / grupy nie jest pożądane.

— CoverosGene

1

Występuje problem ponownego użycia identyfikatora UID i GID (gdy usunięty użytkownik ma najwyższy identyfikator UID / GID), co sprawia, że każde automatyczne użycie userdel jest złym pomysłem.

— Bruno9779,

1

W moim CentOS 6.7 usunąłem polecenie / usr / sbin / groupadd, ponieważ polecenie useradd utworzy samą grupę. Również useradd zakończy działanie z błędem, gdy grupa o tej samej nazwie już istnieje.

— Raffael

raport rpmlint „W: niebezpieczne-polecenie-w% postun userdel”, jeśli go używasz

— Rfraile

5

Każda z dwóch poprzednich odpowiedzi jest gotowa do produkcji, ponieważ metody te usuną użytkownika, jeśli pakiet zostanie zaktualizowany. Yum instaluje nowy pakiet, a następnie usuwa stary pakiet. To pozostawi cię bez użytkownika. Nie fajnie!

Zamiast tego użyj tej metody:

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

— Steven
źródło

4

Odpowiedź Coderera jest dobra, ale drugie polecenie wstępne wyświetla błąd w Centos 7. Grupa musi zostać określona.

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

Dodałem także przekierowanie do / dev / null, aby zignorować niechciane echa.

— Tabinol
źródło