dogtagpki

#311 Unable to deregister subsystem in merged instance
Closed: Fixed Opened by edewata.

Closed: Fixed
Reopen Issue

Normally the pkidestroy will stop the instance first then deregister the subsystem being removed (in configuration step). In a merged instance, stopping the instance will also stop the security domain, so the deregistration will fail. The deregistration should be done after restarting the instance again (in finalization step).

# pkidestroy -v -s KRA -i master
pkidestroy  : INFO     BEGIN destroying subsystem 'KRA' of instance 'master' . . .
pkidestroy  : INFO     ... initializing 'pki.deployment.initialization'
pkidestroy  : INFO     ....... executing 'systemctl stop pki-tomcatd@master.service'
pkidestroy  : INFO     ... unconfiguring 'pki.deployment.configuration'
pkidestroy  : INFO     ....... contacting the security domain master to update security domain 'EXAMPLE'
pkidestroy  : WARNING  ....... this 'KRA' entry will NOT be deleted from security domain 'EXAMPLE'!
pkidestroy  : WARNING  ....... security domain 'EXAMPLE' may be offline or unreachable!
pkidestroy  : ERROR    ....... subprocess.CalledProcessError:  Command '/usr/bin/sslget -n 'subsystemCert cert-master' -p '838957996689' -d '/etc/pki/master/alias' -e 'name="/var/lib/pki/master"&type=KRA&list=kraList&host=vm-091.idm.lab.bos.redhat.com&sport=8443&ncsport=8443&adminsport=8443&agentsport=8443&operation=remove' -v -r '/ca/agent/ca/updateDomainXML' vm-091.idm.lab.bos.redhat.com:8443 2>&1' returned non-zero exit status 6!

Note that pkidestroy doesn't stop at the error, it continues to finish the subsystem removal.

The error happens in util.security_domain.deregister() which is invoked in the configuration step. If the invocation is moved into the finalization step it will fail because by that time the subsystem configuration is already removed.

This can be fixed by reading the configuration during the configuration step, keeping the configuration object in memory, and using it to deregister at the finalization step. With the current scriptlet loading framework the configuration object will have to be passed as a global variable which we should avoid due to maintenance issue. A better way to fix this is to convert the scriptlets into methods and use class attributes or local variables to pass the configuration object. See also https://fedorahosted.org/pki/ticket/228#comment:3.

In speaking with alee, it was suggested that a much simpler solution to this issue would be to simply move the util.security_domain.deregister() method call to the "initialization" scriptlet's "destroy()" method just prior to its call to util.systemd.stop().

Additionally, while I disagree with the https://fedorahosted.org/pki/ticket/311#comment:1 proposal to remove the scriptlet framework, I have submitted an alternative counter-proposal at https://fedorahosted.org/pki/ticket/228#comment:4 which I believe would provide greater maintainability and customizability while still utilizing the existing scriptlet framework.

Resolved:

commit 69c06845a7a39c016ab29b0f2758e989b424698b
Author: Matthew Harmsen <mharmsen@redhat.com>
Date:   Thu Sep 13 17:16:53 2012 -0700
    Deregister subsystem in merged instance
    * TRAC Ticket #311 - Unable to deregister subsystem in merged instance

Metadata Update from @edewata:
- Issue assigned to mharmsen
- Issue set to the milestone: Dogtag 10.0.0.a1

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

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, and we apologize for any inconvenience.
Metadata
None
None
None
Normal
defect
Installation/Configuration
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.