8:34 a.m.
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
12:12 p.m.
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.
--
Liam Gretton liam.gretton(a)le.ac.uk
HPC Architect http://www.le.ac.uk/its/
IT Services Tel: +44 (0)116 2522254
University Of Leicester, University Road
Leicestershire LE1 7RH, United Kingdom
6:10 a.m.
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(a)OpenLDAP.org
[mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Liam Gretton
Sent: Tuesday, June 03, 2014 2:12 PM
To: openldap-technical(a)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.
--
Liam Gretton liam.gretton(a)le.ac.uk
HPC Architect http://www.le.ac.uk/its/
IT Services Tel: +44 (0)116 2522254
University Of Leicester, University Road Leicestershire LE1 7RH, United Kingdom
6:51 a.m.
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(a)OpenLDAP.org
[mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Liam Gretton
Sent: Tuesday, June 03, 2014 2:12 PM
To: openldap-technical(a)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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7:25 a.m.
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(a)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(a)OpenLDAP.org
[mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Liam
Gretton
Sent: Tuesday, June 03, 2014 2:12 PM
To: openldap-technical(a)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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9:28 a.m.
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.
--
Liam Gretton liam.gretton(a)le.ac.uk
HPC Architect http://www.le.ac.uk/its/
IT Services Tel: +44 (0)116 2522254
University Of Leicester, University Road
Leicestershire LE1 7RH, United Kingdom
2:04 a.m.
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 liam.gretton(a)le.ac.uk
Systems Specialist http://www.le.ac.uk/its/
IT Services Tel: +44 (0)116 2522254
University Of Leicester, University Road
Leicestershire LE1 7RH, United Kingdom
6:12 a.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:15 p.m.
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 liam.gretton(a)le.ac.uk
HPC Architect http://www.le.ac.uk/its/
IT Services Tel: +44 (0)116 2522254
University Of Leicester, University Road
Leicestershire LE1 7RH, United Kingdom
2:45 p.m.
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
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:49 p.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3216
days inactive
3218
days old
openldap-technical@openldap.org
10 comments
3 participants
participants (3)
-
Howard Chu -
Jack Kielsmeier -
Liam Gretton