The client pointing to the replica is a 3rd host also running centOS. OpenLDAP 2.3.43. I can pretty much narrow down the issue to configuration, our network/server config side is pretty straightforward.
I turned the logging to 256 on the replica, I pointed my client using authconfig to the replica.
su - ldapuser
Just hangs, in the logs on replica:
Nov 9 02:25:48 mnetmgt2 slapd[30963]: slapd shutdown: initiated Nov 9 02:25:48 mnetmgt2 slapd[30963]: ====> bdb_cache_release_all Nov 9 02:25:48 mnetmgt2 slapd[30963]: slapd destroy: freeing system resources. Nov 9 02:25:48 mnetmgt2 slapd[30963]: slapd stopped. Nov 9 02:25:48 mnetmgt2 slapd[15086]: @(#) $OpenLDAP: slapd 2.3.43 (Jan 21 2009 03:59:37) $ mockbuild@builder10.centos.org:/builddir/build/BUILD/openldap-2.3.43/openldap-2.3.43/build-servers/servers/slapd Nov 9 02:25:48 mnetmgt2 slapd[15087]: slapd starting
If I point it back to the primary, it works fine. Here are the slapd files, they look correct based on what I read in the documentation.
Primary Slapd.conf:
include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/solaris.schema include /etc/openldap/schema/sudo.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/openldap.schema
# DATABASE CONFIG database bdb suffix "dc=domain,dc=com" rootdn "cn=Manager,dc=domain,dc=com" rootpw {SSHA}somepassword
directory /var/lib/ldap
index entryCSN,entryUUID eq,pres index objectClass,uid,uidNumber,gidNumber,ou eq index cn,mail,surname,givenname eq,subinitial index memberUid eq index nisDomain eq index uniqueMember pres #index sudoUser eq,sub
overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 loglevel 1
# Performance tuning directives sizelimit 5000 threads 16 idletimeout 14400 cachesize 10000 checkpoint 256 15 password-hash {SSHA}
Replica slapd.conf file:
nclude /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/solaris.schema include /etc/openldap/schema/sudo.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/duaconf.schema
pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args
# DATABASE CONFIG database bdb suffix "dc=domain,dc=com" rootdn "cn=Manager,dc=domain,dc=com" rootpw {SSHAsomehash
index entryCSN,entryUUID eq,pres directory /var/lib/ldap loglevel 256
syncrepl rid=001 provider=ldap://10.10.1.91 interval=00:05:00:00 bindmethod=simple scope=sub filter="(objectClass=organizationalPerson)" attrs="cn,sn,ou,telephoneNumber,title,l" searchbase="dc=matlock,dc=com" binddn="cn=proxyagent,ou=profile,dc=matlock,dc=com" credentials="abc123" schemachecking=off type=refreshAndPersist retry="60 +"
# Indices to maintain
index objectClass,uid,uidNumber,gidNumber,ou eq index cn,mail,surname,givenname eq,subinitial index memberUid eq index nisDomain eq index uniqueMember pres
# Performance tuning directives sizelimit 5000 threads 16 idletimeout 14400 cachesize 10000 checkpoint 256 15 password-hash {SSHA}
On Mon, Nov 9, 2009 at 3:16 AM, Jonathan Clarke jonathan@phillipoux.net wrote:
On 06/11/2009 15:31, Scott Behrens wrote:
Hello,
I am running 2 hosts CentOS release 5.3 (Final) with kernel 2.6.18-164.el5l.
One box is the provider and the other is a consumer using syncrepl. When the primary goes down, I can perform searches against the domain from the replica so I know the replica has replicated the data (when I stop both hosts I can't preform the search obviously). When I point a client to the replica, I get a timeout when trying to perform searches or pull data. ldap_bind: Can't contact LDAP server (-1).
Any ideas? I will provide more information if needed.
Hi,
Which client are you pointing to the replica? ldapsearch? And what version of OpenLDAP are you running?
This is a pretty vague error, many things could be the cause: bad client setup, network problems, server problems...
I suggest you check out the logs from the server you're trying to connect to, having previously set them to include "stats" (level 256).
Hope this helps, Jonathan