Prebuilt official openldap packages? (Was: Re: Query performance degrades over time.)

[Christian Haugan Toldnes <christian.toldnes@ntnu.no>]

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



-- 
Christian Haugan Toldnes
Overingeniør, Plattform
IT-avdelingen, NTNU
Tel: (735)98054 Mob: 93060023