[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites



On 10/05/2012 02:12 PM, quanah@zimbra.com wrote:
> --On Friday, October 05, 2012 2:11 AM +0000 richm@stanfordalumni.org wrote:
>
>>> Certainly, here's a recent example:
>>> <https://www.openldap.org/lists/openldap-technical/201210/msg00024.html>
>> 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

https://www.openldap.org/lists/openldap-technical/201210/msg00024.html
"
# 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 
minutes.
"

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 
http://www.openldap.org/software/release/changes.html
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 
with hanging.

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 - 
https://bugzilla.redhat.com/buglist.cgi?list_id=641623&classification=Red%20Hat&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&component=openldap&product=Red%20Hat%20Enterprise%20Linux%206

Here is the current Fedora openldap bug list - 
https://bugzilla.redhat.com/buglist.cgi?list_id=641625&classification=Fedora&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&component=openldap&product=Fedora

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
>
> --
>
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> --------------------
> Zimbra ::  the leader in open source messaging and collaboration
>
>