Introduction to Red Hat Subscription Management Workflows

Red Hat Subscription Management 2023

finding and utilizing the best subscription management workflow for your environment

Customer Content Services


Red Hat Subscription Management tools and applications provide different ways to view system-level and organization-level notifications and statuses. There are multiple workflows to cater to an individual customer environment, and understanding what each does is the best way to learn to select which workflow to use.

1. Understanding your workflow for subscribing with Red Hat products

Before you can register your systems with Red Hat Subscription Management, you need an active subscription and available entitlements. Subscriptions can be purchased through the Red Hat Store or by contacting Sales directly.

  1. A system is registered to the inventory for the subscription service. This means that the subscription service can manage the server and attach subscriptions to it
  2. A subscription is attached to a system
  3. The system downloads software packages and updates from the content delivery network for as long as the subscription is active

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

Subscription management delivers better information and offers administrators better control over their infrastructures.

1.1. Introduction to Red Hat Subscription Management

Red Hat Subscription Management tracks the Red Hat products your organization has purchased and the systems on which the products are installed. Subscription Management establishes the relationship between the product subscriptions that are available and the elements of infrastrcuture of your business where those subscriptions are allocated.

2. Tools and applications available for Red Hat Subscription Management

All Red Hat Enterprise Linux subscriptions automatically include some tools for managing the subscription configuration:

  • Red Hat Subscription Manager client tools to manage local systems
  • Red Hat Subscription Management in the Customer Portal to manage systems and subscription application organizations for a single account globally through the Customer Portal
  • Red Hat Satellite as an on-premise solution for systems that may not regularly check in

The diversity of tools allows administrators to create a workflow that fits both the business and infrastructure demands of their organization.

2.1. Red Hat Subscription Manager

Both registration and subscriptions are managed on the local system through UI and CLI tools called Red Hat Subscription Manager. The Subscription Manager tracks and displays what subscriptions are available to the local system and what subscriptions have been consumed by the local system. The Subscription Manager works as a conduit back to the subscription service to synchronize changes like available product quantities or subscription expiration and renewals.


The Red Hat Subscription Manager tools are always run as 'root'' because of the nature of the changes to the system. However, Red Hat Subscription Manager connects to the subscription service as a user account for the subscription service.

The Subscription Manager handles both registration and subscriptions for a system. The Subscription Manager is part of the firstboot process for configuring content and updates, but the system can be registered at any time through the Red Hat Subscription Manager UI or CLI. New subscriptions, new products, and updates can be viewed and applied to a system through the Red Hat Subscription Manager tools.

Red Hat Subscription Manager has two tools in its set, a UI-based client to manage the local machine and a CLI client for advanced users (which can be used to work with other applications or in scripting management tasks, like kickstarting machines.

These tools allow administrators to perform three major tasks directly related to managing subscriptions: registering machines, assigning (attaching) subscriptions to systems, and updating the certificates required for authentication. Some minor operations, like updating system facts, are available to help display and track what subscriptions are available.

2.1.1. Launching Red Hat Subscription Manager

  • In Red Hat Enterprise Linux 7, Subscription Manager is accessed from the System Tools > Administration menu in the top management bar.
  • In Red Hat Enterprise Linux 8, Subscription Manager is accessed from the Activities > Show All Programs menu in the top management bar.

3. Managing subscription workflows

There are different types of systems and different ways of organizing systems. The underlying concepts of a subscription server and content provider are flexible enough to accommodate special types of systems and different infrastructure setups.

3.1. Planning the right workflow to use

Subscription and content services work in tandem. The local Red Hat Subscription Manager client on a system must identify a subscription service and a content delivery service. These can both be hosted services, both locally-managed services, or a mix.

All subscription and content data originates with Red Hat. By default, all Red Hat Enterprise Linux systems are configured to point to the Red Hat hosted services. If administrators use an on-premise server for subscription or content management, that on-premise server first obtains its information from the Red Hat hosted services, and then manages the local systems. Red Hat subscription inventories are aware of the on-premise subscription application, then, but not aware of any of the local systems that subscription application manages.

The Red Hat Subscription Manager configuration points to two servers, the subscription server and content server. These two settings can be changed (independently) to use any supported subscription server or content server.

Table 1. Subscription and Content Services by Source

Subscription ServiceSupports Subscription ServicesSupports Content Delivery ServicesRecommended Environment Types

Red Hat Subscription Management in the Customer Portal



No need to script subscription or content updates

Red Hat Satellite 6



Business with security rules that preclude hosted services, Custom content and deployment scripts, and system management along with subscription/content management


A user account is associated with an activation key and is used to redeem the activation key — but which user account to use depends on who issued the key. If a key was created by a vendor, then they will also define a user account to use with the key, as will Red Hat if the key were issued by Red Hat. For activation keys created by local IT departments using Subscription Asset Manager, then the associated Subscription Asset Manager user account is to be used.

3.2. Understanding autoattaching subscriptions on the Customer Portal

Subscription management for a Red Hat Enterprise Linux system has two steps to it: registering the system to a subscription service and then applying subscriptions for the operating system and products installed on that system. By default, when attaching subscriptions to a system through the Red Hat Subscription Manager user interface on a system or through firstboot, these two steps are performed at the same time.

The Red Hat Subscription Manager configuration can point to any subscription server or content server. By default, it points to Red Hat’s hosted services.

So, using the default configuration, then system is registered with Customer Portal Subscription Management hosted services and the best-matched available subscriptions are automatically attached to the system.

3.2.1. Environments for autoattaching subscriptions on the Customer Portal

Hosted services are designed for IT environments where simplicity of deployment is the most important consideration. This is for small businesses or businesses with small Linux infrastructures:

  • Fewer than 20 Linux servers
  • Limited IT resources for system maintenance
  • No business need to create custom subscription or content utilities

Hosted services make it easier to administer a small number of machines:

  • Simple to implement, since it uses the default system configuration
  • No additional software or hardware overhead
  • Possible to migrate to on-premise subscription/content services based on organization configuration later
  • The same subscription services for all systems, even if the systems are in different data centers or geographic locations

Hosted services do have some potential issues related to the overall network performance. As the IT infrastructure grows, then there could be local bandwidth or latency issues if a large number of systems are attempting to retrieve content or receive updates.


Even if a small IT environment uses Red Hat hosted services at the start, it can be expanded to use on-premise subscription or content services in the future.

3.2.2. Automatically attaching subscriptions on the Customer portal

When automatically attaching matched subscriptions (the default setting in the Red Hat Subscription Manager UI or '--auto-attach' with the subscription-manager command), there is only a single step to the registration process.

3.2.3. Options and details for autoattaching subscriptions on the Customer portal

Most of the options are configuration settings that can be set after registration.

  • Attaching additional subscriptions, which is especially useful if the system is autoattached during firstboot, when subscriptions are only attached for the operating system.
  • Overriding system facts, which is used by the autoattach and healing processes to determine what the system architecture and hardware is for finding compatible subscriptions.
  • Setting a service level preference (this can also be done during registration, so it is used as one of the priorities when selecting subscriptions).
  • Setting a release preference, so that the system only updates for software targeted to that release version and ignores any upgrades to a later operating system version.
  • Enabling or disabling associated yum repos.

3.3. Understanding the manual registration and subscription on the Customer Portal

While system registration and subscription can be performed in a single step (autoattaching), these are separate configuration areas. That means that the steps can be performed separately, which offers much more control over how systems are provisioned and how subscriptions are assigned.

With autoattaching, whatever subscriptions best match the system’s architecture and currently installed products are attached automatically. This can be limiting in certain instances. For example, registering during firstboot would only attach the operating system subscriptions since no other products would yet be installed. Or, there may be a product which is not yet installed on a system, but will be soon, or a package listed for 32-bit systems which will be run on a 64-bit system.

In any of those cases, the autoattach process cannot detect the desired subscriptions because there are no settings on the system which would signal which subscriptions to include.

Dividing the registration and subscription processes allows administrators to manually select subscriptions and attach them to the systems.

3.3.1. Environments for manually attaching subscriptions on the Customer Portal

There is nothing about registering and then applying subscriptions manually which requires that a system use Red Hat’s hosted services.

There are some benefits, particularly for small businesses or infrastructures with relatively few Linux systems, to using hosted services. As with the autoattach process, using the hosted services minimizes the administrative overhead since it uses the default system configuration and requires no maintenance from IT staff.

3.3.2. Manually attaching subscriptions on the Customer Portal


  1. Open Subscription Manager on the system you need to register.
  2. Select the Available Subscriptions tab.
  3. Select the subscriptions to attach to the system.

To register a system using the command line interface, enter the 'subscription-manager register' command with your Customer Portal credentials.

3.3.3. Options and details for manually attaching subscriptions to the Customer portal

Most of the options are configuration settings that can be set after registration.

  • Setting a service level preference (this can also be done during registration, so it is used as one of the priorities when selecting subscriptions).
  • Setting a release preference, so that the system only updates for software targeted to that release version and ignores any upgrades to a later operating system version.
  • Enabling or disabling associated yum repos.

3.4. Understanding registration using firstboot

Registering a system during firstboot is the same as registering a system using Red Hat Subscription Manager later, so there is no special workflow associated with it. The main reason for mentioning firstboot is that the firstboot wizard does provide several different ways to configure the system for subscriptions and content updates. The system always has some kind of subscription configuration, from the first time it is configured, and understanding those options can make it easier to administer the system later.

During firstboot, the subscription service and attached subscriptions are configured in the Set Up Software Updates screens. There are three choices:

  • Red Hat Subscription Management
  • Red Hat Satellite
  • Register later

By default, firstboot registers the system to Customer Portal Subscription Management and autoattaches compatible subscriptions. Selecting the Skip automatic subscription selection…​ checkbox disables autosubscription, so that the system can have subscriptions attached manually.

The firstboot options for setting up the content server are the same as using Red Hat Subscription Manager to configure an existing system.

3.5. Understanding registering subscriptions using Kickstart

Kickstart is a key component for provisioning systems. Subscription setup can be included in kickstart instructions as a post-install script.

Kickstart setups can follow any workflow an administrator wants to use: registering to hosted services, registering with a Subscription Asset Manager instance using an activation key, manually attaching subscriptions, whatever. First learn which subscription workflow to use, and then use the subscription-manager command to run through each of the required steps.

3.5.1. Environments for using Kickstart to attach Subscriptions

Kickstart is used to script system creation, so this is used in environments where instances may be created and destroyed routinely, such as test environments, or in data centers and private clouds.

3.5.2. Attaching subscriptions using Kickstart

To register a system and attach subscriptions as part of Kickstart, run the 'subscription-manager'' command as a post-install script"

subscription-manager register --username username --password password --auto-attach

In this example, the subscription configuration is the default configuration, meaning that the system is registered with the Red Hat Subscription Management (hosted) system. Additionally, this uses the ''--auto-attach'' option to attach the best-matched subscriptions.

3.5.3. Options and details for attaching subscriptions using kickstart

Kickstart can follow any of the supported configurations, but it can require using additional post-install scripts first to set up the environment.

  • Set a service level preference using the '--servicelevel' option.
  • To attach subscriptions manually, leave off the '--auto-attach' option and run a second script with the attach command or add the subscriptions later.
  • By default, Red Hat Subscription Manager uses the Customer Portal hosted subscription and content services. To use an on-premise service like Subscription Asset Manager, first run the subscription-manager config command and reset the Red Hat Subscription Manager configuration, and then register the system using the new configuration.
  • To register a system and attach subscriptions using an activation key, first configure Red Hat Subscription Manager to use the appropriate subscription service and then register with the activation key.

3.6. Understanding attaching subscriptions for hypervisors and guests

Red Hat Enterprise Linux has an optional service which can automatically detect guests on a virtual host system, create a map of hosts to guests, and register guests as virtual systems. This allows subscriptions which are specific to virtual systems to be available to the guest and for subscriptions which are inherited from the host to be applied to the guest automatically. Supported virtualization platforms to which a Virtual Data Center (VDC) subscription can be applied are:

  • Red Hat Virtualization (RHV)
  • Red Hat OpenStack Platform (RHOSP)
  • Red Hat Enterprise Linux hypervisors
  • VMware vSphere
  • Microsoft Hyper-V

The 'virt-who' daemon does not currently support Microsoft System Center 2012 R2 Virtual Machine Manager (SCVMM). There must be a virt-who configuration file for each Microsoft Hyper-V host to which v is to connect.

3.6.1. Environments for attaching hypervisor and guest subscriptions

For subscriptions to be managed effectively — particularly with inheritable subscriptions or interactions between subscriptions — there has to be an internal awareness in the subscription service of the relationships between hosts and guests. This is a host/guest mapping, which is a list of all of the guest identifiers for a given hypervisor.

Hypervisors are registered as a special type of consumer in Red Hat Subscription Management. Hypervisors themselves are managed as regular physical systems, but the hypervisor type indicates that that particular system will have guests mapped to it, and that subscriptions may be inheritable or applied differently to those guests.

With a host/guest mapping to associate every guest with a specific host, a subscription service can properly attach a single subscription to a virtual host and then apply an included and inheritable subscription to its guest (for example), rather than consuming two separate subscriptions for each instance.

This association is done by extracting a universally unique identifier for each guest and associating it with its hypervisor. These UUIDs are part of the system facts for each virtual system.

The hypervisor is registered first, and then a related process on the system scans for any guests and submits the discovered UUIDs to the subscription service. This is done by the 'virt-who' process on the hypervisor.

3.6.2. Registering hypervisors or guest subscriptions


The 'virt-who process must be running on the virtual host or on a hypervisor in the environment (for VMware) to ensure that 'virt-who' process maps the guest to a physical host, so the system is properly registered as a virtual system. Otherwise, the virtual instance will be treated as a physical instance.


Virtual machine hypervisors use the same registration process as other systems:

  1. Enter the command:

    # sudo subscription-manager register

3.7. Understanding the registration of disconnected systems

Disconnected systems are a unique use case because the system is offline, either off the corporate network or possible entirely lacking Internet access. This means that the system has no ability to access any subscription or content services, so any changes to the system must be manual.

3.7.1. Environments for registration of disconnected systems

Disconnected systems are simply any system that cannot connect to the Internet or, possibly, even an intranet. The products and subscriptions for that system, and the system itself, should still be included in an inventory.

This frequently means servers in secure locations where they are prevented by business rules from connecting to the Internet. It can also include backup systems, which may be kept offline until needed.

Most of the subscription and content operations are performed over the network. For example, the 'rhsmcertd' process checks for updated subscription information every four hours by connecting to the given subscription service. If a system cannot connect to the Internet, than almost all of those management tasks cannot be performed.

3.7.2. Registering disconnected systems to Red Hat

Administrators may want to attach and track subscriptions for a system with limited connectivity or inconsistent access to the Internet. To register an offline or "air-gapped" system, you need to manually create a system profile using Red Hat Subscription Management in the Customer Portal.


This profile serves as a placeholder and is not connected to your actual system until it can access the Internet again.


  1. Create a system profile. From the systems page in Red Hat Subscription Management, click the New button. Provide the required information to finish creating the new system profile.
  2. Attach subscriptions. In your newly created system profile, click the Subscriptions tab, and attach any subscriptions you want to use with the system.
  3. Download and import the entitlement certificate(s). From the Subscriptions tab on your system profile, click Download Certificates to download the entitlement certificate(s) for attached subscriptions. The downloaded file will be in zip format. Extract the content and in /export/entitlement_certificates/ folder you will find the certificate xyz.pem. Move it to the client system’s /tmp directory.

    # subscription-manager import --certificate=/tmp/Name_Of_Downloaded_Entitlement_Cert.pem

3.7.3. Options and details for registering a disconnected system

Virtually all of the additional configuration options — both system-level configuration like setting a service level and infrastructure-level configuration like using a different subscription or content service — are not applicable to a disconnected system as long as it is disconnected. Most parameters, such as autoattaching, configure operations that occur automatically over the network.

One thing to plan is what configuration should be used if the system is ever brought online. For example, if the rest of the infrastructure is using Satellite 6 rather than Customer Portal Subscription Management hosted services, the disconnected system should probably also be registered to the Satellite 6 services rather than Red Hat Subscription Management. For security rules, that system may never be brought online, so that configuration may always be irrelevant. Backup systems could come online at any time, which would make proper configuration important.