-
Bug
-
Resolution: Unresolved
-
Blocker
-
rhel-9.6, rhel-10.0
-
None
-
subscription-manager-1.30.8-1.el10
-
No
-
Low
-
subs-client-tools
-
5
-
False
-
False
-
-
None
-
None
-
Pass
-
Automated
-
Unspecified
-
Unspecified
-
Unspecified
-
None
What were you trying to do that didn't work?
Spinning a 3rd-party RHEL 10.0 image from an Azure or AWS cloud account results in the system getting automatically registered, but not having access to content from the CDN on time. The SCA certificate is fetched by the client too late.
What is the impact of this issue to you?
If this goes live, that means customers will not have access to content from the CDN for up to 4 hours (in the worst case), and would have to manually remove the redhat-cloud-client-configuration-cdn package, and re-enable RHUI as a workaround to be able to access content. This is obviously an issue for users that may want
to run automation (e.g. kickstarts) that needs access to content almost immediately after booting.
Please provide the package NVR for which the bug is seen:
subscription-manager: 1.30.6-1.el10_0
redhat-cloud-client-configuration-cdn-1-13.el10.noarch
How reproducible is this bug?:
At the time of writing, 100% on RHEL 10.0 (tested on 2 RHEL 10 VMs, one in Azure, one in AWS), however, we are unsure if RHEL9.6 is unaffected. More investigation is required.
Steps to reproduce
- Spin up a RHEL10 3rd party image VM from Azure or AWS.
- After a few seconds (maximum 2 minutes), look at the /var/log/rhsm/rhsm.log and /etc/yum.repos.d/redhat.repo
Expected results
There is no/minimal delay (a few seconds) between when the VM got autoregistered, and when the SCA cert got updated (fetched for the first time). E.g.:
2025-05-08 09:04:24,249 [INFO] rhsmcertd-worker:10478:MainThread @rhsmcertd_worker.py:230 - Standard automatic registration was successful.
2025-05-08 09:04:30,646 [INFO] subscription-manager:11024:MainThread @entcertlib.py:108 - certs updated:
Total updates: 1
Found (local) serial# []
Expected (UEP) serial# [1233442352352352]
Added (new)
[sn:1233442352352352 ( Content Access,) @ /etc/pki/entitlement/1233442352352352.pem]
Deleted (rogue):
<NONE>
The /etc/yum.repos.d/redhat.repo file is populated with repos after the 'certs updated'.
Actual results
The VM got autoregistered, but the SCA cert did not get fetched. E.g.:
2025-05-08T09:06:07.313+00:00 [INFO] rhsmcertd-worker:11406:MainThread @rhsmcertd_worker.py:230 - Standard automatic registration was successful.
The /etc/yum.repos.d/redhat.repo file is not populated.
In this case the 'certs updated' action may happen in up to 4 hours after the registration.
- relates to
-
RHEL-105102 Autoregv2: Change waiting game of rhsmcertd
-
- Release Pending
-
-
RHEL-105250 Fix redhat-cloud-client-configuration to support the new autoregistration v2 flow
-
- Release Pending
-
-
RHEL-105584 [autoreg v2] The rhsmcertd should wait and then it should hit IMDS server
-
- Release Pending
-
- links to
-
RHBA-2025:149779 subscription-manager bug fix and enhancement update