openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

RE: (ITS#8846) Patch to introduce new LDAP option to ignore hostname checking while verifying certificates in TLS mode
by sudhir.singam＠nokia.com 13 May '18

13 May '18

SGksDQoNCktpbmRseSBwbGVhc2UgcmVwbHkuDQoNClJlZ2FyZHMsDQpTdWRoaXIgU2luZ2FtDQoN CkRFTElWRVJJTkcgQkVTVC1JTi1DTEFTUyBQTEFURk9STSBpcyBvdXIgdmlzaW9uDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTaW5nYW0sIFN1ZGhpciAoTm9raWEgLSBJTi9C YW5nYWxvcmUpIA0KU2VudDogV2VkbmVzZGF5LCBNYXkgMDksIDIwMTggMTE6MjYgQU0NClRvOiAn SG93YXJkIENodScgPGh5Y0BzeW1hcy5jb20+OyAnb3BlbmxkYXAtaXRzQE9wZW5MREFQLm9yZycg PG9wZW5sZGFwLWl0c0BPcGVuTERBUC5vcmc+DQpTdWJqZWN0OiBSRTogKElUUyM4ODQ2KSBQYXRj aCB0byBpbnRyb2R1Y2UgbmV3IExEQVAgb3B0aW9uIHRvIGlnbm9yZSBob3N0bmFtZSBjaGVja2lu ZyB3aGlsZSB2ZXJpZnlpbmcgY2VydGlmaWNhdGVzIGluIFRMUyBtb2RlDQoNCkhpLA0KDQpUaGFu a3MgZm9yIHlvdXIgcmVzcG9uc2UuDQoNCkJhc2ljYWxseSBvdXIgdXNlIGNhc2UgY2FuIGJlIGJl bG93IG9yIGFueSBzaW1pbGFyIG9uZSB3aGVyZSB3ZSB3YW50IHRvIGRpc2FibGUgaG9zdG5hbWUg Y2hlY2tpbmcuDQoNCmEpCVdlIHdhbnQgdXNlIHRoZSBzYW1lIGNlcnRzIGZyb20gbXVsdGkgZG9t YWlucw0KYikJV2Ugd2FudCB1c2UgdGhlIHNhbWUgY2VydHMgZm9yIGFsbCBzdWIgZG9tYWlucyB1 bmRlciBhIG1haW4gZG9tYWluLg0KYykJRE5TIHNlcnZlciBpcyBub3Qgc2V0IHVwICAgSS5lLiwg dGhlIGNlcnRpZmljYXRlIGNvdWxkIGJlIGlzc3VlZCB3aXRoIGEgbmFtZSBsaWtlIOKAnG5ldGFj dC5vcGVyYXRvcuKAnSwgYnV0IHdl4oCZZCBiZSB1c2luZyAxMC4yLjMuNywgYW5kIEROUyBoYXMg bm90IGJlZW4gc2V0dXAgaW4gdGhlIG9wZXJhdG9yIGludGVybmFsIG5ldHdvcmsNCg0KQnV0IHdo YXQgd2UgZmVlbCBpcyB0aGF0IHRoZXJlIHNob3VsZCBiZSBhbiBvcHRpb24gdG8gYmUgY2hvc2Vu IGJ5IHVzZXIgdG8gZWl0aGVyIGlnbm9yZSBvciBlbmFibGUgaG9zdG5hbWUgY2hlY2tpbmcuIEFs cmVhZHkgd2Uga25vdyB0aGF0IEhUVFAgY2xpZW50cywgZm9yIGV4YW1wbGUsIGJyb3dzZXJzIHBy b3ZpZGUgc3VjaCBvcHRpb24gdG8gdXNlciBhbmQgaXQncyB1cCB0byB0aGUgdXNlciB0aGF0IHdo ZXRoZXIgdG8gY29udGludWUgY29tbXVuaWNhdGlvbiB0byB0aGUgc2VydmVyIG9yIG5vdCwgaWYg aG9zdG5hbWUgbWlzbWF0Y2ggb2NjdXJzLg0KDQpSRkMgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmMv cmZjMjgxOC50eHQgKGZvciBIVFRQKSBzYXlzIGJlbG93LCB3aGljaCBtZWFucyBmb3IgaW50ZXJh Y3RpdmUgb3IgQVVUT01BVEVEIGNsaWVudHMgb3B0aW9uIHNob3VsZCBiZSBwcm92aWRlZC4NCg0K IiAgIElmIHRoZSBob3N0bmFtZSBkb2VzIG5vdCBtYXRjaCB0aGUgaWRlbnRpdHkgaW4gdGhlIGNl cnRpZmljYXRlLCB1c2VyDQogICBvcmllbnRlZCBjbGllbnRzIE1VU1QgZWl0aGVyIG5vdGlmeSB0 aGUgdXNlciAoY2xpZW50cyBNQVkgZ2l2ZSB0aGUNCiAgIHVzZXIgdGhlIG9wcG9ydHVuaXR5IHRv IGNvbnRpbnVlIHdpdGggdGhlIGNvbm5lY3Rpb24gaW4gYW55IGNhc2UpIG9yDQogICB0ZXJtaW5h dGUgdGhlIGNvbm5lY3Rpb24gd2l0aCBhIGJhZCBjZXJ0aWZpY2F0ZSBlcnJvci4gQXV0b21hdGVk DQogICBjbGllbnRzIE1VU1QgbG9nIHRoZSBlcnJvciB0byBhbiBhcHByb3ByaWF0ZSBhdWRpdCBs b2cgKGlmIGF2YWlsYWJsZSkNCiAgIGFuZCBTSE9VTEQgdGVybWluYXRlIHRoZSBjb25uZWN0aW9u ICh3aXRoIGEgYmFkIGNlcnRpZmljYXRlIGVycm9yKS4NCiAgIEF1dG9tYXRlZCBjbGllbnRzIE1B WSBwcm92aWRlIGEgY29uZmlndXJhdGlvbiBzZXR0aW5nIHRoYXQgZGlzYWJsZXMNCiAgIHRoaXMg Y2hlY2ssIGJ1dCBNVVNUIHByb3ZpZGUgYSBzZXR0aW5nIHdoaWNoIGVuYWJsZXMgaXQuDQoiDQoN ClJGQyBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDUxMyAoTERBUCkgc2F5cyBiZWxv dywgdGhhdCBBVVRPTUFURUQgY2xpZW50IHNob3VsZCBsb2cgZXJyb3IgYnV0IG5vdCBwcm92aWRl IGFueSBjb25maWd1cmFibGUgb3B0aW9uLg0KDQrigJwNCg0KSWYgdGhlIHNlcnZlciBpZGVudGl0 eSBjaGVjayBmYWlscywgdXNlci1vcmllbnRlZCBjbGllbnRzIFNIT1VMRA0KICAgZWl0aGVyIG5v dGlmeSB0aGUgdXNlciAoY2xpZW50cyBtYXkgZ2l2ZSB0aGUgdXNlciB0aGUgb3Bwb3J0dW5pdHkg dG8NCiAgIGNvbnRpbnVlIHdpdGggdGhlIExEQVAgc2Vzc2lvbiBpbiB0aGlzIGNhc2UpIG9yIGNs b3NlIHRoZSB0cmFuc3BvcnQNCiAgIGNvbm5lY3Rpb24gYW5kIGluZGljYXRlIHRoYXQgdGhlIHNl cnZlcidzIGlkZW50aXR5IGlzIHN1c3BlY3QuDQogICBBdXRvbWF0ZWQgY2xpZW50cyBTSE9VTEQg Y2xvc2UgdGhlIHRyYW5zcG9ydCBjb25uZWN0aW9uIGFuZCB0aGVuDQogICByZXR1cm4gb3IgbG9n IGFuIGVycm9yIGluZGljYXRpbmcgdGhhdCB0aGUgc2VydmVyJ3MgaWRlbnRpdHkgaXMNCiAgIHN1 c3BlY3Qgb3IgYm90aC4NCuKAnA0KDQpOb3Qgc3VyZSBob3cgdGhlIEFVVE9NQVRFRCBjbGllbnRz IGRpZmZlciBmb3IgSFRUUCBvciBMREFQLg0KDQpTbyBJIHdvdWxkIGxpa2UgdG8ga25vdyB3aHkg dGhpcyBpcyBub3QgaW1wbGVtZW50ZWQgb3IgY2FuJ3QgYmUgaW1wbGVtZW50ZWQgZm9yIG9wZW5M REFQLg0KDQo=

1 0

Re: (ITS#8853) back-mdb broken on GNU/kFreeBSD
by ryan＠nardis.ca 12 May '18

12 May '18

Never mind. This works for me on a local VM. The build server has a bunch of outdated packages so I'm going to blame that build environment unless proven otherwise. Closing the ITS; sorry for the noise.

1 0

(ITS#8853) back-mdb broken on GNU/kFreeBSD
by ryan＠openldap.org 12 May '18

12 May '18

Full_Name: Ryan Tandy Version: 2.4.46 OS: Debian URL: Submission from: (NULL) (70.66.128.207) Submitted by: ryan On Debian GNU/kFreeBSD (Debian with GNU userland and FreeBSD kernel), liblmdb and back-mdb compile but slapd apparently fails to start. Build log: https://buildd.debian.org/status/fetch.php?pkg=openldap&arch=kfreebsd-amd64… >>>>> Executing all LDAP tests for mdb >>>>> Starting test000-rootdse for mdb... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... 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... ../../../tests/scripts/test000-rootdse: 66: kill: No such process ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>> Test failed >>>>> test000-rootdse failed for mdb This is a low priority issue. Just filing the ITS for tracking. More details to come once I find time to install a VM and compile/run it myself. Probably similar to ITS#8554. Debian bug reference: https://bugs.debian.org/898070

1 0

Re: (ITS#8852) slapd memory use grows continuously with non-delta syncrepl and modifying groups
by ryan＠nardis.ca 12 May '18

12 May '18

bisect identifies c365ac359e9c9b483b934c2a1f0bc552645c32fa as the commit that introduced this behaviour. 003dfbda574f37bbf1a2240f530ff9fa35ab0801 on RE24 (2.4.20) commit c365ac359e9c9b483b934c2a1f0bc552645c32fa Author: Howard Chu <hyc(a)openldap.org> Date: Sun Nov 22 04:42:00 2009 +0000 ITS#6368 use dup'd entries in response queue

1 0

(ITS#8852) slapd memory use grows continuously with non-delta syncrepl and modifying groups
by ryan＠openldap.org 11 May '18

11 May '18

Full_Name: Ryan Tandy Version: 2.4.46 OS: Debian URL: ftp://ftp.openldap.org/incoming/20180511_rtandy_syncrepl-memory-consumer.tgz Submission from: (NULL) (70.66.128.207) Submitted by: ryan When running object-based syncrepl, and making changes to groups, the provider slapd uses more and more memory, apparently without bound. We've discussed this issue before but there was no ITS tracking it specifically. original Debian bug: https://bugs.debian.org/725091 and a possibly related openldap-technical post: https://www.openldap.org/lists/openldap-technical/201503/msg00206.html reproducer: ftp://ftp.openldap.org/incoming/20180511_rtandy_syncrepl-memory-consumer.tgz ./prepare ./runslapd (backgrounds a provider slapd and a consumer slapd) ./modify (makes a number of modifications on the provider) ./clean (kills both slapds and cleans databases) Run top in another terminal and watch the memory growth. On my system, the provider grows to over 3 GB resident and does not shrink even after replication completes. with delta-syncrepl enabled, the producer's RSS is only around 10 MB. Reproduced on Debian unstable with 2.4.46 and glibc malloc (glibc 2.27-3) and tcmalloc_minimal (2.7-1).

1 0

(ITS#8851) Severe warnings
by pbrilius＠gmail.com 10 May '18

10 May '18

Full_Name: Povilas Brilius Version: 2.4.45 OS: Gentoo URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.17.80.180) Excerpt from Gentoo net-nds/openldap build log: * QA Notice: Package triggers severe warnings which indicate that it * may exhibit random runtime failures. * /var/tmp/portage/net-nds/openldap-2.4.45/work/openldap-2.4.45/libraries/libldap/open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url; did you mean ldap_is_ldapi_url? [-Wimplicit-function-declaration] * /var/tmp/portage/net-nds/openldap-2.4.45/work/openldap-2.4.45/libraries/libldap_r/thr_posix.c:93:9: warning: implicit declaration of function pthread_setconcurrency; did you mean pthread_setcanceltype? [-Wimplicit-function-declaration] * /var/tmp/portage/net-nds/openldap-2.4.45/work/openldap-2.4.45/libraries/libldap_r/thr_posix.c:107:9: warning: implicit declaration of function pthread_getconcurrency; did you mean ldap_pvt_thread_get_concurrency? [-Wimplicit-function-declaration] * open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url; did you mean ldap_is_ldapi_url? [-Wimplicit-function-declaration] * /var/tmp/portage/net-nds/openldap-2.4.45/work/openldap-2.4.45/libraries/libldap/open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url; did you mean ldap_is_ldapi_url? [-Wimplicit-function-declaration] * /var/tmp/portage/net-nds/openldap-2.4.45/work/openldap-2.4.45/libraries/libldap_r/thr_posix.c:93:9: warning: implicit declaration of function pthread_setconcurrency; did you mean pthread_setcanceltype? [-Wimplicit-function-declaration] * /var/tmp/portage/net-nds/openldap-2.4.45/work/openldap-2.4.45/libraries/libldap_r/thr_posix.c:107:9: warning: implicit declaration of function pthread_getconcurrency; did you mean ldap_pvt_thread_get_concurrency? [-Wimplicit-function-declaration] * open.c:251:7: warning: implicit declaration of function ldap_is_ldapc_url; did you mean ldap_is_ldapi_url? [-Wimplicit-function-declaration] * Please do not file a Gentoo bug and instead report the above QA * issues directly to the upstream developers of this software. * Homepage: http://www.OpenLDAP.org/

1 0

(ITS#8850) Split thread pool shutdown and destruction
by ondra＠openldap.org 09 May '18

09 May '18

Full_Name: Ondrej Kuznik Version: master OS: URL: https://github.com/mistotebe/openldap/tree/ITS8850 Submission from: (NULL) (82.10.24.68) At the moment, libldap_r only supports one thread pool. Closing and freeing that pool is currently done in a single step. If there is a side thread that wants to schedule work into this global pool, there is currently a (short) window when the thread pool is being destroyed and that thread has not been notified yet (which only happens after the main slapd threads have already finished). If a thread tries to schedule more work to be done, it might trample onto memory/mutexes that have already been released. The linked patch outlines a solution to the problem by separating ldap_pvt_thread_pool_destroy into a part that shuts down the pool and the actual deconstruction. slapd is adapted to call the shutdown at the shutdown point and only destroy the pool after all backends have been closed. Tries to maintain backward compatibility. Any feedback is welcome.

1 0

(ITS#8849) Notify backends of server (un)pause
by ondra＠openldap.org 09 May '18

09 May '18

Full_Name: Ondrej Kuznik Version: master OS: URL: https://github.com/mistotebe/openldap/tree/ITS8849 Submission from: (NULL) (82.10.24.68) If a backend needs to handle its own long-running threads on the side, it might need to be notified to pause while a config modification is underway and when it is finished. This is the case of the load balancer module, which registers itself as a module and maintains its own threads and needs to know when a server (or even its own) reconfiguration is in progress. The linked patches provide one of the possible implementations, they introduce the hooks to pause and unpause the server, use them in bconfig.c and add two new backend hooks that are consulted while this is happening.

1 0

Re: (ITS#8845) Cannot preserve existing controls with new extended operations
by ondra＠mistotebe.net 09 May '18

09 May '18

On Tue, May 08, 2018 at 04:09:12PM +0000, hyc(a)symas.com wrote: > ondra(a)mistotebe.net wrote: >> The issue is actually allowing existing controls to be used with newly >> registered exops, since the only way to declare the compatibility would >> be by re-registering the control. Problem there is that built-in >> controls have everything static to controls.c, so it's not even possible >> to do that. >> >> A solution would be to add another piece of API that receives a pair of >> (control OID, exop OID), finds the control and adds the OID to the >> sc_extendedops(bv) lists. >> >> Going to do just that (register_control_exop() a decent name?). This implementation is in the ITS8845 branch of my GitHub repo: https://github.com/mistotebe/openldap/tree/ITS8845 -- 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#8846) Patch to introduce new LDAP option to ignore hostname checking while verifying certificates in TLS mode
by sudhir.singam＠nokia.com 08 May '18

08 May '18

SGksDQoNClRoYW5rcyBmb3IgeW91ciByZXNwb25zZS4NCg0KQmFzaWNhbGx5IG91ciB1c2UgY2Fz ZSBjYW4gYmUgYmVsb3cgb3IgYW55IHNpbWlsYXIgb25lIHdoZXJlIHdlIHdhbnQgdG8gZGlzYWJs ZSBob3N0bmFtZSBjaGVja2luZy4NCg0KYSkJV2Ugd2FudCB1c2UgdGhlIHNhbWUgY2VydHMgZnJv bSBtdWx0aSBkb21haW5zDQpiKQlXZSB3YW50IHVzZSB0aGUgc2FtZSBjZXJ0cyBmb3IgYWxsIHN1 YiBkb21haW5zIHVuZGVyIGEgbWFpbiBkb21haW4uDQpjKQlETlMgc2VydmVyIGlzIG5vdCBzZXQg dXAgICBJLmUuLCB0aGUgY2VydGlmaWNhdGUgY291bGQgYmUgaXNzdWVkIHdpdGggYSBuYW1lIGxp a2Ug4oCcbmV0YWN0Lm9wZXJhdG9y4oCdLCBidXQgd2XigJlkIGJlIHVzaW5nIDEwLjIuMy43LCBh bmQgRE5TIGhhcyBub3QgYmVlbiBzZXR1cCBpbiB0aGUgb3BlcmF0b3IgaW50ZXJuYWwgbmV0d29y aw0KDQpCdXQgd2hhdCB3ZSBmZWVsIGlzIHRoYXQgdGhlcmUgc2hvdWxkIGJlIGFuIG9wdGlvbiB0 byBiZSBjaG9zZW4gYnkgdXNlciB0byBlaXRoZXIgaWdub3JlIG9yIGVuYWJsZSBob3N0bmFtZSBj aGVja2luZy4gQWxyZWFkeSB3ZSBrbm93IHRoYXQgSFRUUCBjbGllbnRzLCBmb3IgZXhhbXBsZSwg YnJvd3NlcnMgcHJvdmlkZSBzdWNoIG9wdGlvbiB0byB1c2VyIGFuZCBpdCdzIHVwIHRvIHRoZSB1 c2VyIHRoYXQgd2hldGhlciB0byBjb250aW51ZSBjb21tdW5pY2F0aW9uIHRvIHRoZSBzZXJ2ZXIg b3Igbm90LCBpZiBob3N0bmFtZSBtaXNtYXRjaCBvY2N1cnMuDQoNClJGQyBodHRwOi8vd3d3Lmll dGYub3JnL3JmYy9yZmMyODE4LnR4dCAoZm9yIEhUVFApIHNheXMgYmVsb3csIHdoaWNoIG1lYW5z IGZvciBpbnRlcmFjdGl2ZSBvciBBVVRPTUFURUQgY2xpZW50cyBvcHRpb24gc2hvdWxkIGJlIHBy b3ZpZGVkLg0KDQoiICAgSWYgdGhlIGhvc3RuYW1lIGRvZXMgbm90IG1hdGNoIHRoZSBpZGVudGl0 eSBpbiB0aGUgY2VydGlmaWNhdGUsIHVzZXINCiAgIG9yaWVudGVkIGNsaWVudHMgTVVTVCBlaXRo ZXIgbm90aWZ5IHRoZSB1c2VyIChjbGllbnRzIE1BWSBnaXZlIHRoZQ0KICAgdXNlciB0aGUgb3Bw b3J0dW5pdHkgdG8gY29udGludWUgd2l0aCB0aGUgY29ubmVjdGlvbiBpbiBhbnkgY2FzZSkgb3IN CiAgIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbiB3aXRoIGEgYmFkIGNlcnRpZmljYXRlIGVycm9y LiBBdXRvbWF0ZWQNCiAgIGNsaWVudHMgTVVTVCBsb2cgdGhlIGVycm9yIHRvIGFuIGFwcHJvcHJp YXRlIGF1ZGl0IGxvZyAoaWYgYXZhaWxhYmxlKQ0KICAgYW5kIFNIT1VMRCB0ZXJtaW5hdGUgdGhl IGNvbm5lY3Rpb24gKHdpdGggYSBiYWQgY2VydGlmaWNhdGUgZXJyb3IpLg0KICAgQXV0b21hdGVk IGNsaWVudHMgTUFZIHByb3ZpZGUgYSBjb25maWd1cmF0aW9uIHNldHRpbmcgdGhhdCBkaXNhYmxl cw0KICAgdGhpcyBjaGVjaywgYnV0IE1VU1QgcHJvdmlkZSBhIHNldHRpbmcgd2hpY2ggZW5hYmxl cyBpdC4NCiINCg0KUkZDIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NTEzIChMREFQ KSBzYXlzIGJlbG93LCB0aGF0IEFVVE9NQVRFRCBjbGllbnQgc2hvdWxkIGxvZyBlcnJvciBidXQg bm90IHByb3ZpZGUgYW55IGNvbmZpZ3VyYWJsZSBvcHRpb24uDQoNCuKAnA0KDQpJZiB0aGUgc2Vy dmVyIGlkZW50aXR5IGNoZWNrIGZhaWxzLCB1c2VyLW9yaWVudGVkIGNsaWVudHMgU0hPVUxEDQog ICBlaXRoZXIgbm90aWZ5IHRoZSB1c2VyIChjbGllbnRzIG1heSBnaXZlIHRoZSB1c2VyIHRoZSBv cHBvcnR1bml0eSB0bw0KICAgY29udGludWUgd2l0aCB0aGUgTERBUCBzZXNzaW9uIGluIHRoaXMg Y2FzZSkgb3IgY2xvc2UgdGhlIHRyYW5zcG9ydA0KICAgY29ubmVjdGlvbiBhbmQgaW5kaWNhdGUg dGhhdCB0aGUgc2VydmVyJ3MgaWRlbnRpdHkgaXMgc3VzcGVjdC4NCiAgIEF1dG9tYXRlZCBjbGll bnRzIFNIT1VMRCBjbG9zZSB0aGUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gYW5kIHRoZW4NCiAgIHJl dHVybiBvciBsb2cgYW4gZXJyb3IgaW5kaWNhdGluZyB0aGF0IHRoZSBzZXJ2ZXIncyBpZGVudGl0 eSBpcw0KICAgc3VzcGVjdCBvciBib3RoLg0K4oCcDQoNCk5vdCBzdXJlIGhvdyB0aGUgQVVUT01B VEVEIGNsaWVudHMgZGlmZmVyIGZvciBIVFRQIG9yIExEQVAuDQoNClNvIEkgd291bGQgbGlrZSB0 byBrbm93IHdoeSB0aGlzIGlzIG5vdCBpbXBsZW1lbnRlZCBvciBjYW4ndCBiZSBpbXBsZW1lbnRl ZCBmb3Igb3BlbkxEQVAuDQoNCg==

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs