Testing with dogtag 10.0.2.1, it does not appear that the dogtag service starts on boot.
Following an install:
[root@cfgdev-intca01 ~]# systemctl list-units | grep pki pki-tomcatd@pki-tomcat.service loaded active running PKI Tomcat Server pki-tomcat system-pki\x2dtomcatd.slice loaded active active system-pki\x2dtomcatd.slice pki-tomcatd.target loaded active active PKI Tomcat Server
After rebooting the OS:
[root@cfgdev-intca01 ~]# systemctl list-units | grep pki [cfgdev-intca01.iam.redhat.com] [01:29:15 PM]
pkispawn should configure the system to start the pki-tomcat service at boot.
Red Hat Enterprise Linux Server release 7.1 (Maipo) pki-ca-10.2.1-1.el7.noarch pki-base-10.2.1-1.el7.noarch pki-server-10.2.1-1.el7.noarch dogtag-pki-server-theme-10.2.1-1.el7.noarch pki-tools-10.2.1-1.el7.x86_64
Per CS/DS meeting of 2015/03/23: 10.2.3
This patch replaces 20150409-pki-tomcatd-fails-to-start-on-boot.patch. 20150410-pki-tomcatd-fails-to-start-on-boot.patch
Note that the DS is not automatically configured to start at boot time: https://fedorahosted.org/389/ticket/47616
It has to be enabled manually: http://www.port389.org/docs/389ds/howto/howto-systemd.html#how-do-i-make-it-start-at-boot-time
Currently there is a bug with the manual configuration: https://fedorahosted.org/389/ticket/48147
This will block Dogtag startup at boot time if the DS is running on the same machine.
Replying to [comment:5 edewata]:
Note that the DS is not automatically configured to start at boot time: https://fedorahosted.org/389/ticket/47616 It has to be enabled manually: http://www.port389.org/docs/389ds/howto/howto-systemd.html#how-do-i-make-it-start-at-boot-time Currently there is a bug with the manual configuration: https://fedorahosted.org/389/ticket/48147 This will block Dogtag startup at boot time if the DS is running on the same machine.
Please note that the attached patch appears to address this issue for Dogtag with the changes to the following two files:
By adding the lines "Wants=dirsrv.target" and "After=...dirsrv.target", testing revealed, that if 389 is locally present on the system, it will be started up on boot whenever Dogtag has been configured to start on boot.
It should also be noted that since "Wants" was used rather than "Requires", testing also revealed that it would not stop Dogtag from starting up if 389 did not exist locally on the machine (i. e. - Dogtag relies upon using a 389 server reachable on the network rather than locally).
The one small problem with the proposed solution is if a deployment contained a machine which required having both 389 and Dogtag on it, but Dogtag actually utilized a network reachable 389 rather that the local 389; the local 389 would still be started upon boot due to this logic. It may be possible for a deployment to address this scenario by using systemd.preset logic.
Checked into master:
Metadata Update from @bja: - Issue assigned to mharmsen - Issue set to the milestone: 10.2.3
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/1877
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Login to comment on this ticket.