3. Responding to Notifications and Changed Status

3.1. Red Hat Subscription Manager: Autoattaching and Updating Subscriptions

The subscription daemon, rhsmcertd, monitors the subscriptions that are attached to a system and tracks when they near their expiration dates or if they are removed.
When a system has installed products without valid subscriptions, Red Hat Subscription Manager automatically attaches the best-matched subscriptions to cover the installed products on the system. This is the same process, conceptually, as autoattaching the system when registering a system, but this is all done without the administrator having to run a script. This process keeps the subscriptions updated even in a dynamic environment.
There are a couple of common scenarios where autoattaching is useful:
  • As new products are installed.
  • When subscriptions expire.
    Within 24 hours of when the subscription expires, the Subscription Manager automatically re-attaches subscriptions to the system.
  • When subscriptions are renewed.
  • When a subscription management application replaces its manifest.
    If a new manifest is uploaded (instead of refreshing the original manifest), the old manifest is delete. Any subscriptions attached to a system from the old manifest are automatically removed — which means that the system could have products that no longer have a subscription for them. Enabling autoattaching on a system means that the system can automatically request and apply subscriptions from the new manifest.
System autoattaching prevents a system from having products without a subscription as long as any active, compatible subscription is available for it.
Auto-attaching is enabled by default on systems to ensure that they maintain their subscription status. Auto-attaching can be disabled and re-enabled through the given subscription service (such as the Customer Portal or Subscription Asset Manager) and the local autoattaching check for rhsmcertd can be changed.

3.1.1. Setting Preferences for Systems

Autoattaching and updating subscriptions selects what subscriptions to attach to a system based on a variety of criteria, including current installed products, hardware, and architecture. It is possible to set two additional preferences for Subscription Manager to use:
  • Service levels for subscriptions
  • The operating system minor version (X.Y) to use
This is especially useful for healing, which runs daily to ensure that all installed products and current subscriptions remain active.
3.1.1.1. Setting Preferences in the UI
Both a service level preference and an operating system release version preference are set in the System Preferences dialog box in Subscription Manager.
  1. Open the Subscription Manager.
  2. Open the System menu.
  3. Select the System Preferences menu item.
  4. Select the desired service level agreement preference from the drop-down menu. Only service levels available to the Red Hat account, based on all of its active subscriptions, are listed.
  5. Select the operating system release preference in the Release version drop-down menu. The only versions listed are Red Hat Enterprise Linux versions for which the account has an active subscription.
  6. The preferences are saved and applied to future subscription operations when they are set. To close the dialog, click Close.
3.1.1.2. About Service-Level Preferences
Part of a subscription is recognizing the service level for a product on a given system. Setting a preferred service level for a system in Red Hat Subscription Manager means that Subscription Manager uses that preference as part of the criteria for automatically attaching subscriptions to the system the system, either when initially applying subscriptions or when healing subscriptions.
Red Hat service levels are defined in the contract; a summary of production support levels is available at https://access.redhat.com/support/offerings/production/sla.html.
The support, or service, information for each subscription is part of the subscription details. Two attributes are displayed, per subscription: its service level and its service type. The level defines how quickly support is guaranteed to respond to a case. The type defines the methods of communication; for production level support, this is always web and phone.
Service Level Information for a Subscription

Figure 30. Service Level Information for a Subscription

An account can have multiple levels of support available, even for the same product. The support level for a given system can be configured so that the appropriate level of support is available. A production system usually has a premium support level since it is a business critical system, while a development system may have standard support or be self-supported.

Note

By default, the highest available level of support is selected for the subscription and system.
3.1.1.3. Setting Service Levels Through the Command Line
Autoattaching a system sets the best match to the system based on its hardware and architecture, operating system, and installed products. There is an option, when autoattaching a system, to include service level in the process for selecting subscriptions. For example, a production system may prefer to have premium subscriptions over standard.
Setting a service level during registration or subscription does two things:
  • It selects subscriptions on a best match with the desired service level (and other criteria).
  • It sets the system preference to the specified service level.

Note

When a preference is set during registration, during subscription, or in the UI, this preference is applied both to current subscriptions and to renewals and healed subscriptions.
A general service level preference can be set using the service-level --set command.

Example 1. Setting a Service Level Preference

First, list the available service levels for the system, using the --list option with the service-level command. 
[root@server ~]# subscription-manager service-level --list
+-------------------------------------------+
          Available Service Levels
+-------------------------------------------+
Standard
None
Premium
Self-Support
Then, set the desired level for the system. 
[root@server ~]# subscription-manager service-level --set=self-support
Service level set to: self-support
The current setting for the local system is shown with the --show option: 
[root#server ~]# subscription-manager service-level --show
Current service level: self-support
A service level preference can be defined when a subscription operation is being run (such as registering a system or attaching subscriptions after registration). This can be used to override a system preference. Both the register and attach commands have the --servicelevel option to set a preference for that action.

Example 2. Autoattaching Subscriptions with a Premium Service Level

[root#server ~]# subscription-manager attach --auto --servicelevel Premium
Service level set to: Premium
Installed Product Current Status:
ProductName:            RHEL 6 for Workstations
Status:                 Subscribed

Note

The --servicelevel option requires the --auto-attach option (for register) or --auto option (for attach). It cannot be used when attaching a specified pool or when importing a subscription.
3.1.1.4. Viewing Service Level Settings in the Command Line
A system can have multiple service levels available to it. An available level may not be the one that is actually in effect for the system or for a product on the system; it depends on the subscriptions themselves.
Service level information is viewed using the service-level command. This is an information command; it returns the current information about service levels for the system or the account, but it does not make any changes to the assigned service level.
To view available service levels for the system, use the --list option. Simply knowing what levels are available is helpful for setting preferences, autoattaching, or even purchasing subscriptions. 
[root@server ~]# subscription-manager service-level --list
+-------------------------------------------+
          Available Service Levels
+-------------------------------------------+
Standard
None
Premium
Preferences for default service levels can be specified for an account and for a local system, and those two settings do not have to be the same.
The current setting for the local system is shown with the --show option: 
[root#server ~]# subscription-manager service-level --show
Current service level: Premium
3.1.1.5. Setting a Preferred Operating System Release Version in the Command Line
Many IT environments have to be certified to meet a certain level of security or other criteria. In that case, major upgrades must be carefully planned and controlled — so administrators cannot simply run yum update and move from version to version.
Setting a release version preference limits the system access to content repositories associated with that operating system version instead of automatically using the newest or latest version repositories.
For example, if the preferred operating system version is 6.3, then 6.3 content repositories will be preferred for all installed products and attached subscriptions for the system, even as other repositories become available.
Only packages, updates, and errata for that specific version will be used for the system.

Example 3. Setting an Operating System Release During Registration

A preference for a release version can be set when the system is registered by using --release option with the register. This applies the release preference to any subscriptions selected and auto-attached to the system at registration time.
Setting a preference requires the --auto-attach option, because it is one of the criteria used to select subscriptions to auto-attach. 
[root#server ~]# subscription-manager register --auto-attach --release=6.4 --username=admin@example.com...

Note

Unlike setting a service level preference, a release preference can only be used during registration or set as a preference. It cannot be specified with the attach command.

Example 4. Setting an Operating System Release Preference

The release command can display the available operating system releases, based on the available, purchased (not only attached) subscriptions for the account. 
[root#server ~]# subscription-manager release --list
+-------------------------------------------+
          Available Releases
+-------------------------------------------+
6.2
6.3
The --set then sets the preference to one of the available release versions: 
[root#server ~]# subscription-manager release --set=6.3
Release version set to: 6.3
3.1.1.6. Removing a Preference
To remove a preference through the command line, use the --unset with the appropriate command. For example, to unset a release version preference: 
[root#server ~]# subscription-manager release --unset
Release version set to:
To remove or unset a preference in the UI:
  1. Open the Subscription Manager.
  2. Open the System menu.
  3. Select the System Preferences menu item.
  4. Set the service level or release version value to the blank line in the corresponding drop-down menu.
  5. Click Close.

3.1.2. Autoattaching in Response to Notifications

When the Subscription Manager UI opens, whether it was opened through a notification or just opened normally, there is an icon in the upper left corner that shows whether products lack a valid certificate. The easiest way to attach subscriptions which match invalidated products is to click the Auto-attach button.
Auto-attach Button

Figure 31. Auto-attach Button

3.1.3. Autoattaching at Registration

The register command has an option, --auto-attach, which allows the system to be registered to the subscription service and immediately attaches the subscriptions which best match the system's architecture, in a single step. 
[root@server1 ~]# subscription-manager register --username admin-example --password secret --auto-attach

3.1.4. Autoattaching after Registration

The --auto option with the attach (which is analogous to the --auto-attach option with the register command) attaches the best-fitting subscriptions to the system based on it's currently installed products and other criteria. 
[root@server1 ~]# subscription-manager attach --auto
Running this after registration may be useful if the system has add-on products like Cluster Suite or layered products like Red Hat Directory Server installed. Since these products are not installed by default, autoattaching at registration time may not apply the appropriate subscriptions to the machine. Autoattaching after they are installed can make it easier to attach the proper subscriptions, and it is a little easier since it is not necessary to find and select a pool ID.