Using Notification and Reports with Red Hat Subscription Management

Red Hat Subscription Management 1

to view and respond to system notifications, infrastructure reports, and other subscription information

Red Hat Subscription Management Documentation Team

October 1, 2013

Abstract

Red Hat's Subscription Management tools and applications provide different ways to view system-level and organization-level notifications and statuses and to respond to changing subscription needs. This guide details the different reporting and notification mechanisms and some quick paths to remediating insufficient and expired subscriptions.

1. About Subscription Status, Notifications, and Compliance

IT hardware needs to be managed and clearly inventoried, and the software installed on those machines also needs to be managed and clearly inventoried. 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.
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 certifications, 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.
Subscription management is a way of identifying and creating relationships between the systems in your IT environment and the software products that you have available through Red Hat.
Subscriptions follow a set lifecycle:
  1. An account buys a subscription to a product, which gives them access to Red Hat's Content Delivery Network, errata and patches, upgrades, and support.
    A subscription is usable or valid for a set amount of time and can be used a certain number of times (the quantity).
  2. A server is added, or registered, to the inventory for the subscription management service. Once the system is added, there is a list of facts defining attributes about the system and a profile which lists the installed products and their versions.
  3. A subscription is attached to a system, so that the system is entitled to support services and content for that product.
    Subscriptions can be manually assigned by an administrator or they can be automatically attached by the subscription process based on what subscriptions best match the system attributes and installed products.
  4. As the validity period of the subscription ends or as new products are added, then new subscriptions must be attached to the system so that it maintains coverage.

1.1. About Relationships Between Subscriptions and Systems

1.1.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 — 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.1.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.2. Status: Expiration and Validity Ranges

Subscriptions are active for a certain period of time, called the validity period. When a subscription is purchased, the start and end dates for the contract are set.
On a system, there can be multiple subscriptions attached. Each product requires its own subscription. Additionally, some products may require multiple quantities of subscriptions for the product to be fully covered. For example, a 16 socket machine may require four 4-socket operating system subscriptions to cover the socket count.
The My Installed Software tab shows the subscription status for the entire system. It also shows a date; that is the first date that a product subscription goes from valid to invalid (meaning it expires).
Valid Until...

Figure 1. Valid Until...

For example, if you have a Load Balancer subscription that expires on April 17 and all other product subscriptions are valid until October 1, the Certificate Status summary show that the certificates are valid until April 17, the closest expiration date.
Subscriptions can string together in a queue. For example, you have a 4-socket system that uses two 2-socket subscriptions to cover the socket count. However, the system actually has three subscriptions attached to it:
  • 2-socket subscription A expires April 1, 2012.
  • 2-socket subscription B expires July 31, 2013.
  • 2-socket subscription C starts March 1, 2012 and expires April 1, 2014.
The system is valid through July 31, 2013, because Subscription C is already queued up to replace Subscription A when it expires.

1.3. Different Subscription States

All of the subscription management tools — Red Hat Subscription Manager on the local systems, Subscription Asset Manager for on-premise services, and Customer Portal Subscription Management for hosted services — provide a series of log and UI messages that indicate any changes to the valid certificates of any installed products for a system.
The status of the system subscriptions is color-coded, where green means all subscriptions are attached for all installed products, yellow means that some products may not have all of the required subscriptions attached but updates are still in effect, and red means that updates are disabled.
Color-Coded Status Views

Figure 2. Color-Coded Status Views

The command-line tools also indicate that status of the machine. The green, yellow, and red codes translate to text status messages of subscribed, partially subscribed, and expired/not subscribed, respectively.
[root@server ~]# subscription-manager list
+-------------------------------------------+
    Installed Product Status
+-------------------------------------------+

ProductName:            Red Hat Enterprise Linux Server
Status: Not Subscribed
Expires:
SerialNumber:
ContractNumber:
AccountNumber:

Table 1. Status Labels and Icons

Icon Message Description
  • Valid
  • Subscribed
  • Sufficient
All products on the system have a valid subscription attached for it, and the system itself is fully covered (there are adequate subscriptions for the core, socket, or RAM counts).
  • Insufficient
  • Partially subscribed
Some products do not have subscriptions or do not have an adequate number of subscriptions attached. Updates and support policies are still in effect.
  • Invalid
  • Not subscribed
No subscriptions are attached to the system or to the product. Updates will be disabled and support responses may be affected.

1.4. Notifications and Messages

Part of Red Hat Subscription Manager on local systems is the rhsmcertd process, which interacts with the subscription service to check for new subscriptions, monitors subscription expiration for subscriptions attached to the local system, and tracks installed products for required subscriptions.
rhsmcertd provides a mechanism for issuing warnings for expiring or insufficient subscriptions on the local system. Because it interacts with the subscription service (such as Customer Portal Subscription Management or Subscription Asset Manager), there are also views in the subscription management application dashboards which show the overall status of individual systems and of the infrastructure as a whole.
In practice, subscription compliance is managed at the system-level, so Red Hat Subscription Manager messages and notifications are invaluable for responding to systems. For overall infrastructure tracking, resource planning, and regulatory or standards compliance, then the high-level overviews in Customer Portal Subscription Management or Subscription Asset Manager are exceptionally useful for auditing, purchasing, and other planning activities.

1.5. Compliance: Ways to Remediate Changing Subscription States

When a system has insufficient or expired subscriptions, the way to remediate it is to update the subscriptions for the system. This can be done manually, but the most efficient management is to enable autoattaching on the systems so that subscriptions are automatically attached or updated when the subscription status for the system changes.
Autoattaching is part of the rhsmcertd process. Every four hours (in the default configuration), the rhsmcertd process checks the current installed products, the current attached and active subscriptions, and the available subscriptions in the subscription service. If autoattaching is enabled, then the rhsmcertd process can automatically use the best-matched subscriptions.
It is also possible to run an asynchronous autoattach operation. On the local system, this can be done with the Red Hat Subscription Manager utilities. Both Subscription Asset Manager and Customer Portal Subscription Management also provide options to initiate an autoattach operation on all registered systems.