--On Wednesday, October 03, 2012 10:42 PM +0000 richm(a)stanfordalumni.org
This is quite off-topic, but I could not resist replying.
Agreed, but Jan opened it up for discussion.
On 10/03/2012 03:29 PM, quanah(a)zimbra.com wrote:
> --On Wednesday, October 03, 2012 8:33 AM +0000 jvcelak(a)redhat.com wrote:
>> I understand that you don't want to support older OpenLDAP versions,
>> builds with non-default libraries, etc. But the users will rather use
>> the package from their distribution, instead of compiling it by
>> themselves. And we cannot support users' builds, because we do not have
>> the sources and the build environment under control. And we cannot
>> rebase the packages freely.
> Redhat needs to come up with a solution to this problem, because they are
> putting their users in a catch-22 situation. Either they get support
> from RedHat for a package that will not work,
There are many Red Hat customers who are happy using the openldap server
that comes with the distribution, and they do escalate problems through
the support they are paying for, and they do get help and fixes that
they pay for.
There are many people who use Red Hat. There are many of those many who
don't use openldap at all. There are many people just now migrating to
RHEL6. My question would be -- Why is Red Hat being reactive instead of
proactive? Upgrade your builds to include the latest patch level. Also,
you may have "many" happy customers using the distribution version, but I
wonder how many would be "happy" if they knew the risks they were being
exposed to because Red Hat will not update the build. Like data loss in
sync replication, etc.
> or they build their own, and can't
> get support from RedHat.
Why should they get support from Red Hat if they build their own (in
which case they have to support it themselves, or use the openldap
community), or install 3rd party software (in which case they should get
support from whoever provided the software)?
You missed my point entirely. My point is they shouldn't have to build it
themselves in the first place. Red Hat, as the provider, should be a
*responsible* entity, and upgrade the build being provided, so none of
their customers get put in the untenable situation they now face. Either
build it themselves to get a working OpenLDAP server and lose Red Hat
support, or deal with the fact that they are provided with a bad build.
> There are reasons new *patch* level releases are
> made. I see zero reason why RedHat cannot update the versions of
> OpenLDAP they ship since the fixes are incremental. No one should be
> running OpenLDAP 2.4.23 as a *production server*.
The openldap in RHEL6 is *not* a *stock* openldap 2.4.23. They are
running 2.4.23 with many patches backported from later openldap
releases. The current version is openldap-2.4.23-26.el6_3.2.x86_64 -
note the "-26" which means a lot more than 26 patches.
Sorry, but the number "26" is quite unimpressive. How many of those 26
patches deal with fixing Red Hat's busted MozNSS bits? Your statement here
is like having a mechanic tell me how much better my vehicle is now because
he replaced one of twelve bad spark plugs.
There have been approximately 450 committed fixes to RE24 since 2.4.23 was
released. So you have about 5% of the fixes in your build. That is just
so very encouraging to hear, isn't it? As a customer, wouldn't you truly
feel that Red Hat was doing its best for you, but grabbing a full 5% of
fixes to OpenLDAP? And lets not forget a fair number of those patches you
have actually have zero to do with OpenLDAP itself, but with MozNSS... So
we're down to what? 3%?
> Keep the RPM version string the
> same, and note the upstream release in the RPM patchlevel, if that is
> necessary, but fix the actual code to be current.
That's not what many Red Hat customers pay for. They pay for very
stable releases with only critical patches applied. The Red Hat
customers that want to use newer versions have many options - use Fedora
(which does track upstream openldap closely), build their own, go to
As is often noted, Fedora is for "bleeding edge". Patch level releases are
not bleeding edge. They are INCREMENTAL FIXES. If Red Hat's goal is to
provide a "stable release", then your current strategy is utterly flawed.
You aren't providing a stable release. Your fixing your distribution to a
*random* release, and then holding all your customers to that release,
regardless of how broken it might be. If your goal is truly to provide a
stable release, then upgrade the patch level. If I was asking you to jump
from 2.3 to 2.4, or 2.4 to 2.5, where the minor level was changing, I'd
agree that would not qualify as stable. I'm not. I'm saying be
responsible, and do right by your customers. Given them actual stable
builds of OpenLDAP, instead of hiding behind this excuse of sticking to a
specific version for "stability". You will notice that the OpenLDAP
foundation does not mark *any* release as "stable". And that is because
people would use that in the same broken fashion Red Hat is applying here.
> This is why the Debian folks *wisely* recommend that people do
> the distribution build for a production server.
Can you point me to a link that has that statement in context?
Absolutely. They were kind enough to contribute it to the OpenLDAP FAQ.
I'm actually surprised you aren't familiar with it at this point, given
that I routinely note it on IRC and the mailing list:
> As long as RedHat keeps up this policy, the only advice ever for
> customers is to build their own RPMs, and get support elsewhere, since
> RedHat clearly can't keep working server versions together for their
Clearly. Except for the many customers who are quite happy.
See above. You say they are happy, but would they actually be happy if
they knew the risks Red Hat was knowingly putting their data under? And in
that "happiness" quotient, are you counting the increasing number of people
emailing the -technical list and asking question on IRC about why their
OpenLDAP build is so broken? I'm think that is likely not the case.
> And then that leads to the question of what exactly they are
> paying RedHat for support for in the first place.
I like how you use "RedHat" instead of "Red Hat".
I like how you avoided addressing my point.
Sr. Member of Technical Staff
A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration