Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-90416

Autoregv2: Cloud Images do not have immediate access to content from CDN

Linking RHIVOS CVEs to...Migration: Automation ...Sync from "Extern...XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Blocker Blocker
    • rhel-10.1
    • rhel-9.6, rhel-10.0
    • subscription-manager
    • None
    • subscription-manager-1.30.8-1.el10
    • No
    • Low
    • subs-client-tools
    • 5
    • False
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • 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

      1. Spin up a RHEL10 3rd party image VM from Azure or AWS.
      2. 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.

              jhnidek@redhat.com Jiri Hnidek
              nmoumoul@redhat.com Nikolaos Moumoulidis
              CSI Client Tools Bugs Bot CSI Client Tools Bugs Bot
              Craig Donnelly Craig Donnelly
              Votes:
              0 Vote for this issue
              Watchers:
              21 Start watching this issue

                Created:
                Updated: