Howard Chu wrote:
Laurence Field wrote:
Laurence Field wrote:
The answer to this question can probably be gleaned from reading the openldap-devel archives from the time 2.4 was being first prepared for release. A lot of profiling and refactoring went into the 2.4 code to improve performance relative to 2.3. At this point 2.3 is ancient and I've forgotten everything that we've changed internally, and it's not worth my while to dig back to remember what we fixed.
Thanks, will start digging.
Laurence
Just to complete this thread. In the devel list there was quite a bit of discussion about the bdb backend. Debugging suggested that most of the time was spent in the following library.
/usr/lib64/tls/libslapd_db-4.4.so
As a solution, I have just taken the openldap source rpm from Fedora 12 and rebuilt it on CENTOS 5, relocating it to /opt/openldap2.4 and turning off auto-provides.
And now you know why (a) we recommend never using slapd as built by your distro vendor (particularly Red Hat and its derivatives) and (b) we always recommend using the most current code.
As this seems to be the one and only, always true answer, which covers all common openldap server scenarios, I can't help but wonder:
Why are there no pre-built, openldap-crew-certified, latest stable version, auto-updateable packages made available for most common server distros, including RHEL, CentOS, SLES, Ubuntu LTS and Debian Stable?
When software are provided in source form only, the burden of pre-compilation configuration, compilation and quality assurance are placed on the user, which in most cases are less qualified, less informed, and less able to keep up to date with the work. Even more important, the risk of human error are multiplied by the number of users that accept this burden.
The combination of only releasing the software in source form, frequent development in the stable branch (too early too frequent), and continuously stating that vendor provided binary packages should NOT be used, places this software project way down on the list of software we want to include in a production environment, I am sorry to say. Sorry both because the alternatives are still quite expensive, and because openldap is what we currently use on our rather large and critical LDAP cluster.
This LDAP implementation has the potential to be on the very top of the list. But right now, it's found wanting.
I'm quite sure that we are not the only organization willing to pay good money for support contracts that includes up to date packages for our server distributions at any time. Feel free to cash in! :)
Kind regards
c