Sometimes when pkispawn fails it might leave the machine in an inconsistent state. When that happens the pkidestroy might fail and subsequent pkispawn might also fail, so the machine would become unusable. The only recourse is a manual cleanup which might not be very well documented.
The pkidestroy should provide a way to remove the entire instance regardless of the status of the installation. For example:
$ pkidestroy -i pki-tomcat
In this case the pkidestroy should perform the following cleanup operations:
# kill Tomcat instance pids="`ps -ef | grep catalina.base=/var/lib/pki/$INSTANCE_NAME | grep -v grep | awk '{print $2}'`" for pid in $pids; do kill -9 $pid done # remove DS instance remove-ds.pl -f -i slapd-$INSTANCE_NAME # remove instance files rm -rf /etc/pki/$INSTANCE_NAME rm -rf /etc/sysconfig/$INSTANCE_NAME rm -rf /etc/sysconfig/pki/tomcat/$INSTANCE_NAME rm -rf /var/lib/pki/$INSTANCE_NAME rm -rf /var/log/pki/$INSTANCE_NAME rm -rf $HOME/.dogtag/$INSTANCE_NAME
To ensure the machine will return into a consistent state, each of these operations should be executed regardless of the result of any other operations.
Ticket #2426 is a duplicate of this ticket.
Metadata Update from @edewata: - Issue set to the milestone: 10.4
Metadata Update from @mharmsen: - Custom field feature adjusted to '' - Custom field proposedmilestone adjusted to '' - Custom field proposedpriority adjusted to '' - Custom field reviewer adjusted to '' - Custom field version adjusted to '' - Issue close_status updated to: None - Issue priority set to: 3 (was: 2)
Per CS/DS Meeting of August 7, 2017, it was determined to move this issue from 10.4 ==> FUTURE.
Metadata Update from @mharmsen: - Issue set to the milestone: FUTURE (was: 10.4)
Metadata Update from @mharmsen: - Issue set to the milestone: 10.5 (was: FUTURE)
[20171025] - Offline Triage ==> 10.6
Metadata Update from @mharmsen: - Issue set to the milestone: 10.6 (was: 10.5)
http://www.dogtagpki.org/wiki/Manual_PKI_Server_Removal
Per 10.5.x/10.6 Triage: 10.5.x
alee: this is related to dogtagpki Pagure Issue #2712. Fixing this will help ipa and other installs in cases of install failure.
Metadata Update from @mharmsen: - Issue set to the milestone: 10.5 (was: 10.6)
Note the "remove-ds.pl -f -i slapd-$INSTANCE_NAME" will erase data from all PKI susbsystems.
Scenario: IPA KRA install fails, how do I keep other subsystems like IPA CA, and so, and only remove the failed IPA KRA left over data?
Shouldn't this tool accommodate the pkidestroy -s option to select a CA, KRA, OCSP, TKS ?
Metadata Update from @dmoluguw: - Issue assigned to dmoluguw
Fixed in PR: https://github.com/dogtagpki/pki/pull/79
Summary of changes:
pkidestroy
--remove-logs
pkidestroy --force
--force
Metadata Update from @dmoluguw: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Metadata Update from @dmoluguw: - Assignee reset - Issue set to the milestone: 10.6.8 (was: 10.5) - Issue status updated to: Open (was: Closed)
Metadata Update from @dmoluguw: - Issue marked as depending on: #3077
The changes have been backported (to 10.5) through PR: https://github.com/dogtagpki/pki/pull/93
The commit that fixes this specific bug: https://github.com/dogtagpki/pki/commit/926c26e10db1b3fde8f24802d7a77419d0f2f28d
New change to keep logs by default is introduced by commit: https://github.com/dogtagpki/pki/commit/9e2cdb0b2f5df552ef50ba7883b4c686adec41b3
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/1735
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.