For what it’s worth I’m having the same problem. I installed Foreman v1.24 last week, with Centos 7.7 Clients, and get the exact same problem of clients not seeing any subscribed products, & error in the /var/log/rhsm.log:
File “/usr/lib64/python2.7/site-packages/rhsm/certificate2.py”, line 113, in _read_x509
raise CertificateException(str(e))
CertificateException: unknown string format
Thank you for raising a thread on this. We’re currently prepping Katello 3.14.1 and 3.13.4 to include the fix (Bug #28714: custom products can't be consumed by hosts - Katello - Foreman). Please keep an eye on the Release Announcements area to know when they’re available. I would estimate early next week.
I’m hoping that I’m not the bearer of bad news… but I think this problem may not be quite fixed yet. I’ve completely rebuilt my Katello server install from the ground up (both for a completely fresh installation as well as a different product layout,) including a fresh install of CentOS 7, Katello & Foreman, and fully patched as of this morning (noting @Jonathon_Turel post above.) I’ve been attempting to provision new clients (OL6 and CentOS6, I can try OL7 & CentOS7 if necessary) and getting no repositories provisioned during the registration process. I do see a similar error in the client’s /var/log/rhsm/rhsm.log:
unknown string format
2020-01-16 10:47:26,301 [ERROR] subscription-manager:7798:MainThread @certificate2.py:112 - unknown string format
Traceback (most recent call last):
File "/usr/lib64/python2.6/site-packages/rhsm/certificate2.py", line 107, in _read_x509
‘subscription-manager repos’ displays a series of blank lines followed by "This system has no repositories available through subscriptions.’
‘subscription-manager repo-override --list’ returns the list of repositories that have specifically been disabled in this host.
I suspect that I’m hitting the bug referenced above, and thus, it’s really not quite fixed completely.
The further I dig into this, the more that I’m suspecting it’s something I’m doing. Same issue with OL6, CentOS6 and CentOS7. With the string issue I’m experiencing, I’m wondering if I have the wrong subscription-manager RPMs for the clients. The major distro requirement does match (the following is for a CentOS 6 install.)
Went back to the dgoodwin repositories, still experiencing the same thing on both CentOS6 and CentOS7. Stranger, ‘subscription-manager list --available’ does indeed succeed. Anything that lists what should be available repositories is failing, such as ‘subscription-manager repos --list’.
I just had this same problem (I think), and the issue like was mentioned was that certificate expiration for the subscriptions is set 30 years in the future to a date > 2050…and that causes an internal python datetime module to overflow.
There was a solution posted on the redhat satellite forum about this, basically, updating the candlepin database to change the subscription expiration date to something < the year 2050, then updating foreman. See if this works:
Unfortunately, at least for an OL7 client, the above referenced procedure (both the psql update as well as the foreman-rake console work,) doesn’t appear to make a difference.
We had the same issue.
Yesterday we upgraded from foreman 1.14.0/katello 1.24.0 to foreman 1.14.1/katello 1.24.1 after reading this post and executed the Redhat-Satelite solution provided by taylor1
I can confirm it now creates the redhat.repo.
After a fair amount of discussion with Jonathon Turel, & testing, there’s a small opportunity for problems with custom (non-RedHat) products. In short, custom products created between Jan. 1, 2020 and the installation of Katello 3.14.1 leaves a problem value in cp_pool:enddate (Jan. 1, 2050 or greater.) This is one of the issues that lead to the 3.14.1 release.
To find out if you’re in this scope:
sudo su - postgres -c “psql -d candlepin -c “select id,enddate from cp_pool where enddate > ‘2049-12-31 00:00:00’;””
If this returns one or more rows, there are at least 2 remediation options.
Drop and recreate your products that were originally created during the scope window.