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

[Rich Megginson]

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
>
>>>>>>>>> fileserver3's /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of:
>>>>>>>>> [13/Apr/2012:13:52:50 -0400] slapi_ldap_bind - Error: could not send
>>>>>>>>> startTLS request: error -1 (Can't contact LDAP server) errno 107
>>>>>>>>> (Transport endpoint is not connected)
>>>>>>>>
>>>>>>>> This is a real connection error - could be cert or hostname lookup
>>>>>>>> related.
>>>>>>> How do I find out if it's cert or hostname lookup? Which hostname?
>>>>>>> Fileserver3 runs DNS, and it seems to be working fine.
>>>>>>
>>>>>> Try ldapsearch - on server3
>>>>>>
>>>>>> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-PKI-IPA ldapsearch -x -ZZ -H
>>>>>> ldap://server2.fqdn -D "cn=directory manager" -W -s base -b ""
>>>>>>
>>>>>> If that works, check to make sure the replication agreement has the
>>>>>> correct
>>>>>> server2.fqdn
>>>>>>
>>>>>> If that doesn't work, use ldapsearch -d 1 -x ..... to get further
>>>>>> debugging
>>>>>> information.
>>>>> The replication agreements (according to ipa-replica-manage) all have
>>>>> the correct host names - I'm not sure what ldapsearch command to run
>>>>> to check the replication agreements.
>>>>
>>>> ipa-replica-manage --list?  or something like that?
>>> That's what I was using - they are all correct.
>>
>> Ok.  And the LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-PKI-IPA ldapsearch ... is
>> working?
> It returns a load of supportedExtension: and supportedControl: entries
> - I guess that means 'working'? :)
Yes.

Then I'm not sure why TLS/SSL connections with replication are not working.
>
> Thanks,
>
> Dan