openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#8859) Support backends without a database
by ondra＠mistotebe.net 22 May '18

22 May '18

On Tue, May 22, 2018 at 09:03:28AM +0000, h.b.furuseth(a)usit.uio.no wrote: > On 21. mai 2018 17:07, ondra(a)openldap.org wrote: >> In order to support the load balancer within the slapd process and integrate >> correctly, we declare it to be a backend as that is the best match - allows us >> to register all the callbacks that a subsystem like this needs. (...) > > Please comment SLAP_BFLAG_STANDALONE, explaining this, even though that goes > against the surrounding coding style:-( Also maybe struct BackendInfo could > use a comment about database backends vs database-less backends. I've put a comment there. As for BackendInfo, there should be no difference as far as I understand. But there is probably quite a bit of context I'm still missing. -- 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#8859) Support backends without a database
by h.b.furuseth＠usit.uio.no 22 May '18

22 May '18

On 21. mai 2018 17:07, ondra(a)openldap.org wrote: > In order to support the load balancer within the slapd process and integrate > correctly, we declare it to be a backend as that is the best match - allows us > to register all the callbacks that a subsystem like this needs. (...) Please comment SLAP_BFLAG_STANDALONE, explaining this, even though that goes against the surrounding coding style:-( Also maybe struct BackendInfo could use a comment about database backends vs database-less backends. -- Hallvard

1 0

(ITS#8859) Support backends without a database
by ondra＠openldap.org 21 May '18

21 May '18

Full_Name: Ondrej Kuznik Version: master OS: URL: https://github.com/mistotebe/openldap/tree/ITS8859 Submission from: (NULL) (82.10.24.68) In order to support the load balancer within the slapd process and integrate correctly, we declare it to be a backend as that is the best match - allows us to register all the callbacks that a subsystem like this needs. The only problem is that slapd will skip startup for backends that are not used by at least one database. The linked patch deals with this limitation and a few bugs encountered along the way (some code has not been exercised in a long time and has suffered from some bitrot). The support to provide backend global configuration was nominally present but has never worked with cn=config. The first two patches deal with that. The last patch introduces a new backend flag that indicates that it should be started up even if there is no database using it. IPR notice: The linked files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patches were developed Symas corp. Symas corp. has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Symas corp. to release this work under the following terms. Symas corp. 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.

1 0

(ITS#8858) Walking the thread pool work queue
by ondra＠openldap.org 21 May '18

21 May '18

Full_Name: Ondrej Kuznik Version: master OS: URL: https://github.com/mistotebe/openldap/tree/ITS8858 Submission from: (NULL) (82.10.24.68) During reconfiguration, the load balancer might need to dispose of some resources (connections, ...) as the new configuration invalidates their state. Due to how pool pause is handled in libldap_r, tasks might still be queued in there that reference those objects and need to be de-queued before we resume. Most of the time, it is sufficient to record the cookie from pool_submit2 and use pool_retract. At least in some phases of the load balancer implementation we could have more than one task scheduled for the same object - with reconfiguration being the rare case, optimising for it at the expense of the common case does not feel right. The linked patch is ready for review, it lets the caller examine the tasks with a specified start_routine and have any of them retracted where appropriate.

1 0

Re: (ITS#8852) slapd memory use grows continuously with non-delta syncrepl and modifying groups
by hyc＠symas.com 18 May '18

18 May '18

ryan(a)nardis.ca wrote: > 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 I've run your reproducer and see no memory leak. The response queue will indeed grow without bound if the consumer runs slower than the provider, and doesn't read responses fast enough. But in the case of this test script, eventually the client finishes and the consumer catches up. The provider's process size may not decrease, but that just means the malloc implementation isn't returning freed memory to the kernel - it's not a leak. This can be verified using mleak, and using SIGPROF to snapshot the memory usage of the provider. The simplest way to force the memory use to grow is to first suspend the consumer with SIGSTOP. Let the modify client run to completion. mleak / SIGPROF will show a large amount of memory in use. Resume the consumer with SIGCONT, let it run to completion, and then check with SIGPROF on the provider again - all of the response queue memory is freed. So, conclusively, there is no actual leak. But there's a problem with sustained client modifications when the consumer is too slow. Our options here are to configure a size limit on the response queue, and hang the client when the limit is hit, or to return LDAP_BUSY to the client. Neither of these are very attractive options. Doing batched commits will speed up the consumer, but that feature is only in 2.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#8846) Patch to introduce new LDAP option to ignore hostname checking while verifying certificates in TLS mode
by sudhir.singam＠gmail.com 16 May '18

16 May '18

--000000000000ef2539056c5164f5 Content-Type: text/plain; charset="UTF-8" Hi, Reference to SOAP, where we have the option of SOAP_SSL_SKIP_HOST_CHECK https://www.genivia.com/doc/soapdoc2.html --000000000000ef2539056c5164f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hi,<br><br>Reference to SOAP, where we have the option of= =C2=A0=C2=A0<span style=3D"color:rgb(0,0,0);font-family:inconsolatamedium,m= onospace,serif;font-size:14px;font-style:normal;font-variant-ligatures:norm= al;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-alig= n:left;text-indent:0px;text-transform:none;white-space:normal;word-spacing:= 0px;background-color:rgb(255,255,238);text-decoration-style:initial;text-de= coration-color:initial;float:none;display:inline">SOAP_SSL_SKIP_HOST_CHECK<= /span> <br><br><a href=3D"https://www.genivia.com/doc/soapdoc2.html">https://www.g= enivia.com/doc/soapdoc2.html</a><div><br></div><div><br><div><br></div></di= v></div> --000000000000ef2539056c5164f5--

1 0

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

15 May '18

Hi, Thanks for the reply. For DNS use case, " Operator may make certificates only once in a while (as they cost), and at that point it is not certain that all IP addresses are known. They likely might now only know the current literal address, but the numeric address can change in the lifetime of the certificate Changing /etc/hosts is not possible, as this configuration is not supported for operators. " Still we feel configuration is a good thing, i.e., if one explicitly wants to allow a connection despite of warnings (i.e., has analysed the warning to be a false positive), that should still be acceptable, and not unilaterally bad. Also, one needs to be able to distinguish between =E2=80=9Cnormal=E2=80=9D network (open for everyone), and an operat= or-internal network: requirements for these two are different, and if one library is to serve both, it should be able to handle (=3Dbeing configurable) both use cases. System configuration setup is anyway also done by a human, so if someone wants explicitly disable some checks for automated clients, it is logically similar to a human pressing some =E2=80=9Cacknowledge=E2=80=9D= button. And i don't think the browsers are going to remove it, at most they may move this option to settings. I think nobody wants a monolithic browser that cannot be tailored for user needs, which anyway cannot be anticipated by the browser maker. Whether it is interactive or configuration based does not matter as long as the configuration is there somehow. And the same logic applies also for LDAP ;) But then openLDAP or openSSL is already providing options to ignore some of the certificate errors, for example, i can set SSL verify call back function via LDAP options to ignore certificate CRL errors and continue the connection. So i still wonder why it is not possible in this case and feel it has to be user configurable. Regards, Sudhir, NOKIA

1 0

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

15 May '18

--000000000000d6fc43056c4ba325 Content-Type: text/plain; charset="UTF-8" Hi, --000000000000d6fc43056c4ba325 Content-Type: text/html; charset="UTF-8" <div dir="ltr">Hi,</div> --000000000000d6fc43056c4ba325--

1 0

Re: (ITS#8854) Memory leak in modify transaction case
by quanah＠symas.com 14 May '18

14 May '18

--On Monday, May 14, 2018 2:56 PM +0000 verchaswa(a)mavenir.com wrote: > Full_Name: Verchaswa Sharma > Version: 2.4.11 2.4.11 is nearly 10 years old. Please use a current release of OpenLDAP. This ITS will be closed. If you find the issues exists in the current 2.4.46 release, then follow up and the ITS will be reopened. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8855) Memory leak in modify transaction case
by verchaswa.sharma＠mavenir.com 14 May '18

14 May '18

Full_Name: Verchaswa Sharma Version: 2.4.11 OS: Windriver x86_64 GNU/Linux URL: Submission from: (NULL) (62.168.56.1) Hi, While testing modify for transactions, we observed memory leak in libldap. We ran memtrace found following memory leak. + 27605 1526029632 0x168b0008 4060 @0 memtrace_newhook(void const*, unsigned long) [0x5b1b3d] @1 MallocHook::InvokeNewHookSlow(void const*, unsigned long) [0x7f1cb61648e1] @2 malloc [0x7f1cb616748a] @3 ber_memalloc_x [0x5adf24] @4 ber_realloc [0x5accf4] @5 ber_write [0x5acd82] @6 ber_put_tag [0x5aba2a] @7 ber_put_int_or_enum [0x5abbbf] @8 ber_printf [0x5ac89d] @9 ldap_modify_ext [0x6c46e4] --------------- + 4167 1526297517 0x2b7a9048 136 @0 memtrace_newhook(void const*, unsigned long) [0x5b1b3d] @1 MallocHook::InvokeNewHookSlow(void const*, unsigned long) [0x7f11bb68b8e1] @2 tc_calloc [0x7f11bb68ebf9] @3 ber_memcalloc_x [0x5adf94] @4 ldap_send_server_request [0x6cbfa5] @5 ldap_send_initial_request [0x6cc23d] @6 ldap_modify_ext [0x6c47de] ---------------- + 4169 1526297517 0x2c4672e8 15 @0 memtrace_newhook(void const*, unsigned long) [0x5b1b3d] @1 MallocHook::InvokeNewHookSlow(void const*, unsigned long) [0x7f11bb68b8e1] @2 malloc [0x7f11bb68e48a] @3 ber_memalloc_x [0x5adf24] @4 ber_strdup_x [0x5ae5c2] @5 ldap_control_create [0x6c3d18] ---------------------- + 4171 1526297517 0x2aa8c828 80 @0 memtrace_newhook(void const*, unsigned long) [0x5b1b3d] @1 MallocHook::InvokeNewHookSlow(void const*, unsigned long) [0x7f11bb68b8e1] @2 tc_calloc [0x7f11bb68ebf9] @3 ber_memcalloc_x [0x5adf94] @4 ber_alloc_t [0x5acff1] @5 ldap_alloc_ber_with_options [0x6cb7cf] @6 ldap_modify_ext [0x6c4687] ---------------------------

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