openldap-devel

openldap-devel@openldap.org

1416 discussions

Another bogus Usenix report on LMDB failure modes
by Howard Chu 14 Aug '22

14 Aug '22

Yet another paper out of University of Wisconsin researching open source projects like LMDB without communicating with anyone on the project https://www.usenix.org/conference/atc20/presentation/rebello I explain their mistake on Twitter https://twitter.com/hyc_symas/status/1558909442737012736 -- -- 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

Plain syncrepl vs. accesslog aka. ITS#9580
by Ondřej Kuzník 30 Jun '22

30 Jun '22

It's becoming untenable how a plain refresh cannot be represented in accesslog in a way that's capable of serving a deltasync session. Whatever happens, we have lost a fair amount of information to run a proper deltasync yet if we don't want to abandon this functionality, we have to try and fill some in. The current issues: With refreshDeletes=FALSE we get a list of entries in no particular order (each can be tagged with a CSN of the latest change), then have to synthesize a list of deletes with no idea what CSN they belong to at all, the best we can do is pick the whole CSN vector (we certainly *cannot* pick a single CSN for any of them, not even the highest timestamp). If we're receiving refreshDeletes=TRUE, we have lost less information as there are no implied deletes in the normal case where no subtree renames happen to remove a whole subtree from view (we fail here at the moment). Updates are still liable to be returned in arbitrary order, at least we know they're tagged with some sort of CSN, most likely the CSN of the last change to the entry except for entries that have been deleted. Some of the above is due to how the provider decides to send information down to us and we are free to change that. The major gap that the provider cannot fill is deletes implied by present phase ending. The entries deleted there cannot be tagged with a single CSN since we need to remember the whole vector to make a consistent decision whether or not to recreate an entry in the future. Since we do not follow RFC 4533 in many aspects already, e.g. we send cookies in the middle of a refresh, our cookies are often unusable on their own, we can just own up to this and define an extension to the protocol if needed. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

2 6

Patch for SSL ctx
by Michael Ströder 21 May '22

21 May '22

HI! Could someone please review whether this patch makes sense? https://build.opensuse.org/package/view_file/home:firstyear:branches:networ… Ciao, Michael.

2 1

Fwd: 2.5 deprecated backends
by Aapo Romu 28 Mar '22

28 Mar '22

We are heavily utilising back-sql on our product. Granted it has its issues but it does so far fulfill our needs. We are currently running on 2.4.58 which we build ourselves for Debian and RHEL/CentOS based systems. We needed couple of patches to back-sql to make it work for us. I just created issues (and added my patches) for them. I don't have a slightest idea if the patches are of any use for you but they make our environments work. Removing back-sql from future releases would make us stuck with 2.4 release. https://bugs.openldap.org/show_bug.cgi?id=9629 https://bugs.openldap.org/show_bug.cgi?id=9630 --- Aapo Romu --- Software Architect --- Eficode Oy On Mon, 9 Aug 2021 at 00:02, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Sunday, August 8, 2021 6:32 PM +0100 Howard Chu <hyc(a)symas.com> > wrote: > > > Quanah Gibson-Mount wrote: > >> For 2.5, we deprecated: > >> > >> back-ndb > >> back-sql > >> back-perl > >> > >> Should these be removed for 2.6? > > > > I still routinely build back-perl in master. Is there any reason to > > remove it? > > Not necessarily, that's why I started the discussion. back-bdb was > deprecated with 2.3, but was around for all of 2.4 as well. I see no > reason to keep back-ndb around. back-sql has numerous open issues, but > I've no real insight into whether it retains any usefulness. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

3 5

HEADS UP: New release policy
by Howard Chu 20 Jan '22

20 Jan '22

After evaluating our experience with OpenLDAP 2.4 and demands* from e.g. Symas enterprise customers, we're adopting a new release policy which will be posted on -announce shortly. The main objective is to resolve the tension between wanting to release new features as soon as they're available, vs keeping stability over the long term. *i.e., enterprises want to avoid any version updates unless they're for a specific feature they commissioned. We considered resurrecting use of the STABLE tag but that really didn't satisfy, and its use was retired for good reasons. -- -- 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

asserts and manadatory build instructions (was ITS#8240)
by Michael Ströder 04 Nov '21

04 Nov '21

hyc(a)symas.com wrote in ITS#8240: > Our patch response was too hasty. There is no OpenLDAP bug here, the real > issue is production binaries being built with asserts enabled instead of > compiling with -DNDEBUG. That's an issue for packagers and distros to resolve. > Closing this ITS, not an OpenLDAP bug. Maybe I missed something. But this is the first time I've heard about -DNDEBUG being mandatory when compiling binary packages for production use. Does it have other effects? And what are general rules for assert statements in OpenLDAP code? In my own (Python) code assert statements are supposed to be only triggered if something goes wrong *internally* (type issues etc.). If somebody manages to trigger an assert statement with invalid input from "outside" I always consider this to be a serious bug revealing insufficient error handling even though e.g. web2ldap just logs the exception but won't crash. YMMV, but please clarify. I also wonder whether there are more mandatory rules for building packages and where I can find them. Please don't get me wrong: My inquiry is in good faith to avoid unnecessary ITS based on misunderstanding. Ciao, Michael.

1 1

Using mbedtls as a OpenLDAP TLS back-end?
by nickpelling＠nickpelling.com 18 Oct '21

18 Oct '21

Hi everyone, I'm trying to use OpenLDAP as the basis for a C LDAP client on a POSIX-y (but non-Linux) embedded RTOS, and so would like to replace its OpenSSL TLS backend with an mbedtls backend. (Note that mbedtls, as I understand it, was originally developed as a lightweight embedded replacement for OpenSSL.) The hacky answer would be to use a translation layer from OpenSSL to mbedtls (the ESP32's esp-idf code has one of these), but this run the risk of hitting a corner case and getting completely stuck. :-( So... has anyone tried writing a direct mbedtls TLS backend for OpenLDAP? I understand that OpenLDAP had specific licence-related issues with TLS code, and so anything like this might possibly have had to have been developed in a fork under a different licence. Thanks very much, Nick

1 0

Futures wishlist
by Howard Chu 07 Sep '21

07 Sep '21

For a future version 2.x or maybe 3.x but hopefully sooner: The original idea behind sl_malloc / op->o_tmpalloc was to have per-operation memory allocation that never needed an explicit free(), the memory would simply be discarded/reset when the operation finished. This idea has been subverted over time, and the code is now littered with ch_free/tmpfree everywhere, which is exactly what sl_malloc was supposed to eliminate. There was one key problem with the original sl_malloc idea, it only accounted for two types of memory but in practice we really have three: global memory, whose allocations must persist beyond the life of a single operation, per-operation memory, and actual scratch/temporary memory. In a future version I'd like to add an opalloc() function for the per-operation memory. Rationale: most global allocations occur at startup time, processing the config. Generally this stuff never needed explicit freeing because it only went away at shutdown time, but now that we have runtime config with delete support we need to handle that too. The other obvious case is for per-connection state, such as established after a Bind op. Back when we still used BerkeleyDB backends, the backend's various caches would also need global memory. All of these would be allocated using ch_malloc. The per-operation memory is primarily the per-operation ACL cache. The other case that makes sense would be to use it for all per-op callback structures. Overhauling overlays to only use opalloc() for these (instead of the stack, which is frequently being used now) would allow many overlays to work correctly with asynchronous backends. The scratch memory usage remains the most frequently used, typically for DN/attribute normalization, entry construction, etc. For LDAP operations that only affect a single entry, like every operation besides Search, there usually wouldn't be much difference in memory lifetime between opalloc and tmpalloc memory. But for Search, the normal use pattern would be to do a sl_mark() before constructing a search response, send the response, then do an sl_release() before constructing the next response, and so on. ### Another item to overhaul would be the use of op->o_bd->bd_info for invoking backend/overlay functions. Currently we create an entire dummy copy of the original op->o_bd so we can override the bd_info as we walk thru the overlays. That has caused the need for a few other ridiculous things (like bd_self to point back to the real backend structure). We should have just added a new op->o_bdinfo pointer to the Operation struct and left the backend structure alone. This will reduce a bit of pointless memory copying and speed up overlay processing overall. -- -- 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

2.6 branch created
by Quanah Gibson-Mount 17 Aug '21

17 Aug '21

The OpenLDAP 2.6 release branch has been created. master is now open for 2.7 development. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: order of <what> clauses in ACLs
by Michael Ströder 15 Aug '21

15 Aug '21

HI! Moving this thread here to openldap-devel because it's not a usage question anymore: https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/… TL;DR: 1. Would you consider the attached patch as a valid solution? 2. Improving slapo-constraint would also help. On 8/13/21 10:59 AM, Michael Ströder wrote: > On 8/13/21 1:51 AM, Howard Chu wrote: >> Michael Ströder wrote: >>> Let there be ACLs with dn.regex="..", attrs=foo,bar and val.regex=".." >>> in the <what> clauses. >>> >>> Obviously depending on complexity of regex-pattern and length of DNs / >>> avals the regex checking is more expensive than equality checking of attrs=. >>> >>> Can I improve ACL performance by order of <what> clauses or are they >>> processed in fixed order anyway? If in fixed order, which one? >> >> The order is fixed, in order of increasing granularity. DN first, >> attribute next, value-specific last. > > Is this order implemented in function slap_acl_get() in acl.c? > The last seems to be filter= after val=. Right? > >> That is the only order that makes logical sense. > > Why? > > IMHO attrs= should be checked first because > > dn.regex=".." > val.regex=".." > filter=".." > > are all potentially way more CPU-intensive than checking attrs= against > a simple hash-map. First tests (OpenLDAP 2.5/master) show with customer ACLs reading all attrs of 100k user entries and one huge group entry takes 2m23.459s with standard acl.c but only 1m22.718s with patched acl.c which evaluates attrs= before dn.regex= and val.regex=. The reason for improved performance here is that the test data has one really big group entry (100k members) with expensive ACLs on uniqueMember attribute. Thus quickly skipping the ACLs with attrs=uniqueMember saves lots of CPU. Yes, the tests are somewhat artificial and optimizing the clients is also needed. But anyway I'd like to avoid clients accidently causing unneeded load. And I expect this to also improve things for lots of smaller groups in real-world usage. Ciao, Michael. P.S.: The uniqueMember-ACLs are so complex because the original author wanted to work-around deficiencies of slapo-constraint. Have a set-relation for fully checking partical sets would make this problem go away... P.P.S.: Before you ask: These are *not* tests with Æ-DIR ACLs. P.P.P.S: I like the new etime= logging. :-)

2 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel