Bug 1367140
| Summary: | NO_SUCH_USER and entryUSN error messages after CA installation | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Roshni <rpattath> |
| Component: | pki-core | Assignee: | RHCS Maintainers <rhcs-maint> |
| Status: | CLOSED ERRATA | QA Contact: | Asha Akkiangady <aakkiang> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.3 | CC: | alee, ftweedal, mharmsen, tlavigne |
| Target Milestone: | rc | ||
| Target Release: | 7.3 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | pki-core-10.3.3-9.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-11-04 05:27:12 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: | |||
I do see those messages even without changing the trust of CA signing cert. I installed CA and checked journatctl [root@ipaqavmf ~]# journalctl -xe | grep NO_SUCH_USER Aug 18 14:34:37 ipaqavmf.idmqe.lab.eng.bos.redhat.com server[6324]: CMSEngine: init(): password test execution failed for replicationdbwith NO_SUCH_USER. This may not be a latest instance. Ignoring .. [root@ipaqavmf ~]# journalctl -xe | grep entryUSN Aug 18 14:34:40 ipaqavmf.idmqe.lab.eng.bos.redhat.com server[6324]: CMS Warning: FAILURE: Authority entry has no entryUSN. This is likely because the USN plugin is not enabled in the database| [root@ipaqav I've investigated the entryUSN issue - I think if can happen if the USN plugin gets enabled after the entry in question is created. As long as the USN plugin is enabled this is not actually a problem. The proposed fix is, if entry is missing entryUSN attribute, to check if the DS USN plugin is enabled. We will print the warning only if it is not enabled. I believe alee is investigating the NO_SUCH_USER message. We probably need the fix that ftweedal suggests above for the case where we have migrated data. But I'm a little confused --- based on the code in SystemConfigService.java (line 765), it seems like one of the first things we do is enable the USN plugin. So I'm not sure how a CA entry would occur .. The NO_SUCH_USER error message is benign. Its been around forever and can be ignored. Cherry-picked into DOGTAG_10_3_RHEL_BRANCH: From 8e0235adccb11868f0036d48d2b52230c82b3e6b Mon Sep 17 00:00:00 2001 From: Fraser Tweedale <ftweedal> Date: Wed, 24 Aug 2016 14:10:55 +1000 Subject: [PATCH 8/9] Perform host authority check before entryUSN check When processing lightweight CAs, currently we perform the entryUSN check before the host authority check. If the entry does not have an entryUSN attribute, and if the DS USN plugin is not enabled, the entry gets skipped and we do not reach the host authority check. This causes the CA to believe that it has not seen the host authority entry, and results in additional entries being added. Move the host authority check before the entryUSN check to avoid this scenario. Fixes: https://fedorahosted.org/pki/ticket/2444 (cherry picked from commit e457cb8367f39562a844229ddb9da9c3a46d9611) (cherry picked from commit 3a97c5fc0df7015a7e19236778089c67441a1499) From 06a85c76938211d6ecf2b49ac72b168e9f6e7fdd Mon Sep 17 00:00:00 2001 From: Fraser Tweedale <frase.au> Date: Tue, 23 Aug 2016 14:50:03 +1000 Subject: [PATCH 7/9] Accept LWCA entry with missing entryUSN if plugin enabled Currently we abort adding a lightweight CA if its entry does not have an 'entryUSN' attribute, and log a failure, even if the USN plugin is enabled. But if the plugin is enabled, it's fine to proceed. Update the authority monitor to check if the USN plugin is enabled and only log the failure if it is not. Clarify the log message accordingly. Part of: https://fedorahosted.org/pki/ticket/2444 (cherry picked from commit d1aa1ec049d7cb5beed9ba79b09930a90a3c51fe) (cherry picked from commit 21e268ae6d5f9c2f93d4d80a6285e453974b5c07) [root@cypher ~]# rpm -qi pki-ca Name : pki-ca Version : 10.3.3 Release : 10.el7 Architecture: noarch Install Date: Tue 13 Sep 2016 09:58:32 AM EDT Group : System Environment/Daemons Size : 2431460 License : GPLv2 Signature : (none) Source RPM : pki-core-10.3.3-10.el7.src.rpm Build Date : Sat 10 Sep 2016 02:18:45 AM EDT Build Host : ppc-042.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 Verification steps 1. Install CA with defaults 2. [root@cypher ~]# journalctl | grep entryUSN [root@cypher ~]# journalctl | grep NO_SUCH_USER Sep 13 11:22:19 cypher.idmqe.lab.eng.bos.redhat.com server[23189]: CMSEngine: init(): password test execution failed for replicationdbwith NO_SUCH_USER. This may not be a latest instance. Ignoring .. Sep 13 11:39:42 cypher.idmqe.lab.eng.bos.redhat.com server[24503]: CMSEngine: init(): password test execution failed for replicationdbwith NO_SUCH_USER. This may not be a latest instance. Ignoring .. Sep 15 11:00:27 cypher.idmqe.lab.eng.bos.redhat.com server[31536]: CMSEngine: init(): password test execution failed for replicationdbwith NO_SUCH_USER. This may not be a latest instance. Ignoring .. Based on comment 5 marking the bug verified 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 |
Description of problem: NO_SUCH_USER and entryUSN error messages when CA is restarted with the ca signing cert's trust set to "u,u,u" Version-Release number of selected component (if applicable): pki-ca-10.3.3-5.el7.noarch How reproducible: always Steps to Reproduce: 1. Create CA instance. 2. Shutdown the instance. 3. Remove signing cert's trust flags with this command: certutil -M -d /var/lib/pki/pki-tomcat/alias -n "caSigningCert cert-pki-tomcat CA" -t "u,u,u" 4. Restart the instance. [root@auto-hv-02-guest02 ~]# systemctl status pki-tomcatd -l ● pki-tomcatd - PKI Tomcat Server topology-CA Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled; vendor preset: disabled) Active: active (running) since Sun 2016-08-14 17:43:57 EDT; 1min 7s ago Process: 29058 ExecStop=/usr/libexec/tomcat/server stop (code=exited, status=0/SUCCESS) Process: 29106 ExecStartPre=/usr/bin/pkidaemon start %i (code=exited, status=0/SUCCESS) Main PID: 29219 (java) CGroup: /system.slice/system-pki\x2dtomcatd.slice/pki-tomcatd └─29219 /usr/lib/jvm/jre-1.8.0-openjdk/bin/java -DRESTEASY_LIB=/usr/share/java/resteasy-base -Djava.library.path=/usr/lib64/nuxwdog-jni -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/var/lib/pki/topology-CA -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/lib/pki/topology-CA/temp -Djava.util.logging.config.file=/var/lib/pki/topology-CA/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.security.manager -Djava.security.policy==/var/lib/pki/topology-CA/conf/catalina.policy org.apache.catalina.startup.Bootstrap start Aug 14 17:44:42 auto-hv-02-guest02.idmqe.lab.eng.bos.redhat.com server[29219]: testLDAPConnection connecting to auto-hv-02-guest02.idmqe.lab.eng.bos.redhat.com:389 Aug 14 17:44:42 auto-hv-02-guest02.idmqe.lab.eng.bos.redhat.com server[29219]: testLDAPConnection: The specified user cn=Replication Manager masterAgreement1-auto-hv-02-guest02.idmqe.lab.eng.bos.redhat.com-topology-CA,cn=config does not exist Aug 14 17:44:43 auto-hv-02-guest02.idmqe.lab.eng.bos.redhat.com server[29219]: CMSEngine: init(): password test execution failed for replicationdbwith NO_SUCH_USER. This may not be a latest instance. Ignoring .. Aug 14 17:44:45 auto-hv-02-guest02.idmqe.lab.eng.bos.redhat.com server[29219]: CMS Warning: FAILURE: Authority entry has no entryUSN. This is likely because the USN plugin is not enabled in the database|FAILURE: Authority entry has no entryUSN. This is likely because the USN plugin is not enabled in the database|FAILURE: Authority entry has no entryUSN. This is likely because the USN plugin is not enabled in the database| Aug 14 17:44:45 auto-hv-02-guest02.idmqe.lab.eng.bos.redhat.com server[29219]: CA is started. Aug 14 17:44:45 auto-hv-02-guest02.idmqe.lab.eng.bos.redhat.com server[29219]: Aug 14, 2016 5:44:45 PM org.apache.catalina.startup.HostConfig deployDescriptor Aug 14 17:44:45 auto-hv-02-guest02.idmqe.lab.eng.bos.redhat.com server[29219]: INFO: Deployment of configuration descriptor /etc/pki/topology-CA/Catalina/localhost/ca.xml has finished in 4,528 ms Aug 14 17:44:46 auto-hv-02-guest02.idmqe.lab.eng.bos.redhat.com server[29219]: Aug 14, 2016 5:44:46 PM org.apache.tomcat.util.http.Cookies processCookieHeader Aug 14 17:44:46 auto-hv-02-guest02.idmqe.lab.eng.bos.redhat.com server[29219]: INFO: Cookies: Invalid cookie. Value not a token or quoted value Aug 14 17:44:46 auto-hv-02-guest02.idmqe.lab.eng.bos.redhat.com server[29219]: Note: further occurrences of Cookie errors will be logged at DEBUG level. [ Actual results: Expected results: Additional info: