| ADDUSER(8) | System Manager's Manual | ADDUSER(8) |
adduser, addgroup - Benutzer oder Gruppen im System hinzufügen oder verändern
adduser |
[--add-extra-groups] [--allow-all-names] [--allow-bad-names] [--comment Kommentar] [--conf Datei] [--debug] [--disabled-login] [--disabled-password] [--firstgid Kennung] [--firstuid Kennung] [--gid Kennung] [--home Verzeichnis] [--ingroup Gruppe] [--lastgid Kennung] [--lastuid Kennung] [--no-create-home] [--shell Shell] [--quiet] [--uid Kennung] [--verbose] [--stdoutmsglevel prio] [--stderrmsglevel prio] [--logmsglevel prio] Benutzer |
adduser |
--system [--comment Kommentar] [--conf Datei] [--debug] [--gid Kennung] [--group] [--home Verzeichnis] [--ingroup Gruppe] [--no-create-home] [--shell Shell] [--uid Kennung] [--quiet] [--verbose] [--stdoutmsglevel prio] [--stderrmsglevel prio] [--logmsglevel prio] Benutzer |
adduser |
--group [--conf Datei] [--debug] [--firstgid Kennung] [--gid Kennung] [--lastgid Kennung] [--quiet] [--verbose] [--stdoutmsglevel prio] [--stderrmsglevel prio] [--logmsglevel prio] group |
addgroup |
[--conf Datei] [--debug] [--firstgid Kennung] [--gid Kennung] [--lastgid Kennung] [--quiet] [--verbose] [--stdoutmsglevel prio] [--stderrmsglevel prio] [--logmsglevel prio] group |
addgroup |
--system [--gid Kennung] [--conf Datei] [--quiet] [--verbose] [--stdoutmsglevel prio] [--stderrmsglevel prio] [--logmsglevel prio] group |
adduser |
[--conf Datei] [--debug] [--quiet] [--verbose] [--stdoutmsglevel prio] [--stderrmsglevel prio] [--logmsglevel prio] Benutzer Gruppe |
adduser |
--help |
adduser |
--version |
Die Befehle adduser und addgroup fügen im System Benutzer und Gruppen unter Berücksichtigung der Befehlszeilen-Optionen und der Konfigurationsinformationen in /etc/adduser.conf hinzu. Sie sind Debian-spezifischere Oberflächen für die Programme useradd(8), groupadd(8) und usermod(8), die unabhängiger von Distributionen sind. adduser und addgroup(8) wählen standardmäßig UID- und GID-Werte, die den Debian-Richtlinien folgen, erstellen ein Home-Verzeichnis mit Gerüstkonfiguration, führen ein benutzerdefiniertes Skript aus und haben einige weitere Funktionalitäten.
adduser und addgroup sind als Schicht für Richtlinien gedacht. Sie erleichtern Paketbetreuern und lokalen Administratoren die Erstellung lokaler Systemkonten auf eine Art, wie Debian deren Erstellung erwartet. Sie übernehmen dabei die Last, sich an die möglicherweise ändernden Anforderungen der Debian-Richtlinien anzupassen. Im Besonderen benötigt adduser --system nur einen einzigen Aufruf in den Paketbetreuerskripten, keine zusätzlichen Wrapper, Fehlerunterdrückungen oder andere Hilfskonstrukte.
adduser respektiert die Unterscheidung zwischen dynamisch zugewiesenen Systembenutzern und -gruppen und dynamisch zugewiesenen Benutzerkonten, die in den Debian-Richtlinien, Kapitel 9.2.2 beschrieben ist.
Eine vollständige Liste und Beschreibungen aller Optionen finden Sie im Abschnitt OPTIONEN.
adduser und addgroup können in einem von fünf Modi betrieben werden:
Wird adduser ohne die Optionen --system oder --group und mit einem Argument, das keine Option ist, aufgerufen, richtet adduser einen regulären Benutzer ein. Dies ist ein dynamisch zugewiesenes Benutzerkonto im Sinne der Debian-Richtlinien. Im Kontext von adduser wird dies typischerweise als Nicht-Systembenutzer bezeichnet.
adduser wird die erste noch freie UID aus dem in der Konfigurationsdatei durch FIRST_UID und LAST_UID festgelegten Bereich auswählen. Der Bereich kann mit den Optionen --firstuid und --lastuid außer Kraft gesetzt werden. Schließlich kann die UID mit der Option --uid vollständig manuell gesetzt werden.
Standardmäßig erhält jeder Benutzer eine entsprechende Gruppe mit dem gleichen Namen. Dies wird typischerweise Benutzergruppen genannt und erlaubt die leichte Verwaltung von gruppenbeschreibbaren Verzeichnissen, indem die entsprechenden Benutzer in die neue Gruppe abgelegt, das Bit set-group-ID im Verzeichnis gesetzt und sichergestellt wird, dass alle Benutzer über die Umask 002 verfügen.
Für eine Benutzergruppe wird adduser die erste noch freie GID aus dem in der Konfigurationsdatei durch FIRST_GID und LAST_GID festgelegten Bereich auswählen. Der Bereich kann mit den Optionen --firstgid und --lastgid außer Kraft gesetzt werden. Schließlich kann die GID mit der Option --gid vollständig manuell gesetzt werden.
Die Wechselwirkung zwischen USERS_GID, USERS_GROUP und USERGROUPS wird im Detail in adduser.conf(5) beschrieben.
Die Voreinstellung für die primäre Gruppe des neuen Benutzers kann auf der Befehlszeile auch mit --gid und einer Gruppenkennung oder --ingroup und einem Gruppenamen außer Kraft gesetzt werden. Auch können Benutzer zu ergänzenden Gruppen hinzugefügt werden, die als EXTRA_GROUPS in der Konfigurationsdatei entweder durch Setzen von ADD_EXTRA_GROUPS auf 1 oder durch Angabe von --add-extra-groups auf der Befehlszeile angegeben wurden.
adduser kopiert Dateien aus /etc/skel in das Home-Verzeichnis und bittet um Eingaben für das Kommentarfeld und ein Passwort, falls sich diese Funktionen nicht aufgrund von Eingaben auf der Befehlszeile erübrigen.
UID, Kommentare, Home-Verzeichnis und die Shell können mit den Optionen UID_POOL und GID_POOL vorabbestimmt sein, siehe adduser.conf(5).
Wird adduser mit einem Argument, das keine Option ist, und der Option --system aufgerufen, dann wird adduser einen dynamisch zugewiesenen Systembenutzer, im Kontext des Pakets adduser oft als Systembenutzer abgekürzt, hinzufügen.
adduser wird die erste noch freie UID aus dem in der Konfigurationsdatei durch FIRST_SYSTEM_UID und LAST_SYSTEM_UID festgelegten Bereich auswählen. Dies kann mit der Option --uid außer Kraft gesetzt werden.
Standardmäßig wird Systembenutzern die Gruppe nogroup als primäre Gruppe zugeordnet. Um eine bereits bestehende Gruppe als primäre Gruppe zuzuordnen, nutzen Sie die Optionen --gid oder --ingroup. Falls die Option --group angegeben ist und eine identisch benannte Gruppe nicht bereits existiert, dann wird sie mit der gleichen Kennung erstellt.
Falls kein Home-Verzeichnis festgelegt ist, ist das Standard-Home-Verzeichnis für einen neuen Systembenutzer /nonexistent. Dieses Verzeichnis sollte niemals auf irgendeinem Debian-System existieren und adduser sollte es niemals automatisch erstellen.
Falls ein Home-Verzeichnis mit der Option --home festgelegt ist und das Verzeichnis noch nicht existiert (beispielsweise, weil das Paket Dateien in diesem Verzeichnis ausliefert), setzt adduser den Eigentümer ohne Rückmeldung nicht auf den neu erstellten Benutzer. Das Setzen des Eigentümers könnte eine Entscheidung des lokalen Administrators außer Kraft setzen und das Melden der Tatsache würde das Schweigen von adduser während der Paketinstallation brechen. Falls Sie adduser --home in Ihren Paketverwaltungsskripten verwenden, könnte ein explizites rekursives chown(1) für das Home-Verzeichnis nach dem Aufruf von adduser sinnvoll sein.
Wird nicht explizit eine Shell mit der Option --shell gesetzt, dann wird diese für den neuen Systembenutzer auf /usr/sbin/nologin gesetzt. adduser --system setzt kein Passwort für das neue Konto. Die Gerüstkonfigurationsdateien werden nicht kopiert.
Andere Optionen verhalten sich wie bei der Erstellung regulärer Benutzer. Die von UID_POOL und GID_POOL referenzierten Dateien werden ebenfalls berücksichtigt.
Wird adduser mit der Option --group und ohne die Option --system aufgerufen oder wird addgroup aufgerufen, wird eine Benutzergruppe hinzugefügt.
Eine dynamisch zugewiesene Systemgruppe wird oft im Kontext des Pakets adduser als Systemgruppe abgekürzt und wird erstellt, falls adduser --group oder addgroup mit der Option --system aufgerufen werden.
Es wird eine GID aus dem zugehörigen, in der Konfigurationsdatei für GIDs festgelegten Bereich (FIRST_GID, LAST_GID, FIRST_SYSTEM_GID, LAST_SYSTEM_GID) gewählt. Sie können diesen Mechanismus außer Kraft setzen, indem Sie die GID mit der Option --gid festlegen.
Für Nicht-Systemgruppen kann der in der Konfigurationsdatei festgelegte Bereich mit den Optionen --firstgid und --lastgid außer Kraft gesetzt werden.
Die Gruppe wird ohne Mitglieder erzeugt.
Wird adduser mit zwei Argumenten, die keine Optionen sind, aufgerufen, wird ein bestehender Benutzer zu einer bestehenden Gruppe hinzugefügt.
Verschiedene Modi von adduser erlauben verschiedene Optionen. Falls keine gültigen Modi für eine Option aufgeführt sind, wird sie in allen Modi akzeptiert.
Aus historischen Gründen können für bestimmte Aktionen Kurzversionen der Optionen existieren. Sie werden weiterhin unterstützt, aber aus der Dokumentation entfernt. Benutzern wird empfohlen, auf die lange Version der Optionen umzusteigen.
Historischerweise erzwangen adduser(8) und addgroup(8) Konformität zu IEEE Std 1.003,1-2001. Damit sind nur die folgenden Zeichen in Gruppen- und Benutzernamen erlaubt: Buchstaben, Ziffern, Unterstriche, Punkte, Klammeraffen (@) und Bindestriche. Der Name darf nicht mit einem Bindestrich oder @ beginnen. Das »$«-Zeichen wird am Ende von Benutzernamen erlaubt, um typische Samba-Maschinenkonten zu erlauben.
Die Standardeinstellungen für NAME_REGEX und SYS_NAME_REGEX erlauben, dass Benutzernamen Buchstaben und Ziffern enthalten, sowie den Gedanken- (-) und Unterstrich (_). Der Name muss mit einem Buchstaben (oder einem Unterstrich für Systembenutzer) beginnen.
Die über die Option --allow-all-names verfügbare, am wenigsten beschränkende Richtlinie macht einfach die gleichen Prüfungen wie useradd(8). Bitte beachten Sie, dass die Prüfungen von useradd in Debian 13 deutlich restriktiver geworden sind.
Durch Ändern des Standardverhaltens können verwirrende oder irreführende Namen erstellt werden; seien Sie vorsichtig.
Adduser verwendet umfangreiche und konfigurierbare Protokollierung, um seine Ausführlichkeit an die Bedürfnisse des Systemadministrators anzupassen.
Jede Meldung, die adduser ausgibt, hat von den Autoren einen Prioritätswert zugewiesen bekommen. Diese Priorität kann zur Laufzeit nicht geändert werden. Verfügbare Prioritätswerte sind crit, error, warning, info, debug und trace.
Falls Sie eine Meldung mit einer falschen Priorität finden, reichen Sie bitte (auf Englisch) einen Fehlerbericht ein.
Jedes Mal, wenn eine Meldung erzeugt wird, entscheidet der Code, ob die Meldung auf der Standardausgabe, der Standardfehlerausgabe oder dem Syslog ausgegeben werden soll. Dies wird hauptsächlich und unabhängig voneinander durch die Konfigurationseinstellungen STDOUTMSGLEVEL, STDERRMSGLEVEL und LOGMSGLEVEL gesteuert. Zu Testzwecken können diese Einstellungen auf der Befehlszeile außer Kraft gesetzt werden.
Nur Meldungen mit einer Priorität höher oder gleich der entsprechenden Meldungsstufe werden in das entsprechende Ausgabemedium protokolliert. Eine Meldung, die auf die Standardfehlerausgabe geschrieben wurde, wird nicht ein zweites Mal auf die Standardausgabe geschrieben.
Oder es war einer von vielen anderen noch undokumentierten Gründen, die dann auf der Konsole ausgegeben werden. Sie können dann überlegen, ob Sie die Protokollierstufe erhöhen, damit adduser mehr Informationen ausgibt.
adduser benötigt Systemadministratorberechtigungen. Es bietet über die Befehlszeilenoption --conf die Möglichkeit, verschiedene Konfigurationsdateien zu verwenden. Verwenden Sie nicht sudo(8) oder ähnliche Befehle, um Teilprivilegien an adduser mit beschränkten Befehlszeilenparametern zu geben. Dies kann leicht umgangen werden und könnte Benutzern erlauben, beliebige Konten zu erstellen. Falls Sie dies erreichen wollen, entwickeln Sie Ihr eigenes Skript, das adduser kapselt, und vergeben Sie Privilegien, um dieses Skript aufzurufen.
Unglücklicherweise wird der Begriff Systemkonto unter Debian in zwei Bedeutungen verwandt. In beiden Bedeutungen ist es ein Konto für das tatsächliche Debian-System, das sich von einem Anwendungskonto unterscheidet, das in der Benutzerdatenbank einer beliebigen, unter Debian betriebenen Anwendung vorhanden ist. Ein Systemkonto in dieser Definition verfügt über die Möglichkeit, sich am tatsächlichen System anzumelden, hat eine UID, kann Mitglied in Systemgruppen sein, kann Dateien und Prozesse besitzen. Im Gegensatz dazu unterscheiden die Debian-Richtlinien in Kapitel 9.2.2 zwischen dynamisch zugewiesenen Systembenutzern und -gruppen und dynamisch zugewiesenen Benutzerkonten. Beides sind Sonderfälle eines Systemkontos. Die beiden Begriffswelten dürfen nicht durcheinander gebracht werden. Da adduser und deluser(8) niemals Anwendungskonten adressieren und sich alles in diesem Paket um Systemkonten dreht, ist die Verwendung des Ausdrucks Benutzerkonto und Systemkonto in dem Kontext dieses Paketes tatsächlich eindeutig. Zur Klarheit verwendet dieses Dokument die Definition lokales Systemkonto oder lokale Systemgruppe, falls die Unterscheidung zu Anwendungskonten oder Konten, die durch Verzeichnisdienste verwaltet werden, benötigt wird.
Früher, seit den 1990er Jahren, hatte adduser die Vision, die universelle Oberfläche zum Erstellen und Entfernen normaler und Systemkonten für die verschiedenen Verzeichnisdienste zu sein. Diese Vision wurde 2022 aufgegeben. Der Grund hierfür ist unter anderem, dass in der Praxis ein kleines Serversystem sowieso keinen Schreibzugriff auf einen firmenweiten Verzeichnisdienst hat und dass lokal installierte Pakete schwierig mit zentral gesteuerten Systemkonten zu verwalten sind, dass firmenweite Verzeichnisdienste über zentral gesteuerte Systemkonten verfügen, dass firmenweite Verzeichnisdienste sowieso ihre eigene Verwaltungsprozesse haben und dass die Personalstärke des adduser-Teams wahrscheinlich niemals so groß sein wird, um die Unterstützung für die Vielzahl an Verzeichnisdiensten, die das benötigen, zu schreiben und zu betreuen.
adduser beschränkt sich darauf, eine Richtlinienoberfläche für die Verwaltung lokaler Systemkonten zu sein. Dabei werden die Werkzeuge des Pakets passwd für die eigentliche Arbeit verwandt.
Inkonsistente Verwendung von Begriffen rund um den Ausdruck Systemkonto in der Dokumentation und den Programmen ist ein Fehler. Bitte berichten Sie dies, um uns zu ermöglichen, die Dokumentation zu verbessern.
adduser berücksichtigt besonders die direkte Verwendbarkeit in Debian-Betreuerskripten ohne fallweise Wrapper, Fehlerunterdrückung und anderem zusätzlichem Rüstwerk. Das einzige, was im Paketbetreuerskript programmiert werden sollte, ist eine Prüfung auf das Vorhandensein des Programms im Skript postrm. Die Betreuer von adduser betrachten die Notwendigkeit für zusätzliches Rüstwerk als einen Fehler und ermutigen ihre Mit-Debian-Paketbetreuer, in diesem Fall Fehlerberichte gegen das Paket adduser einzureichen.
adduser.conf(5), deluser(8), groupadd(8), useradd(8), usermod(8), /usr/share/doc/base-passwd/users-and-groups.html auf jedem Debian-System, Debian-Richtlinien 9.2.2, RFC8264 »PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols«, RFC8265 »PRECIS Representing Usernames and Passwords«, https://wiki.debian.org/UserAccounts.
| Debian GNU/Linux |