Introduction to Red Hat Subscription Management Workflows

Red Hat Subscription Management 1

to better understand and manage subscriptions for an IT infrastructure

Red Hat Subscription Management Documentation Team

October 1, 2013


This guide covers background concepts about subscription management, tools, and common use scenarios.

1. Introduction to Subscription Management

IT hardware needs to be managed and clearly inventoried, and the software installed on those machines also needs to be managed and clearly inventoried.

1.1. The Goals of Subscription Management

IT administrators face increasing pressure to have an accurate accounting of the software, not just from governmental regulations like Sarbanes-Oxley in the United States, but also to achieve critical industry certificataions, such as Payment Card Industry Data Security Standard (PCI-DSS) or SAS-70. Generally, this accounting of software assets is called software license management; with Red Hat's subscription model, this is subscription management.
Effective subscription management helps enterprises achieve four primary goals:
  • Maintain regulatory compliance by tracking software attached subscriptions and expiration periods.
  • Simplify IT audits.
  • Be more effective at assigning subscriptions by clarifying the relationships between subscriptions and systems.
  • Lower costs and streamline procurement. While under-subscribing systems can run afoul of regulations, over-subscribing systems can cause a significant impact on IT budgets.
Red Hat Subscription Management tracks software counts by directly associating a purchased subscription with the machine the product is installed on. Subscription management establishes the relationship between the product subscriptions that are available and the elements of the IT infrastructure where those subscriptions are allocated.
This is very similar to license management, which is common in other software. However, licenses define who can use a piece of software. Red Hat is committed to free and open software, so we do not license our software and do not enforce usage requirements. Rather, our subscriptions allow:
  • Access to support services
  • Content delivery and hosted repositories
  • Access to knowledgebases, forums, videos, and other resources

1.2. Subscriptions: The Relationship Between Systems, Software, and Support

An IT infrastructure tries to maintain balance between the products that are installed and the licensese or subscriptions that those products require.
There is a reliable pattern in subscription lifecycles:
  1. A company (account) buys a subscription to a product. The subscription defines a number of times it can be used (the quantity), the support level, the content repositories, and the period that it is good for.
  2. A system is added, or registered, to the inventory for the subscription service. This means that the subscription service can manage the server and attach subscriptions to it.
    The subscription service collects certain facts about the system, including its hardware and installed products, which it uses to help determine what subscriptions the system requires.
  3. A subscription is assigned or attached to a system.
  4. The system downloads software packages and updates from the content delivery network for as long as the subscription is active.
An inventory is simply a means to track what software is installed and where it is installed and how many copies are actively being used.
The Structure of the Subscription Service

Figure 1. The Structure of the Subscription Service

Each element in the subscription service must be uniquely identified; this allows true relationships to be established between the system, the products, and the subscriptions. This is done using public-key infrastructure (PKI) certificates. The subscription service generates and installs these certificates on the local system:
  • An identity certificate for the system; this is used by the system to authenticate to the subscription service periodically to check for updates.
    This is created when the system is registered.
  • A product certificate for each product installed on the system. Each product in Red Hat has an identifying certificate (but this is not unique to the system).
    This is installed on the system as part of installing the product.
  • A subscription certificate for each subscription attached to the system. This includes information about the subscription from the inventory.
    This is installed on the system when a subscription is attached to the system.


Attaching a subscription does not actually perform any installation or updates. The software packages themselves are still maintained with the normal system tools, like yum. Conversely, having a product installed does not mean that the appropriate subscriptions have been attached to the system. A system does not require a valid certificate to install a product.
Ultimately, subscription management delivers better information and offers administrators better control over their infrastructures. The primary goals of subscription management are regulatory compliance, infrastructure management, better purchasing decisions, better system maintenance.
All of these goals come down to information — to providing administrators a better understanding of what subscriptions they have and how they are being used with their systems.
  • For regulatory compliance and IT audits, Red Hat offers two account-wide views into systems and subscription associations: the utilization views in the Customer Portal and the reporting and dashboards in subscription management applications such as Subscription Asset Manager
  • For better effectiveness at assigning subscriptions, system tools allow systems to have all relevant, compatible subscriptions automatically assigned (attached) to the system based on what products are installed — or for administrators to select and manually attach subscriptions (Viewing Reports and Notifications). Tools list both available subscriptions and the quantities still available for those subscriptions, so that the right subscription can be attached and the right number of subscriptions are used.
  • For better purchasing strategies, subscription management tools help simultaneously track oversubscribing (using the same subscription on too many systems), undersubscribing (not having enough subscriptions for the installed products on a system), and subscription expirations.
    Having a time-based picture on subscriptions — not only what is covered but how long it is covered — helps administrators control identify when to purchase new subscriptions, so subscriptions are not purchased too early or too late.
Better information translates into better control. The long-range goals for subscription management for Red Hat software is to enhance how administrators understand and manage their infrastructures.

1.3. About Relationships Between Subscriptions and Systems

1.3.1. Interactions with Subscriptions, Products, and Systems

Products on a system have relationships, dependencies, and conflicts between each other. Likewise, subscriptions have relationships that parallel the relationships of the software it represents. Some subscriptions allow virtual guests, some require other subscriptions, some conflict with other subscriptions.
Subscription define the relationships between installed products and each other and the systems on which those products are installed. Likewise, subscriptions can also define relationships between systems and how they interact within an environment. This is particularly apparent with virtual environments, where subscriptions can define different relationships for physical hosts and virtual guests, but there are other ways that systems can interact, such as data centers and cloud infrastructures. Subscriptions are a part of those meta relationships.
Using subscriptions to define these relationships introduces a lot of flexibility in how products and systems interact:
  • Associate a single quantity of a product with a single system (which is the most common relationship).
  • Restrict one product so that it cannot be installed on the same system as a specific, different product.
  • Keep a system on a consistent service level. Each subscription includes a definition for what service level (e.g., standard or premium) the product has. Subscription clients first try to assign subscriptions of the same service level (and this can be enforced) so that the system has consistent support levels.
  • Allow virtual guests to inherit some subscriptions from their host.
  • Allow some hosts to have unlimited guests for a data center deployment.
  • Allow a single “subscription” to be broken across multiple systems. This works in something like Red Hat Cloud Infrastructure, where a single purchase actually covers four products — Red Hat Enterprise Linux, Red Hat OpenStack, Red Hat Virtualization, and Satellite 6 Management Engine — and those products each have their own subscription which can be used on different systems to create the stack.
  • Stack or combine subscriptions of the same type to cover a system.

1.3.2. Counting Subscriptions

Part of the subscription service inventory is keeping track of subscriptions – not just what subscriptions are purchased but how many of those subscriptions are available.
When a subscription is first purchased, it defines the quantity of times that the subscription can be used. The subscription count is based on a certain element of the underlying system, most commonly its socket count (but it can be something else, such as the number of cores, depending on the specific subscription). The element of a system or software which is directly covered by a subscription is called an instance.
For example, for the subscription for Red Hat Enterprise Linux for 2 sockets, the product is Red Hat Enterprise Linux and the attribute is a physical socket pair. The socket pair is the instance.
A single subscription quantity is usually tied to a single socket pair (or other attribute). A system with eight sockets, then, requires more subscription quantities to cover its socket count than a four socket system. (This is called stacking.)
This simplistic arrangement, however, does not apply to all subscriptions.
Starting in October 2013, Red Hat began introducing other types of subscription relationships, such as:
  • Multiple products with a single subscription (Red Hat Cloud Infrastructure)
  • Inheritable subscriptions
  • Data center subscriptions, which allow unlimited virtual guests (and only the host requires a specific subscription)
Additionally, the 2013 subscription changes altered how virtual guests are handled in subscriptions. There used to be subscriptions for physical systems and then different subscriptions for virtual guests. In the current subscription model, the same subscription is used for both physical and virtual systems – but the quantity used is different, depending on whether it is a physical system or a virtual one.
As stated previously, a single subscription quantity is used per socket pair on a physical system. A virtual guest counts as a single socket, not a socket pair – so it is essentially half of a subscription quantity. When virtual guests are added to the inventory, the total number of available subscriptions is multiplied by two (the instance multiplier). This allows the subscription count to stay in whole numbers, even with virtual guests taking only a “half” quantity.
However, with some subscriptions counts multiplied by two; data center virtual guests not consuming any individual subscriptions; some subscriptions (Cloud Infrastructure) relating to multiple products installed on different systems; and older, pre-2013-style subscriptions all in the same environment — the actual counts listed in the subscription utilization pages or subscription management tools may not appear to reflect the quantities purchased in the contract. The fundamental counts are the same; most of the differences reflect changes to keep the count whole or new, more flexible subscription types.

1.4. Subscription Terms

Certain terms are used repeatedly throughout the Red Hat Subscription Management documentation, messages, and tools, and it can be easier to understand the subscription lifecycle and management if those terms are clearly defined.
These are some of the most common, relevant terms for Red Hat Subscription Management.
The primary, top-level account for a company. This is the entity that is used within the Customer Portal to define the company and it is where all user and subscription information originates.
Assigning a subscription to a system.
A setting on the local system (or an option with the Subscription Manager tools) that perodically checks for new subscriptions, changing subscription statuses for products, and then automatically assigns new subscriptions to cover the changes. The subscriptions are selected based on the best fit for the system architecture and hardware, installed product, and defined preferences.
A specific file based on the X.509 certificate standard that is used for SSL communication and within a public key infrastructure. This is used to identify elements within Red Hat Subscription Management including identities (systems), installed products, and consumed subscriptions.
An entity registered with a subscription management application. An identity usually correlates to a system, but it can also be a hypervisor, domain, an organization within a management application, or other servers such as RHUI and Satellite.
An element within a system that is covered by a subscription. For physical systems, an instance is most commonly a socket pair. For virtual environments, an instance is a single virtual guest.
The list of systems, hypervisors, applications, and other entities registered with a subscription application. The inventory also contains a list of available and used subscriptions for the organization.
A subdivision in an on-premise application such as Subscription Asset Manager. An organization has its own system inventory and a subset of subscriptions (defined in a manifest). This is a way to define a subscription structure that reflects the IT environment. An organization can be aligned with a physical location or an organizational division in a company.
The complete set of subscriptions and quantities allocated to an organization or account.
A defined criterion used by autoattach operations to select subscriptions. Preferences are set on the local system, but they actually define attributes within the potential subscriptions that should be evaluated for autoattach. There are two preferences: the service level for the subscription and the operating system minor release (the X.Y version, such as 5.10 or 6.5).
The number of subscriptions used to cover a product or system. A subscription covers a set amount of attributes, such as the number of sockets on a physical system. Multiple subscriptions may be required to cover a given system, based on its hardware and configuration.
To add a system or other entity (such as an organization or hypervisor) to the subscription management inventory.
Combining multiple subscriptions to cover a product or system. There are rules applied to what subscriptions can be stacked. For example, only subscriptions of the same service level can be stacked. Also, some subscriptions may restrict what products can be installed with it, so some subscriptions may not be available to some systems.
The cumulative state for a system of all of the installed products and associated valid subscriptions. If all installed products have active subscriptions, the status is valid (green). If some products lack subscriptions or do not have enough quantities of subscriptions to cover its configuration, the status is insufficient (yellow). If a product or system has no subscriptions, the status is invalid (red).
A definition of the products that are available, the support levels, the quantities (or number) of servers that the product can be installed on, architectures that the product is available for, content repositories which supply the product, and other information related to the products.
subscription management application
The backend server which interacts with the individual systems by creating an inventory of systems. It also keeps the inventory of subscriptions, including contracts, quantities, and expiration dates. When a new system is registered, when subscriptions are attached, or when products are installed, the subscription management service manages the changes and issues a corresponding certificate to the system to mark the change. The subscription management service also defines rules for products, such as hardware/architecture restrictions, to help with attaching subscriptions.
Any entity — a physical or virtual machine — which is in the subscription service inventory and which can have subscriptions attached to it.
A summary of the total number of subscriptions available to an organization, and the total number of subscriptions that are attached to Customer Portal Subscription Management, RHN Classic, and different subscription management applications.

1.5. RHN Classic, Satellite, and Channel Entitlements

Beginning in Red Hat Enterprise Linux 6.1, the way that subscriptions are defined was changed. In older subscription models — the model used by RHN Classic and Satellite 4 and 5 — a system required a system entitlement in order to register the system with the subscription service. Then, the system required channel entitlements which granted access to sets of content and software, whatever was defined in the channel.
There was no direct correlation between registered systems, the software installed on them, and the channels to which they were entitled access. There were two separate entitlements pools and even reporting didn't clarify or reveal any relationships.
However, clear subscription tracking is an increasingly critical part of IT maintenance. The older channel-based subscription management process in RHN Classic was great at providing access, but it was very difficult to get an accurate accounting of how subscriptions were applied, how many subscriptions were being used, where subscriptions were being used, and what any individual system was using.
Red Hat Subscription Management uses public-key infrastructure (PKI) certificates to uniquely identify the system, the products on the system, and its attached subscriptions. There is always a correlation, both on the system and in the subscription management service, between systems, products, and subscriptions.
The old and new subscription models are fundamentally different in how they view and structure systems and subscriptions within their inventories. Real-world infrastructures will commonly have a mix of subscription services and system versions. Any infrastructure with Red Hat Enterprise Linux 4.x, 5.7, and 6.0 systems (and older), registered with RHN Classic or using Satellite 4 and 5 will use the older subscription model. Any systems registered to Customer Portal Subscription Management or using Subscription Asset Manager are using the new subscription model.
There are several different paths that administrators can take to manage these mixed environments.
  • Use Satellite 5.6 and Subscription Asset Manager 1.3 for enhanced reporting.
  • Migrate Red Hat Enterprise Linux 5 and 6 systems from the old subscription service to a new subscription service (Subscription Asset Manager or Customer Portal Subscription Management); this moves their registration, updates their attached subscriptions, and changes what client tools are used to manage the system from rhn_register to subscription-manager.
Both have advantages and disadvantages which can be determined by administrators.
From a high-level, both migrating and enhanced reporting extend the benefits of better subscription tracking and maintenance to legacy systems:
  • Consolidate channel entitlements and system entitlements into a single entitlement pool, which is more structurally similar to the new subscription model.
  • Map channel entitlements to new product subscriptions.
  • Correlate installed products on managed systems with corresponding subscriptions, based on their channel subscriptions.
  • Display legacy systems and entitlements in the same style as modern subscription management, to make it easier to create cohesive audit reports.
  • Provide unified views of subscriptions and products for legacy systems and systems registered with Red Hat Subscription Management.