[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd

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

-- 
Christian Kratzer                      CK Software GmbH
Email:   ck@cksoft.de                  Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0          D-71126 Gaeufelden
Fax:     +49 7032 893 997 - 9          HRB 245288, Amtsgericht Stuttgart
Web:     http://www.cksoft.de/         Geschaeftsfuehrer: Christian Kratzer