Problem mit LDAP-Replikation zum Schulserver

UCS@school
#1

Hallo,

ich habe hier in einer Testumgebung ein Problem festgestellt, welches die LDAP-Replikation vom DC-Master zu einem Schulserver betrifft.

Ich habe schon versucht, durch manuellen Restart des slapd (auf dem Schulserver) das failed.ldif-File einzulesen, aber dies scheitert.

/var/log/univention/listener.log:

22.10.14 16:57:13.827  LISTENER    ( WARN    ) : Failed to delete non leaf object: dn=[cn=BRGSCustom,cn=custom attributes,cn=univention,dc=domain,dc=local];
22.10.14 16:57:13.828  LISTENER    ( ERROR   ) : dn=cn=BRGSCustom,cn=custom attributes,cn=univention,dc=domain,dc=local: Operation not allowed on non-leaf
22.10.14 16:57:13.828  LISTENER    ( ERROR   ) :        additional info: subordinate objects must be deleted first
22.10.14 16:57:13.828  LISTENER    ( ERROR   ) : Could not write to transaction file /var/lib/univention-ldap/listener/listener. Check for /var/lib/univention-directory-replication/failed.ldif

22.10.14 16:57:13.828  LISTENER    ( ERROR   ) : listener: -1
Try to sync changes stored in /var/lib/univention-directory-replication/failed.ldif into local LDAP
waiting for listener-shutdown  . . . . . . . shutdown done
replay stored changes ...
some DNs have failed and have to be synced manually:
cn=BRGSCustom,cn=custom attributes,cn=univention,dc=domain,dc=local

You can find the failed modifications in /tmp/file3y67vr
Check them for being sync with the master-LDAP, then delete /var/lib/univention-directory-replication/failed.ldif and start the listener again typing:
/etc/init.d/univention-directory-listener start

/tmp/file3y67vr:

# Error: Operation not allowed on non-leaf (66), additional info: subordinate objects must be deleted first
dn: cn=BRGSCustom,cn=custom attributes,cn=univention,dc=domain
 ,dc=local
changetype: delete

Der angegebene DN wurde auf dem Master gelöscht. Er enthielt ein Unterobjekt.

Mir ist nun nicht so ganz klar, was ich wo genau machen muss, um die Server wieder synchron zu bekommen.

Mit ldapdelete konnte ich auf dem lokalen System nichts löschen:

root@sydney:/var# ldapdelete -D "uid=Administrator,cn=users,dc=domain,dc=local" -W 'cn=BRGSCustom,cn=custom attributes,cn=univention,dc=domain,dc=local' -p 7389 -h sydney.domain.local
Enter LDAP Password: *********
ldap_delete: Referral (10)
        referrals:
                ldap://aldebaran.domain.local:7389/cn=BRGSCustom,cn=custom%20attributes,cn=univention,dc=domain,dc=local

(sydney ist der Schulserver, während aldebaran der DC-Master ist)

Ein lokaler ldapsearch findet die Objekte weiterhin…

Gruß,
H.Röhrup

#2

Ich konnte das Problem jetzt selbst lösen, indem ich die Datei failed.ldif von Hand bearbeitet habe und die Unterobjekte dadurch zuerst löschen ließ. Nach zwei weiteren slapd-Restarts und weiteren von Hand zu bearbeitenden Fehlern in der failed.ldif wurde dann auch alles wieder synchronisert.

Mir ist zwar schleierhaft, wie dies überhaupt dazu kommen konnte, aber ich vermute, dass ich wohl zwei Operationen zu schnell hintereinander auf dem selben Objekt durchgeführt habe und dies dem Listener nicht geschmeckt hat. (Objekt wurde zuerst umbenannt und unmittelbar danach dann doch gelöscht…)

Gruß,
H.Röhrup

Mastodon