Einmal genügt

Im zweiten Teil des LDAP-Tutorials ging es unter anderem darum, wie die L.d.a.P. GmbH Teile des Verzeichnisdienstes auf einen separaten Server auslagerte. Dies ist sinnvoll, wenn abgeschlossene Datenbereiche nur an einem bestimmten Ort eine Rolle spielen. Andererseits werden häufig Daten zwar an mehreren Stellen benötigt, ihre Pflege muss aber zentral erfolgen, und zwar vollständig. In diesem Fall empfiehlt es sich, den gesamten Bestand auf mehrere Server zu replizieren. Außerdem kann dieses Vorgehen stark beschäftigte Systeme durch Slaves entlasten. Die im Round-Robin-Verfahren im DNS-Server geänderte IP-Adresse des LDAP-Servers gewährleistet dabei eine gleichmäßige Lastverteilung zwischen Master und Slave(s).

Zur Replikation dient der Daemon slurpd. Er bezieht seine Informationen aus der Konfigurationsdatei /etc/openldap/slapd.conf, sofern man ihn nicht mit anderen Angaben startet. Replikation erfolgt bei OpenLDAP immer unidirektional von einem Master zu dem oder den Slaves. Änderungen der Master-Daten reicht dieser an alle Slaves weiter. Die Einrichtung einer Replikation zwischen zwei Servern erfolgt in fünf Schritten.

Da zwischen den Systemen nur Änderungen übertragen werden, müssen beide mit demselben Datenbestand beginnen. Als Ausgangspunkt dazu dienen zwei Maschinen mit identischer Konfiguration:

database bdb
suffix "dc=ldap-gmbh,dc=de"
rootdn "cn=Manager,dc=ldap-gmbh,dc=de"
rootpw secret
directory /var/lib/ldap index objectClass     eq

Dem zukünftigen Master-System entlockt man seine Daten vollständig durch den Befehl slapcat. Dessen Ausgabe lässt sich entweder mit der Option -l oder per Ausgabeumleitung in eine Datei schreiben:

slapcat -l komplett.ldif

Zur Herstellung eines konsistenten Zustands darf nach der Ausführung von slapcat keine Änderung am Master mehr erfolgen, was sich am einfachsten durch das Anhalten des Servers erreichen lässt. Alternativ unterbindet die Option readonly on in slapd.conf Änderungen.

Fünf Schritte zur Replikation

Statt slapcat und slapadd zu verwenden, kann man in manchen Fällen die Datenbank-Dateien des Masters auf den Slave kopieren. Wo sie zu finden sind, verrät die directory-Direktive. Dies ist jedoch nur sinnvoll, wenn beide Rechner hinreichend ähnlich sind, beispielsweise hinsichtlich der Byteorder.

Auf dem angehenden Slave spielt

slapadd -l komplett.ldif

die Ausgabe von slapcat wieder ein. Es existieren somit zwei Systeme mit identischer Konfiguration und Datenbestand, und der erste Schritt ist abgeschlossen.

Als zweiter Schritt folgen Ergänzungen in der Konfiguration des Masters, die die Übertragung von Änderungen zu den Slaves ermöglichen. Jede Definition eines Slave-Servers beginnt mit einer replica-Direktive, die die LDAP-URL des Slave enthält. Es folgen Informationen zum Binden an den Slave-Server wie der Bind-DN, die verwendete Methode zum Binden und das Passwort. All das muss gegenüber der Replica-Direktive eingerückt sein.

Schließlich ist eine so genannte Replog-Datei erforderlich, in die der Master Änderungen seiner Daten schreibt. Der slurpd liest die Änderungen daraus und verteilt sie an die Slave-Server. Beispielhaft sieht eine replica-Direktive so aus:

replica uri=ldap://slave1.ldap-gmbh.de
  binddn=cn=Replicator,dc=ldap-gmbh,dc=de
  bindmethod=simple
  credentials=geheim
replogfile /var/lib/ldap/replog-slave.log

Nach einem erneuten Start des Masters (oder nach dem Entfernen der readonly-Option und dem Neuladen der Konfiguration) protokolliert der LDAP-Server alle Änderungen in der Replog-Datei.

Erhält Hugo Schulz beispielsweise eine neue Telefon-Durchwahl, sieht dies dort so aus wie in Listing 1.

replica: slave1.ldap-gmbh.de:389
time: 1149756391
dn: uid=hschulz,ou=IT,dc=ldap-gmbh,dc=de
changetype: modify
delete: telephoneNumber
-
add: telephoneNumber
telephoneNumber: 152
-
replace: entryCSN
entryCSN: 20060608084631Z#000001#00#000000
-
replace: modifiersName
modifiersName: cn=Manager,dc=ldap-gmbh,dc=de
-
replace: modifyTimestamp
modifyTimestamp: 20060608084631Z 

Wie die letzten beiden Schritte zur Replikation aussehen, was bei der Verbindung von Samba mit LDAP zu beachten ist und wie man Zugriffsrechte für LDAP-Verzeichnisse feinkörnig vergibt, erfahren Sie in der aktuellen Print-Ausgabe.

Teil 1: LDAP-Grundlagen, Directory Information Tree, Datenimport, Kommandozeilen-Werkzeuge

Teil 2: Fortgeschrittene Suche, Datenverwaltung, Aufteilung des DIT in mehrere Teile, Linux- und Apache-Authentifizierung über LDAP (ck)