Bug 1717229
Summary: | dogtag stopped working after dnf update due to docBase in /etc/pki/pki-tomcat/Catalina/localhost/ca.xml not being updated | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> |
Component: | pki-core | Assignee: | Matthew Harmsen <mharmsen> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | urgent | Docs Contact: | |
Priority: | unspecified | ||
Version: | 29 | CC: | alee, ascheel, dmoluguw, edewata, kwright, mharmsen, rcritten, tomek |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Fixed In Version: | pki-core-10.7.3-3.fc29 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-10-31 19:48:53 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Adam Williamson
2019-06-05 00:11:16 UTC
*** Bug 1717230 has been marked as a duplicate of this bug. *** The logs in the original bug description said that the pki-base package got upgraded to 10.7.0-1, but did the other PKI packages (e.g. pki-server) get upgraded as well? A NoSuchMethodException usually indicates that there are mismatching packages being installed (since such error would have been caught at build time), or the packages got upgraded while the server is still running. Yes, these were full system updates/upgrades (I just ran 'dnf update' and 'dnf system-upgrade download / dnf system-upgrade reboot'). All packages would've been updated/upgraded together. I was gonna check the logs to confirm this, but unfortunately they seem to have been rotated out of existence :/ I can confirm that right now everything is 10.7.0-1, though: [root@id adamw]# rpm -qa | grep pki- pki-base-java-10.7.0-1.fc30.noarch pki-kra-10.7.0-1.fc30.noarch python3-pki-10.7.0-1.fc30.noarch dogtag-pki-server-theme-10.7.0-1.fc30.noarch pki-ca-10.7.0-1.fc30.noarch pki-server-10.7.0-1.fc30.noarch pki-tools-10.7.0-1.fc30.x86_64 pki-base-10.7.0-1.fc30.noarch pki-symkey-10.7.0-1.fc30.x86_64 BTW, this is still happening and I have no idea how to fix it; my server has been out of commission for over a month at this point... Tomasz Torcz just found something: <zdzichu> adamw: hey, about https://bugzilla.redhat.com/show_bug.cgi?id=1717229; could you fpaste output of 'grep netscape.security /etc/pki/pki-tomcat/ca/CS.cfg'? <zdzichu> adamw: I had a problem with freeipa recently, class names weren't updates to correct ones <adamw> zdzichu: https://paste.fedoraproject.org/paste/mIZl-Ktm0XK7oSyWQS7qng <zdzichu> yep, seems like the same. It should have org.mozilla.jss in front, like in https://paste.fedoraproject.org/paste/QY9ECyRbHOIWKbHw2ysoKQ <adamw> oo so I changed all those to add org.mozilla.jss on the front and rebooted. Then it seemed to blow up on a certificate validity issue. So I tried rewinding time and restarting certmonger...which fails because it can't talk to a KDC. At this point I would like to set the whole thing on fire and go punt it in a freaking lake. Can I just give you root permissions on the thing and let you go to town with it? About the CMSEngine issue, could you attach a tarball of these folders? - /etc/pki - /var/lib/pki - /var/log/pki I'm suspecting your machine might contain an older JAR file. Feel free to exclude the NSS database, passwords, or any other sensitive information. About the JSS classes, it's a different issue, but there is already an upgrade script for that: https://github.com/dogtagpki/pki/blob/master/base/server/upgrade/10.7.0/02-UpdateNetscapeSecurityClasses Could you check /var/log/pki/pki-server-upgrade-*.log to make sure the upgrade ran successfully? "Could you check /var/log/pki/pki-server-upgrade-*.log to make sure the upgrade ran successfully?" It doesn't look like it did, no. The last log that looks successful was /var/log/pki/pki-server-upgrade-10.5.6.log : === Upgrading from version 10.5.5 to 10.5.6: 1. Add token profile params for externalRegISEtoken for TPS CS.cfg Upgrade complete. --------------- System migrated --------------- === After that, there's 10.5.7, 10.5.8, 10.5.9 , which all look like this: === Upgrading PKI server configuration at Fri Jun 22 09:47:10 PDT 2018. pki-tomcat instance: Configuration version: 10.5.6 pki-tomcat/ca subsystem: Configuration version: 10.5.6 Upgrade incomplete. --------------- System migrated --------------- === (just with different dates). Then 10.6.6.log looks like this: === Upgrading PKI server configuration at Mon Dec 3 12:14:48 PST 2018. Upgrading from version 10.5.6 to 10.6.0: No upgrade scriptlets. Tracker has been set to version 10.6.0. Upgrading from version 10.6.0 to 10.6.5: 1. Remove NSS_DEFAULT_DB_TYPE from instance sysconfig 2. Fix server configuration ERROR: [Errno 2] No such file or directory: '/etc/pki/pki-tomcat/ciphers.info' Failed upgrading pki-tomcat instance. Upgrade failed in pki-tomcat: [Errno 2] No such file or directory: '/etc/pki/pki-tomcat/ciphers.info' Continue (Yes/No) [Y]? Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/pki/server/upgrade.py", line 91, in upgrade self.upgrade_instance(instance) File "/usr/share/pki/server/upgrade/10.6.0/02-FixServerConfiguration", line 41, in upgrade_instance '/usr/share/pki/server/conf/ciphers.info') File "/usr/share/pki/server/upgrade/10.6.0/02-FixServerConfiguration", line 62, in replace_with_link os.remove(source) FileNotFoundError: [Errno 2] No such file or directory: '/etc/pki/pki-tomcat/ciphers.info' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/pki/upgrade.py", line 593, in upgrade_version scriptlet.upgrade() File "/usr/lib/python3.7/site-packages/pki/server/upgrade.py", line 113, in upgrade 'Upgrade failed in %s: %s' % (instance, e), e, instance) pki.server.PKIServerException: Upgrade failed in pki-tomcat: [Errno 2] No such file or directory: '/etc/pki/pki-tomcat/ciphers.info' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib64/python3.7/runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "/usr/lib64/python3.7/runpy.py", line 85, in _run_code exec(code, run_globals) File "/usr/lib/python3.7/site-packages/pki/server/cli/upgrade.py", line 210, in <module> main(sys.argv) File "/usr/lib/python3.7/site-packages/pki/server/cli/upgrade.py", line 203, in main upgrader.upgrade() File "/usr/lib/python3.7/site-packages/pki/upgrade.py", line 623, in upgrade self.upgrade_version(version) File "/usr/lib/python3.7/site-packages/pki/upgrade.py", line 613, in upgrade_version case_sensitive=False).lower() File "/usr/lib/python3.7/site-packages/pki/__init__.py", line 142, in read_text value = input(message) EOFError: EOF when reading a line === Then 10.7.0.log looks basically the same: errors about /etc/pki/pki-tomcat/ciphers.info not existing. So I just tried doing 'touch /etc/pki/pki-tomcat/ciphers.info' and running pki-server-upgrade , and that completed successfully, but it doesn't seem to help the original problem unfortunately. ipa-server-upgrade is still blowing up. I just found this thread from December: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/J257R4GFYIEG64JU5TO7Z2S6GVZZBHFK/ which looks a lot like my problem. But I cannot quite understand Arjen's mail saying 'this is solved': https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/message/PTXTMW6XZUY5FEYO2AO5T4W4O5AR3KOC/ what does he mean about those two files? What did he have to change to 'solve' it? I don't get it. Here's those two files on my system: [root@id ca]# rpm -qf /usr/share/pki/ca/webapps/ca/WEB-INF/lib/pki-cmscore.jar pki-ca-10.7.0-1.fc30.noarch [root@id ca]# rpm -qf /usr/share/java/pki/pki-cmscore.jar pki-server-10.7.0-1.fc30.noarch [root@id ca]# ls -l /usr/share/pki/ca/webapps/ca/WEB-INF/lib/pki-cmscore.jar lrwxrwxrwx. 1 root root 35 May 7 09:58 /usr/share/pki/ca/webapps/ca/WEB-INF/lib/pki-cmscore.jar -> /usr/share/java/pki/pki-cmscore.jar [root@id ca]# so, is there something wrong there? There might be several issues here. I've fixed the JSS upgrade issue here (not merged yet): https://github.com/edewata/pki/commit/9cf2be94943ad9be8a4603969291381320bd0746 I was suspecting there might be an old JAR file (or a link to it) in one of the instance folders here: - /etc/pki - /var/lib/pki - /var/log/pki If you could post a tarball of those directories I'd be able to take a look at it. I'll email them to you. Thanks. Thanks. Here's what I found. The docBase in your /etc/pki/pki-tomcat/Catalina/localhost/ca.xml is pointing to /var/lib/pki/pki-tomcat/ca/webapps/ca folder which contains an old copy of PKI CA web application, including old JAR files (see WEB-INF/lib subfolder). In the past the PKI installer used to copy the web application files into the instance folder, allowing the admin to customize the files (e.g. changing the HTML templates, adding custom JAR files). However, this meant that the admin would be responsible to update the web application manually when the PKI packages are upgraded. In newer PKI the installer sets the docBase to /usr/share/pki/ca/webapps/ca which is part of the package so it will be updated automatically by default. To fix the issue in older instances, assuming there was no customization, simply change the docBase to /usr/share/pki/ca/webapps/ca, then remove the old /var/lib/pki/pki-tomcat/ca/webapps/ca folder. Since it may be difficult to automatically determine whether there was any customization, I don't think PKI should automatically update the docBase and remove the old web application. However, since IPA has a more strict usage of PKI (i.e. IPA users do not access PKI CA web application directly), it's probably safe to assume that there is no customization in PKI instances installed as part of IPA. In that case I'd suggest that IPA should perform this change as part of IPA upgrade, either automatically with a script or manually by providing the above instruction. > However, this meant that the admin would be responsible to update the web application manually when the PKI packages are upgraded.
This is first time I heard about such requirement, and I'm running my home FreeIPA for 6 years now…
This should certainly be automated and path should be corrected during packages upgrade.
Thanks Endi! That was exactly the problem; with that plus a date dodge to get certificates re-issued by certmonger, I'm *finally* back up and running. This should definitely be handled on upgrade by Tomcat or FreeIPA, though, I'd say. Just to clarify, the problem happened because there was a change in WEB-INF/web.xml in PKI 10.7 that affected how the CMSEngine is created. Had the docBase been pointing to /usr/share/pki/ca/webapps/ca as in newer instances, there wouldn't be any problem since the file would have been updated automatically. However, since in old instances the web.xml was copied into /var/lib/pki/pki-tomcat/ca/webapps/ca, it is not updated automatically during upgrade, causing the NoSuchMethodException exception. Please take a look at this page and let me know what you think: https://www.dogtagpki.org/wiki/Upgrading_Custom_PKI_Subsystem It will determine how this ticket will be resolved. Thanks! I don't think I have a sufficient understanding of the components to provide a useful opinion. The only opinion I'd venture is that /etc/pki/pki-tomcat/Catalina/localhost/ca.xml , being in /etc , is a *config* file, yes? We already have a substantial body of knowledge about handling config files in RPM: are we not using the %config mechanism, such that RPM would replace the file if it was unmodified, but preserve it if it was modified? If not, why not? (Also, perhaps you could consider using the config file fragment approach, which is I think pretty well established by now as a superior approach to shipping a config file you expect to possibly be modified...) Further thought: if the case here is that the config file is marked as %config in the tomcat package but FreeIPA deployment modifies it, I'd say that makes this pretty clearly a problem for FreeIPA to handle on upgrade. The files in /etc/pki/<instance> are configuration files created when that particular PKI server instance was created using pkispawn (which was invoked by IPA installer). They are not part of the RPM packages so I don't think we will be able to use the %config on them, but thanks for your feedback! Ah, I see, that explains it. So unless tomcat invents its own mechanism for doing it, there's no possibility to tell whether they've been modified from "stock" or not, I guess. We decided to fix this issue in PKI and replace the "custom" webapps with the default ones. This should avoid similar issues in the future. Here are the changes in master branch: * https://github.com/dogtagpki/pki/commit/f24ec55923ee01981954e41c64d7a7304707d41d * https://github.com/dogtagpki/pki/commit/f4275bfcf1bd7f6e9ef008d264d76928f3a19e99 Thanks! This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. |