Bug 1316580
| Summary: | dirsrv service doesn't ask for pin when pin.txt is missing | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Viktor Ashirov <vashirov> |
| Component: | 389-ds-base | Assignee: | wibrown <wibrown> |
| Status: | CLOSED ERRATA | QA Contact: | Viktor Ashirov <vashirov> |
| Severity: | urgent | Docs Contact: | Petr Bokoc <pbokoc> |
| Priority: | urgent | ||
| Version: | 7.2 | CC: | gparente, jpazdziora, ksiddiqu, nhosoi, nkinder, pasteur, pbokoc, pvoborni, rmeggins, spoore, sramling, wibrown |
| Target Milestone: | rc | Keywords: | Regression, TestBlocker |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | 389-ds-base-1.3.5.10-7.el7 | Doc Type: | Bug Fix |
| Doc Text: |
*ns-slapd* now correctly prompts for a pin when the `pin.txt` file is not found
In previous releases, _389-ds-base_ did not display a prompt asking for a pin if the `pin.txt` file was not found, due to the fact that *systemd* captures standard input and output which _389-ds-base_ was attempting to use. With this update, _389-ds-base_ detects whether *systemd* is running on the system during startup, and uses the correct *systemd* API to display the password prompt if required. Directory Server can therefore be started without a `pin.txt` file, which allows administrators to keep *nssdb* passwords away from the system.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-11-03 20:40:19 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1322167, 1324983 | ||
| Bug Blocks: | |||
|
Description
Viktor Ashirov
2016-03-10 14:16:45 UTC
Yes, it is a known issue. See the second item in the ToDos section: http://www.port389.org/docs/389ds/design/allow-usage-of-openldap-lib-w-openssl.html#to-dos I think we need a doc bug if we haven't filed it... How to verify: 1) using systemctl # setfacl -m g:dirsrv:rwx /var/run/systemd/ask-password <== This is needed unless bz 1322167 is taken care by the systemd team. # start-dirsrv SERV_ID Enter PIN for Internal (Software) Token: **************************************** Or # systemctl start dirsrv Enter PIN for Internal (Software) Token: **************************************** 2) using the raw command line [1] # /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-SERV_ID -i /var/run/dirsrv/slapd-SERV_ID.pid -d 0 It issues this wall message: [2] Broadcast message from root@<host>.<domain> (Mon 2016-04-04 16:23:04 PDT): Password entry required for 'Enter PIN for Internal (Software) Token:' (PID 26762). Please enter password with the systemd-tty-ask-password-agent tool! # systemd-tty-ask-password-agent Enter PIN for Internal (Software) Token: **************************************** [2] For some reason, the wall is not enabled on my gnome-terminal :(, but it is on xterm. So, it is not a bug of the DS... Just in case, the command line [1] does not issue the message, take a look at the error log. The similar message is logged to run systemd-tty-ask-password-agent. (In reply to Noriko Hosoi from comment #4) > I think we need a doc bug if we haven't filed it... I will file a doc bug when I have finished / acked the feature. Build tested: 389-ds-base-1.3.5.4-1.el7.x86_64
# setfacl -m g:dirsrv:rwx /var/run/systemd/ask-password
[1] Starting using start-dirsrv/systemctl
# start-dirsrv
Starting instance "qeos-106"
Enter PIN for Internal (Software) Token: ****************************************
[0 root@qeos-106 ~]# ss -ntpl | grep ns-slapd
LISTEN 0 128 :::389 :::* users:(("ns-slapd",pid=2717,fd=6))
LISTEN 0 128 :::636 :::* users:(("ns-slapd",pid=2717,fd=7))
[2] Starting manually
# /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-qeos-106 -i /var/run/dirsrv/slapd-qeos-106.pid -d 0
[08/Jun/2016:11:05:50.992369342 -0400] SSL alert: Sending pin request to SVRCore. You may need to run systemd-tty-ask-password-agent to provide the password.
Broadcast message from root.eng.rdu2.redhat.com (Wed 2016-06-08 11:05:50 EDT):
Password entry required for 'Enter PIN for Internal (Software) Token:' (PID 2827).
Please enter password with the systemd-tty-ask-password-agent tool!
On a second console:
# systemd-tty-ask-password-agent
Enter PIN for Internal (Software) Token: ****************************************
And then server starts up.
[08/Jun/2016:11:06:27.182694793 -0400] slapd started. Listening on All Interfaces port 389 for LDAP requests
[08/Jun/2016:11:06:27.183931026 -0400] Listening on All Interfaces port 636 for LDAPS requests
Marking as VERIFIED.
With the new build server doesn't start, since /usr/sbin/ds_systemd_ask_password_acl is missing: [root@rhel7ds ~]# systemctl status dirsrv ● dirsrv - 389 Directory Server rhel7ds. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Fri 2016-08-05 09:04:29 CEST; 10s ago Process: 6552 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl /etc/dirsrv/slapd-%i/dse.ldif (code=exited, status=203/EXEC) [root@rhel7ds ~]# file /usr/sbin/ds_systemd_ask_password_acl /usr/sbin/ds_systemd_ask_password_acl: cannot open (No such file or directory) Marking as ASSIGNED and TestBlocker. possible duplicates: * bug 1364452 - installation of IPA * bug 1364377 - installation of IPA * bug 1364510 - upgrade of IPA *** Bug 1364802 has been marked as a duplicate of this bug. *** *** Bug 1364452 has been marked as a duplicate of this bug. *** *** Bug 1364510 has been marked as a duplicate of this bug. *** *** Bug 1364377 has been marked as a duplicate of this bug. *** Build tested: 389-ds-base-1.3.5.10-8.el7.x86_64 No manual workaround for systemd is needed, marking as VERIFIED. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2016-2594.html |