Fwd: 2.5 deprecated backends
by Aapo Romu
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>
>
1 year, 2 months
asserts and manadatory build instructions (was ITS#8240)
by Michael Ströder
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 year, 6 months
2.6 branch created
by Quanah Gibson-Mount
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 year, 9 months
Re: order of <what> clauses in ACLs
by Michael Ströder
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.or...
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. :-)
1 year, 9 months
Release Maintenance Policy
by Howard Chu
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/
1 year, 9 months
2.5 deprecated backends
by Quanah Gibson-Mount
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>
1 year, 9 months
ITS#9611
by Quanah Gibson-Mount
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 year, 9 months
