Umzug einer LDAP-Datenbank auf einen neuen Server

Da wir gerade für einen Kunden ein LDAP-Verzeichnis von einem Alt-Server auf ein neues System bei uns migriert haben und das Ganze nicht ganz trivial ist, möchte ich heute ein paar Tipps geben, wie man solche Daten erfolgreich umziehen kann.

Quasi-Standard für LDAP ist openLDAP, welches wir ebenfalls einsetzen und welches wir auch auf dem alten Server vorgefunden haben.
Zu beachten ist, dass sich die Konfigurationsdateien je nach Distribution unterscheiden, z.B. /etc/ldap (Debian) oder /etc/openldap (Gentoo).

OpenLDAP-Migration

Leider lassen sich die OpenLDAP-Dateien nicht einfach von einem Server auf einen anderen kopieren.
Grund dafür ist hauptsächlich, dass in diesen auch die Konfiguration gespeichert wird und sich diese meist von Server zu Server unterscheidet. Unter Gentoo findet sich diese Konfiguration im Verzeichnis /etc/openldap/slapd.d.
Hierbei ist die Besonderheit, dass die Konfiguration des eigentlichen LDAP-Servers (bsp. Ort der PID-Datei) auf die selbe Art und Weise gespeichert wird, wie das Schema der Datenbank. Verglichen mit MySQL wäre dies, als wenn my.cnf und die Definition der Tabellenspalten sich alle in ein- und derselben Datei befinden würden.

Prinzipiell liegen die Konfigurationsdateien, wie von anderen Programmen gewohnt (Bsp. INI-Datei) im Klartext vor und sind daher gut lesbar. Allerdings werden die Dateien mit einer Prüfsumme abgesichert. Sobald man manuell Änderungen vornimmt, stimmen diese natürlich nicht mehr und OpenLDAP weigert sich, die Dateien einzulesen.

Daher empfiehlt es sich zur Migration, die Konfiguration auf dem alten Server mit dem Befehl

zu sichern. Die Konfiguration befindet sich dann in der Datei ldap-config.ldif (ohne Prüfsumme) und kann dort beliebig an das neue System angepasst werden. Danach lassen sich mit dem Befehl

auch die eigentlichen Nutzdaten in der Datei ldap-userdata.ldif sichern. Beide Dateien können dann auf den neuen Server per scp kopiert werden.

Um die Daten auf dem neuen Server einzulesen, sollte dort zuerst, falls er schon läuft, der OpenLDAP-Daemon beendet werden (z.B. /etc/init.d/slapd stop). Dann sollte man die alte Konfiguration sowie das Daten-Verzeichnis (meist /var/lib/ldap oder /var/lib/openldap-data) löschen und neu anlegen:

Im Anschluss kann man die Daten mit den folgenden Befehlen auf dem neuen Server einlesen:

Die Pfade bzw. Dateinamen sind natürlich je nach System individuell passend zu wählen. Die Datenbank 0 gibt dabei die Konfiguration an. Datenbank 1 sind die eigentlichen Daten.

In der Datei /etc/openldap/slapd.conf müssen außerdem die richtigen Angaben zum Suffix (Domain) und rootdn (Admin-Benutzer-Name) gemacht werden. Beispiel:

Wichtig ist außerdem, im Anschluss noch die Verzeichnisrechte korrekt zu setzen, damit der LDAP-Daemon später Lese- und Schreibrechte auf die Dateien besitzt. Beispiel:

Im Anschluss sollte es möglich sein, den Daemon ganz normal zu starten und man sollte auf dem Server wieder alle seine Daten vorfinden. Überprüfen kann man dies wiederum mit einem Aufruf von slapcat (siehe oben).

Trouble-Shooting

Leider funktioniert nicht immer alles in der Praxis so wie gewünscht. Probleme kann es zum Beispiel beim Einlesen der Daten via slapadd geben. Falls dies passiert, empfiehlt es sich zu überprüfen, ob OpenLDAP auf dem neuen System mit allen Modulen/Erweiterungen installiert wurde, die auch auf dem Alt-System vorhanden sind. Ist dies nicht der Fall und entsprechende Datenbankerweiterungen werden verwendet, wird der Import fehlschlagen.

Ebenso kommt es häufig vor, dass der OpenLDAP-Daemon nicht startet. Leider gibt er dabei auch keine Fehlermeldungen aus, was die Fehlersuche unnötig erschwert. Dieses Verhalten lässt sich etwas verbessern, wenn man den Daemon nicht über das Init-Skript der Distribution startet, sondern /usr/lib64/openldap/slapd manuell ausführt. Hierbei kann man den Parameter -d übergeben, um die Debug-Ausgabe zu erhöhen. Die Meldungen sind jedoch auch dann nicht immer besonders aussagekräftig. Meine Empfehlung ist daher, zusätzlich strace zu verwenden. Hiermit lässt sich den häufig auftretenden Rechte-Problemen und Problemen beim Laden nicht vorhandener Erweiterungen meist schneller auf die Spur kommen.