dívida técnica
Pelas razões abaixo, é muito mais simples resolver esse problema desde o início, para evitar o acúmulo de dívida técnica . Mesmo se você já se encontra nessa situação, provavelmente é melhor lidar com isso em um futuro próximo do que deixá-lo continuar se desenvolvendo.
sistemas de arquivos em rede
Essa pergunta parece estar focada no escopo restrito da transferência de arquivos entre máquinas com sistemas de arquivos locais, o que permite estados de propriedade específicos da máquina.
As considerações sobre o sistema de arquivos em rede são facilmente o maior argumento para tentar manter seus mapeamentos UID / GID sincronizados, porque geralmente você pode lançar o "feito de outra maneira" que você mencionou pela janela no momento em que entram na imagem. Claro, você pode não ter sistemas de arquivos em rede compartilhados entre esses hosts agora ... mas e o futuro? Você pode dizer honestamente que nunca haverá um caso de uso para um sistema de arquivos em rede sendo introduzido entre os hosts atuais ou os hosts criados no futuro? Não é muito antecipado assumir o contrário.
Suponha que /home
seja um sistema de arquivos em rede compartilhado entre host1
e host2
nos exemplos a seguir.
- Permissões discordantes :
/home/user1
pertence a um usuário diferente em cada sistema. Isso impede que um usuário possa acessar ou modificar consistentemente seu diretório pessoal nos sistemas.
- chown wars : é muito comum que um usuário envie um ticket solicitando que suas permissões de diretório inicial sejam fixadas em um sistema específico. A correção desse problema
host2
interrompe as permissões host1
. Às vezes, pode levar vários desses tíquetes para serem trabalhados antes que alguém dê um passo para trás e perceba que um cabo de guerra está em jogo. A única solução é corrigir os mapeamentos de ID discordantes. O que leva a...
- Reequilíbrio UID / GID : a complexidade da correção de IDs aumenta posteriormente exponencialmente pelo número de remapeamentos envolvidos para corrigir um único usuário em várias máquinas. (
user1
tem o ID de user2
, mas user2
tem o ID de user17
... e esse é apenas o primeiro sistema no cluster). Quanto mais você esperar para corrigir o problema, mais complexas essas cadeias podem se tornar, geralmente exigindo o tempo de inatividade de aplicativos em vários servidores para que as coisas sejam sincronizadas corretamente.
- Problemas de segurança :
user2
on host2
tem o mesmo UID que user1
on host1
, permitindo que eles gravem /home/user1
on host2
sem o conhecimento de user1
. Essas alterações são avaliadas host1
com as permissões de user1
. O que poderia dar errado? (se user1
é um usuário do aplicativo, alguém em dev vai descobrir que é gravável e vai fazer alterações. este é um fato comprovado tempo.)
Existem outros cenários, e esses são apenas exemplos dos mais comuns.
nomes nem sempre são uma opção
Quaisquer scripts ou arquivos de configuração gravados com IDs numéricos tornam-se inerentemente não portáveis em seu ambiente. Geralmente, isso não é um problema, porque a maioria das pessoas não codifica essas informações a menos que seja absolutamente necessário ... mas às vezes a ferramenta com a qual você está trabalhando não oferece uma opção. Nesses cenários, você é forçado a manter n versões diferentes do script ou arquivo de configuração.
Exemplo: pam_succeed_if
permite que você use campos de user
, uid
e gid
... uma opção de "grupo" é conspicuamente ausente. Se você fosse colocado em uma posição em que vários sistemas deveriam implementar alguma forma de restrição de acesso baseada em grupo, você teria n variações diferentes das configurações do PAM. (ou pelo menos um único GID no qual você precisa evitar colisões)
gerenciamento centralizado
A resposta da natxo cobriu isso muito bem.