[Fedora-directory-users] "Server failed to start !!!" when installing FDS 1.1.3 in RHEL5.2

[Christopher Waltham]

On Nov 14, 2008, at 11:32 AM, Rich Megginson wrote:

> Christopher Waltham wrote:
>> Thanks for the reply, Rich:
>>
>> On Nov 14, 2008, at 10:59 AM, Rich Megginson wrote:
>>
>>>> [root at falls ~]# /etc/init.d/dirsrv start
>>>> Starting dirsrv:
>>>>   falls...                                               [FAILED]
>>>> *** Warning: 1 instance(s) failed to start
>>>>
>>>> If I manually chmod & chown the /var/run/dirsrv directory, it  
>>>> will start:
>>>>
>>>> [root at falls ~]# chmod 770 /var/run/dirsrv && chown nobody:nobody / 
>>>> var/run/dirsrv
>>>> [root at falls ~]# /etc/init.d/dirsrv start
>>>> Starting dirsrv:
>>>>   falls...                                               [  OK  ]
>>>>
>>>> However, because the setup-ds-admin.pl process never completed,  
>>>> the admin server hasn't been configured (and I don't want to have  
>>>> to do that by hand). Note that I am using nobody:nobody in the  
>>>> FDS installer when asked who I want to run the services as.
>>>>
>>>> When I manually ( chmod 770 /var/run/dirsrv && chown  
>>>> nobody:nobody /var/run/dirsrv ) *before* I run setup-ds-admin.pl  
>>>> I get this error:
>>>>
>>>> [08/11/14:09:00:33] - [Setup] Info Are you ready to set up your  
>>>> servers?
>>>> [08/11/14:09:00:34] - [Setup] Info yes
>>>> [08/11/14:09:00:34] - [Setup] Info Creating directory server . . .
>>>> [08/11/14:09:00:36] - [Setup] Info Your new DS instance 'ldap'  
>>>> was successfully created.
>>>> [08/11/14:09:00:36] - [Setup] Info Creating the configuration  
>>>> directory server . . .
>>>> [08/11/14:09:00:36] - [Setup] Fatal The suffix 'o=NetscapeRoot'  
>>>> already exists.  Config entry DN 'cn="o=NetscapeRoot",cn=mapping  
>>>> tree,cn=config'.
>>>>
>>>> [08/11/14:09:00:36] - [Setup] Fatal Failed to create the  
>>>> configuration directory server
>>>> [08/11/14:09:00:36] - [Setup] Fatal Exiting . . .
>>>>
>>>> Any thoughts? This is getting pretty frustrating :-\
>>> Yes.  The first problem caused the second.  The first problem is  
>>> the permissions on /var/run/dirsrv, which allowed you to get past  
>>> "the point of no return" with setup.  That is, your system is  
>>> already configured to the point that subsequent runs of setup  
>>> think it has been set up correctly.
>>>
>>> Try running ds_removal first - you may have to use the -f argument  
>>> to force removal.
>>
>> Ok, that's done.
>>
>>> Then, try this:
>>> service dirsrv stop # may error if not running - that is ok
>>> service dirsrv-admin stop # may error if not running - that is ok
>>
>> Done.
>>
>>> find /etc/dirsrv /usr/lib/dirsrv /usr/lib64/dirsrv /var -name  
>>> slapd-\*
>>
>> [root at falls sbin]# find /etc/dirsrv /usr/lib/dirsrv /usr/lib64/ 
>> dirsrv /var -name slapd-\*
>> /etc/dirsrv/config/slapd-collations.conf
>> /etc/dirsrv/slapd-falls.removed
>> find: /usr/lib64: No such file or directory
>>
>> This is i386, so that looks fine.
>>
>>> If that list looks ok, do
>>> rm -rf `find /etc/dirsrv /usr/lib/dirsrv /usr/lib64/dirsrv /var - 
>>> name slapd-\*`
>>
>> Done...
>>
>>> Finally, rm everything in /etc/dirsrv/admin-serv EXCEPT  
>>> admserv.conf httpd.conf console.conf nss.conf - do not remove  
>>> these files or the directory
>>
>> Those were the only files in there, so no problem.
>>
>>> Then you should have a clean system to start over with
>>
>> Okay, so I can start again with the setup-ds-admin.pl script?
> Yes.

Hmm, no dice.

Are you ready to set up your servers? [yes]:
Creating directory server . . .
Could not copy file '/etc/dirsrv/config/slapd-collations.conf' to '/ 
etc/dirsrv/slapd-ldap/slapd-collations.conf'.  Error: No such file or  
directory
Error: Could not create directory server instance 'ldap'.
Exiting . . .
Log file is '/tmp/setup8I0wbR.log'

[root at falls config]# ls -al /etc/dirsrv/config/
total 24
drwxr-xr-x 2 root root   4096 Nov 14 11:22 .
drwxrwxr-x 7 root nobody 4096 Nov 14 11:31 ..
-rw-r--r-- 1 root root   3595 Sep 24 21:58 certmap.conf
[root at falls config]#

I'm not sure where that file would have gone?


Chris



>
>> And, I don't mean to be rude, but has the root cause of the problem  
>> been identified? :P I can easily replicate it...
> The root cause is the bogus ownership/permissions on /var/run/dirsrv  
> - the directory server user id (default: nobody) must be able to  
> write to this directory.  We are working to fix this problem.
>>
>>
>> Chris