Hi,

Summary: it seems having a modifiersdn outside of cn=config in cn=config breaks replication once slapd is restarted.

I have a more elaborate test setup with four servers.

Two masters ldaptest1, ldaptest2 using syncrepl in mirrormode .

Two slaves ldaptest3, ldaptest4 that use syncrepl to slave from the masters.

The masters and the slaves also replicate cn=config between themselves.

Replication config is as follows:

on ldaptest1 and ldaptest2:

dn: cn=config ... olcServerID: 1 ldap://ldaptest1.cksoft.de olcServerID: 2 ldap://ldaptest2.cksoft.de olcServerID: 3 ldap://ldaptest3.cksoft.de olcServerID: 4 ldap://ldaptest4.cksoft.de

dn: olcDatabase={1}mdb,cn=config ... olcSyncrepl: rid=001 provider=ldap://ldaptest1.cksoft.de bindmethod=simple binddn="cn=replica,ou=system,dc=test" credentials="secret" keepalive=0:0:0 starttls=yes tls_cert="/usr/local/etc/openldap/certs/server.cert" tls_key="/usr/local/etc/openldap/certs/server.key" tls_cacert="/usr/local/etc/openldap/certs/cksoftware-gmbh-ca-2011-2031.cert" tls_reqcert=demand tls_crlcheck=none filter="(objectclass=*)" searchbase="dc=test" scope=sub type=refreshAndPersist retry="60 10 300 +" olcSyncrepl: rid=002 provider=ldap://ldaptest2.cksoft.de bindmethod=simple binddn="cn=replica,ou=system,dc=test" credentials="secret" keepalive=0:0:0 starttls=yes tls_cert="/usr/local/etc/openldap/certs/server.cert" tls_key="/usr/local/etc/openldap/certs/server.key" tls_cacert="/usr/local/etc/openldap/certs/cksoftware-gmbh-ca-2011-2031.cert" tls_reqcert=demand tls_crlcheck=none filter="(objectclass=*)" searchbase="dc=test" scope=sub type=refreshAndPersist retry="60 10 300 +" olcMirrorMode: TRUE

on ldaptest3 and ldaptest4:

dn: cn=config ... olcServerID: 1 ldap://ldaptest1.cksoft.de olcServerID: 2 ldap://ldaptest2.cksoft.de olcServerID: 3 ldap://ldaptest3.cksoft.de olcServerID: 4 ldap://ldaptest4.cksoft.de

dn: olcDatabase={1}mdb,cn=config ... olcSyncrepl: rid=001 provider=ldap://ldaptest1.cksoft.de bindmethod=simple binddn="cn=replica,ou=system,dc=test" credentials="secret" keepalive=0:0:0 starttls=yes tls_cert="/usr/local/etc/openldap/certs/server.cert" tls_key="/usr/local/etc/openldap/certs/server.key" tls_cacert="/usr/local/etc/openldap/certs/cksoftware-gmbh-ca-2011-2031.cert" tls_reqcert=demand tls_crlcheck=none filter="(objectclass=*)" searchbase="dc=test" scope=sub type=refreshAndPersist retry="60 10 300 +" olcSyncrepl: rid=002 provider=ldap://ldaptest2.cksoft.de bindmethod=simple binddn="cn=replica,ou=system,dc=test" credentials="secret" keepalive=0:0:0 starttls=yes tls_cert="/usr/local/etc/openldap/certs/server.cert" tls_key="/usr/local/etc/openldap/certs/server.key" tls_cacert="/usr/local/etc/openldap/certs/cksoftware-gmbh-ca-2011-2031.cert" tls_reqcert=demand tls_crlcheck=none filter="(objectclass=*)" searchbase="dc=test" scope=sub type=refreshAndPersist retry="60 10 300 +" olcMirrorMode: FALSE

Once I modify something trivial like olcLogLevel on the slaves using my personal dn, cn=config will have following operational attributes:

# config dn: cn=config structuralObjectClass: olcGlobal entryUUID: dc78e00a-461a-1032-9454-cd151c72b364 creatorsName: cn=config createTimestamp: 20130430194949Z entryCSN: 20130526075059.867187Z#000000#004#000000 modifiersName: uid=ckratzer,ou=people,dc=test modifyTimestamp: 20130526075059Z contextCSN: 20130526074631.636527Z#000000#003#000000 contextCSN: 20130526075059.867187Z#000000#004#000000 entryDN: cn=config subschemaSubentry: cn=Subschema

I then restart slapd on the first slave ldaptest3 and leave it running on ldaptest4.

A change replicated from the masters will appear on ldaptest4 just fine.

The restarted master on ldaptest3 fails to apply the change

May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_message_to_entry: rid=001 DN: cn=test,dc=test, UUID: 3e48a550-4dd1-1032-9f9f-47169a206073 May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=001 inserted UUID 3e48a550-4dd1-1032-9f9f-47169a206073 May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=001 be_search (0) May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=001 cn=test,dc=test May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=001 entry unchanged, ignored (cn=test,dc=test,) May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_updateCookie: rid=001 be_modify failed (17) May 26 10:06:13 ldaptest3 slapd[2410]: do_syncrepl: rid=001 rc 17 retrying May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_message_to_entry: rid=002 DN: cn=test,dc=test, UUID: 3e48a550-4dd1-1032-9f9f-47169a206073 May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=002 inserted UUID 3e48a550-4dd1-1032-9f9f-47169a206073 May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=002 be_search (0) May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=002 cn=test,dc=test, May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_entry: rid=002 entry unchanged, ignored (cn=test,dc=test,) May 26 10:06:13 ldaptest3 slapd[2410]: syncrepl_updateCookie: rid=002 be_modify failed (17) May 26 10:06:13 ldaptest3 slapd[2410]: do_syncrepl: rid=002 rc 17 retrying

I currently have customer data in above test setup so I had to do some obfuscation in above samples and logs. If required I can setup maximally stripped down case that illustrates the problem.

Would it be possible to mask modifiersName inside cn=config to either a fixed value just append something like cn=proxied,cn=config to dns outside of cn=config.

Greetings Christian