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