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.
Scott .
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
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
On 09/11/2009 14:33, Scott Behrens wrote:
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
This log just shows slapd being shut down and restarted. Nothing connection related - did you restart slapd after changing the loglevel in slapd.conf? Without more logs, it's hard to tell what's going on.
A good test would be to use ldapsearch directly to interrogate your two servers. This will help determine whether the problem is coming from your LDAP server(s) or your system authentication settings.
Hope this helps, Jonathan
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 Clarkejonathan@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
I restarted slapd after changing the log setting in slapd.conf. I also noticed that when doing a ldapsearch from the client host, it always searched the primary. Nothing seems to be happening on the replica:
ldapsearch -xLLL -b "dc=domain,dc=com"
Nothing in replica ldap.log. In primary log:
ov 9 08:42:23 mnetmgt1 slapd[14019]: >>> slap_listener(ldap:///) Nov 9 08:42:23 mnetmgt1 slapd[14019]: connection_get(21): got connid=69 Nov 9 08:42:23 mnetmgt1 slapd[14019]: connection_read(21): checking for input on id=69 Nov 9 08:42:23 mnetmgt1 slapd[14019]: do_bind Nov 9 08:42:23 mnetmgt1 slapd[14019]: >>> dnPrettyNormal: <> Nov 9 08:42:23 mnetmgt1 slapd[14019]: <<< dnPrettyNormal: <>, <> Nov 9 08:42:23 mnetmgt1 slapd[14019]: do_bind: version=3 dn="" method=128 Nov 9 08:42:23 mnetmgt1 slapd[14019]: send_ldap_result: conn=69 op=0 p=3 Nov 9 08:42:23 mnetmgt1 slapd[14019]: send_ldap_response: msgid=1 tag=97 err=0 Nov 9 08:42:23 mnetmgt1 slapd[14019]: do_bind: v3 anonymous bind Nov 9 08:42:23 mnetmgt1 slapd[14019]: connection_get(21): got connid=69 Nov 9 08:42:23 mnetmgt1 slapd[14019]: connection_read(21): checking for input on id=69 Nov 9 08:42:23 mnetmgt1 slapd[14019]: do_search Nov 9 08:42:23 mnetmgt1 slapd[14019]: >>> dnPrettyNormal: <dc=domain,dc=com> Nov 9 08:42:23 mnetmgt1 slapd[14019]: <<< dnPrettyNormal: <dc=domain,dc=com>, <dc=domain,dc=com> Nov 9 08:42:23 mnetmgt1 slapd[14019]: ==> limits_get: conn=69 op=1 dn="[anonymous]" Nov 9 08:42:23 mnetmgt1 slapd[14019]: => bdb_search Nov 9 08:42:23 mnetmgt1 slapd[14019]: bdb_dn2entry("dc=domain,dc=com") Nov 9 08:42:23 mnetmgt1 slapd[14019]: search_candidates: base="dc=domain,dc=com" (0x00000001) scope=2 Nov 9 08:42:23 mnetmgt1 slapd[14019]: => bdb_dn2idl("dc=domain,dc=com") Nov 9 08:42:23 mnetmgt1 slapd[14019]: => bdb_presence_candidates (objectClass) Nov 9 08:42:23 mnetmgt1 slapd[14019]: bdb_search_candidates: id=-1 first=1 last=27 Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="cn=Manager,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="ou=profile,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="ou=People,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="ou=Group,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="cn=Users,ou=Group,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="cn=proxyagent,ou=profile,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="cn=default,ou=profile,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="cn=tls_profile,ou=profile,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="uid=bobbyt,ou=People,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="ou=Groups,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="cn=bobbyt,ou=Groups,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="uid=jenkins,ou=People,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="uid=scott,ou=People,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="cn=developers,ou=Group,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="cn=developers,ou=Groups,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="uid=izaydlin,ou=People,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="cn=izaydlin,ou=Groups,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="uid=egutman,ou=People,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="cn=egutman,ou=Groups,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="uid=trodgers,ou=People,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: => send_search_entry: conn 69 dn="cn=trodgers,ou=Groups,dc=domain,dc=com" Nov 9 08:42:23 mnetmgt1 slapd[14019]: <= send_search_entry: conn 69 exit. Nov 9 08:42:23 mnetmgt1 slapd[14019]: send_ldap_result: conn=69 op=1 p=3 Nov 9 08:42:23 mnetmgt1 slapd[14019]: send_ldap_response: msgid=2 tag=101 err=0 Nov 9 08:42:23 mnetmgt1 slapd[14019]: connection_get(21): got connid=69 Nov 9 08:42:23 mnetmgt1 slapd[14019]: connection_read(21): checking for input on id=69 Nov 9 08:42:23 mnetmgt1 slapd[14019]: ber_get_next on fd 21 failed errno=0 (Success) Nov 9 08:42:23 mnetmgt1 slapd[14019]: connection_closing: readying conn=69 sd=21 for close Nov 9 08:42:23 mnetmgt1 slapd[14019]: do_unbind Nov 9 08:42:23 mnetmgt1 slapd[14019]: connection_close: deferring conn=69 sd=-1 Nov 9 08:42:23 mnetmgt1 slapd[14019]: connection_resched: attempting closing conn=69 sd=21 Nov 9 08:42:23 mnetmgt1 slapd[14019]: connection_close: conn=69 sd=-1
On Mon, Nov 9, 2009 at 7:58 AM, Jonathan Clarke jonathan@phillipoux.net wrote:
On 09/11/2009 14:33, Scott Behrens wrote:
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
This log just shows slapd being shut down and restarted. Nothing connection related - did you restart slapd after changing the loglevel in slapd.conf? Without more logs, it's hard to tell what's going on.
A good test would be to use ldapsearch directly to interrogate your two servers. This will help determine whether the problem is coming from your LDAP server(s) or your system authentication settings.
Hope this helps, Jonathan
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 Clarkejonathan@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
----- "Scott Behrens" sbehrens@gmail.com wrote:
I restarted slapd after changing the log setting in slapd.conf. I also noticed that when doing a ldapsearch from the client host, it always searched the primary. Nothing seems to be happening on the replica:
ldapsearch -xLLL -b "dc=domain,dc=com"
Let's see your client configuration. For ldapsearch, that should be /etc/openldap/ldap.conf, and any .ldaprc or similar files if you have created them. For nss_ldap, that means /etc/ldap.conf and possibly /root/.ldaprc or similar.
In essence, how did you "point the client at the replice" ?
Regards, Buchan
Here is how I am pointing to the replica.
# @(#)$Id: ldap.conf,v 1.38 2006/05/15 08:13:31 lukeh Exp $ base dc=domainname,dc=com timelimit 30
bind_timelimit 30 idle_timelimit 3600
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
#pam_sasl_mech DIGEST-MD5 # Replica IP uri ldap://10.10.1.31 ssl no tls_cacertdir /etc/openldap/cacerts pam_password md5 ~
On Mon, Nov 9, 2009 at 10:34 AM, Buchan Milne bgmilne@staff.telkomsa.net wrote:
----- "Scott Behrens" sbehrens@gmail.com wrote:
I restarted slapd after changing the log setting in slapd.conf. I also noticed that when doing a ldapsearch from the client host, it always searched the primary. Nothing seems to be happening on the replica:
ldapsearch -xLLL -b "dc=domain,dc=com"
Let's see your client configuration. For ldapsearch, that should be /etc/openldap/ldap.conf, and any .ldaprc or similar files if you have created them. For nss_ldap, that means /etc/ldap.conf and possibly /root/.ldaprc or similar.
In essence, how did you "point the client at the replice" ?
Regards, Buchan
Does this help? I would really love to get this working!
Scott
On Wed, Nov 11, 2009 at 10:55 AM, Scott Behrens sbehrens@gmail.com wrote:
Here is how I am pointing to the replica.
# @(#)$Id: ldap.conf,v 1.38 2006/05/15 08:13:31 lukeh Exp $ base dc=domainname,dc=com timelimit 30
bind_timelimit 30 idle_timelimit 3600
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
#pam_sasl_mech DIGEST-MD5 # Replica IP uri ldap://10.10.1.31 ssl no tls_cacertdir /etc/openldap/cacerts pam_password md5 ~
On Mon, Nov 9, 2009 at 10:34 AM, Buchan Milne bgmilne@staff.telkomsa.net wrote:
----- "Scott Behrens" sbehrens@gmail.com wrote:
I restarted slapd after changing the log setting in slapd.conf. I also noticed that when doing a ldapsearch from the client host, it always searched the primary. Nothing seems to be happening on the replica:
ldapsearch -xLLL -b "dc=domain,dc=com"
Let's see your client configuration. For ldapsearch, that should be /etc/openldap/ldap.conf, and any .ldaprc or similar files if you have created them. For nss_ldap, that means /etc/ldap.conf and possibly /root/.ldaprc or similar.
In essence, how did you "point the client at the replice" ?
Regards, Buchan
On 12/11/2009 18:50, Scott Behrens wrote:
Does this help? I would really love to get this working!
I suggest checking the basics: use ldapsearch to search your replica, and check it's logs. Add the -H option to the ldapsearch command you used previously.
If this works as expected, then the problem is somewhere in the client configuration files. If it doesn't, the server logs should help clear up why.
Hope this helps, Jonathan
Scott
On Wed, Nov 11, 2009 at 10:55 AM, Scott Behrenssbehrens@gmail.com wrote:
Here is how I am pointing to the replica.
# @(#)$Id: ldap.conf,v 1.38 2006/05/15 08:13:31 lukeh Exp $ base dc=domainname,dc=com timelimit 30
bind_timelimit 30 idle_timelimit 3600
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
#pam_sasl_mech DIGEST-MD5 # Replica IP uri ldap://10.10.1.31 ssl no tls_cacertdir /etc/openldap/cacerts pam_password md5 ~
On Mon, Nov 9, 2009 at 10:34 AM, Buchan Milne bgmilne@staff.telkomsa.net wrote:
----- "Scott Behrens"sbehrens@gmail.com wrote:
I restarted slapd after changing the log setting in slapd.conf. I also noticed that when doing a ldapsearch from the client host, it always searched the primary. Nothing seems to be happening on the replica:
ldapsearch -xLLL -b "dc=domain,dc=com"
Let's see your client configuration. For ldapsearch, that should be /etc/openldap/ldap.conf, and any .ldaprc or similar files if you have created them. For nss_ldap, that means /etc/ldap.conf and possibly /root/.ldaprc or similar.
In essence, how did you "point the client at the replice" ?
Regards, Buchan
openldap-technical@openldap.org
-
Buchan Milne -
Jonathan Clarke -
Scott Behrens