On Tue, Apr 17, 2012 at 15:32, Rich Megginson <rmegg...@redhat.com> wrote: > On 04/17/2012 09:59 AM, Dan Scott wrote: >> >> On Tue, Apr 17, 2012 at 10:29, Richard Megginson<rmegg...@redhat.com> >> wrote: >>> >>> ----- Original Message ----- >>>> >>>> On Tue, Apr 17, 2012 at 09:26, Rich Megginson<rmegg...@redhat.com> >>>> wrote: >>>>> >>>>> On 04/17/2012 07:26 AM, Dan Scott wrote: >>>>>> >>>>>> On Fri, Apr 13, 2012 at 17:44, Rich Megginson<rmegg...@redhat.com> >>>>>> wrote: >>>>>>> >>>>>>> On 04/13/2012 03:40 PM, Dan Scott wrote: >>>>>>>> >>>>>>>> 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? >>>>>>> >>>>>>> >>>>>>> The entry should exist, but the deleted servers should not be >>>>>>> present in >>>>>>> the >>>>>>> nsds50ruv attribute. >>>>>> >>>>>> OK, so it's safe to delete replica entries which have >>>>>> ldap://fileserver4.ecg.mit.edu:389 (fileserver4 is not currently a >>>>>> replica) but not for the other servers? >>>>> >>>>> Yes. Following the CLEANRUV procedure: >>>>> http://port389.org/wiki/Howto:CLEANRUV >>>> >>>> Thanks. I think I'm getting there - removed the tombstones from the >>>> main directory and the PKI-IPA directory (only one server so far >>>> though). I still have a few strange entries though: >>>> >>>> [root@fileserver1 ~]# ldapsearch -xLLL -D "cn=directory manager" -W >>>> -b >>>> dc=ecg,dc=mit,dc=edu >>>> >>>> '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' >>>> Enter LDAP Password: >>>> dn: >>>> nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=ecg,dc=mit,dc=edu >>>> objectClass: top >>>> objectClass: nsTombstone >>>> objectClass: extensibleobject >>>> nsds50ruv: {replicageneration} 4e7b746e000000040000 >>>> nsds50ruv: {replica 6 ldap://fileserver1.ecg.mit.edu:389} >>>> 4f50e685001d00060000 >>>> 4f8d7874000200060000 >>>> nsds50ruv: {replica 43 ldap://fileserver2.ecg.mit.edu:389} >>>> 4f88cf450001002b000 >>>> 0 4f8d78140000002b0000 >>>> nsds50ruv: {replica 5 ldap://fileserver3.ecg.mit.edu:389} >>>> 4f5047ad001d00050000 >>>> 4f8d77c3000000050000 >>>> nsds50ruv: {replica 4 ldap://fileserver3.ecg.mit.edu:389} >>>> nsds50ruv: {replica 9 ldap://fileserver3.ecg.mit.edu:389} >>>> nsds50ruv: {replica 8 ldap://fileserver3.ecg.mit.edu:389} >>>> 4f7363d2001d00080000 >>>> 4f736402000700080000 >>>> dc: ecg >>>> nsruvReplicaLastModified: {replica 6 >>>> ldap://fileserver1.ecg.mit.edu:389} 4f8d7 >>>> 806 >>>> nsruvReplicaLastModified: {replica 43 >>>> ldap://fileserver2.ecg.mit.edu:389} 4f8d >>>> 77a6 >>>> nsruvReplicaLastModified: {replica 5 >>>> ldap://fileserver3.ecg.mit.edu:389} 4f8d7 >>>> 756 >>>> nsruvReplicaLastModified: {replica 4 >>>> ldap://fileserver3.ecg.mit.edu:389} 00000 >>>> 000 >>>> nsruvReplicaLastModified: {replica 9 >>>> ldap://fileserver3.ecg.mit.edu:389} 00000 >>>> 000 >>>> nsruvReplicaLastModified: {replica 8 >>>> ldap://fileserver3.ecg.mit.edu:389} 00000 >>>> 000 >>>> >>>> Is it safe to run CLEANRUV on IDs 4 and 9? That still leaves me with >>>> 2 >>>> entries for fileserver3. How do I know which one to delete? >>> >>> Whichever one is the one currently in use. >>> >>> ldapsearch -xLLL -h fileserver3 -D "cn=directory manager" -W -b cn=config >>> cn=replica >>> >>> What is the replica ID? That is the one that is currently in use. You >>> should be able to safely delete the others. >> >> Excellent thanks. >> >> Nearly there now. >> >> I think my only remaining problems are: >> >> 1. The fileserver5.ecg.mit.edu entry (dn: >> cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu) >> which I cannot delete due to: [LDAP: error code 66 - Not Allowed On >> Non-leaf] > > > It won't let you delete the tombstones? Or it is not showing any > tombstones? > If this is due to "orphan" tombstone entries, the only resolution will be to > db2ldif, then ldif2db.
It's not showing any tombstones. Is there any documentation for "db2ldif, then ldif2db"? I guess it's the scripts in /var/lib/dirsrv/scripts-ECG-MIT-EDU/. But I'm not sure if there are any options I should be using? >> 2. One inconsistency in my replication agreements: >> ipa-csreplica-manage -v list fileserver1.ecg.mit.edu shows only >> fileserver2. >> ipa-csreplica-manage -v list fileserver3.ecg.mit.edu shows both >> fileservers 1 and 2. >> >> So, fileserver3 thinks that it's replicating fine with fileserver1, >> but fileserver1 is not replicating with fileserver3. >> >> Any ideas? > > > Not sure. You can look at the replication agreements directly using > ldapsearch: > > ldapsearch -xLLL -D "cn=directory manager" -W -b cn=config > objectclass=nsds5replicationagreement The agreements agree with the output of ipa-replica-manage list i.e. There's an entry on fileserver3 pointing to fileserver1: dn: cn=masterAgreement1-fileserver1.ecg.mit.edu-pki-ca,cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config but no equivalent entry on fileserver1. Is there an easy way to fix this? I think I have also found yet another problem. On fileserver2, the output of: ldapsearch -xLLL -D "cn=directory manager" -W -b cn=config objectclass=nsds5replicationagreement Shows lots of entries for missing replicas: nsruvReplicaLastModified: {replica 5 ldap://fileserver3.ecg.mit.edu:389} 00000 000 nsruvReplicaLastModified: {replica 4 ldap://fileserver3.ecg.mit.edu:389} 00000 000 nsruvReplicaLastModified: {replica 9 ldap://fileserver3.ecg.mit.edu:389} 00000 000 But these entries do not show up in the output of: ldapsearch -xLLL -D "cn=directory manager" -W -s sub -b cn=config objectclass=nsds5replica Do I need to run the cleanruv task for the above replica IDs? Thanks, Dan _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users