Benutzerverwaltung unter Linux/Unix
Wenn es um die Benutzerverwaltung unter Unix/Linux geht, würde ich die Welt in zwei Lager einteilen:
Die eine Hälfte verplant die UID/GID schön in Blöcken. 0-1000 Systemaccounts, 1001-5000 Mitarbeiter und Externe fangen bei 55000 an. Genauso sieht es bei den GIDs aus. Der anderen Hälfte ist das meiste davon schnurz egal. Ok, die Systemaccounts sollte man frei lassen, aber wenn intressiert schon die UID/GID, hauptsache sie ist überall gleich.
Zu welcher Hälfte gehörst Du und warum?
Ich gehöre zu letzterer, aus Unwissenheit.
Erstere Gruppe, weil es auch für andere nachvollziehbar sein muss.
letzterer, weil dies mein privater pc ist, und da eh kein anderer nutzer ausser welchen zum testen drauf sind. aber gut zu wissen, dass es in der arbeitswelt so eine einteilung gibt – muss ich mir direkt mal merken
Zur ersteren und ich gehe sogar noch weiter, in dem ich zwischen leitenden und normalen Mitarbeitern unterscheide.
Die Erklärung dafür ist folgende.
Ich habe ein generationsbasierendes Sicherungssystem. D.h. ich kann für einen gewissen Zeitraum den Datenbestand eines bestimmten Tages zurückholen.
Aber im Laufe der Jahre habe ich die Erfahrung gemacht, daß Chefs in der Regel relativ wenige Daten produzieren. Dafür aber im Schnitt weniger Ahnung von Computern haben. Deshalb hebe ich von ihnen vergleichsweise mehr Generationen auf als von anderen Mitarbeitern. Denen fällt in der Regel auch schneller auf, wenn einmal was daneben gegangen ist und sie haben weniger Hemmungen nach Hilfe zu schreien.
Im Gegenzug werden die Generationen der normalen MItarbeiter nach einiger Zeit ausgedünnt um die Gesamtdatenmenge im Rahmen zu halten.
Aber einfach über die Namen der User wäre das nicht wartbar. Durch die UID-Range geht es aber ganz einfach.
Und bevor sich jetzt jemand wundert, ich rede hier von knapp 500 Usern.
Und die dritte hälfte schert schert sich nicht mal drum dass die IDs nicht überall gleich sind oder nicht wiederverwendet werden. Die kommen wohl aus dem MS Lager und haben keine Ahnung…
Ich gehörte bisher aus Unwissenheit zu letzterer.
Da demnächst ein Umziehen/Zusammenfügen zweier Systeme/User-DBs ansteht versuche ich gerade mit Mühen den Sprung in die erste Hälfte zu schaffen :-)
Ich gehöre zu der Fraktion die sich keine Gedanken um UIDs/GIDs machen WILL :-) Die UID/GID sind für mich nur ein Mittel zum Zweck. Und zwar für die Rechverwaltung. Wenn man ein zentralisiertes Benutzermanagement aufsetzt welches z.B. auf MS DS basiert hat man eh kaum noch Einfluss auf die Vergabe von IDs.
Obwohl ich ja ehrlich gesagt sagen muss dass ich die Argumente von Sascha Vogt sehr gut nachvollziehen kann. Die Dinge die er anführt sind auch nicht außer acht zu lassen. Mich persönlich interessiert an den ID-Vergaben eher die automatisierbarkeit. Man kann durch “Ranges” Benutzergruppen eher durch Scripte trennen bzw. verarbeiten als wenn man das “Chaos-System” nutzt.
Wenn man jedoch sowieso überall eine strikte Trennung von Benutzer- und Rollenaccounts hat dann sollte das auch wieder egal sein.
Von daher lebe ich lieber in Welt Nr.2 und gebe mich möglichst wenig mit IDs ab.
zur ersten Fraktion, damit es fuer mich und andere uebersichtlicher ist!
Ab einer gewissen Größe geht es nur mit dem Chaos-System. Alles andere ist nur für Leute mit viel, viel Zeit oder überzogener deutscher Gründlichkeit. Schon der Aufwand , zusätzlich noch eine Tabelle zu pflegen mit allen ID/GIDs ist nicht gerechtfertigt. Der Server soll meine Arbeit machen, nicht ich seine.
Wir haben im bytecamp eine Abstraktions-Schicht drübergelegt, müssen uns um die numerischen UID/GID also nicht mehr kümmern. Jeder Kunde/Reseller gehört auf den Webservern der gleichen Gruppe an und kann mehrere Accounts haben. Für die Gruppen ist nur Quota aktiviert, für die User Quota und auch ACLs.
Ich zähle zur ersten Hälfte. Wir haben wenige Accounts auf den Systemen und nur in extremen Ausnahmefällen externe. Dennoch sind die vorhandenen aus Konsistenzgründen festgelegt. In unseren Fall – kleines Team, vergleichweise hohe Anzahl Server – ist das sinnvoll und durchführbar.
@Dirk Deimeke: Warum reicht eine UID/GID nicht für die Einordnung aus?
@Sascha Vogt: Wenn man UIDs einteilt, schaffte man eine Kategorisierung, die man auch mit Gruppen erledigen könnte. Warum das doppeln?
Meistens ist es so, dass in Unternehmen Personalnummern verteilt werden, wenn man sich daraus jetzt ein UID/GID-Schema bastelt, kann jeder auf Anhieb sagen, welcher User welche ID bekommen hat.
Ausserdem kann man auf Anhieb sagen, ob ein realer User oder ein Systemprozess an irgendwas beteiligt war.
zur letzten Gruppe. Es arbeitet nur einer an meinen Systemen und das bin ich :)
Nummern sollten nie eine Bedeutung haben. Ausserdem ist das als Ordnungskriterium viel zu unflexibel, da eindimensional. Und: Will man die uid auch aendern, wenn aus einem Indianer ein Häuptling geworden ist ;) Irgendwann passt die UID kaum noch. User und Gruppen in den LDAP, Klassifizierung der User ueber Gruppen.
Definitiv zweite Gruppe.
Da fehlt mir doch Kategorie 3
root ohne ssh , deshalb ein Admin-Login-Account für su per ssh.
Alle andreren User kriegen eh als shell /bin/false :)
nix fuer ungut ;)