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
is still showing entries though. Is that OK?
The entry should exist, but the deleted servers should not be present in the
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:
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
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
If that doesn't work, use ldapsearch -d 1 -x ..... to get further
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
It returns a load of supportedExtension: and supportedControl: entries
- I guess that means 'working'? :)
Then I'm not sure why TLS/SSL connections with replication are not working.
Freeipa-users mailing list