CentOS host cannot subscribe to repositories

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

Hi Team,
I have the exact same issue, on my RHEL 7.6 machines.
/etc/yum.repos.d/redhat.repo < is also empty.

Having the same issue here. This issue is related to /usr/lib64/python2.7/site-packages/rhsm/certificate.py

The get_datetime_from_x509 function is unable to parse the datetime from the certificate. I had changed the function to :

dateutil.parser.parse(date, fuzzy=True)

When I do this and re-register, the repository shows up as expired. Thats where I am stuck now.

I suspect this is https://bugzilla.redhat.com/show_bug.cgi?id=1789654#c4.

@Jonathon_Turel might have more information about a plan to fix this in upstream.

1 Like

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.

1 Like

Closing the loop - Katello 3.14.1 is available with the fix: Katello 3.14.1 has been released!

I expect 3.13.4 to follow along shortly.

1 Like

Good morning, all.

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.

What are my next steps?

What exact version of Katello are you using?

I can confirm that on my end Katello 3.14.1 on CentOS 7.7 is no longer affected by this (CentOS 7.7 clients)

$ rpm -q katello foreman
katello-3.14.1-1.el7.noarch
foreman-1.24.1-1.el7.noarch

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.)

# rpm -q subscription-manager katello-host-tools
subscription-manager-1.20.10-8.el6.x86_64
katello-host-tools-3.5.1-2.el6.noarch

I could not reproduce on a CentOS 6 VM:

[root@centos6 vagrant]# rpm -q subscription-manager
subscription-manager-1.17.6-1.el6.x86_64
[root@centos6 vagrant]# cat /etc/yum.repos.d/subscription-manager.repo 
[subscription-manager]
name=Subscription manager repository from Candlepin
baseurl=https://copr-be.cloud.fedoraproject.org/results/dgoodwin/subscription-manager/epel-6-x86_64/
gpgcheck=0
enabled=1
[root@centos6 vagrant]# subscription-manager list --available
+-------------------------------------------+
    Available Subscriptions
+-------------------------------------------+
Subscription Name:   animals
Provides:            
SKU:                 776111295418
Contract:            
Pool ID:             4028f95f6faa6db5016fb13dc65f0009
Provides Management: No
Available:           Unlimited
Suggested:           1
Service Level:       
Service Type:        
Subscription Type:   Standard
Ends:                12/01/2049
System Type:         Physical

[root@centos6 vagrant]# subscription-manager attach --pool 4028f95f6faa6db5016fb13dc65f0009
Successfully attached a subscription for: animals
[root@centos6 vagrant]# subscription-manager repos
+----------------------------------------------------------+
    Available Repositories in /etc/yum.repos.d/redhat.repo
+----------------------------------------------------------+
Repo ID:   Default_Organization_animals_zoo
Repo Name: zoo
Repo URL:  https://centos7-katello-3-14.strangeways.example.com/pulp/repos/Default_Organization/Library/custom/animals/zoo
Enabled:   1

I’ll ping the subscription-manager team to see if they have any thoughts. Thanks for sharing @jkalchik

IIRC, the subscription manager package I’ve been trying to use on the EL6 systems is 1.20.x, from the slaanesh repository.

On the system I’m tinkering with at home (rebuilt over the weekend,) I can’t even find a 1.17.x el6 rpm.

Gotta be something I’m doing. Should I consider going back to the dgoodwin repositories?

In any event, I need to stop polluting this thread.

Well, shoot…

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:

sudo -u postgres -H – psql -d candlepin -c “update cp_pool set enddate = ‘2049-12-01 00:00:00’ where enddate > ‘2049-12-31 00:00:00’;”

echo ’
User.current = User.anonymous_admin
m = Katello::Subscription
m.import_all
m = Katello::Pool
m.import_all
’ | foreman-rake console

Thanks for RedHat for that solution. I sorta figured out how to do the database update, but the foreman-rake thing I was clueless about.

Hope this helps

1 Like

Also, this needs to be done each time you add a product.

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.

I’ve opened up a dedicated thread for this.

Just to be clear: this is not the case in Katello 3.14.1

The dates will not go beyond 2049

I confirm it works, I had the same issue and now I’m able to attach the product.

1 Like

Hi,

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.

1 Like

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.

  1. Drop and recreate your products that were originally created during the scope window.
  2. Follow the procedure from @taylor1 above.

Any clients that have been registered to use products with the enddate issue will need to be reregistered.

3 Likes

See https://bugzilla.redhat.com/show_bug.cgi?id=1789654#c4 for other details.

1 Like