Com sysvinit , uma entrada sudoers como essa seria suficiente:
%webteam cms051=/sbin/service httpd *
Isso permitiria comandos como:
sudo service httpd status sudo service httpd restart Agora, com systemd , o nome do serviço é o argumento final. Ou seja, o reinício do serviço seria feito com:
systemctl restart httpd.service
Naturalmente, achei que definir o comando como systemctl * httpd.service funcionaria, mas isso permitiria algo como systemctl restart puppet.service httpd.service , que não é o efeito desejado.
Com isso sendo considerado, qual seria a melhor maneira de permitir que usuários não-root controlem um serviço system.d ? Isso não precisa ser sudoers ; talvez uma alteração de permissão de arquivo possa ser suficiente?
Basta adicionar todos os comandos necessários a sudoers separadamente:
%webteam cms051=/usr/bin/systemctl restart httpd.service
%webteam cms051=/usr/bin/systemctl stop httpd.service
%webteam cms051=/usr/bin/systemctl start httpd.service
%webteam cms051=/usr/bin/systemctl status httpd.service
A resposta do @jofel foi exatamente o que eu precisava para ter uma configuração funcional. Espero que mais alguém tropeça nessa questão. Eu precisava de uma maneira de ter o capistrano de reiniciar meu aplicativo Ruby após a implementação da minha máquina local. Isso significa que eu precisei de acesso sem senha para reiniciar systemd services. É isso que eu tenho e funciona maravilhosamente!
Observação : meu usuário e grupo são chamados de deployer
Coloque o código em um arquivo personalizado aqui: /etc/sudoers.d/deployer
Código:
%deployer ALL= NOPASSWD: /bin/systemctl start my_app
%deployer ALL= NOPASSWD: /bin/systemctl stop my_app
%deployer ALL= NOPASSWD: /bin/systemctl restart my_app
É mais seguro listá-las conforme jofel sugere.
Se eu quisesse permitir que alguém usasse um subconjunto limitado das habilidades de um comando, eu não confiaria em curingas em uma linha sudoers para fazê-lo. Mesmo que a linguagem fosse mais expressiva do que globals de conchas, há casos demais para acompanhar.
A linha " service httpd * " é relativamente segura porque (verifique isso :) service tem apenas um sinalizador útil ( --status-all ) que não faz nada particularmente sensível, e ( verifique isso também :) /etc/init.d/httpd aceitará apenas as linhas de comando que você deseja permitir.
Se houver tantas combinações que listá-las torna-se estranho, provavelmente você deve questionar o que está fazendo. Mas você pode dar a eles acesso a um script de ajuda cuidadosamente escrito que executa o comando para eles (parecido com /etc/init.d/http ). Mesmo nesse caso, você deve ser o mais preciso e explícito possível para listar exatamente quais comandos e opções são permitidos e não passar nenhuma entrada do usuário diretamente para o comando de destino.
Crie um alias de comando com os comandos que você deseja que eles tenham acesso. Em seguida, atribua o grupo a esse alias de comando:
Cmnd_Alias APACHE-SVC = /usr/bin/systemctl stop httpd, /usr/bin/systemctl start httpd, /usr/bin/systemctl restart httpd
%webteam ALL=APACHE-SVC
Também é uma boa prática colocar quaisquer edições em seu /etc/sudoers.d/filename em vez de editar diretamente o arquivo sudoers. Certifique-se de apontar para o seu .d / nome de arquivo nos sudoers, o que a maioria das novas distribuições faz de qualquer maneira. Colocar essas duas linhas em seus sudoers deve funcionar:
## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
#includedir /etc/sudoers.d
Nota: Esse # na frente do includedir não é um comentário. Deve permanecer.
Tags sudo services systemd rhel not-root-user