Existem vários serviços que estão sendo executados em nossas máquinas, por exemplo, cassandra, datadog, etc.
Ocasionalmente, precisamos alterar a configuração e desejamos automatizar a propagação dos arquivos de configuração e reinicializações.
Usamos Jenkins para automatizar o fluxo de trabalho de nosso software aplicativo e estávamos pensando em usá-lo também para serviços. Não desejamos que o servidor em que o Jenkins é executado tenha acesso root remoto (ou mesmo sudo) ao servidor host.
Eu queria saber se poderíamos mudar com segurança o proprietário de /etc/cassandra para cassandra, /etc/datadog para dd-agent, etc, porque isso nos ajudaria a automatizar. (Na verdade, é recomendado que tais pastas/arquivosdevepertencer ao usuário apropriado e que ter root como proprietário é errado?)
Responder1
A ideia deste diretório é que o /etcdiretório contenha todosNo âmbito do sistemaconfiguração - oposta à configuração de cada usuário individual, que reside na maioria dos casos abaixo em $HOME/.configalgum lugar. Como a configuração de todo o sistema afeta todos os usuários, é correto que esses arquivos sejam propriedade do root.
Agora, eu não conheço o seu sistema, mas provavelmente você está executando o cassandra etc. uma vez por sistema e, portanto, provavelmente não precisa de um arquivo de configuração de usuário individual. Não vejo nenhuma armadilha em alterar a propriedade desses arquivos/subdiretórios, exceto que isso contradiz a maneira como foi projetado. (Contanto que você não altere a propriedade do /etcdiretório principal!)
Pessoalmente, eu configuraria um diretório de instância (provavelmente em sua pasta pessoal) e usaria a configuração armazenada lá - mas isso depende de você.
Responder2
Root não deve ser proprietário de arquivos de configuração etc. pertencentes a aplicativos. A solução elegante seria algo assim: o aplicativo datadog é executado pelo usuário datadog e os arquivos de configuração pertencem ao datadog e ao grupo datadog. Mas agora aparece Jenkins e precisa procurar/editar alguns arquivos em /etc/datadog, mas talvez não todos.
Então, criamos um novo grupo chamado "datadogjenkins" e tornamos AMBOS o datadog e o jenkins membros desse grupo. Em seguida, alteramos o proprietárioGROUP para os arquivos/pastas que Jenkins precisa ler/escrever/executar em nosso novo grupo.
Agora, tanto o datadog quanto o jenkins podem alcançar esses ativos. E nenhum deles precisa escalar privilégios para root. E podemos manter Jenkins fora do que ele não precisa ver, caso o Jenkins seja comprometido.
Espero que isso explique bem o suficiente.