openldap-devel

openldap-devel@openldap.org

1418 discussions

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

Release Maintenance Policy
by Howard Chu 08 Aug '21

08 Aug '21

Planning to post this to -announce soon, any comments? Just a reminder to everyone: the Project has a long-standing policy of doing active development on only one release version at a time. To allow time for migrations we provide some overlap from one release version to the next. E.g., while 2.5 is active we will still provide critical bugfixes for 2.4. Since 2.4 has been around for something like 14 years now people may have forgotten this policy. This is a heads up that with 2.6 due for release in September, all updates to 2.4 will cease at that time. Likewise, when 2.7 is released next year all updates to 2.5 will cease. Also for clarity: We consider "Critical" bugs to include security flaws resulting in unauthorized data disclosure, or unauthorized remote code execution. We do not consider assert() failures or crashes resulting only in Denial of Service as security flaws. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 8

2.5 deprecated backends
by Quanah Gibson-Mount 08 Aug '21

08 Aug '21

For 2.5, we deprecated: back-ndb back-sql back-perl Should these be removed for 2.6? Additionally, I think we should be deleting retired backends out of master. Git is designed for this type of thing, there's no need for them to persist (For example, back-shell). It makes branching new releases a major headache. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 2

ITS#9611
by Quanah Gibson-Mount 06 Aug '21

06 Aug '21

It appears there is an accidental backwards incompatibility with 2.4 where slapd doesn't honor alias names with structural objectClasses. This would be good to fix for 2.5.7 so that it doesn't impact people upgrading from 2.4. It could also cause issues with slapcat of a 2.4 config database with 2.5 slapcat unnecessarily. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

About REP_TEXT_MUSTBEFREED (ITS#6138)
by Hallvard Breien Furuseth 30 Jul '21

30 Jul '21

REP_TEXT_MUSTBEFREED looks like a bad idea, at lest for now: Errors can happen anywhere, and then sr_text is usually set to a string constant. If REP_TEXT_MUSTBEFREED is already set, slapd will then later try to free that constant. To add this flag, first add result.c:rs_replace_text() or something similar, like rs_replace_entry(). Modify all code which modifies sr_text to use this function/macro, and encourage 3rd party code to do the same. Also look at code which copies a SlapReply. Each REP_*_MUSTBEFREED flag and its related data should be managed by a similar function/macro, really. (I tried to add a comment in Github, but that didn't seem to work, so mailing here instead.)

3 4

Re: New logging system ideas
by Howard Chu 18 Jul '21

18 Jul '21

Ondřej Kuzník wrote: > On Wed, Jul 14, 2021 at 03:40:35PM +0100, Howard Chu wrote: >> Howard Chu wrote: >>> Just some initial thoughts on what a new logging daemon should do for us: >> >> Scaling back to something easier for now: >> >> We'll use the existing Debug msgs as-is. The olcLogFile directive will specify the >> path of a local logging file to write to. Currently, writing to this logfile is >> controlled by the -d debuglevel flags, not the -s sysloglevel flags. When a logfile >> is configured, debug messages go to both stderr and the logfile. >> >> We'll add a new option olcLogFileOnly (boolean), which will force messages to only >> go to the logfile (and skip writing any to stderr). Since the point of using the >> local file logging facility is for performance, it will be desirable to avoid this >> double-writing of messages. >> >> We'll add an olcLogFileRotate option that specifies a logfile maxsize and rotation >> interval, in megabytes and hours, respectively. Any message that would cause the >> current logfile to exceed the specified size will cause the file to be closed/rotated/reopened. >> Any message that arrives after the specified number of hours will do likewise. >> Rotated files will be renamed to <logfile>.YYYYMMDDHHMM. > > This sounds too complicated, you'd need to measure time and/or size > written everywhere and all the time. Yes, that's exactly what https://git.openldap.org/openldap/openldap/-/merge_requests/358 does. > Solutions already exist that do this and everyone knows how to use them: > logrotate(8). We just need to register a signal (SIGHUP or SIGUSR1 are > used most often) and freopen(3) the stderr stream in the handler. No > locks needed, job done. The reason we're discussing rotate functionality is because of a requirement that no other system dependencies are needed. So, we can't just tell people to use logrotate. Also, freopen() is not async-signal-safe and so isn't legal inside a signal handler. Nor is it clear that freopen() is atomic within a threaded program. As such, you would still need at least a mutex. -- -- 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

New logging system ideas
by Howard Chu 18 Jul '21

18 Jul '21

Just some initial thoughts on what a new logging daemon should do for us: The primary goal - we want to use a binary message format with as few format conversions as possible between log sender and log processor. I'm thinking that we use message catalogs; we will need a tool to preprocess every logging invocation in the source tree and replace them with a integer messageID. So at runtime only the messageID and the message parameters need to be sent, not any plaintext. The message catalog will be compiled into the binary. When it performs its "openlog" to talk to the logging server, it will send the UUID of its catalog. If the logging server doesn't know this UUID, it will transmit the message catalog to the logging server, before doing anything else. (It may make more sense just to use a SHA hash here instead of a UUID.) This way the logging server will work with any version of the binaries, and we don't need to do special coordination to update message catalogs between revisions. The logging server will just know that a specific catalog is to be used with a particular logging session. The message protocol will be length-prefixed. We may even just use DER, since that would allow us to encode arrays of parameters, and other such stuff. The logging server will write the log messages to disk/network verbatim, doing no parsing at all. It may prefix the records with a log session ID, so that a postprocessor can lookup the catalog that belongs to the session, for dumping out as text. The logging server can store its received catalogs in an LMDB database. The postprocessor can then lookup individual messageIDs in this database, interpolate the parameters, and dump out in text. ... that's what I have so far. It's a bit worrisome because of the additional moving parts: message catalog creator, log server, log postprocessor. There's definitely more complexity here, but most of it is moved out of the runtime hot path, which is the main goal. Suggestions? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

5 12

Bugzilla spam (was: [Issue 9606] New: What is [..])
by Michael Ströder 07 Jul '21

07 Jul '21

HI! This looks like spam to me: https://bugs.openldap.org/show_bug.cgi?id=9606 Please make this bug invisible so nobody clicks on the link. Ciao, Michael.

2 1

Re: New OpenLDAP TLS backend? (wolfSSL)
by Hayden Roche 20 May '21

20 May '21

Hi, Unfortunately, all my time is allocated to other wolfSSL tasks at the moment, so I won't be able to work on this for 2.6. This will probably be the case until a customer of ours comes along requesting a port of OpenLDAP to wolfSSL, as customer demands drive most of our development. If that changes, I will let you know, though. Thanks, Hayden On Thu, May 20, 2021 at 9:56 AM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Thursday, February 25, 2021 1:53 PM -0600 Hayden Roche > <haydenroche5(a)gmail.com> wrote: > > > > > Quanah and Howard, > > > > > > Thanks for your quick replies! I'm glad to hear there's interest in this. > > I think 2.6 is a more realistic target, as I'll need to get my boss to > > allocate time for this work amongst other wolfSSL tasks I've been > > assigned. Look forward to a merge request in the (hopefully near) future! > > The openldap mainline code branch is now open for 2.6 development, so this > would be a good time for work to start on this item for inclusion. > > Regards, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

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-devel