On Fri, Apr 13, 2012 at 16:41, Rich Megginson <rmegg...@redhat.com> wrote: > On 04/13/2012 02:30 PM, Dan Scott wrote: >> >> On Fri, Apr 13, 2012 at 15:24, Rich Megginson<rmegg...@redhat.com> wrote: >>> It's not a problem until it's a problem :-) I would go ahead and run >>> CLEANRUV. >> >> I cleaned up a load of these entries, but now I think I've broken the >> replication between fileserver1 and 3: >> >> fileserver1:/var/log/dirsrv/slapd-ECG-MIT-EDU/errors >> [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - changelog program >> - agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): CSN >> 4f5039960000002b0000 not found, we aren't as up to date, or we purged >> [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - >> agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): Data required >> to update replica has been purged. The replica must be reinitialized. >> [13/Apr/2012:15:57:56 -0400] NSMMReplicationPlugin - >> agmt="cn=meTofileserver3.ecg.mit.edu" (fileserver3:389): Incremental >> update failed and requires administrator action >> >> fileserver3:/var/log/dirsrv/slapd-ECG-MIT-EDU/errors >> [13/Apr/2012:16:19:38 -0400] NSMMReplicationPlugin - changelog program >> - agmt="cn=meTofileserver1.ecg.mit.edu" (fileserver1:389): CSN >> 4f031e76001d000b0000 not found, we aren't as up to date, or we purged >> >> Is it safe to run: >> [root@fileserver3 ~]# ipa-replica-manage re-initialize --from >> fileserver1.ecg.mit.edu >> >> I want to make sure I get it the correct way round! > > > Are you sure that fileserver1 has the correct data?
Maybe? :) I've snapshotted both VMs and re-initialized from fileserver1 - looking good so far. I cleaned up all the "ruv_compare_ruv: RUV [changelog max RUV] does not contain element" errors in the logs for each of fileservers 1, 2 and 3. The ldapsearch for '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' is still showing entries though. Is that OK? Also, the PKI-CA error logs are showing RUV errors, should I clean those too? I guess that I need to modify the commands (-b o=ipaca -p 7389 -h localhost). >>>>>> fileserver3's /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of: >>>>>> [13/Apr/2012:13:52:50 -0400] slapi_ldap_bind - Error: could not send >>>>>> startTLS request: error -1 (Can't contact LDAP server) errno 107 >>>>>> (Transport endpoint is not connected) >>>>> >>>>> >>>>> This is a real connection error - could be cert or hostname lookup >>>>> related. >>>> >>>> How do I find out if it's cert or hostname lookup? Which hostname? >>>> Fileserver3 runs DNS, and it seems to be working fine. >>> >>> >>> Try ldapsearch - on server3 >>> >>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-PKI-IPA ldapsearch -x -ZZ -H >>> ldap://server2.fqdn -D "cn=directory manager" -W -s base -b "" >>> >>> If that works, check to make sure the replication agreement has the >>> correct >>> server2.fqdn >>> >>> If that doesn't work, use ldapsearch -d 1 -x ..... to get further >>> debugging >>> information. >> >> The replication agreements (according to ipa-replica-manage) all have >> the correct host names - I'm not sure what ldapsearch command to run >> to check the replication agreements. > > > ipa-replica-manage --list? or something like that? That's what I was using - they are all correct. >>>> The /var/log/dirsrv/slapd-ECG-MIT-EDU/errors is >>>> now full of: >>>> >>>> [13/Apr/2012:14:59:19 -0400] NSMMReplicationPlugin - conn=1 op=571 >>>> csn=4f70a9e5000100060000: Can't created glue entry >>>> cn=fileserver4.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu >>>> uniqueid=6949d104-775b11e1-abce82a1-a45dd3c3, error 68 >>>> >>>> Should I delete the LDAP entry which is trying to replicate >>>> fileserver2 with fileserver4? >>> >>> >>> Yes. And it may be due to the fact that the entry it is trying to delete >>> has those tombstone children that have to be deleted too. >> >> OK, I'll see how this goes, once the tombstones are gone. The tombstones for ECG-MIT-EDU are gone now, still receiving this message in the logs. I think that's enough for this week - I'll look into it more next week. Thanks for your help, have a good weekend. Dan _______________________________________________ Freeipa-users mailing list Freeipaemail@example.com https://www.redhat.com/mailman/listinfo/freeipa-users