From ryan@nardis.ca Sun Sep 1 19:14:22 2019 From: ryan@nardis.ca To: openldap-bugs@openldap.org Subject: Re: (ITS#8383) msys build error "portable.h:1116:19: error: two or more data types in declaration specifiers" Date: Sun, 01 Sep 2019 19:14:21 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2532208294928166670==" --===============2532208294928166670== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I've run into this myself while trying to test ITS#9069 on Windows. In my MinGW environment, does not define socklen_t, so=20 portable.h:1116 does '#define socklen_t int'. However, =20 includes which does typedef socklen_t. base64.c includes "portable.h" first and then later. This=20 second include triggers the error as the original typedef essentially=20 becomes "typedef int int". I think we can fix it by searching the Windows header as well, avoiding=20 the #define appearing in "portable.h". https://github.com/openldap/openldap/compare/openldap:master...rtandy:its8383= .patch --===============2532208294928166670==-- From feng.wang@iquantex.com Mon Sep 2 01:02:32 2019 From: feng.wang@iquantex.com To: openldap-bugs@openldap.org Subject: =?utf-8?b?562U5aSNOg==?= (ITS#9072) openLdap client problem Date: Mon, 02 Sep 2019 01:02:30 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1557075200482075301==" --===============1557075200482075301== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable --_6DA7EF0F-7766-481F-9373-22F0846C9405_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=3D"utf-8" Thank you for your reply! =3DC2=3DA0=3DC2=3DA0=3DC2=3DA0=3DC2=3DA0 This problem has been solved, not th= e openldap pro=3D blem, but the problem with the use of the sssd service. Of course, I will c=3D onsider your suggestion to upgrade to version 2.4.48. =3DE5=3D8F=3D91=3DE9=3D80=3D81=3DE8=3D87=3DAA Windows 10 =3DE7=3D89=3D88=3DE9= =3D82=3DAE=3DE4=3DBB=3DB6=3DE5=3DBA=3D94=3D =3DE7=3D94=3DA8 =3DE5=3D8F=3D91=3DE4=3DBB=3DB6=3DE4=3DBA=3DBA: Quanah Gibson-Mount =3DE5=3D8F=3D91=3DE9=3D80=3D81=3DE6=3D97=3DB6=3DE9=3D97=3DB4: 2019=3DE5=3DB9= =3DB48=3DE6=3D9C=3D8830=3DE6=3D97=3DA5 22=3D :07 =3DE6=3D94=3DB6=3DE4=3DBB=3DB6=3DE4=3DBA=3DBA: feng.wang(a)iquantex.com; open= ldap-its(a)OpenLDAP.=3D org =3DE4=3DB8=3DBB=3DE9=3DA2=3D98: Re: (ITS#9072) openLdap client problem --On Friday, August 30, 2019 7:14 AM +0000 feng.wang(a)iquantex.com wrote: > Thank you very much for getting support! > ???? In the production of openldap is the HA environment, other uses are > normal, only in the modification of the user to multiple groups (some > client new user information is updated, and some other host clients are > not updated). Please update to a current release of OpenLDAP, i.e, at least version=3D20 2.4.48 as numerous replication fixes have been made to the product since=3D20 that time. You were already told to upgrade in ITS#9053 as well. Please=3D20 stop filing ITSes until such a time as you have upgraded to a current=3D20 release. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: --_6DA7EF0F-7766-481F-9373-22F0846C9405_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=3D"utf-8"

Thank you for= you=3D r reply!

  &n= bs=3D p;  This problem has been solved, not the openldap problem, but the pr=3D oblem with the use of the sssd service. Of course, I will consider your sug=3D gestion to upgrade to version 2.4.48.

 

=3DE5=3D8F=3D91=3DE9=3D8= 0=3D81=3DE8=3D87=3D =3DAA Windows 10 =3DE7=3D89=3D88<=3D span lang=3D3DEN-US>=3DE9=3D82=3DAE=3DE4=3DBB=3DB6= =3DE5=3DBA=3D94=3DE7=3D =3D94=3DA8

 

=3DE= 5=3D8F=3D =3D91=3DE4=3DBB=3DB6=3DE4=3DBA=3DBA: Quanah Gibson-Mount
=3D= E5=3D =3D8F=3D91=3DE9=3D80=3D81=3DE6=3D97=3DB6=3DE9=3D97=3DB4:= 2019=3DE5=3DB9=3DB48=3DE6=3D9C= =3D8830=3DE6=3D97=3DA5 22:07
= =3DE6=3D94=3DB6=3D =3DE4=3DBB=3DB6=3DE4=3DBA=3DBA: feng.wang(a)iquantex.com; openldap-its(a)OpenLDAP.org
<=3D b>=3DE4=3DB8=3DBB=3DE9=3DA2=3D98: Re: =3D (ITS#9072) openLdap client problem

 =

 <= /s=3D pan>

 <= /p=3D >

--On Friday, August 30, 2019 7:1= 4 =3D AM +0000 feng.wang(a)iquantex.com wrote:

 

> Thank you very much for getting support!

> ???? In the production of openldap i= s =3D the HA environment, other uses are

> normal, only in the modification of the user to multiple gro= =3D ups (some

> client n= ew=3D user information is updated, and some other host clients are

> not updated).

 

Please update to a current release of OpenLDAP, i.= =3D e, at least version

2.= 4.=3D 48 as numerous replication fixes have been made to the product since

that time.=3DC2=3DA0 You wer= e alre=3D ady told to upgrade in ITS#9053 as well.=3DC2=3DA0 Please

stop filing ITSes until such a time as yo= u =3D have upgraded to a current

release.

 =

Regards,<=3D p class=3D3DMsoNormal>Quanah

 

 

--

&nbs= p;

Quanah Gibson-Moun= t<=3D /span>

Product Architect<=3D /p>

Symas Corporation

Packaged, certified, and supported LD= AP=3D solutions powered by OpenLDAP:

<http://www.symas.com>

 

=3D --_6DA7EF0F-7766-481F-9373-22F0846C9405_-- --===============1557075200482075301==-- From ondra@mistotebe.net Thu Sep 5 09:53:14 2019 From: ondra@mistotebe.net To: openldap-bugs@openldap.org Subject: Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements Date: Thu, 05 Sep 2019 09:53:13 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3013222650040119222==" --===============3013222650040119222== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 31, 2019 at 08:14:55PM +0000, gv(a)members.scinet.supercomputing.= org wrote: > v3 of the patch is available, which includes hashing functions > and documents the expected input format when using those functions. > I don't have the updated module on any of my servers yet, but > running slappasswd from my build directory does seem to yield > the same results as the non-password versions: >=20 > $ ../../../../servers/slapd/slappasswd -T passwd -o module-load=3D`pwd`/.li= bs/pw-totp.so -h "{TOTP1}" > New password:=20 > Re-enter new password:=20 > {TOTP1}GAYA=3D=3D=3D=3D >=20 > $ ../../../../servers/slapd/slappasswd -T passwd -o module-load=3D`pwd`/.li= bs/pw-totp.so -h "{TOTP1ANDPW}" > New password:=20 > Re-enter new password:=20 > {TOTP1ANDPW}GAYA=3D=3D=3D=3D|{SSHA}Qo6WiIWWsWohlwZSo9oQkImKvSNArGio >=20 > This is using an OTP seed of 00 and a password of foo >=20 > https://scinet.supercomputing.org/~gv/slapd-totp-v3.txt Hi Greg, looking at the code, I think I'd be ok with this functionality and nothing major comes up for me. I would like to see a few changes though: - could you split it in two patches, one to check the previous time step (+doc) and one to support the new schemes (+doc)? - I don't think you need to allocate a copy of the passwd just come in, you can just frame it into separate bervals reusing the provided buffer so long as you keep in mind they are not NUL-terminated properly. Just a style note, if there's an else coming, could you make sure both the if and the else blocks are in {}? Regards, --=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 --===============3013222650040119222==-- From gv@members.scinet.supercomputing.org Thu Sep 5 14:59:50 2019 From: gv@members.scinet.supercomputing.org To: openldap-bugs@openldap.org Subject: Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements Date: Thu, 05 Sep 2019 14:59:49 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6559496009761870863==" --===============6559496009761870863== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, Sep 05, 2019 at 11:52:45AM +0200, Ond??ej Kuzn??k wrote: > - could you split it in two patches, one to check the previous time step > (+doc) and one to support the new schemes (+doc)? Working on it, will have updated patches up shortly... > - I don't think you need to allocate a copy of the passwd just come in, > you can just frame it into separate bervals reusing the provided > buffer so long as you keep in mind they are not NUL-terminated > properly. Are you referring to the chk_totp_and_pw() function? If so, since the expected format is with no seperator, if I terminated the password part that would overwrite the first char of totp, yes? That's the reason I make a copy and allocate an extra byte for the NUL. > Just a style note, if there's an else coming, could you make sure both > the if and the else blocks are in {}? Implemented, it will be included in the updated patches. -- Greg Veldman --===============6559496009761870863==-- From openldap-its@OpenLDAP.org Fri Sep 6 15:00:45 2019 From: openldap-its@OpenLDAP.org To: openldap-bugs@openldap.org Subject: ITS#9074 published: SECURITY: Not able to view directory structure in 389 management Console Date: Fri, 06 Sep 2019 15:00:43 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6729250837630459903==" --===============6729250837630459903== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Private ITS#9074 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=9074 --===============6729250837630459903==-- From openldap-its@OpenLDAP.org Fri Sep 6 15:01:01 2019 From: openldap-its@OpenLDAP.org To: openldap-bugs@openldap.org Subject: ITS#9075 published: SECURITY: Not able to view directory structure in 389 management Console Date: Fri, 06 Sep 2019 15:01:00 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2687694056416188575==" --===============2687694056416188575== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Private ITS#9075 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=9075 --===============2687694056416188575==-- From ryan@nardis.ca Fri Sep 6 17:56:51 2019 From: ryan@nardis.ca To: openldap-bugs@openldap.org Subject: Re: (ITS#9069) Stop setting custom GnuTLS mutex functions Date: Fri, 06 Sep 2019 17:56:50 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3122679822000818486==" --===============3122679822000818486== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I know the locking gets exercised (both libldap and GnuTLS sides) during connection and TLS handshake, so I tested this by doing a bind/search/unbind loop on a bunch of parallel threads. I built master with this patch in all of the following environments: Debian 8 (jessie), GnuTLS 3.3.30 Debian 9 (stretch), GnuTLS 3.5.8 Debian 10 (buster), GnuTLS 3.6.7 Debian unstable (sid), GnuTLS 3.6.9 FreeBSD 12.0, GnuTLS 3.6.8 Solaris 11.4, GnuTLS 3.5.16, --with-threads=lwp Solaris 11.4, GnuTLS 3.5.16, --with-threads=posix Windows 10 (MinGW), GnuTLS 3.6.8, --with-threads=nt Windows 10 (MinGW), GnuTLS 3.6.8, --with-threads=posix and ran my test program successfully on all of them. On each of these I also stepped into the debugger and confirmed that the expected calls happened (gnutls_system_mutex_lock calling resp. pthread_mutex_lock or EnterCriticalSection, ldap_pvt_thread_mutex_lock calling the expected API, etc). Any further comments, or suggestions for additional tests I should run? --===============3122679822000818486==-- From gv@members.scinet.supercomputing.org Fri Sep 6 18:19:33 2019 From: gv@members.scinet.supercomputing.org To: openldap-bugs@openldap.org Subject: Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements Date: Fri, 06 Sep 2019 18:19:32 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6366602131727408300==" --===============6366602131727408300== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, Sep 05, 2019 at 10:59:46AM -0400, Greg Veldman wrote: > On Thu, Sep 05, 2019 at 11:52:45AM +0200, Ond??ej Kuzn??k wrote: > > - could you split it in two patches, one to check the previous time step > > (+doc) and one to support the new schemes (+doc)? > > Working on it, will have updated patches up shortly... Sorry that took a bit longer than I thought, got tied up with day job stuff yesterday afternoon. New patches are available that break out the two changes: https://scinet.supercomputing.org/~gv/slapd-totp-v4.txt https://scinet.supercomputing.org/~gv/slapd-totp-accept-previous-time-v1.txt -- Greg Veldman --===============6366602131727408300==-- From ondra@mistotebe.net Mon Sep 9 14:02:21 2019 From: ondra@mistotebe.net To: openldap-bugs@openldap.org Subject: Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements Date: Mon, 09 Sep 2019 14:02:20 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8751903368128161907==" --===============8751903368128161907== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Thu, Sep 05, 2019 at 10:59:46AM -0400, Greg Veldman wrote: > On Thu, Sep 05, 2019 at 11:52:45AM +0200, Ond??ej Kuzn??k wrote: >> - could you split it in two patches, one to check the previous time step >> (+doc) and one to support the new schemes (+doc)? > > Working on it, will have updated patches up shortly... Thanks for the updated patches. >> - I don't think you need to allocate a copy of the passwd just come in, >> you can just frame it into separate bervals reusing the provided >> buffer so long as you keep in mind they are not NUL-terminated >> properly. > > Are you referring to the chk_totp_and_pw() function? If so, > since the expected format is with no seperator, > if I terminated the password part that would overwrite the first > char of totp, yes? That's the reason I make a copy and allocate > an extra byte for the NUL. I mean the ber_str2bv(,,1,) in both new functions. Not sure which code you think would overwrite parts of the buffer? ber_str2bv(,,0,) never touches it, manually initialising the berval certainly wouldn't either. And then you have fewer memory regions to scrub. Since you already know the length, you can also pass it in so ber_str2bv can skip its strlen() check (and since anything can be in a {PLAINTEXT} password, you're now embedded NUL safe). >> Just a style note, if there's an else coming, could you make sure both >> the if and the else blocks are in {}? > > Implemented, it will be included in the updated patches. I think I mentioned this before as something worth changing: rather than call time(0L), you can use op->o_time which is stable and the closest you can get to the time the operation was received. BTW, scinet.supercomputing.org's HTTPS cert is signed by Let's Encrypt Authority X3 as an intermediate, but isn't sending it during the handshake, so wget/curl aren't happy trusting it (I think browsers cache it or already have a copy). Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP --===============8751903368128161907==-- From ondra@openldap.org Tue Sep 10 17:56:04 2019 From: ondra@openldap.org To: openldap-bugs@openldap.org Subject: (ITS#9076) back-ldap tries to free the wrong controls Date: Tue, 10 Sep 2019 17:56:03 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6737743537839278090==" --===============6737743537839278090== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Ondrej Kuznik Version: re24/master OS:=20 URL:=20 Submission from: (NULL) (82.132.242.212) ldap_back_extended_one needs to play with op->o_ctrls since it doesn't just p= ass ctrls over like the other sites in back-ldap, but it never sets oldctrls as is should. If a control is ever added to the list, it will restore op->o_ctrls to the wr= ong value and crash. This happens e.g. in certain chaining scenarios with mode=3Dlegacy. --===============6737743537839278090==-- From ondra@mistotebe.net Wed Sep 11 16:04:38 2019 From: ondra@mistotebe.net To: openldap-bugs@openldap.org Subject: Re: (ITS#9023) crash using ppolicy chaining from slave to master Date: Wed, 11 Sep 2019 16:04:37 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4583799997462229944==" --===============4583799997462229944== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Jean-Philippe, I have just seen and fixed a crash that might be similar to yours (ITS#9076), could you try and see if the crash goes away if you apply commit a14fb731ac6e39cd037512ca63bcb021f0196e5b? Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP --===============4583799997462229944==-- From gray@nxg.name Fri Sep 13 15:34:05 2019 From: gray@nxg.name To: openldap-bugs@openldap.org Subject: (ITS#9486) slapo-unique spins its wheels on a non-trivial olcUniqueURI spec Date: Fri, 13 Sep 2019 15:34:04 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6452367482824482713==" --===============6452367482824482713== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Norman Gray Version: 2.4.48 OS: FreeBSD 12.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.209.45.140) A plausible-looking spec in olcUniqueURI causes slapadd to spin its wheels indefinitely. I want to specify something like: dn: olcOverlay=3Dunique,olcDatabase=3D{1}mdb,cn=3Dconfig objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueURI: ldap:///ou=3Ddept-A,o=3Dexample?uidnumber?sub ldap:///ou=3Ddept-B,o=3Dexample?uidnumber?sub If I do this, however, then slapadd spins its wheels when the `slapd.ldif` is loaded into an otherwise empty configuration (ie, this happens at configurati= on time, before any records/objects are loaded): $ rm -R /usr/local/etc/openldap/slapd.d/* $ su -m ldap -c "slapadd -d255 -n 0 -F /usr/local/etc/openldap/slapd.d -l /usr/local/etc/openldap/slapd.ldif" ... ... 5d77d377 >>> dnPrettyNormal: 5d77d377 <<< dnPrettyNormal: , 5d77d377 <=3D str2entry(olcOverlay=3Dunique,olcDatabase=3D{1}mdb,cn=3Dcon= fig) -> 0x800d4eca8 5d77d377 oc_check_required entry (olcOverlay=3Dunique,olcDatabase=3D{1}mdb,cn=3Dconfig), objectClass "olcUniqu= eConfig" 5d77d377 oc_check_allowed type "objectClass" 5d77d377 oc_check_allowed type "olcOverlay" 5d77d377 oc_check_allowed type "olcUniqueURI" 5d77d377 oc_check_allowed type "structuralObjectClass" 5d77d377 >>> dnNormalize: 5d77d377 <<< dnNormalize: 5d77d377 =3D=3D> unique_db_init 5d77d377 =3D=3D> unique_new_domain 5d77d377 >>> dnPrettyNormal: 5d77d377 <<< dnPrettyNormal: , 5d77d377 >>> dnPrettyNormal: 5d77d377 <<< dnPrettyNormal: , 5d77d377 >>> dnPrettyNormal: 5d77d377 <<< dnPrettyNormal: , 5d77d377 >>> dnPrettyNormal: 5d77d377 <<< dnPrettyNormal: , 5d77d377 >>> dnPrettyNormal: 5d77d377 <<< dnPrettyNormal: , 5d77d377 >>> dnPrettyNormal: 5d77d377 <<< dnPrettyNormal: , ... ^C and so on and on and on, apparently indefinitely. The idea is that the uidnumber attribute should be unique across the two OUs, ou=3Ddept-A and ou=3Ddept-B. Whether or not this is a valid spec is another = issue; even if it's invalid, it shouldn't cause this behaviour; if the spec is inval= id, it should produce a terminal error. Looking at the code in servers/slapd/overlays/unique.c, nothing leaps out as = an obvious error (ie, I'm not claiming I have a fix for this). There was a brief thread about this on openldap-technical: Configuration: # /usr/local/libexec/slapd -VVV =20 @(#) $OpenLDAP: slapd 2.4.48 (Sep 10 2019 13:30:19) $ root(a)hermite.physics.gla.ac.uk:/var/ports/usr/ports/net/openldap24-server/= work/openldap-2.4.48/servers/slapd Included static overlays: constraint syncprov unique Included static backends: config ldif relay # freebsd-version 12.0-RELEASE-p9 This is the most recent currently-packaged version of OpenLDAP on FreeBSD. --===============6452367482824482713==-- From gv@members.scinet.supercomputing.org Fri Sep 13 15:57:19 2019 From: gv@members.scinet.supercomputing.org To: openldap-bugs@openldap.org Subject: Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements Date: Fri, 13 Sep 2019 15:57:18 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0217352020788566252==" --===============0217352020788566252== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, Sep 09, 2019 at 04:01:59PM +0200, Ond??ej Kuzn??k wrote: > I mean the ber_str2bv(,,1,) in both new functions. Not sure which code > you think would overwrite parts of the buffer? ber_str2bv(,,0,) never > touches it, manually initialising the berval certainly wouldn't either. > And then you have fewer memory regions to scrub. > > Since you already know the length, you can also pass it in so ber_str2bv > can skip its strlen() check (and since anything can be in a {PLAINTEXT} > password, you're now embedded NUL safe). Ah, OK, I didn't realize that would be NUL safe. I made an updated patch with that change[1]. > I think I mentioned this before as something worth changing: rather > than call time(0L), you can use op->o_time which is stable and the > closest you can get to the time the operation was received. Yes, sorry I did see that before just forgot to do it. It's also included in the latest update[1]. > BTW, scinet.supercomputing.org's HTTPS cert is signed by Let's Encrypt > Authority X3 as an intermediate, but isn't sending it during the > handshake, so wget/curl aren't happy trusting it (I think browsers cache > it or already have a copy). Thank you, this has been corrected. [1] https://scinet.supercomputing.org/~gv/slapd-totp-v5.txt -- Greg Veldman --===============0217352020788566252==-- From dpa-openldap@aegee.org Fri Sep 13 16:54:56 2019 From: dpa-openldap@aegee.org To: openldap-bugs@openldap.org Subject: (ITS#9487) Indices MDB Date: Fri, 13 Sep 2019 16:54:55 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2082340839441471282==" --===============2082340839441471282== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; &#1055= ;&#1072;&#1083;&#1072;&#1091;&#1079;&#1086;&#1074; Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.118.146.153) How can I write to a ticket here, after I submit it? https://www.openldap.org/software/man.cgi?query=3Dslapd-mdb&apropos=3D0&sekti= on=3D0&manpath=3DOpenLDAP+2.4-Release&format=3Dhtml (man slapd-mdb) is not clear about indices. Is=20 olcDbIndex A eq olcDbIndex B eq the same as olcDbIndex A,B eq and is the latter the same as oldDbIndex B,A eq ? In the SQL word these are different things and while Postgresql is supposed to handle "index A,B" and "index B.A" as equivalent, it does not, so a query = has to be tuned to make use of existing indices. The particular use-case is the LDAP backend of MIT Kerberos and the indices it needs for this query, as discussed at https://github.com/krb5/krb5/pull/974#issuecomment-531167854. The debug outp= ut of OpenLDAP is: Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf conn=3D1117 op=3D7 SRCH base=3D"cn=3DX.NET,cn=3DkrbContainer" scope=3D2 deref=3D0 filter=3D"(&(|(objectClass=3DkrbPrincipalAux)(objectClass=3DkrbPrincipal))(kr= bPrincipalName=3Dkrbtgt/X.NET(a)X.NET))" Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf conn=3D1117 op=3D7 SRCH attr=3Dkrbprincipalname krbcanonicalname objectclass krbprincipalkey krbmaxrenewable age krbmaxticketlife krbticketflags krbprincipalexpiration krbticketpolicyreference krbUpEnabled krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange krbLastAdminUnlock krbPrincipalAuthInd krbExtraData krbObjectReferences krbAllowedToDelegateTo krbPwdHistory Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf <=3D mdb_equality_candidates: (objectClass) not indexed Sep 13 09:09:03 mail slapd[14296]: 5d7b5caf conn=3D1117 op=3D7 SEARCH RESULT = tag=3D101 err=3D0 nentries=3D1 text=3D Does it need one index on objectClass, one index on krbPrincipal, or one index on "first objectClass, then krbPrincipal"? If no mdb_candidate output can be triggered, does it mean, that creating an index is pointless? Moreover, it is not clear when changing the oldDbIndex on a database regenera= tes the index, and when running slapindex is necessary. --===============2082340839441471282==-- From gray@nxg.name Fri Sep 13 17:07:14 2019 From: gray@nxg.name To: openldap-bugs@openldap.org Subject: (ITS#9488) documentation: slapo-unique syntax explanation unclear Date: Fri, 13 Sep 2019 17:07:13 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2741031312565503658==" --===============2741031312565503658== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Norman Gray Version: 2.4.48 OS: FreeBSD 12.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.209.45.140) Documentation bug The documentation for the `unique_uri` or `olcUniqueURI` attribute is very compact, with the result that it is not clear what counts as correct syntax, = nor what are the semantics of the specification. I'm not suggesting that the text is necessarily _inaccurate_, but that it is = too brief. That is, someone who already understand the syntax and semantics will probably not notice anything wrong with this paragraph; someone who doesn't already understand (eg, me) will struggle. slapo-unique(5) says that the syntax here is: unique_uri <[strict ][ignore ]URI[URI...]...> Configure the base, attributes, scope, and filter for uniqueness checking. Multiple URIs may be specified within a domain, allowing complex selections of objects. Multiple unique_uri statements or olcUniqueURI attributes will create independent domains, each with their own independent lists of URIs and ignore/strict settings. Keywords strict and ignore have to be enclosed in quotes (") together with the URI. The LDAP URI syntax is a subset of RFC-4516, and takes the form: ldap:///[base dn]?[attributes...]?scope[?filter] I understand from this text the following: * One can specify multiple URIs in the value of a olcUniqueURI attribute. I _guess_ these can be space-separated, even though that isn't shown in this syntax. * Each URI defines a set of object attributes * One can have multiple olcUniqueURI attributes, _each of which_ creates a 'domain' * This doesn't say what a 'domain' is, but I _guess_ that it means that all= of the attributes which match the search are forced, by this overlay, to be uniq= ue, but that there are no mutual uniqueness requirements between separate olcUniqueURI/'domain' specifications * If multiple URIs are specified in a 'domain', or olcUniqueURI attribute, then (wild guess) the union of the attributes matched by each URI is unique; I doubt it means the intersection of the result sets (I guess that because that= 's the only thing that sounds sensible; the phrase 'complex selections of object= s' doesn't clarify) * It's not clear where the quotes go, when combining with 'strict' or 'igno= re' (I guess "strict ldap://..."). * Can 'strict' or 'ignore' be combined with the second or subsequent URIs? = The syntax suggests not. I don't think the above understanding is correct, because when I specify a olcUniqueURI attribute with multiple URIs, I get an error (see ITS#9486 and thread ). At any rate, I have little confidence that I have interpreted the text correctly, and the above is the result of several careful readings and some guesswork. If the above, or something like it, is roughly correct, I could draft an alternative paragraph, if that would be useful. If the manpage included more than one example, that would be _extremely_ useful. I'll mention in passing that in servers/slapd/overlays/unique.c, the comment above `unique_new_domain` says instead * domain_specs look like * * [strict ][ignore ]uri[[ uri]...] * e.g. "ldap:///ou=3Dfoo,o=3Dbar?uid?sub ldap:///ou=3Dbaz,o=3Dbar?uid?sub" * "strict ldap:///ou=3Daccounts,o=3Dbar?uid,uidNumber?one" * etc =20 --===============2741031312565503658==-- From quanah@symas.com Fri Sep 13 17:33:45 2019 From: quanah@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#9077) slapo-unique spins its wheels on a non-trivial olcUniqueURI spec Date: Fri, 13 Sep 2019 17:33:44 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2948482576660687182==" --===============2948482576660687182== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Friday, September 13, 2019 4:34 PM +0000 gray(a)nxg.name wrote: > Full_Name: Norman Gray > Version: 2.4.48 > OS: FreeBSD 12.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.209.45.140) Unrelated side note, ITS number fixed to be 9077. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: --===============2948482576660687182==-- From quanah@symas.com Fri Sep 13 17:38:55 2019 From: quanah@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#9078) Indices MDB Date: Fri, 13 Sep 2019 17:38:53 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7405080340498073141==" --===============7405080340498073141== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Friday, September 13, 2019 5:54 PM +0000 dpa-openldap(a)aegee.org wrote: Hello, The ITS system is for bug reports, not usage questions. Please redirect your questions to the openldap-technical(a)openldap.org mailing list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: --===============7405080340498073141==-- From quanah@symas.com Fri Sep 13 17:41:45 2019 From: quanah@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#9079 documentation: slapo-unique syntax explanation unclear Date: Fri, 13 Sep 2019 17:41:44 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8789092429847509927==" --===============8789092429847509927== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Friday, September 13, 2019 6:07 PM +0000 gray(a)nxg.name wrote: > Full_Name: Norman Gray > Version: 2.4.48 > OS: FreeBSD 12.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.209.45.140) Note: this is now ITS#9079. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: --===============8789092429847509927==-- From gray@nxg.name Sat Sep 14 10:29:51 2019 From: gray@nxg.name To: openldap-bugs@openldap.org Subject: (ITS#9080) Feature request: support DNS SRV lookups in ldap.conf Date: Sat, 14 Sep 2019 10:29:50 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0198742350876530522==" --===============0198742350876530522== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Norman Gray Version: 2.4.47 OS: FreeBSD 12.0 (but not OS-soecific) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:8b0:df5:af53:c1a5:cbb2:6a6a:3390) Feature request: support specification of DNS SRV records in ldap.conf, match= ing ldapsearch -H The `ldapsearch` tools supports specifying lookups of SRV records via a special case syntax in the argument to the `-H` option. A URI such as ldap:///dc=3Dldap,dc=3Dexample,dc=3Dcom (with the commas and equals signs suitably escaped) prompts ldapsearch to do a lookup of an SRV record for ldap.example.com. However the URI synatx in ldap.conf doesn't have a corresponding special case, so it's not possible to put such a spec in a ldap.conf file. The ldap.conf documentation doesn't claim any support for SRV records, so there isn't a bug here, but on a Principle of Least Astonishment it would be very useful if the same syntax that -H respects were respected by ldap.conf as well. Other LDAP clients have different ways of specifying this (eg, nslcd.conf supports a `DNS:` syntax; Linux automount's `autofs.conf` has a `ldap_uri` attribute which supports a very similar dc=3Dxxx syntax), so an alternative ldap.conf syntax would be a good second best. As an auxiliary point, when `ldapsearch` sees `URI ldap:///dc%3D...` in the ldap.conf file, it silently ignores it, rather than producing an error. It doesn't even produce a warning when `ldapsearch` is invoked with `-d-1`. I had to use strace to reassure myself that the config file was actually being read. I feel that a library should make a _lot_ more noise about an attribute in a configuration file being seen but ignored (I can see that the `ldap://dc...` URI, which is of course syntactically OK, _might_ be inadvertently meaningful, and thus not necessarily a detectable error, but even in that case `-d-1` should produce _something_). A scan through ITS reports found the following: * ITS#5919 (2009, still open) discusses a similar request, and discusses a variety of issues with it. This is a useful cross-reference. * ITS#6462 (2010, open) and ITS#8610 (2017, open) both touch on SRV records, but aren't particularly relevant, since they're both about the handling of ldaps:// URIs specifying a SRV record. * ITS#7027 (2011, closed) and ITS#8196 (open) are concerned with the internal handling of SRV records, but not their configuration $ ldapsearch -VV ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.47 (Jul 25 2019 01:30:14) $ root(a)120amd64-quarterly-job-16:/wrkdirs/usr/ports/net/openldap24-sasl-clie= nt/work/openldap-2.4.47/clients/tools (LDAP library: OpenLDAP 20447) --===============0198742350876530522==-- From Norman.Gray@glasgow.ac.uk Sat Sep 14 11:55:48 2019 From: Norman.Gray@glasgow.ac.uk To: openldap-bugs@openldap.org Subject: ITS#9080 a further relevant ITS Date: Sat, 14 Sep 2019 11:55:47 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3185045056495336998==" --===============3185045056495336998== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I should also note that ITS#4996 (2007, closed) appears to be the issue=20 which resulted in the support for `-H ":///DN"` being added to=20 the command-line clients. --=20 Norman Gray : https://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK --===============3185045056495336998==-- From jengelh@inai.de Mon Sep 16 11:54:01 2019 From: jengelh@inai.de To: openldap-bugs@openldap.org Subject: (ITS#9081) Memory leak in ldap_initialize/ldap_unbind Date: Mon, 16 Sep 2019 11:53:58 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4203469600086337004==" --===============4203469600086337004== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Full_Name: Jan Engelhardt Version: 2.4.48 OS: openSUSE Tumbleweed; Linux 5.3.0-rc7 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a02:8108:96c0:15fc:2137:8684:9608:51f8) » cat x.c #define LDAP_DEPRECATED 1 #include int main() { LDAP *ld; ldap_initialize(&ld, "ldapi:///"); ldap_unbind(ld); } » gcc x.c -Wall -lldap -ggdb3 » valgrind --leak-check=full ./a.out ==25779== HEAP SUMMARY: ==25779== in use at exit: 26,395 bytes in 85 blocks ==25779== total heap usage: 233 allocs, 148 frees, 177,134 bytes allocated ==25779== ==25779== 40 bytes in 1 blocks are definitely lost in loss record 11 of 24 ==25779== at 0x4838B65: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==25779== by 0x4A8310C: ber_memcalloc_x (memory.c:283) ==25779== by 0x4A84EC0: ber_sockbuf_alloc (sockbuf.c:60) ==25779== by 0x487396A: ldap_create (open.c:172) ==25779== by 0x4873C8D: ldap_initialize (open.c:241) ==25779== by 0x10915F: main (x.c:6) ==25779== ==25779== LEAK SUMMARY: ==25779== definitely lost: 40 bytes in 1 blocks ==25779== indirectly lost: 0 bytes in 0 blocks ==25779== possibly lost: 0 bytes in 0 blocks ==25779== still reachable: 26,355 bytes in 84 blocks ==25779== suppressed: 0 bytes in 0 blocks ==25779== Reachable blocks (those to which a pointer was found) are not shown. ==25779== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==25779== ==25779== For lists of detected and suppressed errors, rerun with: -s ==25779== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) unbind.c: 123 for ( lm = ld->ld_responses; lm != NULL; lm = next ) { 128 if ( ld->ld_abandoned != NULL ) { 132 LDAP_MUTEX_UNLOCK( &ld->ld_res_mutex ); 136 ber_int_sb_destroy( ld->ld_sb ); Should this probably be LBER_FREE rather than ber_int_sb_destroy? --===============4203469600086337004==-- From jpayanides@prosodie.com Tue Sep 17 13:03:33 2019 From: jpayanides@prosodie.com To: openldap-bugs@openldap.org Subject: RE: (ITS#9023) crash using ppolicy chaining from slave to master Date: Tue, 17 Sep 2019 13:03:29 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4691366650199655391==" --===============4691366650199655391== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --_000_AM0PR0202MB3553BA671B52D50E489F7ACBBA8F0AM0PR0202MB3553_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SGVsbG8gT25kxZllaiAsDQp0aGFua3MgYSBsb3QgZm9yIHdhcm5pbmcgbWUuDQpJIHdpbGwgdGVz dCB0aGUgbmV3IGNvZGUgd2l0aGluIGEgbW9udGggKEkgY2Fubm90IGRvIGl0IGF0IHRoaXMgdGlt ZSkuDQoNCklsIGtlZXAgeW91IGluZm9ybWVkLg0KDQpraW5kIHJlZ2FyZHMsDQoNCg0KSmVhbi1Q aGlsaXBwZSBBeWFuaWRlcw0KQ29uY2VwdGlvbiBldCBhcmNoaXRlY3R1cmUgc8OpY3VyaXTDqQ0K U2VydmljZSAmIE9wZXJhdGlvbiAvIEluZnJhc3RydWN0dXJlIE5ldHdvcmsgU2VjdXJpdHkgQmFj a2JvbmUNCnTDqWwgKzMzMTM0NDkwNjI4DQpQcm9zb2RpZS1DYXBnZW1pbmkNClBlb3BsZSBtYXR0 ZXIsIHJlc3VsdHMgY291bnQuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGUg OiBPbmTFmWVqIEt1em7DrWsgPG9uZHJhQG1pc3RvdGViZS5uZXQ+DQpFbnZvecOpIDogbWVyY3Jl ZGkgMTEgc2VwdGVtYnJlIDIwMTkgMTg6MDQNCsOAIDogQVlBTklERVMsIEpFQU4tUEhJTElQUEUg PGpwYXlhbmlkZXNAcHJvc29kaWUuY29tPg0KQ2MgOiBvcGVubGRhcC1pdHNAT3BlbkxEQVAub3Jn IDxvcGVubGRhcC1pdHNAT3BlbkxEQVAub3JnPg0KT2JqZXQgOiBSZTogKElUUyM5MDIzKSBjcmFz aCB1c2luZyBwcG9saWN5IGNoYWluaW5nIGZyb20gc2xhdmUgdG8gbWFzdGVyDQoNCkhpIEplYW4t UGhpbGlwcGUsDQpJIGhhdmUganVzdCBzZWVuIGFuZCBmaXhlZCBhIGNyYXNoIHRoYXQgbWlnaHQg YmUgc2ltaWxhciB0byB5b3Vycw0KKElUUyM5MDc2KSwgY291bGQgeW91IHRyeSBhbmQgc2VlIGlm IHRoZSBjcmFzaCBnb2VzIGF3YXkgaWYgeW91IGFwcGx5DQpjb21taXQgYTE0ZmI3MzFhYzZlMzlj ZDAzNzUxMmNhNjNiY2IwMjFmMDE5NmU1Yj8NCg0KVGhhbmtzLA0KDQotLQ0KT25kxZllaiBLdXpu w61rDQpTZW5pb3IgU29mdHdhcmUgRW5naW5lZXINClN5bWFzIENvcnBvcmF0aW9uICAgICAgICAg ICAgICAgICAgICAgICBodHRwOi8vd3d3LnN5bWFzLmNvbQ0KUGFja2FnZWQsIGNlcnRpZmllZCwg YW5kIHN1cHBvcnRlZCBMREFQIHNvbHV0aW9ucyBwb3dlcmVkIGJ5IE9wZW5MREFQDQpUaGlzIG1l c3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25m aWRlbnRpYWwgYW5kIGlzIHRoZSBwcm9wZXJ0eSBvZiB0aGUgQ2FwZ2VtaW5pIEdyb3VwLiBJdCBp cyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIHRvIHdob20gaXQgaXMgYWRkcmVzc2VkLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdCBhdXRob3Jp emVkIHRvIHJlYWQsIHByaW50LCByZXRhaW4sIGNvcHksIGRpc3NlbWluYXRlLCBkaXN0cmlidXRl LCBvciB1c2UgdGhpcyBtZXNzYWdlIG9yIGFueSBwYXJ0IHRoZXJlb2YuIElmIHlvdSByZWNlaXZl IHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIG1lc3NhZ2UuCg== --_000_AM0PR0202MB3553BA671B52D50E489F7ACBBA8F0AM0PR0202MB3553_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBD YWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNv bG9yOiByZ2IoMCwgMCwgMCk7Ij4NCkhlbGxvIDxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTFwdCI+T25kxZllaiA8L3NwYW4+PC9mb250Piw8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCnRoYW5rcyBhIGxvdCBmb3Igd2Fy bmluZyBtZS48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwg SGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwg MCk7Ij4NCkkgd2lsbCB0ZXN0IHRoZSBuZXcgY29kZSB3aXRoaW4gYSBtb250aCAoSSBjYW5ub3Qg ZG8gaXQgYXQgdGhpcyB0aW1lKS48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxp YnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9y OiByZ2IoMCwgMCwgMCk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsg Y29sb3I6IHJnYigwLCAwLCAwKTsiPg0KSWwga2VlcCB5b3UgaW5mb3JtZWQuPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8YnI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7Ij4NCmtpbmQgcmVn YXJkcyw8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlh bCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwg MCwgMCk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBpZD0iU2lnbmF0dXJlIj4NCjxkaXYgaWQ9ImRp dnRhZ2RlZmF1bHR3cmFwcGVyIiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyBjb2xv cjojMDAwMDAwOyBmb250LWZhbWlseTpDYWxpYnJpLEhlbHZldGljYSxzYW5zLXNlcmlmIj4NCjxk aXYgaWQ9ImRpdnRhZ2RlZmF1bHR3cmFwcGVyIiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQtc2l6ZTox MnB0OyBjb2xvcjojMDAwMDAwOyBiYWNrZ3JvdW5kLWNvbG9yOiNGRkZGRkY7IGZvbnQtZmFtaWx5 OkNhbGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPg0KPHAgc3R5bGU9Im1hcmdpbi10 b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PHNwYW4gbGFuZz0iZnIiPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46MCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJv bWFuLHNlcmlmIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQiPjxmb250IHNpemU9IjIiIGZh Y2U9IlZlcmRhbmEsc2Fucy1zZXJpZiIgY29sb3I9IiMwMDQ2OEMiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OXB0Ij48Yj5KZWFuLVBoaWxpcHBlIEF5YW5pZGVzPGJyPg0KPC9iPjwvc3Bhbj48L2Zv bnQ+PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7IGZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9y OmJsYWNrIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0OyBmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+Q29uY2VwdGlv biBldCBhcmNoaXRlY3R1cmUgc8OpY3VyaXTDqTwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjhwdDsgZm9udC1mYW1pbHk6QXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPlNlcnZp Y2UgJmFtcDsgT3BlcmF0aW9uIC8gSW5mcmFzdHJ1Y3R1cmU8L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjhw dDsgZm9udC1mYW1pbHk6QXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPg0KIE5ldHdvcmsgU2Vj dXJpdHkgQmFja2JvbmU8L3NwYW4+PGJyPg0KPGEgY2xhc3M9Im8zNjVidXR0b24iPjxzcGFuIGNs YXNzPSJtcy1mb250LXMgbXMtZm9udC1jb2xvci10aGVtZVByaW1hcnkiIHRpdGxlPSImIzQzOzMz MTM0NDkwNjI4Ij50w6lsICYjNDM7MzMxMzQ0OTA2Mjg8L3NwYW4+PC9hPjxicj4NClByb3NvZGll LUNhcGdlbWluaTxicj4NCjwvc3Bhbj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMDA5OENDIj5Q ZW9wbGUgbWF0dGVyLCByZXN1bHRzIGNvdW50Ljwvc3Bhbj48L3N0cm9uZz48L2Rpdj4NCjxzdHJv bmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7IGNvbG9yOiMwMDk4Q0MiPjwvc3Bhbj48L3N0cm9uZz48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBpZD0iYXBwZW5kb25zZW5kIj48L2Rpdj4NCjxociBzdHlsZT0iZGlzcGxheTppbmxp bmUtYmxvY2s7d2lkdGg6OTglIiB0YWJpbmRleD0iLTEiPg0KPGRpdiBpZD0iZGl2UnBseUZ3ZE1z ZyIgZGlyPSJsdHIiPjxmb250IGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYiIHN0eWxlPSJmb250 LXNpemU6MTFwdCIgY29sb3I9IiMwMDAwMDAiPjxiPkRlIDo8L2I+IE9uZMWZZWogS3V6bsOtayAm bHQ7b25kcmFAbWlzdG90ZWJlLm5ldCZndDs8YnI+DQo8Yj5FbnZvecOpIDo8L2I+IG1lcmNyZWRp IDExIHNlcHRlbWJyZSAyMDE5IDE4OjA0PGJyPg0KPGI+w4AgOjwvYj4gQVlBTklERVMsIEpFQU4t UEhJTElQUEUgJmx0O2pwYXlhbmlkZXNAcHJvc29kaWUuY29tJmd0Ozxicj4NCjxiPkNjJm5ic3A7 OjwvYj4gb3BlbmxkYXAtaXRzQE9wZW5MREFQLm9yZyAmbHQ7b3BlbmxkYXAtaXRzQE9wZW5MREFQ Lm9yZyZndDs8YnI+DQo8Yj5PYmpldCA6PC9iPiBSZTogKElUUyM5MDIzKSBjcmFzaCB1c2luZyBw cG9saWN5IGNoYWluaW5nIGZyb20gc2xhdmUgdG8gbWFzdGVyPC9mb250Pg0KPGRpdj4mbmJzcDs8 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iQm9keUZyYWdtZW50Ij48Zm9udCBzaXplPSIyIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+SGkg SmVhbi1QaGlsaXBwZSw8YnI+DQpJIGhhdmUganVzdCBzZWVuIGFuZCBmaXhlZCBhIGNyYXNoIHRo YXQgbWlnaHQgYmUgc2ltaWxhciB0byB5b3Vyczxicj4NCihJVFMjOTA3NiksIGNvdWxkIHlvdSB0 cnkgYW5kIHNlZSBpZiB0aGUgY3Jhc2ggZ29lcyBhd2F5IGlmIHlvdSBhcHBseTxicj4NCmNvbW1p dCBhMTRmYjczMWFjNmUzOWNkMDM3NTEyY2E2M2JjYjAyMWYwMTk2ZTViPzxicj4NCjxicj4NClRo YW5rcyw8YnI+DQo8YnI+DQotLSA8YnI+DQpPbmTFmWVqIEt1em7DrWs8YnI+DQpTZW5pb3IgU29m dHdhcmUgRW5naW5lZXI8YnI+DQpTeW1hcyBDb3Jwb3JhdGlvbiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 YSBocmVmPSJodHRwOi8vd3d3LnN5bWFzLmNvbSI+aHR0cDovL3d3dy5zeW1hcy5jb208L2E+PGJy Pg0KUGFja2FnZWQsIGNlcnRpZmllZCwgYW5kIHN1cHBvcnRlZCBMREFQIHNvbHV0aW9ucyBwb3dl cmVkIGJ5IE9wZW5MREFQPGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogOXB4OyBsaW5lLWhlaWdodDogMTBweDsiPlRoaXMgbWVzc2FnZSBj b250YWlucyBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlh bCBhbmQgaXMgdGhlIHByb3BlcnR5IG9mIHRoZSBDYXBnZW1pbmkgR3JvdXAuIEl0IGlzIGludGVu ZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90IGF1dGhvcml6ZWQgdG8g cmVhZCwgcHJpbnQsIHJldGFpbiwgY29weSwgZGlzc2VtaW5hdGUsIGRpc3RyaWJ1dGUsIG9yIHVz ZSB0aGlzIG1lc3NhZ2Ugb3IgYW55IHBhcnQgdGhlcmVvZi4gSWYgeW91IHJlY2VpdmUgdGhpcyBt ZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5k IGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoaXMgbWVzc2FnZS48L3NwYW4+PC9ib2R5Pg0KPC9odG1s Pg0K --_000_AM0PR0202MB3553BA671B52D50E489F7ACBBA8F0AM0PR0202MB3553_-- --===============4691366650199655391==-- From krishradhe11@gmail.com Tue Sep 17 17:47:08 2019 From: krishradhe11@gmail.com To: openldap-bugs@openldap.org Subject: (ITS#9082) Issues while upgrading to 2.4.48 Date: Tue, 17 Sep 2019 17:47:07 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2426456545407975168==" --===============2426456545407975168== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Radhe Krish Version: 2.4.44 OS: Centos 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (139.85.223.11) Hello ! I 'm using Openldap version 2.4.44 running on my centos 7 machine. In process to upgrade to the recently released Openldap version 2.4.48, I'm faci= ng some difficulties while choosing the concerned folder to save executable libraries. I followed the instructions as in official website but I'm not positive about how to upgrade from already installed Openldap 2.4.44 to 2.4.4= 8. I tried to find RPMs supporting this but still no luck.Can you help me with clear instructions to proceed upgrade from 2.4.44 to 2.4.48 or help me with t= he corresponding RPM, that will be really helpful. --===============2426456545407975168==-- From quanah@symas.com Tue Sep 17 23:17:53 2019 From: quanah@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#9082) Issues while upgrading to 2.4.48 Date: Tue, 17 Sep 2019 23:17:52 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5872533893591314645==" --===============5872533893591314645== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Tuesday, September 17, 2019 6:47 PM +0000 krishradhe11(a)gmail.com wrote: > Full_Name: Radhe Krish > Version: 2.4.44 > OS: Centos 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (139.85.223.11) Hello, The ITS system is for reporting bugs, not usage questions. Please redirect your query to the openldap-technical(a)openldap.org email list for questions such as yours. I will note that this question has been asked and answered there already for other individuals, so if you look at the list archives, you'll find your answer. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: --===============5872533893591314645==-- From marketing@daasi.de Wed Sep 18 09:47:14 2019 From: marketing@daasi.de To: openldap-bugs@openldap.org Subject: (ITS#9083) Broken link in the list of commercial support partners Date: Wed, 18 Sep 2019 09:47:13 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4004516944690762973==" --===============4004516944690762973== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Romy Hoffart Version: - OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.24.13.226) Hey everyone,=20 I am with the marketing department of DAASI International, one of the commerc= ial support partners for OpenLDAP listed on your website. Unfortunately I noticed that the link to our website doesn't work anymore. Could you replace the link here (https://www.openldap.org/support/) with a new link to our website (https://daasi.de/en/)? I was in touch with Quanah from Symas before, she recommended me to submit th= is issue here.=20 Thank you so much for your time & help, Romy --===============4004516944690762973==-- From aixtools@felt.demon.nl Wed Sep 18 16:55:12 2019 From: aixtools@felt.demon.nl To: openldap-bugs@openldap.org Subject: (ITS#9084) Build issue when slaps is not included Date: Wed, 18 Sep 2019 16:55:10 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6523954941685903732==" --===============6523954941685903732== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Michael Felt Version: 2.4.48 OS: AIX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (109.104.126.147) Build of 2.4.46 proceeds with no issue. When using the same command to build 2.4.48 the build stops with an undefined variable error: root(a)x066:[/data/prj/aixtools/src]grep LDAP_OPT_X_TLS *46/* *48/* openldap-2.4.46/CHANGES: Added libldap LDAP_OPT_X_TLS_PACKAGE (ITS#696= 9) openldap-2.4.48/CHANGES: Added libldap LDAP_OPT_X_TLS_PACKAGE (ITS#696= 9) root(a)x066:[/data/prj/aixtools/src]find *46 *48 | xargs grep LDAP_OPT_X_TLS_ECNAME openldap-2.4.48/include/ldap.h:#define LDAP_OPT_X_TLS_ECNAME 0x6012 openldap-2.4.48/libraries/libldap/tls2.c: case LDAP_OPT_X_TLS_ECNAME: openldap-2.4.48/libraries/libldap/tls2.c: case LDAP_OPT_X_TLS_ECNAME: openldap-2.4.48/servers/slapd/bconfig.c: case CFG_TLS_ECNAME: flag = =3D LDAP_OPT_X_TLS_ECNAME; break; >From above, it appears that LDAP_OPT_X_TLS_ECNAME should be defined, but I question that as I get the following error when compiling... Entering subdirectory libldap make[2]: Entering directory '/data/prj/aixtools/static/openldap-2.4.48/libraries/libldap' /bin/sh ../../libtool --mode=3Dcompile xlc_r -I/opt/include -O2 -qmaxmem=3D-1 -I../../include -I../../../../src/openldap-2.4.48/include =20 -I/opt/include -DLDAP_LIBRARY -c ../../../../src/openldap-2.4.48/libraries/libldap/tls2.c xlc_r -I/opt/include -O2 -qmaxmem=3D-1 -I../../include -I../../../../src/openldap-2.4.48/include -I/opt/include -DLDAP_LIBRARY -c ../../../../src/openldap-2.4.48/libraries/libldap/tls2.c -o tls2.o "../../../../src/openldap-2.4.48/libraries/libldap/tls2.c", line 658.14: 1506-045 (S) Undeclared identifier LDAP_OPT_X_TLS_ECNAME. "../../../../src/openldap-2.4.48/libraries/libldap/tls2.c", line 658.14: 1506-051 (S) Case expression must be a valid integral constant. "../../../../src/openldap-2.4.48/libraries/libldap/tls2.c", line 781.14: 1506-045 (S) Undeclared identifier LDAP_OPT_X_TLS_ECNAME. "../../../../src/openldap-2.4.48/libraries/libldap/tls2.c", line 781.14: 1506-051 (S) Case expression must be a valid integral constant. make[2]: *** [Makefile:413: tls2.lo] Error 1 make[2]: Leaving directory '/data/prj/aixtools/static/openldap-2.4.48/libraries/libldap' make[1]: *** [Makefile:297: all-common] Error 1 make[1]: Leaving directory '/data/prj/aixtools/static/openldap-2.4.48/libraries' make: *** [Makefile:313: all-common] Error 1 Researching further... Michael --===============6523954941685903732==-- From kriszyp@gmail.com Wed Sep 18 18:56:36 2019 From: kriszyp@gmail.com To: openldap-bugs@openldap.org Subject: Re: (ITS#9017) Improving performance of commit sync in Windows Date: Wed, 18 Sep 2019 18:56:34 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7714618235955763312==" --===============7714618235955763312== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable --000000000000d8a73d0592d86418 Content-Type: text/plain; charset=3D"UTF-8" Content-Transfer-Encoding: quoted-printable Checking on this again, is this still a possibility for merging into LMDB? This fix is still working great (improved performance) on our systems. Thanks, Kris On Mon, Jun 17, 2019 at 1:04 PM Kris Zyp wrote: > Is this still being considered/reviewed? Let me know if there are any > other changes you would like me to make. This patch has continued to yiel=3D d > significant and reliable performance improvements for us, and seems like =3D it > would be nice for this to be available for other Windows users. > > On Fri, May 3, 2019 at 3:52 PM Kris Zyp wrote: > >> For the sake of putting this in the email thread (other code discussion >> in GitHub), here is the latest squashed commit of the proposed patch (wi=3D th >> the on-demand, retained overlapped array to reduce re-malloc and opening >> event handles): >> https://github.com/kriszyp/node-lmdb/commit/726a9156662c703bf3d453aab75e=3D e222072b990f >> >> >> >> Thanks, >> Kris >> >> >> >> *From: *Kris Zyp >> *Sent: *April 30, 2019 12:43 PM >> *To: *Howard Chu ; openldap-its(a)OpenLDAP.org >> *Subject: *RE: (ITS#9017) Improving performance of commit sync in Window=3D s >> >> >> >> > What is the point of using writemap mode if you still need to use >> WriteFile >> >> > on every individual page? >> >> >> >> As I understood from the documentation, and have observed, using writema=3D p >> mode is faster (and uses less temporary memory) because it doesn=3DE2=3D80= =3D =3D99t require >> mallocs to allocate pages (docs: =3DE2=3D80=3D9CThis is faster and uses fe= wer =3D mallocs=3DE2=3D80=3D9D). >> To be clear though, LMDB is so incredibly fast and efficient, that in >> sync-mode, it takes enormous transactions before the time spent allocati=3D ng >> and creating the dirty pages with the updated b-tree is anywhere even >> remotely close to the time it takes to wait for disk flushing, even with=3D an >> SSD. But the more pertinent question is efficiency, and measuring CPU >> cycles rather than time spent (efficiency is more important than just ti=3D me >> spent). When I ran my tests this morning of 100 (sync) transactions with >> 100 puts per transaction, times varied quite a bit, but it seemed like >> running with writemap enabled typically averages about 500ms of CPU and >> with writemap disabled it typically averages around 600ms. Not a huge >> difference, but still definitely worthwhile, I think. >> >> >> >> Caveat emptor: Measuring LMDB performance with sync interactions on >> Windows is one of the most frustratingly erratic things to measure. It i=3D s >> sunny outside right now, times could be different when it starts raining >> later, but, this is what I saw this morning... >> >> >> >> > What is the performance difference between your patch using writemap, >> and just >> >> > not using writemap in the first place? >> >> >> >> Running 1000 sync transactions on 3GB db with a single put per >> transaction, without writemap map, without the patch took about 60 secon=3D ds. >> And it took about 1 second with the patch with writemap mode enabled! >> (there is no significant difference in sync times with writemap enabled =3D or >> disabled with the patch.) So the difference was huge in my test. And not >> only that, without the patch, the CPU usage was actually _*higher*_ >> during that 60 seconds (close to 100% of a core) than during the executi=3D on >> with the patch for one second (close to 50%). Anyway, there are certain=3D ly >> tests I have run where the differences are not as large (doing small >> commits on large dbs accentuates the differences), but the patch always >> seems to win. It could also be that my particular configuration causes >> bigger differences (on an SSD drive, and maybe a more fragmented file?). >> >> >> >> Anyway, I added error handling for the malloc, and fixed/changed the >> other things you suggested. Be happy to make any other changes you want. >> The updated patch is here: >> >> >> https://github.com/kriszyp/node-lmdb/commit/25366dea9453749cf6637f43ec17=3D b9b62094acde >> >> >> >> > OVERLAPPED* ov =3D3D malloc((pagecount - keep) * sizeof(OVERLAPPED)); >> >> > Probably this ought to just be pre-allocated based on the maximum >> number of dirty pages a txn allows. >> >> >> >> I wasn=3DE2=3D80=3D99t sure I understood this comment. Are you suggesting = we m=3D alloc(MDB_IDL_UM_MAX >> * sizeof(OVERLAPPED)) for each environment, and retain it for the life o=3D f >> the environment? I think that is 4MB, if my math is right, which seems l=3D ike >> a lot of memory to keep allocated (we usually have a lot of open >> environments). If the goal is to reduce the number of mallocs, how about=3D we >> retain the OVERLAPPED array, and only free and re-malloc if the previous >> allocation wasn=3DE2=3D80=3D99t large enough? Then there isn=3DE2=3D80=3D9= 9t unneces=3D sary allocation, >> and we only malloc when there is a bigger transaction than any previous.=3D I >> put this together in a separate commit, as I wasn=3DE2=3D80=3D99t sure if = this=3D what you >> wanted (can squash if you prefer): >> https://github.com/kriszyp/node-lmdb/commit/2fe68fb5269c843e2e789746a17a=3D 4b2adefaac40 >> >> >> >> Thank you for the review! >> >> >> >> Thanks, >> Kris >> >> >> >> *From: *Howard Chu >> *Sent: *April 30, 2019 7:12 AM >> *To: *kriszyp(a)gmail.com; openldap-its(a)OpenLDAP.org >> *Subject: *Re: (ITS#9017) Improving performance of commit sync in Window=3D s >> >> >> >> kriszyp(a)gmail.com wrote: >> >> > Full_Name: Kristopher William Zyp >> >> > Version: LMDB 0.9.23 >> >> > OS: Windows >> >> > URL: >> https://github.com/kriszyp/node-lmdb/commit/7ff525ae57684a163d32af74a0ab=3D 9332b7fc4ce9 >> >> > Submission from: (NULL) (71.199.6.148) >> >> > >> >> > >> >> > We have seen very poor performance on the sync of commits on large >> databases in >> >> > Windows. On databases with 2GB of data, in writemap mode, the sync of >> even small >> >> > commits is consistently well over 100ms (without writemap it is faster=3D , >> but >> >> > still slow). It is expected that a sync should take some time while >> waiting for >> >> > disk confirmation of the writes, but more concerning is that these syn=3D c >> >> > operations (in writemap mode) are instead dominated by nearly 100% >> system CPU >> >> > utilization, so operations that requires sub-millisecond b-tree update >> >> > operations are then dominated by very large amounts of system CPU >> cycles during >> >> > the sync phase. >> >> > >> >> > I think that the fundamental problem is that FlushViewOfFile seems to >> be an O(n) >> >> > operation where n is the size of the file (or map). I presume that >> Windows is >> >> > scanning the entire map/file for dirty pages to flush, I'm guessing >> because it >> >> > doesn't have an internal index of all the dirty pages for every >> file/map-view in >> >> > the OS disk cache. Therefore, the turns into an extremely expensive, >> CPU-bound >> >> > operation to find the dirty pages for (large file) and initiate their >> writes, >> >> > which, of course, is contrary to the whole goal of a scalable database >> system. >> >> > And FlushFileBuffers is also relatively slow as well. We have attempte=3D d >> to batch >> >> > as many operations into single transaction as possible, but this is >> still a very >> >> > large overhead. >> >> > >> >> > The Windows docs for FlushFileBuffers itself warns about the >> inefficiencies of >> >> > this function ( >> https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-=3D flushfilebuffers >> ). >> >> > Which also points to the solution: it is much faster to write out the >> dirty >> >> > pages with WriteFile through a sync file handle >> (FILE_FLAG_WRITE_THROUGH). >> >> > >> >> > The associated patch >> >> > ( >> https://github.com/kriszyp/node-lmdb/commit/7ff525ae57684a163d32af74a0ab=3D 9332b7fc4ce9 >> ) >> >> > is my attempt at implementing this solution, for Windows. Fortunately, >> with the >> >> > design of LMDB, this is relatively straightforward. LMDB already >> supports >> >> > writing out dirty pages with WriteFile calls. I added a write-through >> handle for >> >> > sending these writes directly to disk. I then made that file-handle >> >> > overlapped/asynchronously, so all the writes for a commit could be >> started in >> >> > overlap mode, and (at least theoretically) transfer in parallel to the >> drive and >> >> > then used GetOverlappedResult to wait for the completion. So basically >> >> > mdb_page_flush becomes the sync. I extended the writing of dirty pages >> through >> >> > WriteFile to writemap mode as well (for writing meta too), so that >> WriteFile >> >> > with write-through can be used to flush the data without ever needing >> to call >> >> > FlushViewOfFile or FlushFileBuffers. I also implemented support for >> write >> >> > gathering in writemap mode where contiguous file positions infers >> contiguous >> >> > memory (by tracking the starting position with wdp and writing >> contiguous pages >> >> > in single operations). Sorting of the dirty list is maintained even in >> writemap >> >> > mode for this purpose. >> >> >> >> What is the point of using writemap mode if you still need to use >> WriteFile >> >> on every individual page? >> >> >> >> > The performance benefits of this patch, in my testing, are >> considerable. Writing >> >> > out/syncing transactions is typically over 5x faster in writemap mode, >> and 2x >> >> > faster in standard mode. And perhaps more importantly (especially in >> environment >> >> > with many threads/processes), the efficiency benefits are even larger, >> >> > particularly in writemap mode, where there can be a 50-100x reduction >> in the >> >> > system CPU usage by using this patch. This brings windows performance >> with >> >> > sync'ed transactions in LMDB back into the range of "lightning" >> performance :). >> >> >> >> What is the performance difference between your patch using writemap, an=3D d >> just >> >> not using writemap in the first place? >> >> >> >> -- >> >> -- Howard Chu >> >> CTO, Symas Corp. http://www.symas.com >> >> Director, Highland Sun http://highlandsun.com/hyc/ >> >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> >> >> >> >> > --000000000000d8a73d0592d86418 Content-Type: text/html; charset=3D"UTF-8" Content-Transfer-Encoding: quoted-printable
Checking on this again, is this still a possibility for me= =3D rging into LMDB? This fix is still working great (improved performance) on =3D our systems.
Thanks,
Kris

On Mon, Jun 17, 2019 at 1:04= P=3D M Kris Zyp <kriszyp(a)gmail.com&g=3D t; wrote:
Is this still being considered/reviewed? Let me know if there ar= =3D e any other changes you would like me to make. This patch has continued to =3D yield significant and reliable performance improvements for us, and seems l=3D ike it would be nice for this to be available for other Windows users.
O= n Fr=3D i, May 3, 2019 at 3:52 PM Kris Zyp <kriszyp(a)gmail.com> wrote:

For the sake of putting this in the email thread (other code di=3D scussion in GitHub), here is the latest squashed commit of the proposed pat=3D ch (with the on-demand, retained overlapped array to reduce re-malloc and o=3D pening event handles): https://gith= =3D ub.com/kriszyp/node-lmdb/commit/726a9156662c703bf3d453aab75ee222072b990f

=3DC2=3DA0

=3D Thanks,
Kris

=3DC2=3DA0

From: Kris Zyp
Sent: April 30, 2019 12:43 PM
<= =3D b>To: Howard Chu= =3D ; openld= ap-i=3D ts(a)OpenLDAP.org
Subject: RE: (ITS#9017) Improving performance= =3D of commit sync in Windows

=3DC2=3DA= 0=3D

> What is the point of using writemap mod= =3D e if you still need to use WriteFile

> on every individual page?

=3DC2=3DA0

As I understood from the d= ocum=3D entation, and have observed, using writemap mode is faster (and uses less t=3D emporary memory) because it doesn=3DE2=3D80=3D99t require mallocs to allocate= pag=3D es (docs: =3DE2=3D80=3D9CThis is faster and uses fewer mallocs=3DE2=3D80=3D9D= ). To be c=3D lear though, LMDB is so incredibly fast and efficient, that in sync-mode, i=3D t takes enormous transactions before the time spent allocating and creating=3D the dirty pages with the updated b-tree is anywhere even remotely close to=3D the time it takes to wait for disk flushing, even with an SSD. But the mor=3D e pertinent question is efficiency, and measuring CPU cycles rather than ti=3D me spent (efficiency is more important than just time spent). When I ran my=3D tests this morning of 100 (sync) transactions with 100 puts per transactio=3D n, times varied quite a bit, but it seemed like running with writemap enabl=3D ed typically averages about 500ms of CPU and with writemap disabled it typi=3D cally averages around 600ms. Not a huge difference, but still definitely wo=3D rthwhile, I think.

=3DC2=3DA= 0=3D

Caveat emptor: Measuring LMDB performance wi= =3D th sync interactions on Windows is one of the most frustratingly erratic th=3D ings to measure. It is sunny outside right now, times could be different wh=3D en it starts raining later, but, this is what I saw this morning...<=3D u>

=3DC2=3DA0

> What is the performance difference between your patch using write=3D map, and just

> not using writem= =3D ap in the first place?

=3DC2= =3D =3DA0

Running 1000 sync transactions on 3G= B =3D db with a single put per transaction, without writemap map, without the pat=3D ch took about 60 seconds. And it took about 1 second with the patch with wr=3D itemap mode enabled! (there is no significant difference in sync times with=3D writemap enabled or disabled with the patch.) So the difference was huge i=3D n my test. And not only that, without the patch, the CPU usage was actually=3D _higher_ during that 60 seconds (close to 100% of a core) than duri=3D ng the execution with the patch for one second (close to 50%).=3DC2=3DA0 Anyw= ay=3D , there are certainly tests I have run where the differences are not as lar=3D ge (doing small commits on large dbs accentuates the differences), but the =3D patch always seems to win. It could also be that my particular configuratio=3D n causes bigger differences (on an SSD drive, and maybe a more fragmented f=3D ile?).

=3DC2=3DA0

=

Anyway, I added error handling for the malloc, and fixed= =3D /changed the other things you suggested. Be happy to make any other changes=3D you want. The updated patch is here:

https://github.com/kriszyp/node-= =3D lmdb/commit/25366dea9453749cf6637f43ec17b9b62094acde

<=3D p class=3D3D"MsoNormal">=3DC2=3DA0

= > OVERLAPPED* ov =3D3D malloc((pagecou= =3D nt - keep) * sizeof(OVERLAPPED));<=3D /span>

> Probably this o=3D ught to just be pre-allocated based on the maximum number of dirty pages a =3D txn allows.

=3DC2=3DA0

I wasn=3D =3DE2=3D80=3D99t sure I understood this comment. Are you suggesting we mal=3D loc(MDB_IDL_UM_MAX * sizeof(OVERLAPPED)) for each environment, and retain i=3D t for the life of the environment? I think that is 4MB, if my math is right=3D , which seems like a lot of memory to keep allocated (we usually have a lot=3D of open environments). If the goal is to reduce the number of mallocs, how=3D about we retain the OVERLAPPED array, and only free and re-malloc if the p=3D revious allocation wasn=3DE2=3D80=3D99t large enough? Then there isn=3DE2=3D8= 0=3D99t un=3D necessary allocation, and we only malloc when there is a bigger transaction=3D than any previous. I put this together in a separate commit, as I wasn=3DE2= =3D =3D80=3D99t sure if this what you wanted (can squash if you prefer): https://github.com/kriszyp/node-lmdb/commit/2= =3D fe68fb5269c843e2e789746a17a4b2adefaac40

=3DC2=3DA0

Thank you for t= he r=3D eview!

=3DC2=3DA0

Tha= nks,Kris

=3DC2=3DA0

=

F= =3D rom: Howard Chu<= /a><=3D br>Sent: April 30, 2019 7:12 AM
To: kriszyp(a)gmail.com; openldap-its(a)OpenLDAP.orgSubject: Re: (ITS#9017) Improving performance of commit sync in Wi=3D ndows

=3DC2=3DA0

kriszyp(a)gmail.com wrote:

= &g=3D t; Full_Name: Kristopher William Zyp

> Version: LMDB 0.9.23

> OS= =3D : Windows

> URL: https://github.com/kriszyp/node-lmdb/commit/7ff525= =3D ae57684a163d32af74a0ab9332b7fc4ce9

> Submission from: (NULL) (71.199.6.148)

>

> =

> We have seen very poor performance on = =3D the sync of commits on large databases in

> Windows. On databases with 2GB of data, in writemap mode, the s=3D ync of even small

> commits is c= =3D onsistently well over 100ms (without writemap it is faster, but

> still slow). It is expected that a sync s= =3D hould take some time while waiting for

> disk confirmation of the writes, but more concerning is that these=3D sync

> operations (in writemap = =3D mode) are instead dominated by nearly 100% system CPU

> utilization, so operations that requires sub-millis= =3D econd b-tree update

> operations= =3D are then dominated by very large amounts of system CPU cycles during

> the sync phase.

>

> I= t=3D hink that the fundamental problem is that FlushViewOfFile seems to be an O(=3D n)

> operation where n is the si= =3D ze of the file (or map). I presume that Windows is

> scanning the entire map/file for dirty pages to flush,= =3D I'm guessing because it

> d= =3D oesn't have an internal index of all the dirty pages for every file/map=3D -view in

> the OS disk cache. Th= =3D erefore, the turns into an extremely expensive, CPU-bound

=3D

> operation to find the dirty pages for (large fi= =3D le) and initiate their writes,

>= =3D which, of course, is contrary to the whole goal of a scalable database sys=3D tem.

> And FlushFileBuffers is a= =3D lso relatively slow as well. We have attempted to batch

> as many operations into single transaction as pos= =3D sible, but this is still a very

>= =3D ; large overhead.

>

> The Windows docs for FlushFileBuffers its= =3D elf warns about the inefficiencies of

> this function (https://= =3D docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-flushfilebu=3D ffers).

> Which also points = =3D to the solution: it is much faster to write out the dirty

=3D

> pages with WriteFile through a sync file handle= =3D (FILE_FLAG_WRITE_THROUGH).

>

> The associated patch<= =3D /u>

> (https://github.com/kriszyp/node-lmdb/commit/7ff525ae57684a163d32af74a0ab93=3D 32b7fc4ce9)

> is my attempt = =3D at implementing this solution, for Windows. Fortunately, with the=3D

> design of LMDB, this is relatively stra= =3D ightforward. LMDB already supports

= =3D > writing out dirty pages with WriteFile calls. I added a write-through =3D handle for

> sending these write= =3D s directly to disk. I then made that file-handle

> overlapped/asynchronously, so all the writes for a comm= =3D it could be started in

> overlap= =3D mode, and (at least theoretically) transfer in parallel to the drive and

> then used GetOverlappedResult t= =3D o wait for the completion. So basically

> mdb_page_flush becomes the sync. I extended the writing of dirty =3D pages through

> WriteFile to wri= =3D temap mode as well (for writing meta too), so that WriteFile<=3D /p>

> with write-through can be used to flush the = =3D data without ever needing to call

&= =3D gt; FlushViewOfFile or FlushFileBuffers. I also implemented support for wri=3D te

> gathering in writemap mode = =3D where contiguous file positions infers contiguous

> memory (by tracking the starting position with wdp and = =3D writing contiguous pages

> in si= =3D ngle operations). Sorting of the dirty list is maintained even in writemap<=3D u>

> mode for this purpose.<= =3D u>

=3DC2=3DA0

What is the point of using writemap mode if you still need to use Writ=3D eFile

on every individual page?<= =3D /u>

=3DC2=3DA0

> The performance benefits of this patch, in my testing, are co=3D nsiderable. Writing

> out/syncin= =3D g transactions is typically over 5x faster in writemap mode, and 2x<=3D u>

> faster in standard mode. And perhaps = =3D more importantly (especially in environment

> with many threads/processes), the efficiency benefits are eve=3D n larger,

> particularly in writ= =3D emap mode, where there can be a 50-100x reduction in the

<=3D p class=3D3D"MsoNormal">> system CPU usage by using this patch. This bring= =3D s windows performance with

> syn= =3D c'ed transactions in LMDB back into the range of "lightning" =3D performance :).

=3DC2=3DA0

What is the performance difference between your= =3D patch using writemap, and just

not= =3D using writemap in the first place?

=3DC2=3DA0

--

=3DC2=3DA0=3DC2=3DA0-- Howard Chu

=3DC2=3DA0 CTO, Symas Corp.=3DC2=3DA0=3DC2=3DA0=3DC2=3DA0=3DC2=3DA0= =3DC2=3DA0=3DC2=3DA0=3DC2=3DA0=3D =3DC2=3DA0=3DC2=3DA0=3DC2=3DA0 http:=3D //www.symas.com

=3DC2=3DA0 Dire= ctor=3D , Highland Sun=3DC2=3DA0=3DC2=3DA0=3DC2=3DA0=3DC2=3DA0 http://highlandsun.com/hyc/

=3DC2=3DA0 Chief Architect, OpenLDAP=3DC2=3DA0 http://www.openldap.org/proje= =3D ct/

=3DC2=3DA0

=3DC2=3DA0

--000000000000d8a73d0592d86418-- --===============7714618235955763312==-- From kloczko.tomasz@gmail.com Fri Sep 20 05:15:00 2019 From: kloczko.tomasz@gmail.com To: openldap-bugs@openldap.org Subject: (ITS#9085) Test suite is failing Date: Fri, 20 Sep 2019 05:14:59 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8773064531929449819==" --===============8773064531929449819== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Tomasz Kloczko Version: 2.4.48 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.25.145.71) + /usr/bin/make -O -j48 V=1 VERBOSE=1 check -j1 cd tests; /usr/bin/make test make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/openldap-2.4.48/tests' make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/openldap-2.4.48/tests' Initiating LDAP tests for BDB... Running ./scripts/all for bdb... >>>>> Executing all LDAP tests for bdb >>>>> Starting test000-rootdse for bdb... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Using ldapsearch to retrieve the cn=Subschema... Using ldapsearch to retrieve the cn=Monitor... dn: objectClass: top objectClass: OpenLDAProotDSE structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: o=OpenLDAP Project,l=Internet monitorContext: cn=Monitor supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.3.6.1.1.22 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 supportedSASLMechanisms: GSS-SPNEGO supportedSASLMechanisms: GSSAPI vendorName: The OpenLDAP Project entryDN: subschemaSubentry: cn=Subschema dn: cn=Subschema objectClass: top objectClass: subentry objectClass: subschema objectClass: extensibleObject cn: Subschema dn: cn=Monitor objectClass: monitorServer cn: Monitor description: This subtree contains monitoring/managing objects. description: This object contains information about this server. description: Most of the information is held in operational attributes, which must be explicitly requested. monitoredInfo: OpenLDAP: slapd 2.4.48 (Sep 20 2019 05:49:42) ./scripts/test000-rootdse: line 68: 1709599 Hangup $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 >>>>> Test succeeded >>>>> test000-rootdse completed OK for bdb. >>>>> Starting test001-slapadd for bdb... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve all the entries... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ldapsearch failed (32)! ./scripts/test001-slapadd: line 55: kill: (1709740) - No such process >>>>> test001-slapadd failed for bdb (exit 32) make[2]: *** [Makefile:294: bdb-yes] Error 32 make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/openldap-2.4.48/tests' make[1]: *** [Makefile:279: test] Error 2 make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/openldap-2.4.48/tests' make: *** [Makefile:291: test] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.aVXfhD (%check) --===============8773064531929449819==-- From ryan@openldap.org Fri Sep 20 23:41:10 2019 From: ryan@openldap.org To: openldap-bugs@openldap.org Subject: (ITS#9086) Add debug logging for GnuTLS configuration errors Date: Fri, 20 Sep 2019 23:41:09 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7807204212610367202==" --===============7807204212610367202== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Ryan Tandy Version: master OS: Debian 10/buster URL: https://github.com/openldap/openldap/compare/master...rtandy:gnutls-logg= ing.patch Submission from: (NULL) (70.66.128.207) Submitted by: ryan This patch adds debug logging for common GnuTLS configuration errors. It shou= ld help with troubleshooting issues such as slapd failing to start due to incorr= ect paths or permissions, or client TLS connections failing if the CA file can't = be read. Posting here for review. I'll upload this to Debian as well and try to get so= me feedback from users. --=20 The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Ryan Tandy . I have not assigned rights and/or interest in this work to any party. I, Ryan Tandy, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. --===============7807204212610367202==-- From zagarc@oclc.org Sat Sep 21 05:30:31 2019 From: zagarc@oclc.org To: openldap-bugs@openldap.org Subject: (ITS#9087) Minor patch for OpenLDAP use of windres when cross-compiling Date: Sat, 21 Sep 2019 05:30:30 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5507999586951230607==" --===============5507999586951230607== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Chris Zagar Version: 2.4.48 OS: URL: ftp://ftp.openldap.org/incoming/chris-zagar-190920.patch Submission from: (NULL) (68.98.212.84) The file libraries/liblutil/Makefile.in is hard-coded to call windres when compiling the resources for slapdmsg.rc. This causes a problem when building using a cross-compiler. Please consider using $(RC) instead to allow the complete name for windres to be specified. Thanks! --===============5507999586951230607==-- From aixtools@felt.demon.nl Sun Sep 22 19:55:32 2019 From: aixtools@felt.demon.nl To: openldap-bugs@openldap.org Subject: Re: (ITS#9084) Build issue when slaps is not included Date: Sun, 22 Sep 2019 19:55:30 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7322137925935610858==" --===============7322137925935610858== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gJgclWXWHobp9Jm8TzWLGKLDSFUeHbtMu Content-Type: multipart/mixed; boundary="ftnTy1YEAYlvdoLUzJ64mQJw2X9PqF44q"; protected-headers="v1" From: Michael To: openldap-its(a)OpenLDAP.org Cc: aixtools(a)felt.demon.nl Message-ID: Subject: Re: (ITS#9084) Build issue when slaps is not included --ftnTy1YEAYlvdoLUzJ64mQJw2X9PqF44q Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Update. After uninstall openldap-2.4.46 and openldap-2.4.48 build fine. --ftnTy1YEAYlvdoLUzJ64mQJw2X9PqF44q-- --gJgclWXWHobp9Jm8TzWLGKLDSFUeHbtMu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE4MC4YtVFAh73PAYk4vWDeFkjp+AFAl2H0lgACgkQ4vWDeFkj p+CPrQf9Encsrt1sAI2T7VmR5MenhrXDQrZFeiMPjx7aILExkvu68yOSaM195nii yci/MQJWY982I1tA7EFuXKlN0NXM0LKTMK1FpjwrgkITQK6ov2KSPaLV3B9JoQSw MEQyCXhTIiN6ahAUWUw+pVqXk4o313mqqyfmQWoVrUxhgqiZlGFvyStSL+Fp5P+7 7YwxyfvhmEcQsolyqB/WLkw0T86jqPRgk/S8IV69NFiXd3A26bfVyA1sjrlWyRN4 5MRXg/btAimfvH+xlpAebY49GZ1MGt+AdZUu4qr1i2FlJi67Y2Ron/cq5EmwZeYu kqiD1Z5MOd3Ovfxz1UvWuMQ7EbvqwQ== =fAQW -----END PGP SIGNATURE----- --gJgclWXWHobp9Jm8TzWLGKLDSFUeHbtMu-- --===============7322137925935610858==-- From jrajalakshmi@juniper.net Mon Sep 23 09:22:47 2019 From: jrajalakshmi@juniper.net To: openldap-bugs@openldap.org Subject: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44 Date: Mon, 23 Sep 2019 09:22:45 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2437819779658601459==" --===============2437819779658601459== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Rajalakshmi Version: 2.4.44 OS: RHEL 7.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (116.197.184.12) (1) What problem/issue/behavior are you having trouble with? What do you expe= ct to see? Using OpenLDAP version 2.4.44 we are not seeing Concurrency whereas in OpenLD= AP Version 2.4.23 we are seeing Concurrent LDAP Requests. In our product OpenLDAP 2.4.23 was previously used and the concurrent request for search using the API ' ldap_search_ext_s() ' was working as expected and = our product scalability was better.=20 We have recently upgraded LDAP to OpenLDAP 2.4.44. But with this version, the api 'ldap_search_ext_s()' does not seem to work as expected, i.e concurrent requests handling is not happening.=20 (2) Where are you experiencing the behavior? What environment?=20 In RHEL 7.6.=20 If we sent 10 Concurrent Requests each request is processed one by one. Most = of the threads are waiting in ldap_search_req.=20 (3) When does the behavior occur? Frequently? Repeatedly? At certain times?=20 Repeatedly.=20 (4) What information can you provide around timeframes and the business impac= t? There is a release impact due to the open issue. Hence seeking a reply at the earliest. In our product, the API =C2=91ldap_search_req =C2=91 is used and this will b= e called by multiple threads at a time. On the process startup of the application, bind to ldap Server is created. status =3D ldap_search_ext_s(m_ld, pszBase, nScope, pszFilter, ppszAttrs2, nAttrsOnly, NULL, NULL, pTimeout2, LDAP_NO_LIMIT, ppResult);=20 (5) Whether we need to do anything on that? Request for a solution at the earliest, is there any alternative api to suppo= rt concurrency request Is there any open defect in the 'OpenLDAP 2.4.44' related to the synchronous handling method ' ldap_search_ext_s() '.=20 --===============2437819779658601459==-- From ondra@mistotebe.net Mon Sep 23 15:08:44 2019 From: ondra@mistotebe.net To: openldap-bugs@openldap.org Subject: Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements Date: Mon, 23 Sep 2019 15:08:42 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2164484606252671545==" --===============2164484606252671545== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Fri, Sep 13, 2019 at 11:57:14AM -0400, Greg Veldman wrote: > On Mon, Sep 09, 2019 at 04:01:59PM +0200, Ond??ej Kuzn??k wrote: >> I mean the ber_str2bv(,,1,) in both new functions. Not sure which code >> you think would overwrite parts of the buffer? ber_str2bv(,,0,) never >> touches it, manually initialising the berval certainly wouldn't either. >> And then you have fewer memory regions to scrub. >> >> Since you already know the length, you can also pass it in so ber_str2bv >> can skip its strlen() check (and since anything can be in a {PLAINTEXT} >> password, you're now embedded NUL safe). > > Ah, OK, I didn't realize that would be NUL safe. I made an > updated patch with that change[1]. > >> I think I mentioned this before as something worth changing: rather >> than call time(0L), you can use op->o_time which is stable and the >> closest you can get to the time the operation was received. > > Yes, sorry I did see that before just forgot to do it. It's > also included in the latest update[1]. Hi Greg, thanks for both, I should merge that soon. On a side note, any ideas how to deal with ppolicy's pwdHistory here so it can reject changing the password to an old one? AFAIK using these schemas will prevent slap_passwd_check() from working and there isn't an obvious way to proceed. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP --===============2164484606252671545==-- From quanah@symas.com Mon Sep 23 15:42:42 2019 From: quanah@symas.com To: openldap-bugs@openldap.org Subject: Re: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44 Date: Mon, 23 Sep 2019 15:42:40 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6854664078809119888==" --===============6854664078809119888== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Monday, September 23, 2019 10:22 AM +0000 jrajalakshmi(a)juniper.net wrote: > Full_Name: Rajalakshmi > Version: 2.4.44 > OS: RHEL 7.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (116.197.184.12) Hello, RedHat makes changes to OpenLDAP that are not reviewed by the OpenLDAP project. I would advise using an unmodified version of the current release of OpenLDAP to confirm whether or not this issue is in OpenLDAP itself or is caused by a change made by RedHat. You can use the packages from the LTB project for testing: Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: --===============6854664078809119888==-- From marc.pape@telekom.de Mon Sep 23 16:05:16 2019 From: marc.pape@telekom.de To: openldap-bugs@openldap.org Subject: (ITS#9089) OpenLDAP sends searchResDone success to early Date: Mon, 23 Sep 2019 16:05:15 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5504481098284932798==" --===============5504481098284932798== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Full_Name: Marc Pape Version: 2.4.48 OS: Debian 9 Kernel 4.9 URL: https://qnap.testlab-lpz.de/share.cgi?ssid=3D0NbcOIY Submission from: (NULL) (80.153.108.120) Hello dear OpenLDAP-Team,=20 we have a problem with the OpenLDAP Server which we operate as LDAP Proxy. In our deployment the OpenLDAP Proxy is for synchronization and authentication between a Cisco Callmanager 12.5 and two Microsoft ActiveDirectories in Versi= on 2008R2. The Cisco Callmanager can only handle one Directory, but in some customer deployments exist two different directories. For that szenario we installed a Debian 9 server with OpenLDAP 2.4.48. The syncronization and authentication runs so far until one directory has more than 50 user. The Cisco Callmanager uses a SearchControlValue with size 50. By syncronize t= he Callmanager against one Microsoft AD directly the Microsoft Server will send responses with 50 user and in the end after all responses a unbindRequest. In our lab deployment we tested the Cisco Callmanager against a Microsoft AD with over 2000 enduser successfully.=20 By implementing the OpenLDAP Server between the Cisco Callmanager and the Microsoft AD the OpenLDAP sends the unbindRequest directly after the first response with the first 50 user. All other requests and over 1950 user don't syncronize to the Cisco Callmanager. Is there a possible solution to send that unbindRequest after all responses a= nd all users from the Microsoft AD were send to the Callmanager in that 50 users steps / responses?=20 I've provided the configuration file of the OpenLDAP Server and a pcap file f= rom a syncronizationrun in the upload below. The pcap file shows the following IPs and Server: 10.34.100.2 Cisco Callmanager 10.34.100.110 Debian 9 with OpenLDAP as LDAP Proxy 10.34.100.16 Microsoft AD #1 10.34.100.17 Microsoft AD #2 Kind regards Marc Pape --===============5504481098284932798==-- From ondra@mistotebe.net Mon Sep 23 16:35:36 2019 From: ondra@mistotebe.net To: openldap-bugs@openldap.org Subject: Re: (ITS#9081) Memory leak in ldap_initialize/ldap_unbind Date: Mon, 23 Sep 2019 16:35:34 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0437327747187385485==" --===============0437327747187385485== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, Sep 16, 2019 at 11:53:58AM +0000, jengelh(a)inai.de wrote: > » cat x.c > #define LDAP_DEPRECATED 1 > #include > int main() > { > LDAP *ld; > ldap_initialize(&ld, "ldapi:///"); > ldap_unbind(ld); > } > > unbind.c: > 123 for ( lm = ld->ld_responses; lm != NULL; lm = next ) { > 128 if ( ld->ld_abandoned != NULL ) { > 132 LDAP_MUTEX_UNLOCK( &ld->ld_res_mutex ); > 136 ber_int_sb_destroy( ld->ld_sb ); > > Should this probably be LBER_FREE rather than ber_int_sb_destroy? Hi Jan, thanks for the report. I think it should be doing both as _destroy() functions do not seem to be designed to free the pointer, only all its local structures. A patch has now been pushed to master. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP --===============0437327747187385485==-- From gv@members.scinet.supercomputing.org Mon Sep 23 19:59:43 2019 From: gv@members.scinet.supercomputing.org To: openldap-bugs@openldap.org Subject: Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements Date: Mon, 23 Sep 2019 19:59:42 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2231797925194488615==" --===============2231797925194488615== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, Sep 23, 2019 at 05:08:19PM +0200, Ond??ej Kuzn??k wrote: > Hi Greg, > thanks for both, I should merge that soon. Wonderful, thank you. :-) > On a side note, any ideas how to deal with ppolicy's pwdHistory here so > it can reject changing the password to an old one? AFAIK using these > schemas will prevent slap_passwd_check() from working and there isn't an > obvious way to proceed. I'm not familiar enough with how the ppolicy overlay hooks in to say ATM. I'll poke at this a bit and see if anything comes to mind... If the user is using the exop to set the password we do have access to the plaintext reusable password stripped of the OTP seed in the new hash_totp_and_pw() function, so if there's something better than calling lutil_passwd_hash() directly to restore this functionality I'd be perfectly fine with that change. Though I'm guessing it won't be quite that easy. ;-) -- Greg Veldman --===============2231797925194488615==-- From ondra@mistotebe.net Tue Sep 24 09:33:58 2019 From: ondra@mistotebe.net To: openldap-bugs@openldap.org Subject: Re: (ITS#9018) dynlist don't close connection Date: Tue, 24 Sep 2019 09:33:57 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4571974809505970888==" --===============4571974809505970888== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Thu, May 02, 2019 at 10:40:21AM +0000, i.harbuz(a)velcom.by wrote: > Any ldapsearch commands work fine if request doesn't hit into dynlist. > If request hit in dynlist then it output information and hanged up. Hello Ihar, it seems you have configured dynlist as a global overlay. I would note that not many overlays fully support this type of configuration at the moment and might not function correctly. It is possible that dynlist will do just fine for your use case. Make sure you test with a simpler scenario as well (where databases are not subordinate and/or without back-meta in the picture) to see if there might be interaction between them. Do let us know if you decide to investigate further and find a minimal use case where things start to break. Also a full test script that sets up a self-contained environment and reliably triggers the issue would greatly improve our chances of diagnosing it correctly. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP --===============4571974809505970888==-- From ondra@mistotebe.net Tue Sep 24 10:24:40 2019 From: ondra@mistotebe.net To: openldap-bugs@openldap.org Subject: Re: (ITS#8964) ldap proxy segmentation fault Date: Tue, 24 Sep 2019 10:24:38 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2989880942727637739==" --===============2989880942727637739== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 29, 2019 at 03:10:02PM +0000, praveen.adini(a)fireeye.com wrote: > I'm trying to setup a openldap proxy wherein the proxy denies any search > requests for uid=3Droot. When i tried using the rwm overlay to stop the > operation(#), i'm getting a segmentation fault although i see the unwilling= to > perform operation 53 message being printed. here is the snippet of the conf= that > i'm using. >=20 > overlay rwm > rwm-rewriteEngine on > rwm-rewriteContext searchFilter > rwm-rewriteRule "(.*)(uid=3Droot)(.*)" "$1$2$3" "#" Hi Praveen, can you post a self-contained test script that triggers this issue? On its own, the above works as advertised, so maybe other overlays are interfering? There have been (probably still are) issues when combining rwm with some other overlays. Thanks, --=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 --===============2989880942727637739==-- From ondra@mistotebe.net Tue Sep 24 10:41:01 2019 From: ondra@mistotebe.net To: openldap-bugs@openldap.org Subject: Re: (ITS#8923) compare op with dynlist returns wrong code when requested DN is in scope but doesn't exist Date: Tue, 24 Sep 2019 10:40:59 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2062862473292899016==" --===============2062862473292899016== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 03, 2018 at 08:25:44PM +0000, quanah(a)openldap.org wrote: > In a situation where a dynamic group has been created and a compare operati= on is > run with a DN that doesn't exist but is within the scope of the dynamic gro= up > URI, the ldapcompare operation will incorrectly return an error 80 instead = of > error 5 (compare FALSE). >=20 > For example, if I have: >=20 > dn: cn=3Dplanning,ou=3DGroups,dc=3Dexample,dc=3Dcom > objectClass: groupOfURLs > cn: planning > memberURL: ldap:///ou=3Dplanning,dc=3Dexample,dc=3Dcom??sub?(objectClass=3D= inetorgpers > on) >=20 > and I do an ldapcompare with: >=20 > ldapcompare -x -H ldap://anvil2.rb.symas.net -D dc=3Dexample,dc=3Dcom -w se= cret > cn=3Dplanning,ou=3DGroups,dc=3Dexample,dc=3Dcom "member:cn=3DRamakant > Wolow,ou=3DPlanning,dc=3Dexample,dc=3Dcom" >=20 > (i.e., this entry doesn't exist in the DB), I get: >=20 > Compare Result: Other (e.g., implementation specific) error (80) > UNDEFINED >=20 > This appears to be due to the fact that in this scenario, slapd attempts to= find > the DN in the underlying DB and it doesn't exist, so an err=3D32 is returne= d back. > This is incorrectly interpreted as an unknown error, thus the err=3D80 res= ult.=20 > Instead it should be treated as "not a member of the group". I thought that exact scenario was being tested here? And that one passes. https://www.openldap.org/devel/gitweb.cgi?p=3Dopenldap.git;a=3Dblob;f=3Dtests= /scripts/test044-dynlist;h=3D86885cd1150f765d4e42695947fcb6f63965a073;hb=3Dre= fs/heads/master#l471 --=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 --===============2062862473292899016==-- From I.Harbuz@A1.by Tue Sep 24 10:59:54 2019 From: I.Harbuz@A1.by To: openldap-bugs@openldap.org Subject: Re: (ITS#9018) dynlist don't close connection Date: Tue, 24 Sep 2019 10:59:53 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7147932041951590758==" --===============7147932041951590758== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit R29vZCBkYXksIE9uZMWZZWouDQoNCkkgaGF2ZSBjaGFuZ2VkIGJhY2stbWV0YSB0byB0aGUgYmFj ay1sZGFwLCBhbmQgaXQgcmVzb2x2ZWQgdGhpcyBwcm9ibGVtLg0KDQpCZXN0IHJlZ2FyZHMsDQpJ aGFyIEhhcmJ1eg0KPGh0dHA6Ly9pbnRyYW5ldC9TaXRlUGFnZXMvZW1wbG95ZWUuYXNweD9kZXBf aWQ9NTE1XzExOTMvNy8yPg0KU3lzdGVtIFNvbHV0aW9ucyBEZXZlbG9wbWVudCBhbmQgT3BlcmF0 aW9ucyBHcm91cA0KSVQgc29sdXRpb25zIERldmVsb3BtZW50IGFuZCBPcGVyYXRpb25zIERlcGFy dG1lbnQNCkNsb3VkIGFuZCBJQ1QgaW5mcmFzdHJ1Y3R1cmUgRGl2aXNpb24NCg0KVW5pdGFyeSBl bnRlcnByaXNlIEExDQpBMS1jZW50ZXINCnVsLiBJbnRlcm5hdHNpb25hbG5heWEsIDM2LTINCjIy MDAzMCwgTWluc2ssIEJlbGFydXMNClRlbC4gKzM3NSA0NCA3MTAtMTEtNzQNCnd3dy5BMS5ieTxo dHRwOi8vd3d3LnZlbGNvbS5ieS8+DQp3d3cuQTEuZ3JvdXA8aHR0cDovL3d3dy5hMS5ncm91cC8+ DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K0J7RgjogT25kxZllaiBL dXpuw61rIDxvbmRyYUBtaXN0b3RlYmUubmV0Pg0K0J7RgtC/0YDQsNCy0LvQtdC90L46IDI0INGB 0LXQvdGC0Y/QsdGA0Y8gMjAxOSDQsy4gMTI6MzMNCtCa0L7QvNGDOiBJaGFyIEhhcmJ1eg0K0JrQ vtC/0LjRjzogb3BlbmxkYXAtaXRzQE9wZW5MREFQLm9yZw0K0KLQtdC80LA6IFJlOiAoSVRTIzkw MTgpIGR5bmxpc3QgZG9uJ3QgY2xvc2UgY29ubmVjdGlvbg0KDQpPbiBUaHUsIE1heSAwMiwgMjAx OSBhdCAxMDo0MDoyMUFNICswMDAwLCBpLmhhcmJ1ekB2ZWxjb20uYnkgd3JvdGU6DQo+IEFueSBs ZGFwc2VhcmNoIGNvbW1hbmRzIHdvcmsgZmluZSBpZiByZXF1ZXN0IGRvZXNuJ3QgaGl0IGludG8g ZHlubGlzdC4NCj4gSWYgcmVxdWVzdCBoaXQgaW4gZHlubGlzdCB0aGVuIGl0IG91dHB1dCBpbmZv cm1hdGlvbiBhbmQgaGFuZ2VkIHVwLg0KDQpIZWxsbyBJaGFyLA0KaXQgc2VlbXMgeW91IGhhdmUg Y29uZmlndXJlZCBkeW5saXN0IGFzIGEgZ2xvYmFsIG92ZXJsYXkuIEkgd291bGQgbm90ZQ0KdGhh dCBub3QgbWFueSBvdmVybGF5cyBmdWxseSBzdXBwb3J0IHRoaXMgdHlwZSBvZiBjb25maWd1cmF0 aW9uIGF0IHRoZQ0KbW9tZW50IGFuZCBtaWdodCBub3QgZnVuY3Rpb24gY29ycmVjdGx5Lg0KDQpJ dCBpcyBwb3NzaWJsZSB0aGF0IGR5bmxpc3Qgd2lsbCBkbyBqdXN0IGZpbmUgZm9yIHlvdXIgdXNl IGNhc2UuIE1ha2UNCnN1cmUgeW91IHRlc3Qgd2l0aCBhIHNpbXBsZXIgc2NlbmFyaW8gYXMgd2Vs bCAod2hlcmUgZGF0YWJhc2VzIGFyZSBub3QNCnN1Ym9yZGluYXRlIGFuZC9vciB3aXRob3V0IGJh Y2stbWV0YSBpbiB0aGUgcGljdHVyZSkgdG8gc2VlIGlmIHRoZXJlDQptaWdodCBiZSBpbnRlcmFj dGlvbiBiZXR3ZWVuIHRoZW0uDQoNCkRvIGxldCB1cyBrbm93IGlmIHlvdSBkZWNpZGUgdG8gaW52 ZXN0aWdhdGUgZnVydGhlciBhbmQgZmluZCBhIG1pbmltYWwNCnVzZSBjYXNlIHdoZXJlIHRoaW5n cyBzdGFydCB0byBicmVhay4gQWxzbyBhIGZ1bGwgdGVzdCBzY3JpcHQgdGhhdCBzZXRzDQp1cCBh IHNlbGYtY29udGFpbmVkIGVudmlyb25tZW50IGFuZCByZWxpYWJseSB0cmlnZ2VycyB0aGUgaXNz dWUgd291bGQNCmdyZWF0bHkgaW1wcm92ZSBvdXIgY2hhbmNlcyBvZiBkaWFnbm9zaW5nIGl0IGNv cnJlY3RseS4NCg0KVGhhbmtzLA0KDQotLQ0KT25kxZllaiBLdXpuw61rDQpTZW5pb3IgU29mdHdh cmUgRW5naW5lZXINClN5bWFzIENvcnBvcmF0aW9uICAgICAgICAgICAgICAgICAgICAgICBodHRw Oi8vd3d3LnN5bWFzLmNvbQ0KUGFja2FnZWQsIGNlcnRpZmllZCwgYW5kIHN1cHBvcnRlZCBMREFQ IHNvbHV0aW9ucyBwb3dlcmVkIGJ5IE9wZW5MREFQDQo8cCBzdHlsZT0iZm9udDogMTJweCBhcmlh bCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYmEoMTAyLCAxMDIsIDEwMiwgMSk7Ij4gVGhpcyBlLW1h aWwgYW5kIGFueSBhdHRhY2htZW50cyB0byBpdCBtYXkgY29udGFpbiBDT05GSURFTlRJQUwgT1Ig UFJPUFJJRVRBUlkgSU5GT1JNQVRJT04gb2YgQTEgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgcmVj aXBpZW50LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBieSBtaXN0YWtlIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSB0ZWxlcGhvbmUgb3IgcmVwbHkgdGhp cyBlLW1haWwgYW5kIERFTEVURSB0aGUgb3JpZ2luYWwgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1l bnRzIHRvIGl0IHdpdGhvdXQgbWFraW5nIGEgQ09QWS4gWW91IGFyZSBoZXJlYnkgbm90aWZpZWQg dGhhdCBhbnkgdW5hdXRob3JpemVkIHJldmlldywgdXNlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlv biBvZiB0aGlzIG1lc3NhZ2UgYW5kIGF0dGFjaG1lbnRzIHRvIGl0IGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuIFRoaXMgZS1tYWlsIGFuZCBhdHRhY2htZW50cyB0byBpdCBtYXkgbm90IGJlIHJldHJh bnNtaXR0ZWQgdG8gYW55IHBhcnR5IG91dHNpZGUgb2YgdGhlIHJlY2lwaWVudCdzIG9yZ2FuaXph dGlvbiB3aXRob3V0IHRoZSBwcmlvciB3cml0dGVuIGNvbnNlbnQgb2YgdGhlIHNlbmRlci4NCjwv cD4NCg== --===============7147932041951590758==-- From quanah@symas.com Thu Sep 26 13:21:51 2019 From: quanah@symas.com To: openldap-bugs@openldap.org Subject: RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44 Date: Thu, 26 Sep 2019 13:21:49 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7011795053213036896==" --===============7011795053213036896== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Thursday, September 26, 2019 2:19 PM +0000 Rajalakshmi Jayaraman wrote: > > > Hi, > > Thanks for sharing the inputs. We have tried with the unmodified release > of OpenLDAP that was suggested. From the pcap, we have noticed the LDAP > search requests are sequential. (pl. find attached the pcap) for > reference Please put your pcap file on the FTP server rather than sending it via the ITS system. Then respond to the ITS with a link to the file. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: --===============7011795053213036896==-- From jrajalakshmi@juniper.net Thu Sep 26 14:12:05 2019 From: jrajalakshmi@juniper.net To: openldap-bugs@openldap.org Subject: RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44 Date: Thu, 26 Sep 2019 14:12:02 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8864210669900816422==" --===============8864210669900816422== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable --_000_CH2PR05MB69514726BCB360A68DA761D2DF860CH2PR05MB6951namp_ Content-Type: text/plain; charset=3D"us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The FTP "ftp://ftp.openldap.org/incoming/" is not working. Hence pasted the=3D pcap details, hope this helps As you can see, 9 requests from a single AAA server to LDAP server were ini=3D tiated at the same time (concurrent request). But from the LDAP, our unders=3D tanding is the 'searchRequest' is sequential..after every 'searchRequest' t=3D here is "searchResDone" before handling the subsequent request "searchReque=3D st' No Time Source Destination Protocol Length =3D Info 1 0.000000000 10.212.10.218 10.212.10.120 RADIUS 115 Access=3D -Request(1) (id=3D3D2, l=3D3D71) 2 0.000359909 10.212.10.218 10.212.10.120 RADIUS 115 Access=3D -Request(1) (id=3D3D7, l=3D3D71) 3 0.000512919 10.212.10.218 10.212.10.120 RADIUS 115 Access=3D -Request(1) (id=3D3D8, l=3D3D71) 4 0.001219680 10.212.10.218 10.212.10.120 RADIUS 115 Access=3D -Request(1) (id=3D3D9, l=3D3D71) 5 0.001228416 10.212.10.218 10.212.10.120 RADIUS 115 Access=3D -Request(1) (id=3D3D10, l=3D3D71) 6 0.001359636 10.212.10.218 10.212.10.120 RADIUS 115 Access=3D -Request(1) (id=3D3D11, l=3D3D71) 7 0.002419581 10.212.10.218 10.212.10.120 RADIUS 115 Access=3D -Request(1) (id=3D3D5, l=3D3D71) 8 0.002432108 10.212.10.218 10.212.10.120 RADIUS 115 Access=3D -Request(1) (id=3D3D6, l=3D3D71) 9 0.002435112 10.212.10.218 10.212.10.120 RADIUS 115 Access=3D -Request(1) (id=3D3D4, l=3D3D71) 10 0.002511929 10.212.10.120 10.212.10.220 LDAP 124 searchReq=3D uest(52) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree 11 0.002637421 10.212.10.218 10.212.10.120 RADIUS 115 Access=3D -Request(1) (id=3D3D3, l=3D3D71) 12 0.004109740 10.212.10.220 10.212.10.120 LDAP 378 searchRes=3D Entry(52) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom" 13 0.004146613 10.212.10.220 10.212.10.120 LDAP 82 searchResD=3D one(52) success [2 results] 14 0.004348866 10.212.10.120 10.212.10.220 LDAP 124 searchReq=3D uest(55) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree 15 0.004781891 10.212.10.120 10.212.10.218 RADIUS 120 Access=3D -Accept(2) (id=3D3D7, l=3D3D76) 16 0.004952000 10.212.10.220 10.212.10.120 LDAP 378 searchRes=3D Entry(55) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom" 17 0.004962643 10.212.10.220 10.212.10.120 LDAP 82 searchResD=3D one(55) success [0 results] 18 0.005087014 10.212.10.120 10.212.10.220 LDAP 124 searchReq=3D uest(57) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree 19 0.005153658 10.212.10.120 10.212.10.218 RADIUS 120 Access=3D -Accept(2) (id=3D3D8, l=3D3D76) 20 0.005698130 10.212.10.220 10.212.10.120 LDAP 378 searchRes=3D Entry(57) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom" 21 0.005723767 10.212.10.220 10.212.10.120 LDAP 82 searchResD=3D one(57) success [1 result] 22 0.005915500 10.212.10.120 10.212.10.218 RADIUS 120 Access=3D -Accept(2) (id=3D3D5, l=3D3D76) 23 0.006033219 10.212.10.120 10.212.10.220 LDAP 124 searchReq=3D uest(59) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree 24 0.006566138 10.212.10.220 10.212.10.120 LDAP 378 searchRes=3D Entry(59) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom" 25 0.006578873 10.212.10.220 10.212.10.120 LDAP 82 searchResD=3D one(59) success [1 result] 26 0.006740243 10.212.10.120 10.212.10.218 RADIUS 120 Access=3D -Accept(2) (id=3D3D6, l=3D3D76) 27 0.006831740 10.212.10.120 10.212.10.220 LDAP 124 searchReq=3D uest(61) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree 28 0.007507468 10.212.10.220 10.212.10.120 LDAP 378 searchRes=3D Entry(61) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom" 29 0.007519658 10.212.10.220 10.212.10.120 LDAP 82 searchResD=3D one(61) success [1 result] 30 0.007650375 10.212.10.120 10.212.10.220 LDAP 124 searchReq=3D uest(53) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree 31 0.007733127 10.212.10.120 10.212.10.218 RADIUS 120 Access=3D -Accept(2) (id=3D3D4, l=3D3D76) 32 0.008406756 10.212.10.220 10.212.10.120 LDAP 378 searchRes=3D Entry(53) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom" 33 0.008418925 10.212.10.220 10.212.10.120 LDAP 82 searchResD=3D one(53) success [1 result] 34 0.008554053 10.212.10.120 10.212.10.220 LDAP 124 searchReq=3D uest(54) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree 35 0.008629869 10.212.10.120 10.212.10.218 RADIUS 120 Access=3D -Accept(2) (id=3D3D10, l=3D3D76) 36 0.008978083 10.212.10.220 10.212.10.120 LDAP 378 searchRes=3D Entry(54) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom" 37 0.008988019 10.212.10.220 10.212.10.120 LDAP 82 searchResD=3D one(54) success [1 result] 38 0.009107220 10.212.10.120 10.212.10.220 LDAP 124 searchReq=3D uest(60) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree 39 0.009172870 10.212.10.120 10.212.10.218 RADIUS 120 Access=3D -Accept(2) (id=3D3D9, l=3D3D76) 40 0.009654133 10.212.10.220 10.212.10.120 LDAP 378 searchRes=3D Entry(60) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom" 41 0.009667685 10.212.10.220 10.212.10.120 LDAP 82 searchResD=3D one(60) success [1 result] 42 0.009783997 10.212.10.120 10.212.10.220 LDAP 124 searchReq=3D uest(56) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree 43 0.009882004 10.212.10.120 10.212.10.218 RADIUS 120 Access=3D -Accept(2) (id=3D3D3, l=3D3D76) 44 0.010270458 10.212.10.220 10.212.10.120 LDAP 378 searchRes=3D Entry(56) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom" 45 0.010280926 10.212.10.220 10.212.10.120 LDAP 82 searchResD=3D one(56) success [1 result] 46 0.010400940 10.212.10.120 10.212.10.220 LDAP 124 searchReq=3D uest(58) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree 47 0.010474219 10.212.10.120 10.212.10.218 RADIUS 120 Access=3D -Accept(2) (id=3D3D2, l=3D3D76) 48 0.010881808 10.212.10.220 10.212.10.120 LDAP 378 searchRes=3D Entry(58) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom" 49 0.010891960 10.212.10.220 10.212.10.120 LDAP 82 searchResD=3D one(58) success [1 result] 50 0.011050696 10.212.10.120 10.212.10.218 RADIUS 120 Access=3D -Accept(2) (id=3D3D11, l=3D3D76) Thanks, Raji -----Original Message----- From: Quanah Gibson-Mount Sent: Thursday, September 26, 2019 6:52 PM To: Rajalakshmi Jayaraman ; openldap-its(a)OpenLD= AP=3D .org Cc: Muthaiyan Vel Subject: RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44 --On Thursday, September 26, 2019 2:19 PM +0000 Rajalakshmi Jayaraman > wrote: > > > Hi, > > Thanks for sharing the inputs. We have tried with the unmodified > release of OpenLDAP that was suggested. From the pcap, we have noticed > the LDAP search requests are sequential. (pl. find attached the pcap) > for reference Please put your pcap file on the FTP server rather than sending it via the =3D ITS system. Then respond to the ITS with a link to the file. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > Juniper Business Use Only --_000_CH2PR05MB69514726BCB360A68DA761D2DF860CH2PR05MB6951namp_ Content-Type: text/html; charset=3D"us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

The FTP "ftp://ftp.openldap.org/incoming/" is not working. Hence =3D pasted the pcap details, hope this helps

As you can see, 9 requests from a single AAA serv= =3D er to LDAP server were initiated at the same time (concurrent request). But=3D from the LDAP, our understanding is the ‘searchRequest’ is sequential..after every ‘searchReq= =3D uest’ there is “searchResDone” before handling the subsequent requ=3D est “searchReques= =3D t’

 

No   Time       Source &=3D nbsp;        Destination  &nbs=3D p;  Protocol        Length &nb=3D sp;        Info

1    0.000000000     10.212.10.218&nb=3D sp;  10.212.10.120   RADIUS     115 =3D ; Access-Request(1) (id=3D3D2, l=3D3D71)

2    0.000359909     10.212.10.218&nb=3D sp;  10.212.10.120   RADIUS     115 =3D ; Access-Request(1) (id=3D3D7, l=3D3D71)

3    0.000512919     10.212.10.218&nb=3D sp;  10.212.10.120   RADIUS     115 =3D ; Access-Request(1) (id=3D3D8, l=3D3D71)

4    0.001219680     10.212.10.218&nb=3D sp;  10.212.10.120   RADIUS     115 =3D ; Access-Request(1) (id=3D3D9, l=3D3D71)

5    0.001228416     10.212.10.218&nb=3D sp;  10.212.10.120   RADIUS     115 =3D ; Access-Request(1) (id=3D3D10, l=3D3D71)

6    0.001359636     10.212.10.218&nb=3D sp;  10.212.10.120   RADIUS     115 =3D ; Access-Request(1) (id=3D3D11, l=3D3D71)

7    0.002419581     10.212.10.218&nb=3D sp;  10.212.10.120   RADIUS     115 =3D ; Access-Request(1) (id=3D3D5, l=3D3D71)

8    0.002432108     10.212.10.218&nb=3D sp;  10.212.10.120   RADIUS     115 =3D ; Access-Request(1) (id=3D3D6, l=3D3D71)

9    0.002435112     10.212.10.218&nb=3D sp;  10.212.10.120   RADIUS     115 =3D ; Access-Request(1) (id=3D3D4, l=3D3D71)

10   0.002511929     10.212.10.120 &n=3D bsp; 10.212.10.220   LDAP 124     searchReque=3D st(52) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree

11   0.002637421     10.212.10.218 &n=3D bsp; 10.212.10.120   RADIUS     115  Acc=3D ess-Request(1) (id=3D3D3, l=3D3D71)

12   0.004109740     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 378     searchResEn=3D try(52) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom"

13   0.004146613     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 82     searchResDon=3D e(52) success  [2 results]

14   0.004348866     10.212.10.120 &n=3D bsp; 10.212.10.220   LDAP 124     searchReque=3D st(55) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree

15   0.004781891     10.212.10.120 &n=3D bsp; 10.212.10.218   RADIUS     120  Acc=3D ess-Accept(2) (id=3D3D7, l=3D3D76)

16   0.004952000     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 378     searchResEn=3D try(55) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom"

17   0.004962643     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 82     searchResDon=3D e(55) success  [0 results]

18   0.005087014     10.212.10.120 &n=3D bsp; 10.212.10.220   LDAP 124     searchReque=3D st(57) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree

19   0.005153658     10.212.10.120 &n=3D bsp; 10.212.10.218   RADIUS     120  Acc=3D ess-Accept(2) (id=3D3D8, l=3D3D76)

20   0.005698130     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 378     searchResEn=3D try(57) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom"

21   0.005723767     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 82     searchResDon=3D e(57) success  [1 result]

22   0.005915500     10.212.10.120 &n=3D bsp; 10.212.10.218   RADIUS     120  Acc=3D ess-Accept(2) (id=3D3D5, l=3D3D76)

23   0.006033219     10.212.10.120 &n=3D bsp; 10.212.10.220   LDAP 124     searchReque=3D st(59) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree

24   0.006566138     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 378     searchResEn=3D try(59) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom"

25   0.006578873     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 82     searchResDon=3D e(59) success  [1 result]

26   0.006740243     10.212.10.120 &n=3D bsp; 10.212.10.218   RADIUS     120  Acc=3D ess-Accept(2) (id=3D3D6, l=3D3D76)

27   0.006831740     10.212.10.120 &n=3D bsp; 10.212.10.220   LDAP 124     searchReque=3D st(61) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree

28   0.007507468     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 378     searchResEn=3D try(61) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom"

29   0.007519658     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 82     searchResDon=3D e(61) success  [1 result]

30   0.007650375     10.212.10.120 &n=3D bsp; 10.212.10.220   LDAP 124     searchReque=3D st(53) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree

31   0.007733127     10.212.10.120 &n=3D bsp; 10.212.10.218   RADIUS     120  Acc=3D ess-Accept(2) (id=3D3D4, l=3D3D76)

32   0.008406756     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 378     searchResEn=3D try(53) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom"

33   0.008418925     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 82     searchResDon=3D e(53) success  [1 result]

34   0.008554053     10.212.10.120 &n=3D bsp; 10.212.10.220   LDAP 124     searchReque=3D st(54) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree

35   0.008629869     10.212.10.120 &n=3D bsp; 10.212.10.218   RADIUS     120  Acc=3D ess-Accept(2) (id=3D3D10, l=3D3D76)

36   0.008978083     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 378     searchResEn=3D try(54) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom"

37   0.008988019     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 82     searchResDon=3D e(54) success  [1 result]

38   0.009107220     10.212.10.120 &n=3D bsp; 10.212.10.220   LDAP 124     searchReque=3D st(60) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree

39   0.009172870     10.212.10.120 &n=3D bsp; 10.212.10.218   RADIUS     120  Acc=3D ess-Accept(2) (id=3D3D9, l=3D3D76)

40   0.009654133     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 378     searchResEn=3D try(60) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom"

41   0.009667685     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 82     searchResDon=3D e(60) success  [1 result]

42   0.009783997     10.212.10.120 &n=3D bsp; 10.212.10.220   LDAP 124     searchReque=3D st(56) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree

43   0.009882004     10.212.10.120 &n=3D bsp; 10.212.10.218   RADIUS     120  Acc=3D ess-Accept(2) (id=3D3D3, l=3D3D76)

44   0.010270458     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 378     searchResEn=3D try(56) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom"

45   0.010280926     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 82     searchResDon=3D e(56) success  [1 result]

46   0.010400940     10.212.10.120 &n=3D bsp; 10.212.10.220   LDAP 124     searchReque=3D st(58) "dc=3D3Dexample,dc=3D3Dcom" wholeSubtree

47   0.010474219     10.212.10.120 &n=3D bsp; 10.212.10.218   RADIUS     120  Acc=3D ess-Accept(2) (id=3D3D2, l=3D3D76)

48   0.010881808     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 378     searchResEn=3D try(58) "cn=3D3Dtest,dc=3D3Dexample,dc=3D3Dcom"

49   0.010891960     10.212.10.220 &n=3D bsp; 10.212.10.120   LDAP 82     searchResDon=3D e(58) success  [1 result]

50   0.011050696     10.212.10.120 &n=3D bsp; 10.212.10.218   RADIUS     120  Acc=3D ess-Accept(2) (id=3D3D11, l=3D3D76)

 

 

 

Thanks,

Raji

 

 

 

-----Original Message-----
From: Quanah Gibson-Mount <quanah(a)symas.com>
Sent: Thursday, September 26, 2019 6:52 PM
To: Rajalakshmi Jayaraman <jrajalakshmi(a)juniper.net>; openldap-its(a)= Op=3D enLDAP.org
Cc: Muthaiyan Vel <mvel(a)juniper.net>
Subject: RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44<=3D /p>

 

 

 

--On Thursday, September 26, 2019 2:19 PM +00= =3D 00 Rajalakshmi Jayaraman <= jrajalakshmi(a)juniper.= ne=3D t> wrote:

 

> 

> 

> Hi,

> 

> Thanks for sharing the inputs. We have tried= =3D with the unmodified

> release of OpenLDAP that was suggested. From= =3D the pcap, we have noticed

> the LDAP search requests are sequential. (pl= =3D . find attached the pcap)

> for reference

 

Please put your pcap file on the FTP server rathe= =3D r than sending it via the ITS system.  Then respond to the ITS with a =3D link to the file.

 

--Quanah

 

--

 

Quanah Gibson-Mount

Product Architect

Symas Corporation

Packaged, certified, and supported LDAP solutions= =3D powered by OpenLDAP:

<https://urldefense.com/v3/__http://www.symas.com__;!8WoA6RjC81c!R398=3D Hvv4fWbtEY6cojq9Y7NDCOui0Wmtxg3ZIwwbs-vEdcC_Ir4Odx8wrsWJSPM5qmj9$ >

 

Juniper Business Use Only

--_000_CH2PR05MB69514726BCB360A68DA761D2DF860CH2PR05MB6951namp_-- --===============8864210669900816422==-- From quanah@symas.com Thu Sep 26 14:52:51 2019 From: quanah@symas.com To: openldap-bugs@openldap.org Subject: RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44 Date: Thu, 26 Sep 2019 14:52:49 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7347695886919728107==" --===============7347695886919728107== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Thursday, September 26, 2019 3:11 PM +0000 Rajalakshmi Jayaraman wrote: > > > Hi, > > The FTP "ftp://ftp.openldap.org/incoming/" is not working. Hence pasted > the pcap details, hope this helps It's working just fine: quanah(a)ub18:~$ ftp ftp.openldap.org Connected to www.openldap.org. 220 ProFTPD 1.3.4a Server (gauss) [::ffff:23.92.27.230] Name (ftp.openldap.org:quanah): ftp 331 Anonymous login ok, send your complete email address as your password Password: 230 Anonymous access granted, restrictions apply Remote system type is UNIX. Using binary mode to transfer files. ftp> pass Passive mode on. ftp> cd incoming 250 CWD command successful ftp> mkdir its9088 257 "/incoming/its9088" - Directory successfully created ftp> cd its9088 250 CWD command successful ftp> lcd /tmp Local directory now /tmp ftp> put blah local: blah remote: blah 227 Entering Passive Mode (23,92,27,230,156,55). 150 Opening BINARY mode data connection for blah 226 Transfer complete ftp> -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: --===============7347695886919728107==-- From jrajalakshmi@juniper.net Fri Sep 27 09:50:50 2019 From: jrajalakshmi@juniper.net To: openldap-bugs@openldap.org Subject: RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44 Date: Fri, 27 Sep 2019 09:50:48 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5485141411832922155==" --===============5485141411832922155== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable --_000_CH2PR05MB6951111C41162851F03396AEDF810CH2PR05MB6951namp_ Content-Type: text/plain; charset=3D"us-ascii" Content-Transfer-Encoding: quoted-printable Hi Quanah, Can we have a solution for the issue reported at the earliest. Since we hav=3D e a release and the fix needs to be done. Thanks, Raji -----Original Message----- From: Quanah Gibson-Mount Sent: Thursday, September 26, 2019 8:23 PM To: Rajalakshmi Jayaraman ; openldap-its(a)OpenLD= AP=3D .org Cc: Muthaiyan Vel Subject: RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44 --On Thursday, September 26, 2019 3:11 PM +0000 Rajalakshmi Jayaraman > wrote: > > > Hi, > > The FTP > "https://urldefense.com/v3/__ftp://ftp.openldap.org/incoming/__;!8WoA6 > RjC81c!WuKVskHw8TTh7xPBLQCayeOo0jLoA3scmo73fpEyBwOwyP2lAUVT_sk-67s4ryH > U5-Z3$ " is not working. Hence pasted the pcap details, hope this > helps It's working just fine: quanah(a)ub18:~$ ftp ftp.openldap.org Connected to www.openldap.org. 220 ProFTPD 1.3.4a Server (gauss) [::ffff:23.92.27.230] Name (ftp.openldap.=3D org:quanah): ftp 331 Anonymous login ok, send your complete email address as your password Password: 230 Anonymous access granted, restrictions apply Remote system type is UNIX=3D . Using binary mode to transfer files. ftp> pass Passive mode on. ftp> cd incoming 250 CWD command successful ftp> mkdir its9088 257 "/incoming/its9088" - Directory successfully created ftp> cd its9088 250 CWD command successful ftp> lcd /tmp Local directory now /tmp ftp> put blah local: blah remote: blah 227 Entering Passive Mode (23,92,27,230,156,55). 150 Opening BINARY mode data connection for blah 226 Transfer complete ftp> -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > Juniper Business Use Only --_000_CH2PR05MB6951111C41162851F03396AEDF810CH2PR05MB6951namp_ Content-Type: text/html; charset=3D"us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Quanah,

Can we have a solution for the issue reported at = =3D the earliest. Since we have a release and the fix needs to be done.

 

Thanks,
Raji

 

-----Original Message-----
From: Quanah Gibson-Mount <quanah(a)symas.com>
Sent: Thursday, September 26, 2019 8:23 PM
To: Rajalakshmi Jayaraman <jrajalakshmi(a)juniper.net>; openldap-its(a)= Op=3D enLDAP.org
Cc: Muthaiyan Vel <mvel(a)juniper.net>
Subject: RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44<=3D /p>

 

 

 

--On Thursday, September 26, 2019 3:11 PM +00= =3D 00 Rajalakshmi Jayaraman <= jrajalakshmi(a)juniper.= ne=3D t> wrote:

 

> 

> 

> Hi,

> 

> The FTP

> "https://urldefense.com/v3/__ftp://ftp.= =3D openldap.org/incoming/__;!8WoA6

> RjC81c!WuKVskHw8TTh7xPBLQCayeOo0jLoA3scmo73f= =3D pEyBwOwyP2lAUVT_sk-67s4ryH

> U5-Z3$ " is not working. Hence pasted t= =3D he pcap details, hope this

> helps

 

It's working just fine:

 

quanah(a)ub18:~$ ftp ftp.openldap.org= =3D

Connected to =3D www.openldap.org.

220 ProFTPD 1.3.4a Server (gauss) [::ffff:23.92.2= =3D 7.230] Name (ftp.openldap.org:quanah): ftp<=3D o:p>

331 Anonymous login ok, send your complete email = =3D address as your password

Password:

230 Anonymous access granted, restrictions apply = =3D Remote system type is UNIX.

Using binary mode to transfer files.

ftp> pass

Passive mode on.

ftp> cd incoming

250 CWD command successful

ftp> mkdir its9088

257 "/incoming/its9088" - Directory suc= =3D cessfully created

ftp> cd its9088

250 CWD command successful

ftp> lcd /tmp

Local directory now /tmp

ftp> put blah

local: blah remote: blah

227 Entering Passive Mode (23,92,27,230,156,55).<= =3D o:p>

150 Opening BINARY mode data connection for blah<= =3D o:p>

226 Transfer complete

ftp>

 

 

--

 

Quanah Gibson-Mount

Product Architect

Symas Corporation

Packaged, certified, and supported LDAP solutions= =3D powered by OpenLDAP:

<https://urldefense.com/v3/__http://www.symas.com__;!8WoA6RjC81c!WuKV=3D skHw8TTh7xPBLQCayeOo0jLoA3scmo73fpEyBwOwyP2lAUVT_sk-67s4r6bEJRvo$ >

 

Juniper Business Use Only

--_000_CH2PR05MB6951111C41162851F03396AEDF810CH2PR05MB6951namp_-- --===============5485141411832922155==-- From quanah@symas.com Fri Sep 27 15:10:26 2019 From: quanah@symas.com To: openldap-bugs@openldap.org Subject: RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44 Date: Fri, 27 Sep 2019 15:10:25 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4097209000082051785==" --===============4097209000082051785== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit --On Friday, September 27, 2019 10:50 AM +0000 Rajalakshmi Jayaraman wrote: > > > Hi Quanah, > > Can we have a solution for the issue reported at the earliest. Since we > have a release and the fix needs to be done. Hello Raji, If you need an immediate fix to an issue, you may wish to contact one of the companies that offers such services via the support page: The project itself cannot commit to when it will or will not have a specific issue resolved. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: --===============4097209000082051785==-- From hugh.mcmaster@outlook.com Sun Sep 29 11:54:53 2019 From: hugh.mcmaster@outlook.com To: openldap-bugs@openldap.org Subject: Re: (ITS#8996) Please supply a pkg-config file for libldap Date: Sun, 29 Sep 2019 11:54:52 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5436890504922936115==" --===============5436890504922936115== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Dear OpenLDAP developers, I've rebased the above patches on the current master branch (as of 29 September) and replaced them on the FTP server. I'm hoping someone can review them as development begins on the 2.5 branch. Thank you, Hugh --===============5436890504922936115==-- From santucco@mail.ru Mon Sep 30 11:04:09 2019 From: santucco@mail.ru To: openldap-bugs@openldap.org Subject: (ITS#9090) memory leak: ldap_unbind_* functions don't free 'ld_sb' field of LDAP structure Date: Mon, 30 Sep 2019 11:04:08 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0074352514353154874==" --===============0074352514353154874== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Full_Name: Alexander Sychev Version: 2.4.48 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.103.66.207) Steps to reproduce: 1. Write a test: #include int main() { LDAP* h = NULL; LDAPURLDesc u; memset(&u, 0, sizeof(LDAPURLDesc)); char* s = 0; u.lud_scheme = "ldap"; u.lud_host = "locahost"; u.lud_port = 8080; u.lud_scope = LDAP_SCOPE_DEFAULT ; s = ldap_url_desc2str(&u); ldap_initialize(&h, s); ldap_memfree(s); ldap_unbind_ext_s(h, NULL, NULL); return 0; } 2. Compile it with AddressSanitizer support: gcc test.c -g -fsanitize=address 3. Run the test, analyze AddressSanitizer output: ================================================================= ==29038==ERROR: LeakSanitizer: detected memory leaks Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f9d35ac23a8 in __interceptor_calloc ../../../../libsanitizer/asan/asan_malloc_linux.cc:70 #1 0x55d793627512 in ber_memcalloc_x (/tmp/test+0x67512) #2 0x55d79362757b in ber_memcalloc (/tmp/test+0x6757b) #3 0x55d793628a2d in ber_sockbuf_alloc (/tmp/test+0x68a2d) #4 0x55d7935ee453 in ldap_create (/tmp/test+0x2e453) #5 0x55d7935ee628 in ldap_initialize (/tmp/test+0x2e628) #6 0x55d7935ede8e in main /tmp/test.c:14 #7 0x7f9d3442c3d4 in __libc_start_main (/lib64/libc.so.6+0x223d4) SUMMARY: AddressSanitizer: 40 byte(s) leaked in 1 allocation(s). ================================================================= 4. Possible patch: --- openldap/libraries/libldap/unbind.c.orig 2019-07-23 17:46:22.000000000 +0300 +++ openldap/libraries/libldap/unbind.c 2019-09-27 15:39:40.000000000 +0300 @@ -134,6 +134,8 @@ /* Should already be closed by ldap_free_connection which knows not to free * this one */ ber_int_sb_destroy( ld->ld_sb ); + /* free memory to avoid of leak */ + ber_memfree( ld->ld_sb ); LDAP_MUTEX_LOCK( &ld->ld_ldopts_mutex ); --===============0074352514353154874==-- From ondra@mistotebe.net Mon Sep 30 12:11:32 2019 From: ondra@mistotebe.net To: openldap-bugs@openldap.org Subject: Re: (ITS#9090) memory leak: ldap_unbind_* functions don't free 'ld_sb' field of LDAP structure Date: Mon, 30 Sep 2019 12:11:31 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4088261463454435892==" --===============4088261463454435892== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 30, 2019 at 11:04:08AM +0000, santucco(a)mail.ru wrote: > 3. Run the test, analyze AddressSanitizer output: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D29038=3D=3DERROR: LeakSanitizer: detected memory leaks >=20 > Direct leak of 40 byte(s) in 1 object(s) allocated from: > #0 0x7f9d35ac23a8 in __interceptor_calloc > ../../../../libsanitizer/asan/asan_malloc_linux.cc:70 > #1 0x55d793627512 in ber_memcalloc_x (/tmp/test+0x67512) > #2 0x55d79362757b in ber_memcalloc (/tmp/test+0x6757b) > #3 0x55d793628a2d in ber_sockbuf_alloc (/tmp/test+0x68a2d) > #4 0x55d7935ee453 in ldap_create (/tmp/test+0x2e453) > #5 0x55d7935ee628 in ldap_initialize (/tmp/test+0x2e628) > #6 0x55d7935ede8e in main /tmp/test.c:14 > #7 0x7f9d3442c3d4 in __libc_start_main (/lib64/libc.so.6+0x223d4) >=20 > 4. Possible patch: > =09 > --- openldap/libraries/libldap/unbind.c.orig 2019-07-23 17:46:22.000000000 > +0300 > +++ openldap/libraries/libldap/unbind.c 2019-09-27 15:39:40.000000000 +0300 > @@ -134,6 +134,8 @@ > /* Should already be closed by ldap_free_connection which knows not to fr= ee > * this one */ > ber_int_sb_destroy( ld->ld_sb ); > + /* free memory to avoid of leak */ > + ber_memfree( ld->ld_sb ); > =20 > LDAP_MUTEX_LOCK( &ld->ld_ldopts_mutex ); Dear Alexander, this looks like a duplicate of ITS#9081, fixed with commit 639e5f15fdeaf46941ec6da5c5d5f7ef707a976c. Regards, --=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 --===============4088261463454435892==-- From ondra@mistotebe.net Mon Sep 30 14:48:17 2019 From: ondra@mistotebe.net To: openldap-bugs@openldap.org Subject: Re: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44 Date: Mon, 30 Sep 2019 14:48:16 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1644157177655633706==" --===============1644157177655633706== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 23, 2019 at 09:22:45AM +0000, jrajalakshmi(a)juniper.net wrote: > (1) What problem/issue/behavior are you having trouble with? What do you ex= pect > to see? > Using OpenLDAP version 2.4.44 we are not seeing Concurrency whereas in Open= LDAP > Version 2.4.23 we are seeing Concurrent LDAP Requests. > In our product OpenLDAP 2.4.23 was previously used and the concurrent reque= st > for search using the API ' ldap_search_ext_s() ' was working as expected an= d our > product scalability was better.=20 > We have recently upgraded LDAP to OpenLDAP 2.4.44. But with this version, t= he > api 'ldap_search_ext_s()' does not seem to work as expected, i.e concurrent > requests handling is not happening.=20 Hi, if you want the project to investigate this, it would be useful if you provide a sample program that exhibits this behaviour with a vanilla build of 2.4.48 and doesn't exhibit that with an analogous build of 2.4.23. I would like to point out that since 2.4.23 is a very old release, it is also possible you have been relying on undocumented behaviour or a libldap_r bug that has since been fixed. That is what a sample program would also help to rule out. Regards, --=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 --===============1644157177655633706==--