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

[Dan Scott]

On Tue, Apr 17, 2012 at 15:32, Rich Megginson <rmeggins at redhat.com> wrote:
> 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.

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