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.
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 ***