Red Hat Bugzilla – Bug 708967
dirsrv fails to start during setup
Last modified: 2011-06-27 16:51:03 EDT
Description of problem:
389 setup crashes if package svrcore-devel.i686 (file libsvrcore.so.0) is not present. 389-ds-base should have this as a dependency.
Version-Release number of selected component (if applicable):
Install clean machine, install 389-packages, run setup-ds-admin.pl. Complete process, crashes on creating directory server - however, not before actually creating the server so one has to guess what files to delete in order to run the process again.
Is this a bug in F15 rpm or rpmbuild? Note that we have this in the spec file for 389-ds-base on f15:
afaik, rpmbuild is supposed to automatically add dependencies - that is, if I have that build requires above, rpmbuild automatically adds a Requires: libsvrcore.so.0
What is the output of
rpm -q --requires 389-ds-base
I ran into the same problem with setup-ds-admin.pl failing to start the dirsrv instance. It had nothing to do with svrcore though (svrcore was properly pulled in, and svrcore-devel is not needed at runtime).
The problem appears to be selinux related. It looks similar to bug 704889. Basically, /var/lock is incorrectly labeled as var_t when the policy says it should be var_lock_t. Running a "restorecon -R -v /var" fixes it up, but I don't know why things didn't get labeled correctly automatically.
Here is what I did to reproduce the issue:
- Fresh install of F15 x86_64 from the final DVD iso.
- A 'yum update' of the whole system, then a reboot.
- A 'yum install 389-ds' to install the 389 packages.
- Run setup-ds-admin.pl. Setup will fail since /var/lock is labeled as var_t instead of var_lock_t.
I'm cc'ing Dan Walsh to see if he knows why things were not labeled properly in the first place.
/var/lock being mislabeled has nothing to do with dirsrv, it is a problem with restorecon and the way anaconda installs are happening.
(In reply to comment #3)
> /var/lock being mislabeled has nothing to do with dirsrv, it is a problem with
> restorecon and the way anaconda installs are happening.
Is there a bug open against restorecon or anaconda for this issue already? I'd like to record that bug number here for future reference.
(In reply to comment #5)
Thanks. Marking this bug as a duplicate.
*** This bug has been marked as a duplicate of bug 701575 ***