[Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?

[Dan Scott]

On Tue, Apr 17, 2012 at 10:29, Richard Megginson <rmeggins at redhat.com> wrote:
> ----- Original Message -----
>> On Tue, Apr 17, 2012 at 09:26, Rich Megginson <rmeggins at redhat.com>
>> wrote:
>> > On 04/17/2012 07:26 AM, Dan Scott wrote:
>> >>
>> >> On Fri, Apr 13, 2012 at 17:44, Rich Megginson<rmeggins at 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 at 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