Am Mi 08.02.2006 07:14 schrieb Falk Sauer
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