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. > 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 > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20081114/220103f4/attachment.bin
