June 2017 - openldap-bugs

Re: (ITS#8669) Slapd service becomes unresponsive intermittently
by quanah＠symas.com 07 Jun '17

07 Jun '17

--On Wednesday, June 07, 2017 8:44 PM +0200 Michael Str=C3=B6der=20 <michael(a)stroeder.com> wrote: > quanah(a)symas.com wrote: >>> Is it possible we have the idletimeout set too high and it should be >>> lowered? I=3DC2=3DB9m wondering if there is some sweet-spot value for = this >>> particular setting. >> >> I generally leave it unset unless one is encountering an issue of = running >> out of connections. Generally, it would be fairly strange for >> idletimeout to affect things this way at all. > > I generally recommend to set idletimeout even somewhat tight in case you > don't have a strictly defined set of clients. Because a client > application which does not use its LDAP connection for ~5 min. is most > times simply not closing connections. And running out of file handles can > affect all file creation on your system (e.g. creating BDB's transaction > log files). Yep, there can be poorly written clients out there. I'd expect idletimeout = to be completely unrelated, given it's long standing existence and use. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8669) Slapd service becomes unresponsive intermittently
by michael＠stroeder.com 07 Jun '17

07 Jun '17

quanah(a)symas.com wrote: >> Is it possible we have the idletimeout set too high and it should be >> lowered? I=C2=B9m wondering if there is some sweet-spot value for this >> particular setting. > > I generally leave it unset unless one is encountering an issue of running > out of connections. Generally, it would be fairly strange for idletimeout > to affect things this way at all. I generally recommend to set idletimeout even somewhat tight in case you don't have a strictly defined set of clients. Because a client application which does not use its LDAP connection for ~5 min. is most times simply not closing connections. And running out of file handles can affect all file creation on your system (e.g. creating BDB's transaction log files). Only the original poster can find out with monitoring. One can find out stale connections via back-monitor in sub-tree cn=Connections,cn=Monitor. IITC attribute 'monitorConnectionActivityTime' contains last client access time on this connection. (Ummh, I have to add this to my own monitoring script...) And of course normal system monitoring of file handles would be also helpful. Ciao, Michael. (Keep repeating this mantra: monitoring, monitoring, monitoring, monitoring…)

1 0

Re: (ITS#8669) Slapd service becomes unresponsive intermittently
by quanah＠symas.com 07 Jun '17

07 Jun '17

--On Wednesday, June 07, 2017 7:07 AM -0600 Joaquin Estrada=20 <jmestrada69(a)gmail.com> wrote: > Quanah, > > We are running the Berkley DB back-end, =C2=B3back-bdb=C2=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=C2=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=C2=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? No, back-bdb is not remotely the same as back-mdb. However, I've no idea=20 what options RedHat compiles their BDB library with and there were specific = options that had an effect on OpenLDAP. Generally, I would note that the=20 back-bdb backend and back-hdb backends are deprecated at this point. > Is it possible we have the idletimeout set too high and it should be > lowered? I=C2=B9m wondering if there is some sweet-spot value for this > particular setting. I generally leave it unset unless one is encountering an issue of running=20 out of connections. Generally, it would be fairly strange for idletimeout=20 to affect things this way at all. It simply drops idle connections based=20 off of the timer. Disabling rate throttling in rsyslogd is a good idea,=20 but may be unrelated as well. We've also seen cases with RHEL7 where Redhat = has set things up so that journald also gets all the syslog messages, which = causes severe performance degredation. You could spend some time seeing if you can isolate an exact cause. For=20 example, set loglevel to 0 and see if you still encounter the issue. If=20 you do, it is unrelated to syslog activity. Another test would be to set idletimeout to 0. If you still encounter the=20 issue, it is unrelated to idle connections being dropped. etc. As Michael noted, Redhat builds are somewhat questionable as they make=20 various changes to the code base that the OpenLDAP project have not been=20 reviewed. Your issues may or may not be related to such a change, it's=20 generally impossible to know. Hope that helps. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: ITS#8504 fix breaks Solaris builds
by quanah＠symas.com 07 Jun '17

07 Jun '17

--On Wednesday, June 07, 2017 3:35 PM +0200 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no> wrote: > On 06. juni 2017 21:59, quanah(a)openldap.org wrote: >> /usr/include/signal.h:233:12: note: declared here >> extern int sigwait(sigset_t *); >> ^ > > POSIX says it has two arguments: > http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigwait.html > Is there a two-argument version of sigwait in the Solaris headers > somewhere, > maybe enabled by #define POSIX_C_SOURCE 1 or something like that? It's insanely long.... /* * sigwait() prototype is defined here. */ #if defined(__EXTENSIONS__) || (!defined(_STRICT_STDC) && \ !defined(__XOPEN_OR_POSIX)) || (_POSIX_C_SOURCE - 0 >= 199506L) || \ defined(_POSIX_PTHREAD_SEMANTICS) #if defined(__STDC__) #if (_POSIX_C_SOURCE - 0 >= 199506L) || defined(_POSIX_PTHREAD_SEMANTICS) #ifdef __PRAGMA_REDEFINE_EXTNAME #pragma redefine_extname sigwait __posix_sigwait extern int sigwait(const sigset_t *_RESTRICT_KYWD, int *_RESTRICT_KYWD); #else /* __PRAGMA_REDEFINE_EXTNAME */ extern int __posix_sigwait(const sigset_t *_RESTRICT_KYWD, int *_RESTRICT_KYWD); #ifdef __lint #define sigwait __posix_sigwait #else /* !__lint */ static int sigwait(const sigset_t *_RESTRICT_KYWD __setp, int *_RESTRICT_KYWD __signo) { return (__posix_sigwait(__setp, __signo)); } #endif /* !__lint */ #endif /* __PRAGMA_REDEFINE_EXTNAME */ #else /* (_POSIX_C_SOURCE - 0 >= 199506L) || ... */ extern int sigwait(sigset_t *); #endif /* (_POSIX_C_SOURCE - 0 >= 199506L) || ... */ #else /* __STDC__ */ #if (_POSIX_C_SOURCE - 0 >= 199506L) || defined(_POSIX_PTHREAD_SEMANTICS) #ifdef __PRAGMA_REDEFINE_EXTNAME #pragma redefine_extname sigwait __posix_sigwait extern int sigwait(); #else /* __PRAGMA_REDEFINE_EXTNAME */ extern int __posix_sigwait(); #ifdef __lint #define sigwait __posix_sigwait #else /* !__lint */ static int sigwait(__setp, __signo) sigset_t *__setp; int *__signo; { return (__posix_sigwait(__setp, __signo)); } #endif /* !__lint */ #endif /* __PRAGMA_REDEFINE_EXTNAME */ #else /* (_POSIX_C_SOURCE - 0 >= 199506L) || ... */ extern int sigwait(); #endif /* (_POSIX_C_SOURCE - 0 >= 199506L) || ... */ #endif /* __STDC__ */ #endif /* defined(__EXTENSIONS__) || (!defined(_STRICT_STDC) ... */ -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8669) Slapd service becomes unresponsive intermittently
by jmestrada69＠gmail.com 07 Jun '17

07 Jun '17

Yes, I've reached out to our vendor about this. I am hoping we can sidestep t= he RHEL releases. Thanks for the info on this.=20 Sent from my iPhone > On Jun 7, 2017, at 6:16 AM, Michael Str=C3=B6der <michael(a)stroeder.com> wr= ote: >=20 > jmestrada69(a)gmail.com wrote: >> Our server vendor did the upgrade to version 2.4.39 last year in April. I= n >> 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. >=20 > They seem to just recommend what seems to be the easiest choice for them a= nd not what > would be the recommended choice for *you*. RHEL packages are heavily patch= ed by Red Hat > and generally not recommended. The upstream developers cannot oversee what= 's the current > patch state of RHEL packages. >=20 > =3D> You should kick out your server vendor from doing the OpenLDAP suppor= t. >=20 > Ciao, Michael.

1 0

Re: ITS#8504 fix breaks Solaris builds
by h.b.furuseth＠usit.uio.no 07 Jun '17

07 Jun '17

On 06. juni 2017 21:59, quanah(a)openldap.org wrote: > /usr/include/signal.h:233:12: note: declared here > extern int sigwait(sigset_t *); > ^ POSIX says it has two arguments: http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigwait.html Is there a two-argument version of sigwait in the Solaris headers somewhere, maybe enabled by #define POSIX_C_SOURCE 1 or something like that? -- Hallvard

1 0

Re: (ITS#8669) Slapd service becomes unresponsive intermittently
by michael＠stroeder.com 07 Jun '17

07 Jun '17

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.

1 0

Re: (ITS#8669) Slapd service becomes unresponsive intermittently
by jmestrada69＠gmail.com 07 Jun '17

07 Jun '17

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> >

1 0

Re: (ITS#8671) Declare ldap_init_fd() in ldap.h to help external consumers
by abokovoy＠redhat.com 07 Jun '17

07 Jun '17

--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--

1 0

(ITS#8671) Declare ldap_init_fd() in ldap.h to help external consumers
by abokovoy＠redhat.com 07 Jun '17

07 Jun '17

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.

1 0

Re: (ITS#8669) Slapd service becomes unresponsive intermittently
by quanah＠symas.com 06 Jun '17

06 Jun '17

--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>

1 0

ITS#8504 fix breaks Solaris builds
by quanah＠openldap.org 06 Jun '17

06 Jun '17

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

1 0

(ITS#8669) Slapd service becomes unresponsive intermittently
by jmestrada69＠gmail.com 06 Jun '17

06 Jun '17

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?

1 0

Re: (ITS#8668) Cache overlay, unexpected behaviour and occasional segfaults
by quanah＠symas.com 06 Jun '17

06 Jun '17

--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>

1 0

(ITS#8668) Cache overlay, unexpected behaviour and occasional segfaults
by acrow＠integrafin.co.uk 05 Jun '17

05 Jun '17

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

1 0

Re: (ITS#8666) Fix build with LibreSSL
by pawel＠FreeBSD.org 05 Jun '17

05 Jun '17

Hi Howard, On 2017-06-05 17:03 +0100, Howard Chu <hyc(a)symas.com> wrote: >pawel(a)FreeBSD.org wrote: >> Full_Name: Pawe&#322; P&#281;kala >> Version: 2.4.45 >> OS: FreeBSD 12-CURRENT >> URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219781 >> Submission from: (NULL) (62.141.192.76) >> =20 > >No. LibreSSL should not be hijacking OPENSSL_VERSION_NUMBER macros, >especially if it doesn't actually implement the features of those >versions. > First off let me clarify first that I'm not representing LibreSSL project, this is my opinion as a outsider. From my point of view they are keeping OPENSSL_VERSION_NUMBER for backwards compatibility not forwards, from their openssl/opensslv.h: * These will change with each release of LibreSSL-portable */ #define LIBRESSL_VERSION_NUMBER 0x2050400fL #define LIBRESSL_VERSION_TEXT "LibreSSL 2.5.4" /* These will never change */ #define OPENSSL_VERSION_NUMBER 0x20000000L >> Latest version fails to build with LibreSSL. Following patch fixes >> issue for me: >> >> --- libraries/libldap/tls_o.c.orig 2017-06-04 16:31:28 UTC >> +++ libraries/libldap/tls_o.c >> @@ -47,7 +47,7 @@ >> #include <ssl.h> >> #endif >> >> -#if OPENSSL_VERSION_NUMBER >=3D 0x10100000 >> +#if OPENSSL_VERSION_NUMBER >=3D 0x10100000 >> && !defined(LIBRESSL_VERSION_NUMBER) #define >> ASN1_STRING_data(x) ASN1_STRING_get0_data(x) #endif >> >> @@ -157,7 +157,7 @@ tlso_init( void ) >> (void) tlso_seed_PRNG( lo->ldo_tls_randfile ); >> #endif >> >> -#if OPENSSL_VERSION_NUMBER < 0x10100000 >> +#if OPENSSL_VERSION_NUMBER < 0x10100000 || >> defined(LIBRESSL_VERSION_NUMBER) SSL_load_error_strings(); >> SSL_library_init(); >> OpenSSL_add_all_digests(); >> @@ -205,7 +205,7 @@ static void >> tlso_ctx_ref( tls_ctx *ctx ) >> { >> tlso_ctx *c =3D (tlso_ctx *)ctx; >> -#if OPENSSL_VERSION_NUMBER < 0x10100000 >> +#if OPENSSL_VERSION_NUMBER < 0x10100000 || >> defined(LIBRESSL_VERSION_NUMBER) #define >> SSL_CTX_up_ref(ctx) CRYPTO_add( &(ctx->references), 1, >> CRYPTO_LOCK_SSL_CTX ) #endif >> SSL_CTX_up_ref( c ); >> @@ -464,7 +464,7 @@ tlso_session_my_dn( tls_session *sess, struct >> berval * if (!x) return LDAP_INVALID_CREDENTIALS; >> =09 >> xn =3D X509_get_subject_name(x); >> -#if OPENSSL_VERSION_NUMBER < 0x10100000 >> +#if OPENSSL_VERSION_NUMBER < 0x10100000 || >> defined(LIBRESSL_VERSION_NUMBER) der_dn->bv_len =3D i2d_X509_NAME( xn, >> NULL ); der_dn->bv_val =3D xn->bytes->data; >> #else >> @@ -500,7 +500,7 @@ tlso_session_peer_dn( tls_session *sess, struct >> berval return LDAP_INVALID_CREDENTIALS; >> >> xn =3D X509_get_subject_name(x); >> -#if OPENSSL_VERSION_NUMBER < 0x10100000 >> +#if OPENSSL_VERSION_NUMBER < 0x10100000 || >> defined(LIBRESSL_VERSION_NUMBER) der_dn->bv_len =3D i2d_X509_NAME( xn, >> NULL ); der_dn->bv_val =3D xn->bytes->data; >> #else >> @@ -721,7 +721,7 @@ struct tls_data { >> Sockbuf_IO_Desc *sbiod; >> }; >> >> -#if OPENSSL_VERSION_NUMBER < 0x10100000 >> +#if OPENSSL_VERSION_NUMBER < 0x10100000 || >> defined(LIBRESSL_VERSION_NUMBER) #define BIO_set_init(b, x) >> b->init =3D x #define BIO_set_data(b, x) b->ptr =3D x >> #define BIO_clear_flags(b, x) b->flags &=3D ~(x) >> @@ -822,7 +822,7 @@ tlso_bio_puts( BIO *b, const char *str ) >> return tlso_bio_write( b, str, strlen( str ) ); >> } >> >> -#if OPENSSL_VERSION_NUMBER >=3D 0x10100000 >> +#if OPENSSL_VERSION_NUMBER >=3D 0x10100000 >> && !defined(LIBRESSL_VERSION_NUMBER) struct bio_method_st { >> int type; >> const char *name; >> >> >> =20 > > --=20 pozdrawiam / with regards Pawe=C5=82 P=C4=99kala

1 0

Re: (ITS#8666) Fix build with LibreSSL
by hyc＠symas.com 05 Jun '17

05 Jun '17

pawel(a)FreeBSD.org wrote: > Full_Name: Pawe&#322; P&#281;kala > Version: 2.4.45 > OS: FreeBSD 12-CURRENT > URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219781 > Submission from: (NULL) (62.141.192.76) > No. LibreSSL should not be hijacking OPENSSL_VERSION_NUMBER macros, especially if it doesn't actually implement the features of those versions. > Latest version fails to build with LibreSSL. Following patch fixes issue for > me: > > --- libraries/libldap/tls_o.c.orig 2017-06-04 16:31:28 UTC > +++ libraries/libldap/tls_o.c > @@ -47,7 +47,7 @@ > #include <ssl.h> > #endif > > -#if OPENSSL_VERSION_NUMBER >= 0x10100000 > +#if OPENSSL_VERSION_NUMBER >= 0x10100000 && !defined(LIBRESSL_VERSION_NUMBER) > #define ASN1_STRING_data(x) ASN1_STRING_get0_data(x) > #endif > > @@ -157,7 +157,7 @@ tlso_init( void ) > (void) tlso_seed_PRNG( lo->ldo_tls_randfile ); > #endif > > -#if OPENSSL_VERSION_NUMBER < 0x10100000 > +#if OPENSSL_VERSION_NUMBER < 0x10100000 || defined(LIBRESSL_VERSION_NUMBER) > SSL_load_error_strings(); > SSL_library_init(); > OpenSSL_add_all_digests(); > @@ -205,7 +205,7 @@ static void > tlso_ctx_ref( tls_ctx *ctx ) > { > tlso_ctx *c = (tlso_ctx *)ctx; > -#if OPENSSL_VERSION_NUMBER < 0x10100000 > +#if OPENSSL_VERSION_NUMBER < 0x10100000 || defined(LIBRESSL_VERSION_NUMBER) > #define SSL_CTX_up_ref(ctx) CRYPTO_add( &(ctx->references), 1, > CRYPTO_LOCK_SSL_CTX ) > #endif > SSL_CTX_up_ref( c ); > @@ -464,7 +464,7 @@ tlso_session_my_dn( tls_session *sess, struct berval * > if (!x) return LDAP_INVALID_CREDENTIALS; > > xn = X509_get_subject_name(x); > -#if OPENSSL_VERSION_NUMBER < 0x10100000 > +#if OPENSSL_VERSION_NUMBER < 0x10100000 || defined(LIBRESSL_VERSION_NUMBER) > der_dn->bv_len = i2d_X509_NAME( xn, NULL ); > der_dn->bv_val = xn->bytes->data; > #else > @@ -500,7 +500,7 @@ tlso_session_peer_dn( tls_session *sess, struct berval > return LDAP_INVALID_CREDENTIALS; > > xn = X509_get_subject_name(x); > -#if OPENSSL_VERSION_NUMBER < 0x10100000 > +#if OPENSSL_VERSION_NUMBER < 0x10100000 || defined(LIBRESSL_VERSION_NUMBER) > der_dn->bv_len = i2d_X509_NAME( xn, NULL ); > der_dn->bv_val = xn->bytes->data; > #else > @@ -721,7 +721,7 @@ struct tls_data { > Sockbuf_IO_Desc *sbiod; > }; > > -#if OPENSSL_VERSION_NUMBER < 0x10100000 > +#if OPENSSL_VERSION_NUMBER < 0x10100000 || defined(LIBRESSL_VERSION_NUMBER) > #define BIO_set_init(b, x) b->init = x > #define BIO_set_data(b, x) b->ptr = x > #define BIO_clear_flags(b, x) b->flags &= ~(x) > @@ -822,7 +822,7 @@ tlso_bio_puts( BIO *b, const char *str ) > return tlso_bio_write( b, str, strlen( str ) ); > } > > -#if OPENSSL_VERSION_NUMBER >= 0x10100000 > +#if OPENSSL_VERSION_NUMBER >= 0x10100000 && !defined(LIBRESSL_VERSION_NUMBER) > struct bio_method_st { > int type; > const char *name; > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
by okuznik＠symas.com 05 Jun '17

05 Jun '17

Although Quanah hasn't been able to trigger this yet, the regression test in master he wrote has been consistently able to trigger for me on my machine, so I've started to investigate. For posterity and in case anyone is interested, I have uploaded the testrun/ directory from a failing run (I suspect the fact of this laptop having a slow 2-core CPU helps) with a slightly patched slapd that records the thread ID as well since, in part, this seems like a race of some sort. The tgz is available at ftp://ftp.openldap.org/incoming/its8444-regression-testrun-sync,stat.tgz So far it looks like replica #3's threads 7f50fb7fe700 and 7f51017bb700 are both trying to apply the modification with CSN 20170605125334.856475Z#000000#001#000000 which sends it into a full refresh.=20 --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#8667) slapcat not honoring '-g' option
by gnoe＠symas.com 05 Jun '17

05 Jun '17

Full_Name: Gregory Noe Version: 2.4.44 OS: Debian 8.7 URL: ftp://ftp.openldap.org/incoming/gregory-noe-170605.tar Submission from: (NULL) (63.142.209.94) Slapcat is not honoring the '-g' option. The output includes entries from glued subordinates when it shouldn't. The attached test script (gregory-noe-170605.tar) sets up the following DIT with inetOrgPerson entries in each OU: dn: dc=example,dc=com |- ou=NonSub00,dc=example,dc=com |- ou=NonSub01,dc=example,dc=com |- ou=NonSub02,dc=example,dc=com glued sub: ou=Accounting,dc=example,dc=com glued sub: ou=Administrative,dc=example,dc=com glued sub: ou=Janitorial,dc=example,dc=com Then the script runs 'slapcat -g -b dc=example,dc=com | grep ^dn'. The result contains entries from all three glued subordinates. Tested using Symas OpenLDAP 2.4.44.5

1 0

(ITS#8666) Fix build with LibreSSL
by pawel＠FreeBSD.org 05 Jun '17

05 Jun '17

Full_Name: Pawe&#322; P&#281;kala Version: 2.4.45 OS: FreeBSD 12-CURRENT URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219781 Submission from: (NULL) (62.141.192.76) Latest version fails to build with LibreSSL. Following patch fixes issue for me: --- libraries/libldap/tls_o.c.orig 2017-06-04 16:31:28 UTC +++ libraries/libldap/tls_o.c @@ -47,7 +47,7 @@ #include <ssl.h> #endif -#if OPENSSL_VERSION_NUMBER >= 0x10100000 +#if OPENSSL_VERSION_NUMBER >= 0x10100000 && !defined(LIBRESSL_VERSION_NUMBER) #define ASN1_STRING_data(x) ASN1_STRING_get0_data(x) #endif @@ -157,7 +157,7 @@ tlso_init( void ) (void) tlso_seed_PRNG( lo->ldo_tls_randfile ); #endif -#if OPENSSL_VERSION_NUMBER < 0x10100000 +#if OPENSSL_VERSION_NUMBER < 0x10100000 || defined(LIBRESSL_VERSION_NUMBER) SSL_load_error_strings(); SSL_library_init(); OpenSSL_add_all_digests(); @@ -205,7 +205,7 @@ static void tlso_ctx_ref( tls_ctx *ctx ) { tlso_ctx *c = (tlso_ctx *)ctx; -#if OPENSSL_VERSION_NUMBER < 0x10100000 +#if OPENSSL_VERSION_NUMBER < 0x10100000 || defined(LIBRESSL_VERSION_NUMBER) #define SSL_CTX_up_ref(ctx) CRYPTO_add( &(ctx->references), 1, CRYPTO_LOCK_SSL_CTX ) #endif SSL_CTX_up_ref( c ); @@ -464,7 +464,7 @@ tlso_session_my_dn( tls_session *sess, struct berval * if (!x) return LDAP_INVALID_CREDENTIALS; xn = X509_get_subject_name(x); -#if OPENSSL_VERSION_NUMBER < 0x10100000 +#if OPENSSL_VERSION_NUMBER < 0x10100000 || defined(LIBRESSL_VERSION_NUMBER) der_dn->bv_len = i2d_X509_NAME( xn, NULL ); der_dn->bv_val = xn->bytes->data; #else @@ -500,7 +500,7 @@ tlso_session_peer_dn( tls_session *sess, struct berval return LDAP_INVALID_CREDENTIALS; xn = X509_get_subject_name(x); -#if OPENSSL_VERSION_NUMBER < 0x10100000 +#if OPENSSL_VERSION_NUMBER < 0x10100000 || defined(LIBRESSL_VERSION_NUMBER) der_dn->bv_len = i2d_X509_NAME( xn, NULL ); der_dn->bv_val = xn->bytes->data; #else @@ -721,7 +721,7 @@ struct tls_data { Sockbuf_IO_Desc *sbiod; }; -#if OPENSSL_VERSION_NUMBER < 0x10100000 +#if OPENSSL_VERSION_NUMBER < 0x10100000 || defined(LIBRESSL_VERSION_NUMBER) #define BIO_set_init(b, x) b->init = x #define BIO_set_data(b, x) b->ptr = x #define BIO_clear_flags(b, x) b->flags &= ~(x) @@ -822,7 +822,7 @@ tlso_bio_puts( BIO *b, const char *str ) return tlso_bio_write( b, str, strlen( str ) ); } -#if OPENSSL_VERSION_NUMBER >= 0x10100000 +#if OPENSSL_VERSION_NUMBER >= 0x10100000 && !defined(LIBRESSL_VERSION_NUMBER) struct bio_method_st { int type; const char *name;

1 0

(ITS#8665) limits documentation update for glued databases
by quanah＠openldap.org 01 Jun '17

01 Jun '17

Full_Name: Quanah Gibson-Mount Version: 2.4.43 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) When using glued/subordinate databases, the "limits" directive needs to be set on the parent as well as subordinate dbs to be applied if there are global limits in place. This is currently not documented. Otherwise, the "limits" directive settings on the subordinate databases is not honored.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2017