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 /homeseja um sistema de arquivos em rede compartilhado entre host1e host2nos exemplos a seguir.
- Permissões discordantes :
/home/user1pertence 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
host2interrompe 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. (
user1tem o ID de user2, mas user2tem 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 :
user2on host2tem o mesmo UID que user1on host1, permitindo que eles gravem /home/user1on host2sem o conhecimento de user1. Essas alterações são avaliadas host1com 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_ifpermite que você use campos de user, uide 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.