[Freeipa-users] IPA Replica Issue

[Rich Megginson]

On 06/05/2013 07:20 PM, JR Aquino wrote:
> 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'
ok - try this
dbscan -k 000000de000000000000 -f /var/lib/dirsrv/slapd-INST/cldb/xxxxxx.db4
and
dbscan -k 0000014d000000000000 -f /var/lib/dirsrv/slapd-INST/cldb/xxxxxx.db4

If that gives you nothing, then just tell me what the first and last 
csns are.

>
>> 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.aquino at citrix.com<mailto:jr.aquino at citrixonline.com>
>>> http://www.citrixonline.com<http://www.citrixonline.com/>
>>>
>>>
>>> _______________________________________________
>>> Freeipa-users mailing list
>>> Freeipa-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-users