|
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.
|
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".
|
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.
|
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.
|
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.
|
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.
|
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.
|
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!
|
|
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.
|
|