openldap-devel February 2016

openldap-devel@openldap.org

7 participants
6 discussions

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

Fwd: LMDB and text encoding
by Timur Kristóf 07 Jun '17

07 Jun '17

> I just had a look at how BDB handled this. As you can see they used a > TO_TSTRING macro to convert incoming pathnames from UTF8 to UTF16. > > https://gitorious.org/berkeleydb/berkeleydb/source/347d239a1e44ed4f773ae927… > > https://gitorious.org/berkeleydb/berkeleydb/source/347d239a1e44ed4f773ae927… > > (And a FROM_TSTRING for the reverse, as well.) (Mea culpa, I accidentally hit "reply" instead of "reply all". Sorry. Now reposting to the mailing list.) Since we only need to do this on Windows, we could use MultiByteToWideChar with CP_UTF8. (That's what TO_TSTRING does, too.) I do not think we would ever need to do any such conversion on UNIX. https://msdn.microsoft.com/en-us/library/windows/desktop/dd319072%28v=vs.85… I'm not sure if we can just copy-paste BDB's code. Probably not, that would lead to licensing issues, wouldn't it?

4 16

Performance degredation between 2.4.39 and 2.4.44
by Quanah Gibson-Mount 15 Mar '16

15 Mar '16

I've noticed a bit of a performance degradation between the 2.4.39 release and 2.4.44, when doing searches that require ACL processing (anonymous or authenticated user). To test, I set up my server with 2.4.39, freshly load the DB, reboot, and then do a query of each type to ensure its data set is fully loaded in memory, and then get timing on the subsequent searches. The server is idle other than my searches. Overall, there's about a 30 second consistent degradation in search results, regardless of whether or not ACLs are involved. It works out to about a 15% degredation for authenticated queries, and a 32% degredation for rootdn searches. Results are as follows: 2.4.39 anonymous search (only returns some data, subject to ACL processing): zimbra@zre-ldap001:~$ time ldapsearch -x -h zre-ldap001.eng.zimbra.com >/dev/null real 3m25.871s user 1m43.872s sys 0m45.254s zimbra@zre-ldap001:~$ time ldapsearch -x -h zre-ldap001.eng.zimbra.com >/dev/null real 3m22.730s user 1m39.575s sys 0m26.400s zimbra@zre-ldap001:~$ time ldapsearch -x -h zre-ldap001.eng.zimbra.com >/dev/null real 3m23.506s user 1m41.919s sys 0m25.968s 2.4.44 anonymous search (only returns some data, subject to ACL processing): zimbra@zre-ldap001:~$ time ldapsearch -x -h zre-ldap001.eng.zimbra.com >/dev/null real 3m54.841s user 1m36.754s sys 0m44.509s zimbra@zre-ldap001:~$ time ldapsearch -x -h zre-ldap001.eng.zimbra.com >/dev/null real 3m56.609s user 1m37.875s sys 0m48.151s zimbra@zre-ldap001:~$ time ldapsearch -x -h zre-ldap001.eng.zimbra.com >/dev/null real 3m53.275s user 1m36.293s sys 0m45.131s 2.4.39 authenticated search (returns all data, subject to ACL processing): zimbra@zre-ldap001:~$ time ldapsearch -x -h zre-ldap001.eng.zimbra.com -D uid=zimbra,cn=admins,cn=zimbra -w zimbra >/dev/null real 3m23.057s user 1m59.358s sys 0m35.809s zimbra@zre-ldap001:~$ time ldapsearch -x -h zre-ldap001.eng.zimbra.com -D uid=zimbra,cn=admins,cn=zimbra -w zimbra >/dev/null real 3m23.478s user 2m0.236s sys 0m26.972s zimbra@zre-ldap001:~$ time ldapsearch -x -h zre-ldap001.eng.zimbra.com -D uid=zimbra,cn=admins,cn=zimbra -w zimbra >/dev/null real 3m22.965s user 1m58.245s sys 0m28.030s 2.4.44 authenticated search (returns all data, subject to ACL processing): zimbra@zre-ldap001:~$ time ldapsearch -x -h zre-ldap001.eng.zimbra.com -D uid=zimbra,cn=admins,cn=zimbra -w zimbra >/dev/null real 3m57.967s user 1m56.335s sys 0m49.483s zimbra@zre-ldap001:~$ time ldapsearch -x -h zre-ldap001.eng.zimbra.com -D uid=zimbra,cn=admins,cn=zimbra -w zimbra >/dev/null real 3m57.405s user 1m55.415s sys 0m50.772s zimbra@zre-ldap001:~$ time ldapsearch -x -h zre-ldap001.eng.zimbra.com -D uid=zimbra,cn=admins,cn=zimbra -w zimbra >/dev/null real 3m57.717s user 1m57.427s sys 0m41.401s 2.4.39 rootdn search (no ACL processing): zimbra@zre-ldap001:~$ time ldapsearch -x -h zre-ldap001.eng.zimbra.com -D cn=config -w zimbra >/dev/null real 1m20.718s user 1m14.501s sys 0m6.164s zimbra@zre-ldap001:~$ time ldapsearch -x -h zre-ldap001.eng.zimbra.com -D cn=config -w zimbra >/dev/null real 1m19.569s user 1m13.557s sys 0m5.935s zimbra@zre-ldap001:~$ time ldapsearch -x -h zre-ldap001.eng.zimbra.com -D cn=config -w zimbra >/dev/null real 1m20.488s user 1m14.514s sys 0m5.917s 2.4.44 rootdn search (no ACL processing): zimbra@zre-ldap001:~$ time ldapsearch -x -h zre-ldap001.eng.zimbra.com -D cn=config -w zimbra >/dev/null real 1m57.199s user 1m10.855s sys 0m14.161s zimbra@zre-ldap001:~$ time ldapsearch -x -h zre-ldap001.eng.zimbra.com -D cn=config -w zimbra >/dev/null real 1m58.030s user 1m10.797s sys 0m14.970s zimbra@zre-ldap001:~$ time ldapsearch -x -h zre-ldap001.eng.zimbra.com -D cn=config -w zimbra >/dev/null real 1m57.754s user 1m10.069s sys 0m15.336s --Quanah -- Quanah Gibson-Mount Platform Architect, Manager Release Engineering Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

2 6

Supported backends/overlays in 2.5
by Quanah Gibson-Mount 03 Mar '16

03 Mar '16

For 2.5, it would be good to take a look at existing backends and overlays we ship as supported, and see if there are any we want to retire. I think it would be nice as well to make it so people could configure in various contrib modules via configure flags, rather than the current manual make process. I'll start with my thoughts: backends: I would like to see us retire slapd-bdb and slapd-hdb. We first documented they were deprecated in March of 2013 and updated the man pages to officially note that in May of 2014. Nearly 2 years have passed since then, and it'll likely be at least another year before 2.5 is production ready. That's some 3 years. In addtion, both slapd-bdb and slapd-hdb depend on BDB versions that are not supported by Oracle, and the source to which Oracle is doing its best to remove and make inaccessible. Another possibility is back-perl. back-sock is a better solution. OTOH, We have gotten contributions fixing issues in it as recently as April 2015, so there may be folks using it who would like to see it continue. overlays: I'd like to see the passwd/sha2 overlay be considered for promotion. Having the ability to set strong hashes for passwords is crucial in todays world. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

6 9

Re: RE24 testing call #1 (2.4.44) LMDB RE0.9 testing call #2 (0.9.18)
by Abdelkader Chelouah 05 Feb '16

05 Feb '16

git bd5e44c9ee9108b26053a0d03a587dda94c4ebe9 All tests run through without error on CentOS 7.2 x86_64 for hdb (bdb 5.1.29) and mdb. On Wed, Feb 3, 2016 at 10:47 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > Changes since testing call #1: > > Fixed slapo-syncprov ctxcsn snapshot on refresh (ITS#8281, ITS#8365) > > --Quanah > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > A division of Synacor, Inc > >

1 0

RE24 testing call #1 (2.4.44) LMDB RE0.9 testing call #2 (0.9.18)
by Quanah Gibson-Mount 04 Feb '16

04 Feb '16

Changes since testing call #1: Fixed slapo-syncprov ctxcsn snapshot on refresh (ITS#8281, ITS#8365) --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel February 2016