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: [email protected] 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
