[Date Prev][Date Next]
Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
On 10/05/2012 02:12 PM, email@example.com wrote:
> --On Friday, October 05, 2012 2:11 AM +0000 firstname.lastname@example.org wrote:
>>> Certainly, here's a recent example:
>> I guess I missed it, but exactly which OpenLDAP release(s) had the fix
>> for this particular problem? That is, how could Red Hat have avoided
>> this problem by rebasing to a later OpenLDAP?
> My guess is it was fixed in 2.4.26 or 2.4.27. There have been numerous
> fixes to cn=config support since 2.4.23, so it is hard to know specifically
> which one fixes the above issue. ;)
I've gone through the entire thread again. I still don't know
1) what caused the hanging problem with slaptest
2) if upgrading to 2.4.32 fixed the problem
# slaptest -v -d 448 -f ./slapd.conf.new -F /etc/openldap/slapd.d
The last step just hangs and does not do anything even after waiting 45
Do you know if there was a specific hanging problem with slaptest used
to convert slapd.conf to slapd.d in 2.4.1-2.4.23 that would have been
fixed by rebasing to 2.4.26-2.4.27? How can you be sure that upgrading
to 2.4.32 will fix the problem that this guy was having? No one asked
him to use gdb to attach to the process to see what was going on. No
one asked him to provide the log output of the -d 448 log level. Is it
possible that his issue was unrelated to the version of openldap he was
using? I guess we'll never know.
I've looked through the list of changes at
I do see several fixes for cn=config/slapd.d issues in 2.4.24 and
later. But I don't see any that look like they have something to do
I would still like to know a specific problem in Red Hat's OpenLDAP,
that has been reported by a customer/user, that would have been avoided
by rebasing. It would be a good data point to present to management to
say "we could have avoided all of these customer problems by rebasing
instead of cherry picking patches".
>>> I will note that Mandriva, at least, continually updates the version
>>> of OpenLDAP they ship, unlike most distributions, so it definitely
>>> isn't all. And my point is, Red Hat could do better, and I'd like to
>>> see them do better. I'd like to see Debian/Ubuntu do better too.
>>> I.e., this isn't specific to Red Hat, but the discussion here is about
>>> Red Hat, and what it can do. I discuss Debian and what it can do
>>> better with the Debian devs on their openldap dev list.
>> Then I'd like to hear what Jan and the other Red Hat OpenLDAP
>> maintainers have to say.
> Ok. One thing I do with Debian is help triage issues that are reported
> there with the upstream ITS system if the issues do not appear to be due to
> the usage of an old version. If there is a simple way to do that with Red
> Hat, I could help there as well.
Here is the current RHEL 6 openldap bug list -
Here is the current Fedora openldap bug list -
If you have a bugzilla account, you can simply add the link to the ITS
as a comment in the bugzilla bug. That would be most appreciated. Thanks!
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> Zimbra :: the leader in open source messaging and collaboration