openldap-bugs

openldap-bugs@openldap.org

20960 discussions

(ITS#8674) Leak in ldap_create_assertion_control
by matt.johnson＠hpe.com 15 Jun '17

15 Jun '17

Full_Name: Matt Johnson Version: 2.4.40 OS: RedHat 7.2 (Maipo) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (15.203.233.86) The LDAPClient::modify logic has a leak within the ldap_create_assertion_control method. The leaky code occurs when the existing ld_errno is anything but 0 when the method is invoked. Not only that, but your assertion returned is NULL. The workaround is to call the following before calling ldap_create_assertion_control. int lvErrno = 0; ldap_set_option(myLDAPPtr, LDAP_OPT_RESULT_CODE, &lvErrno);

1 0

Re: (ITS#8672) syncrepl with openldap 2.4.{40,42} and mdb backend
by remy.dernat＠univ-montp2.fr 12 Jun '17

12 Jun '17

Hi Ryan, Quanah, Le 11/06/2017 à 03:57, Ryan Tandy a écrit : > On Thu, Jun 08, 2017 at 01:06:21PM +0000, remy.dernat(a)umontpellier.fr > wrote: >> I am able to reproduce the bug quite easily. > > I'm afraid I have not been able to. I followed the steps you posted > (with s/hdb/mdb/) with both servers running slapd 2.4.40+dfsg-1+deb8u3 > and syncrepl seems to work fine. > > https://bugs.debian.org/798964 seems quite similar. R�my, do you think > this problem started for you right after you upgraded to +deb8u3? Indeed, I am afraid that this upgrade causes this issue, or maybe rather the previous one. `2.4.40+dfsg-1+deb8u2` were upgraded on my system in February and syncrepl does not work from this moment. Concerning tests from the latest source, I am not able to reproduce this bug as I get a weird error, with some stuff remaining from my previous install: ``` LDAP vendor version mismatch: library 20440, header 20445 ``` Google leads me to this topics : https://bbs.archlinux.org/viewtopic.php?id=56872 http://www.openldap.org/lists/openldap-software/200307/msg00399.html Although I removed every previous packages. Using ldd : ``` ldd `which ldapadd` linux-vdso.so.1 (0x00007ffe19765000) libldap-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap-2.4.so.2 (0x00007fef25b0d000) liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007fef258fe000) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007fef256e1000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fef254aa000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fef25293000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fef24ee7000) libgnutls-deb0.so.28 => /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28 (0x00007fef24bc7000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fef249aa000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fef247a5000) /lib64/ld-linux-x86-64.so.2 (0x000055776c6be000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fef2458a000) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007fef24344000) libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007fef2412f000) libnettle.so.4 => /usr/lib/x86_64-linux-gnu/libnettle.so.4 (0x00007fef23efd000) libhogweed.so.2 => /usr/lib/x86_64-linux-gnu/libhogweed.so.2 (0x00007fef23cce000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fef23a4a000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fef23842000) ``` with strace : http://paste.debian.net/971168/ And no result with: ``` for file in `ldd /usr/local/bin/ldapadd |awk '{print $3}'`; do echo $file && objdump -T $file |grep 2044; done ``` (and nothing in /var/log/slapd.log) I should try to install it from a fresh install, it would be easier. Anyway, as you said, if installing it from a fresh install did not gave you this bug, I think you can close it... In the meantime, I am working with two other servers for production. As it works for me now (with hdb), I think I will remove the 2 others. This bug already took me too many time. Best regards, Rémy -- Rémy Dernat Ingénieur d'Etudes MBB/ISE-M

1 0

Re: (ITS#8672) syncrepl with openldap 2.4.{40,42} and mdb backend
by ryan＠nardis.ca 11 Jun '17

11 Jun '17

On Thu, Jun 08, 2017 at 01:06:21PM +0000, remy.dernat(a)umontpellier.fr wrote: >I am able to reproduce the bug quite easily. I'm afraid I have not been able to. I followed the steps you posted (with s/hdb/mdb/) with both servers running slapd 2.4.40+dfsg-1+deb8u3 and syncrepl seems to work fine. https://bugs.debian.org/798964 seems quite similar. Rémy, do you think this problem started for you right after you upgraded to +deb8u3?

1 0

Re: (ITS#8664) lmdb fragmentation leads to DDoS for consumers
by quanah＠symas.com 09 Jun '17

09 Jun '17

--On Thursday, June 01, 2017 12:22 AM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.44 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) Going to close this out, as the problem statement & other bits is incorrect. I will file a new ITS with a better summary of the issues. Looking forward to a different bug tracker that allows modification of the bug summary, etc. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8673) Need duration logging for sync ops
by quanah＠openldap.org 08 Jun '17

08 Jun '17

Full_Name: Quanah Gibson-Mount Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) We log the duration of an operation at stats level which allows being able to see how long a write OP took on a master. However we do not have any duration logging at the sync log level and therefore cannot determine how long a write op takes on a replica for the same modification. This is problematic when attempting to debug issues related to replication.

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs