Description of problem: On a Fedora 9 Beta system, installed fedora-ds-base (NVR below). Ran setup-ds.pl to initialize the directory server. Did a Typical setup using an account called dirsrv as both user and group for the server. See attached log for typescript containing output of setup-ds.pl as well as output from ldapsearch command used on ns-slapd run both with and without the -d parameter. When running ns-slapd without -d parameter, password auth (-x param) does not work for the ldapsearch/ldapmodify commands. If I run the server manually with -d 0, the password auth succeeds. Version-Release number of selected component (if applicable): fedora-ds-base-1.1.0.1-3.fc9.x86_64 How reproducible: Every time Steps to Reproduce: 1. Start with Fedora 9 Beta, install fedora-ds-base 2. Run setup-ds.pl and use default values for most options (see exceptions in attachment) 3. Run ldapsearch as shown in the attachment while ns-slapd is running without the -d parameter. Actual results: ldap_bind: Invalid credentials (49) Expected results: pass auth should succeed and the search should work Additional info:
Created attachment 299738 [details] typescript output of running setup-ds.pl and ldapsearch commands
Posted this /etc/init.d/dirsrv patch on IRC... If you apply this change, things work fine. But we obviously don't want to be forced to run in debug mode permanently. diff -Naur 1/etc/init.d/dirsrv 2/etc/init.d/dirsrv --- 1/etc/init.d/dirsrv 2008-03-31 13:24:00.000000000 -0400 +++ 2/etc/init.d/dirsrv 2008-03-31 13:23:52.000000000 -0400 @@ -156,7 +156,7 @@ # init config environment will not apply to any other instance ( [ -f /etc/sysconfig/dirsrv-$instance ] && . /etc/sysconfig/dirsrv-$instance - $exec -D $instbase/slapd-$instance -i $pidfile -w $startpidfile + ( $exec -D $instbase/slapd-$instance -i $pidfile -w $startpidfile -d 0 & ) > /dev/null 2>&1 < /dev/null ) if [ $? -eq 0 ]; then server_started=1 # well, perhaps not running, but started ok
The problem is that NSS 3.11.99 requires the application to call fork() _before_ calling NSS_Initialize, for security reasons. ds calls fork() _after_ calling NSS_Initialize(). The fix will be a little bit tricky since we need to call NSS_Initialize after the fork, but before detaching from the controlling process, in case NSS needs to prompt on stdin for the tokens' passwords.
Created attachment 300273 [details] diffs
Created attachment 300347 [details] cvs commit log Reviewed by: nkinder (Thanks!) Files: see diff Branch: HEAD Fix Description: The new softokn in NSS 3.11.99 and later requires that the server calls NSS_Init() after forking, but before detaching from the controlling terminal. In fact, this was always a requirement, but the softokn in older NSS allow it. However, it's possible that some hardware crypto devices do not allow this and may not work with older directory servers. The fix is to move the nss/ssl initialization so that it can be called at the right point, or from other points in cases where the server does not fork (e.g. db2ldif). Platforms tested: Fedora 9 i386, RHEL5 x86_64 Flag Day: no Doc impact: no
Based on comment#7, marking the bug as VERIFIED