Bug 1302127

Summary:	After uninstalling all KRA instances, dogtag still returns info that KRA instance exists somewhere
Product:	Red Hat Enterprise Linux 7	Reporter:	Matthew Harmsen <mharmsen>
Component:	pki-core	Assignee:	Christian Heimes <cheimes>
Status:	CLOSED ERRATA	QA Contact:	Asha Akkiangady <aakkiang>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.3	CC:	arubin, pvoborni, rpattath, spoore
Target Milestone:	rc
Target Release:	7.3
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	pki-core-10.3.1-1.el7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-11-04 05:22:26 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Matthew Harmsen 2016-01-26 21:40:31 UTC

Hello,

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()
    try:
        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-server-install
ipa-kra-install
ipa-kra-install --uninstall
ipa-kra-install
}}}

Let me know if you need additional info.

Comment 3 Christian Heimes 2016-01-29 16:08:11 UTC

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 
ldapi://%2fvar%2frun%2fslapd-IPA-EXAMPLE.socket

# 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
 main,o=ipaca
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 22:25:24 UTC

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 6 Scott Poore 2016-07-07 21:56:18 UTC

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 16:27:57 UTC

[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 05:22:26 UTC

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.

https://rhn.redhat.com/errata/RHBA-2016-2396.html