1) Einleitung

mod_sql ist ein Authentisierung und Log Modul für ProFTPD.

Es beinhaltet ein Frontend Modul (mod_sql) und ein Backend Modul, das Datenbank spezifisch ist, wie z.B. mod_sql_mysql oder mod_sql_postgres. mod_sql überläßt hierbei das Datenbank Handling dem Backend

mod_sql liegt dem ProFTPD Tarball bei, es muss jedoch explizit einkompiliert werden.

2) Wie benutze ich ProFTPD mit mod_sql ?

Um ProFTPD mit dem mod_sql zu kompilieren, starte "configure" mit folgenden Parametern (als Beispiel):

Bei Verwendung von mySQL:

./configure --with-modules=mod_sql:mod_sql_mysql

Bei Verwendung von Progres:

./configure --with-modules=mod_sql:mod_sql_postgres

Ausserdem kann es notwendig sein, die Pfader der Datenbank spezifische Libraries und Header Files mit anzugeben.

Bei Verwendung von mySQL:

./configure --with-modules=mod_sql:mod_sql_mysql --with-includes=/usr/local/include --with-libraries=/usr/local/lib/mysql

Bei Verwendung von Progres:

./configure --with-modules=mod_sql:mod_sql_postgres --with-includes=/usr/local/include --with-libraries=/usr/local/lib

3) Wie konfiguriere ich meine SQL Datenbank für mod_sql ?

Gehen wir einmal davon aus, daß Du weisst, wie Du Deine Datenbank benutzen musst. Als Minimum, muss es mod_sql möglich sein, eine Tabelle mit zwei Feldern (userid und passwd) anzusprechen. Für eine komplette Funktionalität ist es notwendig, mehr Felder anzusprechen, inklusive einer weiteren Tabelle für die Gruppeneinträge.

Die folgende Tabellenbeschreibung ist wie folgt aufgebaut:

• 'COLUMN' steht für die Feld Bezeichnung
• 'TYPE' Feldtyp (Text oder numerisch)
• 'R' notwendig
• 'DUP' Doppelte Einträge sind erlaubt
• 'NULL?' NULL ist erlaubt
• 'USE' Erklärung

USERTABLE (muss vorhanden sein)

GROUPTABLE:

Für vollständige Funktion des Moduls, sollte diese Tabelle existieren.

Wenn man sich entscheidet, diese Tabelle nicht zu benutzen, dann muss man die

'SQLAuthenticate' Anweisung richtig setzen.

Anmerkung:

Normalerweise wird mod_sql alle passenden Gruppeneinträge verbinden. Das

bedeutet, dass man entweder mehrere Zeilen für jede Gruppe hat, mit je nur einem Mitglied pro Gruppe, oder Du hast eine einzelne Zeile mit mehreren Gruppen, oder beides gemischt. Bei Verwendung der "fast" Option für "Groupset"

bei der "SQLAuthenticate" Abweisung sind NICHT mehrere Zeilen pro Gruppe erlaubt

Um die User Tabelle zu erstellen:

CREATE TABLE users (

userid VARCHAR(30) NOT NULL ,

passwd VARCHAR(80) NOT NULL,

uid INTEGER UNIQUE,

gid INTEGER,

homedir VARCHAR(255),

shell VARCHAR(255)

)

Gruppen Tabelle:

CREATE TABLE groups (

groupname VARCHAR(30) NOT NULL,

gid INTEGER NOT NULL,

members VARCHAR(255)

)

4) Installations Anweisungen

Langsamer Login und Timeout Probleme:

Eine oft gestellte Frage in der ProFTPD User Mailinglise ist "Wieso geht mod_sql Schrittweise jeden User in der Datenbank durch ?"

Hier kommt die Erklärung: mod_sql ist ausgelegt um, alle Authentisierung Funktionen zu bearbeiten, die ProFTPD übergibt. Dieses beinhaltet Funktionen, wo alle User abgefragt werden (setpwent, getpwent, endpwent) und Funktionen, wo alle Gruppen abgefragt werden (setgrent, getgrent, endgrent).

Falls also mod_sql alle User oder Gruppen abfragt, dann weil es so von ProFTPD angefragt wurde. Weil es keinen guten Weg gibt, eine offene Abfrage aufrecht zu erhalten, ohne gleich neuen Code an die einzelnen Backend Module anzufügen, cached mod_sql User wenn setpwent() aufgerufen wird und cached alle Gruppen, wenn setgrent() aufgerufen wird. Dieses erlaubt die getpwent() und getgrent() Aufrufe einfach zu gestalten, auf Kosten der Zeit zu Beginn.

In einfachen Situationen werden diese Funktionen niemals aufgerufen. Wenn Du beginnst Zugriffe auf Verzeichnisse und Dateien, oder das Aufrufen von FTP Befehlen, auf Basis von Usernamen oder Gruppenname zu beschränken, dann muss ProFTPD alle User und Gruppen abfragen, um die Rechte zu überprüfen. Ein Standard FTP Server, inklusive Virtuellen und Anonymen Server, wird wahrscheinlich nie schrittweise alle User abfragen benötigen, jedoch wird alle Gruppen so abfragen.

Die 'SQLAuthenticate' Anweisung sieht eine Methode vor, mod_sql stumm zu stellen, standardmässig mod_sql wird die verschiedenen pwent() und grent() Aufrufe abarbeiten. Wenn 'SQLAuthenticate' gesagt wird, die Userabfragen oder Gruppenabfragen nicht zu bearbeiten, wird mod_sql diese einfach an irgendein Authentisierungsmechanismus im System weiterleiten. Bedenke hierbei, daß wenn man 'SQLAuthenticate' so benutzt wird, es bedeutet, daß ProFTPD nicht die gleichen Informationen benutzt um den User zu authentisieren als später die Zugriffskontrolle während der Session zu überprüfen.

Bei denen, die bereits in der Vergangenheit die mod_sql benutzt haben, sollten die Abfragen möglicherweise ausgeschaltet werden. Versionen von mod_sql vor V 3.2.0 (irgendwo da) haben die "{set|get|end}{pw|gr}ent" Aufrufe garnicht bearbeitet, so dass ein Abstellen dieses Abfragen keinerlei Funktionsverlust mit sich bringt.

Neue Benutzer von mod_sql sollten ihre Bedürfnisse überdenken - ist die Abfrage jedes Benutzers und Gruppe es wert, dass die Zugriffskontroll aus der Datenbank erfolgt ? Falls nicht, sollte man die Art der Datenbank Benutzung überdenken und wo man die User und Gruppeninformationen speichert

5) Anweisungen

Die Anweisungen sind hier in alphabetischer Reihenfolge aufgelistet. Falls Du gerade mit mod_sql beginnst, dann sind wahrscheinlich 'SQLConnectInfo', 'SQLAuthTypes', und die Anweisung, welche Tabelle und Felder die Daten enthalten ('SQLUserInfo' und 'SQLGroupInfo') die Interessantesten.

Die meisten Anweisungen habe sinnvolle Default Werte, bei ganz einfachen Konfigurationen benötigt man nur zwei Anweisungen: 'SQLConnectInfo' und 'SQLAuthTypes'.

5.1) SQLAuthenticate

Anmerkung:

Die 'SQLLog' und 'SQLShowInfo' Anweisungen werden immer von mod_sql abgearbeitet. Die 'SQLAuthenticate' Anweisung betrifft nur die Abfragen von "User" und "Group" durch das Modul.

Durch abstellen (bzw. nicht einbinden) der User oder Gruppen abfragen, wird die Funktionalität von mod_sql beeinträchtigt. Hierdurch wird ggf. die Möglichkeit der Zugriffskontrolle aufgrund von Gruppenzugehörigkeit verhindert. Dies ist jedoch Abhängig von anderen Möglichkeiten der Authentifizierung. Jedoch nimmt die Geschwindigkeit der Authentifizerung deutlich zu, diese Abfragen nicht durchführt.

Die "fast" Option ist nicht für jede Seite angebracht. Normalerweise, mod_sql empfängt eine Liste von Usern und Gruppen und bekommt die Informationen aus der Datenbank pro User oder pro Gruppe. Diese ist sehr Abfragen aufwendig - es benötigt (n+1) Abfragen, wobei "n" die Anzahl der User oder Gruppen ist. Wenn man die "Fast" Abfragen wählt, wird mit einer einzelnen SELECT Anfrage die Informationen aus der Datenbank geholt. Man erreicht zwar so eine dramatische Reduzierung der Abfragen, jedoch einen deutlich erhöhten Speicherbedarf, da alle User und Gruppen informationen auf einmal gelesen werden, statt in kleinen Portionen.

GROUP TABLE STRUKTUR

Normalerweise mod_sql erlaubt mehrere Gruppen per Zeile und mehrere Zeilen pro Gruppe. Bei Verwendung der Fast Option für Groupset, DARF es nur eine Zeile pro Gruppe geben. Zum Beispiel: Normalerweise behandelt mod_sql alle drei Tabellen exakt gleich.

5.2) SQLAuthTypes

Gibt die erlaubten Authentisierung Typen an und die Reihenfolge der überprüfung. Beachte: DU MUSST MINDESTENS EINE AUTHENTISIERUNGS METHODE ANGEBEN ! Falls keine Methode angegeben wird, werden mod_sql keine User authentisiert.

Zum Beispiel:

SQLAuthTypes Crypt Empty

bedeutet: überprüfe ob das Passwort in der Datenbank im UNIX crypt() Format gültig ist; wenn diese Abfrage nicht stimmt, überprüfen ob das Passwort in der Datenbank leer ist (ALLE Passwörter sind gültig); wenn dieses auch nicht simmt lehnt mod_sql die Authentisierung ab.

Aktuelle Typen:

5.3) SQLConnectInfo Syntax

Gibt die Verbindungsinformationen an. Die Verbindungsinformationen geben die Datenbank, Host, port und andere Backend-spezifische Angaben. "Username" und "Password" geben den User an, mit dem an die Datenbank angemeldet werden soll.

Die Standard Werte sind NULL, die das Backend in einem Backend spezifisch behandeln wird. Falls Du ein Passwort angibst, MUSST Du einen Usernamen angeben. Falls keine "SQLConnectInfo" Anweisung im Konfigurationsfile definiert ist, wird mod_sql sich selbst abschalten und niemand im Weg sein. Man hat dennoch natürlich keine Datenbank Unterstützung mehr.

Jedes Backend hat die Möglichkeit (aber NICHT die Verpflichtung) beim Start von ProFTPD nach Syntax Fehlern bei den Verbindungsinformationen zu suchen. Du solltest aber nicht die Erkennung logische Fehler erwarten, bis mod_sql versucht sich mit dem Server zu verbinden. Eine Datenbank Verbindung wird beherscht von einer Methode, wann die Datenbankverbindungen geöffnet und geschlossen werden soll.

Es gibt drei Möglichkeiten:

Falls die Methode nicht angegeben ist, falls die Methode keine Nummer ist; falls die Nummer kleiner 1 ist; oder falls als Methode "PERSESSION" angegeben ist, wird die "PERSESSION" Methode verwendet. Wird als Methode "PERCALL" angegeben, so wird die "PERCALL" Methode verwendet. Wird als Methode eine Zahl grösser 0 angeben, gibt diese die Zeit dafür in Sekunden an, in der die Datenbankverbindung trotz inaktivität offen gehalten wird. Nach dieser Zeit wird die Verbindung geschlossen und sobald eine Verbindung wieder benötigt wird, wieder aufgebaut.

Die MySQL und Progess Backend Verbindung Info wird im folgenden Format erwartet:

database[@hostname][:port]

Der Hostname ist Standardmässig abhängig vom Datenbank Backend und ist bei MySQL und Progres jeweils "localhost". Der Port ist ebenfalls Backend Abhängig und ist bei MySQL: 3306 und bei Postgres: 5432.

MySQL: Aus der Dokumentation: "Der Wert des Hosts ist entweder ein Hostname oder eine IP Adresse. Ist der Wert "NULL" oder der String "localhost" wird eine Verbindung zum lokalen Rechner angenommen. Sollte das Betriebssystem Sockets (Unix) oder Named Pipes (Windows) unterstützen, werden diese statt TCP/IP zur Verbindung benutzt.

PostgreSQL: Aus der Dokumentation: 'Falls [Der hostname] mit einem Slash beginnt, bezeichnet er eine Unix Domain Kommunikation statt TCP/IP. Der Wert ist der Name von einem Verzeichnis in dem das Socket File liegt. Die Voreinstellung ist eine Verbindung zu einem Unix Domain Socket in /tmp.'

Beachte: Wenn Du die Verwendung von PERCALL oder TIMED Verbindungen planst, bedenke den Einfluss von Anweisungen wie 'DefaultRoot' auf die lokale Socket Verbindung - nachdem der User chroot(ed) wurde, kann ggf. die Socket Datei nicht mehr erreicht werden und das wiedererstellen der Verbindung scheitert. Ein möglicher Ausweg, wäre die Verwendung von Hardlinks innerhalb der User Verzeichnisse.PERSESSION Verbindungen haben diese Einschränkung nicht, da die Verbindung vor dem Aufruf von chroot() geschieht und während der Session aktiv bleibt. Netzwerk Verbindungen sind von diesem Problem nicht betroffen, z.B. falls 'localhost' in MySQL nicht funktioniert, da MySQL eine Socket Verbindung aufbauen will, wird eine Verbindung mit 127.0.0.1 funktionieren (solange die Datenbank diese Verbindungen nicht untersagt).

Beispiele:

5.4) SQLDefaultGID

5.5) SQLDefaultHomedir:

5.6) SQLDefaultUID

5.7) SQLGroupInfo

5.8) SQLLog

Schreibt Informationen in eine Tabelle. Mehrere SQLLog Anweisungen können für jeden Befehl zuständig sein. z.B. ein User ändert ein Verzeichnis kann mehrere Log Aktionen starten. Das erste Parameter für SQLLOG, das Befehlsset, ist eine Liste von FTP Befehlen (per Komma getrennt, keine Leerzeichen), die ein Loggen starten. Die Liste der Befehle ist zu lang, um hier komplett aufgelistet zu werden und beinhaltet u.a. die wichtigen Befehle CWD, DELE, HELP, LIST, MKD, MODE, NLST, PASS, PASV, PORT und viele andere. Für eine komplette Liste schaut bitte in der RFC von FTP. [www.proftpd.org/docs/rfc.html]

Normalerweise wird mod_sql Aktionen loggen, nachdem sie erfolgreich beendet sind. Im Falle des "QUIT" Befehles jedoch, loggt mod_sql dieses bevor der Befehl von ProFTPD aufgeführt wird.Logeinträge werden nur ausgeführt, wenn die FTP Befehle erfolgreichbeendet wurden. Ein vorgestelltes "ERR_" erlaubt das loggen, wenn der ausgeführte Befehl nicht erfolgreich beendet wurde. Um beide Möglichkeiten (also erfolgreiche und unerfolgreiche Aktion) zu loggen, müssen beide Möglichkeiten genannt werden. Die Angabe '*' bezeichnet alle FTP Befehle, während 'ERR_*' alle Fehler bezeichnet.

Das zweite Argument ist der Name eine Abfrage, definiert durch die 'SQLNamedQuery' Anweisung. Die Abfrage muss vom Typ eine UPDATE, INSERT oder FREEFORM Abfrage sein - SELECT Abfragen werden nicht abgearbeitet. Das dritte Argument ist optional. Wenn man ein 'IGNORE_ERRORS' anfügt, wird SQLLOG während der Ausführung der Abfrage keine Fehlerüberprüfung vornehmen. Jedes andere Argument als "IGNORE_ERRORS' wird ohne Fehlermeldung ignoriert.

Normalerweise werden Fehler in einer SQLLOG Anweisungen sehr ernst genommen und mod_sql wird die Verbindung beenden. Verweise auf nicht existierende Abfragen werden NICHT die Verbindung beenden, können jedoch fehlende Datenbank Einträge erzeugen. Prüfe Deine Anweisungen !!

Beispiel:

Beispiele:

SQLLog PASS updatecount

SQLNamedQuery updatecount UPDATE "count=count+1 WHERE userid='%u'" users

Dieses ersetzt die alte 'SQLLoginCountField count' Anweisung und zählt bei jedem Einloggen den Wert des Feldes count in der Tabelle users einen höher. Ist der aktuelle User 'joe', so würde dieses übersetzt werden in: "update users set count=count+1 where userid='joe'"

Diese Abfrage würde immer gestartet werden, wenn ein User sich angemeldet hat.

SQLLog CWD updatedir

SQLNamedQuery updatedir UPDATE "cwd='%d' where userid='%u'" users

Dieses ersetzt die alte 'SQLLogDirs cwd' Anweisung und schreibt jedes Verzeichnis in das der User wechselt in die Datenbank, Tabelle "users". Ist aktuelle User 'joe' uns das aktuelle Verzeichnis '/tmp', wird dieses übersetzt in: "update users set cwd='/tmp' where userid='joe'". Diese Anfrage wird immer gestartet, wenn ein User ein Verzeichnis wechselt.

SQLLog RETR,STOR insertfileinfo

SQLNamedQuery insertfileinfo INSERT "'%f', %b, '%u@%v', now()" filehistory

Dieses schreibt bei jedem (erfolgreich) senden oder empfangen einer Datei den Namen, die Grösse in Bytes, den User und Host sowie die aktuelle Zeit (zumindest unter MySQL) in die Tabelle filehistory. Dieses würde übersetzt werden Abfrage ähnlich:

"insert into filehistory values ('somefile', 12345, 'joe@joe.org', '21-05-2001 20:01:00')"

5.9) SQLMinID

5.10) SQLMinUserGID

5.11) SQLMinUserUID

5.12) SQLNamedQuery

Das erste Argument ist der Name, der für alle Abfragen eindeutig ein muss und keine Leerzeichen enthalten darf. Das Ergebnis bei Benutzer identischer Namen ist nicht definiert.

Das zweite Argument "type" ist der Typ der Abfrage, entweder SELECT', 'UPDATE', 'INSERT' oder 'FREEFORM'. Bitte beachte die Anmerkungen unten über die FREEFORM Abfragen.

Das dritte Argument ist die eigentlich Abfrage selbst und muss dem Typ (zweites Argument) entsprechen. Die Parameter hier sind dentisch zur 'LogFormat' Anweisungen.

Folgende Anweisungen sind jedoch NICHT ERLAUBT:

Folgende Parameter bietet mod_sql zusätzlich zu der normalen 'LogFormat'

Anweisung:

Die korrekte Form einer Abfrage wird aus den Angaben zur Anweisung gebildet, mit Ausnahme der FREEFORM Abfragen, die direkt zum Server geschickt werden. Folgende Beispiele sollen zeigen, die mod_sql die Anweisungen in eine Abfrage umbaut. Das vierte Argumnt 'table' ist zwingend Notwendig bei 'UPDATE' oder 'INSERT' Abfragen.

Anmerkung:

FREEFORM Abfragen sind ein nötiges übel. Die einfache Syntax der UPDATE, INSERT und SELECT Abfragen nutzen nicht die Möglichkeiten moderner Datenbanksysteme. Auf der anderen Seite, macht es die Verwendung von FREEFORM Abfragen mod_mysql unmöglich den Sinn von Abfragen zu überprüfen, z.B. die Verwendung einer SELECT Anweisung in einer SQLLOG Anweisung. Daher sollte man wenn möglich die normalen Abfrage Typen benutzen.

Beispiele:

SQLNamedQuery count SELECT "count from users where userid='%u'"

erstellt eine Abfrage mit dem Namen 'count', die einem User mittels SQLShowInfo während dessen Login angezeigt wird. Die eigentliche Abfrage wäre ähnlich: "SELECT count from users where userid='matilda'" for user 'matilda'.

SQLNamedQuery updatecount UPDATE "count=count+1 WHERE userid='%u'" users

erstellt eine Abfrage mit dem Namen 'updatecount', die mittels SQLLOG dazu benutzt wird einen Login Zähler in der Tabelle 'users' zu erhöhen. Die eigentlich Abfrage für den User 'stonki' wäre ähnlich: "UPDATE users SET count=count+1 WHERE userid='stonki'"

SQLNamedQuery accesslog INSERT "now(), '%u'" accesslog

erstellt eine Abfrage mit den Namen 'accesslog', die mittels SQLLOG zum loggen der Onlinezeiten benutzt werden kann. Die eigentlich Abfrage wäre für den User 'paul' ähnlich: "INSERT INTO accesslog valueS (now(), 'paul')"

Diese Tabellenstruktur mag für den täglich Gebrauch zu einfach sein, da die meisten Datenbanken die Daten für JEDE Feld benötigen. Falls man nur ein Felder ändern will, ist ggf. die FREEFORM Abfrage besser geeignet:

SQLNamedquery accesslog FREEFORM "INSERT INTO accesslog(date, user) values (now(), '%u')"

erstellt eine Abfrage mit dem Namen 'accesslog', die mittels SQLLOG zum loggen der Onlinezeiten benutzt werden kann. Die eigentlich Abfrage wäre für den User 'weller' ähnlich: "INSERT INTO accesslog(date, user) valueS (now(), 'weller')"

5.13) SQLRatios

5.14) SQLRatioStats

5.15) SQLShowInfo

Das erste Parameter, das Befehlsset, ist eine Liste von FTP Befehlen (per Komma getrennt, keine Leerzeichen), die ein Loggen starten. Die Liste der Befehle i st zu lang, um hier komplett aufgelistet zu werden und beinhaltet u.a. die wichtigen Befehle CWD, DELE, HELP, LIST, MKD, MODE, NLST, PASS, PASV, PORT und viele andere. Für eine komplette Liste schaü bitte in der RFC von FTP. [Anmerkung des Übersetzers: www.proftpd.org/docs/rfc.html]

Logeinträge werden nur ausgeführt, wenn die FTP Befehle erfolgreich beendet wurden. Ein vorgestelltes "ERR_" erlaubt das loggen, wenn der ausgeführte Befehl nicht erfolgreich beendet wurde. Um beide Möglichkeiten (also erfolgreiche und unerfolgreiche Aktion) zu loggen, müssen beide Möglichkeiten genannt werden.

Die Angabe '*' bezeichnet alle FTP Befehle, während 'ERR_*' alle Fehler bezeichnet. Das zweite Argument 'numeric' gibt den numersichen Wert an, mit dem die Nachricht, an den FTP Client gesendet wird. Wähle diese Nummern NICHT zufällig aus, sie könnte vom Client weiterverarbeitet werden. In den meisten Fällen sollte man "214" für die Hilfsnachricht benutzen. Das gibt an, dass die Nachricht für den User bestimmt ist. Das dritte Argument, der 'query-string', ist identisch mit dem 'query-string' Argument der 'SQLLog' Anweisung, mit einer Ergänzung:

Es gibt derzeit keinen Weg, um mehr als einen Rückgabewert pro Abfrage zu erfragen.

Alle Verweise auf nicht existierende Abfragen, nicht SELECT oder FREEFORM Abfragen, oder verweise auf Abfrage, die einen NULL Wert zuerst zurückgeben, werden mit einem String "{null}" ersetzt. Zum Beispiel:

SQLNamedQuery count SELECT "count from users where userid='%u'"

SQLShowInfo PASS "230" "You've logged on %{count} times, %u"

Angenommen die Informationen existieren in der Datenbank, geben diese beiden Anweisungen an, dass der User nach einem erfolgreichen

Login mit seinem Login Counter begrüsst wird. Beachte die Verwendung des "230" Codes. Diese ist in der RFC für FTP definiert als "230 User logged in, proceed", was soviel bedeutet, daß alles ok ist. Dieser Code ist hier angebracht, da die Nachricht unmittelbar nach Akzeptieren des Passwortes geschickt wird und die Verbindung gestartet ist. [Anmerkung des übersetzers: siehe auch [www.rfc-editor.org/rfc/rfc959.txt]

5.16) SQLUserInfo

Lese die obige Beschreibung. Solltest Du ein dieser Feld anders benennen müssen, so müssen alle Felder angebeben werden, ggf. als NULL

5.17) SQLUserWhereClause

Syntax: | SQLUserWhereClause whereclause

Default: | none

Context: | server config, Global, VirtualHost

Module: | mod_sql

Anleitung: | Gibt eine Abfrage an, die an jede User Abfrage angehängt wird. Die Abfrage muss alle relevanten Zeichen enthalten, jedoch KEIN führendes "and". Um eine Verwendung einmal zu demonstrieren, stelle mir eine User Tabelle mit einem "zugang_ok" Feld vor:

SQLUserWhereClause "zugang_ok= 'true'"

würde an jede User relevante Abfragen folgenden String anhängen: " WHERE (zugang_ok = 'true')"

6) SQL Beispiel einer Tabellen Erstellung

Diese beiden SQL Befehle sollten mit jeder ANSI SQL Komplatiblen Datenbank funktionieren, und funktionieren definitiv unter MySQL und PostgreSQL. Beide erstellen die in Kapitel 2 dieses Dokumentes genannten Tabellen, mit sinnvollen Werten für den Datentyp und die Feldlänge.

Man kann strengere Definionen bei Bedarf verwenden - wenn man z.B. das Heimatverzeichnis oder die Shell definiert sollte man diese Felder als NOT NULL oder UNIQUE (einzigartig) definieren.

Um die Usertabelle zu erstellen:

CREATE TABLE users (userid VARCHAR(30) NOT NULL UNIQUE, passwd VARCHAR(30) NOT NULL, uid INTEGER UNIQUE, gid INTEGER, homedir VARCHAR(255), shell VARCHAR(255))

Um die Gruppentabelle zu erstellen:

CREATE TABLE groups (groupname VARCHAR(30) NOT NULL, gid INTEGER NOT NULL, members VARCHAR(255))