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-
>> 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

Reply via email to