4 ms·

Those who've been following OpenLDAP-technical long enough know that the project's support policy is very much at odds with the way in which classic Linux distr

Those who've been following OpenLDAP-technical long enough know that the project's support policy is very much at odds with the way in which classic Linux distros work. The recommendation from the maintainers has always (or at least for a long time) been that one should skip distro-provided server packages and install the latest release from tarballs or third-party packages, with the implication, or sometimes rather direct assertions, that the distros are doing a bad job of maintaining and packaging the server. The fact that RH builds use MozNSS instead of OpenSSL, a constant source of low-level friction and intermittent breakage, doesn't help matters. (Likewise, Debian builds OpenLDAP with GnuTLS.) So, my impression is that OpenLDAP and RH never had good cooperation. Since LDAP is a rather niche protocol/ecosystem these days (a pity, IMO, but that's how it is), I'm not surprised that RH felt confident in ditching a component which they couldn't maintain to anyone's satisfaction, especially given that they have their own server, which is not as good but good enough.

hyc_symas 8y ago
RH's insistence on using MozNSS was certainly a point of contention, since MozNSS was absolutely unsuitable for the purpose and unfit for use. http://mozilla.6506.n7.nabble.com/Comparison-of-OpenSSL-and-NSS-tp196021p196029.html http://mozilla.6506.n7.nabble.com/Comparison-of-OpenSSL-and-... https://bugzilla.redhat.com/show_bug.cgi?id=502133 https://bugzilla.redhat.com/show_bug.cgi?id=502133 https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX Not that we didn't try. We went out of our way to support that crap. Despite the inadequacies of the API I wrote the code to support it. http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=history;f=libraries/libldap/tls_m.c;h=95bcd3cad62e2c73de56b47e84aa7025b3b7d0fd;hb=HEAD http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=hi... We bent over backwards to support their crap. Which is more than can be said in return. https://bugzilla.mozilla.org/show_bug.cgi?id=480174 https://bugzilla.mozilla.org/show_bug.cgi?id=480174
ti_ranger 8y ago
> The fact that RH builds use MozNSS instead of OpenSSL, a constant source of low-level friction and intermittent breakage, doesn't help matters. (Likewise, Debian builds OpenLDAP with GnuTLS.) But, IIRC, the Debian developers did some work on addressing the gaps, whereas the RH/moznss guys just put their fingers in their ears and said "nobody needs well-performing SSL handling in a server context like OpenSSL provides", and all of their contributions focused purely on the OpenLDAP client-side. For a long time, I provided builds of OpenLDAP for RHEL3/4/5, and finally on RHEL7 RH's packages were recent enough and didn't have too many mozNSS-related problems to be usable out-the-box in our large OpenLDAP deployment. I'll have to give the guys who are still there a heads-up and consider reviving my RPM rebuilds for RHEL.
kakwa_ 8y ago
Quanah Gibson-Mount and Howard Chu can be quite aggressive at times in Debian tickets: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725091 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725091 > Distribution packages are not meant to be used for production services. You have to have balls to put in a ticket something that basically amounts to: "what you are doing is useless, people should be recompiling everything". And while while searching for this ticket, I also can across a few others like that. But at least, there are active on downstream tickets...

hyc_symas 8y ago

RH's insistence on using MozNSS was certainly a point of contention, since MozNSS was absolutely unsuitable for the purpose and unfit for use. http://mozilla.6506.n7.nabble.com/Comparison-of-OpenSSL-and-NSS-tp196021p196029.html http://mozilla.6506.n7.nabble.com/Comparison-of-OpenSSL-and-... https://bugzilla.redhat.com/show_bug.cgi?id=502133 https://bugzilla.redhat.com/show_bug.cgi?id=502133 https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX Not that we didn't try. We went out of our way to support that crap. Despite the inadequacies of the API I wrote the code to support it. http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=history;f=libraries/libldap/tls_m.c;h=95bcd3cad62e2c73de56b47e84aa7025b3b7d0fd;hb=HEAD http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=hi... We bent over backwards to support their crap. Which is more than can be said in return. https://bugzilla.mozilla.org/show_bug.cgi?id=480174 https://bugzilla.mozilla.org/show_bug.cgi?id=480174

ti_ranger 8y ago

> The fact that RH builds use MozNSS instead of OpenSSL, a constant source of low-level friction and intermittent breakage, doesn't help matters. (Likewise, Debian builds OpenLDAP with GnuTLS.) But, IIRC, the Debian developers did some work on addressing the gaps, whereas the RH/moznss guys just put their fingers in their ears and said "nobody needs well-performing SSL handling in a server context like OpenSSL provides", and all of their contributions focused purely on the OpenLDAP client-side. For a long time, I provided builds of OpenLDAP for RHEL3/4/5, and finally on RHEL7 RH's packages were recent enough and didn't have too many mozNSS-related problems to be usable out-the-box in our large OpenLDAP deployment. I'll have to give the guys who are still there a heads-up and consider reviving my RPM rebuilds for RHEL.

kakwa_ 8y ago

Quanah Gibson-Mount and Howard Chu can be quite aggressive at times in Debian tickets: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725091 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725091 > Distribution packages are not meant to be used for production services. You have to have balls to put in a ticket something that basically amounts to: "what you are doing is useless, people should be recompiling everything". And while while searching for this ticket, I also can across a few others like that. But at least, there are active on downstream tickets...