Bug 2244861
| Summary: | BaseRestLib._format_http_date doesn't format date correctly | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | elie.brami |
| Component: | Candlepin | Assignee: | Barnaby Court <bcourt> |
| Status: | CLOSED DUPLICATE | QA Contact: | Satellite QE Team <sat-qe-bz-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.13.2 | CC: | nmoumoul, phine, rlavi |
| Target Milestone: | Unspecified | Keywords: | Reopened, Triaged |
| Target Release: | Unused | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-10-24 12:51:44 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: | |||
*** This bug has been marked as a duplicate of bug 2242214 *** Hello, I saw this bug but I am not satisfied with this resolution. As redhat mention in preambule of every documentation: https://access.redhat.com/documentation/fr-fr/red_hat_enterprise_linux/9/html/security_hardening/making-open-source-more-inclusive I don't feel this inclusive enough because many coworker doesn't speak english. Also it will lower the required knowledge for recruiting people, it will improve the UX for people analysing the logs. One solution I propose is using a language agnostic format so we don't need to use this workaround. Another solution is to set this environment variable in the systemd service so new user doesn't get caught by the same bug. cheers (In reply to elie.brami from comment #2) > Hello, Hi, > One solution I propose is using a language agnostic format so we don't need > to use this workaround. That would be the ideal solution (using ISO 8601 format), but unfortunately changing this now would break backwards compatibility (Candlepin needs to support old versions of subscription-manager too). That being said, the date in the error is using the HTTP standard for the If-Modified-Since HTTP header (see https://datatracker.ietf.org/doc/html/rfc7232#section-3.3), which, is restricted to English (see here https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.1.1 and https://datatracker.ietf.org/doc/html/rfc5322#section-3.3). > I don't feel this inclusive enough because many coworker doesn't speak > english. > > Also it will lower the required knowledge for recruiting people, it will > improve the UX for people analysing the logs. As someone whose native language is not English, I understand this sentiment. However, the date you saw in the logs is not supposed to be human-readable/localizable data. It is part of the HTTP protocol, used by machines in a client/server communication. Supporting multiple languages for the protocol itself is not realistic; it would be like saying that Candlepin should not be written in Java because it uses English keywords, and should be re-written in a language-agnostic programming language. > Another solution is to set this environment variable in the systemd service > so new user doesn't get caught by the same bug. Set which environment variable exactly? For the locale? Which systemd service (tomcat, or rhsmcertd)? And how would that work? Candlepin can be deployed anywhere in the world, and each client (subscription-manager) may be located in a different place, again, anywhere in the world. If all clients and the server itself are using arbitrary locales, they would not be able to communicate (again, this would not be a problem if ISO 8601 format was used, but as I said, a design decision was made a long time ago to use the HTTP standard, and that is what we are stuck with). Thanks, Nikos > That would be the ideal solution (using ISO 8601 format), but unfortunately changing this now would break backwards compatibility (Candlepin needs to support old versions of subscription-manager too). Ah yes I forgot about backward compatibility. > the date in the error is using the HTTP standard for the If-Modified-Since HTTP header On python side it use standard email format date not subject to localization, shouldn't we use a function similar in backend https://www.tabnine.com/code/java/methods/javax.mail.internet.MailDateFormat/parse If the date isn't supposed to be localized it shouldn't use a localized function. > Set which environment variable exactly? For the locale? yes LANG="en_US.UTF-8" > Which systemd service (tomcat, or rhsmcertd)? And how would that work? systemd service unit file can specify environment variable for the associated process see https://serverfault.com/a/413408/498628 or the associated documentation https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html so when candlepin process is launched only this process has this variable and other tools can have the default value in french (so error message for binary like cat/ls cat be translated) I don't know exactly how candlepin server is launched but when I do `satellite-maintain status` I see candlepin so I guess their is a service associated where we can add the env var. So first solution is to stick to HTTP Protocol and use a non localized function (I have found the code in python if you want to replicate the exact same behaviour to the comma) second solution is to apply the workaround in in the related systemd unit file I hope one of this solution will avoid this bug to show up for new user. (In reply to elie.brami from comment #4) > So first solution is to stick to HTTP Protocol and use a non localized > function (I have found the code in python if you want to replicate the exact > same behaviour to the comma) How would this work? The HTTP protocol itself says the date must be localized to en_US values (for day of the week / month, etc). If you use a non localized function what would the resulting date look like before being sent to the server? > second solution is to apply the workaround in in the related systemd unit > file How would this solution be different from the current one? If the satellite installer sets the locale for candlepin to en_US, or if candlepin itself parses If-Modified-Since dates as en_US is the same, no? Can you explain a bit more what you want to do? Is it that you want all your client systems (subscription-manager) and Candlepin to use fr_FR locale, and exchange the If-Modified-Since values in French? Or something else? Also, can you please set the following environment variables for http traffic debugging (https://www.candlepinproject.org/docs/subscription-manager/debug_http_traffic.html#debug-environment-variables) run your scenario again, and send us the output, along with the rhsm.log, the version(s) of RHEL your clients are on, and the version of subscription-manager they use? > How would this work? The HTTP protocol itself says the date must be localized to en_US values (for day of the week / month, etc). I understand localized as to be subject to locale variable (LANG, LC...). When I proposed to use a non-localized function I think about a function like in python that hardcode Mon, Tue, Wes, ... so changing the locale doesn't modify output (and thus we always respect HTTP RFC). The java function used is subject to LANG variable and thus fail to parse if the machine has a global locale in non-en_US. > How would this solution be different from the current one? If the satellite installer sets the locale for candlepin to en_US I can't view issue on Red Hat Issue Tracker (CANDLEPIN-688, SAT-20593) so I don't know the current solution. Can you point me to the related PR maybe we have the same idea. The current solution (on satellite server) we did is ``` --- /etc/sysconfig/tomcat 2023-10-24 13:42:02.375889860 +0200 +++ /etc/sysconfig/tomcat 2023-10-24 12:34:25.122932471 +0200 @@ -9,3 +9,4 @@ # Please take a look at /etc/tomcat/tomcat.conf to have an idea # what you can override. +LANG="en_US.UTF-8" ``` candlepin seem to be launched by tomcat so we add it here (maybe their is a more precise place only for candlepin process) > Is it that you want all your client systems (subscription-manager) and Candlepin to use fr_FR locale, and exchange the If-Modified-Since values in French? Or something else? I originally wanted that but you made a point about RFC > However, the date you saw in the logs is not supposed to be human-readable/localizable data. > It is part of the HTTP protocol, used by machines in a client/server communication. The current workaround modify the globale locale. I can accept locale english (because RFC say so) only for communication between subman and candlepin. I don't want to be forced to change locale that apply to all binary. in the workaround:
> reboot the Satellite machine
since I only modified candlepin(tomcat) I can only restart the service and not rebooting the machine. I don't see this error anymore.
first solution seems to be implemented in https://github.com/candlepin/candlepin/commit/7deedc758d123358aff134253a4e1e5e106d7953 I will test on next upgrade but will close now The fix should be: - for CP 4.4: https://github.com/candlepin/candlepin/pull/4289 -- 4.4 is not released yet at the time of this writing - for CP 4.3.x: https://github.com/candlepin/candlepin/pull/4291 -- available in CP 4.3.10+ - for CP 4.2.x: https://github.com/candlepin/candlepin/pull/4290 -- will be in any release after 4.2.16 Most likely this needs a new CP 4.2.x release, pulling it in a zstream version of Satellite. Which version of Satellite are you using? $ rpm -qi satellite candlepin | grep -e Version -e Name Name : satellite Version : 6.13.2 Name : candlepin Version : 4.2.15 rpm -qi satellite candlepin | grep -e Version -e Name Name : satellite Version : 6.13.7 Name : candlepin Version : 4.2.15 with respect to "... will be in any release after 4.2.16" and "Most likely this needs a new CP 4.2.x release, pulling it in a zstream version of Satellite." I don't see a new candlepin rpm on satellite-6.13-for-rhel-8-x86_64-rpms repo. How is the new release suppose to be triggered ? thanks Peter (In reply to NLAphine from comment #11) > rpm -qi satellite candlepin | grep -e Version -e Name > Name : satellite > Version : 6.13.7 > Name : candlepin > Version : 4.2.15 > > > with respect to "... will be in any release after 4.2.16" and "Most likely > this needs a new CP 4.2.x release, pulling it in a zstream version of > Satellite." > > I don't see a new candlepin rpm on satellite-6.13-for-rhel-8-x86_64-rpms > repo. > How is the new release suppose to be triggered ? > > thanks > Peter Hi, This issue is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=2242214 and it was incorrectly closed as 'CURRENTRELEASE'. I'm closing it as a duplicate to avoid confusion. You can see in the original bug the 'Fixed In Version' is set to : candlepin-4.2.17-1, candlepin-4.3.10-1, candlepin-4.4.0-1 and it doesn't seem that candlepin-4.2.17-1 made it into a satellite 6.13 release (and probably won't). To get the fix you would need to upgrade to satellite 6.14 or 6.15 *** This bug has been marked as a duplicate of bug 2242214 *** (In reply to Nikos Moumoulidis from comment #12) > Hi, > > This issue is a duplicate of > https://bugzilla.redhat.com/show_bug.cgi?id=2242214 and it was incorrectly > closed as 'CURRENTRELEASE'. > I'm closing it as a duplicate to avoid confusion. You can see in the > original bug the 'Fixed In Version' is set to : candlepin-4.2.17-1, > candlepin-4.3.10-1, candlepin-4.4.0-1 > and it doesn't seem that candlepin-4.2.17-1 made it into a satellite 6.13 > release (and probably won't). To get the fix you would need to upgrade to > satellite 6.14 or 6.15 > > *** This bug has been marked as a duplicate of bug 2242214 *** Thanks for that. Slightly annoying as we only need this instance to manage the RHEL7 servers that couldn't be moved before support ran out. P |
Description of problem: We first noticed on our satellite (and also in rhsm.log) this kind of message: RestClient::InternalServerError: 500 Internal Server Error Body: {"displayMessage":"Erreur d’exécution Text 'Thu, 29 Jun 2023 09:04:10 GMT' could not be parsed at index 0 à java.time.format.DateTimeFormatter.parseResolved0:2 046","requestUuid":"0d738566-5073-4dd9-8aea-501f3d00933c"} Version-Release number of selected component (if applicable): candlepin-4.2.15-1 How reproducible: It appear each time rhsm try to contact katello. Steps to Reproduce: Don't remember anything special just install satellite by following the guide and kickstart a new VM Actual results: Because the server handler crash machine doesn't get update of accessible content and we need to re-register to update accessible content or do a remote job wth subman repos override. Expected results: The server give response to rhsm Additional info: We did the troubleshooting we know exactly which line we need to modify but we prefer to get update via RedHat to not break our licence: https://github.com/candlepin/subscription-manager/blob/a45afb704338cb8c940c17f9ca2283d0173c5236/src/rhsm/connection.py#L1868-L1870 These lines are at fault: They always add English date as we can see here https://github.com/python/cpython/blob/cb1bf89c4066f30c80f7d1193b586a2ff8c40579/Lib/email/utils.py#L114-L150 On the other end the server use an alternative format: https://github.com/candlepin/candlepin/blob/candlepin-4.2.15-1/src/main/java/org/candlepin/resource/ConsumerResource.java#L2135-L2139 'mar., 17 oct. 2023 14:20:05 GMT' since we have exactly the format (we can read in candeplin source code) we want to update the python codebase with strfmttime to ensure we get exactly the same string on both side.