Simple Content Access

Updated -

What is Simple Content Access and Why should I use it?

Simple Content Access (SCA) is a capability in Red Hat’s subscription tools which simplifies the behavior of the entitlement tooling, making it easier to consume the content provided by your Red Hat subscriptions without the complexity of configuring subscription tooling.

By doing such, Simple Content Access removes processes which are

  • Time consuming
  • Overly complex, especially for the systems administration persona.
  • Business impacting. (The penalty for 'getting it wrong' is high)

Simple Content Access simplifies the entitlement experience so that the Linux administrator does not have a complex workflow that needs to be completed when adding, removing, and renewing subscriptions. SCA gives the administrator back valuable time (on average 10 hours a week) to spend doing things other than subscription management. At its core, it does this by removing the need to attach subscriptions at a per system level. Without needing to attach subscriptions, much of the complexity of the subscription tools is reduced or removed:

  • You no longer need to have complex activation key setups to ensure that a system gets the correct subscription (which grants access to the repositories). Simply register and enable the repositories that you need.
  • You no longer need to run virt-who as frequently to support fresh host-guest mappings to support newly provisioned hosts. Run virt-who as needed for reporting.
  • Challenges with auto-attach assigning a subscription that you didn’t intend are eliminated.
  • The requirement to attach a subscription to a new hypervisor (or remove one from an old hypervisor) is removed.
  • Reattaching subscriptions after a renewal is no longer required.

Simple Content Access is an optional feature of Red Hat Subscription Management(RHSM) and Red Hat Satellite 6, and in the case of Satellite 6, can be enabled on a per Subscription Allocation basis by an Organization Administrator.

  • As of 15-Jul-2022, newly created Red Hat accounts default to having Simple Content Access enabled.

When enabling Simple Content Access, you are enabling a new subscription experience that happens to use the existing subscription tools that already exist. As such, these tools will behave very differently than before. The “What Operational Changes do I have to make after enabling Simple Content Access?” section of this document covers exactly what these changes are.

While it is not mandatory to use both (or either), Simple Content Access is best paired with Subscription Watch, as Subscription Watch provides the visibility and governance that is needed to get the most out of SCA. The videos below cover more about why Red Hat built Subscription Watch and Simple Content Access, and how both of the capabilities qualitatively improve your subscription experience.

Modernizing the Registration Experience

Introduction to Subscription Watch

How do I enable Simple Content Access for Red Hat Subscription Management?

Simple Content Access is generally available, "settings" are accessible via access.redhat.com, as of 15-Jul-2022, newly created Red Hat accounts default to having Simple Content Access enabled ​and soon to be configurable at the Red Hat Cloud Services platform.

Simple Content Access can be enabled or disabled by an Organizational Administrator in Red Hat Subscription Management by setting the Simple content access for Red Hat Subscription Management slider.

SCA RHSM Slide

Once enabled for your account, systems simply need to be registered (via subscription-manager), and additional repositories enabled if necessary.

Example:

To register a system.

subscription-manager register --username <$INSERT_USERNAME_HERE>

OR (if using activation keys)

subscription-manager register --org <$INSERT_ORG_ID_HERE> --activationkey <$INSERT_ACTIVATION_KEY_HERE>

then, (if necessary) enable additional repos

subscription-manager repos --enable rhel-7-server-ansible-2.9-rpms

NOTE commands to attach subscriptions (such as subscription-manager attach --auto and/or subscription-manager attach --pool <$POOLID>) are obsolete and no longer required.

How do I enable Simple Content Access for Red Hat Satellite?

NOTE: Newly created Subscription Allocations default to having Simple Content Access enabled.

However, to disable/enable Simple Content Access for any existing allocation, configure one or more subscription allocations to use Simple Content Access and refresh them within your Satellite Server.
SCA Slider 2
* Setting this value to Enabled enables SCA, which will be effective the next time the manifest is refreshed.
* Setting this value to Disabled disables SCA, which will be effective the next time the manifest is refreshed.

Alternatively, users with Satellite which can connect to access.redhat.com can enable Simple Content Access within the Satellite UI directly. This can be done by visiting Content -> Subscriptions, and selecting Manage Manifest

Manifest

What Operational Changes do I have to make after enabling Simple Content Access?

When Simple Content Access is enabled, the ‘laws of physics’ in the world of Subscription Management change. Even though the same tools (subscription-manager, virt-who, Satellite) are used, they behave very differently. Fundamentally the switch to Simple Content Access should be treated like a new operating model, which is incompatible with most workflows related to Subscription Management.

First and foremost, when Simple Content Access is enabled, the attaching of subscriptions is not required, so (as an example), if you had a workflow which checked that a system had a valid subscription as part of a post-provisioning workflow, it would need to change. Listed below are other workflows that drastically change when SCA is enabled.

  • Manifest generation
  • Subscription Status
  • Activation keys
  • auto-attach
  • Virt-who
  • System purpose status.
  • UI changes
  • Reporting and understanding subscription utilization.

Manifest generation

When SCA is disabled:

When SCA is disabled, a subscription manifest needed to contain (at a minimum) enough subscriptions to cover every system registered to the Satellite.

When SCA is enabled:

When SCA is enabled, a subscription manifest only needs to contain enough subscriptions to provide access to repositories needed by your systems. 1 of each subscription is sufficient.

Subscription Status

When SCA is disabled:

System level subscription status (as reported by the subscription-manager tool) was used to understand if a system has a valid subscription, and if a status of insufficient or invalid was reported, it could be addressed by attaching a different (or additional) subscription(s)

subscription-manager status
+-------------------------------------------+
   System Status Details
+-------------------------------------------+
Overall Status: Current

System Purpose Status: Matched

Subscription status could also be used as an indicator of ‘did this system get properly registered?’.

When SCA is enabled:

System level subscription status (as reported by the subscription-manager tool) is now disabled.

subscription-manager status
+-------------------------------------------+
   System Status Details
+-------------------------------------------+
Overall Status: Disabled
Content Access Mode is set to Simple Content Access. This host has access to content, regardless of subscription status.

System Purpose Status: Disabled

As subscriptions are no longer required to be attached to the host, the very concept of ‘does THIS host have a valid subscription’ is obsolete. If you want to confirm ‘did this system get properly registered?’, use the output of subscription-manager identity instead of the output of subscription-manager status.

Note: Subscription Status shows as ‘unknown’ in Satellite versions 6.7 and below

Sub Status 1

This can be safely ignored and is addressed in Satellite 6.8 and will show ‘disabled’ similar to the CLI tools.

Sub Status 2

Activation Keys

When SCA is disabled:

Activation keys, which are used in lieu of username/password as a means to register to a Satellite server, generally contain a number of attributes to configure a host as registration. These include (but are not limited to):

  • Which subscriptions to attach?
  • Which repositories to enable?
  • Which environment & content view to configure the system with?
  • Which host collection to join?

The subscription related aspects of activation keys are where activation keys have generally had their complexity. Previously, it was suggested (such as in Subscription-manager for the former Red Hat Network User: Part 9 - A Case Study with activation keys ) to use 1-3 activation keys to configure a system (1 key to grant a virtual sub, 1 key to configure content [like repositories], and 1 to configure custom or layered subscriptions)

When SCA is enabled:

Activation keys continue to be used to register systems, however, their subscription related aspects are obsolete. As a result, the number of activation keys required to register a system is simplified and should optimally be 1 key per host to configure the content related aspects (repositories and content views).

Additionally it is recommended to set the ‘content host limit’ attribute, which sets the maximum number of times an activation key can be used. This can be used to help limit the number of systems which can be registered.

It is STRONGLY recommended to revisit your activation key design as the number of activation keys required to register a host can likely be simplified.

Auto-attach

When SCA is disabled:

The auto-attach function is generally used to attach appropriate subscriptions to a system, either at registration time or subscription expiry.

When SCA is enabled:

As subscriptions are not required to be attached to hosts when SCA is enabled, workflows related to auto-attach are obsolete. You no longer need to:

  • Run ‘subscription-manager attach --auto’
  • Run ‘hammer host subscription auto-attach’
  • Set activation keys to ‘auto-attach’

Running the above commands will result in either a no-op (no change) or explicitly error.

Virt-who

When SCA is disabled:

Virt-who, the utility which gathers host/guest mappings from hypervisors and reports them to Satellite, was a mandatory tool which was required to be used to consume content provided by subscriptions which support multiple guests (such as RHEL vDC). Virt-who was typically configured to run every 1-4 hours to provide refreshed host/guest mappings.

When SCA is enabled:

Virt-who is no longer in the ‘critical path’ of content access (again, since subscriptions no longer have to be attached to hosts). However, virt-who is an extremely important tool to support Subscription Watch. The host/guest mappings which are gathered by virt-who are critical information used to render accurate charts in Subscription Watch. However, the frequency at which virt-who needs to run can be limited to be less frequent. Without a correctly configured installation of both virt-who and the installation/enablement of the Satellite Inventory Plugin, Satellite users will not have accurate reporting in Subscription Watch

It is recommended when Satellite has SCA enabled, virt-who configurations should be configured to run no more frequently than twice daily.

System Purpose (and System Purpose Status)

When SCA is disabled:

System purpose allows you to set various parameters about how the system is being used, which are persistent and are used by the subscription tooling to better guide a system to a proper subscription. By providing those technical, business, and operational use-cases, the subscription tooling (particularly auto-attach) can make more informed decisions. You provide:

  • ROLE - What is the workload running on the system
    • E.g. ‘Red Hat Enterprise Linux Server’
  • SLA - What is the expected service level for this system?
    • E.g. Self-Support, Standard (business hours), Premium
  • USAGE - What is the scope of support for this system? Exactly what will we help you with.
    • E.g Development (assistance with design), Production (assistance with installation and runtime issues)

When SCA is not in use, System purpose attributes which are provided are used to better guide auto-attach and when auto-attach is able to match the requested attributes with a valid subscription, the system purpose status is updated to MATCHED (and MISMATCHED otherwise).

When SCA is enabled:

System Purpose status is set to DISABLED, as subscriptions are not required to be attached to systems. However, it is strongly recommended to continue to set system purpose attributes as those are also used by Subscription Watch (https://cloud.redhat.com/subscriptions/) to help filter/identify hosts.

UI Changes

On content related pages in the Satellite UI, there are now banners which inform the user that Simple Content Access is enabled. Examples:

  • Manifest import (Satellite 6.8+)

UI 1

  • Host page:

UI 2

  • Activation Key page:

UI 3

No change is required by the user other than importing a manifest with Simple Content Access enabled. These UI changes are intended to inform the user that SCA is enabled and that subscriptions should not be attached to hosts.

Behavior of the 'subscription-manager' CLI tool.

when SCA is enabled

The subscription-manager CLI tool, in versions less than 1.27.9-1 will display spurious messages when SCA is enabled.

When running yum commands, the user will receive output similar to This system is registered with an entitlement server, but is not receiving updates. You can use subscription-manager to assign subscriptions.

This message can be safely ignored in:

  • RHEL8 - subscription-manager versions less than 1.27.9-1 when SCA is enabled, and will be properly suppressed in versions greater than 1.27.9-1. This is being tracked in BZ1815624
  • RHEL7 - subscription-manager versions less than 1.24.26-1 when SCA is enabled, and will be properly suppressed in versions greater than 1.24.26-1. This is being tracked in BZ1831104

Further Reading

There are a number of documents which are worth reading to further your knowledge and understanding of Simple Content Access and Subscription Watch:

10 Comments

Subscription reporting is being affected by SCA, once enabled, the subscription report is empty... is there any solution? I´m using SCA but still linking the VDC entlitements to the virt-who asset, however, the subscription report is "empty".

That is expected. When SCA is enabled, attaching subscriptions isn't required. So any function dependent on attached subscriptions is effectively obsolete, to include host-level subscription reporting.

The solution is to use Subscription Reporting as part of Subscription Watch

So does this mean that Red Hat have admitted that:

1) activation keys are frequently broken, and depend on the order of attaching activation keys? 2) virt-who is frequently out of date, and if VMs only check in every 4 hours, the whole thing with Temporary subscriptions is moot?

Has Red Hat finally just come around to the realisation that the subscription model just is outdated with Linux?

Personally speaking, I've wasted MONTHS of cumulative time hand holding subscription manager, virt-who, virt-who.service, temporary activation keys.

Red Hat is saying that system level entitlement management has enough operational impact that solving the core problem it aims to solve (help me understand how much I am using and stay without established guardrails) is worth solving differently.

SCA is part of that. SCA removes the system level complexity (attaching pools, temp subs, ordering of activation keys, auto-attach, etc). Activation keys still have value, even in an environment where SCA is enabled. After all they still can be used instead of username/password, they still can enable repos, set release version, join host collections (in Satellite), etc.

But the "complex ordering to get a sub attached" parts, those are deprecated and are unneeded when SCA is available.

Pair SCA with Subscription Watch for best effect.

Yes it looks good the SCA. It's a shame, Red Hat doesn't give us a formula to estimate the total subscription cost.

cost is difficult because of discounting, markups, etc.

However, we do show you (in Subscription Watch) "this group of systems" is supported by "this group of subscriptions".

And we allow you to filter that by Usage (Development or Production) or SLA (Self-Support, Standard, Premium)

So if you want to answer the question of *what subscriptions do I need?", we can answer that.

If your question is "exactly how much will this cost me?", take your list of subs to a 'sales person of your choosing'™

This is an utter failure of an option to work around people not able to do such a simple task such as attach subscriptions to hosts (ie: they buy less licenses than they should have or don't know how to purchase more). Ie - there's NOTHING to stop me just using 1 subscription right now to validate countless hosts - because they aren't attached... Thanks for enabling incorrect book-keeping..

So, I take it this has been changed from an optional feature to mandatory given that my activation keys now say at the top that legacy subscription management is deprecated and will be removed? May want to update this article.

Unless this essential "BUG" isn't resolved, you really shouldn't deprecate "Legacy Subscriptions".

It's a failure by design though:

Deprecation of legacy subscription management

Will Red hat continue to support the "legacy model" running with SCA disabled? Need time to evaluate the impact. Next major activity at m workplace will be merging red hat clients onto single satellite manager. Currently two hosts belong to different entities with separate support contracts.