Red Hat Bugzilla – Full Text Bug Listing
|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>|
|Version:||15||CC:||ckannan, dwalsh, edewata, nhosoi, nkinder, rmeggins|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-06-01 16:45:34 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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): 184.108.40.206-1 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