Bug 2026873

Summary: Date parse error around SCA cert fetching when system locale is en_AU or en_CA
Product: Red Hat Satellite Reporter: Nikos Moumoulidis <nmoumoul>
Component: CandlepinAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED ERRATA QA Contact: sganar
Severity: low Docs Contact:
Priority: unspecified    
Version: 6.10.0CC: hyu, mshimura, redakkan, sganar
Target Milestone: 6.11.0Keywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: candlepin-4.0.14-1, candlepin-4.1.9-1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 2026874 2026875 (view as bug list) Environment:
Last Closed: 2022-07-05 14:30:33 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:
Bug Depends On: 2026874, 2026875    
Bug Blocks:    
Attachments:
Description Flags
stacktrace none

Description Nikos Moumoulidis 2021-11-26 09:58:42 UTC 
Created attachment 1843686 [details]
stacktrace

Description of problem:
When the system's default locale is set to en_AU or en_CA (and possibly other locales), SCA cert generation on the /accessible_content candlepin API always fails with 400 status code and this error:

Runtime Error RESTEASY003870: Unable to extract parameter from http request: javax.ws.rs.HeaderParam("If-Modified-Since") value is 'Thu, 01 Jan 1970 00:00:00 GMT' for public javax.ws.rs.core.Response org.candlepin.resource.ConsumerResource.getContentAccessBody(java.lang.String,java.util.Date) at org.candlepin.resteasy.DateFormatter.fromString:75
(see attachment for full stacktrace)

This is only happening on Java 11 (new for Sat 6.10) with root cause being https://bugs.openjdk.java.net/browse/JDK-8208487


Version-Release number of selected component (if applicable):
candlepin-4.0.9-1.el7sat.noarch.rpm

How reproducible:
100%

Steps to Reproduce:
1. Set system locale with "sudo localectl set-locale LANG=en_AU.UTF-8"
2. Restart the tomcat service.
3. Register a host to an organization with SCA mode enabled (the registration and SCA cert generation should still be successful).
4. Check /var/log/candlepin.log on the server, and /var/lib/rhsm/cache/content_access.json on the host.

Actual results:
There is a stack trace and 400 response status on the candlepin.log on the server.
There is no /var/lib/rhsm/cache/content_access.json cache file on the client.

Expected results:
There should be no stack trace or error on the candlepin.log.
The file cache file /var/lib/rhsm/cache/content_access.json should exist on the client.

Additional info:

The effect is minimal, since the SCA cert generation still works (through other API calls subscription-manager/rhsmcertd makes), but the client-side cache loses it's effect, since now the server is re-sending the same SCA certificate on every check in (instead of a 304 response).
Comment 1 Hao Chang Yu 2021-11-26 10:05:07 UTC 
*** Bug 2026864 has been marked as a duplicate of this bug. ***
Comment 2 Nikos Moumoulidis 2021-11-26 10:07:41 UTC 
There are workarounds:

One workaround is to set the system locale to en_US.UTF-8 and then restart tomcat.
--------------------------
localectl set-locale LANG=en_US.UTF-8
systemctl restart tomcat
--------------------------


Alternatively, you can add jvm variable '-Djava.locale.providers=COMPAT,CLDR' in the JAVA_OPTS of /etc/tomcat/tomcat.conf.
------------------------------------
# Edit /etc/tomcat/tomcat.conf, change this line from:

JAVA_OPTS="-Xms1024m -Xmx4096m"

# To:

JAVA_OPTS="-Xms1024m -Xmx4096m -Djava.locale.providers=COMPAT,CLDR"

# Then restart tomcat
systemctl restart tomcat
-----------------------------------
Comment 4 sganar 2022-06-14 12:09:34 UTC 
Verified.

Tested on Satellite 6.11.0 Snap 24.0

Steps followed: 
1. Set system locale with "sudo localectl set-locale LANG=en_AU.UTF-8"
2. Restart the tomcat service.
3. Register a host to an organization with SCA mode enabled (the registration and SCA cert generation should still be successful).
4. Check `/var/log/candlepin.log` on the server, and `/var/lib/rhsm/cache/content_access.json` on the host.

Observations: 
No error is observed in `/var/log/candlepin.log` and `/var/lib/rhsm/cache/content_access.json` exists on the client.
Comment 7 errata-xmlrpc 2022-07-05 14:30:33 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: Satellite 6.11 Release), 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-2022:5498