389-ds-base

#586 selinux errors with /usr/sbin/setup-ds-admin.pl
Closed: wontfix Opened by rmeggins.

Closed: wontfix
Reopen Issue

Ticket was cloned from Red Hat Bugzilla (product Fedora EPEL): Bug 767225

Description of problem:
When i run /usr/sbin/setup-ds-admin.pl, script fail with
Creating directory server . . .
/usr/bin/pwdhash-bin: error while loading shared libraries: libslapd.so.0:
cannot open shared object file: No such file or directory
Version-Release number of selected component (if applicable):
389-admin-1.1.23-1.el5
389-ds-base-1.2.9.9-1.el5
How reproducible:
always
Steps to Reproduce:
1.run  /usr/sbin/setup-ds-admin.pl
2.Setup with:
Would you like to continue with set up? yes
Do you agree to the license terms? yes
Would you like to continue? yes
Choose a setup type 2
Computer name `hostname`
System User nobody
System Group nobody
configuration directory server? no
administrator ID admin
Password: foobartmp
Administration Domain foobar.com
Directory server network port 389
Directory server identifier foobar
Suffix "dc=foo,dc=bar,dc=com"
Directory Manager DN  "cn=Manager"
Password: foobartmp
Administration port 9830
Are you ready to set up your servers? [yes]: yes
Actual results:
Creating directory server . . .
/usr/bin/pwdhash-bin: error while loading shared libraries: libslapd.so.0:
cannot open shared object file: No such file or directory
Could not import LDIF file '/tmp/ldifYnRYn3.ldif'.  Error: 32512.  Output:
importing data ...
./ns-slapd: error while loading shared libraries: libslapd.so.0: cannot open
shared object file: No such file or directory
Expected results:
Correctly setup ds
Additional info:

I can't reproduce any errors during install on rhel 6.3 running 389-ds-base-1.2.10.2-15.el6.x86_64.

This is what I did(following the instructions from bug 767225):

[root@cisco-c22m3-01 ~]# getenforce
Enforcing

[1] yum install 389-ds-base
- this installs 389-ds-base-libs
[2] yum erase 389-bs-base
- this leaves 389-ds-base-libs intact.
[3] yum install 389-ds-base
[4] yum install 389-admin
[5] setup-ds.admin.pl

I also tried without 389-admin(step 4), and just running setup-ds.pl.

They both work, and there are no SE linux errors in the audit.log.

Replying to [comment:3 mreynolds]:

I can't reproduce any errors during install on rhel 6.3 running 389-ds-base-1.2.10.2-15.el6.x86_64.

This is what I did(following the instructions from bug 767225):

[root@cisco-c22m3-01 ~]# getenforce
Enforcing

[1] yum install 389-ds-base
- this installs 389-ds-base-libs
[2] yum erase 389-bs-base
- this leaves 389-ds-base-libs intact.
[3] yum install 389-ds-base
[4] yum install 389-admin
[5] setup-ds.admin.pl

I also tried without 389-admin(step 4), and just running setup-ds.pl.

They both work, and there are no SE linux errors in the audit.log.

Ok. Original problem was with 389-ds-base-1.2.9.9 on EL5, so probably platform specific.

Tested 1.2.11.15-20 on RHEL 6.2:

389-ds-base-1.2.11.15-20.el6_4.x86_64
389-ds-base-libs-1.2.11.15-20.el6_4.x86_64
389-admin-1.1.34-1.el6.x86_64
selinux-policy-3.7.19-195.el6_4.12.noarch

Tested 1.3.0.6-1 on Fedora 18 with:

389-ds-base-1.3.0.6-1.fc18.x86_64
389-ds-base-libs-1.3.0.6-1.fc18.x86_64
389-admin-1.1.31-1.fc18.1.x86_64
selinux-policy-3.11.1-97.fc18.noarch

I can not generate any selinux messages installing admin server and DS. I've retested yum installing/removing/reinstalling the packages, and rerunning setup-ds-admin.pl, etc.

This appears to only happen running el5 and 1.2.10.x and earlier

Closing ticket, as this is not an issue with the current supported versions of 389.

Metadata Update from @rmeggins:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.2 - 08/13 (August)

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/586

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Invalid)
Metadata
None
None
None
Normal
needinfo
Community
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.