Bug 708967

Summary: dirsrv fails to start during setup
Product: [Fedora] Fedora Reporter: Andreas-Johann Ulvestad <aj>
Component: 389-ds-baseAssignee: Rich Megginson <rmeggins>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 15CC: ckannan, dwalsh, edewata, nhosoi, nkinder, rmeggins
Target Milestone: ---Keywords: screened
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-01 16:45:34 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Andreas-Johann Ulvestad 2011-05-30 05:45:19 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):

How reproducible:
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.
Comment 1 Rich Megginson 2011-05-31 11:31:02 EDT
Is this a bug in F15 rpm or rpmbuild?  Note that we have this in the spec file for 389-ds-base on f15:
BuildRequires:    svrcore-devel
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
Comment 2 Nathan Kinder 2011-05-31 16:41:10 EDT
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.
Comment 3 Daniel Walsh 2011-06-01 09:53:35 EDT
/var/lock being mislabeled has nothing to do with dirsrv, it is a problem with restorecon and the way anaconda installs are happening.
Comment 4 Nathan Kinder 2011-06-01 11:13:39 EDT
(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.
Comment 5 Daniel Walsh 2011-06-01 13:44:23 EDT
Comment 6 Nathan Kinder 2011-06-01 16:45:34 EDT
(In reply to comment #5)
> 701575

Thanks.  Marking this bug as a duplicate.

*** This bug has been marked as a duplicate of bug 701575 ***