OX 5 – LDAP Restaurierung nach Fehler | Linux-Blog

Gestern hatte ich nach 6 Jahren erstmals ein größeres LDAP-Problem mit unserem alten OX5-Server.

Meine Kollegin hatte versucht, eine neue Mail-Adresse auf dem OX 5 Server von Kontakt/Kmail eines Client-Rechners aus zu speichern. Dabei wird ein neuer Kontakt angelegt, dessen Daten bei meinem OX 5 sowohl in der Postgres-Datenbank als auch in einer LDAP-Datenbank hinterlegt werden.

Leider hatte die Kollegin die Mail von einem Outlook-Benutzer erhalten, der seine Adressangaben recht chaotisch gepflegt hatte. Seine “von”-Adresse wies eine Angabe der Form “mailto:xxx@yyy.com” auf. Unvorsichtigerweise hat meine Kollegin zur Übernahme der Mailadresse in das Kmail-Adressbuch (das eigentlich ein OX-Adressbuch ist) wie gewohnt mit der rechten Maustaste auf diesen “mailto-Link” im Adressbereich der an sie weitergeleiteten Mail geklickt. Dies hatte schlimme Folgen:

Der Speichervorgang für den neu anzulegenden “Kontakt” in den Kontakte- und Adressen-Verzeichnissen des OX5 Servers wurde leider nicht korrekt abgearbeitet. Als resultierende Symptome musste ich nach einiger Analyse von Log-Dateien des Servers leider einen traurigen Zustand feststellen:

Absturz von Tomcat
Korrumpierte LDAP-Datenbank
Massive Performancereduktion des OX-Servers wegen hängendem LDAP

Für die, die hier evtl. schlimmere Dinge vermuten: Ein Virenscan der Mail mit unterschiedlichen Scannern hat nichts erbracht.

Wegen der korrupten LDAP-Datenbank war auf dem OX5-server natürlich auch keinerlei Login mehr für die OX-User möglich, da diese alle über LDAP verwaltet und über “pam-ldap” authentisiert werden. User auf externen Servern konnten daher weder Dienste des OX-IMAP-Servers, noch Samba- und NFS-Dienste nutzen. Hier war schnelle Abhilfe von Nöten.

Die Lösung brachte hier (SUSE-SLES-System) folgende Kommandosequenz :

cd /var/lib/ldap
rcldap stop
db_recover -v
slapindex
rcldap start

LDAP unter Opensuse und auf SLES-Systemen nutzt defaultmäßig die Berkely DB als Backend zur Datenhaltung. Damit ist das Kommando “db_recover” angesagt. ( Unter Red Hat ist übrigens statt “db_recover -v” das Kommando “/usr/sbin/slapd_db_recover -h /var/lib/ldap ” einzusetzen.)

Für “katastrophale” Fälle kann man auch – nach weiteren Sicherungsmaßnahmen (! siehe die Links unten !) – die Variante

db_recover -v -c

verwenden. “-c” steht hier für “catastrophic”.

Will man das Kommando von einem anderen Ort als dem Verzeichnis “/var/lib/ldap” ausführen, so ist die Option “-h” nützlich.

Weitere Informationen – auch für hartnäckige Fälle der Restaurierung der LDAP Backend Datenbank – liefert die Artikel unter folgenden Links:

http://sdb.open-xchange.com/node/29
http://blog.mydream.com.hk/howto/linux/openldap-recovery-howto

Zu den Optionen von “db_rcover” für die BDB siehe :

http://www.manpagez.com/man/1/db_recover/

Weitere Informationen zur Fehlerbehebung findet man unter:

http://techarold.blogspot.com/2006/07/more-openldap-recovery.html
http://www.prestonlee.com/2009/07/08/recovering-a-corrupt-openldap-database-on-osx-server/
http://serverfault.com/questions/87889/ldap-database-recovery-after-server-crash
http://
web.archiveorange.com/archive/v/TDuKz11zCkpKFJNjBppH
http://www.bynari.net/support/users/kb.php?id=236

Generelle LDAP-Admin-Informationen findet man unter :

http://www.openldap.org/doc/admin24/