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] 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? Thanks for all your help. It's looking good now. Dan _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
