Bug 708967
Summary: | dirsrv fails to start during setup | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Andreas-Johann Ulvestad <aj> |
Component: | 389-ds-base | Assignee: | Rich Megginson <rmeggins> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 15 | CC: | ckannan, dwalsh, edewata, nhosoi, nkinder, rmeggins |
Target Milestone: | --- | Keywords: | screened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-06-01 20:45:34 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Andreas-Johann Ulvestad
2011-05-30 09:45:19 UTC
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 ? 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. 701575 (In reply to comment #5) > 701575 Thanks. Marking this bug as a duplicate. *** This bug has been marked as a duplicate of bug 701575 *** |