3.2.1. Setting a Preferred Service Level
There are three basic support levels:
An account can have multiple levels of support available, even for the same product, and, obviously, not every system within an IT environment demands the same response times and support as other systems. For example, 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.
By default, the highest available level of support is selected for the subscription and system.
When a system is configured, it can be assigned a preferred service level. When subscriptions are autoattached to the system and the preferred service level is available, then the subscription matching that preference is used. (Service-level preferences are not evaluated or enforced for manually selecting and attaching subscriptions.)
Service-level preferences must first be set locally on the client when it is registered, by autoattaching, or when editing the configuration later. For example:
[root#server ~]# subscription-manager attach --auto --servicelevel Premium
After the service-level preference is set for the system, then that preference can be viewed and edited through the Portal.
The service-level preference is set in the system details page.
Figure 32. Service-Level Preference
3.2.2. Viewing the Operating System Release Release Preference
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.
A release version preference can only be set using the local Red Hat Subscription Manager tools. However, if a release preference is set for the local system, that preference is viewable for that system in the portal.
Figure 33. Operating System Release Version Preference Setting
3.2.3. Autoattaching Subscriptions
The subscription service can monitor the subscriptions that are attached to a system and track when they near their expiration dates. Within 24 hours of when the subscription expires, the Subscription Manager automatically re-attaches the system to a matching new subscription so that the subscription status remains green.
Autoattaching prevents a system from having uncovered products as long as any active, compatible subscription is available for it.
22.214.171.124. Enabling Autoattach on a System
Autoattaching is enabled by default on systems to ensure that they maintain their subscription status. Autoattaching can be disabled and re-enabled by toggling the
buttons on the system's details page.
Figure 34. Toggling Autoattaching
126.96.36.199. Initiating an Autoattach Operation on All Systems
Autoattach is configured on individual systems and is generally a local operation. However, there can be times when it is easier or more beneficial to initiate an asynchronous, mass-update of systems, such as when a new set of subscriptions are purchased or a large number of new systems are provisioned.
At the bottom of the Units area is a button to run an autoattach operation on all registered systems. This applies any available subscriptions to any system as required to bring them all into a proper (green) status.
Figure 35. Attaching to All Systems