On Jun 5, 2013, at 5:26 PM, Rich Megginson wrote: > On 06/05/2013 05:49 PM, JR Aquino wrote: >> I have been having replication issues since the update to RHEL6.4 and >> 389-ds-base-1.2.11.15-12. >> >> It is entirely possible that we have more than just 1 problem. >> >> Frequently we seeing errors in our replication monitoring indicating: -1 >> Incremental update has failed and requires administrator actionLDAP error: >> Can't contact LDAP server >> >> This problem cannot be solved via ipa-replication-managment force-sync and >> it does not get permanently solved with a re-initializeation or a dirsrv >> restart either (the problem eventually comes back or appears on a different >> server) >> >> Have any of you also seen this error when you could verify that the servers >> can communicate over ldap? >> >> When checking with Rich today in IRC, we turned on debugging for replication >> and did not see a smoking gun. >> >> We -did- see log messages showing things like: (auth1:389): CSN >> 51ad2c55000900660000 not found, we aren't as up to date, or we purged > > On replicaID 0x66 - I think dbscan -f > /var/lib/dirsrv/slapd-INST/cldb/xxxxxx.db4 will tell you what are the purge > and max CSNs, somewhere near the beginning - what are they?
I've looked up and down the dbscan output and there is no sign of the word 'purge' or 'max' > Also, what is the database RUV on 0x66? that is, do > > ldapsearch -xLLL -h 0x66hostname -D "cn=directory manager" -w password -b > dc=expertcity,dc=com > '(&(objectclass=nsTombstone)(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff))' I've sent you a private email from for the above output > >> >> When looking for this change, it was determined that the originating IPA >> server who was responsible for the change show that this was a modification >> by the MemberOf plugin associating a host with a hostgroup or vice versa. >> >> This change was -not- found on the IPA server who is reporting the >> replication troubles. >> >> IPA deliberately excludes memberof changes during incremental updates for >> performance reasons. This is because each server does replicate the >> 'member' info, where by the local MemberOf plugin will fire off and perform >> its respective fixups accordingly. >> >> Rich asked me to bring this issue up to the attention of the mailing list so >> that we could continue to track the root cause of the issue(s) and hopefully >> come to a conclusion about how to fix them. >> >> >> "Keeping your head in the cloud" >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Jr Aquino | Sr. Information Security Specialist >> GXPN | GIAC Exploit Researcher and Advanced Penetration Tester >> GCIH | GIAC Certified Incident Handler >> GWAPT | GIAC WebApp Penetration Tester >> >> Citrix Online | 7408 Hollister Avenue | Goleta, CA >> 93117<x-apple-data-detectors://0/0> >> T: +1 805.690.3478<tel:+1%C2%A0805.690.3478> >> C: +1 805.717.0365<tel:+1%20805.717.0365> >> jr.aqu...@citrix.com<mailto:jr.aqu...@citrixonline.com> >> http://www.citrixonline.com<http://www.citrixonline.com/> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users@redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
