Bug 708967 - dirsrv fails to start during setup
Summary: dirsrv fails to start during setup
Keywords:
Status: CLOSED DUPLICATE of bug 701575
Alias: None
Product: Fedora
Classification: Fedora
Component: 389-ds-base
Version: 15
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-30 09:45 UTC by Andreas-Johann Ulvestad
Modified: 2011-06-27 20:51 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-01 20:45:34 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Andreas-Johann Ulvestad 2011-05-30 09:45:19 UTC
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):
1.2.8.3-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 15:31:02 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
?

Comment 2 Nathan Kinder 2011-05-31 20:41:10 UTC
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 13:53:35 UTC
/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 15:13:39 UTC
(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 17:44:23 UTC
701575

Comment 6 Nathan Kinder 2011-06-01 20:45:34 UTC
(In reply to comment #5)
> 701575

Thanks.  Marking this bug as a duplicate.

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


Note You need to log in before you can comment on or make changes to this bug.