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=Re...
Here is the current Fedora openldap bug list - https://bugzilla.redhat.com/buglist.cgi?list_id=641625&classification=Fe...
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
-
richm＠stanfordalumni.org