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

[Rich Megginson]

On 04/17/2012 09:59 AM, Dan Scott wrote:
> 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]

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.

> 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

>
> Thanks for all your help. It's looking good now.
>
> Dan