Subscription-Manager for the former RHN user, part 13: System Purpose

Subscription-Manager for the former RHN user, part 13: System Purpose (or how I learned to love subscriptions again).

What is system purpose and why should I care about it?

System purpose is a means to tag Red Hat Enterprise Linux systems with additional subscription-pertinent information to better inform Red Hat's subscription reporting tools, such as the subscription service and drive more accurate reporting.

System purpose provides a means to articulate certain aspects of "what makes up a subscription" which generally cannot be easily measured. While the binary bits for RHEL's use-cases are the same, RHEL subscriptions are priced differently based on use-cases and supportability. Tracking this information is important as it impacts purchasing decisions. System purpose provides a means to note these use-cases without the complexity of attaching subscriptions. These include:

• Technical use case information, e.g. Is this RHEL system being used as Server, Workstation, or Computenode
• Business use case information, e.g. Is this system being used in a Disaster Recovery environment?
• Operational use case information, e.g. Is this system Premium or Standard? Is this system being used in Production or Development use-cases?

So as an example, if you own RHEL subscriptions of differing SLAs (Premium v. Standard), system purpose allows the ability to tag the systems in your environment so that the subscription reporting tools know which systems should be counted in which category.

Requirements:

• Red Hat Satellite 6.5 or newer
• Red Hat Customer Portal
• Red Hat Enterprise Linux 10.0+, 9.0+, 8.0+ or 7.7+

System purpose is part of the subscription-manager family of tools, and is also exposed via the redhat_subscription Ansible module, the Web Console in RHEL8+, Satellite, and the Red Hat Hybrid Cloud Console

Now that we understand what system purpose is, let’s dive into how to use it.

Getting started with system purpose.

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 for inventory & reporting purposes.

• 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?
  • E.g Development (assistance with design), Production (assistance with installation and runtime issues)

Let’s walk through setting up system purpose on a new RHEL 10.0 system.

For this system, I plan to use it as a Server, so I select ‘Red Hat Enterprise Linux Server’ as its ROLE. I want to tag this system as ‘Premium’ for its Service Level Agreement - SLA, and I want Production Support so I select ‘Production’ as my USAGE.

In RHEL 8.2 (and newer) , you can register to Red Hat Subscription Management during installation, but for this example, we are going to skip that step.

After login, let’s take a look at the system purpose that was set during installation and get the system registered.

Firstly, let’s take a look at the various options available:

# subscription-manager syspurpose --help
usage: subscription-manager syspurpose [SUBMODULE] [OPTIONS]

Convenient module for managing all system purpose settings

options:
  -h, --help            show this help message and exit
  --proxy PROXY_URL     proxy URL in the form of hostname:port
  --proxyuser PROXY_USER
                        user for HTTP proxy with basic authentication
  --proxypassword PROXY_PASSWORD
                        password for HTTP proxy with basic authentication
  --noproxy NO_PROXY    host suffixes that should bypass HTTP proxy
  --no-progress-messages
                        Do not display progress messages
  --show                show current system purpose

Syspurpose submodules:

    role                Show or modify the system purpose role setting
    service-level       Show or modify the system purpose service-level setting
    usage               Show or modify the system purpose usage setting

Let’s confirm that System Purpose Attributes we set during installation are applied.

# subscription-manager syspurpose --show
{
  "addons": [],
  "role": "Red Hat Enterprise Linux Server",
  "service_level_agreement": "Premium",
  "usage": "Production"
}

With system purpose defined, let’s register the system. Note: this example uses the subscription-manager command for brevity and maximum compatibility with older versions of RHEL. Most modern versions of RHEL should use the rhc command as documented in the Getting Started with RHEL Registration Guide

# subscription-manager register
Registering to: subscription.rhsm.redhat.com:443/subscription
Username: [redacted]
Password: [redacted]
The system has been registered with ID: f4cc3ae4-5077-4f33-a710-a3d374705183
The registered system name is: syspurpose.example.com

To change system purpose values, we can use the subscription-manager syspurpose command. For example, if I wanted to set the SLA of this system to Standard, versus its currently configured Premium, simply issue the subscription-manager syspurpose service-level command with the appropriate arguments.

# subscription-manager syspurpose service-level --set "Standard"
service_level_agreement set to "Standard".

and this can be confirmed by running either subscription-manager syspurpose service-level (to show just the service-level value) OR subscription-manager syspurpose (to show ALL configured system purpose values)

# subscription-manager syspurpose service-level
Current Service-level: Standard

OR

# subscription-manager syspurpose --show
{
  "addons": [],
  "role": "Red Hat Enterprise Linux Server",
  "service_level_agreement": "Standard",
  "usage": "Production"
}

System Purpose and the subscription service:

For example, in the subscription service, the ability to filter via SLA is driven by the system purpose attributes which are set on hosts (via the CLI, Satellite or RHSM). It is key, if you wish to filter per SLA (and in the future USAGE, ROLE, and SERVICE TYPE), it is critical to set the system purpose attributes.

System Purpose and Activation Keys

Activation Keys, which can be used in lieu of username/password to register systems, can also have System Purpose attributes associated with them

Hopefully, this post has helped you to understand what System Purpose is, and how it helps to improve your subscription experience.