Eu apenas criei o mysql e corri para um problema estranho em que o gid para o grupo mysql no dev difere da produção. Aparentemente na produção eu tenho um usuário que não existe no ambiente dev e atualmente está reivindicando o gid que eu gostaria de usar para o grupo mysql.
Minha pergunta é: qual é a melhor abordagem para garantir que os usuários / grupos se alinhem independentemente do ambiente? Eu li alguns artigos onde é prática comum para iniciar uid / gid @ 1000. Se eu forçar esta prática e alterar o uid / gid existente, isso vai destruir meus servidores?
Eu também estava pensando em alterar o código do usuário que está reivindicando o gid que gostaria de usar, mas queria ver se havia uma prática recomendada para resolver essa situação.
- Atualização -
Ugh, posso dizer que é uma segunda-feira. Não é o gid que está colidindo, é uid:
class user::mysql inherits user {
include group::logger
include group::mysql
user { 'mysql':
gid => 'mysql',
groups => [ 'logger' ],
managehome => false,
membership => 'inclusive',
require => Class['group::mysql'],
shell => '/sbin/nologin',
uid => '498'
}
Class['group::logger']->Class['user::mysql']
}
As questões acima mencionadas ainda são relevantes:
"Qual é a melhor abordagem para garantir a linha de usuários / grupos, independentemente do ambiente?"
"Se eu forçar essa prática e alterar o uid / gid existente, isso destruirá meus servidores?"
Meu palpite é que você está fazendo algo parecido com
group => 500,
Onde 500 é o id do grupo do mysql? Bem, se você não se importa que o id do grupo seja um erro, então use o nome
group => "mysql",
EDITAR
O mesmo vale para o uid .. se você não especificar um para o usuário, o SO escolherá um para você. Então, se você não se importa com a combinação do uid, remova a linha uid
Tags user-management puppet centos