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).
The syncprov overlay is in place root@ldap-master-dev [DEV] ~/ldap-config/# ldapsearch -Y EXTERNAL -H ldapi:// -LL -b olcOverlay={0}syncprov,olcDatabase={0}config,cn=config SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 version: 1
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov
The SyncUser has access to read the cn=schema,cn=config and olcDatabase={2}bdb,cn=config branches: root@ldap-master-dev [DEV] ~/ldap-config/# ldapsearch -Y EXTERNAL -H ldapi:// -LL -b olcDatabase={0}config,cn=config olcAccess SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 version: 1
dn: olcDatabase={0}config,cn=config olcAccess: {0}to dn.subtree="cn=schema,cn=config" by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn="cn=SyncUser,dc=une,dc=edu,dc=au" read by * none olcAccess: {1}to dn.subtree="olcDatabase={2}bdb,cn=config" by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn="cn=SyncUser,dc=une,dc=edu,dc=au" read by * none olcAccess: {2}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
On the consumer side, I've added the following two olcSyncRepl enteries to the olcDatabase={2}bdb,cn=config:
root@ldap-slave-dev-00 [DEV] ~/ldap-slave-config/# ldapsearch -Y EXTERNAL -H ldapi:/// -LL -b olcDatabase={0}config,cn=config olcSyncRepl SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 version: 1
dn: olcDatabase={0}config,cn=config olcSyncrepl: {0}rid=001 provider=ldap://ldap-master-dev.server.une.edu.au bindmethod=simple binddn="cn=SyncUser,dc=une,dc=edu,dc=au" credentials="PASSWORD" searchbase="cn=schema,cn=config" type=refreshAndPersistinterval=00:00:00:10 retry="5 5 300 5" timeout=1 olcSyncrepl: {1}rid=003 provider=ldap://ldap-master-dev.server.une.edu.au bindmethod=simple binddn="cn=SyncUser,dc=une,dc=edu,dc=au" credentials="PASSWORD" searchbase="olcDatabase={2}bdb,cn=config" attrs="olcDbIndex,olcDbConfig,olcAccess,olcLimits" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 5" timeout=1
I don't follow why this doesn't work.
Any suggestions?
Thanks
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.
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.
On 8/08/2013 12:15 PM, Howard Chu wrote:
Andrew Devenish-Meares wrote:
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.
Thanks for that Howard. Progress is being made.
Now when I update an olcAccess attribute on the master I'm getting a "CSN too old" error.
Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: connection_get(15) Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: connection_get(15): got connid=0 Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: =>do_syncrepl rid=006 Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: =>do_syncrep2 rid=006 Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: do_syncrep2: rid=006 cookie=rid=006,csn=20130808045819.993645Z#000000#000#000000 Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: <<< dnPrettyNormal: <cn=config>, <cn=config> Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: >>> dnNormalize: <cn=config> Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: <<< dnNormalize: <cn=config> Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: >>> dnNormalize: <cn=config> Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: <<< dnNormalize: <cn=config> Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: <= str2entry(cn=config) -> 0x7f8ee99ede08 Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: <= acl_access_allowed: granted to database root Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: ldif_write_entry: wrote entry "cn=config" Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: send_ldap_result: conn=-1 op=0 p=0 Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: send_ldap_result: err=0 matched="" text="" Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: send_ldap_result: conn=-1 op=0 p=0 Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: send_ldap_result: err=0 matched="" text="" Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: slap_graduate_commit_csn: removing 0x7f8ecc109130 20130808045819.993645Z#000000#000#000000 Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: do_syncrep2: rid=006 CSN too old, ignoring 20130808045819.993645Z#000000#000#000000 Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: daemon: activity on 1 descriptor Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: daemon: activity on: Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Aug 8 14:58:20 ldap-slave-dev-00 slapd[24927]: daemon: epoll: listen=9 active_threads=0 tvp=NULL
Both servers are synced via NTP with our onsite time servers. root@ldap-master-dev [DEV] ~/# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *ntp1.une.edu.au 129.180.1.14 2 u 281 1024 377 0.719 0.575 0.769 +ntp2.une.edu.au 129.180.126.10 2 u 856 1024 377 0.862 0.603 0.190
root@ldap-slave-dev-00 [DEV] ~/ldap-slave-config/# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== +ntp1.une.edu.au 129.180.1.14 2 u 546 1024 377 0.759 0.359 0.413 *ntp2.une.edu.au 129.180.126.10 2 u 298 1024 377 1.141 0.619 1.080
It doesn't seem like time should be an issue. Updating an entry in the main DB dc=une,dc=edu,dc=au works as expected.
Any suggestions of where to look now?
Thanks
openldap-technical@openldap.org
-
Andrew Devenish-Meares -
Howard Chu