Hallvard B Furuseth wrote:
matthew sporleder writes:
On 2/26/07, Hallvard B Furuseth h.b.furuseth@usit.uio.no wrote:
Quanah Gibson-Mount writes:
Using vendor packages to run an OpenLDAP server is nearly always a bad idea (Mandriva's a definite exception). There is almost nothing that motivates the vendor to use current releases, or backport stability fixes. There are known problems with the connection code in OL 2.3.27, for example, that were fixed in OpenLDAP 2.3.32. In general, use vendor packages at extreme risk.
Is there something particular which makes this more so for OpenLDAP than other packages, or (...) I had the impression that this was mostly a RedHat issue. (...)
It's more a general problem with the decoupled nature of linux distros. OpenLDAP is simply mentioned a lot on this list. :)
Ouch. Does that mean the way to have a solid system is to check the age of most of its major packages and compile newer ones myself?
Unfortunately, I think this reflects some immaturity of the software. We're still fighting with even the basic definition of the C API. There are other packages in the same situation: I just installed OpenSUSE 10.2 on my laptop yesterday, which is the latest and greatest version there, but it still shipped with old wireless lan drivers, that did not work on my laptop. I had to go download current drivers and firmware and build them manually before I had something usable.
The problems are exacerbated by the clumsy design of the pam_ldap/nss_ldap mechanisms, which cause system-level functionality to pollute user-program namespaces. If distros would take the proper steps to hide the symbols of their dynamically loaded pam/nss modules from user code, then most of the compatibility issues would disappear. (I note that we do this correctly in Symas' CNS packages. Hint, hint.)
I have a feeling that not enough people complain to their distro vendors about these problems, and so the distros continue to pretend the problems don't exist.