Created attachment 389463 [details] Openldap init script patch to fix parameter passing to daemon() function Description of problem: The RHEL-5.5 openldap init script does not handle multiple listen uris correctly. If the openldap configuration requires the salpd daemon to listen on more that one uri, such as ldap:/// and ldaps:/// the deamon does not listen for connections on the second uri. Testing indicated this is a problem with the quoting of parameters passed to the daemon() function.
*** Bug 562846 has been marked as a duplicate of this bug. ***
Well, after some testing I'm pretty sure that this is not really a bug. I've tried openldap-2.3.43-3.el5 and everything works perfectly (-h "ldap:/// ldaps:///"). I see no problem in function daemon() in init script at all. slapd is invoked correctly with quotes around $harg variable. See the relevant part of the script: harg="ldap:///" if grep -q ^TLS /etc/openldap/slapd.conf || test x$SLAPD_LDAPS = xyes ; then harg="$harg ldaps:///" fi if test x$SLAPD_LDAPI = xyes ; then harg="$harg ldapi:///" fi ... cat >> $wrapper <<- EOF exec ${slapd} -h "$harg" -u ${user} $OPTIONS $SLAPD_OPTIONS EOF ... So slapd is executed via wrapper in order to avoid some problems (including quotes): # Build a wrapper script to exec slapd with the right arguments, to # avoid being tripped out by changes or weirdness in how daemon() # handles quoted arguments. What version of openldap has been used?
The problem was originally seen when running RHTS autofs tests that use ldaps://.. in the ldap.conf. I checked out a lab machine and saw that openldap wasn't listening for ldaps requests and the manual change in comment #1 above resolved it. The version of openldap was 2.3.43-9.el5 (RHEL5.5-Server-20100201.0) and the init script wasn't like what you have quoted above. AFAICT 2.3.43-3.el5 is the openldap version from RHRL-5.4 which we know works fine from the QA testing for RHEL-5.4. Why are you using that version when this bug is logged against RHEL-5.5?
Ondrej, you tried an old openldap. This wrapper thing has been removed (see https://bugzilla.redhat.com/show_bug.cgi?id=483356), that's when this bug appeared.
Well, that's interesting... so it's a regression. Okay I have a RHTS test prepared, so let's it run again :-). Thank you both for your help!
RHTS test proposed. See QA Whiteboard. Successfully reproduced and verified via RHTS. * RHEL5.5-Server-20100202.0 (i386, x86_64, ppc, s390x, ia64) * RHEL5.5-Client-20100202.0 (i386, x86_64)
RHTS test proposed. See QA Whiteboard. Successfully reproduced and verified via RHTS. * RHEL5.5-Server-20100202.0 (i386, x86_64, ppc, s390x, ia64) * RHEL5.5-Client-20100202.0 (i386, x86_64) :: [ LOG ] :: Installed: : openldap-2.3.43-9.el5.x86_64 :: [ LOG ] :: Installed: : openldap-2.3.43-9.el5.i386 :: [ PASS ] :: Running 'verify_openssl_client' :: [ PASS ] :: Running 'ldapsearch -H ldap://127.0.0.1 -x -D ... -w x -d1' :: [ FAIL ] :: Running 'ldapsearch -H ldaps://127.0.0.1 -x -D ... -w x -d1' :: [ FAIL ] :: RESULT: Test ... and ... :: [ LOG ] :: Installed: : openldap-2.3.43-12.el5.x86_64 :: [ LOG ] :: Installed: : openldap-2.3.43-12.el5.i386 :: [ PASS ] :: Running 'verify_openssl_client' :: [ PASS ] :: Running 'ldapsearch -H ldap://127.0.0.1 -x -D ... -w x -d1' :: [ PASS ] :: Running 'ldapsearch -H ldaps://127.0.0.1 -x -D ... -w x -d1' :: [ PASS ] :: RESULT: Test
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0198.html