Bug 1302127 - After uninstalling all KRA instances, dogtag still returns info that KRA instance exists somewhere
After uninstalling all KRA instances, dogtag still returns info that KRA inst...
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pki-core (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: 7.3
Assigned To: Christian Heimes
Asha Akkiangady
Depends On:
  Show dependency treegraph
Reported: 2016-01-26 16:40 EST by Matthew Harmsen
Modified: 2016-11-04 01:22 EDT (History)
4 users (show)

See Also:
Fixed In Version: pki-core-10.3.1-1.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-11-04 01:22:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matthew Harmsen 2016-01-26 16:40:31 EST

in IPA project we hit this bug https://fedorahosted.org/freeipa/ticket/5469

When all KRA instances are uninstalled, following method, 'is_installing_replica', still returns True, what in IPA context means that KRA still exists on any server
def get_security_domain():
    Get the security domain from the REST interface on the local Dogtag CA
    This function will succeed if the local dogtag CA is up.
    connection = PKIConnection()
    domain_client = pki.system.SecurityDomainClient(connection)
    info = domain_client.get_security_domain_info()
    return info

def is_installing_replica(sys_type):
    We expect only one of each type of Dogtag subsystem in an IPA deployment.
    That means that if a subsystem of the specified type has already been
    deployed - and therefore appears in the security domain - then we must be
    installing a replica.
    info = get_security_domain()
        sys_list = info.systems[sys_type]
        return len(sys_list.hosts) > 0
    except KeyError:
        return False

sys_type = "KRA"

>>> print(repr(sys_list.hosts))
{u'KRA vm-058-094.example.com 443': <pki.system.SecurityDomainHost object at 0x7f95171b9510>}

Uninstallation of KRA is done with following command:
pkidestroy -i pki-tomcat -s KRA

This is reproducible with just one server too:
ipa-kra-install --uninstall

Let me know if you need additional info.
Comment 3 Christian Heimes 2016-01-29 11:08:11 EST
PKI #1704 fixes the problem, To reproduce the issue you need a version of PKI without the fix and a recent version of mod_nss (mod_nss >= 1.0.12 on Fedora 23).

1) Install FreeIPA with CA:

# ipa-server-install

2) Get LDAPI URI from FreeIPA's config file and retrieve KRA list from LDAP:

# export LDAP_URI=$(grep ^ldap_uri /etc/ipa/default.conf | awk -F= '{print $2}')
# echo $LDAP_URI 

# ldapsearch -LLL -Q -H $LDAP_URI -b "cn=KRAList,ou=Security Domain,o=ipaca" "(objectClass=top)" dn SubsystemName
dn: cn=KRAList,ou=Security Domain,o=ipaca

Your LDAPI uri may look differently. Please note that ldapsearch only returns one DN.

3) Install KRA:

# ipa-kra-install

4) Verify installation:

# ldapsearch -LLL -Q -H $LDAP_URI -b "cn=KRAList,ou=Security Domain,o=ipaca" "(objectClass=top)" dn SubsystemName
dn: cn=KRAList,ou=Security Domain,o=ipaca

dn: cn=vm-058-084.abc.idm.lab.eng.brq.redhat.com:443,cn=KRAList,ou=Security Do
SubsystemName: KRA vm-058-084.abc.idm.lab.eng.brq.redhat.com 8443

Now ldapsearch returns two DNs. The second DN is the KRA instance you have just installed.

5) Uninstall KRA:

# ipa-kra-install --uninstall

6) Verify uninstallation:

# ldapsearch -LLL -Q -H $LDAP_URI -b "cn=KRAList,ou=Security Domain,o=ipaca" "(objectClass=top)" dn SubsystemName
dn: cn=KRAList,ou=Security Domain,o=ipaca

On a system with a fixed sslget command, you will get just one DN. A broken system will still show two DNs like in 4).

7) Check unstallation log for errors:

# less /var/log/pki/pki-kra-destroy.CURRENT_DATE_AND_TIME.log

Look for 'sslget'. The output of 'sslget' should contain "HTTP/1.1 200 OK" and the line 

<?xml version="1.0" encoding="UTF-8" standalone="no"?><XMLResponse><Status>0</Status></XMLResponse>

followed by

updateDomainXML SUCCESSFULLY deleted this 'KRA' entry from security domain 'IPA'

On a broken system you should see entries similar to https://fedorahosted.org/pki/ticket/1704#comment:4.

8) Try to install KRA again:

# ipa-kra-install
Comment 4 Mike McCune 2016-03-28 18:25:24 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 6 Scott Poore 2016-07-07 17:56:18 EDT
FYI, I ran a quick check with ipa-kra-install --uninstall and it looks good:

[root@replica ~]# ipa-kra-install --uninstall 
Configuring certmonger to stop tracking system certificates for KRA
Unconfiguring KRA
The ipa-kra-install command was successful

[root@replica ~]# ldapsearch -LLL -Q -H ldapi://%2fvar%2frun%2fslapd-TESTRELM-TEST.socket -b "cn=KRAList,ou=Security Domain,o=ipaca" "(objectClass=top)" dn SubsystemName
dn: cn=KRAList,ou=Security Domain,o=ipaca

[root@replica ~]# 

[root@master ~]# ldapsearch -LLL -Q -H ldapi://%2fvar%2frun%2fslapd-TESTRELM-TEST.socket -b "cn=KRAList,ou=Security Domain,o=ipaca" "(objectClass=top)" dn SubsystemName
dn: cn=KRAList,ou=Security Domain,o=ipaca

[root@master ~]#
Comment 7 Roshni 2016-09-06 12:27:57 EDT
[root@auto-hv-02-guest05 ~]# rpm -qi pki-ca
Name        : pki-ca
Version     : 10.3.3
Release     : 8.el7
Architecture: noarch
Install Date: Sun 04 Sep 2016 05:27:32 PM EDT
Group       : System Environment/Daemons
Size        : 2430595
License     : GPLv2
Signature   : (none)
Source RPM  : pki-core-10.3.3-8.el7.src.rpm
Build Date  : Tue 30 Aug 2016 03:23:27 PM EDT
Build Host  : ppc-015.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://pki.fedoraproject.org/
Summary     : Certificate System - Certificate Authority

Executed the steps in comment 3 successfully.
Comment 9 errata-xmlrpc 2016-11-04 01:22:26 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.