Technische Schulden
Aus den folgenden Gründen ist es viel einfacher , dieses Problem frühzeitig anzugehen, um eine Anhäufung von technischen Schulden zu vermeiden . Auch wenn Sie sich bereits in dieser Situation befinden, ist es wahrscheinlich besser, sich in naher Zukunft darum zu kümmern, als es weiter aufbauen zu lassen.
vernetzte Dateisysteme
Diese Frage scheint sich auf den engen Bereich der Übertragung von Dateien zwischen Computern mit lokalen Dateisystemen zu konzentrieren, der maschinenspezifische Besitzverhältnisse zulässt.
Überlegungen zum Netzwerk-Dateisystem sind mit Sicherheit der größte Grund, um Ihre UID / GID-Zuordnungen synchron zu halten, da Sie normalerweise das "Erreichte" aus dem Fenster werfen können, das Sie beim Betreten des Bildes erwähnt haben. Sicher, Sie könnten nicht vernetzte Dateisysteme haben zwischen diesen Hosts gemeinsam jetzt ... aber was ist die Zukunft? Können Sie ehrlich sagen, dass es niemals einen Anwendungsfall für ein vernetztes Dateisystem geben wird, das zwischen Ihren aktuellen oder zukünftig erstellten Hosts eingeführt wird? Es ist nicht sehr vorausschauend, etwas anderes anzunehmen.
Es sei angenommen , dass /homeein Netzwerk - Dateisystem ist geteilt zwischen host1und host2in den folgenden Beispielen.
- Nicht zustimmende Berechtigungen :
/home/user1Jeder Benutzer auf jedem System ist im Besitz eines anderen Benutzers. Dies verhindert, dass ein Benutzer systemübergreifend auf sein Basisverzeichnis zugreifen oder dieses ändern kann.
- chown wars : Es kommt häufig vor, dass ein Benutzer ein Ticket sendet, in dem er darum bittet, dass seine Home-Verzeichnis-Berechtigungen auf einem bestimmten System festgelegt werden. Das Beheben dieses Problems
host2unterbricht die Berechtigungen für host1. Manchmal müssen mehrere dieser Tickets bearbeitet werden, bevor jemand zurücktritt und feststellt, dass ein Tauziehen im Spiel ist. Die einzige Lösung besteht darin, die nicht übereinstimmenden ID-Zuordnungen zu beheben. Was dazu führt...
- UID / GID-Neuausgleich : Die Komplexität der Korrektur von IDs steigt später exponentiell um die Anzahl der Neuzuordnungen, die erforderlich sind, um einen einzelnen Benutzer auf mehreren Computern zu korrigieren. (
user1hat die ID von user2, hat aber user2die ID von user17... und das ist nur das erste System im Cluster.) Je länger Sie auf die Behebung des Problems warten, desto komplexer können diese Ketten werden, die häufig Ausfallzeiten von Anwendungen auf mehreren Servern erfordern um die Dinge richtig in Einklang zu bringen.
- Sicherheitsprobleme :
user2auf host2die gleiche UID als user1auf host1, so dass sie zu schreiben , /home/user1auf host2ohne das Wissen user1. Diese Änderungen werden dann host1mit den Berechtigungen von ausgewertet user1. Was könnte möglicherweise falsch laufen? (Wenn user1es sich um einen App-Benutzer handelt, erkennt jemand in dev , dass er beschreibbar ist, und nimmt Änderungen vor. Dies ist eine bewährte Tatsache.)
Es gibt andere Szenarien, und dies sind nur Beispiele für die häufigsten.
Namen sind nicht immer eine Option
Alle Skripts oder Konfigurationsdateien, die mit numerischen IDs geschrieben wurden, sind in Ihrer Umgebung von Natur aus nicht mehr portierbar. Im Allgemeinen kein Problem, da die meisten Leute diese nicht fest codieren, es sei denn, sie müssen dies unbedingt tun ... aber manchmal gibt Ihnen das Tool, mit dem Sie arbeiten, in dieser Angelegenheit keine Wahl. In diesen Szenarien müssen Sie n verschiedene Versionen des Skripts oder der Konfigurationsdatei verwalten.
Beispiel: pam_succeed_ifermöglicht es Ihnen , Felder zu verwenden user, uidund gid... eine „Gruppe“ Option ist auffällig abwesend. Wenn Sie in die Lage versetzt würden, dass mehrere Systeme eine Form der gruppenbasierten Zugriffsbeschränkung implementieren, hätten Sie n verschiedene Variationen der PAM-Konfigurationen. (oder mindestens eine einzelne GID, bei der Sie Kollisionen vermeiden müssen)
zentrale Verwaltung
Die Antwort von natxo hat dies ziemlich gut abgedeckt.