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

Re: Replicating Schema, olcAccess and olcLimits

Andrew Devenish-Meares wrote:

On 6/08/2013 3:56 PM, Andrew Devenish-Meares wrote:

Hi List,

I'm attempting to set up replication of schema, olcAccess and olcLimits.
    It appears replicating the schema works, but the olcAccess and
olcLimits do not appear to replicate under olcDatabase={2}bdb,cn=config.
    (Additionally the DIT under dc=une,dc=edu,dc=au is also replicated
without issue).


Having turned logging to 1024 to trace shell calls I get the following:
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: <= test_filter 5
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: send_ldap_result:
conn=-1 op=0 p=0
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: send_ldap_result: err=0
matched="" text=""
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: syncrepl_entry: rid=006
be_search (0)
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: syncrepl_entry: rid=006
olcDatabase={2}bdb,cn=config
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: slap_queue_csn: queing
0x7f23d1d2b730 20130808010713.847335Z#000000#000#000000
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: => access_allowed: add
access to "olcDatabase={2}bdb,cn=config" "entry" requested
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: <= root access granted
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: => access_allowed: add
access granted by manage(=mwrscxd)
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: <= acl_access_allowed:
granted to database root
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: conn=-1 op=0:
config_add_internal: DN="olcDatabase={2}bdb,cn=config" already exists
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: send_ldap_result:
conn=-1 op=0 p=0
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: send_ldap_result: err=68
matched="" text=""
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]:
slap_graduate_commit_csn: removing 0x7f23d1d2bae0
20130808010713.847335Z#000000#000#000000
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: syncrepl_entry: rid=006
be_add olcDatabase={2}bdb,cn=config (68)
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: => access_allowed:
search access to "olcDatabase={2}bdb,cn=config" "entry" requested
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: <= root access granted
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: => access_allowed:
search access granted by manage(=mwrscxd)
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: => test_filter
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]:     PRESENT
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: => access_allowed:
search access to "olcDatabase={2}bdb,cn=config" "objectClass" requested
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: <= root access granted
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: => access_allowed:
search access granted by manage(=mwrscxd)
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: <= test_filter 6
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: send_ldap_result:
conn=-1 op=0 p=0
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: send_ldap_result: err=0
matched="" text=""
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: <= acl_access_allowed:
granted to database root
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: send_ldap_result:
conn=-1 op=0 p=0
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: send_ldap_result: err=67
matched="" text="Use modrdn to change the entry name"
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: null_callback : error
code 0x43
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: syncrepl_entry: rid=006
be_modify olcDatabase={2}bdb,cn=config (67)
Aug  8 11:07:13 ldap-slave-dev-00 slapd[19914]: syncrepl_entry: rid=006
be_modify failed (67)

My reading of this suggests that the existance of the
olcDatabase={2}bdb,cn=config is causing an issue.  I'm unsure how to
proceed at this point.

Any help would be appreciated.
When syncrepl's Add attempt fails, it falls back to doing a Modify, trying to set whatever attribute values differ between the local entry and the syncrepl update. In this particular case, it seems that syncrepl thinks the two entries' RDNs are not exactly the same, so it tries to modify them as well. Your log shows that this attempt also fails (err=67). You'll have to doublecheck that the local and remote entries have exactly identical DNs. 

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/