SelfLinux Linux im Netzwerk Das Lightweight Directory Access Protocol Abschnitt 5 | SelfLinux-0.13.0

| Das Lightweight Directory Access Protocol | Autoren Formatierung GFDL

#### 6 Erstellen eines Beispielverzeichnisses

#### 6.1 Erstellen der LDIF Dateien

Nach der Installation und Konfiguration des LDAP-Servers muss dieser mit Daten gefüttert werden. Das folgende Beispiel erklärt einen "Directory Information Tree" anhand einer Firma mit mehreren Abteilungen. Die einzelnen Felder müssen den lokalen Gegebenheiten nur angepaßt werden, um eine simple Konfiguration aufzusetzen.
Für das folgende Beispiel wird im Verzeichnis /usr/local/etc/openldap das Unterverzeichnis ldif/ angelegt. In diesem Verzeichnis kann mit jedem x-beliebigen Editor, der ASCII unterstützt, eine Datei mit dem Namen struktur.ldif erstellt werden. Der Name und das Verzeichnis für die Beispiel-LDIF-Dateien sind beliebig. Es müssen für den Fall, dass andere Namen oder Pfade verwendet werden, diese nur an die lokalen Gegebenheiten angepaßt werden.

Kommen wir aber nun zu der LDIF-Datei. Wir definieren einen neuen "Namensraum" selflinux.de. In LDAP-"Sprache" heißt das dc=selflinux,dc=de. Alles, was definiert wird, spielt sich unter diesem Punkt ab, damit gibt es keine Konflikte mit anderen Verzeichnissen.

Das Verzeichnis besteht zunächst aus einer Firma (bzw. Organisation) SelfLinux. Neben dieser Firma wird noch ein separater Eintrag eingerichtet, in dem die Administratoren (Manager) referenziert werden. Verzeichnis-Manager gehören also zu keiner Organisation oder Abteilung. Logisch gesehen ist das ja so auch korrekt.

Die Firma Selflinux bekommt drei Abteilungen ("Unterorganisationen") spendiert: Development, Sales und Support. Die Mitarbeiter werden dann mit den Abteilungen referenziert. Daraus ergibt sich folgende Struktur:

Struktur der Firma Selflinux

    selflinux.de:
    |
    +-- Manager
    |
    +-- Selflinux
    |
    |
    +-- Development
    |   |
    |   +-- Mitarbeiter 1 (Thomas Bendler)
    |   |
    |   +-- Mitarbeiter 2 (Steffen Dettmer)
    |
    +-- Sales
    |   |
    |   +-- Mitarbeiter 4 (Sonja Essler)
    |
    +-- Support
    |
    +-- Mitarbeiter 3 (Thomas Lippert)

Hat man keinen rootdn-Eintrag in der slapd.conf, sollte unbedingt ein Manager-Account in dieser Struktur mit angegeben werden, da ansonsten kein Schreib-Zugriff auf das Verzeichnis möglich wäre.

#### 6.2 Beispiel LDIF struktur.ldif

Beispiel LDIF: struktur.ldif

    dn: cn=Manager, dc=selflinux, dc=de
    cn: Manager
    description: Directory Manager
    description: Verzeichnis-Manager
    objectClass: organizationalRole
    objectclass: top
    roleOccupant: cn=Thomas Bendler,ou=Development,dc=selflinux,dc=de
    roleOccupant: cn=Steffen Dettmer,ou=Development,dc=selflinux,dc=de

    dn: o=Selflinux,dc=selflinux,dc=de
    objectclass: top
    objectclass: domain
    objectclass: organization
    o: Selflinux
    l: Hamburg
    postalcode: 21033
    streetadress: Billwiese 22

    dn: ou=Development,o=Selflinux,dc=selflinux,dc=de
    objectclass: top
    objectclass: organizationalunit
    ou: Development

    dn: ou=Sales,o=Selflinux,dc=selflinux,dc=de
    objectclass: top
    objectclass: organizationalunit
    ou: Sales

    dn: ou=Support,o=Selflinux,dc=selflinux,dc=de
    objectclass: top
    objectclass: organizationalunit
    ou: Linux

    dn: cn=Thomas Bendler,ou=Development,o=selflinux,dc=selflinux,dc=de
    objectclass: top
    objectclass: person
    objectclass: organizationalperson
    objectclass: inetorgperson
    cn: Thomas Bendler
    sn: Bendler
    ou: Development
    mail:project@selflinux.de
    l: Hamburg
    postalcode: 21033
    streetadress: billwiese 22
    telephonenumber: 040-7654321
    facsmiletelephonenumber: 040-7654321
    userpassword: {CRYPT}saHW9GdxihkGQ

    dn: cn=Steffen Dettmer,ou=Development,o=Selflinux,dc=selflinux,dc=de
    cn: Steffen Dettmer
    sn: Dettmer
    ou: Development
    mail: steffen@dett.de
    telephoneNumber: +49 (30) 1234567
    objectClass: person

    dn: cn=Sonja Essler,ou=Sales,o=Selflinux,dc=selflinux,dc=de
    cn: Sonja Essler
    sn: Essler
    ou: Sales
    mail: sonja@bendler-net.de
    telephoneNumber: +49 (30) 1234568
    objectClass: person

    dn: cn=Thomas Lippert,ou=Support,o=Selflinux,dc=selflinux,dc=de
    cn: Thomas Lippert
    sn: Lippert
    ou: Support
    mail: tom@bendler-net.de
    telephoneNumber: +49 (30) 1234569
    objectClass: person

Das in diesem Beispiel eingesetzte Passwort {CRYPT}saHW9GdxihkGQ wurde mit Hilfe von Perl erzeugt. Dazu muss in der Shell folgender Befehl eingegeben werden. Das Ergebnis wird auf dem Bildschirm angezeigt und muss 1:1 in die LDIF Datei übertragen werden. Dieser Aufruf ist exemplarisch und nur zum Testen geeignet, da "salt" konstant und nicht zufällig ist! perl -e 'print("{CRYPT}".crypt("secret","salt")."\n");'

Damit wird das Passwort in ein für den Server verständliches Format gebracht. Möchten sie ein anderes Passwort verwenden, müssen sie stattdessen das gewünschte einsetzen. Sie können es nachträglich mit dem Befehl ldappasswd ändern.

Es ist in der Praxis einfacher, sofort das Passwort mit ldappasswd zu setzen (es beim Erstellen der Ursprungsdatei erstmal wegzulassen, wie im Beispiel bei den anderen Personen).

Falls man nicht über Rollen sondern Gruppen arbeiten möchte, kann man beispielsweise auch folgenden Manager-Eintrag benutzen:

Auszug LDIF struktur.ldif

    dn: cn=Manager,dc=selflinux,dc=de
    cn=Manager
    objectclass: top
    objectclass: groupofnames
    member: cn=Thomas Bendler,ou=People,dc=selflinux,dc=de

Das Rollen-Modell ist jedoch üblicher und natürlicher, denn es ist hier klar, dass die Mitglieder bestimmte Rollen oder Aufgaben erfüllen. Der Begriff "Gruppe" hingegen suggeriert jedoch eher eine Personenaufteilung, technisch gesehen können natürlich Personen in mehreren Gruppen sein. Wenn die Gruppe jedoch eine bestimmte abstrakte Aufgabe hat, sollte man hier jedoch eher eine Rolle definieren. Dies wird oben im Beispiel so verwendet. Die Rolle "Manager" hat hier zwei "Mitglieder".

#### 6.3 Umwandeln der LDIF-Datei in das LDBM-Format

Als nächstes muss die LDIF-Datei ins LDBM-Format konvertiert werden. Dazu dient der Befehl ldif2ldbm. Dieser ist unter "/usr/local/sbin/" zu finden.
Der Aufruf lautet:
ldif2ldbm -i /usr/local/etc/openldap/ldif/struktur.ldif -f /usr/local/etc/openldap/slapd.conf

Sollten sich irgendwelche Dateien nicht in den Standardpfaden befinden, so kann man so nach den Dateien suchen lassen:
locate "Dateiname"

oder, falls das nichts hilft, über das jedoch sehr langsame Kommando:
find / -name "Dateiname"

Ist die LDIF-Datei konvertiert, muss der LDAP-Server gestartet werden. Die meisten Distributionen stellen dafür ein Skript zur Verfügung welches sich unter /etc/init.d/, /etc/rc.d/init.d/ oder unter /sbin/init.d befindet. Für gewöhnlich schimpft sich dieses ldap und kann mit diversen Parametern aufgerufen werden. Unter SuSE z.B. würde man mit folgendem init-Script den Server starten:
/sbin/init.d/ldap start

Ist kein Startskript vorhanden, wird der LDAP-Server mit folgendem Kommando gestartet:
/usr/local/libexec/slapd -f /usr/local/etc/openldap/slapd.conf

Damit der slapd beim Hochfahren automatisch gestartet wird, muss man ein Skript im initd/ Verzeichnis anlegen. Das befindet sich je nach Distribution an einer anderen Stelle, so dass dem Leser nichts übrig bleibt als ein bisschen zu suchen. Normalerweise bieten die Distributionen ein Skeleton an, das an die jeweiligen Bedürfnisse angepasst werden muss. Ausführliche Informationen entnehmen Sie bitte der Dokumentation über das "Sys V System" Ihrer Distribution. Wahlweise hilft meistens auch ein man init, um etwas mehr über selbiges zu erfahren.

#### 6.4 Testen des LDAP-Servers

Um den LDAP-Server zu testen, kann man jetzt eine Anfrage an selbigen schicken. Dies geschieht mit folgendem Befehl: ldapsearch \
-D "cn=Thomas Bendler,ou=Develpoment,o=Support,dc=selflinux,dc=de" \
-W objectclass=\*

Der Server sollte nun eine Struktur, wie in der Datei beschrieben, als Antwort übergeben.

#### 6.5 Hinzufügen von Datensätzen

Nun geht es an das Hinzufügen von Datensätzen. Dazu werden die bereits erstellten LDIF-Dateien benutzt. Das Hinzufügen geschieht mit Hilfe des Befehls ldapadd entsprechend der Syntax für die zwei erstellten LDIF-Dateien:
ldapadd -v \
-D "cn=Thomas Bendler,ou=Develpoment,o=Support,dc=selflinux,dc=de" \
-W \
-f /usr/local/etc/openldap/ldif/people.ldif
ldapadd -v \
-D "cn=Thomas Bendler,ou=Develpoment,o=Support,dc=selflinux,dc=de" \
-W \
-f /usr/local/etc/openldap/ldif/zuordnung.ldif

Auf diese Weise können auch weitere Einträge hinzugefügt werden.. Neben der reinen Kommandozeile gibt es auch Tools, die eine ``komfortablere'' Eingabe zulassen (auch wenn's meiner Meinung nach nichts komfortableres als die Kommandozeile gibt). Diese werden in der zweiten LDAP-Serie beschrieben.

#### 6.6 Bilder im Verzeichnis

Man kann Bilder im JPEG-Format ebenfalls in das Verzeichnis aufnehmen. Das folgende Beispiel zeigt, wie man zu einem Personeneintrag ein "Paßfoto" hinzufügt.

Angenommen, das Bild heißt "/tmp/pic.jpg". Nun muss der DN der betreffenden Person natürlich bekannt sein und man benötigt selbstverständlich Schreibzugriff auf das Verzeichnis.

Man erzeugt eine Datei, in der der DN und der Bild-Eintrag stehen. Diese "pic.datei" könnte wie folgt aussehen:

pic.datei

    dn: cn=Thomas Bendler,ou=People,dc=selflinux,dc=de
    jpegphoto: /tmp/pic.jpg

Nun kann man mit dem Kommando ldapmodify den Eintrag dieses DNs ändern (indem man das Attribut jpegphoto hinzufügt). Damit nicht der Bildpfad, sondern dessen Dateiinhalt in das Verzeichnis aufgenommen wird, muss dem ldapmodify der Parameter "-b" mitgegeben werden. Diese Option veranlaßt die ldap*-Werkzeuge, absolute Pfade als Binärdaten zu betrachten. Der Beispielaufruf:

ldapmodify \
-D "cn=Thomas Bendler,ou=Develpoment,o=Support,dc=selflinux,dc=de" \
-W -b < pic.datei

Noch ein Hinweis zur Arbeitserleichterung. Da gerade beim ersten Aufsetzen in der Regel nur ein Manager benötigt wird, empfielt es sich, diesen Account über die Parameter "rootdn" und "rootpw" in der slapd.conf einzustellen. Man bindet in diesem Fall über:

...
-D "cn=Manager,dc=selflinux,dc=de"
...

und spart etliches an Tipparbeit. In der Produktion ist dies dann jedoch unzulänglich, da ein Manager ja auch mal Urlaub macht, und auch in dieser Zeit jemand beispielsweise vergessene Paßwörter ändern können muss. Man benötigt hier also immer mehrere Manager. Die Parameter "rootdn" und "rootpw" sollte man dann auskommentieren und den slapd neustarten.

#### 6.7 Ändern von Indizes

Werden in der slapd.conf neue Indizes konfiguriert, so gelten die Einstellungen natürlich sofort für neue Einträge. Die bereits vorhandenen Einträge sind in diesen neuen Indizes aber nicht enthalten. Suchanfragen führen in diesem Fall zu merkwürdig aussehenden Resultaten: Alle neuen Datensätze werden gefunden, jedoch nie alte. In solchen Fällen müssen die Indizes neu erzeugt werden. Dazu stoppt man den slapd, erzeugt sich eine LDIF-Kopie der Datenbank und indiziert diese (der Indexer kann nur LDIFs indizieren). Letztlich startet man den slapd neu.

Hier die Kommandos (ohne start/stop):

user@linux $ ldbmcat /var/lib/ldap/id2entry.gdbm > id2entry.dump user@linux $ ldif2ldbm -i id2entry.dump

Dieser Vorgang kann einige Zeit in Anspruch nehmen, wenn man große Datenbestände hat. Technisch gesehen exportiert man die gesamte Datenbank und importiert sie anschließend.

#### 6.8 Datensicherung

Es gibt mehrere Möglichkeiten, Daten zu sichern. Die eleganteste Lösung ist, mehrere sich untereinander replizierende LDAP-Server zu verwenden. Für kleine Installationen ist dies jedoch zu aufwendig. Leichter ist es, sich einfach mit ldapsearch alle Datensätze ausgeben zu lassen, und in einer Datei zu speichern. Ein besserer Weg ist, das Werkzeug ldbmcat zu verwenden, um sicherzugehen, wirklich alle Einträge zu erhalten. Um Inkonsistenzen zu vermeiden, sollte der slapd unbedingt gestoppt werden. Um die Ausfallzeit gering zu halten, kopiert man einfach die Datenbankdatei. Unter SuSE-Distributionen könnte man folgende Kommandofolge verwenden:

rcldap stop \
&& cp /var/lib/ldap/id2entry.gdbm id2entry-snap.gdbm ; \
rcldap start \
id2entry-snap.gdbm > id2entry-snap

Man erhält id2entry-snap.gdbm im Datenbankformat und eine LDIF-Datei id2entry-snap. Es empfielt sich letztere zu sichern, da über diese Datei notfalls auch in andere Verzeichnisserver zurückgesichert werden kann. Das GDBM-Format hingegen ist versions- und plattformabhänig.

Der Backup-Vorgang muss vorher unbedingt durchgetestet werden, um vor Überraschungen sicher zu sein. Dieser Test muss auch eine Rücksicherung einschließen, denn nur so kann man sicher sein, dass alles funktioniert. In der Praxis kann es sonst zu bösen Überraschungen kommen, denn das Verzeichnis wird schnell zu einem wichtigen Dienst in der Organisation werden!

#### 7 Tuning des LDAP-Servers

Es gibt unterschiedliche Möglichkeiten, den LDAP-Server zu tunen. Diese Möglichkeiten beziehen sich in erster Linie auf die LDBM-Datenbank. Deutliche Performancegewinne lassen sich aber erst in Verbindung mit großen Datenbeständen erzielen. Der "The SLAPD and SLURPD Administration Guide" bietet einen Überblick der Möglichkeiten zum Tunen des LDAP-Servers. Weitere Informationen finden sich im FAQ-O-MATIC auf der Homepage des OpenLDAP Projekt.