OpenLDAP von HDB zu MDB migrieren
Einleitung
Vor Kurzem stand ich vor der Aufgabe, ein OpenLDAP-Verzeichnis fit für die Zukunft zu machen. Das besagte LDAP-Verzeichnis enthält ca. 100 Benutzer und 30 Gruppen. Es läuft auf einem SUSE Linux Enterprise Server 12 (SLES) und verfügt dementspechend auch über SUSE-spezifische Schema-Erweiterungen.
Da das Verzeichnis schon älter ist, verwendet es noch das sog. HDB-Backend, das auf Berkeley DB basiert. Dieses HDB-Backend ist aber deprecated und soll nicht mehr verwendet werden. Stattdessen soll das MDB-Backend verwendet werden, das auf Lightning Memory-Mapped Database (LMDB) basiert. Dies ist eine von OpenLDAP entwickelte Datenbank-Engine, die ähnlich zu Berkeley DB Schlüssel-Werte-Paare speichert.
Einige Google-Recherchen später wusste ich, dass es nicht eben mal so umgestellt werden kann, es gibt kein vorgefertigtes Tool, das die Datenbank konvertiert. Die einzige Möglichkeit, die es gibt, ist eine neue Datenbank anzulegen und die alten Daten einzulesen. Doch auch dies ist aufgrund der Schema-Erweiterungen nicht einfach so getan. Es muss also die Konfiguration der alten Datenbank angepasst werden, sodass MDB verwendet wird und anschließend daraus eine neue Datenbank erzeugt werden.
Der Weg sieht nun folgendermaßen aus:
- LDAP-Datenbanken 0 (Schema und Konfiguration) und 1 (Inhalt) ins LDIF-Format exportieren
- Export 0 so anpassen, dass MDB statt HDB verwendet wird
- LDAP-Dienst anhalten
- Alte Datenbanken löschen
- Mit Export 0 eine neue Datenbank anlegen
- Export 1 unverändert einlesen
- LDAP-Dienst starten
Auf die einzelnen Schritte werde ich nun näher eingehen. Ich gehe im Folgenden von diesen Dingen aus:
- Sie arbeiten mit
root-Rechten - Die Exporte werden im Home-Verzeichnis (
~) desroot-Benutzers abgelegt - Der Benutzer, unter dem der LDAP-Dienst läuft, heißt
ldap, die Gruppe heißt ebenfallsldap - Schema und Konfiguration befinden sich in einer Verzeichnisstruktur (und nicht in einer einzelnen Datei), diese liegt unter
/etc/openldap/slapd.d - Die eigentlichen LDAP-Daten befinden sich unter
/var/lib/ldap
Bitte prüfen Sie, ob es bei Ihnen Abweichungen bei den Verzeichnissen gibt und passen Sie die Shell-Kommandos ggf. an. Dies kann bspw. der Fall sein, wenn Sie Debian oder Ubuntu statt SLES verwenden.
Ich übernehme keinerlei Haftung für Datenverlust, der durch Befolgung dieser Anleitung entsteht! Machen Sie unbedingt eine Datensicherung, verschieben Sie lieber erstmal, statt zu löschen und machen Sie Kopien, bevor Sie Dateien editieren.
Schritt 1: Export
Je nachdem, wie stark das LDAP-Verzeichnis genutzt wird, können Sie auch zuerst den LDAP-Dienst anhalten (Schritt 3). Da sich das in meinem Fall betroffene LDAP nicht schnell ändert, habe ich den Dienst laufen lassen.
Es werden nun die LDAP-Daten exportiert bzw. gedumpt. Die Exporte oder Dumps liegen dann im sog. LDIF-Format vor. Das geht folgendermaßen:
# slapcat -n 0 -l ~/config.ldif # slapcat -n 1 -l ~/data.ldif
Schritt 2: Export 0 anpassen
Nun muss der Export 0 mit einem Texteditor bearbeitet werden, um HDB durch MDB zu ersetzen. Das ist definitiv der aufwändigste Schritt, weil man genau schauen muss, was raus und was verändert werden muss. Eine fehlerhafte oder nicht mit MDB kompatible Zeile verhindert, dass der Export wieder eingelesen werden kann.
Ich musste folgendes in der config.ldif anpassen (arbeiten sie lieber mit einer Kopie der Datei), es kann sein, dass bei anderen LDAP-Verzeichnissen anders vorgegangen werden muss:
Die Zeilen
olcModuleLoad: {0}back_bdb.so
olcModuleLoad: {1}back_mdb.so
olcModuleLoad: {2}back_hdb.so
olcModuleLoad: {3}syncprov.so
wurden geändert zu:
olcModuleLoad: {0}back_mdb.so
olcModuleLoad: {1}syncprov.so
Dadurch werden die alten Berkeley-DB-Backends abgeschaltet.
Die Zeilen
olcDbCacheSize: 10000
olcDbCheckpoint: 1024 5
olcDbConfig: {0}set_cachesize 0 15000000 1
olcDbConfig: {1}set_lg_regionmax 262144
olcDbConfig: {2}set_lg_bsize 2097152
olcDbConfig: {3}set_flags DB_LOG_AUTOREMOVE
olcDbConfig: {4}set_lk_max_locks 30000
olcDbConfig: {5}set_lk_max_objects 30000
olcDbIDLcacheSize: 30000
enthalten spezifische Konfigurationsdaten für Berkeley DB. LMDB kann damit nichts anfangen, deswegen müssen sie komplett entfernt werden.
Zu guter letzt habe ich noch sämtliche Vorkommnisse von hdb zu mdb und von Hdb zu Mdb geändert.
Schritt 3: LDAP-Dienst anhalten
Das ist einfach, dazu folgendes in der Shell eingeben:
# systemctl stop slapd
Schritt 4: Alte Datenbanken löschen
Natürlich sollte man die Datenbanken nicht direkt löschen, sondern erst mal umbenennen:
# mv /etc/openldap/slapd.d /etc/openldap/slapd.d_alt # mv /var/lib/ldap /var/lib/ldap_alt
Wenn die Konvertierung funktioniert hat und der LDAP-Dienst ein paar Tage fehlerfrei arbeitet, können die Verzeichnisse natürlich gelöscht werden.
Schritt 5: Export 0 einlesen
Zunächst müssen die im vorherigen Schritt umbenannten Verzeichnisse neu angelegt werden:
# mkdir /etc/openldap/slapd.d # mkdir /var/lib/ldap
Jetzt kann der Export 0 eingelesen und damit das Schema und die Konfiguration wiederhergestellt werden:
# slapadd -n 0 -F /etc/openldap/slapd.d -l ~/config.ldif
Wenn der Import funktioniert hat, müssen die Berechtigungen für das Verzeichnis mit der Konfiguration korrigiert werden:
# chmod 700 /etc/openldap/slapd.d # chown -R ldap:ldap /etc/openldap/slapd.d
Wenn beim Import Fehlermeldungen auftreten, empfehle ich, zu Schritt 4 zurückzugehen. Durch das fehlerhafte Einlesen enthält die Datenbank ungültige Daten, die ein erneutes Einlesen verhindern.
Schritt 6: Export 1 einlesen
Wenn der vorherige Schritt ohne Fehler abgearbeitet werden konnte, können nun die eigentlichen LDAP-Daten wieder eingelesen werden:
# slapadd -n 1 -F /etc/openldap/slapd.d -l ~/data.ldif
Grundsätzlich verläuft dieser Schritt nach meinen Erfahrungen problemlos, wenn der vorherige funktioniert hat. Wenn der Import also abgeschlossen ist, müssen auch hier die Berechtigungen für das Verzeichnis korrigiert werden:
# chmod 700 /var/lib/ldap # chown -R ldap:ldap /var/lib/ldap
Schritt 7: LDAP-Dienst starten
Das ist wieder einfach:
# systemctl start slapd
Wenn alles geklappt hat, sollte der LDAP-Dienst fehlerfrei starten und ein Zugriff möglich sein. Häufige Fehlerquellen sind falsche Berechtigungen an den Datenverzeichnissen oder übersehene Zeilen in Export 0.
Interessant fand ich, dass durch den Austausch der Datenbank-Engine die Größe der LDAP-Datenbank von knapp 30 MB auf nur noch 1 MB geschrumpft ist. Ich weiß, auch 30 MB war nicht viel, aber der Unterschied ist bemerkenswert.