Re: (ITS#8669) Slapd service becomes unresponsive intermittently
by michael＠stroeder.com
jmestrada69(a)gmail.com wrote:
> Our server vendor did the upgrade to version 2.4.39 last year in April. In
> asking them about upgrading to a newer version, as a potential fix, I was
> told the last version in the RHEL repository that they can upgrade to is
> 2.4.40.
They seem to just recommend what seems to be the easiest choice for them and not what
would be the recommended choice for *you*. RHEL packages are heavily patched by Red Hat
and generally not recommended. The upstream developers cannot oversee what's the current
patch state of RHEL packages.
=> You should kick out your server vendor from doing the OpenLDAP support.
Ciao, Michael.
6 years, 5 months
Re: (ITS#8669) Slapd service becomes unresponsive intermittently
by jmestrada69＠gmail.com
Quanah,
We are running the Berkley DB back-end, =B3back-bdb=B2 in the slapd.conf file.
Our server vendor did the upgrade to version 2.4.39 last year in April. In
asking them about upgrading to a newer version, as a potential fix, I was
told the last version in the RHEL repository that they can upgrade to is
2.4.40. I=B9m not certain that our vendor will support our choice to upgrade
to a newer version than what RHEL provides them in the repository, but if
it will fix our problem, I=B9ll have to push the envelope on that matter.
Were there any known fragmentation issues with back-bdb in the 2.4.39
version that could also be causing these pauses?
Initially, when we started having problems with the pausing, the server
would go offline for about 15-20 minutes then recover itself. The
developers had initially set the idletimeout to 8 minutes (480) and we
also noted that rsyslogd was constantly logging entries about the slapd
service, which stated that the the PID of the slapd service was losing
messages to the log due to rate-limiting. Rate limiting was enabled by
default for rsyslog so our vendor recommended to turn this off. At the
same time, when they did this we scaled back the idletimeout period to 5
minutes (300). This seemed to aggravated the problem. With the original
settings, we would encounter this =B3pause=B2 problem maybe once or twice in a
3 month period, and now after these changes were made we=B9re seeing this
more frequently, although when it does pause it seems to only be for about
10 minutes, where it was pausing for 15-20 before. We currently have the
logging level set to the recommended =B3256=B2, but we=B9re considering lowing
the logging level also.
Is it possible we have the idletimeout set too high and it should be
lowered? I=B9m wondering if there is some sweet-spot value for this
particular setting.
The reason our developers had it set so high was because, in the past they
used to run some really long reports. I=B9m pretty sure they do not run
these any longer.
I appreciate your feedback.
Thanks
On 6/6/17, 6:57 PM, "Quanah Gibson-Mount" <quanah(a)symas.com> wrote:
>--On Tuesday, June 06, 2017 8:39 PM +0000 jmestrada69(a)gmail.com wrote:
>
>> Is there a known bug with this version that could be causing this?
>
>Hard to say. It is 3.5 years old and 6 releases behind. You don't state
>which backend you're using, which may be relevant as well. There were
>known fragmentation issues with back-mdb in that release, for example,
>that=20
>could cause extensive pauses. Without knowing significantly more about
>your system configuration, there's only a ton of speculation that can
>ensue.
>
>You may want to see about using the builds from the LTB project
>(<http://ltb-project.org/wiki/download#openldap>), or if you require
>support for your deployment, Symas (my employer) offers packaged builds
>and=20
>various support options.
>
>Regards,
>Quanah
>
>--
>
>Quanah Gibson-Mount
>Product Architect
>Symas Corporation
>Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
><http://www.symas.com>
>
6 years, 5 months
Re: (ITS#8671) Declare ldap_init_fd() in ldap.h to help external consumers
by abokovoy＠redhat.com
--ce5n3c4hsgyizewc
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Patch attached.
--
/ Alexander Bokovoy
--ce5n3c4hsgyizewc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="abokovoy-ldap_init_fd-move-ldap_init_fd-definition-to-ldap.h.patch"
Content-Transfer-Encoding: quoted-printable
=46rom 2c1f3afd8098b2a345a900effa1a2e5c3f9e3b08 Mon Sep 17 00:00:00 2001
=46rom: Alexander Bokovoy <abokovoy(a)redhat.com>
Date: Mon, 5 Jun 2017 14:43:58 +0300
Subject: [PATCH] ldap_init_fd: move ldap_init_fd() definition to ldap.h
While OpenLDAP team position is that all code in OpenLDAP source
distribution can be used by users, most distributions do not ship
ldap_pvt.h as part of openldap-devel (sub)package.
Move ldap_init_fd() to ldap.h to facilitate external users who have a
need to integrate OpenLDAP with their own event loop processing.
---
doc/man/man3/ldap_open.3 | 5 +----
include/ldap.h | 8 ++++++++
include/ldap_pvt.h | 2 --
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/doc/man/man3/ldap_open.3 b/doc/man/man3/ldap_open.3
index 1d5e2b5..4f980f2 100644
--- a/doc/man/man3/ldap_open.3
+++ b/doc/man/man3/ldap_open.3
@@ -3,7 +3,7 @@
.\" Copyright 1998-2017 The OpenLDAP Foundation All Rights Reserved.
.\" Copying restrictions apply. See COPYRIGHT/LICENSE.
.SH NAME
-ldap_init, ldap_initialize, ldap_open \- Initialize the LDAP library and o=
pen a connection to an LDAP server
+ldap_init, ldap_initialize, ldap_open, ldap_init_fd \- Initialize the LDAP=
library and open a connection to an LDAP server
.SH LIBRARY
OpenLDAP LDAP (libldap, \-lldap)
.SH SYNOPSIS
@@ -45,9 +45,6 @@ LDAPURLDesc **url;
void *params;
.LP
.ft B
-#include <ldap_pvt.h>
-.LP
-.ft B
int ldap_init_fd(fd, proto, uri, ldp)
.ft
ber_socket_t fd;
diff --git a/include/ldap.h b/include/ldap.h
index 588e906..dd0c118 100644
--- a/include/ldap.h
+++ b/include/ldap.h
@@ -1548,6 +1548,14 @@ LDAP_F( LDAP * )
ldap_dup LDAP_P((
LDAP *old ));
=20
+/* open */
+LDAP_F (int)
+ldap_init_fd LDAP_P((
+ ber_socket_t fd,
+ int proto,
+ LDAP_CONST char *url,
+ LDAP **ldp ));
+
/*
* in tls.c
*/
diff --git a/include/ldap_pvt.h b/include/ldap_pvt.h
index f1d93ac..49f674c 100644
--- a/include/ldap_pvt.h
+++ b/include/ldap_pvt.h
@@ -344,8 +344,6 @@ ldap_get_message_ber LDAP_P((
/* open */
LDAP_F (int) ldap_open_internal_connection LDAP_P((
struct ldap **ldp, ber_socket_t *fdp ));
-LDAP_F (int) ldap_init_fd LDAP_P((
- ber_socket_t fd, int proto, LDAP_CONST char *url, struct ldap **ldp ));
=20
/* sasl.c */
LDAP_F (int) ldap_pvt_sasl_generic_install LDAP_P(( Sockbuf *sb,
--=20
2.9.3
--ce5n3c4hsgyizewc--
6 years, 5 months
(ITS#8671) Declare ldap_init_fd() in ldap.h to help external consumers
by abokovoy＠redhat.com
Full_Name: Alexander Bokovoy
Version:
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (88.115.170.217)
As discussed on the openldap-devel@, Samba team would like to use ldap_init_fd()
to allow Samba handle actual sockets. To do so we would like to see
ldap_init_fd() declared in ldap.h instead of ldap_pvt.h. The latter is not
shipped by most distributions at all.
Proposed patch moves ldap_init_fd() declaration to ldap.h and changes references
to it in the corresponding manual pages. You can do what you want with the
proposed patch since it does not really contain any code I have written.
6 years, 5 months
Re: (ITS#8669) Slapd service becomes unresponsive intermittently
by quanah＠symas.com
--On Tuesday, June 06, 2017 8:39 PM +0000 jmestrada69(a)gmail.com wrote:
> Is there a known bug with this version that could be causing this?
Hard to say. It is 3.5 years old and 6 releases behind. You don't state
which backend you're using, which may be relevant as well. There were
known fragmentation issues with back-mdb in that release, for example, that
could cause extensive pauses. Without knowing significantly more about
your system configuration, there's only a ton of speculation that can ensue.
You may want to see about using the builds from the LTB project
(<http://ltb-project.org/wiki/download#openldap>), or if you require
support for your deployment, Symas (my employer) offers packaged builds and
various support options.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 5 months
ITS#8504 fix breaks Solaris builds
by quanah＠openldap.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.45
OS: Solaris 11
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.239)
Building the liblmdb bundled with OpenLDAP 2.4.45 on Solaris 11 fails due to the
fix for ITS#8504:
quanah@ub16:~/git/openldap/openldap-2-4/libraries/liblmdb$ git show 894e88bf
commit 894e88bf895529b2f4682f74c7a8c69a0c61cc00
Author: Lorenz Bauer <lmb(a)cloudflare.com>
Date: Thu Oct 20 09:51:22 2016 +0200
ITS#8504 mdb_env_copyfd2(): Don't abort on SIGPIPE
Return EPIPE instead.
This block in particular:
+#ifndef _WIN32
+ if (rc == EPIPE) {
+ int tmp;
+ sigwait(&set, &tmp);
+ }
+#endif
results in:
gcc -m32 -static-libgcc -lrt -fPIC -pthread -O2 -g -W -Wall
-Wno-unused-parameter -Wbad-function-cast -g -O2
-I/export/home/build/sold-2.4.45.1/SunOS5.11-i86pc/install/i86pc_32/opt/symas/include
-c /export/home/build/sold-2.4.45.1/openldap/libraries/liblmdb/mdb.c
/export/home/build/sold-2.4.45.1/openldap/libraries/liblmdb/mdb.c: In function
mdb_env_copythr:
/export/home/build/sold-2.4.45.1/openldap/libraries/liblmdb/mdb.c:9062:6: error:
too many arguments to function sigwait
sigwait(&set, &tmp);
^
In file included from
/export/home/build/sold-2.4.45.1/openldap/libraries/liblmdb/mdb.c:132:0:
/usr/include/signal.h:233:12: note: declared here
extern int sigwait(sigset_t *);
^
make[1]: *** [mdb.o] Error 1
make[1]: Leaving directory
`/export/home/build/sold-2.4.45.1/SunOS5.11-i86pc/build/liblmdb.i86pc_32'
make: *** [inter-build-liblmdb.i86pc_32] Error 2
6 years, 5 months
(ITS#8669) Slapd service becomes unresponsive intermittently
by jmestrada69＠gmail.com
Full_Name: JM Estrada
Version: 2.4.39
OS: RHEL Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (209.136.235.13)
I am trying to determine if a problem we are having is a bug or some other issue
with OpenLDAP 2.4.39.
We have two servers configured as a Master/Slave using syncrepl. Both servers
are running 2.4.39 and at random times, sometimes weeks apart, we are having
issues where the slapd service becomes unresponsive for a period of about 10 to
15 minutes.
When the problem occurs, we see numerous entries in the logs which show an
UNBIND and then a close entry. We then find that the slapd is unresponsive and
will not accept any requests, at the same time the CPU load for slapd skyrockets
to about 100% or very close to it. This lasts for about 10-15 minutes and then
the server recovers itself and again begins responding to requests.
The problem is intermittent and doesn't seem to coincide with periods of heavy
use versus lower usage.
Is there a known bug with this version that could be causing this?
6 years, 5 months
Re: (ITS#8668) Cache overlay, unexpected behaviour and occasional segfaults
by quanah＠symas.com
--On Monday, June 05, 2017 6:08 PM +0000 acrow(a)integrafin.co.uk wrote:
> Full_Name: Alex Crow
> Version: 2.4.40-13.el7
> OS: Centos 7.3
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (95.172.237.70)
>
>
> I'm using OpenLDAP with the caching overlay as a proxy to AD, mostly for
> use with Postfix and Dovecot.
>
> I have been experiencing a strange issue whereby, when a user is moved to
> a different OU in AD, the caching server initially returns only the
> original OU until the cache entry expires. However, after this time, it
> returns both the entry in the original OU and the entry in the new OU.
> This does not seem to change even after the next expiry time has elapsed.
> I can only seem to clear out the "old" result by wiping the cache's
> database.
Hi Alex,
The first thing to do would be to upgrade to OpenLDAP 2.4.44 or 2.4.45 and
confirm you can reproduce the issue in a current release. If you can, then
you need to provide a full backtrace, where debug symbols are enabled (the
"-g" flag for CFLAGS for gcc), and the slapd binary is not stripped (or if
using packaged RPMs, the debuginfo etc bits are installed).
You can grab pre-compiled packages for OpenLDAP 2.4.44 from the LTB project
at <http://ltb-project.org/wiki/download#openldap>. I expect they'll have
2.4.45 packages available soon as well.
Thanks,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 5 months
(ITS#8668) Cache overlay, unexpected behaviour and occasional segfaults
by acrow＠integrafin.co.uk
Full_Name: Alex Crow
Version: 2.4.40-13.el7
OS: Centos 7.3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (95.172.237.70)
I'm using OpenLDAP with the caching overlay as a proxy to AD, mostly for use
with Postfix and Dovecot.
I have been experiencing a strange issue whereby, when a user is moved to a
different OU in AD, the caching server initially returns only the original OU
until the cache entry expires. However, after this time, it returns both the
entry in the original OU and the entry in the new OU. This does not seem to
change even after the next expiry time has elapsed. I can only seem to clear out
the "old" result by wiping the cache's database.
Here is my slapd.conf:
### Schema includes ###########################################################
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/misc.schema
#include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/custom.schema
include /etc/openldap/schema/adstuff.schema
## Module paths ##############################################################
modulepath /usr/lib64/openldap/
moduleload back_ldap
moduleload pcache
#moduleload rwm
# Main settings ###############################################################
TLSCACertificateFile /etc/openldap/cacerts/cacertchain.pem
TLSCertificateFile /etc/openldap/cacerts/certkey.pem
TLSCertificateKeyFile /etc/openldap/cacerts/certkey.pem
TLSVerifyClient never
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
allow bind_v2
database config
rootdn "cn=admin,cn=config"
rootpw {SSHA}blahblahblah
### Database definition (Proxy to AD) #########################################
database ldap
readonly yes
protocol-version 3
rebind-as-user
uri "ldap://foo ldap://bar ..."
suffix "dc=foo,dc=bar,dc=net"
rootdn "dc=foo,dc=bar,dc=net"
timelimit 5
overlay pcache
pcache bdb 100000 1 1000 100
pcacheAttrset 0 mail x-mailHost x-mailStore unixHomeDirectory
pcacheTemplate (sn=) 0 3600 0 0 1800
pcacheTemplate (cn=) 0 3600 0 0 1800
pcacheTemplate (mail=) 0 3600 0 0 1800
pcacheTemplate (&(objectClass=)(mail=)) 0 3600 0 0 1800
pcacheTemplate (&(objectClass=)(mail=*)) 0 3600 0 0 1800
cachesize 10000
directory /var/lib/ldap
index objectClass eq
index cn,sn,uid,mail pres,eq,sub
### Logging ###################################################################
loglevel 0
Here is an example of a search returning two results from the cache:
# extended LDIF
#
# LDAPv3
# base <OU=baz,DC=foo,DC=bar,DC=net> with scope subtree
# filter: mail=test_ajc(a)integrafin.co.uk
# requesting: x-mailHost
#
# test_ajc, DMD, COPS, ...
dn: cn=test_ajc,ou=DMD,ou=COPS, ...
dc=bar,dc=net
x-mailHost: imap.bar.net
# test_ajc, SysAdmin, ITDIV, ...
dn: cn=test_ajc,ou=SysAdmin,ou=ITDIV, ...
dc=bar,dc=net
x-mailHost: imap.bar.net
# search result
search: 2
result: 0 Success
# numResponses: 3
# numEntries: 2
The newer, correct entry is the lower one.
We also occasionally suffer segfaults, eg:
[8432930.512516] slapd[19550]: segfault at 108 ip 00007f4204c401de sp
00007f41c1ff94d0 error 6 in libldap_r-2.4.so.2.10.3[7f4204c18000+56000]
[8434338.469945] slapd[30666]: segfault at 108 ip 00007f102a5c41de sp
00007f1014c744d0 error 6 in libldap_r-2.4.so.2.10.3[7f102a59c000+56000]
[8951331.245103] slapd[9653]: segfault at 11d8 ip 00007f01c523d1de sp
00007f01abffd4d0 error 6 in libldap_r-2.4.so.2.10.3[7f01c5215000+56000]
[10140511.797794] slapd[10247]: segfault at 108 ip 00007fbc84de01de sp
00007fbc477fc4d0 error 6 in libldap_r-2.4.so.2.10.3[7fbc84db8000+56000]
I've not determined what, if anything specific triggers these.
Any insights much appreciated.
Alex
6 years, 6 months
