Add forced instance removal

[pki-bot]

This issue was migrated from Pagure Issue #1172. Originally filed by edewata (@edewata) on 2014-10-03 18:48:40:

• Closed at 2018-10-31 17:04:28 as fixed
• Assigned to dmoluguw (@SilleBille)
• Associated bugzillas
  • https://bugzilla.redhat.com/show_bug.cgi?id=1372056

---

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.

[pki-bot]

Comment from edewata (@edewata) at 2016-12-01 22:30:12

Ticket 2426 is a duplicate of this ticket.

[pki-bot]

Comment from edewata (@edewata) at 2017-02-27 13:58:28

Metadata Update from @edewata:

• Issue set to the milestone: 10.4

[pki-bot]

Comment from mharmsen (@mharmsen) at 2017-03-03 13:47:57

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)

[pki-bot]

Comment from mharmsen (@mharmsen) at 2017-08-09 16:44:57

Per CS/DS Meeting of August 7, 2017, it was determined to move this issue from 10.4 ==> FUTURE.

[pki-bot]

Comment from mharmsen (@mharmsen) at 2017-08-09 16:44:57

Metadata Update from @mharmsen:

• Issue set to the milestone: FUTURE (was: 10.4)

[pki-bot]

Comment from mharmsen (@mharmsen) at 2017-08-31 14:11:27

Metadata Update from @mharmsen:

• Issue set to the milestone: 10.5 (was: FUTURE)

[pki-bot]

Comment from mharmsen (@mharmsen) at 2017-10-25 18:29:40

[20171025] - Offline Triage ==> 10.6

[pki-bot]

Comment from mharmsen (@mharmsen) at 2017-10-25 18:29:41

Metadata Update from @mharmsen:

• Issue set to the milestone: 10.6 (was: 10.5)

[pki-bot]

Comment from edewata (@edewata) at 2018-03-14 18:40:25

http://www.dogtagpki.org/wiki/Manual_PKI_Server_Removal

[pki-bot]

Comment from mharmsen (@mharmsen) at 2018-04-23 21:51:59

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.

[pki-bot]

Comment from mharmsen (@mharmsen) at 2018-04-23 21:52:00

Metadata Update from @mharmsen:

• Issue set to the milestone: 10.5 (was: 10.6)

[pki-bot]

Comment from msauton (@msauton) at 2018-09-26 16:44:32

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 ?

[pki-bot]

Comment from dmoluguw (@SilleBille) at 2018-10-29 12:38:35

Metadata Update from @SilleBille:

• Issue assigned to SilleBille

[pki-bot]

Comment from dmoluguw (@SilleBille) at 2018-10-29 12:41:27

Fixed in PR: #79

Summary of changes:

• pkidestroy tries to uninstall the product normally
• pkidestroy WON'T REMOVE logs by default. --remove-logs need to be specified to remove the logs
• pkidestroy --force will attempt to run normal uninstallation. If the installation/uninstallation was broken, the same command will force remove all the remnant files. NOTE: This will not remove the log files. In order to get a clean slate, --force must be combined with --remove-logs

[pki-bot]

Comment from dmoluguw (@SilleBille) at 2018-10-29 12:41:27

Metadata Update from @SilleBille:

• Issue close_status updated to: fixed
• Issue status updated to: Closed (was: Open)

[pki-bot]

Comment from dmoluguw (@SilleBille) at 2018-10-29 12:43:35

Metadata Update from @SilleBille:

• Assignee reset
• Issue set to the milestone: 10.6.8 (was: 10.5)
• Issue status updated to: Open (was: Closed)

[pki-bot]

Comment from dmoluguw (@SilleBille) at 2018-10-31 17:03:39

Metadata Update from @SilleBille:

• Issue assigned to SilleBille

[pki-bot]

Comment from dmoluguw (@SilleBille) at 2018-10-31 17:04:05

Metadata Update from @SilleBille:

• Issue marked as depending on: 3077

[pki-bot]

Comment from dmoluguw (@SilleBille) at 2018-10-31 17:04:28

Metadata Update from @SilleBille:

• Issue close_status updated to: fixed
• Issue status updated to: Closed (was: Open)

[pki-bot]

Comment from dmoluguw (@SilleBille) at 2018-11-01 18:48:18

The changes have been backported (to 10.5) through PR: #93

10_5 branch:

The commit that fixes this specific bug: 926c26e

New change to keep logs by default is introduced by commit: 9e2cdb0