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

Reply via email to