Gerenciando contas de serviço em uma especificação RPM

16

Recebi uma especificação RPM parcialmente completa para um serviço que estamos escrevendo. Chega ao ponto de criar os diretórios necessários, copiar arquivos, definir permissões etc., mas não cria a conta de sistema necessária na qual o serviço será executado. Foi-me dito que é melhor para o RPM cuidar disso, então eu adicionei

Requires(pre): /usr/sbin/useradd

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

Isso consegue criar a conta de usuário (e o grupo associado), e, posteriormente, quando ele tenta definir a propriedade / permissões nos arquivos do serviço, também obtém êxito.

Meu problema atual é: a) se a conta do usuário já existe, a instalação do RPM falha porque useraddfalha (porque o usuário já existe); e b) não sei como rpm -e myserviceremover também o usuário e o grupo associados.

user-accounts services rpm

— Coderer
fonte

//, você consideraria usar o FPM?

— Nathan Basanese

18

Na verdade, eu resolvi isso de forma independente, observando outras especificações de RPM que faziam coisas semelhantes. Se você quiser apenas adicionar um usuário (condicionalmente), use o link do Ignacio. Eu fiz isso:

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

Isso garante que o RPM "seja limpo depois de si mesmo", mas ainda permita a instalação, mesmo que a conta já exista.

— Coderer
fonte

13

Embora isso responde à pergunta, vale a pena ler a nota na ligação Fedora ligação postado por Ignacio sobre o porquê de remover o usuário / grupo não é desejável.

— CoverosGene

1

Há um problema de reutilização de UID e GID (quando o usuário excluído tem o UID / GID mais alto), que faz com que qualquer uso automatizado do userdel seja uma má ideia.

— Bruno9779

1

No meu CentOS 6.7, removi o comando / usr / sbin / groupadd, pois o comando useradd criará o próprio grupo. Além disso, o useradd será encerrado com um erro quando já existir um grupo com o mesmo nome.

— Raffael

relatório rpmlint "W:-in-perigoso-comando userdel% postun" se você usá-lo

— Rfraile

5

Qualquer uma das duas respostas anteriores está pronta para produção, pois esses métodos excluirão o usuário se o pacote for atualizado. O Yum instala o novo pacote e remove o pacote antigo. Isso deixará você sem um usuário. Não é legal!

Use este método:

%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

A resposta do Coderer é boa, mas o segundo pré-comando me dá um erro no Centos 7. O grupo deve ser especificado.

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

Eu adicionei também redirecionar para / dev / null para ignorar ecos indesejados.

— Tabinol
fonte