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, 7 months
Performance degredation between 2.4.39 and 2.4.44
by Quanah Gibson-Mount
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
7 years, 2 months
Supported backends/overlays in 2.5
by Quanah Gibson-Mount
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
7 years, 3 months
LTB Project off the air?
by Brian Reichert
I know this isn't the forum for this, but I can't reach the LTB Project's
website or mail server; traceroutes fall off somewhere in Europe.
I've tried from a few different networks.
Does anyone here any have insight as to what's going on?
--
Brian Reichert <reichert(a)numachi.com>
BSD admin/developer at large
7 years, 3 months
