Recover der LDAP-Datenbank
Hallo zusammen, ich hatte heute schon zum zweiten mal ein seltsames Phänomen mit OpenLDAP auf einem SuSE-10 Rechner. Zum Verwalten der User/Gruppen benutze ich Gosa (2.4) was auch prima läuft. Am Anfang hatte ich jedoch Gosa falsch konfiguriert. Die User wurden mit cn=... anstatt uid=... angelegt. Also habe ich alle User/Gruppen gelöscht, habe Gosa umgestellt und alles wieder neu angelegt. Soweit alles klar. Als ich kurze Zeit später wie in Gosa ging war einer der beiden User weg. Die Gruppen waren noch da. Also wollte ich den fehlenden User neu anlegen was jedoch mit der Meldung das der User schon im LDAP vorhanden wäre scheiterte. Genau den gleichen Effekt hatte ich vor kurzem schon einmal. Ich dachte es handelt sich um einen Bug in Gosa. Heute versuchte ich dann das System auszutricksen und den User mit meinem LDAP-Browser anzulegen und siehe da, dieser meldete auch das dieser User schon da wäre. Nur sehe ich ihn nicht. Weder im LDAP-Browser, noch wenn ich den LDAP mit ldapsearch auslese. Es scheint als wäre eine nicht abgeschlossene Transaktion in der LDAP-Datenbank (Vermutung) und deshalb die Frage ob es hier irgend eine Reorg-Funktion gibt? Viele Grüße -- Sven Gehr / Linux-User-Nummer: 368994
Hi Sven, Am Dienstag, 7. Februar 2006 22:58 schrieb Sven Gehr:
Heute versuchte ich dann das System auszutricksen und den User mit meinem LDAP-Browser anzulegen und siehe da, dieser meldete auch das dieser User schon da wäre. Nur sehe ich ihn nicht. Weder im LDAP-Browser, noch wenn ich den LDAP mit ldapsearch auslese. Es scheint als wäre eine nicht abgeschlossene Transaktion in der LDAP-Datenbank (Vermutung) und deshalb die Frage ob es hier irgend eine Reorg-Funktion gibt?
nimm slapcat und exportiere deine db, halt den slapd an, schmeiss das was stört aus dem ldif raus, lösch das datenverzeichnis und importier es anschliessend wieder (am besten mit ldapadd statt slapadd weil dann eine schemaprüfung stattfindet sofern du es in der slapd.conf eingeschaltet hast). Diese methode ist so alt wie die openldap's, ältere Versionen hatten auch gerne mal einen korrupten index ... Gruss Falk
Am Mi 08.02.2006 07:14 schrieb Falk Sauer <falk@hb-fein.de>:
Am Dienstag, 7. Februar 2006 22:58 schrieb Sven Gehr:
Hallo [...]
nimm slapcat und exportiere deine db, halt den slapd an, schmeiss das was stört aus dem ldif raus, lösch das datenverzeichnis und importier es anschliessend wieder (am besten mit ldapadd statt slapadd weil dann eine schemaprüfung stattfindet sofern du es in der slapd.conf eingeschaltet hast).
Diese methode ist so alt wie die openldap's, ältere Versionen hatten auch gerne mal einen korrupten index ...
ok, habe ich gemacht. Im exportierten LDIF finde ich keine falsche Einträge. Soll ich dann trotdem mal versuchen nach dem backup den ldap anzuhalten, /var/lib/ldap leeren, wieder starten und Backup wieder einspielen? Konkretes Beispiel. Die User sind in ou=people,dc=pfetzer. Ich möchte den User Petra anlegen der weder im LDAP selbst noch im LDIF das ich mit slapcat erstellt habe aufgeführt ist. Wenn ich versuche den User Petra anzulegen finde ich im Logfile: slapd[15713]: conn=32 op=2 SRCH base="ou=people,dc=pfetzer" scope=0 deref=0 filter="(objectClass=*)" slapd[15713]: conn=32 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= slapd[15713]: conn=32 op=3 ADD dn="uid=petra,ou=people,dc=pfetzer" slapd[15713]: => bdb_dn2id_add: subtree (uid=petra,ou=people,dc=pfetzer) put failed: -30996 slapd[15713]: conn=32 op=3 RESULT tag=105 err=68 text= Vielleicht noch als Hinweis. Bevor der User (uid=petra) verschawnd hatte dieser noch ein Unterobjekt addr, also ou=addr,uid=petra,ou=people,dc=pfetzer Evtl. hat es ja damit was zu tun das dieser Container noch "irgendwie" da ist. Viele Grüße Sven Gehr / Linux-User-Nummer: 368994
participants (2)
-
Falk Sauer -
Sven Gehr