Hello,
We are running OpenLDAP 2.4.23. Part of our implementation proxies to an Active Directory server. Whenever connectivity to the AD server is interrupted, queries to the non-proxied portion of our implementation take a very long time and cause many issues with querying services.
I have been looking at timeout options for both slapd.conf and ldap.conf and I have found the following:
ldap.conf:
NETWORK_TIMEOUT <integer> Specifies the timeout (in seconds) after which the poll(2)/select(2) following a connect(2) returns in case of no activity.
TIMEOUT <integer> Specifies a timeout (in seconds) after which calls to synchronous LDAP APIs will abort if no response is received. Also used for any ldap_result(3) calls where a NULL timeout parameter is supplied.
slapd.conf:
idletimeout <integer> Specify the number of seconds to wait before forcibly closing an idle client connection. A idletimeout of 0 disables this feature. The default is 0. You may also want to set the writetimeout option.
writetimeout <integer> Specify the number of seconds to wait before forcibly closing a connection with an outstanding write. This allows recovery from various network hang conditions. A writetimeout of 0 disables this feature. The default is 0.
I am wondering which timeout values would be best to set in order to speed up queries when proxy connectivity is interrupted. Perhaps there is something else wrong with our config that is causing this issue.
Our ldap.conf file is basically empty (so, using all default)
Our slapd.conf looks something like this (heavily edited to remove specific info):
##########BEGIN 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/samba3.schema include /etc/openldap/schema/lockfile.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/ldap2dns.schema include /etc/openldap/schema/radius.schema include /etc/openldap/schema/mail.schema
loglevel 256
allow bind_v2
sasl-host [REMOVED] sasl-realm [REMOVED]
pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args
modulepath /usr/lib64/openldap moduleload rwm
tool-threads 2
#TLSCipherSuite HIGH:MEDIUM:+SSLv2 #TLSCACertificatePath /etc/ssl/certs/ #TLSCertificateFile [REMOVED] #TLSCertificateKeyFile [REMOVED] #TLSVerifyClient demand
access to attrs=[REMOVED] by anonymous [REMOVED] by * [REMOVED]
access to attrs=[REMOVED] by * [REMOVED]
access to [REMOVED] by * [REMOVED]
access to [REMOVED] by * [REMOVED]
database [REMOVED] suffix "[REMOVED]" checkpoint 20480 5 cachesize 100000 directory [REMOVED]
dbconfig set_cachesize 0 268435456 1 dbconfig set_lg_max 268435456 dbconfig set_lg_bsize 16777216 dbconfig set_lk_max_objects 5000 dbconfig set_lk_max_locks 5000 dbconfig set_lk_max_lockers 50000 dbconfig set_flags DB_LOG_AUTOREMOVE
index [REMOVED] index [REMOVED] index [REMOVED]
rootdn [REMOVED] rootpw [REMOVED] syncrepl rid=[REMOVED] provider=[REMOVED] type=refreshAndPersist retry="300 +" searchbase="[REMOVED]" filter="(objectClass=*)" sizelimit="unlimited" timelimit="unlimited" scope=sub schemachecking=off bindmethod=simple binddn="[REMOVED]" credentials=[REMOVED]
database [REMOVED] suffix "[REMOVED]" checkpoint 20480 5 cachesize 100000 directory [REMOVED]
dbconfig set_cachesize 0 268435456 1 dbconfig set_lg_max 268435456 dbconfig set_lg_bsize 16777216 dbconfig set_lk_max_objects 5000 dbconfig set_lk_max_locks 5000 dbconfig set_lk_max_lockers 50000 dbconfig set_flags DB_LOG_AUTOREMOVE
index [REMOVED] index [REMOVED] index [REMOVED]
rootdn "[REMOVED]" rootpw [REMOVED] syncrepl [REMOVED] provider=[REMOVED] type=refreshAndPersist retry="300 +" searchbase="[REMOVED]" filter="(objectClass=*)" sizelimit="unlimited" timelimit="unlimited" scope=sub schemachecking=off bindmethod=simple binddn="[REMOVED]" credentials=[REMOVED]
database ldap
suffix "[REMOVED]" uri "ldap:// [REMOVED]" uri "ldap:// [REMOVED]"
rebind-as-user lastmod off chase-referrals yes
acl-bind bindmethod=simple binddn="[REMOVED]" credentials="[REMOVED]" idassert-bind bindmethod=simple binddn="[REMOVED]" credentials="[REMOVED]" mode=none flags=prescriptive idassert-authzFrom "dn.regex:.*"
overlay rwm rwm-map attribute [REMOVED] rwm-map attribute [REMOVED] rwm-map attribute [REMOVED] rwm-map attribute [REMOVED] rwm-map attribute [REMOVED] rwm-map attribute [REMOVED] rwm-map objectclass [REMOVED] rwm-map objectclass [REMOVED]
database [REMOVED]
##########END SLAPD.CONF##########
Thank You
On 03/06/2014 16:34, Jack Kielsmeier wrote:
We are running OpenLDAP 2.4.23. Part of our implementation proxies to an Active Directory server. Whenever connectivity to the AD server is interrupted, queries to the non-proxied portion of our implementation take a very long time and cause many issues with querying services.
I reported a similar issue a couple of years ago:
http://www.openldap.org/its/index.cgi/Incoming?id=7372;selectid=7372
That was with 2.4.32. I don't think it's been fixed since, but I've worked around it with a slightly unpleasant out-of-band check on our domain controllers which reconfigures OpenLDAP when it detects a DC going out of service.
Interesting.
So you basically have some sort of script that checks responsiveness. If none, it reconfigures slapd.conf and restarts the process? Seems like quite a bandaid, but it'd work.
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Liam Gretton Sent: Tuesday, June 03, 2014 2:12 PM To: openldap-technical@openldap.org Subject: Re: LDAP Proxy Timeout Values
On 03/06/2014 16:34, Jack Kielsmeier wrote:
We are running OpenLDAP 2.4.23. Part of our implementation proxies to an Active Directory server. Whenever connectivity to the AD server is interrupted, queries to the non-proxied portion of our implementation take a very long time and cause many issues with querying services.
I reported a similar issue a couple of years ago:
http://www.openldap.org/its/index.cgi/Incoming?id=7372;selectid=7372
That was with 2.4.32. I don't think it's been fixed since, but I've worked around it with a slightly unpleasant out-of-band check on our domain controllers which reconfigures OpenLDAP when it detects a DC going out of service.
Jack Kielsmeier wrote:
Interesting.
So you basically have some sort of script that checks responsiveness. If none, it reconfigures slapd.conf and restarts the process? Seems like quite a bandaid, but it'd work.
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Liam Gretton Sent: Tuesday, June 03, 2014 2:12 PM To: openldap-technical@openldap.org Subject: Re: LDAP Proxy Timeout Values
On 03/06/2014 16:34, Jack Kielsmeier wrote:
We are running OpenLDAP 2.4.23. Part of our implementation proxies to an
Active Directory server. Whenever connectivity to the AD server is interrupted, queries to the non-proxied portion of our implementation take a very long time and cause many issues with querying services.
Based on the config info you provided, I don't see how that's possible. You have 3 database sections of note, and they are all independent. Queries to any of the first two databases cannot be affected by anything in the back-ldap database, unless you've deleted something crucial from the censored config you sent.
The doc sections you quote are not relevant, I suggest you re-read the slapd-ldap(5) manpage more carefully.
I reported a similar issue a couple of years ago:
Your issue was reported against back-meta, this post is about back-ldap. The configurations are not similar at all.
http://www.openldap.org/its/index.cgi/Incoming?id=7372;selectid=7372
That was with 2.4.32. I don't think it's been fixed since, but I've worked
around it with a slightly unpleasant out-of-band check on our domain controllers which reconfigures OpenLDAP when it detects a DC going out of service.
From what I see in the mailing list archives, there was nothing to fix. The timeouts all worked as designed when tested locally.
Would it matter that our suffixes are nested?
Example:
DB 1: suffix "ou=sample4,dc=sample3,dc=sample2,dc=sample1"
DB 2: suffix "dc=sample3,dc=sample2,dc=sample1"
AD Server: suffix "dc=sample2,dc=sample1"
So, if the server doing 'suffix "dc=sample2,dc=sample1"' goes down, would the other 2 be affected?
Thanks
- Jack
-----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Wednesday, June 04, 2014 8:51 AM To: Jack Kielsmeier; openldap-technical@openldap.org Subject: Re: LDAP Proxy Timeout Values
Jack Kielsmeier wrote:
Interesting.
So you basically have some sort of script that checks responsiveness. If none, it reconfigures slapd.conf and restarts the process? Seems like quite a bandaid, but it'd work.
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Liam Gretton Sent: Tuesday, June 03, 2014 2:12 PM To: openldap-technical@openldap.org Subject: Re: LDAP Proxy Timeout Values
On 03/06/2014 16:34, Jack Kielsmeier wrote:
We are running OpenLDAP 2.4.23. Part of our implementation proxies to an
Active Directory server. Whenever connectivity to the AD server is interrupted, queries to the non-proxied portion of our implementation take a very long time and cause many issues with querying services.
Based on the config info you provided, I don't see how that's possible. You have 3 database sections of note, and they are all independent. Queries to any of the first two databases cannot be affected by anything in the back-ldap database, unless you've deleted something crucial from the censored config you sent.
The doc sections you quote are not relevant, I suggest you re-read the slapd-ldap(5) manpage more carefully.
I reported a similar issue a couple of years ago:
Your issue was reported against back-meta, this post is about back-ldap. The configurations are not similar at all.
http://www.openldap.org/its/index.cgi/Incoming?id=7372;selectid=7372
That was with 2.4.32. I don't think it's been fixed since, but I've worked
around it with a slightly unpleasant out-of-band check on our domain controllers which reconfigures OpenLDAP when it detects a DC going out of service.
From what I see in the mailing list archives, there was nothing to fix. The timeouts all worked as designed when tested locally.
On 04/06/2014 14:51, Howard Chu wrote:
I reported a similar issue a couple of years ago:
Your issue was reported against back-meta, this post is about back-ldap. The configurations are not similar at all.
Agreed. I couldn't get the timeout directives to work as expected either though. I don't know if the backends share code as far as connection timeouts are concerned.
http://www.openldap.org/its/index.cgi/Incoming?id=7372;selectid=7372
From what I see in the mailing list archives, there was nothing to fix. The timeouts all worked as designed when tested locally.
It was you who suggested I file the ITS about it, with a hint to Pierangelo as to where the problem might be:
http://www.openldap.org/lists/openldap-technical/201208/msg00247.html
That was more to do with back-meta not falling through to alternative targets, but the timeouts didn't seem to behave as expected either.
On 04/06/2014 14:10, Jack Kielsmeier wrote:
So you basically have some sort of script that checks responsiveness. If none, it reconfigures slapd.conf and restarts the process? Seems like quite a bandaid, but it'd work.
Exactly. It's not elegant, but it works.
I'm still using slapd.conf instead of cn=config so a restart is necessary, but as I'm using back-meta I don't think cn=config is possible anyway.
Liam Gretton wrote:
I'm still using slapd.conf instead of cn=config so a restart is necessary, but as I'm using back-meta I don't think cn=config is possible anyway.
cn=config support for back-meta was released in 2.4.33.
On 05/06/2014 14:12, Howard Chu wrote:
Liam Gretton wrote:
I'm still using slapd.conf instead of cn=config so a restart is necessary, but as I'm using back-meta I don't think cn=config is possible anyway.
cn=config support for back-meta was released in 2.4.33.
That's excellent news, thanks.
Regards,
Liam
Liam Gretton wrote:
On 05/06/2014 14:12, Howard Chu wrote:
Liam Gretton wrote:
I'm still using slapd.conf instead of cn=config so a restart is necessary, but as I'm using back-meta I don't think cn=config is possible anyway.
cn=config support for back-meta was released in 2.4.33.
That's excellent news, thanks.
Not exactly news, 2.4.33 was released in 2012...
Howard Chu wrote:
Liam Gretton wrote:
On 05/06/2014 14:12, Howard Chu wrote:
Liam Gretton wrote:
I'm still using slapd.conf instead of cn=config so a restart is necessary, but as I'm using back-meta I don't think cn=config is possible anyway.
cn=config support for back-meta was released in 2.4.33.
That's excellent news, thanks.
Not exactly news, 2.4.33 was released in 2012...
2012-10-10. Fun fact: coincidentally, Double-Ten day, the 100th since the founding of the Republic of China.
openldap-technical@openldap.org
-
Howard Chu -
Jack Kielsmeier -
Liam Gretton