Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
improve the way IPA detects PKI services, do not rely on files or directories, try to rely on the Dogtag tools or interfaces, example:
use
pki-server subsystem-find
from
base/server/python/pki/server/cli/subsystem.py
class SubsystemFindCLI(pki.cli.CLI):
pki-server subsystem-find
-----------------
2 entries matched
-----------------
Subsystem ID: ca
Instance ID: pki-tomcat
Enabled: True
Subsystem ID: kra
Instance ID: pki-tomcat
Enabled: True
instead of
/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py
def is_installed(self):
"""
Determine if subsystem instance has been installed.
Returns True/False
"""
return os.path.exists(os.path.join(
paths.VAR_LIB_PKI_TOMCAT_DIR, self.subsystem.lower()))
this directory path testing return an incorrect true status because for example, there is no "ipa-kra-install --uninstall" ( removed in 2018 / bz 1454444 ):
ipa-kra-install --uninstall
ERROR: Standalone KRA uninstallation was removed in IPA 4.5 as it had never worked properly and only caused issues.
real world scenario example:
there is a RHEL-7 IPA replica deployed
that system is updated from RHEL-7.8 to RHEL-7.9
the update fails in IPA, leading to failing "ipactl restart", then to some serious other problems:
in this case, there was no PKI KRA subsystem configured listed from
ldapsearch -o ldif-wrap=no -LLLxD cn=directory\ manager -W -b "ou=Security Domain,o=ipaca"
nor from a
ipa config-show --all
and no ipara listed from
ldapsearch -o ldif-wrap=no -LLLxD cn=directory\ manager -W -b o=ipaca '(|(uid=ipara)(uid=ipakra))'
but we till had a directory
/var/lib/pki/pki-tomcat/kra/
so the test in
/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py
incorrectly returned a true status in is_installed(self)
that all lead to a LDAP error on no ipakra user entry, then to a failed IPA update, then to a failed ipactl start, and a bad situation.
Version-Release number of selected component (if applicable):
RHEL-7
RHEL-8
How reproducible:
Steps to Reproduce:
1. IPA with CA, NO KRA
2. add a /var/lib/pki/pki-tomcat/kra/ directory
3. try to run the ipa console for
api.Updater[fix_kra_people_entry]()
Actual results:
2020-11-03T17:27:14Z DEBUG Executing upgrade plugin: fix_kra_people_entry
...
2020-11-03T17:27:14Z ERROR Upgrade failed with no such entry
2020-11-03T17:27:14Z DEBUG Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 274, in __upgrade
self.modified = (ld.update(self.files) or self.modified)
File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 966, in update
self._run_updates(all_updates)
...
File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/fix_kra_people_entry.py", line 35, in execute
entry = self.api.Backend.ldap2.get_entry(krainstance.KRA_AGENT_DN)
then I realize there is no KRA agent LDAP entry uid=ipakra,ou=people,o=kra,o=ipaca
because that RHEL IPA system has no KRA installed (but has a CA)
so why the failure in fix_kra_people_entry.py if there is no KRA ??
the IPA update uses "plug-ins" to update various elements, listed from
/usr/share/ipa/updates/90-post_upgrade_plugins.update
and one of them is
/usr/lib/python2.7/site-packages/ipaserver/install/plugins/fix_kra_people_entry.py
which calls
/usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py
which calls a function is_installed()
the problem is is_installed() simply check for a directory path to decide a PKI subsystem is installed and configured, which is not a sufficient way to detect the availability of a service.
Expected results:
yes
Additional info:
Comment 2Florence Blanc-Renaud
2020-11-06 09:56:34 UTC
Notes for triage: looks like an easy fix. The "pki-server subsystem-show kra" command could be used.
If the KRA is configured, the output looks like:
# pki-server subsystem-show kra
Subsystem ID: kra
Instance ID: pki-tomcat
Enabled: True
If the KRA hasn't been configured, the output looks like:
# pki-server subsystem-show kra
ERROR: ERROR: No kra subsystem in instance pki-tomcat.
(return code = 1)
If the server doesn't have PKI configured at all (no CA, no KRA), the output is:
# pki-server subsystem-show kra
ERROR: Invalid instance pki-tomcat.
(return code 1)
Notes:
- pki-server does not require the services to be up. The command can be used even during an upgrade when some of the services are stopped.
- The command /usr/sbin/pki-server is delivered in the package pki-server. freeipa-server indirectly requires pki-server pkg through pki-ca and pki-kra packages, meaning that the command is always installed on a freeipa server.
Comment 4Florence Blanc-Renaud
2020-11-25 08:45:58 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 (Moderate: ipa security and bug fix update), 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://access.redhat.com/errata/RHSA-2021:0860
Description of problem: improve the way IPA detects PKI services, do not rely on files or directories, try to rely on the Dogtag tools or interfaces, example: use pki-server subsystem-find from base/server/python/pki/server/cli/subsystem.py class SubsystemFindCLI(pki.cli.CLI): pki-server subsystem-find ----------------- 2 entries matched ----------------- Subsystem ID: ca Instance ID: pki-tomcat Enabled: True Subsystem ID: kra Instance ID: pki-tomcat Enabled: True instead of /usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py def is_installed(self): """ Determine if subsystem instance has been installed. Returns True/False """ return os.path.exists(os.path.join( paths.VAR_LIB_PKI_TOMCAT_DIR, self.subsystem.lower())) this directory path testing return an incorrect true status because for example, there is no "ipa-kra-install --uninstall" ( removed in 2018 / bz 1454444 ): ipa-kra-install --uninstall ERROR: Standalone KRA uninstallation was removed in IPA 4.5 as it had never worked properly and only caused issues. real world scenario example: there is a RHEL-7 IPA replica deployed that system is updated from RHEL-7.8 to RHEL-7.9 the update fails in IPA, leading to failing "ipactl restart", then to some serious other problems: in this case, there was no PKI KRA subsystem configured listed from ldapsearch -o ldif-wrap=no -LLLxD cn=directory\ manager -W -b "ou=Security Domain,o=ipaca" nor from a ipa config-show --all and no ipara listed from ldapsearch -o ldif-wrap=no -LLLxD cn=directory\ manager -W -b o=ipaca '(|(uid=ipara)(uid=ipakra))' but we till had a directory /var/lib/pki/pki-tomcat/kra/ so the test in /usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py incorrectly returned a true status in is_installed(self) that all lead to a LDAP error on no ipakra user entry, then to a failed IPA update, then to a failed ipactl start, and a bad situation. Version-Release number of selected component (if applicable): RHEL-7 RHEL-8 How reproducible: Steps to Reproduce: 1. IPA with CA, NO KRA 2. add a /var/lib/pki/pki-tomcat/kra/ directory 3. try to run the ipa console for api.Updater[fix_kra_people_entry]() Actual results: 2020-11-03T17:27:14Z DEBUG Executing upgrade plugin: fix_kra_people_entry ... 2020-11-03T17:27:14Z ERROR Upgrade failed with no such entry 2020-11-03T17:27:14Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 274, in __upgrade self.modified = (ld.update(self.files) or self.modified) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 966, in update self._run_updates(all_updates) ... File "/usr/lib/python2.7/site-packages/ipaserver/install/plugins/fix_kra_people_entry.py", line 35, in execute entry = self.api.Backend.ldap2.get_entry(krainstance.KRA_AGENT_DN) then I realize there is no KRA agent LDAP entry uid=ipakra,ou=people,o=kra,o=ipaca because that RHEL IPA system has no KRA installed (but has a CA) so why the failure in fix_kra_people_entry.py if there is no KRA ?? the IPA update uses "plug-ins" to update various elements, listed from /usr/share/ipa/updates/90-post_upgrade_plugins.update and one of them is /usr/lib/python2.7/site-packages/ipaserver/install/plugins/fix_kra_people_entry.py which calls /usr/lib/python2.7/site-packages/ipaserver/install/dogtaginstance.py which calls a function is_installed() the problem is is_installed() simply check for a directory path to decide a PKI subsystem is installed and configured, which is not a sufficient way to detect the availability of a service. Expected results: yes Additional info: