debito tecnico
Per i motivi che seguono, è molto più semplice affrontare questo problema in anticipo per evitare l'accumulo di debito tecnico . Anche se ti trovi già in questa situazione, è probabilmente meglio affrontarlo nel prossimo futuro piuttosto che lasciarlo continuare a costruire.
filesystem in rete
Questa domanda sembra focalizzata sullo stretto ambito del trasferimento di file tra macchine con filesystem locali, che consente stati di proprietà specifici della macchina.
Le considerazioni sul filesystem in rete sono facilmente il caso più importante per cercare di mantenere sincronizzati i mapping UID / GID, perché di solito puoi lanciare quel "risultato altrimenti" che hai citato fuori dalla finestra nel momento in cui entrano nell'immagine. Certo, potresti non avere filesystem in rete condivisi tra questi host in questo momento ... ma per quanto riguarda il futuro? Puoi dire onestamente che non ci sarà mai un caso d'uso per l'introduzione di un filesystem in rete tra i tuoi host attuali o host creati in futuro? Non è molto lungimirante pensare di assumere il contrario.
Supponiamo che /homesia un filesystem di rete condiviso tra host1e host2nei seguenti esempi.
- Autorizzazioni in disaccordo :
/home/user1è di proprietà di un utente diverso su ciascun sistema. Ciò impedisce a un utente di accedere o modificare in modo coerente la propria directory principale tra i sistemi.
- Chown Wars : è molto comune per un utente inviare un ticket che richiede che le autorizzazioni della propria directory home vengano riparate su un sistema specifico. Risolvendo questo problema si
host2rompono le autorizzazioni host1. A volte possono essere necessari diversi di questi biglietti per lavorare prima che qualcuno faccia un passo indietro e si renda conto che è in gioco un tiro alla fune. L'unica soluzione è correggere i mapping degli ID in disaccordo. Che conduce a...
- Inferno di ribilanciamento UID / GID : la complessità della correzione degli ID successivamente aumenta in modo esponenziale del numero di rimappature coinvolti per correggere un singolo utente su più macchine. (
user1ha l'ID di user2, ma user2ha l'ID di user17... e questo è solo il primo sistema nel cluster) Quanto più si aspetta per risolvere il problema, tanto più complesse possono diventare queste catene, che spesso richiedono i tempi di inattività delle applicazioni su più server per sincronizzare correttamente le cose.
- Problemi di sicurezza :
user2on host2ha lo stesso UID di user1on host1, permettendo loro di scrivere /home/user1su host2senza la conoscenza di user1. Queste modifiche vengono quindi valutate host1con le autorizzazioni di user1. Che cosa potrebbe andare storto? (se user1è un utente di app, qualcuno in dev sarà scoprire che è scrivibile e si apportare le modifiche. questo è un fatto dimostrato più.)
Esistono altri scenari, e questi sono solo esempi di quelli più comuni.
i nomi non sono sempre un'opzione
Qualsiasi script o file di configurazione scritto su ID numerici diventa intrinsecamente non portabile all'interno del tuo ambiente. Generalmente non è un problema perché la maggior parte delle persone non li codifica a meno che non siano assolutamente obbligati a ... ma a volte lo strumento con cui stai lavorando non ti dà una scelta in merito. In questi scenari, sei costretto a mantenere n diverse versioni dello script o del file di configurazione.
Esempio: pam_succeed_ifconsente di utilizzare i campi di user, uide gid... un'opzione di "gruppo" è assente. Se ti fossi messo in una posizione in cui ci si aspettava che più sistemi implementassero una qualche forma di restrizione di accesso basata su gruppi, avresti n diverse varianti delle configurazioni PAM. (o almeno un singolo GID sul quale devi evitare le collisioni)
gestione centralizzata
La risposta di Natxo ha coperto abbastanza bene.