Log file mentioned at end of failed install.
setupuwBEVH.log

Hi Matt,
Our latest version is 389-admin-1.1.38 and 389-adminutil-1.1.21. They are still in the testing mode, but could you please upgrade yours and try them? Thanks!
http://www.port389.org/docs/389ds/releases/release-admin-1-1-38.html
Fedora packages are available from the EPEL7, Fedora 20, Fedora 21 and Rawhide repositories.
The new packages and versions are:
389-admin-1.1.38-1
389-adminutil-1.1.21-1

It looks you ran into this issue. The fix is in 1.1.36 and newer. I think you had an admin server on the system with SSL enabled (it updates nss.conf), then you removed it and set it up again? The old nss.conf was left with password.conf removed, which caused the re-setup fail. The work around is force to reinstall 389-admin to replace the modified nss.conf (that should not have password.conf in it), then run setup-ds-admin.pl.

commit fa79ba174a410571af6206568877f91ccfe9aa8e
Author: Mark Reynolds mreynolds@redhat.com
Date: Mon Sep 8 16:41:23 2014 -0400
Ticket 47891 - Admin Server reconfig breaks SSL config

Thanks,
--noriko

Replying to [comment:2 nhosoi]:

It looks you ran into this issue. The fix is in 1.1.36 and newer. I think you had an admin server on the system with SSL enabled (it updates nss.conf), then you removed it and set it up again? The old nss.conf was left with password.conf removed, which caused the re-setup fail. The work around is force to reinstall 389-admin to replace the modified nss.conf (that should not have password.conf in it), then run setup-ds-admin.pl.

commit fa79ba174a410571af6206568877f91ccfe9aa8e
Author: Mark Reynolds mreynolds@redhat.com
Date: Mon Sep 8 16:41:23 2014 -0400
Ticket 47891 - Admin Server reconfig breaks SSL config

Thanks,
--noriko

Yes -- I was working on [https://fedorahosted.org/pki/ticket/1144 PKI TRAC Ticket #1144 - pkispawn needs option to specify ca cert for ldap] when I encountered this problem (it was not a blocker as I don't actually require the admin server).

However, after installing the new packages '''389-admin-1.1.38-1''', and '''389-adminutil-1.1.21-1''', and verifying that my '''nss.conf''' was now correct, I still received the following errors:

{{{

rpm -qa | grep 389

389-console-1.1.7-7.fc21.noarch
389-ds-1.2.2-6.fc21.noarch
389-ds-console-doc-1.2.7-4.fc21.noarch
389-admin-console-doc-1.1.8-7.fc21.noarch
389-admin-1.1.38-1.fc21.x86_64
389-admin-console-1.1.8-7.fc21.noarch
389-ds-console-1.2.7-4.fc21.noarch
389-ds-base-1.3.3.8-1.fc21.x86_64
389-adminutil-1.1.21-1.fc21.x86_64
389-dsgw-1.1.11-4.fc21.x86_64
389-ds-base-libs-1.3.3.8-1.fc21.x86_64

setup-ds-admin.pl

. . .
Are you ready to set up your servers? [yes]:
Creating directory server . . .
Your new DS instance 'pki' was successfully created.
Creating the configuration directory server . . .
Beginning Admin Server creation . . .
Creating Admin Server files and directories . . .
Updating adm.conf . . .
Updating admpw . . .
Registering admin server with the configuration directory server . . .
Updating adm.conf with information from configuration directory server . . .
Updating the configuration for the httpd engine . . .
Starting admin server . . .
output: Job for dirsrv-admin.service failed. See "systemctl status dirsrv-admin.service" and "journalctl -xe" for details.
Could not start the admin server. Error: 256
Failed to create and configure the admin server
Exiting . . .
Log file is '/tmp/setupmKAIxe.log'

journalctl -xe

-- Unit UNIT has finished starting up.

-- The start-up result is done.
Mar 12 18:30:05 pki.usersys.redhat.com systemd[8992]: Starting Exit the Session...
-- Subject: Unit UNIT has begun with start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit UNIT has begun starting up.
Mar 12 18:30:05 pki.usersys.redhat.com systemd[8992]: Received SIGRTMIN+24 from PID 9216 (kill).
Mar 12 18:30:05 pki.usersys.redhat.com systemd[8996]: pam_unix(systemd-user:session): session closed for user root
Mar 12 18:30:11 pki.usersys.redhat.com kernel: SELinux: 2048 avtab hash slots, 104716 rules.
Mar 12 18:30:11 pki.usersys.redhat.com kernel: SELinux: 2048 avtab hash slots, 104716 rules.
Mar 12 18:30:11 pki.usersys.redhat.com kernel: SELinux: 8 users, 103 roles, 4987 types, 295 bools, 1 sens, 1024 cats
Mar 12 18:30:11 pki.usersys.redhat.com kernel: SELinux: 83 classes, 104716 rules
Mar 12 18:30:11 pki.usersys.redhat.com kernel: SELinux: Permission audit_read in class capability2 not defined in policy.
Mar 12 18:30:11 pki.usersys.redhat.com kernel: SELinux: the above unknown classes and permissions will be allowed
Mar 12 18:30:12 pki.usersys.redhat.com dbus[2128]: avc: received policyload notice (seqno=61)
Mar 12 18:30:12 pki.usersys.redhat.com dbus[1941]: avc: received policyload notice (seqno=61)
Mar 12 18:30:12 pki.usersys.redhat.com dbus[818]: avc: received policyload notice (seqno=61)
Mar 12 18:30:12 pki.usersys.redhat.com org.a11y.Bus[1941]: Reloaded configuration
Mar 12 18:30:12 pki.usersys.redhat.com dbus[818]: [system] Reloaded configuration
Mar 12 18:30:12 pki.usersys.redhat.com dbus[2128]: avc: received policyload notice (seqno=62)
Mar 12 18:30:12 pki.usersys.redhat.com dbus[1941]: avc: received policyload notice (seqno=62)
Mar 12 18:30:12 pki.usersys.redhat.com dbus[818]: avc: received policyload notice (seqno=62)
Mar 12 18:30:12 pki.usersys.redhat.com org.a11y.Bus[1941]: Reloaded configuration
Mar 12 18:30:12 pki.usersys.redhat.com dbus[818]: [system] Reloaded configuration
Mar 12 18:30:12 pki.usersys.redhat.com kernel: SELinux: 2048 avtab hash slots, 104716 rules.
Mar 12 18:30:12 pki.usersys.redhat.com kernel: SELinux: 2048 avtab hash slots, 104716 rules.
Mar 12 18:30:12 pki.usersys.redhat.com kernel: SELinux: 8 users, 103 roles, 4987 types, 295 bools, 1 sens, 1024 cats
Mar 12 18:30:12 pki.usersys.redhat.com kernel: SELinux: 83 classes, 104716 rules
Mar 12 18:30:12 pki.usersys.redhat.com kernel: SELinux: Permission audit_read in class capability2 not defined in policy.
Mar 12 18:30:12 pki.usersys.redhat.com kernel: SELinux: the above unknown classes and permissions will be allowed
Mar 12 18:30:13 pki.usersys.redhat.com dbus[2128]: avc: received policyload notice (seqno=63)
Mar 12 18:30:13 pki.usersys.redhat.com dbus[1941]: avc: received policyload notice (seqno=63)
Mar 12 18:30:13 pki.usersys.redhat.com dbus[818]: avc: received policyload notice (seqno=63)
Mar 12 18:30:13 pki.usersys.redhat.com org.a11y.Bus[1941]: Reloaded configuration
Mar 12 18:30:13 pki.usersys.redhat.com dbus[818]: [system] Reloaded configuration
Mar 12 18:30:13 pki.usersys.redhat.com setsebool[9440]: The httpd_can_connect_ldap policy boolean was changed to on by root
Mar 12 18:30:13 pki.usersys.redhat.com systemd[1]: dirsrv-admin.service: control process exited, code=exited status=1
Mar 12 18:30:13 pki.usersys.redhat.com systemd[1]: Failed to start 389 Administration Server..
-- Subject: Unit dirsrv-admin.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit dirsrv-admin.service has failed.
--
-- The result is failed.
Mar 12 18:30:13 pki.usersys.redhat.com systemd[1]: Unit dirsrv-admin.service entered failed state.
Mar 12 18:30:13 pki.usersys.redhat.com systemd[1]: dirsrv-admin.service failed.

systemctl status -l dirsrv-admin.service

● dirsrv-admin.service - 389 Administration Server.
Loaded: loaded (/usr/lib/systemd/system/dirsrv-admin.service; disabled)
Active: failed (Result: exit-code) since Thu 2015-03-12 18:30:13 MDT; 2min 17s ago
Process: 9450 ExecStart=/usr/sbin/httpd -k start -f /etc/dirsrv/admin-serv/httpd.conf (code=exited, status=1/FAILURE)

Mar 12 18:30:13 pki.usersys.redhat.com systemd[1]: dirsrv-admin.service: control process exited, code=exited status=1
Mar 12 18:30:13 pki.usersys.redhat.com systemd[1]: Failed to start 389 Administration Server..
Mar 12 18:30:13 pki.usersys.redhat.com systemd[1]: Unit dirsrv-admin.service entered failed state.
Mar 12 18:30:13 pki.usersys.redhat.com systemd[1]: dirsrv-admin.service failed.
}}}

Log file mentioned at end of second failed install.
setupmKAIxe.log

Please attach /var/log/dirsrv/slapd-pki/errors and /var/log/dirsrv/admin-serv/error.

What happends if you start the admin server manually?
systemctl start dirsrv-admin.service

Is ns-slapd up and running?
ps -ef | grep ns-slapd

Admin Server is often sensitive about FQDN.
grep nsslapd-localhost /etc/dirsrv/slapd-pki/dse.ldif

Is the value your host's FQDN?

Replying to [comment:4 nhosoi]:

Please attach /var/log/dirsrv/slapd-pki/errors and /var/log/dirsrv/admin-serv/error.

What happends if you start the admin server manually?
systemctl start dirsrv-admin.service

Job for dirsrv-admin.service failed. See "systemctl status dirsrv-admin.service" and "journalctl -xe" for details.

Is ns-slapd up and running?
ps -ef | grep ns-slapd

Yes, as I was able to finish my ticket:

nobody 12092 1 1 18:45 ? 00:00:25 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-pki -i /var/run/dirsrv/slapd-pki.pid -w /var/run/dirsrv/slapd-pki.startpid
root 20265 8403 0 19:16 pts/0 00:00:00 grep --color=auto ns-slapd

Admin Server is often sensitive about FQDN.
grep nsslapd-localhost /etc/dirsrv/slapd-pki/dse.ldif

Is the value your host's FQDN?

yes, that is my host's FQDN

attaching /var/log/dirsrv/slapd-pki/errors
errors

attaching /var/log/dirsrv/admin-serv/error
error

What about error logs? I meant please attach them to this ticket...

Please attach /var/log/dirsrv/slapd-pki/errors and /var/log/dirsrv/admin-serv/error.

Is this an upgrade or a fresh install?

error​ (1.1 KB) - added by mharmsen 17 minutes ago.
attaching /var/log/dirsrv/admin-serv/error

1 [Thu Mar 12 18:30:13.561319 2015] [core:notice] [pid 9450:tid 140318158686336] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
2 [Thu Mar 12 18:30:13.564789 2015] [:error] [pid 9450:tid 140318158686336] Password for slot internal is incorrect.
3 [Thu Mar 12 18:30:13.565036 2015] [:error] [pid 9450:tid 140318158686336] NSS initialization failed. Certificate database: /etc/dirsrv/admin-serv.
4 [Thu Mar 12 18:30:13.565041 2015] [:error] [pid 9450:tid 140318158686336] SSL Library Error: -8177 The security password entered is incorrect
5 [Thu Mar 12 19:15:55.632346 2015] [core:notice] [pid 19917:tid 140539873036416] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
6 [Thu Mar 12 19:15:55.635821 2015] [:error] [pid 19917:tid 140539873036416] Password for slot internal is incorrect.
7 [Thu Mar 12 19:15:55.636056 2015] [:error] [pid 19917:tid 140539873036416] NSS initialization failed. Certificate database: /etc/dirsrv/admin-serv.
8 [Thu Mar 12 19:15:55.636060 2015] [:error] [pid 19917:tid 140539873036416] SSL Library Error: -8177 The security password entered is incorrect

Since I finished my ticket yesterday, I was able to purge all 389 packages from my Fedora 21 laptop and re-install.

I happened to notice that I had to manually remove some old NSS security databases and possibly some other files from the '''/etc/dirsrv/admin-serv''' directory; I then manually removed the '''/etc/dirsrv''' directory.

I re-installed everything, and was able to successfully achieve installing a working admin server:
{{{

yum install ./389-admin-1.1.38-1.fc21.x86_64.rpm ./389-adminutil-1.1.21-1.fc21.x86_64.rpm 389-admin-console 389-admin-console-doc 389-console 389-ds 389-ds-base 389-ds-base-libs 389-ds-console 389-ds-console-doc 389-dsgw

rpm -qa | grep 389 | sort

389-admin-1.1.38-1.fc21.x86_64
389-admin-console-1.1.8-7.fc21.noarch
389-admin-console-doc-1.1.8-7.fc21.noarch
389-adminutil-1.1.21-1.fc21.x86_64
389-console-1.1.7-7.fc21.noarch
389-ds-1.2.2-6.fc21.noarch
389-ds-base-1.3.3.8-1.fc21.x86_64
389-ds-base-libs-1.3.3.8-1.fc21.x86_64
389-ds-console-1.2.7-4.fc21.noarch
389-ds-console-doc-1.2.7-4.fc21.noarch
389-dsgw-1.1.11-4.fc21.x86_64

cd /usr/sbin

setup-ds-admin.pl

. . .
Are you ready to set up your servers? [yes]:
Creating directory server . . .
Your new DS instance 'pki' was successfully created.
Creating the configuration directory server . . .
Beginning Admin Server creation . . .
Creating Admin Server files and directories . . .
Updating adm.conf . . .
Updating admpw . . .
Registering admin server with the configuration directory server . . .
Updating adm.conf with information from configuration directory server . . .
Updating the configuration for the httpd engine . . .
Starting admin server . . .
The admin server was successfully started.
Admin server was successfully created, configured, and started.
Exiting . . .
Log file is '/tmp/setupEvzdaD.log'
}}}

I then successfully ran '389-console' to make certain that I could connect with this admin server, so I suspect that when I originally upgraded the '''389-admin'' and '''389-adminutil''' packages, some leftover cruft was preventing me from successfully running the admin server.

That being said, I did notice one small issue; although the admin server was up and running after the installation, the directory server was not:
{{{

systemctl status dirsrv.target

● dirsrv.target - 389 Directory Server
Loaded: loaded (/usr/lib/systemd/system/dirsrv.target; disabled)
Active: inactive (dead)

systemctl status dirsrv-admin.service

● dirsrv-admin.service - 389 Administration Server.
Loaded: loaded (/usr/lib/systemd/system/dirsrv-admin.service; disabled)
Active: active (running) since Fri 2015-03-13 10:12:44 MDT; 1min 49s ago
Process: 6426 ExecStart=/usr/sbin/httpd -k start -f /etc/dirsrv/admin-serv/httpd.conf (code=exited, status=0/SUCCESS)
Main PID: 6427 (httpd)
CGroup: /system.slice/dirsrv-admin.service
├─6427 /usr/sbin/httpd -k start -f /etc/dirsrv/admin-serv/httpd.co...
├─6428 /usr/sbin/httpd -k start -f /etc/dirsrv/admin-serv/httpd.co...
└─6429 /usr/sbin/httpd -k start -f /etc/dirsrv/admin-serv/httpd.co...
}}}

I was able to successfully start the directory server, but it seems strange that the directory server was shutdown at the end of the admin server installation:

{{{

systemctl start dirsrv.target

systemctl status dirsrv.target

● dirsrv.target - 389 Directory Server
Loaded: loaded (/usr/lib/systemd/system/dirsrv.target; disabled)
Active: active since Fri 2015-03-13 10:28:40 MDT; 13s ago
}}}

As for the admin server issue, if you require Karma for Bodhi, please let me know, and I will provide it.

Thank you for the update, Matt. Regarding the status of the Directory Server, could you add the error log (/var/log/dirsrv/slapd-pki/errors) again? DS should be up after the installation...

And it'd be nice if you could give a karma to 389-admin and 389-adminutil...

Thanks a lot, Matt!

Karma provided for 389-admin and 389-adminutil for Fedora 21 (and unfortunately also for EPEL 7 versions by mistake).

Per our conversation on IRC, I purged the machine once more, and was able to re-create the condition whereby the admin-server started successfully but the directory server did not. This time, I have attached the /var/log/dirsrv/errors file:
{{{

cat errors

389-Directory/1.3.3.8 B2015.036.047
pki.usersys.redhat.com:389 (/etc/dirsrv/slapd-pki)

[13/Mar/2015:17:37:29 -0600] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database
[13/Mar/2015:17:37:29 -0600] - check_and_set_import_cache: pagesize: 4096, pages: 4028851, procpages: 56179
[13/Mar/2015:17:37:29 -0600] - Import allocates 6446160KB import cache.
[13/Mar/2015:17:37:29 -0600] - Setting ncache to: 2 to keep each chunk below 4Gbytes
[13/Mar/2015:17:37:30 -0600] - import userRoot: Beginning import job...
[13/Mar/2015:17:37:30 -0600] - import userRoot: Index buffering enabled with bucket size 100
[13/Mar/2015:17:37:30 -0600] - import userRoot: Processing file "/tmp/ldif7u73ri.ldif"
[13/Mar/2015:17:37:30 -0600] - import userRoot: Finished scanning file "/tmp/ldif7u73ri.ldif" (9 entries)
[13/Mar/2015:17:37:30 -0600] - import userRoot: Workers finished; cleaning up...
[13/Mar/2015:17:37:30 -0600] - import userRoot: Workers cleaned up.
[13/Mar/2015:17:37:30 -0600] - import userRoot: Cleaning up producer thread...
[13/Mar/2015:17:37:30 -0600] - import userRoot: Indexing complete. Post-processing...
[13/Mar/2015:17:37:30 -0600] - import userRoot: Generating numsubordinates (this may take several minutes to complete)...
[13/Mar/2015:17:37:30 -0600] - import userRoot: Generating numSubordinates complete.
[13/Mar/2015:17:37:30 -0600] - import userRoot: Gathering ancestorid non-leaf IDs...
[13/Mar/2015:17:37:30 -0600] - import userRoot: Finished gathering ancestorid non-leaf IDs.
[13/Mar/2015:17:37:30 -0600] - import userRoot: Creating ancestorid index (new idl)...
[13/Mar/2015:17:37:30 -0600] - import userRoot: Created ancestorid index (new idl).
[13/Mar/2015:17:37:30 -0600] - import userRoot: Flushing caches...
[13/Mar/2015:17:37:30 -0600] - import userRoot: Closing files...
[13/Mar/2015:17:37:31 -0600] - All database threads now stopped
[13/Mar/2015:17:37:31 -0600] - import userRoot: Import complete. Processed 9 entries in 1 seconds. (9.00 entries/sec)
[13/Mar/2015:17:37:31 -0600] - 389-Directory/1.3.3.8 B2015.036.047 starting up
[13/Mar/2015:17:37:31 -0600] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file.
[13/Mar/2015:17:37:31 -0600] - resizing db cache size: 2305900544 -> 6400000
[13/Mar/2015:17:37:31 -0600] - resizing db cache count: 2 -> 0
[13/Mar/2015:17:37:31 -0600] - slapd started. Listening on All Interfaces port 389 for LDAP requests
[13/Mar/2015:17:37:31 -0600] - convert_pbe_des_to_aes: Converting DES passwords to AES...
[13/Mar/2015:17:37:31 -0600] - convert_pbe_des_to_aes: Successfully disabled DES plugin (cn=DES,cn=Password Storage Schemes,cn=plugins,cn=config)
[13/Mar/2015:17:37:31 -0600] - convert_pbe_des_to_aes: Finished - no DES passwords to convert.
}}}

If there's no ns-slapd process on the host, the server could get crashed.

Could you wipe out the servers and repeat the installation after do some configurations from debug_crashes?
http://www.port389.org/docs/389ds/FAQ/faq.html#debug_crashes

That would allow ns-slapd dump a core. Once the installation is done, please take a look at /var/log/dirsrv/slapd-pki. If lucky, we should see core.### file there.

It turned out the original issue was NSS config file and key/cert DBs left from the previous installation. Cleaning them up and reinstalling DS/Admin server solved the installation problem.

Closing this ticket for now. Please reopen it if there's any problem is found.

Thanks!

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/1459

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.