- openldap-bugs - openldap.org

Re: (ITS#9091) mdb attribute get mixed up in slapadd continue (-c) mode
by maxime.besson＠worteks.com 15 Oct '19

15 Oct '19

On 10/14/19 8:47 PM, Howard Chu wrote: > > I'd also note that using -c has always been pretty risky. You would be better off using -j > in situations like this, as show below: > Thanks for the fix and tip!

1 0

Re: (ITS#9096)
by priit＠ww.ee 15 Oct '19

15 Oct '19

--0000000000009f14730594e762f7 Content-Type: text/plain; charset="UTF-8" [deemon@Zen ~]$ pkg-config --modversion lmdb 0.9.24 could this be the version number you are looking for? - Priit On Mon, 14 Oct 2019 at 20:27, Priit Oorn <priit(a)ww.ee> wrote: > Don't know the version or how to find out, but I zipped it for you so you > can maybe find out yourself? :-) > Or give me some hints how to find out with what command? > > - Priit > --0000000000009f14730594e762f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">[deemon@Zen ~]$ pkg-config --modversion lmdb 0.9.24 = <div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_sig= nature"> </div><div class=3D"gmail_signature" data-smartmail=3D"gmail_si= gnature">could this be the version number you are looking for? </div><di= v dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature">= - Priit</div></div> </div> <div class=3D"gmail_quote"><div dir=3D= "ltr" class=3D"gmail_attr">On Mon, 14 Oct 2019 at 20:27, Priit Oorn <<a = href=3D"mailto:priit@ww.ee">priit(a)ww.ee</a>> wrote: </div><blockquote= class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so= lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Don't know= the version or how to find out, but I zipped it for you so you can maybe f= ind out yourself? :-)</div><div>Or give me some hints how to find out with = what command? </div><div><div><div><div dir=3D"ltr"> - Priit</div></d= iv></div></div></div> </blockquote></div> --0000000000009f14730594e762f7--

1 0

Re: (ITS#9091) mdb attribute get mixed up in slapadd continue (-c) mode
by hyc＠symas.com 14 Oct '19

14 Oct '19

Howard Chu wrote: > maxime.besson(a)worteks.com wrote: >> Full_Name: Maxime Besson >> Version: 2.4.48 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (77.193.139.162) >> >> >> I am attempting to implement the following disaster recovery process: >> >> * rm all previous data >> * run a configuration script (puppet) to recreate a bare-bones LDAP server and >> DIT >> * restore a backed-up slapcat dump on top of the freshly installed OpenLDAP >> server, ignoring duplicates already inserted by Puppet >> >> But it seems that when skipping over the existing objects, something goes wrong >> and causes attributes to get mixed up. But only when certain attributes are >> present in the existing objects. Here is how to reproduce: > > Thanks for the report and simple test case. This is now fixed in git master. I'd also note that using -c has always been pretty risky. You would be better off using -j in situations like this, as show below: >> >> puppet_init.ldif >> === >> dn: dc=example,dc=com >> objectClass: domain >> dc: example >> === >> >> backup.ldif >> === >> dn: dc=example,dc=com >> objectClass: domain >> dc: example >> contextCSN: 20190909094705.796552Z#000000#001#000000 >> >> dn: uid=ttully,dc=example,dc=com >> objectClass: inetOrgPerson >> uid: ttully >> userPassword:: c2Nob29uZXI= >> facsimileTelephoneNumber: +1 408 555 0111 >> givenName: Torrey >> cn: Torrey Tully >> telephoneNumber: +1 408 555 2274 >> sn: Tully >> roomNumber: 3924 >> mail: ttully(a)example.com >> l: Sunnyvale >> ou: Human Resources >> ou: People >> === >> >> When running the following commands: >> >> === >> rm -f /tmp/*.mdb >> slapadd -f slapd.conf puppet_init.ldif >> slapadd -f slapd.conf -c backup.ldif >> === slapadd -f slapd.conf -l puppet_init.ldif slapadd -f slapd.conf -l backup.ldif -j 5 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#9091) mdb attribute get mixed up in slapadd continue (-c) mode
by hyc＠symas.com 14 Oct '19

14 Oct '19

maxime.besson(a)worteks.com wrote: > Full_Name: Maxime Besson > Version: 2.4.48 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (77.193.139.162) > > > I am attempting to implement the following disaster recovery process: > > * rm all previous data > * run a configuration script (puppet) to recreate a bare-bones LDAP server and > DIT > * restore a backed-up slapcat dump on top of the freshly installed OpenLDAP > server, ignoring duplicates already inserted by Puppet > > But it seems that when skipping over the existing objects, something goes wrong > and causes attributes to get mixed up. But only when certain attributes are > present in the existing objects. Here is how to reproduce: Thanks for the report and simple test case. This is now fixed in git master. > > > slapd.conf: > === > include /etc/ldap/schema/core.schema > include /etc/ldap/schema/cosine.schema > include /etc/ldap/schema/inetorgperson.schema > moduleload back_mdb > database mdb > maxsize 1073741824 > suffix "dc=example,dc=com" > directory /tmp > === > > > puppet_init.ldif > === > dn: dc=example,dc=com > objectClass: domain > dc: example > === > > backup.ldif > === > dn: dc=example,dc=com > objectClass: domain > dc: example > contextCSN: 20190909094705.796552Z#000000#001#000000 > > dn: uid=ttully,dc=example,dc=com > objectClass: inetOrgPerson > uid: ttully > userPassword:: c2Nob29uZXI= > facsimileTelephoneNumber: +1 408 555 0111 > givenName: Torrey > cn: Torrey Tully > telephoneNumber: +1 408 555 2274 > sn: Tully > roomNumber: 3924 > mail: ttully(a)example.com > l: Sunnyvale > ou: Human Resources > ou: People > === > > When running the following commands: > > === > rm -f /tmp/*.mdb > slapadd -f slapd.conf puppet_init.ldif > slapadd -f slapd.conf -c backup.ldif > === > > The redundant root object in backup.ldif gets skipped as -c should do, but the > attributes from my "ttully" user (and every following object in the ldif dump) > end up all mixed up: > > > === > slapcat -f slapd.conf > ... > dn: uid=ttully,dc=example,dc=com > objectClass: inetOrgPerson > userPassword:: dHR1bGx5 > facsimileTelephoneNumber: schooner > givenName: +1 408 555 0111 > cn: Torrey > telephoneNumber: Torrey Tully > sn: +1 408 555 2274 > roomNumber: Tully > mail: 3924 > l: ttully(a)example.com > ou: Sunnyvale > ou: Human Resources > ou: People > ... > === > > > This mixup does NOT happen if: > > * I import backup.ldif into an empty database > * OR I remove "contextCSN" from the backup ldif > * OR I use BDB instead of MDB > > So it seems that my issue is caused by a combination of MDB, skipping existing > entries, and having special attributes (contextCSN) in the skipped objects. > > I was able to reproduce this behavior: > * On Debian Buster (OpenLDAP 2.4.47) > * On RHEL7 + LTB project RPMs 2.4.48 > * Using a git snapshot (3be82f40d5cd4ca050e10859ecb961f28c807c41) with no > particular config options > * Using cn=config rather than slapd.conf > * On a real production system, rather than the simplified version presented > here. > * Using another "special" attribute such as pwdAccountLockedTime instead of > "contextCSN" > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#9096) tons of crashing and core dumps after every boot
by hyc＠symas.com 14 Oct '19

14 Oct '19

priit(a)ww.ee wrote: > Full_Name: Priit Oorn > Version: no idea > OS: Manjaro KDE stable > URL: https://bugsfiles.kde.org/attachment.cgi?id=123175 > Submission from: (NULL) (2001:7d0:8240:e600:7a6:c9cf:974a:2e6e) > > > STEPS TO REPRODUCE > 1. reboot system > 2. journalctl -p3 > > OBSERVED RESULT > KDE baloo_file and baloo_file_extr serial crashing due to LMDB crashing. > > EXPECTED RESULT > no services crashing obviously. > > SOFTWARE/OS VERSIONS > Linux/KDE Plasma: Manjaro Linux KDE stable > KDE Plasma Version: 5.16.5 > KDE Frameworks Version: 5.62.0 > Qt Version: 5.13.1 > LBDM version: no idea... that comes with Manjaro KDE stable default install + > all updates. the crashing thing has been there forever though over several > versions. > > reported the bug to KDE initially, but they say it's your fault... :P > https://bugs.kde.org/show_bug.cgi?id=412925 The stack traces you provided there https://bugsfiles.kde.org/attachment.cgi?id=123175 would indicate a crash in LMDB, but without providing version info we have nothing to go on. Nor do we have any insight into how KDE integrated LMDB and whether they used its API correctly. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#9096) tons of crashing and core dumps after every boot
by priit＠ww.ee 14 Oct '19

14 Oct '19

Full_Name: Priit Oorn Version: no idea OS: Manjaro KDE stable URL: https://bugsfiles.kde.org/attachment.cgi?id=123175 Submission from: (NULL) (2001:7d0:8240:e600:7a6:c9cf:974a:2e6e) STEPS TO REPRODUCE 1. reboot system 2. journalctl -p3 OBSERVED RESULT KDE baloo_file and baloo_file_extr serial crashing due to LMDB crashing. EXPECTED RESULT no services crashing obviously. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro Linux KDE stable KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.62.0 Qt Version: 5.13.1 LBDM version: no idea... that comes with Manjaro KDE stable default install + all updates. the crashing thing has been there forever though over several versions. reported the bug to KDE initially, but they say it's your fault... :P https://bugs.kde.org/show_bug.cgi?id=412925

1 0

Re: (ITS#9018) dynlist don't close connection
by quanah＠symas.com 14 Oct '19

14 Oct '19

Decoded we have: "I have changed back-meta to the back-ldap, and it resolved this problem." --On Tuesday, September 24, 2019 11:59 AM +0000 I.Harbuz(a)A1.by wrote: -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9095) back-mdb slapindex missing records
by hyc＠openldap.org 11 Oct '19

11 Oct '19

Full_Name: Howard Chu Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.203.26.174) Submitted by: hyc In back-mdb the entry reindexer operates in batches of 500 entries at a time. (I.e., it commits one LMDB txn for every 500 entries.) But a final txn_commit is missing in tool_entry_close() to flush out the last few entries that were operated on.

1 0

Re: (ITS#9092) LDAP server out of memory
by quanah＠symas.com 10 Oct '19

10 Oct '19

--On Wednesday, October 9, 2019 9:38 AM +0000 gihanridal8(a)gmail.com wrote: > Full_Name: Gihan De Silva > Version: 2.4.44 > OS: 7.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (123.231.119.138) Hello, The OpenLDAP bug tracking system is for bug reports only. Usage questions should be directed to the OpenLDAP Technical discussion list: <https://www.openldap.org/lists/mm/listinfo/openldap-technical> If you have an urgent support need, then I suggest contacting one of the listed 3rd party support providers at: <https://www.openldap.org/support/> This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44
by jrajalakshmi＠juniper.net 10 Oct '19

10 Oct '19

SGksDQpXZSB3aWxsIHNlbmQgdGhlIHNhbXBsZSBjb2RlIHNob3J0bHkuDQoNClRoYW5rcywNClJh amkNCg0KDQpKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBPbmTFmWVqIEt1em7DrWsgPG9uZHJhQG1pc3RvdGViZS5uZXQ+IA0KU2Vu dDogVHVlc2RheSwgT2N0b2JlciA4LCAyMDE5IDEwOjQ1IFBNDQpUbzogUmFqYWxha3NobWkgSmF5 YXJhbWFuIDxqcmFqYWxha3NobWlAanVuaXBlci5uZXQ+DQpDYzogb3BlbmxkYXAtaXRzQE9wZW5M REFQLm9yZw0KU3ViamVjdDogUmU6IChJVFMjOTA4OCkgQ29uY3VycmVuY3kgbm90IHNlZW4gaW4g T3BlbkxEQVAgMi40LjQ0DQoNCk9uIFR1ZSwgT2N0IDA4LCAyMDE5IGF0IDEyOjU2OjA0UE0gKzAw MDAsIGpyYWphbGFrc2htaUBqdW5pcGVyLm5ldCB3cm90ZToNCj4gSGksDQo+IA0KPiBUaGFua3Mg Zm9yIHRoZSByZXBseS4gVGhlcmUgaXMgYW4gaW1wbGVtZW50YXRpb24gYWxyZWFkeSBpbiBvdXIg cHJvZHVjdC4NCg0KSGksDQphcyBtZW50aW9uZWQgcHJldmlvdXNseSwgcGxlYXNlIHByb3ZpZGUg YSBzYW1wbGUgQyBwcm9ncmFtIHRoYXQgc2hvd3Mgd2hhdCdzIGhhcHBlbmluZyBhbmQgcHJlZmVy YWJseSBvbmUgdGhhdCBhbHNvIGJlaGF2ZXMgYmV0dGVyIHdpdGggMi40LjIzIGZyb20geW91ciBw ZXJzcGVjdGl2ZSBzbyB3ZSBjYW4gaGVscCB5b3UgaW52ZXN0aWdhdGUuIEkgZG9uJ3QgYmVsaWV2 ZSBwYWNrZXQgY2FwdHVyZXMgd291bGQgaGVscCB1cyBoZXJlIGF0IHRoaXMgcG9pbnQuDQoNCj4g VG8gc3VtbWFyaXplIG9uIHRoZSBiZWhhdmlvciBvYnNlcnZlZA0KPiANCj4gU2NlbmFyaW8jMToN Cj4gDQo+IFNpbmdsZSBMREFQIHNlc3Npb24gd2l0aCBMREFQIEJpbmQgZG9lcyBhdXRoZW50aWNh dGlvbiBpbiBTZXF1ZW50aWFsIA0KPiBPcmRlci4gRHVlIHRvIHNlcXVlbnRpYWwgZXhlY3V0aW9u IG9mIE9wZW5MREFQIFNlYXJjaCBBUEkgYWZ0ZXIgDQo+IHZlcnNpb24gMi40LjI0IHdlIG9ic2Vy dmUgcGFja2V0IGRyb3BzIGluIExEQVAgQXV0aGVudGljYXRpb24gUmVxdWVzdC4NCj4gVGhpcyBp cyByZXN1bHRpbmcgaW4gTG93IHBlcmZvcm1hbmNlIG9mIG91ciBwcm9kdWN0Lg0KDQpQcmV2aW91 c2x5IHlvdSBtZW50aW9uZWQgb25seSBzZWFyY2hlcywgd2hpY2ggc2hvdWxkIHdvcmsgb3ZlciB0 aGUgc2FtZSBjb25uZWN0aW9uIGRlcGVuZGluZyBob3cgeW91IGRvIHRoaW5ncy4gTm90IHN1cmUg aG93IGJpbmRzIGZpdCBpbiB0aGUgcGljdHVyZSBoZXJlPyBKdXN0IGEgbm90ZSB0aGF0IHlvdSBj YW4gb25seSBoYXZlIGNlcnRhaW4gdHlwZXMgb2Ygb3BlcmF0aW9ucyBwZW5kaW5nIGF0IHRoZSBz YW1lIHRpbWUgYW5kIGJpbmRzIGFyZSBub3Qgb25lIG9mIHRoZW0uDQoNCkFsc28gZG9uJ3Qga25v dyB3aGF0IHlvdSBtZWFuIGJ5IHBhY2tldCBkcm9wcyBoZXJlLiBJcyB0aGF0IHBhY2tldCBkcm9w cyBpbiB5b3VyIHByb2R1Y3Qgb3IgcGFja2V0IGRyb3BzIG9uIHRoZSBMREFQIHNlc3Npb24/DQoN Cj4gU2NlbmFyaW8gIzI6ICh0aGlzIGlzIGEgc2FtcGxlIHRlc3QgY2FzZSB0cmllZCB0byBjb21w YXJlIHRoZSBiZWhhdmlvciANCj4gd2l0aCBTY2VuYXJpbyMxKQ0KPiANCj4gVGhlcmUgYXJlIHNh eSAxMCBMREFQIGluc3RhbmNlcyBjb25maWd1cmVkLCBhbGwgcG9pbnRpbmcgdG8gdGhlIHNhbWUg DQo+IExEQVAgc2VydmVyLiBUaGUgcmVxdWVzdC1yZXNwb25zZSBpcyBoYW5kbGVkIHByb3Blcmx5 LCBwZXJmb3JtYW5jZSBpcyANCj4gaW1wcm92ZWQgd2hlbiBjb21wYXJlZCB0byBzY2VuYXJpbyMx LiBCdXQgdGhlIGRyYXdiYWNrIGlzIHRoZSBtdWx0aXBsZSANCj4gdGhyZWFkcyBmb3IgZXZlcnkg TERBUCBjbGllbnQgc2Vzc2lvbiwgdXRpbGl6aW5nIG1vcmUgbWVtb3J5LiBUaGlzIA0KPiBkZXNp Z24gbWF5IG5vdCBiZSByZWNvbW1lbmRlZCBmb3Igb3VyIHByb2R1Y3QuDQoNCllvdSBjYW4gaGF2 ZSBhIHNpbmdsZSB0aHJlYWQgdGFraW5nIGNhcmUgb2YgdGhlIHNlc3Npb24gKG9yIGhvd2V2ZXIg bWFueSBzZXNzaW9ucyB5b3Ugd2FudCkgaWYgeW91IHVzZSBhIG5vbi1ibG9ja2luZyBzb2NrZXQg Zm9yIHRoZSB1bmRlcmx5aW5nDQpjb25uZWN0aW9uKHMpIChhbmQgdXNlIGxkYXBfcmVzdWx0IGFu ZCBmcmllbmRzKSB3aGljaCBpcyB3aGF0IHRoZSBhc3luY2hyb25vdXMgQVBJIGhhcyBiZWVuIGRl c2lnbmVkIGZvci4NCg0KPiBQbC4gcmVwbHkgYmFjayBmb3IgYW55IGZ1cnRoZXIgcXVlcmllcyAv IGNsYXJpZmljYXRpb25zLiBUaGUgcGFja2V0IA0KPiBjYXB0dXJlcyBmaWxlIHNpemUgaXMgYmln ICg+Nk1CKSwgY2FuIHRyeSB0byBzaGFyZSB0aGUgcmVsZXZhbnQgDQo+IHJlcXVlc3QtcmVzcG9u c2UgZGV0YWlscy4uLi4uLg0KDQpSZWdhcmRzLA0KDQotLQ0KT25kxZllaiBLdXpuw61rDQpTZW5p b3IgU29mdHdhcmUgRW5naW5lZXINClN5bWFzIENvcnBvcmF0aW9uICAgICAgICAgICAgICAgICAg ICAgICBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cDovL3d3dy5zeW1hcy5jb21fXzsh OFdvQTZSakM4MWMhVDNyV05tZTYzRlJFcmJzZ3I4RDVvaV9WVU9HWEY3YVFXSTZFckswMWp0elVM Nm9tcmhXSXFkay1ySDllUGxCald6UXUkIA0KUGFja2FnZWQsIGNlcnRpZmllZCwgYW5kIHN1cHBv cnRlZCBMREFQIHNvbHV0aW9ucyBwb3dlcmVkIGJ5IE9wZW5MREFQDQo=

1 0

(ITS#9094) LDAP server out of memory
by gihanridal8＠gmail.com 09 Oct '19

09 Oct '19

Full_Name: Gihan De Silva Version: 2.4.44 OS: 7.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.231.119.138) Dear Sir/ Madam, We are having two OpenLDAP servers on production with master master data synchronization. We are facing an incident where both servers consume memory upto 99% and LDAP server2 leads to not responding state. As a workaround we have restart both OpenLDAP nodes. However after few days the memory goes high at its peak. There are about 100k+ requests for one LDAP server per day. where both servers are identical in terms of 16 GB RAM, 4 CPUs, CentOS7 OS and LDAP server 2.4.44. We didnt observe any suspiciuos errors in the logs as well. Appreciate your valued consultation and recomendations on this incident for a RCA and a solution. Thank You Regards, Gihan.

1 0

(ITS#9093) LDAP server out of memory
by gihanridal8＠gmail.com 09 Oct '19

09 Oct '19

Full_Name: Gihan De Silva Version: 2.4.44 OS: 7.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.231.119.138) Dear Sir/ Madam, We are having two OpenLDAP servers on production with master master data synchronization. We are facing an incident where both servers consume memory upto 99% and LDAP server2 leads to not responding state. As a workaround we have restart both OpenLDAP nodes. However after few days the memory goes high at its peak. There are about 100k+ requests for one LDAP server per day. where both servers are identical in terms of 16 GB RAM, 4 CPUs, CentOS7 OS and LDAP server 2.4.44. We didnt observe any suspiciuos errors in the logs as well. Appreciate your valued consultation and recomendations on this incident for a RCA and a solution. Thank You Regards, Gihan.

1 0

(ITS#9092) LDAP server out of memory
by gihanridal8＠gmail.com 09 Oct '19

09 Oct '19

Full_Name: Gihan De Silva Version: 2.4.44 OS: 7.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.231.119.138) Dear Sir/ Madam, We are having two OpenLDAP servers on production with master master data synchronization. We are facing an incident where both servers consume memory upto 99% and LDAP server2 leads to not responding state. As a workaround we have restart both OpenLDAP nodes. However after few days the memory goes high at its peak. There are about 100k+ requests for one LDAP server per day. where both servers are identical in terms of 16 GB RAM, 4 CPUs, CentOS7 OS and LDAP server 2.4.44. We didnt observe any suspiciuos errors in the logs as well. Appreciate your valued consultation and recomendations on this incident for a RCA and a solution. Thank You Regards, Gihan.

1 0

(ITS#9091) mdb attribute get mixed up in slapadd continue (-c) mode
by maxime.besson＠worteks.com 08 Oct '19

08 Oct '19

Full_Name: Maxime Besson Version: 2.4.48 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.193.139.162) I am attempting to implement the following disaster recovery process: * rm all previous data * run a configuration script (puppet) to recreate a bare-bones LDAP server and DIT * restore a backed-up slapcat dump on top of the freshly installed OpenLDAP server, ignoring duplicates already inserted by Puppet But it seems that when skipping over the existing objects, something goes wrong and causes attributes to get mixed up. But only when certain attributes are present in the existing objects. Here is how to reproduce: slapd.conf: === include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/inetorgperson.schema moduleload back_mdb database mdb maxsize 1073741824 suffix "dc=example,dc=com" directory /tmp === puppet_init.ldif === dn: dc=example,dc=com objectClass: domain dc: example === backup.ldif === dn: dc=example,dc=com objectClass: domain dc: example contextCSN: 20190909094705.796552Z#000000#001#000000 dn: uid=ttully,dc=example,dc=com objectClass: inetOrgPerson uid: ttully userPassword:: c2Nob29uZXI= facsimileTelephoneNumber: +1 408 555 0111 givenName: Torrey cn: Torrey Tully telephoneNumber: +1 408 555 2274 sn: Tully roomNumber: 3924 mail: ttully(a)example.com l: Sunnyvale ou: Human Resources ou: People === When running the following commands: === rm -f /tmp/*.mdb slapadd -f slapd.conf puppet_init.ldif slapadd -f slapd.conf -c backup.ldif === The redundant root object in backup.ldif gets skipped as -c should do, but the attributes from my "ttully" user (and every following object in the ldif dump) end up all mixed up: === slapcat -f slapd.conf ... dn: uid=ttully,dc=example,dc=com objectClass: inetOrgPerson userPassword:: dHR1bGx5 facsimileTelephoneNumber: schooner givenName: +1 408 555 0111 cn: Torrey telephoneNumber: Torrey Tully sn: +1 408 555 2274 roomNumber: Tully mail: 3924 l: ttully(a)example.com ou: Sunnyvale ou: Human Resources ou: People ... === This mixup does NOT happen if: * I import backup.ldif into an empty database * OR I remove "contextCSN" from the backup ldif * OR I use BDB instead of MDB So it seems that my issue is caused by a combination of MDB, skipping existing entries, and having special attributes (contextCSN) in the skipped objects. I was able to reproduce this behavior: * On Debian Buster (OpenLDAP 2.4.47) * On RHEL7 + LTB project RPMs 2.4.48 * Using a git snapshot (3be82f40d5cd4ca050e10859ecb961f28c807c41) with no particular config options * Using cn=config rather than slapd.conf * On a real production system, rather than the simplified version presented here. * Using another "special" attribute such as pwdAccountLockedTime instead of "contextCSN"

1 0

Re: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44
by ondra＠mistotebe.net 08 Oct '19

08 Oct '19

On Tue, Oct 08, 2019 at 12:56:04PM +0000, jrajalakshmi(a)juniper.net wrote: > Hi, > > Thanks for the reply. There is an implementation already in our product. Hi, as mentioned previously, please provide a sample C program that shows what's happening and preferably one that also behaves better with 2.4.23 from your perspective so we can help you investigate. I don't believe packet captures would help us here at this point. > To summarize on the behavior observed > > Scenario#1: > > Single LDAP session with LDAP Bind does authentication in Sequential > Order. Due to sequential execution of OpenLDAP Search API after > version 2.4.24 we observe packet drops in LDAP Authentication Request. > This is resulting in Low performance of our product. Previously you mentioned only searches, which should work over the same connection depending how you do things. Not sure how binds fit in the picture here? Just a note that you can only have certain types of operations pending at the same time and binds are not one of them. Also don't know what you mean by packet drops here. Is that packet drops in your product or packet drops on the LDAP session? > Scenario #2: (this is a sample test case tried to compare the behavior > with Scenario#1) > > There are say 10 LDAP instances configured, all pointing to the same > LDAP server. The request-response is handled properly, performance is > improved when compared to scenario#1. But the drawback is the multiple > threads for every LDAP client session, utilizing more memory. This > design may not be recommended for our product. You can have a single thread taking care of the session (or however many sessions you want) if you use a non-blocking socket for the underlying connection(s) (and use ldap_result and friends) which is what the asynchronous API has been designed for. > Pl. reply back for any further queries / clarifications. The packet > captures file size is big (>6MB), can try to share the relevant > request-response details...... Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44
by jrajalakshmi＠juniper.net 08 Oct '19

08 Oct '19

--_000_CH2PR05MB69514B8448808C2D1086ABB7DF9A0CH2PR05MB6951namp_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi, Thanks for the reply. There is an implementation already in our product. To summarize on the behavior observed Scenario#1: Single LDAP session with LDAP Bind does authentication in Sequential Order.= Due to sequential execution of OpenLDAP Search API after version 2.4.24 we= observe packet drops in LDAP Authentication Request. This is resulting in = Low performance of our product. Scenario #2: (this is a sample test case tried to compare the behavior with= Scenario#1) There are say 10 LDAP instances configured, all pointing to the same LDAP s= erver. The request-response is handled properly, performance is improved wh= en compared to scenario#1. But the drawback is the multiple threads for eve= ry LDAP client session, utilizing more memory. This design may not be recom= mended for our product. Pl. reply back for any further queries / clarifications. The packet capture= s file size is big (>6MB), can try to share the relevant request-response d= etails...... Thanks, Raji -----Original Message----- From: Ond=F8ej Kuzn=EDk <ondra(a)mistotebe.net> Sent: Monday, September 30, 2019 8:18 PM To: Rajalakshmi Jayaraman <jrajalakshmi(a)juniper.net> Cc: openldap-its(a)OpenLDAP.org Subject: Re: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44 On Mon, Sep 23, 2019 at 09:22:45AM +0000, jrajalakshmi(a)juniper.net<mailto:j= rajalakshmi(a)juniper.net> wrote: > (1) What problem/issue/behavior are you having trouble with? What do > you expect to see? > Using OpenLDAP version 2.4.44 we are not seeing Concurrency whereas in > OpenLDAP 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. > 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. Hi, if you want the project to investigate this, it would be useful if you prov= ide 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 al= so 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 hel= p to rule out. Regards, -- Ond=F8ej Kuzn=EDk Senior Software Engineer Symas Corporation https://urldefense.com/v3/__http://= www.symas.com__;!8WoA6RjC81c!Xs72RxgyQ_p-CmwcbkhCu7cCMZXgmihqyjqC563sunVF3O= tjroYFsOTBsDbndrE4VnYu$<https://urldefense.com/v3/__http:/www.symas.com__;!= 8WoA6RjC81c!Xs72RxgyQ_p-CmwcbkhCu7cCMZXgmihqyjqC563sunVF3OtjroYFsOTBsDbndrE= 4VnYu$> Packaged, certified, and supported LDAP solutions powered by OpenLDAP Juniper Business Use Only --_000_CH2PR05MB69514B8448808C2D1086ABB7DF9A0CH2PR05MB6951namp_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 2"> <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> Hi,<o:p></o:p> Thanks for the reply. There is an implementation = already in our product.<o:p></o:p> <o:p> </o:p> To summarize on the behavior observed<o:p></o:p><= /p> Scenario#1:<o:p></o:p> Single LDAP session with LDAP Bind does authentic= ation in Sequential Order. Due to sequential execution of OpenLDAP Search A= PI after version 2.4.24 we observe packet drops in LDAP Authentication Requ= est. This is resulting in Low performance of our product. <o:p></o:p> <o:p> </o:p> Scenario #2: (this is a sample test case tried to= compare the behavior with Scenario#1)<o:p></o:p> There are say 10 LDAP instances configured, all p= ointing to the same LDAP server. The request-response is handled properly, = performance is improved when compared to scenario#1. But the drawback is th= e multiple threads for every LDAP client session, utilizing more memory. This design may not be recommended = for our product.<o:p></o:p> <o:p> </o:p> Pl. reply back for any further queries / clarific= ations. The packet captures file size is big (>6MB), can try to share th= e relevant request-response details……<o:p></o:p> <o:p> </o:p> Thanks, Raji<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> -----Original Message----- From: Ond=F8ej Kuzn=EDk <ondra(a)mistotebe.net> Sent: Monday, September 30, 2019 8:18 PM To: Rajalakshmi Jayaraman <jrajalakshmi(a)juniper.net> Cc: openldap-its(a)OpenLDAP.org Subject: Re: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44<o:p></o:p><= /p> <o:p> </o:p> On Mon, Sep 23, 2019 at 09:22:45AM +0000, <a = href=3D"mailto:jrajalakshmi@juniper.net"> jrajalakshmi(a)juniper.= net</a> wrote:<o:p></o:p> > (1) What problem/issue/behavior are you havi= ng trouble with? What do <o:p></o:p> > you expect to see?<o:p></o:p> > Using OpenLDAP version 2.4.44 we are not see= ing Concurrency whereas in <o:p></o:p> > OpenLDAP Version 2.4.23 we are seeing Concur= rent LDAP Requests.<o:p></o:p> > In our product OpenLDAP 2.4.23 was previousl= y used and the concurrent <o:p></o:p> > request for search using the API ' ldap_sear= ch_ext_s() ' was working <o:p></o:p> > as expected and our product scalability was = better.<o:p></o:p> > We have recently upgraded LDAP to OpenLDAP 2= .4.44. But with this <o:p></o:p> > version, the api 'ldap_search_ext_s()' does = not seem to work as <o:p></o:p> > expected, i.e concurrent requests handling i= s not happening.<o:p></o:p> <o:p> </o:p> Hi,<o:p></o:p> if you want the project to investigate this, it w= ould 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.<o:p></o:p> <o:p> </o:p> 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 sam= ple program would also help to rule out.<o:p></o:p> <o:p> </o:p> Regards,<o:p></o:p> <o:p> </o:p> --<o:p></o:p> Ond=F8ej Kuzn=EDk<o:p></o:p> Senior Software Engineer<o:p></o:p> Symas Corporation     &n= bsp;           &nbsp= ;     <a href=3D"https://urldefense.com/v3/__http:/www.= symas.com__;!8WoA6RjC81c!Xs72RxgyQ_p-CmwcbkhCu7cCMZXgmihqyjqC563sunVF3Otjro= YFsOTBsDbndrE4VnYu$"> https://urldefense.co= m/v3/__http://www.symas.com__;!8WoA6RjC81c!Xs72RxgyQ_p-CmwcbkhCu7cCMZXgmihq= yjqC563sunVF3OtjroYFsOTBsDbndrE4VnYu$</a> <o:p></o:p> Packaged, certified, and supported LDAP solutions= powered by OpenLDAP<o:p></o:p> <o:p> </o:p> Juniper Business Use Only</span= ><o:p></o:p> </div> </body> </html> --_000_CH2PR05MB69514B8448808C2D1086ABB7DF9A0CH2PR05MB6951namp_--

1 0

Re: (ITS#8996) Please supply a pkg-config file for libldap
by hugh.mcmaster＠outlook.com 03 Oct '19

03 Oct '19

Hi Ryan, Thank you for your review. On Thu, 3 Oct 2019 at 13:05, Ryan Tandy wrote: > Thanks for providing the patches. I have reviewed and tested them, > everything I could think of works properly. Excellent! :) > As a personal opinion I might prefer shorter descriptions, for example > "OpenLDAP ASN.1 Basic Encoding Rules library for LDAP" and "OpenLDAP > Lightweight Directory Access Protocol library (reentrant version)". Only > an opinion, there's nothing wrong with what you wrote. I'm happy for the descriptions to be whatever describes the libraries best. I particularly like your shortened ASN.1 description. > I'd like to see this included, however a more senior team member should > approve it first. Good luck! Thanks. Hopefully that will happen soon. Kind regards, Hugh

1 0

Re: (ITS#8996) Please supply a pkg-config file for libldap
by ryan＠openldap.org 03 Oct '19

03 Oct '19

Hello Hugh, Thanks for providing the patches. I have reviewed and tested them, everything I could think of works properly. As a personal opinion I might prefer shorter descriptions, for example "OpenLDAP ASN.1 Basic Encoding Rules library for LDAP" and "OpenLDAP Lightweight Directory Access Protocol library (reentrant version)". Only an opinion, there's nothing wrong with what you wrote. I'd like to see this included, however a more senior team member should approve it first. Good luck! cheers, Ryan

1 0

Re: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44
by ondra＠mistotebe.net 30 Sep '19

30 Sep '19

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 expect > to see? > Using OpenLDAP version 2.4.44 we are not seeing Concurrency whereas in OpenLDAP > 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. > 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. 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, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#9090) memory leak: ldap_unbind_* functions don't free 'ld_sb' field of LDAP structure
by ondra＠mistotebe.net 30 Sep '19

30 Sep '19

On Mon, Sep 30, 2019 at 11:04:08AM +0000, santucco(a)mail.ru wrote: > 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) > > 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 ); Dear Alexander, this looks like a duplicate of ITS#9081, fixed with commit 639e5f15fdeaf46941ec6da5c5d5f7ef707a976c. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#9090) memory leak: ldap_unbind_* functions don't free 'ld_sb' field of LDAP structure
by santucco＠mail.ru 30 Sep '19

30 Sep '19

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 <ldap.h> 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 );

1 0

Re: (ITS#8996) Please supply a pkg-config file for libldap
by hugh.mcmaster＠outlook.com 29 Sep '19

29 Sep '19

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

1 0

RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44
by quanah＠symas.com 27 Sep '19

27 Sep '19

--On Friday, September 27, 2019 10:50 AM +0000 Rajalakshmi Jayaraman <jrajalakshmi(a)juniper.net> 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: <https://www.openldap.org/support/> 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: <http://www.symas.com>

1 0

RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44
by jrajalakshmi＠juniper.net 27 Sep '19

27 Sep '19

--_000_CH2PR05MB6951111C41162851F03396AEDF810CH2PR05MB6951namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Quanah, Can we have a solution for the issue reported at the earliest. Since we hav= e 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@OpenLDAP= .org Cc: Muthaiyan Vel <mvel(a)juniper.net> Subject: RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44 --On Thursday, September 26, 2019 3:11 PM +0000 Rajalakshmi Jayaraman <jraj= alakshmi(a)juniper.net<mailto:jrajalakshmi@juniper.net>> 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@ub18:~$ ftp ftp.openldap.org<ftp://ftp.openldap.org> Connected to www.openldap.org<http://www.openldap.org>. 220 ProFTPD 1.3.4a Server (gauss) [::ffff:23.92.27.230] Name (ftp.openldap.= org:quanah<ftp://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: <https://urldefense.com/v3/__http://www.symas.com__;!8WoA6RjC81c!WuKVskHw8T= Th7xPBLQCayeOo0jLoA3scmo73fpEyBwOwyP2lAUVT_sk-67s4r6bEJRvo$ <https://urldef= ense.com/v3/__http:/www.symas.com__;!8WoA6RjC81c!WuKVskHw8TTh7xPBLQCayeOo0j= LoA3scmo73fpEyBwOwyP2lAUVT_sk-67s4r6bEJRvo$%20> > Juniper Business Use Only --_000_CH2PR05MB6951111C41162851F03396AEDF810CH2PR05MB6951namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> Hi Quanah,<o:p></o:p> Can we have a solution for the issue reported at = the earliest. Since we have a release and the fix needs to be done. <o:p></o:p> <o:p> </o:p> Thanks, Raji<o:p></o:p> <o:p> </o:p> -----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>et>; openldap-its@Op= enLDAP.org Cc: Muthaiyan Vel <mvel(a)juniper.net> Subject: RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44<o:p></o:p><= /p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> --On Thursday, September 26, 2019 3:11 PM +00= 00 Rajalakshmi Jayaraman <<a href=3D"mailto:jrajalakshmi@juniper.net"><s= pan style=3D"color:windowtext;text-decoration:none">jrajalakshmi(a)juniper.ne= t</a>> wrote:<o:p></o:p> <o:p> </o:p> ><o:p> </o:p> ><o:p> </o:p> > Hi,<o:p></o:p> ><o:p> </o:p> > The FTP <o:p></o:p> > "https://urldefense.com/v3/__ftp://ftp.= openldap.org/incoming/__;!8WoA6<o:p></o:p> > RjC81c!WuKVskHw8TTh7xPBLQCayeOo0jLoA3scmo73f= pEyBwOwyP2lAUVT_sk-67s4ryH<o:p></o:p> > U5-Z3$ " is not working. Hence pasted t= he pcap details, hope this <o:p></o:p> > helps<o:p></o:p> <o:p> </o:p> It's working just fine:<o:p></o:p> <o:p> </o:p> quanah@ub18:~$ ftp <a href=3D"ftp://ftp.openldap.= org">ftp.openldap.org= </a><o:p></o:p> Connected to <a href=3D"http://www.openldap.org">= www.openldap.org</spa= n></a>.<o:p></o:p> 220 ProFTPD 1.3.4a Server (gauss) [::ffff:23.92.2= 7.230] Name (<a href=3D"ftp://ftp.openldap.org:quanah">ftp.openldap.org:quanah</a>): ftp<= o:p></o:p> 331 Anonymous login ok, send your complete email = address as your password<o:p></o:p> Password:<o:p></o:p> 230 Anonymous access granted, restrictions apply = Remote system type is UNIX.<o:p></o:p> Using binary mode to transfer files.<o:p></o:p></= p> ftp> pass<o:p></o:p> Passive mode on.<o:p></o:p> ftp> cd incoming<o:p></o:p> 250 CWD command successful<o:p></o:p> ftp> mkdir its9088<o:p></o:p> 257 "/incoming/its9088" - Directory suc= cessfully created<o:p></o:p> ftp> cd its9088<o:p></o:p> 250 CWD command successful<o:p></o:p> ftp> lcd /tmp<o:p></o:p> Local directory now /tmp<o:p></o:p> ftp> put blah<o:p></o:p> local: blah remote: blah<o:p></o:p> 227 Entering Passive Mode (23,92,27,230,156,55).<= o:p></o:p> 150 Opening BINARY mode data connection for blah<= o:p></o:p> 226 Transfer complete<o:p></o:p> ftp><o:p></o:p> <o:p> </o:p> <o:p> </o:p> --<o:p></o:p> <o:p> </o:p> Quanah Gibson-Mount<o:p></o:p> Product Architect<o:p></o:p> Symas Corporation<o:p></o:p> Packaged, certified, and supported LDAP solutions= powered by OpenLDAP:<o:p></o:p> <<a href=3D"https://urldefense.com/v3/__http:/= www.symas.com__;!8WoA6RjC81c!WuKVskHw8TTh7xPBLQCayeOo0jLoA3scmo73fpEyBwOwyP= 2lAUVT_sk-67s4r6bEJRvo$%20">https://urldefense.com/v3/__http://www.symas.com__;!8WoA6RjC81c!WuKV= skHw8TTh7xPBLQCayeOo0jLoA3scmo73fpEyBwOwyP2lAUVT_sk-67s4r6bEJRvo$ </a>><o:p></o:p> <o:p> </o:p> Juniper Business Use Only</span= ><o:p></o:p> </div> </body> </html> --_000_CH2PR05MB6951111C41162851F03396AEDF810CH2PR05MB6951namp_--

1 0

RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44
by quanah＠symas.com 26 Sep '19

26 Sep '19

--On Thursday, September 26, 2019 3:11 PM +0000 Rajalakshmi Jayaraman <jrajalakshmi(a)juniper.net> 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@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: <http://www.symas.com>

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs