- openldap-bugs - openldap.org

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

08 Jun '17

A more self-contained log of the same issue, available at ftp://ftp.openldap.org/incoming/its8444.log (line numbers below are against current master, commit 91f4d3a6b75e73bf4ea498e83e2e4cb4e7a320e0) There are some things that occur in all the failures I have seen so far: - the server that received the operation (#1) sends the accesslog entry with no CSN in the cookie, then another provider (#2) picks up this message and relays it to its consumers, this one with a CSN in the cookie - a consumer picks up these two in short succession, in the log above, processing of the one from #2 is finished first (they are being processed concurrently) Usually, once one of them gets processed, the new CSN should be noted and the other threads should just skip it (syncrepl.c:943 and onwards). In this one, having no CSN in the cookie seems to allow both to process so far as to run syncrepl_message_to_op(), and one of them will then inevitably fail to add the entry. I don't understand yet why server #1 sends the operations without a CSN in the cookie and (especially if I reorder the overlays to set up memberof last), the race goes the other way around and the operation to fail is the one from server #2. My take on it was that in a delta-sync environment all entries would be passed with a new CSN and that should end up in the cookie, allowing syncrepl.c:986 to do its job. --=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

Re: (ITS#8672) syncrepl with openldap 2.4.{40,42} and mdb backend
by quanah＠symas.com 08 Jun '17

08 Jun '17

--On Thursday, June 08, 2017 2:06 PM +0000 remy.dernat(a)umontpellier.fr wrote: > Best regards, > R?my Hi, Thanks for the report. Please confirm you can reproduce the issue with OpenLDAP 2.4.45. If you can, then please provide your /initial/ cn=config database prior to doing the modifications 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#8672) syncrepl with openldap 2.4.{40,42} and mdb backend
by remy.dernat＠umontpellier.fr 08 Jun '17

08 Jun '17

Full_Name: Dernat R.my Version: 2.4.40+dfsg-1+deb8u3 and 2.4.42+dfsg-2ubuntu3.2 OS: Debian and Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (162.38.181.76) Hi, Since I moved my OpenLDAP to another server my replication between 2 ldap servers through syncrepl does not work anymore. I tested many many things. Finally, I decided to backup the database and restore it on another server (so, I have 3 ldap servers) and (...) it worked. After many other tests, I was able to determine the source of this issue. With a HDB backend on my provider my replication works, while it did not work with a MDB backend on the provider. I had this kind of logs on the provider (with MDB): ============================================================================= Jun 8 12:22:03 ldap2 slapd[15083]: send_search_entry: conn 20855 ber write failed. Jun 8 12:24:03 ldap2 slapd[15083]: send_search_entry: conn 20888 ber write failed. ... ============================================================================= While, on the slave, I get: ============================================================================= Jun 8 09:33:32 ldap3-bis slapd[88560]: do_syncrepl: rid=010 rc -1 retrying Jun 8 09:38:32 ldap3-bis slapd[88560]: do_syncrep2: rid=010 got search entry without Sync State control (dc=my,dc=domain,dc=com) Jun 8 09:38:32 ldap3-bis slapd[88560]: do_syncrepl: rid=010 rc -1 retrying Jun 8 09:43:32 ldap3-bis slapd[88560]: do_syncrep2: rid=010 got search entry without Sync State control (dc=my,dc=domain,dc=com) ... ============================================================================= I am able to reproduce the bug quite easily. I added only two schemas : autofs and quota. With ============================================================================= ldapadd -Q -Y EXTERNAL -H ldapi:/// -f autofs.ldif ldapadd -Q -Y EXTERNAL -H ldapi:/// -f quota.ldif ============================================================================= I also loaded accesslog module (I am creating a specific directory for accesslog(*)) on the provider and the syncprov module on both sides. ============================================================================= (*) mdkir /var/lib/ldap/accesslog chown openldap:openldap /var/lib/ldap/accesslog ============================================================================= Here is what I am doing to setup the syncrepl : ldapadd -Q -Y EXTERNAL -H ldapi:/// -f file.ldif With file.ldif, on the provider site (replication.ldif ; replacing HDB with MDB to test with a MDB backend): ============================================================================= #Load the syncprov and accesslog modules. dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov - add: olcModuleLoad olcModuleLoad: accesslog # Accesslog database definitions dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=XXXX,dc=YYYY,dc=ZZ olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart # Accesslog db syncprov. dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE # syncrepl Provider for primary db dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE # accesslog overlay definitions for primary db dn: olcOverlay=accesslog,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE # scan the accesslog DB every day, and purge entries older than 7 days olcAccessLogPurge: 07+00:00 01+00:00 ============================================================================= On the consumer (with a unique rid, and by replacing HDB with MDB to test with a MDB backend), the file.ldif looks like: ============================================================================= #Load the syncprov module. dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov # syncrepl specific indices dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: entryUUID eq - add: olcSyncRepl olcSyncRepl: rid=1 provider=ldaps://consumer.mydomain.fr bindmethod=simple binddn="cn=XXXXX,dc=mydomain,dc=fr" credentials=XXXX searchbase="dc=mydomain,dc=fr" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0)) schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog - add: olcUpdateRef olcUpdateRef: ldaps://consumer.mydomain.fr ============================================================================= On the provider I am using: ============================================================================= lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 8.8 (jessie) Release: 8.8 Codename: jessie dpkg -l slapd ii slapd 2.4.40+dfsg-1+de amd64 OpenLDAP server (slapd) ============================================================================= Same configuration on one slave, and on the other slave, I am using: ============================================================================= Distributor ID: Ubuntu Description: Ubuntu 16.04.2 LTS Release: 16.04 Codename: xenial dpkg -l slapd ii slapd 2.4.42+dfsg-2ubu amd64 OpenLDAP server (slapd) ============================================================================= Best regards, Rémy

1 0

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

07 Jun '17

--On Wednesday, June 07, 2017 4:11 PM +0000 quanah(a)symas.com wrote: > --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.... This patch fixed it on my box: quanah@sol11-3:~/git/sold-2445/openldap$ git diff diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 8a62eff..1976340 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -113,6 +113,9 @@ typedef SSIZE_T ssize_t; /* Most platforms have posix_memalign, older may only have memalign */ #define HAVE_MEMALIGN 1 #include <malloc.h> +#if defined (__sun) +#define _POSIX_PTHREAD_SEMANTICS 1 +#endif #endif #if !(defined(BYTE_ORDER) || defined(__BYTE_ORDER)) --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 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 07 Jun '17

07 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 02 Jun '17

02 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

(ITS#8664) lmdb fragmentation leads to DDoS for consumers
by quanah＠openldap.org 01 Jun '17

01 Jun '17

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) If a back-mdb database becomes highly fragmented, it can spend a bit of time trying to find an open slot for an incoming write op. If it is a master server, this will cause all of its consumers to block all incoming read requests until the write op is finished. It also blocks all requests to the master as well. Once the page split completes and the write op is done, things go back to normal until the next page split is required. In the case I'm looking at today, it causes sporadic outages of 6-10 minutes for the master and all consumers. It seems poor design that a write operation on the master will cause its consumers to block all ongoing read operations until that write op is completed. A temporary workaround is to stop slapd, export the DB via slapcat, remove the old db, and then re-import via slapadd to eliminate the database fragmentation. Example gdb backtrace of a consumer: (gdb) thr apply all bt full Thread 10 (Thread 0x7f128f187700 (LWP 14660)): #0 0x00007f3a93816f33 in epoll_wait () from /lib64/libc.so.6 No symbol table info available. #1 0x00000000004366ff in slapd_daemon_task (ptr=0x2cf9eb8) at daemon.c:2517 ns = 1 at = 0 nfds = 20 revents = 0x2d9a000 tvp = 0x7f128f186d80 cat = {tv_sec = 1496211426, tv_usec = 0} i = 1 nwriters = 0 now = 1496211138 tv = {tv_sec = 288, tv_usec = 0} tdelta = 1 rtask = 0x2d2b360 l = 2 last_idle_check = 1495145226 ebadf = 0 tid = 0 #2 0x00007f3a93ac9aa1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #3 0x00007f3a9381693d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 9 (Thread 0x7f128e986700 (LWP 14662)): #0 0x00007f3a93acd68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f3a94fe2c2f in ldap_pvt_thread_cond_wait (cond=0x2d36038, mutex=0x2d36010) at thr_posix.c:277 No locals. #2 0x00007f3a94fe147d in ldap_int_thread_pool_wrapper (xpool=0x2d36000) at tpool.c:938 pq = 0x2d36000 pool = 0x2efa180 task = 0x0 work_list = 0x2d36070 ctx = {ltu_pq = 0x2d36000, ltu_id = 139717678491392, ltu_key = {{ltk_key = 0x4ae533, ltk_data = 0x52c8240, ltk_free = 0x4ae358 <slap_sl_mem_destroy>}, { ltk_key = 0x2f02d00, ltk_data = 0x54d1400, ltk_free = 0x7f3a9000778b <mdb_reader_free>}, {ltk_key = 0x43a3eb, ltk_data = 0x3280e00, ltk_free = 0x43a22f <conn_counter_destroy>}, {ltk_key = 0x455939, ltk_data = 0xad30800, ltk_free = 0x45588c <slap_op_q_destroy>}, {ltk_key = 0x7f3a8fffc5b7, ltk_data = 0x8140000, ltk_free = 0x7f3a8fffc594 <search_stack_free>}, {ltk_key = 0x7f3a8fff9071, ltk_data = 0x7e40000, ---Type <return> to continue, or q <return> to quit--- ltk_free = 0x7f3a8fff9029 <scope_chunk_free>}, {ltk_key = 0x2f03400, ltk_data = 0xa519400, ltk_free = 0x7f3a9000778b <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0xabc9600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 286 hash = 4262449438 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f3a93ac9aa1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007f3a9381693d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 8 (Thread 0x7f128e185700 (LWP 14663)): #0 0x00007f3a93acd68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f3a94fe2c2f in ldap_pvt_thread_cond_wait (cond=0x2d36038, mutex=0x2d36010) at thr_posix.c:277 No locals. #2 0x00007f3a94fe147d in ldap_int_thread_pool_wrapper (xpool=0x2d36000) at tpool.c:938 pq = 0x2d36000 pool = 0x2efa180 task = 0x0 work_list = 0x2d36070 ctx = {ltu_pq = 0x2d36000, ltu_id = 139717670098688, ltu_key = {{ltk_key = 0x4ae533, ltk_data = 0x52c9240, ltk_free = 0x4ae358 <slap_sl_mem_destroy>}, { ltk_key = 0x2f02d00, ltk_data = 0x54d4800, ltk_free = 0x7f3a9000778b <mdb_reader_free>}, {ltk_key = 0x43a3eb, ltk_data = 0x3280a00, ltk_free = 0x43a22f <conn_counter_destroy>}, {ltk_key = 0x455939, ltk_data = 0x6b39800, ltk_free = 0x45588c <slap_op_q_destroy>}, {ltk_key = 0x7f3a8fffc5b7, ltk_data = 0x6e3c000, ltk_free = 0x7f3a8fffc594 <search_stack_free>}, {ltk_key = 0x7f3a8fff9071, ltk_data = 0x6b3c000, ltk_free = 0x7f3a8fff9029 <scope_chunk_free>}, {ltk_key = 0x2f03400, ltk_data = 0xa516000, ltk_free = 0x7f3a9000778b <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x10034000, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 398 hash = 1493194126 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f3a93ac9aa1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007f3a9381693d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 7 (Thread 0x7f128d984700 (LWP 14664)): #0 0x00007f3a93acd68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f3a94fe2c2f in ldap_pvt_thread_cond_wait (cond=0x2d36038, mutex=0x2d36010) at thr_posix.c:277 No locals. #2 0x00007f3a94fe147d in ldap_int_thread_pool_wrapper (xpool=0x2d36000) at tpool.c:938 pq = 0x2d36000 pool = 0x2efa180 task = 0x0 work_list = 0x2d36070 ctx = {ltu_pq = 0x2d36000, ltu_id = 139717661705984, ltu_key = {{ltk_key = 0x4ae533, ltk_data = 0x52c8ec0, ltk_free = 0x4ae358 <slap_sl_mem_destroy>}, { ltk_key = 0x2f02d00, ltk_data = 0x54d2e00, ltk_free = 0x7f3a9000778b <mdb_reader_free>}, {ltk_key = 0x43a3eb, ltk_data = 0x3280b00, ltk_free = 0x43a22f <conn_counter_destroy>}, {ltk_key = 0x455939, ltk_data = 0x6b38000, ltk_free = 0x45588c <slap_op_q_destroy>}, {ltk_key = 0x7f3a8fffc5b7, ltk_data = 0xbb42000, ltk_free = 0x7f3a8fffc594 <search_stack_free>}, {ltk_key = 0x7f3a8fff9071, ltk_data = 0xb842000, ltk_free = 0x7f3a8fff9029 <scope_chunk_free>}, {ltk_key = 0x2f03400, ltk_data = 0xa51c800, ltk_free = 0x7f3a9000778b <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x1384b200, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 189 hash = 1589063869 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f3a93ac9aa1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007f3a9381693d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 6 (Thread 0x7f128d183700 (LWP 14665)): #0 0x00007f3a93acd68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f3a94fe2c2f in ldap_pvt_thread_cond_wait (cond=0x2d36038, mutex=0x2d36010) at thr_posix.c:277 No locals. #2 0x00007f3a94fe147d in ldap_int_thread_pool_wrapper (xpool=0x2d36000) at tpool.c:938 pq = 0x2d36000 pool = 0x2efa180 task = 0x0 work_list = 0x2d36070 ctx = {ltu_pq = 0x2d36000, ltu_id = 139717653313280, ltu_key = {{ltk_key = 0x4ae533, ltk_data = 0x52c8200, ltk_free = 0x4ae358 <slap_sl_mem_destroy>}, { ltk_key = 0x2f03400, ltk_data = 0x54cfa00, ltk_free = 0x7f3a9000778b <mdb_reader_free>}, {ltk_key = 0x7f3a8fffc5b7, ltk_data = 0x58e0000, ltk_free = 0x7f3a8fffc594 <search_stack_free>}, {ltk_key = 0x7f3a8fff9071, ltk_data = 0x55e0000, ltk_free = 0x7f3a8fff9029 <scope_chunk_free>}, { ltk_key = 0x43a3eb, ltk_data = 0x3280200, ltk_free = 0x43a22f <conn_counter_destroy>}, {ltk_key = 0x455939, ltk_data = 0x34e9800, ltk_free = 0x45588c <slap_op_q_destroy>}, {ltk_key = 0x2f02d00, ltk_data = 0xa466000, ltk_free = 0x7f3a9000778b <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0xb5e7600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 301 hash = 3114775853 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f3a93ac9aa1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007f3a9381693d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 5 (Thread 0x7f128c982700 (LWP 14666)): #0 0x00007f3a93acd68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f3a94fe2c2f in ldap_pvt_thread_cond_wait (cond=0x2d36038, mutex=0x2d36010) at thr_posix.c:277 No locals. #2 0x00007f3a94fe147d in ldap_int_thread_pool_wrapper (xpool=0x2d36000) at tpool.c:938 pq = 0x2d36000 pool = 0x2efa180 task = 0x0 work_list = 0x2d36070 ctx = {ltu_pq = 0x2d36000, ltu_id = 139717644920576, ltu_key = {{ltk_key = 0x4ae533, ltk_data = 0x52c81c0, ltk_free = 0x4ae358 <slap_sl_mem_destroy>}, { ltk_key = 0x2f03400, ltk_data = 0x54ce000, ltk_free = 0x7f3a9000778b <mdb_reader_free>}, {ltk_key = 0x2f02d00, ltk_data = 0x54d6200, ltk_free = 0x7f3a9000778b <mdb_reader_free>}, {ltk_key = 0x43a3eb, ltk_data = 0x3280900, ltk_free = 0x43a22f <conn_counter_destroy>}, {ltk_key = 0x455939, ltk_data = 0xa52d800, ltk_free = 0x45588c <slap_op_q_destroy>}, {ltk_key = 0x7f3a8fffc5b7, ltk_data = 0x9440000, ltk_free = 0x7f3a8fffc594 <search_stack_free>}, { ltk_key = 0x7f3a8fff9071, ltk_data = 0x9140000, ltk_free = 0x7f3a8fff9029 <scope_chunk_free>}, {ltk_key = 0x0, ltk_data = 0xdd44800, ltk_free = 0}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 92 hash = 3210645596 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f3a93ac9aa1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007f3a9381693d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 4 (Thread 0x7f128c181700 (LWP 20290)): #0 0x00007f3a93acd68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f3a94fe2c2f in ldap_pvt_thread_cond_wait (cond=0x2d36038, mutex=0x2d36010) at thr_posix.c:277 No locals. #2 0x00007f3a94fe147d in ldap_int_thread_pool_wrapper (xpool=0x2d36000) at tpool.c:938 pq = 0x2d36000 pool = 0x2efa180 task = 0x0 work_list = 0x2d36070 ctx = {ltu_pq = 0x2d36000, ltu_id = 139717636527872, ltu_key = {{ltk_key = 0x4ae533, ltk_data = 0x52c8980, ltk_free = 0x4ae358 <slap_sl_mem_destroy>}, { ltk_key = 0x43a3eb, ltk_data = 0x3281100, ltk_free = 0x43a22f <conn_counter_destroy>}, {ltk_key = 0x455939, ltk_data = 0xffefc00, ltk_free = 0x45588c <slap_op_q_destroy>}, {ltk_key = 0x2f02d00, ltk_data = 0xa517a00, ltk_free = 0x7f3a9000778b <mdb_reader_free>}, {ltk_key = 0x7f3a8fffc5b7, ltk_data = 0xcb42000, ltk_free = 0x7f3a8fffc594 <search_stack_free>}, {ltk_key = 0x7f3a8fff9071, ltk_data = 0xa852000, ltk_free = 0x7f3a8fff9029 <scope_chunk_free>}, {ltk_key = 0x2f03400, ltk_data = 0xa51e200, ltk_free = 0x7f3a9000778b <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x11699600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 204 hash = 441390284 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f3a93ac9aa1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007f3a9381693d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 3 (Thread 0x7f128b980700 (LWP 32177)): #0 0x00007f3a93acd68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f3a94fe2c2f in ldap_pvt_thread_cond_wait (cond=0x2d36038, mutex=0x2d36010) at thr_posix.c:277 No locals. #2 0x00007f3a94fe147d in ldap_int_thread_pool_wrapper (xpool=0x2d36000) at tpool.c:938 pq = 0x2d36000 pool = 0x2efa180 task = 0x0 work_list = 0x2d36070 ctx = {ltu_pq = 0x2d36000, ltu_id = 139717628135168, ltu_key = {{ltk_key = 0x4ae533, ltk_data = 0xde2cf00, ltk_free = 0x4ae358 <slap_sl_mem_destroy>}, { ltk_key = 0x2f02d00, ltk_data = 0xa46e200, ltk_free = 0x7f3a9000778b <mdb_reader_free>}, {ltk_key = 0x43a3eb, ltk_data = 0x329a400, ltk_free = 0x43a22f <conn_counter_destroy>}, {ltk_key = 0x455939, ltk_data = 0x1001a800, ltk_free = 0x45588c <slap_op_q_destroy>}, {ltk_key = 0x7f3a8fffc5b7, ltk_data = 0xe382000, ltk_free = 0x7f3a8fffc594 <search_stack_free>}, {ltk_key = 0x7f3a8fff9071, ltk_data = 0xe082000, ltk_free = 0x7f3a8fff9029 <scope_chunk_free>}, {ltk_key = 0x2f03400, ltk_data = 0xa51ae00, ltk_free = 0x7f3a9000778b <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x10034000, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 1019 hash = 537260027 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f3a93ac9aa1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007f3a9381693d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 2 (Thread 0x7f128b17f700 (LWP 11844)): #0 0x00007f3a93acd68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f3a94fe2c2f in ldap_pvt_thread_cond_wait (cond=0x2d36038, mutex=0x2d36010) at thr_posix.c:277 No locals. #2 0x00007f3a94fe147d in ldap_int_thread_pool_wrapper (xpool=0x2d36000) at tpool.c:938 pq = 0x2d36000 pool = 0x2efa180 task = 0x0 work_list = 0x2d36070 ctx = {ltu_pq = 0x2d36000, ltu_id = 139717619742464, ltu_key = {{ltk_key = 0x43a3eb, ltk_data = 0x2f04100, ltk_free = 0x43a22f <conn_counter_destroy>}, { ltk_key = 0x4ae533, ltk_data = 0xaf35fc0, ltk_free = 0x4ae358 <slap_sl_mem_destroy>}, {ltk_key = 0x455939, ltk_data = 0xaf0f800, ltk_free = 0x45588c <slap_op_q_destroy>}, {ltk_key = 0x2f02d00, ltk_data = 0xb810200, ltk_free = 0x7f3a9000778b <mdb_reader_free>}, {ltk_key = 0x7f3a8fffc5b7, ltk_data = 0x117ca000, ltk_free = 0x7f3a8fffc594 <search_stack_free>}, {ltk_key = 0x7f3a8fff9071, ltk_data = 0x10626000, ltk_free = 0x7f3a8fff9029 <scope_chunk_free>}, {ltk_key = 0x2f03400, ltk_data = 0xfdd6000, ltk_free = 0x7f3a9000778b <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0xb76a400, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 10 hash = 1926945802 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007f3a93ac9aa1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007f3a9381693d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 1 (Thread 0x7f3a95690720 (LWP 14658)): #0 0x00007f3a93aca2fd in pthread_join () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f3a94fe2b70 in ldap_pvt_thread_join (thread=139717686884096, thread_return=0x0) at thr_posix.c:197 No locals. #2 0x000000000043785a in slapd_daemon () at daemon.c:2910 i = 0 rc = 0 #3 0x0000000000414c02 in main (argc=9, argv=0x7fff2a3e4818) at main.c:1017 i = 9 no_detach = 0 rc = 0 urls = 0x2cf4020 "ldap://0.0.0.0:389 ldapi:///" username = 0x2cf8018 "TRUE" groupname = 0x0 sandbox = 0x0 syslogUser = 128 pid = 0 waitfds = {9, 10} g_argc = 9 g_argv = 0x7fff2a3e4818 configfile = 0x0 configdir = 0x2cf4060 "/opt/zimbra/data/ldap/config" serverName = 0x7fff2a3e4deb "slapd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x4f2f08 "" l = 5188080 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = 0 __PRETTY_FUNCTION__ = "main" (gdb) Example backtrace from the master. All threads are paused except thread 5 which is the active write op: (gdb) thr apply all bt full Thread 10 (Thread 0x7f61102bc700 (LWP 18918)): #0 0x00007f891494bf33 in epoll_wait () from /lib64/libc.so.6 No symbol table info available. #1 0x00000000004366ff in slapd_daemon_task (ptr=0x2093eb8) at daemon.c:2517 ns = 1 at = 0 nfds = 1109 revents = 0x2134000 tvp = 0x7f61102bbd80 cat = {tv_sec = 1496211098, tv_usec = 0} i = 1 nwriters = 0 now = 1496210912 tv = {tv_sec = 186, tv_usec = 0} tdelta = 1 rtask = 0x20c5360 l = 2 last_idle_check = 1495145198 ebadf = 0 tid = 0 #2 0x00007f8914bfeaa1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #3 0x00007f891494b93d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 9 (Thread 0x7f610fabb700 (LWP 18919)): #0 0x00007f8914c0268c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f8916117c2f in ldap_pvt_thread_cond_wait (cond=0x2722808, mutex=0x27227e0) at thr_posix.c:277 No locals. #2 0x00007f891611478a in ldap_pvt_thread_rmutex_lock (rmutex=0x2469b28, owner=140054851467008) at rmutex.c:129 rm = 0x27227e0 __PRETTY_FUNCTION__ = "ldap_pvt_thread_rmutex_lock" #3 0x00007f8910adafcf in accesslog_op_mod (op=0x1178ac00, rs=0x7f610fabaa00) at accesslog.c:1984 cb = 0x5c9a4c8 cb2 = 0x7f610fab94e0 on = 0x260cd20 li = 0x2469ac0 lo = 0x7f8910cdfb70 logop = 2 doit = 1 #4 0x00000000004cec1d in overlay_op_walk (op=0x1178ac00, rs=0x7f610fabaa00, which=op_modify, oi=0x260c780, on=0x260cd20) at backover.c:661 func = 0x260cd78 rc = 32768 #5 0x00000000004ceee8 in over_op_func (op=0x1178ac00, rs=0x7f610fabaa00, which=op_modify) at backover.c:730 oi = 0x260c780 on = 0x260c960 be = 0x25fc4e0 db = {bd_info = 0x260cd20, bd_self = 0x25fc4e0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x25c20c0, be_nsuffix = 0x25c2100, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x2588440 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x2588460 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x25f1880, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x2629980, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x2418680, be_pb = 0x0, be_cf_ocs = 0x7f8911361180, be_private = 0x297a000, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x5c9a4c8, sc_response = 0x4cdc92 <over_back_response>, sc_cleanup = 0, sc_writewait = 0, sc_private = 0x260c780} sc = 0x7f610fab96e0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #6 0x00000000004cf024 in over_op_modify (op=0x1178ac00, rs=0x7f610fabaa00) at backover.c:769 No locals. #7 0x000000000045b18e in fe_op_modify (op=0x1178ac00, rs=0x7f610fabaa00) at modify.c:303 update = 0 repl_user = 0 op_be = 0x25fc4e0 bd = 0x75a900 textbuf = "\024\000\000\000\021\000\000\000\000)+\002\000\000\000\000\300\227\253\017a\177\000\000)\034F", '\000' <repeats 13 times>"\340, \235\016\021\000\000\000\000`\323\317\017\000\000\000\000\000v+\002\000\000\000\000\000\235B\002\000\000\000\000\002\000\000\000\000\000\000\000\300\062\241\021\000\000\000\000\300\227\253\017a\177", '\000' <repeats 18 times>, "\017\000\000\000\000\000\000\000\020\353\071\020", '\000' <repeats 12 times>, " \000\000\000\000\000\000\000З\253\017a\177\000\000\000\000\000\000\000\000\000\000`\230\253\017a\177\000\000ܻE", '\000' <repeats 14 times>, "\001\000\000\000\000\000\000\220\250\253\017a\177\000\000 \252\253\017a\177", '\000' <repeats 11 times>"\254, x\021\000\000\000\000`\230\253\017a\177\000\000\065yE\000\000\000\000\000\060\230\253\017a\177\000\000\200"... textlen = 256 #8 0x000000000045aa60 in do_modify (op=0x1178ac00, rs=0x7f610fabaa00) at modify.c:177 dn = {bv_len = 48, bv_val = 0x10061b87 "uid=gerald,ou=people,dc=xxxxxxxx,dc=co,dc=za"} textbuf = "\240\250\253\017a\177\000\000\000\000\000\000\000\000\000\000p\251\253\017a\177\000\000\020\330\373\020\000\000\000\000\377\377\377\377\377\377\377\377\271\317\311\000\000\000\000\000\006\000\000\000\000\000\000\000\354\006\360\025\211\177\000\000 \251\253\017a\177\000\000Z\373\357\025\211\177\000\000\000\000\000\000\000\000\000\000\b\---Type <return> to continue, or q <return> to quit--- 000\000\000\000\000\000\000\317\372\004\020\000\000\000\000 \342h\022\000\000\000\000\200$f\004", '\000' <repeats 12 times>"\200, $f\004\000\000\000\000x\251\253\017a\177\000\000\063\345J\000\000\000\000\000\060\253\253\017a\177\000\000\060\253\253\017a\177\000\000\300\372\004\020\001\000\000\000Щ\253\017a\177\000\000\022\346J\000\000\000\000\000p\251\253\017\001\000\000\000\060\253\253\017a\177\000\000\000\000\000\000\001\000\000\000\000\000\020", '\000' <repeats 13 times>"\200, $f\004\000\000\000\000\200$f\004\000\000\000\000\060\253\253\017a\177\000" textlen = 256 tmp = 0x0 #9 0x000000000043a89a in connection_operation (ctx=0x7f610fabab30, arg_v=0x1178ac00) at connection.c:1135 rc = 80 cancel = 0 op = 0x1178ac00 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 102 opidx = SLAP_OP_MODIFY conn = 0x2afc840 memctx = 0x4662480 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #10 0x000000000043ae3b in connection_read_thread (ctx=0x7f610fabab30, argv=0x403) at connection.c:1271 rc = 0 cri = {op = 0x1178ac00, func = 0, arg = 0x0, ctx = 0x7f610fabab30, nullop = 0} s = 1027 #11 0x00007f8916116552 in ldap_int_thread_pool_wrapper (xpool=0x20d0000) at tpool.c:956 pq = 0x20d0000 pool = 0x2294180 task = 0xfd71980 work_list = 0x20d0070 ctx = {ltu_pq = 0x20d0000, ltu_id = 140054851467008, ltu_key = {{ltk_key = 0x43a3eb, ltk_data = 0x261ad00, ltk_free = 0x43a22f <conn_counter_destroy>}, { ltk_key = 0x4ae533, ltk_data = 0x4662480, ltk_free = 0x4ae358 <slap_sl_mem_destroy>}, {ltk_key = 0x229cd00, ltk_data = 0x498ce00, ltk_free = 0x7f891113c78b <mdb_reader_free>}, {ltk_key = 0x455939, ltk_data = 0x0, ltk_free = 0x45588c <slap_op_q_destroy>}, {ltk_key = 0x7f89111315b7, ltk_data = 0x87c2000, ltk_free = 0x7f8911131594 <search_stack_free>}, {ltk_key = 0x7f891112e071, ltk_data = 0x84c2000, ltk_free = 0x7f891112e029 <scope_chunk_free>}, {ltk_key = 0x229d400, ltk_data = 0x9857a00, ltk_free = 0x7f891113c78b <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0xdd55600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 17 hash = 2893171729 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #12 0x00007f8914bfeaa1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #13 0x00007f891494b93d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 8 (Thread 0x7f610f2ba700 (LWP 18920)): #0 0x00007f8914c0268c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f8916117c2f in ldap_pvt_thread_cond_wait (cond=0x2722808, mutex=0x27227e0) at thr_posix.c:277 No locals. #2 0x00007f891611478a in ldap_pvt_thread_rmutex_lock (rmutex=0x2469b28, owner=140054843074304) at rmutex.c:129 rm = 0x27227e0 __PRETTY_FUNCTION__ = "ldap_pvt_thread_rmutex_lock" #3 0x00007f8910adafcf in accesslog_op_mod (op=0x1055e800, rs=0x7f610f2b9a00) at accesslog.c:1984 cb = 0x46684c8 cb2 = 0x7f610f2b84e0 on = 0x260cd20 li = 0x2469ac0 lo = 0x7f8910cdfb70 logop = 2 doit = 1 #4 0x00000000004cec1d in overlay_op_walk (op=0x1055e800, rs=0x7f610f2b9a00, which=op_modify, oi=0x260c780, on=0x260cd20) at backover.c:661 func = 0x260cd78 rc = 32768 #5 0x00000000004ceee8 in over_op_func (op=0x1055e800, rs=0x7f610f2b9a00, which=op_modify) at backover.c:730 oi = 0x260c780 on = 0x260c960 be = 0x25fc4e0 db = {bd_info = 0x260cd20, bd_self = 0x25fc4e0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x25c20c0, be_nsuffix = 0x25c2100, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x2588440 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x2588460 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x25f1880, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x2629980, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x2418680, be_pb = 0x0, be_cf_ocs = 0x7f8911361180, be_private = 0x297a000, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x46684c8, sc_response = 0x4cdc92 <over_back_response>, sc_cleanup = 0, sc_writewait = 0, sc_private = 0x260c780} sc = 0x7f610f2b86e0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #6 0x00000000004cf024 in over_op_modify (op=0x1055e800, rs=0x7f610f2b9a00) at backover.c:769 No locals. #7 0x000000000045b18e in fe_op_modify (op=0x1055e800, rs=0x7f610f2b9a00) at modify.c:303 update = 0 repl_user = 0 op_be = 0x25fc4e0 bd = 0x75a900 textbuf = "\024\000\000\000\021\000\000\000\000)+\002\000\000\000\000\300\207+\017a\177\000\000)\034F", '\000' <repeats 13 times>"\240, {S\020\000\000\000\000\240uS\020\000\000\000\000\000v+\002\000\000\000\000\000\235B\002\000\000\000\000\002\000\000\000\000\000\000\000\000\063\352\r\000\000\000\000\300\207+\017a\177", '\000' <repeats 18 times>, "\017\000\000\000\000\000\000\000\220@\313\021", '\000' <repeats 12 times>, " \000\000\000\000\000\000\000Ї+\017a\177\000\000\000\000\000\000\000\000\000\000`\210+\017a\177\000\000ܻE", '\000' <repeats 14 times>, "\001\000\000\000\000\000\000\220\230+\017a\177\000\000 \232+\017a\177", '\000' <repeats 11 times>"\350, U\020\000\000\000\000`\210+\017a\177\000\000\065yE\000\000\000\000\000"... textlen = 256 #8 0x000000000045aa60 in do_modify (op=0x1055e800, rs=0x7f610f2b9a00) at modify.c:177 dn = {bv_len = 47, bv_val = 0x1064f967 "uid=lionel.xxxxxxxx,ou=people,dc=xxxxxxxxxx,dc=co,dc=za"} textbuf = "\240\230+\017a\177\000\000\000\000\000\000\000\000\000\000p\231+\017a\177\000\000 h\201\020\000\000\000\000\377\377\377\377\377\377\377\377\376\315\311\000\000\000\000\000\004\000\000\000\000\000\000\000\354\006\360\025\211\177\000\000 \231+\017a\177\000\000Z\373\357\025\211\177\000\000\000\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000O]\246\020\000\000\000\000\320O\231\020\000\000\000\000\300!f\004", '\000' <repeats 12 times>"\300, !f\004\000\000\000\000x\231+\017a\177\000\000\063\345J\000\000\000\000\000\060\233+\017a\177\000\000\060\233+\017a\177\000\000@]\246\020\000\000\000\000Й+\017a\177\000\000\022\346J\000\000\000\000\000p\231+\017\001\000\000\000\060\233+\017a\177\000\000\000\000\000\000\001\000\000\000\000\000\020", '\000' <repeats 13 times>"\300, !f\004\000\000\000\000\300!f"... textlen = 256 tmp = 0x0 #9 0x000000000043a89a in connection_operation (ctx=0x7f610f2b9b30, arg_v=0x1055e800) at connection.c:1135 rc = 80 cancel = 0 op = 0x1055e800 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 102 opidx = SLAP_OP_MODIFY conn = 0x2a94300 memctx = 0x46621c0 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #10 0x000000000043ae3b in connection_read_thread (ctx=0x7f610f2b9b30, argv=0x1a4) at connection.c:1271 rc = 0 cri = {op = 0x1055e800, func = 0, arg = 0x0, ctx = 0x7f610f2b9b30, nullop = 0} s = 420 #11 0x00007f8916116552 in ldap_int_thread_pool_wrapper (xpool=0x20d0000) at tpool.c:956 pq = 0x20d0000 pool = 0x2294180 task = 0xfe6e2e0 work_list = 0x20d0070 ctx = {ltu_pq = 0x20d0000, ltu_id = 140054843074304, ltu_key = {{ltk_key = 0x4ae533, ltk_data = 0x46621c0, ltk_free = 0x4ae358 <slap_sl_mem_destroy>}, { ltk_key = 0x229d400, ltk_data = 0x4989a00, ltk_free = 0x7f891113c78b <mdb_reader_free>}, {ltk_key = 0x43a3eb, ltk_data = 0x261ac00, ltk_free = 0x43a22f <conn_counter_destroy>}, {ltk_key = 0x229cd00, ltk_data = 0x498e800, ltk_free = 0x7f891113c78b <mdb_reader_free>}, {ltk_key = 0x455939, ltk_data = 0x0, ltk_free = 0x45588c <slap_op_q_destroy>}, {ltk_key = 0x7f89111315b7, ltk_data = 0x9dea000, ltk_free = 0x7f8911131594 <search_stack_free>}, { ltk_key = 0x7f891112e071, ltk_data = 0x9aea000, ltk_free = 0x7f891112e029 <scope_chunk_free>}, {ltk_key = 0x0, ltk_data = 0x11d48800, ltk_free = 0}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 129 hash = 123916417 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #12 0x00007f8914bfeaa1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #13 0x00007f891494b93d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 7 (Thread 0x7f610eab9700 (LWP 18921)): #0 0x00007f8914c0268c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f8916117c2f in ldap_pvt_thread_cond_wait (cond=0x2722808, mutex=0x27227e0) at thr_posix.c:277 No locals. #2 0x00007f891611478a in ldap_pvt_thread_rmutex_lock (rmutex=0x2469b28, owner=140054834681600) at rmutex.c:129 rm = 0x27227e0 __PRETTY_FUNCTION__ = "ldap_pvt_thread_rmutex_lock" #3 0x00007f8910adafcf in accesslog_op_mod (op=0xfeacc00, rs=0x7f610eab8a00) at accesslog.c:1984 cb = 0x47684b8 cb2 = 0x7f610eab74e0 on = 0x260cd20 li = 0x2469ac0 lo = 0x7f8910cdfb70 logop = 2 doit = 1 #4 0x00000000004cec1d in overlay_op_walk (op=0xfeacc00, rs=0x7f610eab8a00, which=op_modify, oi=0x260c780, on=0x260cd20) at backover.c:661 func = 0x260cd78 rc = 32768 #5 0x00000000004ceee8 in over_op_func (op=0xfeacc00, rs=0x7f610eab8a00, which=op_modify) at backover.c:730 oi = 0x260c780 on = 0x260c960 be = 0x25fc4e0 db = {bd_info = 0x260cd20, bd_self = 0x25fc4e0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x25c20c0, be_nsuffix = 0x25c2100, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x2588440 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x2588460 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x25f1880, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x2629980, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x2418680, be_pb = 0x0, be_cf_ocs = 0x7f8911361180, be_private = 0x297a000, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x47684b8, sc_response = 0x4cdc92 <over_back_response>, sc_cleanup = 0, sc_writewait = 0, sc_private = 0x260c780} sc = 0x7f610eab76e0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #6 0x00000000004cf024 in over_op_modify (op=0xfeacc00, rs=0x7f610eab8a00) at backover.c:769 No locals. #7 0x000000000045b18e in fe_op_modify (op=0xfeacc00, rs=0x7f610eab8a00) at modify.c:303 update = 0 repl_user = 0 op_be = 0x25fc4e0 bd = 0x75a900 textbuf = "\024\000\000\000\021\000\000\000\000)+\002\000\000\000\000\300w\253\016a\177\000\000)\034F", '\000' <repeats 13 times>"\300, '\314\020\000\000\000\000\240\217\214\017\000\000\000\000\000v+\002\000\000\000\000\000\235B\002\000\000\000\000\002\000\000\000\000\000\000\000@\227l\020\000\000\000\000\300w\253\016a\177", '\000' <repeats 18 times>, "\017\000\000\000\000\000\000\000\360~\355\017", '\000' <repeats 12 times>, " \000\000\000\000\000\000\000\320w\253\016a\177\000\000\000\000\000\000\000\000\000\000`x\253\016a\177\000\000ܻE", '\000' <repeats 14 times>, "\001\000\000\000\000\000\000\220\210\253\016a\177\000\000 \212\253\016a\177", '\000' <repeats 11 times>"\314, \352\017\000\000\000\000`x\253\016a\177\000\000\065yE\000\000\000\000\000\005\000\000\000\000\000\000\000\000"... textlen = 256 #8 0x000000000045aa60 in do_modify (op=0xfeacc00, rs=0x7f610eab8a00) at modify.c:177 dn = {bv_len = 45, bv_val = 0x27252c7 "uid=brianvxxxxxx,ou=people,dc=xxxxxxxxx,dc=co,dc=za"} textbuf = "\240\210\253\016a\177\000\000p\002i\022\000\000\000\000p\211\253\016a\177\000\000\200Y\243\020\000\000\000\000\377\377\377\377\377\377\377\377\266\316\311\000\---Type <return> to continue, or q <return> to quit--- 000\000\000\000\006\000\000\000\000\000\000\000\354\006\360\025\211\177\000\000 \211\253\016a\177\000\000Z\373\357\025\211\177\000\000\000\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000ϰ\003\v\000\000\000\000\320\306\333\021\000\000\000\000\000\"f\004", '\000' <repeats 13 times>, "\"f\004\000\000\000\000x\211\253\016a\177\000\000\063\345J\000\000\000\000\000\060\213\253\016a\177\000\000\060\213\253\016a\177\000\000\300\260\003\v\000\000\000\000Љ\253\016a\177\000\000\022\346J\000\000\000\000\000p\211\253\016\001\000\000\000\060\213\253\016a\177\000\000\000\000\000\000\001\000\000\000\000\000\020", '\000' <repeats 14 times>, "\"f\004\000\000\000\000\000\"f\004\000\000\000\000\060\213\253\016a\177\000" textlen = 256 tmp = 0x0 #9 0x000000000043a89a in connection_operation (ctx=0x7f610eab8b30, arg_v=0xfeacc00) at connection.c:1135 rc = 80 cancel = 0 op = 0xfeacc00 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 102 opidx = SLAP_OP_MODIFY conn = 0x2ac9fc0 memctx = 0x4662200 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #10 0x000000000043ae3b in connection_read_thread (ctx=0x7f610eab8b30, argv=0x2dd) at connection.c:1271 rc = 0 cri = {op = 0xfeacc00, func = 0, arg = 0x0, ctx = 0x7f610eab8b30, nullop = 0} s = 733 #11 0x00007f8916116552 in ldap_int_thread_pool_wrapper (xpool=0x20d0000) at tpool.c:956 pq = 0x20d0000 pool = 0x2294180 task = 0x101f22a0 work_list = 0x20d0070 ctx = {ltu_pq = 0x20d0000, ltu_id = 140054834681600, ltu_key = {{ltk_key = 0x4ae533, ltk_data = 0x4662200, ltk_free = 0x4ae358 <slap_sl_mem_destroy>}, { ltk_key = 0x229d400, ltk_data = 0x4988000, ltk_free = 0x7f891113c78b <mdb_reader_free>}, {ltk_key = 0x7f89111315b7, ltk_data = 0x4c92000, ltk_free = 0x7f8911131594 <search_stack_free>}, {ltk_key = 0x7f891112e071, ltk_data = 0x4992000, ltk_free = 0x7f891112e029 <scope_chunk_free>}, { ltk_key = 0x43a3eb, ltk_data = 0x261a800, ltk_free = 0x43a22f <conn_counter_destroy>}, {ltk_key = 0x229cd00, ltk_data = 0x71a9a00, ltk_free = 0x7f891113c78b <mdb_reader_free>}, {ltk_key = 0x455939, ltk_data = 0xb14e800, ltk_free = 0x45588c <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x99ab600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 1008 hash = 222086128 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #12 0x00007f8914bfeaa1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #13 0x00007f891494b93d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 6 (Thread 0x7f610e2b8700 (LWP 18922)): #0 0x00007f8914c0268c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f8916117c2f in ldap_pvt_thread_cond_wait (cond=0x2722808, mutex=0x27227e0) at thr_posix.c:277 No locals. #2 0x00007f891611478a in ldap_pvt_thread_rmutex_lock (rmutex=0x2469b28, owner=140054826288896) at rmutex.c:129 rm = 0x27227e0 __PRETTY_FUNCTION__ = "ldap_pvt_thread_rmutex_lock" #3 0x00007f8910adafcf in accesslog_op_mod (op=0x11150400, rs=0x7f610e2b7a00) at accesslog.c:1984 cb = 0x486c4b8 cb2 = 0x7f610e2b64e0 on = 0x260cd20 li = 0x2469ac0 lo = 0x7f8910cdfb70 logop = 2 doit = 1 #4 0x00000000004cec1d in overlay_op_walk (op=0x11150400, rs=0x7f610e2b7a00, which=op_modify, oi=0x260c780, on=0x260cd20) at backover.c:661 func = 0x260cd78 rc = 32768 #5 0x00000000004ceee8 in over_op_func (op=0x11150400, rs=0x7f610e2b7a00, which=op_modify) at backover.c:730 oi = 0x260c780 on = 0x260c960 be = 0x25fc4e0 db = {bd_info = 0x260cd20, bd_self = 0x25fc4e0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x25c20c0, be_nsuffix = 0x25c2100, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x2588440 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x2588460 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x25f1880, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x2629980, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x2418680, be_pb = 0x0, be_cf_ocs = 0x7f8911361180, be_private = 0x297a000, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x486c4b8, sc_response = 0x4cdc92 <over_back_response>, sc_cleanup = 0, sc_writewait = 0, sc_private = 0x260c780} sc = 0x7f610e2b66e0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #6 0x00000000004cf024 in over_op_modify (op=0x11150400, rs=0x7f610e2b7a00) at backover.c:769 No locals. #7 0x000000000045b18e in fe_op_modify (op=0x11150400, rs=0x7f610e2b7a00) at modify.c:303 update = 0 repl_user = 0 op_be = 0x25fc4e0 bd = 0x75a900 textbuf = "\024\000\000\000\021\000\000\000\000)+\002\000\000\000\000\300g+\016a\177\000\000)\034F", '\000' <repeats 13 times>, "@\227\016\021\000\000\000\000 \212\016\021\000\000\000\000\000v+\002\000\000\000\000\000\235B\002\000\000\000\000\002\000\000\000\000\000\000\000\200]\301\021\000\000\000\000\300g+\016a\177", '\000' <repeats 18 times>, "\017\000\000\000\000\000\000\000\240\004\016\021", '\000' <repeats 12 times>, " \000\000\000\000\000\000\000\320g+\016a\177\000\000\000\000\000\000\000\000\000\000`h+\016a\177\000\000ܻE", '\000' <repeats 14 times>, "\001\000\000\000\000\000\000\220x+\016a\177\000\000 z+\016a\177", '\000' <repeats 11 times>, "\004\025\021\000\000\000\000`h+\016a"... textlen = 256 #8 0x000000000045aa60 in do_modify (op=0x11150400, rs=0x7f610e2b7a00) at modify.c:177 dn = {bv_len = 46, bv_val = 0x119b4d28 "uid=gerald,ou=people,dc=xxxxxxxxx,dc=co,dc=za"} textbuf = "\240x+\016a\177\000\000\360\204\251\021\000\000\000\000py+\016a\177\000\000P\205%\v\000\000\000\000\377\377\377\377\377\377\377\377\231Q\275\000\000\000\000\000\347\v\000\000\000\000\000\000\354\006\360\025\211\177\000\000 y+\016a\177\000\000Z\373\357\025\211\177\000\000\000\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000o\030(\v\000\000\000\000\340\264W\022\000\000\000\000@\"f\004", '\000' <repeats 12 times>, "@\"f\004\000\000\000\000xy+\016a\177\000\000\063\345J\000\000\000\000\000\060{+\016a\177\000\000\060{+\016a\177\000\000`\030(\v\000\000\000\000\320y+\016a\177\000\000\022\346J\000\000\000\000\000py+\016\001\000\000\000\060{+\016a\177\000\000\000\000\000\000\001\000\000\000\000\000\020", '\000' <repeats 13 times>... textlen = 256 tmp = 0x0 #9 0x000000000043a89a in connection_operation (ctx=0x7f610e2b7b30, arg_v=0x11150400) at connection.c:1135 rc = 80 cancel = 0 op = 0x11150400 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 102 opidx = SLAP_OP_MODIFY conn = 0x2a6c500 memctx = 0x4662240 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #10 0x000000000043ae3b in connection_read_thread (ctx=0x7f610e2b7b30, argv=0xbc) at connection.c:1271 rc = 0 cri = {op = 0x11150400, func = 0, arg = 0x0, ctx = 0x7f610e2b7b30, nullop = 0} s = 188 #11 0x00007f8916116552 in ldap_int_thread_pool_wrapper (xpool=0x20d0000) at tpool.c:956 pq = 0x20d0000 pool = 0x2294180 task = 0xfc2dac0 work_list = 0x20d0070 ctx = {ltu_pq = 0x20d0000, ltu_id = 140054826288896, ltu_key = {{ltk_key = 0x4ae533, ltk_data = 0x4662240, ltk_free = 0x4ae358 <slap_sl_mem_destroy>}, { ltk_key = 0x229cd00, ltk_data = 0x498b400, ltk_free = 0x7f891113c78b <mdb_reader_free>}, {ltk_key = 0x43a3eb, ltk_data = 0x261ae00, ltk_free = 0x43a22f <conn_counter_destroy>}, {ltk_key = 0x7f89111315b7, ltk_data = 0x609a000, ltk_free = 0x7f8911131594 <search_stack_free>}, { ltk_key = 0x7f891112e071, ltk_data = 0x5d9a000, ltk_free = 0x7f891112e029 <scope_chunk_free>}, {ltk_key = 0x455939, ltk_data = 0x11151000, ltk_free = 0x45588c <slap_op_q_destroy>}, {ltk_key = 0x229d400, ltk_data = 0x71b0200, ltk_free = 0x7f891113c78b <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0xc8f8000, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 96 hash = 1747798112 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #12 0x00007f8914bfeaa1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #13 0x00007f891494b93d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 5 (Thread 0x7f610dab7700 (LWP 18925)): #0 0x00007f8911153c7a in mdb_midl_xmerge (idl=0x12ec2008, merge=0x7f6110b1b010) at ./../../../libraries/liblmdb/midl.c:207 old_id = 876237 merge_id = 2291035 i = 508 j = 812516 k = 813025 total = 1138842 #1 0x00007f89111422f8 in mdb_page_alloc (mc=0x7f610dab4f80, num=212, mp=0x7f610dab4a60) at ./../../../libraries/liblmdb/mdb.c:2215 key = {mv_size = 8, mv_data = 0x7f6110c05d68} data = {mv_size = 4080, mv_data = 0x7f6110b1b010} leaf = 0x7f6110c05d60 idl = 0x7f6110b1b010 rc = 0 retry = 10484 txn = 0x4654000 env = 0x229cd00 pgno = 2290667 mop = 0x12ec2008 i = 509 j = 32609 mop_len = 1138333 n2 = 211 np = 0x7f6110c05000 oldest = 139368742 last = 139366008 op = MDB_NEXT m2 = {mc_next = 0x0, mc_backup = 0x0, mc_xcursor = 0x0, mc_txn = 0x4654000, mc_dbi = 0, mc_db = 0x4654088, mc_dbx = 0x2622800, mc_dbflag = 0x4655f00 "\b\030\032\030\031\032\032\031", '\032' <repeats 32 times>, mc_snum = 3, mc_top = 2, mc_flags = 1, mc_pg = {0x7f61216da000, 0x7f61216db000, 0x7f6110c05000, 0x7f610dab5170, 0x7f610dab4f80, 0x7f610dab4aa0, 0x7f8911146e37, 0x0, 0x100000000, 0x2622950, 0x7f610dab4cb0, 0x0, 0x7f610dab4f30, 0x7f610dab4c90, 0x7f891114972c, 0x0, 0x111f6d80, 0x0 <repeats 15 times>}, mc_ki = {0, 29, 27, 0 <repeats 13 times>, 16384, 1125, 0, 0, 1, 0, 32609, 0, 16568, 1125, 0, 0, 10288, 610, 0, 0}} found_old = 0 #2 0x00007f891114bbc1 in mdb_page_new (mc=0x7f610dab4f80, flags=4, num=212, mp=0x7f610dab4ac8) at ./../../../libraries/liblmdb/mdb.c:6940 np = 0x0 rc = 0 #3 0x00007f891114bfea in mdb_node_add (mc=0x7f610dab4f80, indx=3, key=0x7f610dab5170, data=0x7f610dab5160, pgno=0, flags=65536) at ./../../../libraries/liblmdb/mdb.c:7081 ovpages = 212 rc = 0 i = 32609 node_size = 24 room = 124 ofs = 0 node = 0x7f61217c6000 mp = 0x7f61217c6000 ofp = 0x0 ndata = 0x7f610dab5170 __FUNCTION__ = "mdb_node_add" #4 0x00007f891114ae20 in mdb_cursor_put (mc=0x7f610dab4f80, key=0x7f610dab5170, data=0x7f610dab5160, flags=65536) at ./../../../libraries/liblmdb/mdb.c:6697 env = 0x229cd00 leaf = 0x7f61217c6088 fp = 0x5 mp = 0x7f6121753a4d sub_root = 0x0 fp_flags = 0 xdata = {mv_size = 0, mv_data = 0x111f6f08} rdata = 0x7f610dab5160 dkey = {mv_size = 0, mv_data = 0x7f610dab4d10} olddata = {mv_size = 867304, mv_data = 0x7f61217c6098} dummy = {md_pad = 229330192, md_flags = 0, md_depth = 0, md_branch_pages = 0, md_leaf_pages = 287272712, md_overflow_pages = 140055149886356, md_entries = 140054817885328, md_root = 140226673805067} do_sub = 0 insert_key = 0 insert_data = 0 mcount = 0 dcount = 0 nospill = 0 nsize = 26 rc = 0 rc2 = 0 nflags = 65536 __FUNCTION__ = "mdb_cursor_put" #5 0x00007f891115257f in mdb_put (txn=0x4654000, dbi=4, key=0x7f610dab5170, data=0x7f610dab5160, flags=65536) at ./../../../libraries/liblmdb/mdb.c:8771 mc = {mc_next = 0x0, mc_backup = 0x0, mc_xcursor = 0x0, mc_txn = 0x4654000, mc_dbi = 4, mc_db = 0x4654148, mc_dbx = 0x26228c0, mc_dbflag = 0x4655f04 "\031\032\032\031", '\032' <repeats 32 times>, mc_snum = 4, mc_top = 3, mc_flags = 1, mc_pg = {0x7f612177f000, 0x7f6121787000, 0x7f61217a1000, 0x7f61217c6000, 0x7f8900000000, 0x7f891113e80a, 0x7f891115aec2, 0x70cb1f0, 0x4654000, 0x7f610dab50b0, 0x7f8911134687, 0x103, 0x1, 0x4, 0x7f8911132765, 0xb237ee0, 0x20b8860, 0x2096b40, 0x20b8840, 0x4654000, 0x10641000, 0x7f610dab50b8, 0x70cb1f0, 0x4, 0x104662780, 0x2584f00, 0x70cb130, 0x4020c25b0, 0x4654000, 0x7f610dab5120, 0x7f891113480e, 0x103}, mc_ki = {0, 0, 30, 3, 20864, 3499, 32609, 0, 21088, 3499, 32609, 0, 16384, 1125, 0, 0, 40960, 663, 0, 0, 16384, 1125, 0, 0, 15336, 13, 0, 0, 1, 0, 64, 0}} mx = {mx_cursor = {mc_next = 0x7f610dab4e40, mc_backup = 0x2459000, mc_xcursor = 0x229cd00, mc_txn = 0x7f6121753a40, mc_dbi = 561330765, mc_db = 0x0, mc_dbx = 0x7f610dab4f30, mc_dbflag = 0x7f610dab4f20 "\b", mc_snum = 0, mc_top = 0, mc_flags = 0, mc_pg = {0x1, 0x0, 0x7f610dab4f30, 0xdab4e50, 0x7f6100000000, 0x4662780, 0x7f6121753000, 0x821753a40, 0x7f6121753000, 0x70cb218, 0x7f6121753d0b, 0x0, 0x111f6d80, 0x7f610dab4ec0, 0x7f8911149131, 0xf0dab4ec0, 0x7f610dab4f20, 0x7f610dab4f30, 0x8010, 0x52, 0x0, 0x111f6f08, 0x30dab4fe0, 0x7f6121753000, 0x40dab4ef8, 0x111f6d80, 0x7f8915efdec2, 0x7f6121753a40, 0x7f610dab4f30, 0x4662780, 0x70cb1f0, 0x4662780}, mc_ki = {40, 0, 0, 0, 45544, 1804, 0, 0, 45584, 1804, 0, 0, 32480, 2851, 0, 0, 82, 0, 0, 0, 33376, 555, 0, 0, 14720, 555, 0, 0, 4, 0, 0, 0}}, mx_db = {md_pad = 327, md_flags = 0, md_depth = 0, md_branch_pages = 8, md_leaf_pages = 287272320, md_overflow_pages = 140054817886032, md_entries = 287272320, md_root = 140054817886080}, mx_dbx = {md_name = {mv_size = 140054859848832, mv_data = 0x7f610dab79c0}, md_cmp = 0x7f891114d1f2 <mdb_cursor_close+181>, md_dcmp = 0x4662780, md_rel = 0x111f6d80, md_relctx = 0x100000001}, mx_dbflag = 32 ' '} rc = 46 #6 0x00007f891113b932 in mdb_id2entry_put (op=0x10641000, txn=0x4654000, mc=0x0, e=0x7f610dab5260, flag=65536) at id2entry.c:71 mdb = 0x297a000 ec = {len = 867304, nattrs = 64, nvals = 4271, offset = 4289} key = {mv_size = 8, mv_data = 0x7f610dab5260} data = {mv_size = 867304, mv_data = 0xf87dc00} rc = 0 #7 0x00007f891113bac1 in mdb_id2entry_update (op=0x10641000, txn=0x4654000, mc=0x0, e=0x7f610dab5260) at id2entry.c:114 No locals. #8 0x00007f891112a52e in mdb_modify (op=0x10641000, rs=0x7f610dab6a00) at modify.c:637 mdb = 0x297a000 e = 0x70b9c70 manageDSAit = 0 textbuf = "\200'f\004\000\000\000\000\360\205\n\a\000\000\000\000H\020d\020\000\000\000\000H\020d\020\000\000\000\000\200\307`\002\000\000\000\000\020U\253\ra\177\000\000@\313`\002\000\000\000\000\340ba\002\000\000\000\000\340ba\002\000\000\000\000\250\207\n\a\000\000\000\000\200S\253\r\000\000\000\000\000j\253\r\000\000\000\000\020U\253\ra\177\000\000p\361J\000\000\000\000\000\070\205\n\a\000\000\000\000\200'f\004\000\000\000\000\260\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\330\204\n\a\000\000\000\000\000j\253\ra\177\000\000PT\253\ra\177\000\000\213\243\316\020\211\177\000\000\000j\253\ra\177\000\000\000\020d\020\000\000\000\000\070\205\n\a\000\000\000\000\000\020d\020\000\000\000\000ؑ\n\a\000\000\000\000H\020d\020\000\000\000\000PT\253\ra\177"... textlen = 256 txn = 0x4654000 opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x297a000}, moi_txn = 0x4654000, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7f610dab52c0 dummy = {e_id = 259, e_name = {bv_len = 43, bv_val = 0x70b9c38 "uid=george,ou=people,dc=xxxxxxx,dc=co,dc=za"}, e_nname = {bv_len = 43, bv_val = 0x70cb1b8 "uid=george,ou=people,dc=xxxxxxxx,dc=co,dc=za"}, e_attrs = 0xfd2cf68, e_ocflags = 256, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x70b9c70} preread_ctrl = 0x0 postread_ctrl = 0x0 ctrls = {0x0, 0x10641000, 0x0, 0x0, 0x0, 0x0} num_ctrls = 0 numads = 1182 #9 0x00000000004cecbb in overlay_op_walk (op=0x10641000, rs=0x7f610dab6a00, which=op_modify, oi=0x260c780, on=0x0) at backover.c:677 func = 0x7f8911361478 rc = 32768 #10 0x00000000004ceee8 in over_op_func (op=0x10641000, rs=0x7f610dab6a00, which=op_modify) at backover.c:730 oi = 0x260c780 on = 0x260c960 be = 0x25fc4e0 db = {bd_info = 0x7f8911361420, bd_self = 0x25fc4e0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x25c20c0, be_nsuffix = 0x25c2100, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x2588440 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x2588460 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x25f1880, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x2629980, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x2418680, be_pb = 0x0, be_cf_ocs = 0x7f8911361180, be_private = 0x297a000, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x70a84a8, sc_response = 0x4cdc92 <over_back_response>, sc_cleanup = 0, sc_writewait = 0, sc_private = 0x260c780} sc = 0x7f610dab56e0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #11 0x00000000004cf024 in over_op_modify (op=0x10641000, rs=0x7f610dab6a00) at backover.c:769 No locals. #12 0x000000000045b18e in fe_op_modify (op=0x10641000, rs=0x7f610dab6a00) at modify.c:303 update = 0 repl_user = 0 op_be = 0x25fc4e0 bd = 0x75a900 textbuf = "@\347\207\f\000\000\000\000\000&+\002\000\000\000\000\300W\253\ra\177\000\000)\034F", '\000' <repeats 13 times>"\200, V\330\017\000\000\000\000@\347\207\f\000\000\000\000\060f+\002\000\000\000\000\300\327e\004\000\000\000\000\002\000\000\000\000\000\000\000\000܇\017\000\000\000\000\300W\253\ra\177", '\000' <repeats 18 times>, "W\001\000\000\000\000\000\000\240\312\303\020", '\000' <repeats 12 times>, " \000\000\000\000\000\000\000\320W\253\ra\177\000\000\000\000\000\000\000\000\000\000`X\253\ra\177\000\000ܻE", '\000' <repeats 14 times>, "\001\000\000\000\000\000\000\220h\253\ra\177\000\000 j\253\ra\177", '\000' <repeats 11 times>, "\020d\020\000\000\000\000`X\253\ra\177\000\000\065yE\000\000\000\000\000\060X\253"... textlen = 256 #13 0x000000000045aa60 in do_modify (op=0x10641000, rs=0x7f610dab6a00) at modify.c:177 dn = {bv_len = 43, bv_val = 0xfaa2c49 "uid=george,ou=people,dc=xxxxxx,dc=co,dc=za"} textbuf = "\240h\253\ra\177\000\000\360\314\066\022\000\000\000\000pi\253\ra\177\000\000\260[\246\020\000\000\000\000\377\377\377\377\377\377\377\377l\315\311\000\000\000\000\000\a\000\000\000\000\000\000\000\354\006\360\025\211\177\000\000 i\253\ra\177\000\000Z\373\357\025\211\177\000\000\000\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\237\363\004\020\000\000\000\000Ю\300\020\000\000\000\000\200'f\004", '\000' <repeats 12 times>"\200, 'f\004\000\000\000\000xi\253\ra\177\000\000\063\345J\000\000\000\000\000\060k\253\ra\177\000\000\060k\253\ra\177\000\000\220\363\004\020\001\000\000\000\320i\253\ra\177\000\000\022\346J\000\000\000\000\000pi\253\r\001\000\000\000\060k\253\ra\177\000\000\000\000\000\000\001\000\000\000\000\000\020", '\000' <repeats 13 times>"\200, 'f\004\000\000\000\000\200'f\004\000\000\000\000"... textlen = 256 tmp = 0x0 #14 0x000000000043a89a in connection_operation (ctx=0x7f610dab6b30, arg_v=0x10641000) at connection.c:1135 rc = 80 cancel = 0 op = 0x10641000 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 102 opidx = SLAP_OP_MODIFY conn = 0x2a6e080 memctx = 0x4662780 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #15 0x000000000043ae3b in connection_read_thread (ctx=0x7f610dab6b30, argv=0xc6) at connection.c:1271 rc = 0 cri = {op = 0x10641000, func = 0, arg = 0x0, ctx = 0x7f610dab6b30, nullop = 0} s = 198 #16 0x00007f8916116552 in ldap_int_thread_pool_wrapper (xpool=0x20d0000) at tpool.c:956 pq = 0x20d0000 pool = 0x2294180 task = 0xc87e1c0 work_list = 0x20d0070 ctx = {ltu_pq = 0x20d0000, ltu_id = 140054817896192, ltu_key = {{ltk_key = 0x43a3eb, ltk_data = 0x261a900, ltk_free = 0x43a22f <conn_counter_destroy>}, { ltk_key = 0x4ae533, ltk_data = 0x4662780, ltk_free = 0x4ae358 <slap_sl_mem_destroy>}, {ltk_key = 0x229cd00, ltk_data = 0x71a8000, ltk_free = 0x7f891113c78b <mdb_reader_free>}, {ltk_key = 0x455939, ltk_data = 0x0, ltk_free = 0x45588c <slap_op_q_destroy>}, {ltk_key = 0x7f89111315b7, ltk_data = 0x74c2000, ltk_free = 0x7f8911131594 <search_stack_free>}, {ltk_key = 0x7f891112e071, ltk_data = 0x71c2000, ltk_free = 0x7f891112e029 <scope_chunk_free>}, {ltk_key = 0x229d400, ltk_data = 0x9856000, ltk_free = 0x7f891113c78b <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0xb1b6400, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 719 hash = 1836767951 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #17 0x00007f8914bfeaa1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #18 0x00007f891494b93d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 4 (Thread 0x7f610d2b6700 (LWP 21499)): #0 0x00007f8914c0268c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f8916117c2f in ldap_pvt_thread_cond_wait (cond=0x2722808, mutex=0x27227e0) at thr_posix.c:277 No locals. #2 0x00007f891611478a in ldap_pvt_thread_rmutex_lock (rmutex=0x2469b28, owner=140054809503488) at rmutex.c:129 rm = 0x27227e0 __PRETTY_FUNCTION__ = "ldap_pvt_thread_rmutex_lock" #3 0x00007f8910adafcf in accesslog_op_mod (op=0x11923c00, rs=0x7f610d2b5a00) at accesslog.c:1984 cb = 0xb3ce498 cb2 = 0x7f610d2b44e0 on = 0x260cd20 li = 0x2469ac0 lo = 0x7f8910cdfb70 logop = 2 doit = 1 #4 0x00000000004cec1d in overlay_op_walk (op=0x11923c00, rs=0x7f610d2b5a00, which=op_modify, oi=0x260c780, on=0x260cd20) at backover.c:661 func = 0x260cd78 rc = 32768 #5 0x00000000004ceee8 in over_op_func (op=0x11923c00, rs=0x7f610d2b5a00, which=op_modify) at backover.c:730 oi = 0x260c780 on = 0x260c960 be = 0x25fc4e0 db = {bd_info = 0x260cd20, bd_self = 0x25fc4e0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x25c20c0, be_nsuffix = 0x25c2100, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x2588440 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x2588460 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x25f1880, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x2629980, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x2418680, be_pb = 0x0, be_cf_ocs = 0x7f8911361180, be_private = 0x297a000, be_next = {stqe_next = 0x0}} cb = {sc_next = 0xb3ce498, sc_response = 0x4cdc92 <over_back_response>, sc_cleanup = 0, sc_writewait = 0, sc_private = 0x260c780} sc = 0x7f610d2b46e0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #6 0x00000000004cf024 in over_op_modify (op=0x11923c00, rs=0x7f610d2b5a00) at backover.c:769 No locals. #7 0x000000000045b18e in fe_op_modify (op=0x11923c00, rs=0x7f610d2b5a00) at modify.c:303 update = 0 repl_user = 0 op_be = 0x25fc4e0 bd = 0x75a900 textbuf = "\024\000\000\000\021\000\000\000\000)+\002\000\000\000\000\300G+\ra\177\000\000)\034F", '\000' <repeats 14 times>"\253, \067\020\000\000\000\000\000r\324\017\000\000\000\000\000v+\002\000\000\000\000\200\332e\004\000\000\000\000\002\000\000\000\000\000\000\000\000\255\207\017\000\000\000\000\300G+\ra\177", '\000' <repeats 18 times>, "\017\000\000\000\000\000\000\000\020\227\263\017", '\000' <repeats 12 times>, " \000\000\000\000\000\000\000\320G+\ra\177\000\000\000\000\000\000\000\000\000\000`H+\ra\177\000\000ܻE", '\000' <repeats 14 times>, "\001\000\000\000\000\000\000\220X+\ra\177\000\000 Z+\ra\177", '\000' <repeats 11 times>, "<\222\021\000\000\000\000`H+\ra\177\000\000\065"... textlen = 256 #8 0x000000000045aa60 in do_modify (op=0x11923c00, rs=0x7f610d2b5a00) at modify.c:177 dn = {bv_len = 37, bv_val = 0xf67be97 "uid=tsv,ou=people,dc=xxxxx,dc=co,dc=za"} textbuf = "\240X+\ra\177\000\000\020\261\205\017\000\000\000\000pY+\ra\177\000\000`\330\004\020\000\000\000\000\377\377\377\377\377\377\377\377K\316\311\000\000\000\000\000\004\000\000\000\000\000\000\000\354\006\360\025\211\177\000\000 Y+\ra\177\000\000Z\373\357\025\211\177\000\000\000\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000?\3 40\373\020\000\000\000\000\360\265\205\017\000\000\000\000\300\375\f\v", '\000' <repeats 12 times>"\300, \375\f\v\000\000\000\000xY+\ra\177\000\000\063\345J\000\000\000\000\000\060[+\ra\177\000\000\060[+\ra\177\000\000\060\340\373\020\000\000\000\000\320Y+\ra\177\000\000\022\346J\000\000\000\000\000pY+\r\001\000\000\000\060[+\ra\177\000\000\000\000\000\000\001\000\000\000\000\000\020", '\000' <repeats 13 times>"\300, \375\f\v\000\000\000\000\300\375\f"... textlen = 256 tmp = 0x0 #9 0x000000000043a89a in connection_operation (ctx=0x7f610d2b5b30, arg_v=0x11923c00) at connection.c:1135 rc = 80 cancel = 0 op = 0x11923c00 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 102 opidx = SLAP_OP_MODIFY conn = 0x2ab29c0 memctx = 0xb0cfdc0 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #10 0x000000000043ae3b in connection_read_thread (ctx=0x7f610d2b5b30, argv=0x255) at connection.c:1271 rc = 0 cri = {op = 0x11923c00, func = 0, arg = 0x0, ctx = 0x7f610d2b5b30, nullop = 0} s = 597 #11 0x00007f8916116552 in ldap_int_thread_pool_wrapper (xpool=0x20d0000) at tpool.c:956 pq = 0x20d0000 pool = 0x2294180 task = 0xfc81c00 work_list = 0x20d0070 ctx = {ltu_pq = 0x20d0000, ltu_id = 140054809503488, ltu_key = {{ltk_key = 0x4ae533, ltk_data = 0xb0cfdc0, ltk_free = 0x4ae358 <slap_sl_mem_destroy>}, { ltk_key = 0x43a3eb, ltk_data = 0x2619f00, ltk_free = 0x43a22f <conn_counter_destroy>}, {ltk_key = 0x229cd00, ltk_data = 0x4990200, ltk_free = 0x7f891113c78b <mdb_reader_free>}, {ltk_key = 0x455939, ltk_data = 0x11788800, ltk_free = 0x45588c <slap_op_q_destroy>}, {ltk_key = 0x7f89111315b7, ltk_data = 0xb7ce000, ltk_free = 0x7f8911131594 <search_stack_free>}, {ltk_key = 0x7f891112e071, ltk_data = 0xb4ce000, ltk_free = 0x7f891112e029 <scope_chunk_free>}, {ltk_key = 0x229d400, ltk_data = 0x985c800, ltk_free = 0x7f891113c78b <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x11d48800, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 831 hash = 3362479935 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #12 0x00007f8914bfeaa1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #13 0x00007f891494b93d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 3 (Thread 0x7f610cab5700 (LWP 22074)): #0 0x00007f8914c0268c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f8916117c2f in ldap_pvt_thread_cond_wait (cond=0x2722808, mutex=0x27227e0) at thr_posix.c:277 No locals. #2 0x00007f891611478a in ldap_pvt_thread_rmutex_lock (rmutex=0x2469b28, owner=140054801110784) at rmutex.c:129 rm = 0x27227e0 __PRETTY_FUNCTION__ = "ldap_pvt_thread_rmutex_lock" #3 0x00007f8910adafcf in accesslog_op_mod (op=0x1259b800, rs=0x7f610cab4a00) at accesslog.c:1984 cb = 0xc9384b0 cb2 = 0x7f610cab34e0 on = 0x260cd20 li = 0x2469ac0 lo = 0x7f8910cdfb70 logop = 2 doit = 1 #4 0x00000000004cec1d in overlay_op_walk (op=0x1259b800, rs=0x7f610cab4a00, which=op_modify, oi=0x260c780, on=0x260cd20) at backover.c:661 func = 0x260cd78 rc = 32768 #5 0x00000000004ceee8 in over_op_func (op=0x1259b800, rs=0x7f610cab4a00, which=op_modify) at backover.c:730 oi = 0x260c780 on = 0x260c960 be = 0x25fc4e0 db = {bd_info = 0x260cd20, bd_self = 0x25fc4e0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x25c20c0, be_nsuffix = 0x25c2100, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x2588440 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x2588460 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x25f1880, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x2629980, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x2418680, be_pb = 0x0, be_cf_ocs = 0x7f8911361180, be_private = 0x297a000, be_next = {stqe_next = 0x0}} cb = {sc_next = 0xc9384b0, sc_response = 0x4cdc92 <over_back_response>, sc_cleanup = 0, sc_writewait = 0, sc_private = 0x260c780} sc = 0x7f610cab36e0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #6 0x00000000004cf024 in over_op_modify (op=0x1259b800, rs=0x7f610cab4a00) at backover.c:769 No locals. #7 0x000000000045b18e in fe_op_modify (op=0x1259b800, rs=0x7f610cab4a00) at modify.c:303 update = 0 repl_user = 0 op_be = 0x25fc4e0 bd = 0x75a900 textbuf = "\024\000\000\000\021\000\000\000\000)+\002\000\000\000\000\300\067\253\fa\177\000\000)\034F", '\000' <repeats 13 times>, "`\226\210\f\000\000\000\000@\206\210\f\000\000\000\000\000v+\002\000\000\000\000\000\235B\002\000\000\000\000\002\000\000\000\000\000\000\000\200V\271\021\000\000\000\000\300\067\253\fa\177", '\000' <repeats 18 times>, "\017\000\000\000\000\000\000\000\200\302e\017", '\000' <repeats 12 times>, " \000\000\000\000\000\000\000\320\067\253\fa\177\000\000\000\000\000\000\000\000\000\000`8\253\fa\177\000\000ܻE", '\000' <repeats 14 times>, "\001\000\000\000\000\000\000\220H\253\fa\177\000\000 J\253\fa\177", '\000' <repeats 11 times>"\270, Y\022\000\000\000\000`8\253\fa\177\000\000\065yE\000\000\000\000\000"... textlen = 256 #8 0x000000000045aa60 in do_modify (op=0x1259b800, rs=0x7f610cab4a00) at modify.c:177 dn = {bv_len = 44, bv_val = 0x119b6997 "uid=20238247,ou=people,dc=xxxxxxxx,dc=co,dc=za"} textbuf = "\240H\253\fa\177\000\000\000\000\000\000\000\000\000\000pI\253\fa\177\000\000Ж\215\020\000\000\000\000\377\377\377\377\377\377\377\377{\310\311\000\000\000\000\000\020\000\000\000\000\000\000\000\354\006\360\025\211\177\000\000 I\253\fa\177\000\000Z\373\357\025\211\177\000\000\000\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000_(f\002\000\000\000\000`_\202\t\000\000\000\000\000\v%\v", '\000' <repeats 13 times>, "\v%\v\000\000\000\000xI\253\fa\177\000\000\063\345J\000\000\000\000\000\060K\253\fa\177\000\000\060K\253\fa\177\000\000P(f\002\001\000\000\000\320I\253\fa\177\000\000\022\346J\000\000\000\000\000pI\253\f\001\000\000\000\060K\253\fa\177\000\000\000\000\000\000\001\000\000\000\000\000\020", '\000' <repeats 14 times>, "\v%\v\000\000\000\000\000"... textlen = 256 tmp = 0x0 #9 0x000000000043a89a in connection_operation (ctx=0x7f610cab4b30, arg_v=0x1259b800) at connection.c:1135 rc = 80 cancel = 0 op = 0x1259b800 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 102 opidx = SLAP_OP_MODIFY conn = 0x2ab3a40 memctx = 0xb250b00 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #10 0x000000000043ae3b in connection_read_thread (ctx=0x7f610cab4b30, argv=0x25b) at connection.c:1271 rc = 0 cri = {op = 0x1259b800, func = 0, arg = 0x0, ctx = 0x7f610cab4b30, nullop = 0} s = 603 #11 0x00007f8916116552 in ldap_int_thread_pool_wrapper (xpool=0x20d0000) at tpool.c:956 pq = 0x20d0000 pool = 0x2294180 task = 0xfd01220 work_list = 0x20d0070 ctx = {ltu_pq = 0x20d0000, ltu_id = 140054801110784, ltu_key = {{ltk_key = 0x43a3eb, ltk_data = 0x261ab00, ltk_free = 0x43a22f <conn_counter_destroy>}, { ltk_key = 0x4ae533, ltk_data = 0xb250b00, ltk_free = 0x4ae358 <slap_sl_mem_destroy>}, {ltk_key = 0x455939, ltk_data = 0x0, ltk_free = 0x45588c <slap_op_q_destroy>}, {ltk_key = 0x229cd00, ltk_data = 0x985e200, ltk_free = 0x7f891113c78b <mdb_reader_free>}, {ltk_key = 0x7f89111315b7, ltk_data = 0xcd38000, ltk_free = 0x7f8911131594 <search_stack_free>}, {ltk_key = 0x7f891112e071, ltk_data = 0xca38000, ltk_free = 0x7f891112e029 <scope_chunk_free>}, {ltk_key = 0x229d400, ltk_data = 0x71ace00, ltk_free = 0x7f891113c78b <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x11d48800, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 430 hash = 3460370862 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #12 0x00007f8914bfeaa1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #13 0x00007f891494b93d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 2 (Thread 0x7f610c2b4700 (LWP 24941)): #0 0x00007f8914c0268c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f8916117c2f in ldap_pvt_thread_cond_wait (cond=0x2722808, mutex=0x27227e0) at thr_posix.c:277 No locals. #2 0x00007f891611478a in ldap_pvt_thread_rmutex_lock (rmutex=0x2469b28, owner=140054792718080) at rmutex.c:129 rm = 0x27227e0 __PRETTY_FUNCTION__ = "ldap_pvt_thread_rmutex_lock" #3 0x00007f8910adafcf in accesslog_op_mod (op=0x108d0400, rs=0x7f610c2b3a00) at accesslog.c:1984 cb = 0xe0a04b8 cb2 = 0x7f610c2b24e0 on = 0x260cd20 li = 0x2469ac0 lo = 0x7f8910cdfb70 logop = 2 doit = 1 #4 0x00000000004cec1d in overlay_op_walk (op=0x108d0400, rs=0x7f610c2b3a00, which=op_modify, oi=0x260c780, on=0x260cd20) at backover.c:661 func = 0x260cd78 rc = 32768 #5 0x00000000004ceee8 in over_op_func (op=0x108d0400, rs=0x7f610c2b3a00, which=op_modify) at backover.c:730 oi = 0x260c780 on = 0x260c960 be = 0x25fc4e0 db = {bd_info = 0x260cd20, bd_self = 0x25fc4e0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x25c20c0, be_nsuffix = 0x25c2100, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x2588440 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x2588460 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x25f1880, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x2629980, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x2418680, be_pb = 0x0, be_cf_ocs = 0x7f8911361180, be_private = 0x297a000, be_next = {stqe_next = 0x0}} cb = {sc_next = 0xe0a04b8, sc_response = 0x4cdc92 <over_back_response>, sc_cleanup = 0, sc_writewait = 0, sc_private = 0x260c780} sc = 0x7f610c2b26e0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #6 0x00000000004cf024 in over_op_modify (op=0x108d0400, rs=0x7f610c2b3a00) at backover.c:769 No locals. #7 0x000000000045b18e in fe_op_modify (op=0x108d0400, rs=0x7f610c2b3a00) at modify.c:303 update = 0 repl_user = 0 op_be = 0x25fc4e0 bd = 0x75a900 textbuf = "\024\000\000\000\021\000\000\000\000)+\002\000\000\000\000\300'+\fa\177\000\000)\034F", '\000' <repeats 13 times>, "`^U\020\000\000\000\000\340*-\020\000\000\000\000\000v+\002\000\000\000\000\000\235B\002\000\000\000\000\002\000\000\000\000\000\000\000@@\301\021\000\000\000\000\300'+\fa\177", '\000' <repeats 18 times>, "\017\000\000\000\000\000\000\000`1\016\021", '\000' <repeats 12 times>, " \000\000\000\000\000\000\000\320'+\fa\177\000\000\000\000\000\000\000\000\000\000`(+\fa\177\000\000ܻE", '\000' <repeats 14 times>, "\001\000\000\000\000\000\000\220\070+\fa\177\000\000 :+\fa\177", '\000' <repeats 11 times>, "\004\215\020\000\000\000\000`(+"... textlen = 256 #8 0x000000000045aa60 in do_modify (op=0x108d0400, rs=0x7f610c2b3a00) at modify.c:177 dn = {bv_len = 46, bv_val = 0x119b4f58 "uid=cwsa-account,ou=people,dc=xxxxxxx,dc=co,dc=za"} textbuf = "\240\070+\fa\177\000\000\000\000\000\000\000\000\000\000p9+\fa\177\000\000`}k\017\000\000\000\000\377\377\377\377\377\377\377\377\024p\257\000\000\000\000\000q\025\000\000\000\000\000\000\354\006\360\025\211\177\000\000 9+\fa\177\000\000Z\373\357\025\211\177\000\000\000\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\377\022\224\t\000\000\000\000\300\366\340\021\000\000\000\000\300\356\f\v", '\000' <repeats 12 times>"\300, \356\f\v\000\000\000\000x9+\fa\177\000\000\063\345J\000\000\000\000\000\060;+\ fa\177\000\000\060;+\fa\177\000\000\360\022\224\t\000\000\000\000\320\071+\fa\177\000\000\022\346J\000\000\000\000\000p9+\f\001\000\000\000\060;+\fa\177\000\000\000\000\000\000\001\000\000\000\000\000\020", '\000' <repeats 13 times>"\300, \356\f\v\000\000\000\000\300"... textlen = 256 tmp = 0x0 #9 0x000000000043a89a in connection_operation (ctx=0x7f610c2b3b30, arg_v=0x108d0400) at connection.c:1135 rc = 80 cancel = 0 op = 0x108d0400 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 102 opidx = SLAP_OP_MODIFY conn = 0x2a82240 memctx = 0xb0ceec0 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #10 0x000000000043ae3b in connection_read_thread (ctx=0x7f610c2b3b30, argv=0x13b) at connection.c:1271 rc = 0 cri = {op = 0x108d0400, func = 0, arg = 0x0, ctx = 0x7f610c2b3b30, nullop = 0} s = 315 #11 0x00007f8916116552 in ldap_int_thread_pool_wrapper (xpool=0x20d0000) at tpool.c:956 pq = 0x20d0000 pool = 0x2294180 task = 0x11a1c860 work_list = 0x20d0070 ctx = {ltu_pq = 0x20d0000, ltu_id = 140054792718080, ltu_key = {{ltk_key = 0x4ae533, ltk_data = 0xb0ceec0, ltk_free = 0x4ae358 <slap_sl_mem_destroy>}, { ltk_key = 0x43a3eb, ltk_data = 0x2619600, ltk_free = 0x43a22f <conn_counter_destroy>}, {ltk_key = 0x229cd00, ltk_data = 0xc90e000, ltk_free = 0x7f891113c78b <mdb_reader_free>}, {ltk_key = 0x7f89111315b7, ltk_data = 0xe4a0000, ltk_free = 0x7f8911131594 <search_stack_free>}, { ltk_key = 0x7f891112e071, ltk_data = 0xe1a0000, ltk_free = 0x7f891112e029 <scope_chunk_free>}, {ltk_key = 0x455939, ltk_data = 0x118aa800, ltk_free = 0x45588c <slap_op_q_destroy>}, {ltk_key = 0x229d400, ltk_data = 0xdfa1a00, ltk_free = 0x7f891113c78b <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0xfa21600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 542 hash = 691115550 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #12 0x00007f8914bfeaa1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #13 0x00007f891494b93d in clone () from /lib64/libc.so.6 No symbol table info available. Thread 1 (Thread 0x7f89167c5720 (LWP 18917)): #0 0x00007f8914bff2fd in pthread_join () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f8916117b70 in ldap_pvt_thread_join (thread=140054859859712, thread_return=0x0) at thr_posix.c:197 No locals. #2 0x000000000043785a in slapd_daemon () at daemon.c:2910 i = 0 rc = 0 #3 0x0000000000414c02 in main (argc=9, argv=0x7fffb8df91e8) at main.c:1017 i = 9 no_detach = 0 rc = 0 urls = 0x208e020 "ldap://0.0.0.0:389 ldapi:///" username = 0x2092018 "TRUE" groupname = 0x0 sandbox = 0x0 syslogUser = 128 pid = 0 waitfds = {9, 10} g_argc = 9 g_argv = 0x7fffb8df91e8 configfile = 0x0 configdir = 0x208e060 "/opt/zimbra/data/ldap/config" serverName = 0x7fffb8dfadeb "slapd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x4f2f08 "" l = 5188080 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = 0 __PRETTY_FUNCTION__ = "main" (gdb) Output from mdb_stat -eaf on the master shows significant fragmentation: [zimbra@ldap01-dc01 db]$ mdb_stat -eaf . Environment Info Map address: (nil) Map size: 85899345920 Page size: 4096 Max pages: 20971520 Number of pages used: 2739630 Last transaction ID: 139737905 Max readers: 126 Number of readers used: 9 Freelist Status Tree depth: 3 Branch pages: 18 Leaf pages: 3311 Overflow pages: 397 Entries: 78618 Free pages: 1504751 Status of Main DB Tree depth: 1 Branch pages: 0 Leaf pages: 1 Overflow pages: 0 Entries: 38 Status of DKIMIdentity Tree depth: 0 Branch pages: 0 Leaf pages: 0 Overflow pages: 0 Entries: 0 Status of DKIMSelector Tree depth: 0 Branch pages: 0 Leaf pages: 0 Overflow pages: 0 Entries: 0 Status of ad2i Tree depth: 2 Branch pages: 1 Leaf pages: 13 Overflow pages: 0 Entries: 1183 Status of cn Tree depth: 3 Branch pages: 159 Leaf pages: 35732 Overflow pages: 0 Entries: 13311385 Status of displayName Tree depth: 3 Branch pages: 131 Leaf pages: 24914 Overflow pages: 0 Entries: 9306285 Status of dn2i Tree depth: 4 Branch pages: 522 Leaf pages: 64580 Overflow pages: 0 Entries: 2727439 Status of entryCSN Tree depth: 4 Branch pages: 1421 Leaf pages: 19563 Overflow pages: 0 Entries: 1363719 Status of entryUUID Tree depth: 3 Branch pages: 65 Leaf pages: 11094 Overflow pages: 0 Entries: 1363719 Status of givenName Tree depth: 3 Branch pages: 9 Leaf pages: 2126 Overflow pages: 0 Entries: 601575 Status of id2e Tree depth: 4 Branch pages: 3955 Leaf pages: 500307 Overflow pages: 283335 Entries: 1363720 Status of mail Tree depth: 3 Branch pages: 137 Leaf pages: 33259 Overflow pages: 0 Entries: 14426766 Status of objectClass Tree depth: 2 Branch pages: 1 Leaf pages: 4 Overflow pages: 0 Entries: 278069 Status of sn Tree depth: 3 Branch pages: 129 Leaf pages: 25165 Overflow pages: 0 Entries: 9769145 Status of uid Tree depth: 3 Branch pages: 33 Leaf pages: 7109 Overflow pages: 0 Entries: 924205 Status of zimbraACE Tree depth: 3 Branch pages: 17 Leaf pages: 3519 Overflow pages: 0 Entries: 1334426 Status of zimbraAuthKerberos5Realm Tree depth: 0 Branch pages: 0 Leaf pages: 0 Overflow pages: 0 Entries: 0 Status of zimbraCalResBuilding Tree depth: 2 Branch pages: 1 Leaf pages: 4 Overflow pages: 0 Entries: 641 Status of zimbraCalResCapacity Tree depth: 1 Branch pages: 0 Leaf pages: 1 Overflow pages: 0 Entries: 27 Status of zimbraCalResFloor Tree depth: 2 Branch pages: 1 Leaf pages: 2 Overflow pages: 0 Entries: 363 Status of zimbraCalResRoom Tree depth: 1 Branch pages: 0 Leaf pages: 1 Overflow pages: 0 Entries: 178 Status of zimbraCalResSite Tree depth: 2 Branch pages: 1 Leaf pages: 4 Overflow pages: 0 Entries: 543 Status of zimbraDomainAliasTargetId Tree depth: 1 Branch pages: 0 Leaf pages: 1 Overflow pages: 0 Entries: 154 Status of zimbraDomainName Tree depth: 3 Branch pages: 9 Leaf pages: 2152 Overflow pages: 0 Entries: 643609 Status of zimbraForeignPrincipal Tree depth: 0 Branch pages: 0 Leaf pages: 0 Overflow pages: 0 Entries: 0 Status of zimbraId Tree depth: 3 Branch pages: 33 Leaf pages: 7968 Overflow pages: 0 Entries: 955084 Status of zimbraMailAlias Tree depth: 3 Branch pages: 65 Leaf pages: 13719 Overflow pages: 0 Entries: 4584536 Status of zimbraMailCatchAllAddress Tree depth: 3 Branch pages: 9 Leaf pages: 208 Overflow pages: 0 Entries: 16676 Status of zimbraMailDeliveryAddress Tree depth: 3 Branch pages: 130 Leaf pages: 26463 Overflow pages: 0 Entries: 11258680 Status of zimbraMailForwardingAddress Tree depth: 3 Branch pages: 3 Leaf pages: 370 Overflow pages: 0 Entries: 43649 Status of zimbraMailHost Tree depth: 2 Branch pages: 1 Leaf pages: 61 Overflow pages: 0 Entries: 659450 Status of zimbraMailTransport Tree depth: 2 Branch pages: 1 Leaf pages: 60 Overflow pages: 0 Entries: 655378 Status of zimbraMemberOf Tree depth: 0 Branch pages: 0 Leaf pages: 0 Overflow pages: 0 Entries: 0 Status of zimbraShareInfo Tree depth: 0 Branch pages: 0 Leaf pages: 0 Overflow pages: 0 Entries: 0 Status of zimbraSharedItem Tree depth: 3 Branch pages: 69 Leaf pages: 16765 Overflow pages: 0 Entries: 10835821 Status of zimbraUCServiceId Tree depth: 0 Branch pages: 0 Leaf pages: 0 Overflow pages: 0 Entries: 0 Status of zimbraVirtualHostname Tree depth: 2 Branch pages: 1 Leaf pages: 4 Overflow pages: 0 Entries: 28593 Status of zimbraVirtualIPAddress Tree depth: 0 Branch pages: 0 Leaf pages: 0 Overflow pages: 0 Entries: 0 Status of zimbraYahooId Tree depth: 0 Branch pages: 0 Leaf pages: 0 Overflow pages: 0 Entries: 0 [zimbra@ldap01-dc01 db]$ cd ../../accesslog/db/ [zimbra@ldap01-dc01 db]$ mdb_stat -eaf . Environment Info Map address: (nil) Map size: 85899345920 Page size: 4096 Max pages: 20971520 Number of pages used: 481574 Last transaction ID: 56766713 Max readers: 126 Number of readers used: 10 Freelist Status Tree depth: 3 Branch pages: 7 Leaf pages: 765 Overflow pages: 0 Entries: 9940 Free pages: 307284 Status of Main DB Tree depth: 1 Branch pages: 0 Leaf pages: 1 Overflow pages: 0 Entries: 8 Status of ad2i Tree depth: 1 Branch pages: 0 Leaf pages: 1 Overflow pages: 0 Entries: 22 Status of dn2i Tree depth: 3 Branch pages: 57 Leaf pages: 12272 Overflow pages: 0 Entries: 1079831 Status of entryCSN Tree depth: 3 Branch pages: 11 Leaf pages: 1988 Overflow pages: 0 Entries: 539915 Status of id2e Tree depth: 4 Branch pages: 623 Leaf pages: 139166 Overflow pages: 2174 Entries: 539915 Status of objectClass Tree depth: 1 Branch pages: 0 Leaf pages: 1 Overflow pages: 0 Entries: 10887 Status of reqEnd Tree depth: 3 Branch pages: 11 Leaf pages: 1987 Overflow pages: 0 Entries: 539914 Status of reqResult Tree depth: 1 Branch pages: 0 Leaf pages: 1 Overflow pages: 0 Entries: 3 Status of reqStart Tree depth: 3 Branch pages: 11 Leaf pages: 1991 Overflow pages: 0 Entries: 539914 [zimbra@ldap01-dc01 db]$

1 0

(ITS#8663) slapo-memberof cannot replace "olcMemberOfRefInt"
by quanah＠openldap.org 31 May '17

31 May '17

Full_Name: Quanah Gibson-Mount Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) While you can set olcMemberOfRefInt during an add operation when instantiating slapo-memberOf with cn=config, you cannot modify the value after that point. Attempting to change the value results in: Running ldapmodify to change olcMemberOfRefInt value ldapmodify failed (80)! slapd log shows: 592ef748 <<< dnPrettyNormal: <olcOverlay={0}memberof,olcDatabase={1}bdb,cn=config>, <olcOverlay={0}memberof,olcDatabase={1}bdb,cn=config> 592ef748 conn=1003 op=1 modifications: 592ef748 replace: olcMemberOfRefInt 592ef748 one value, length 5 592ef748 conn=1003 op=1 MOD dn="olcOverlay={0}memberof,olcDatabase={1}bdb,cn=config" 592ef748 conn=1003 op=1 MOD attr=olcMemberOfRefInt 592ef748 slap_queue_csn: queueing 0x7f326010add0 20170531170304.816445Z#000000#000#000000 592ef748 oc_check_required entry (olcOverlay={0}memberof,olcDatabase={1}bdb,cn=config), objectClass "olcMemberOf" 592ef748 oc_check_allowed type "objectClass" 592ef748 oc_check_allowed type "olcOverlay" 592ef748 oc_check_allowed type "olcMemberOfGroupOC" 592ef748 oc_check_allowed type "olcMemberOfMemberAD" 592ef748 oc_check_allowed type "olcMemberOfMemberOfAD" 592ef748 oc_check_allowed type "structuralObjectClass" 592ef748 oc_check_allowed type "entryUUID" 592ef748 oc_check_allowed type "creatorsName" 592ef748 oc_check_allowed type "createTimestamp" 592ef748 oc_check_allowed type "olcMemberOfRefInt" 592ef748 oc_check_allowed type "entryCSN" 592ef748 oc_check_allowed type "modifiersName" 592ef748 oc_check_allowed type "modifyTimestamp" 592ef748 send_ldap_result: conn=1003 op=1 p=3 592ef748 send_ldap_result: err=80 matched="" text="" 592ef748 send_ldap_response: msgid=2 tag=103 err=80 ber_flush2: 14 bytes to sd 8 592ef748 conn=1003 op=1 RESULT tag=103 err=80 qtime=0.000020 etime=0.816572 text= 592ef748 slap_graduate_commit_csn: removing 0x7f326010add0 20170531170304.816445Z#000000#000#000000 592ef748 connection_get(8)

1 0

Re: (ITS#8590) LMDB: Suppress SIGPIPE in mdb_env_copythr on OS X
by lmb＠cloudflare.com 31 May '17

31 May '17

I've created a test program, available at [1], which will hopefully help verify this patch. 1: https://gist.github.com/lmb/a35e7b9566fa79e7bf971ac21bbb9efb#file-0002-add-… Best, Lorenz

1 0

Re: (ITS#8662) Update mdb_load to safely load back-mdb databases
by hyc＠symas.com 25 May '17

25 May '17

gnoe(a)symas.com wrote: > Full_Name: Gregory Noe > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.142.209.94) > > > Update mdb_load to safely load back-mdb databases. Currently back-mdb's custom > sort functions don't order database items in the correct order. Actually no, this ITS is about tweaking back-mdb to give mdb_load a better hint about what ordering to use. In particular, the id2v table in master/RE25 isn't being reloaded in proper order at the moment. -- -- 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

(ITS#8662) Update mdb_load to safely load back-mdb databases
by gnoe＠symas.com 25 May '17

25 May '17

Full_Name: Gregory Noe Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.142.209.94) Update mdb_load to safely load back-mdb databases. Currently back-mdb's custom sort functions don't order database items in the correct order.

1 0

(ITS#8661) Fix warnings issued by Autoconf 2.68+
by okuznik＠symas.com 24 May '17

24 May '17

Full_Name: Ondrej Kuznik Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170524-Fix-warnings-issued-… Submission from: (NULL) (2a02:c7f:2247:ec00:a3e:8eff:fe52:dac5) Running aclocal/autoconf is quite noisy. The attached patch against master follows the recommendations by the autoconf project https://autotools.io/forwardporting/autoconf.html

1 0

Re: (ITS#8660) slapd segmentation faults (relay backend and rwm overlay)
by quanah＠symas.com 24 May '17

24 May '17

--On Wednesday, May 24, 2017 3:14 PM +0000 nespor(a)id.ethz.ch wrote: > I am not quite sure, if it is really the same problem. I do not use the > Red Hat openldap package. > I have downloaded openldap-2.4.44.tgz on January 5, 2017, and compiled > myself. Yes, it was fixed in May of 2016 (2.4.44 was released February of 2016). So it is already fixed for the next release (2.4.45). 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#8660) slapd segmentation faults (relay backend and rwm overlay)
by nespor＠id.ethz.ch 24 May '17

24 May '17

I am not quite sure, if it is really the same problem. I do not use the Red Hat openldap package. I have downloaded openldap-2.4.44.tgz on January 5, 2017, and compiled myself. On 05/24/17 15:48, Howard Chu wrote: > Howard Chu wrote: >> nespor(a)id.ethz.ch wrote: >>> Full_Name: Vlado Nespor >>> Version: 2.4.44 >>> OS: Red Hat el7 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (2001:67c:10ec:32d0::222) >>> >>> >>> We have experienced random slapd segmentation faults, when the relay >>> backend and rwm overlay were used in the configuration. After some >>> time I could reproduce the segmentation fault on a slow client and >>> with test queries, which were supposed to return a larger set of >>> entries. >>> >>> I could trace the problem to a wrong pointer in the slap_writewait_play >>> function in the openldap-2.4.44/servers/slapd/result.c file, and then >>> further to the openldap-2.4.44/servers/slapd/back-relay/op.c file. >>> After >>> the addition of the sc_writewait pointer initialisation (see the patch >>> below), the test queries returned correct results and random slapd >>> segmentation faults disappeared. >> >> Thanks for the report, but this was already fixed in ITS#8218 >> released in >> 2.4.43. Sounds like Red Hat has botched their source code since the >> official >> fix has been out for nearly 2 years already. > > Sorry, a typo on my part. It was ITS#8428. >

1 0

Re: (ITS#8660) slapd segmentation faults (relay backend and rwm overlay)
by hyc＠symas.com 24 May '17

24 May '17

Howard Chu wrote: > nespor(a)id.ethz.ch wrote: >> Full_Name: Vlado Nespor >> Version: 2.4.44 >> OS: Red Hat el7 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:67c:10ec:32d0::222) >> >> >> We have experienced random slapd segmentation faults, when the relay >> backend and rwm overlay were used in the configuration. After some >> time I could reproduce the segmentation fault on a slow client and >> with test queries, which were supposed to return a larger set of entries. >> >> I could trace the problem to a wrong pointer in the slap_writewait_play >> function in the openldap-2.4.44/servers/slapd/result.c file, and then >> further to the openldap-2.4.44/servers/slapd/back-relay/op.c file. After >> the addition of the sc_writewait pointer initialisation (see the patch >> below), the test queries returned correct results and random slapd >> segmentation faults disappeared. > > Thanks for the report, but this was already fixed in ITS#8218 released in > 2.4.43. Sounds like Red Hat has botched their source code since the official > fix has been out for nearly 2 years already. Sorry, a typo on my part. It was ITS#8428. -- -- 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#8660) slapd segmentation faults (relay backend and rwm overlay)
by hyc＠symas.com 24 May '17

24 May '17

nespor(a)id.ethz.ch wrote: > Full_Name: Vlado Nespor > Version: 2.4.44 > OS: Red Hat el7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:67c:10ec:32d0::222) > > > We have experienced random slapd segmentation faults, when the relay > backend and rwm overlay were used in the configuration. After some > time I could reproduce the segmentation fault on a slow client and > with test queries, which were supposed to return a larger set of entries. > > I could trace the problem to a wrong pointer in the slap_writewait_play > function in the openldap-2.4.44/servers/slapd/result.c file, and then > further to the openldap-2.4.44/servers/slapd/back-relay/op.c file. After > the addition of the sc_writewait pointer initialisation (see the patch > below), the test queries returned correct results and random slapd > segmentation faults disappeared. Thanks for the report, but this was already fixed in ITS#8218 released in 2.4.43. Sounds like Red Hat has botched their source code since the official fix has been out for nearly 2 years already. > > With best regards, > > Vlado Nespor > > > diff -rupN openldap-2.4.44/servers/slapd/back-relay/op.c > openldap-2.4.44_back-relay/servers/slapd/back-relay/op.c > --- openldap-2.4.44/servers/slapd/back-relay/op.c 2016-02-06 00:57:45.000000000 > +0100 > +++ openldap-2.4.44_back-relay/servers/slapd/back-relay/op.c 2017-02-07 > 15:09:55.046188340 +0100 > @@ -97,6 +97,7 @@ relay_back_response_cb( Operation *op, S > (rcb)->rcb_sc.sc_next = (op)->o_callback; \ > (rcb)->rcb_sc.sc_response = relay_back_response_cb; \ > (rcb)->rcb_sc.sc_cleanup = 0; \ > + (rcb)->rcb_sc.sc_writewait = 0; \ > (rcb)->rcb_sc.sc_private = (op)->o_bd; \ > (op)->o_callback = (slap_callback *) (rcb); \ > } > > > -- -- 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

(ITS#8660) slapd segmentation faults (relay backend and rwm overlay)
by nespor＠id.ethz.ch 24 May '17

24 May '17

Full_Name: Vlado Nespor Version: 2.4.44 OS: Red Hat el7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:67c:10ec:32d0::222) We have experienced random slapd segmentation faults, when the relay backend and rwm overlay were used in the configuration. After some time I could reproduce the segmentation fault on a slow client and with test queries, which were supposed to return a larger set of entries. I could trace the problem to a wrong pointer in the slap_writewait_play function in the openldap-2.4.44/servers/slapd/result.c file, and then further to the openldap-2.4.44/servers/slapd/back-relay/op.c file. After the addition of the sc_writewait pointer initialisation (see the patch below), the test queries returned correct results and random slapd segmentation faults disappeared. With best regards, Vlado Nespor diff -rupN openldap-2.4.44/servers/slapd/back-relay/op.c openldap-2.4.44_back-relay/servers/slapd/back-relay/op.c --- openldap-2.4.44/servers/slapd/back-relay/op.c 2016-02-06 00:57:45.000000000 +0100 +++ openldap-2.4.44_back-relay/servers/slapd/back-relay/op.c 2017-02-07 15:09:55.046188340 +0100 @@ -97,6 +97,7 @@ relay_back_response_cb( Operation *op, S (rcb)->rcb_sc.sc_next = (op)->o_callback; \ (rcb)->rcb_sc.sc_response = relay_back_response_cb; \ (rcb)->rcb_sc.sc_cleanup = 0; \ + (rcb)->rcb_sc.sc_writewait = 0; \ (rcb)->rcb_sc.sc_private = (op)->o_bd; \ (op)->o_callback = (slap_callback *) (rcb); \ }

1 0

ITS#8655 published: SECURITY: Segfault by ldapsearch with pagesize=0
by openldap-its＠OpenLDAP.org 22 May '17

22 May '17

Private ITS#8655 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=8655

1 0

Re: (ITS#8659) accesslog man page updates
by michael＠stroeder.com 18 May '17

18 May '17

quanah(a)symas.com wrote: > Seems like it would have been better to leave audit* attrs with slapo-auditlog I was not aware of a specific schema for slapo-auditlog (except attribute type 'olcAuditlogFile' for back-config). Ciao, Michael.

1 0

Re: (ITS#8659) accesslog man page updates
by quanah＠symas.com 18 May '17

18 May '17

--On Thursday, May 18, 2017 6:10 PM +0200 Michael Str=C3=B6der=20 <michael(a)stroeder.com> wrote: > quanah(a)symas.com wrote: >> --On Thursday, May 18, 2017 9:23 AM +0000 elecharny(a)apache.org wrote: >>> There are some differences between the current slapo-accesslog man = page, >>> and the code base : >>> >>> - the auditObject ObjectClass is missing the reqEntryUUID AT >>> - the auditContainer ObjectClass is not described in the man page >>> - the auditModRDN ObjectClass is missing the reqMod AT >> >> I think you mean slapo-auditlog, not slapo-accesslog? > > No, Emmanuel is definitely referring to slapo-accesslog. Yeah, saw that when I grepped the code. Seems like it would have been=20 better to leave audit* attrs with slapo-auditlog and use something else for = accesslog. Oh well. --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#8659) accesslog man page updates
by michael＠stroeder.com 18 May '17

18 May '17

This is a cryptographically signed message in MIME format. --------------ms020708080809040305030308 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable quanah(a)symas.com wrote: > --On Thursday, May 18, 2017 9:23 AM +0000 elecharny(a)apache.org wrote: >> There are some differences between the current slapo-accesslog man pag= e, >> and the code base : >> >> - the auditObject ObjectClass is missing the reqEntryUUID AT >> - the auditContainer ObjectClass is not described in the man page >> - the auditModRDN ObjectClass is missing the reqMod AT >=20 > I think you mean slapo-auditlog, not slapo-accesslog? No, Emmanuel is definitely referring to slapo-accesslog. Ciao, Michael. --------------ms020708080809040305030308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CucwggT9MIID5aADAgECAhBFRleVrRF8X5GwbV0tcLCgMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwOTE2MDcxNjUxWhcNMTkxMjE2MDcxNjUxWjBEMR0wGwYDVQQDDBRtaWNo YWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChMBt5jtuLXsNQ5U7rBbZit8sknIwz hfaousT3d/fssQ6qZwe9l1yklILSXVMqI7/bxbiqcd3zrz+imdSlZPrFBHGfh04DZHCfss2F RwSswGejqP1qE3hPvZi96wFfOMqenpN+pSXqNJ1OPBCJ8a+8ZEioFKoEj3HkCCXjbmezAgms FuA7aFE9BfjJ2eQKw8B9G8X1FjvOTinYSZ2F+qHpKgywl4HTx0dMnYy+Pwu4DDIHkEaVH+uj K1/ed76WUEH51mX9m2Xu0onfQlSM3me6EvAAZiIDsCEbF9WttRuJbpfCFo0m2uW7BBugS7EG Jro1nRSQVnpJyTFgHb5EGMVVAgMBAAGjggG4MIIBtDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFFh1801TSuxT Nltnv9rOjrZzUUgNMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUF BwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUF BzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3Js MB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMCMGA1UdEgQcMBqGGGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tLzBHBgNVHSAEQDA+MDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUH AgEWH2h0dHBzOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEB AKiJ9wpjJeHdEzHDZyqmhn4cHcRj9Ag7ZQK0meq1N3oQ9M1YeVge6vZe20LXojgXsNUQGLSt 1lW2s7fABkL9CF+/RtWznHxlp4YpWX/RgbHBo3uXKNA5JUOjbxQ2+1b1jaTp/FUrSIISAxgd RpeYAODJ0db1x8Q+l66DtIVjj7ktWISdJWE2Opn4QnaRwdj6n35Rul4S2ikUsmxtGrHLpjRR XJqbsGa0RZdJyUKlZ2ZRAoRz4jKHOogQcig937sR5Ut2pGOhrScEhgARY2c8Gs2olRTL3pue mE4vjY0g1Nwr9RzeFwMuasiFh4yD34i6jIRfoNzuLPgydjsJ0grw0akwggXiMIIDyqADAgEC AhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17Ake fMyUGwrQdvwObhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzL A84J6Ws5T4NfXZ0qn4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmC S+kICslYYWgXOMt2xlsSslxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6my Su8j8BWWHpChNNeTrFuhVfrOAyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR 9t4APXGzAgMBAAGjggFkMIIBYDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0 cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDAGCCsGAQUFBzAChiRodHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0OBBYEFCSBbDlhvkkPj7cbRivJKLUn SG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMD8GA1UdIAQ4MDYwNAYEVR0g ADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZI hvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh2NCXTq7im61g7F1L IiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw5kG3DN8pd1hS EUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07v29MdhaP v3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Yklue /quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6 UpVDo/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHM zcwk3EV2B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuK KwHNL8F4GGp6jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ 8j6y6S9p0xE/Ga0peVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMYIDzDCCA8gCAQEwgYkw dTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAx IENsaWVudCBDQQIQRUZXla0RfF+RsG1dLXCwoDANBglghkgBZQMEAgEFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNTE4MTUxMDMzWjAvBgkq hkiG9w0BCQQxIgQg9jM2o7OgykNVN+x7Wk7o6yyHAhqM5i1ZlIObhnQ+uW0wbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYB BAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3Rh cnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwgZwGCyqGSIb3DQEJ EAILMYGMoIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD b20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwDQYJKoZIhvcNAQEBBQAE ggEAXwPJpYHRfcEVgXI6x6aKh5jcpnMv0hE15VTB9wYpvde8y1NXjbC8RrP0K607UXPe/zEO eg1KbsULDOmxc+/nL1G/mWYQpt9ye+PElCXrBDFPjXKp2rbTI7UD9JlZ0ZoiENvQTW2KO2GD LwaQuHvQ1I47M19t7Xw9eHktIhOlpe/AUC4fWPJf5Wpd5fjNePOiLYAex/dZvzjJmtyIRQBl JxiAQofcwDks9GqXbJpl20mWAO3Zz/uWaIKmDZJkzxacl5VF7UBgIAlmBy+bIVnMp4+Rm4e2 SuVkF8cnmArDYDTxagHp48QfcxHOu2wz/MhqEuzqPHOCVZ9XTzFgEOgIaAAAAAAAAA== --------------ms020708080809040305030308--

1 0

Re: (ITS#8659) accesslog man page updates
by quanah＠symas.com 18 May '17

18 May '17

--On Thursday, May 18, 2017 9:23 AM +0000 elecharny(a)apache.org wrote: > Full_Name: Emmanuel Lecharny > Version: 2.4.45 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.202.2.198) > > > There are some differences between the current slapo-accesslog man page, > and the code base : > > - the auditObject ObjectClass is missing the reqEntryUUID AT > - the auditContainer ObjectClass is not described in the man page > - the auditModRDN ObjectClass is missing the reqMod AT I think you mean slapo-auditlog, not slapo-accesslog? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8659) accesslog man page updates
by elecharny＠apache.org 18 May '17

18 May '17

Full_Name: Emmanuel Lecharny Version: 2.4.45 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.202.2.198) There are some differences between the current slapo-accesslog man page, and the code base : - the auditObject ObjectClass is missing the reqEntryUUID AT - the auditContainer ObjectClass is not described in the man page - the auditModRDN ObjectClass is missing the reqMod AT

1 0

Re: (ITS#8658) Can't change olcTLSCipherSuite
by ryan＠nardis.ca 17 May '17

17 May '17

Hello Oleg, The Ubuntu package uses GnuTLS and therefore your olcTLSCipherSuite setting needs to contain a valid GnuTLS priority string. https://gnutls.org/manual/html_node/Priority-Strings.html The slapd crash you are seeing is an Ubuntu-specific bug and has been fixed in later versions. https://bugs.launchpad.net/bugs/1103353 If you configure a valid GnuTLS priority string, it will not crash. In future please report issues with distro packages to the distro's bug tracker (in this case Launchpad); we can always forward them here if appropriate. This ITS will be closed.

1 0

Re: (ITS#8658) Can't change olcTLSCipherSuite
by quanah＠symas.com 17 May '17

17 May '17

--On Wednesday, May 17, 2017 9:24 AM +0000 slonvpalto(a)gmail.com wrote: > Full_Name: Oleg Pekar > Version: 2.4.31 Please use a current release of OpenLDAP. 2.4.31 is over 5 years old and hundreds of bugs with cn=config have been fixed since then. If you can reproduce the issue with a current release, then follow up at that time. In the meantime, this ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8658) Can't change olcTLSCipherSuite
by slonvpalto＠gmail.com 17 May '17

17 May '17

Full_Name: Oleg Pekar Version: 2.4.31 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:420:4482:1252:a136:e35f:4494:428b) When I try to change olcTLSCipherSuite in LDAP configuration I get the following error: root@LDAP-server:/oleg# ldapmodify -Y EXTERNAL -H ldapi:/// -d 1 -f cipher ldap_url_parse_ext(ldapi:///) ldap_create ldap_url_parse_ext(ldapi:///??base) ldap_sasl_interactive_bind: user selected: EXTERNAL ldap_int_sasl_bind: EXTERNAL ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_path ldap_new_socket: 4 ldap_connect_to_path: Trying /var/run/slapd/ldapi ldap_connect_timeout: fd: 4 tm: -1 async: 0 ldap_ndelay_on: 4 ldap_close_socket: 4 ldap_msgfree ldap_err2string ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) File "cipher" used for update in the command above: dn: cn=config changetype: modify replace: olcTLSCipherSuite olcTLSCipherSuite: AES128-SHA The server is indicated as running: root@LDAP-server:/oleg# service slapd status * slapd is running Therefore I cannot change the cipher that is used by secure LDAP. Thanks Oleg

1 0

Re: (ITS#8654) Option for LDAP client to bind to a local address.
by quanah＠symas.com 16 May '17

16 May '17

--On Tuesday, May 16, 2017 1:53 AM +0000 daniel.le(a)exfo.com wrote: As noted in my reply on -technical, you need to subscribe to the openldap-devel list, and have this discussion there, before starting work. Thanks! --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#8654) Option for LDAP client to bind to a local address.
by michael＠stroeder.com 16 May '17

16 May '17

daniel.le(a)exfo.com wrote: > I am not sure what "a list of space-separated addresses" exactly means. Per= > haps one IPv4 IP address and one IPv6 address if both are available. My use= > case is either a local IPv4 or IPv6 address. Hmm, a dual-stack machine is the most likely use-case. This also raises the question of the IP address list os ordered and the caller can therefore give a preference for IPv4 or IPv6 (e.g. like postfix is doing it for out-going SMTP conns). Ciao, Michael.

1 0

Re: (ITS#8654) Option for LDAP client to bind to a local address.
by daniel.le＠exfo.com 16 May '17

16 May '17

--_000_BC204A77E2E9CD4A85A8F600C7F0BA848C0F4476SPQCMBX01exfoco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For reference: https://msdn.microsoft.com/en-us/library/aa367019(v=3Dvs.85).aspx LDAP_OPT_SOCKET_BIND_ADDRESSES 0x44 Sets or retrieves a pointer to a TCHAR string containing a list of space-se= parated addresses to be used by socket bind. For a multihomed machine, use = this option to set a particular network interface address to be used for so= cket bind. Socket bind will be performed before socket connect for the serv= er address. See socket bind for more details. You should provide both IPv4 and IPv6 local addresses, if available, becaus= e both IPv4 and IPv6 server addresses can be used for socket connect. Socke= t bind will fail if there is an address family mismatch. On the Domain Cont= roller, for the default Server (HostName=3DNULL), loopback addresses will b= e used for socket connect. Set loopback addresses (for both IPv4 and IPv6) = for this option to work. This option can only be set before a connection is established. That is, ju= st after ldap_init. ------------------------------- I am not sure what "a list of space-separated addresses" exactly means. Per= haps one IPv4 IP address and one IPv6 address if both are available. My use= case is either a local IPv4 or IPv6 address. Daniel --_000_BC204A77E2E9CD4A85A8F600C7F0BA848C0F4476SPQCMBX01exfoco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> For reference:<o:p></o:p> https://msdn.microsoft.com/en-us/library/aa367019(v= =3Dvs.85).aspx<o:p></o:p> <o:p> </o:p> LDAP_OPT_SOCKET_BIND_ADDRESSES<o:p></o:p> 0x44<o:p></o:p> <o:p> </o:p> Sets or retrieves a pointer to a TCHAR string contai= ning a list of space-separated addresses to be used by socket bind. For a m= ultihomed machine, use this option to set a particular network interface ad= dress to be used for socket bind. Socket bind will be performed before socket connect for the server address= . See socket bind for more details.<o:p></o:p> <o:p> </o:p> You should provide both IPv4 and IPv6 local addresse= s, if available, because both IPv4 and IPv6 server addresses can be used fo= r socket connect. Socket bind will fail if there is an address family misma= tch. On the Domain Controller, for the default Server (HostName=3DNULL), loopback addresses will be used for = socket connect. Set loopback addresses (for both IPv4 and IPv6) for this op= tion to work.<o:p></o:p> <o:p> </o:p> This option can only be set before a connection is e= stablished. That is, just after ldap_init.<o:p></o:p> <o:p> </o:p> -------------------------------<o:p></o:p> I am not sure what "a list of space-separated a= ddresses" exactly means. Perhaps one IPv4 IP address and one IPv6 addr= ess if both are available. My use case is either a local IPv4 or IPv6 addre= ss.<o:p></o:p> <o:p> </o:p> Daniel<o:p></o:p> </div> </body> </html> --_000_BC204A77E2E9CD4A85A8F600C7F0BA848C0F4476SPQCMBX01exfoco_--

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 16 May '17

16 May '17

> From: Quanah Gibson-Mount > Sent: Thursday, April 20, 2017 1:26 PM > > It's fine for there to be legacy entryCSNs and a contextCSN for serverID of > 0. However, it is not fine for any master in an MMR setup to have a > specific serverID of 0. If you're running with serverID's 0-3, I'd simply > try an ldapmodify on the server with 0 to set its serverID to 4, and then > do a modification against it, so it generates a new contextCSN that gets > pushed out to all nodes. I went ahead and updated the serverID from 0 to 4 when I dropped in the patched binary, it seems to have gone smoothly. I'm planning to migrate the memberOf configuration over the summer to the dynamic list implementation, which is going to require a dump to ldif and reload, I'll go ahead and strip out the legacy serverid 0 contextCSN's then. Thanks.

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 16 May '17

16 May '17

> From: Ond=C5=99ej Kuzn=C3=ADk > Sent: Thursday, April 20, 2017 1:34 AM >=20 > Would you be able to try the patch I provided earlier on one of your > servers? Sorry for the long delay on this. I had built an updated binary with the = patch, but was waiting for the server to crash to drop it in. As luck = would have it, it went almost a month without crashing 8-/. It crashed = yesterday though, so it is now running with the patch = (Ondrej-Kuznik-20170327-ITS8609-ignore-invalid-accesslog-ops.patch), = although it might take some time to see if it makes any difference. Or = it might crash again tomorrow. <sigh>. Thanks much=E2=80=A6

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs