Subscription-manager for the former Red Hat Network User: Part 9 - A Case Study with activation keys.

This article was originally published on the Red Hat Customer Portal. The information may no longer be current.

Overview

Activation keys are one of the more important features in the workflow of provisioning and registering hosts. They setup many of the things needed to properly build a host.

Prerequisites

It is important that you have read (or understand) the concepts as presented in:

• Subscription-manager for the former Red Hat Network User: Part 3 - Understanding virt-who
• Subscription-manager for the former Red Hat Network User: Part 4 - Understanding Subscription Manifests
• Subscription-manager for the former Red Hat Network User: Part 5 - working with subscriptions that require virt-who

What is an activation key?

An activation key is a token issued by a subscription management service, such as Satellite, Satellite 6, or Red Hat Subscription Management that allows you the ability to register a host without a username/password.

In addition to no longer requiring a username/password, activation keys are useful for automation as they can set many subscription and content related items at registration.

In the scope of this document, we'll discuss activation keys in Satellite 6.

What properties can be set on an activation key?

Using multiple activation keys, ordering and precedence

Given the number of options above and the variety of hosts that you may be deploying, a single activation key may not be sufficient to get the host registered and configured the way you like.

It is generally recommended to use activation keys in the 'UNIX Model', where a key will do 'one thing well' and you combine multiple keys to achieve your desired effect. That doesn't mean create an activation key for every setting, but try to make your activation keys re-usable across multiple workloads.

Multiple activation keys can be used by providing them comma separated to subscription-manager as such:

# subscription-manager register --activationkey=First_AK,Second_AK --org Example

If you are using Satellite 6 for provisioning, you can define the activation keys on a hostgroup which allows the appropriate subscription-manager commands to be rendered when the host is provisioned. This is done by using the Activation Key tab on the Hostgroup page of the Web UI, or via hammer, similar to the following

hammer hostgroup set-parameter \
  --name kt_activation_keys \
  --value 'First_AK,Second_AK' \
  --hostgroup 'NAME_OF_HOSTGROUP'

As you can provide potentially conflicting settings via multiple activation keys, it is important to understand what happens in that situation.

Generally speaking, for items that conflict, the rightmost activation key takes precedence. Thus, ordering matters. subscription-manager register --activationkey=First_AK,Second_AK is not the same as subscription-manager register --activationkey=Second_AK,First_AK

Settings that will conflict (and the rightmost setting wins):

• Service Level
• Release Version
• Environment
• Content View
• Product Content

Some of the other settings do not conflict and the host will get the union of them. These include:

• Subscriptions
• Host Collections

Settings that influence the behavior of the key itself (and these operate independently):

• Host Limit
• auto attach

Auto attach behavior with Red Hat Subscriptions on activation keys

When configuring a key with the intent of getting a Red Hat subscription attached, the presence (or absence) of Red Hat Subscriptions and the auto attach property will change how an activation key behaves.

• Use Case 1: Use EXACTLY the subscriptions specified

  You can associate a subscription (or multiple subscriptions) to a key, and force that (those) subscription(s) to be applied. This was the default and only behavior in Red Hat Satellite 6.0

• Use Case 2: Define NO subscriptions, and auto attach something proper

  You can associate no subscription to a key, set the key to auto attach, and the key will pick the best subscription. This is similar to running subscription-manager register --auto-attach. This activation key type is VERY useful when provisioning virtual guests as it allows you to take advantage of the following behavior:

  • If the hypervisor is known to the Subscription Management Platform, the virtual machine has been reported via virt-who, and an unlimited guest subscription is already attached to the hypervisor , the guest will consume the virtual guest pool that already exists for the hypervisor.
  • If the hypervisor is known to the Subscription Management Platform and the virtual machine has been reported via virt-who, but the hypervisor does not have a valid subscription, an unlimited guest subscription will get attached to the hypervisor which will cover itself and the virtual machine.
  • If the hypervisor is known to the Subscription Management Platform, but the guest has NOT been reported via virt-who yet, the guest will consume a 24 hour temporary guest subscription.

• Use Case 3: Use ANY of a subset of subscriptions

  You can associate n subscriptions to a key, set the key to auto attach, and then auto attach will apply only to the listed subscriptions.

The table below illustrates these use cases:

Difference between Activation Key Behavior with Red Hat Products versus Custom Products

Activation keys have different behavior when they are being used with Red Hat Products versus Custom Products (which usually are used to reflect non-Red Hat software). Custom Products will always attach regardless of auto attach settings.

General Best Practices for Activation Keys

As a general practice, follow the UNIX model of 'doing one thing well' with activation keys, as it allows their reuse. Additionally, which activation key that was used to register a host is stored as part of the host's profile, allowing you the ability to query this via the UI or API. Lastly, by having activation keys that do one thing well and combining them, activation key sprawl is prevented, or at least reduced

Since subscriptions grant access to content, it is recommended to create keys with the following workflow:
- attach a valid subscription.
- configure a host with the proper lifecycle environment and content View
- [Optional] attach subscriptions for custom (non Red Hat) content.

Depending on the deployment, this may be accomplished with 1 or more keys. In simpler environments you can combine these into a single key.

Case Study

Example Corp. has 25 hypervisors (named hypervisor01.example.com -> hypervisor25.example.com) which they run Red Hat Enterprise Linux workloads on. The hypervisors are managed via a virtualization manager, such as VMWare vSphere or Red Hat Virtualization.

Environment Setup and Assumptions

It is assumed that the environment has been setup in the following manner:

Subscriptions and Content

The following subscriptions have been purchased and imported via the subscription manifest:

$rct cat-manifest --no-content /tmp/manifest.zip.

Subscription:
        Name: Red Hat Enterprise Linux for Virtual Datacenters, Premium
        Quantity: 25
        Created: 2016-07-06T00:42:33.000+0000
        Start Date: 2016-05-28T04:00:00.000+0000
        End Date: 2017-05-28T03:59:59.000+0000
        Service Level: Premium
        Service Type: L1-L3
        Architectures:
        SKU: RH00001
        Contract: [REDACTED]
        Order: [REDACTED]
        Account: [REDACTED]
        Virt Limit: unlimited
        Requires Virt-who: True
        Entitlement File: export/entitlements/8a99f98255bc1d4b0155bda8063f4d16.json
        Certificate File: export/entitlement_certificates/5039938100641083556.pem
        Certificate Version: 3.2
        Provided Products:
        Derived Products:
                69: Red Hat Enterprise Linux Server
                70: Red Hat Enterprise Linux Server - Extended Update Support
                84: Red Hat Enterprise Linux High Availability (for RHEL Server) - Extended Update Support
                86: Red Hat Enterprise Linux Load Balancer (for RHEL Server) - Extended Update Support
                91: Red Hat Enterprise Linux Resilient Storage (for RHEL Server) - Extended Update Support
                93: Red Hat Enterprise Linux Scalable File System (for RHEL Server) - Extended Update Support
                127: Red Hat S-JIS Support (for RHEL Server) - Extended Update Support
                133: Red Hat Enterprise Linux High Performance Networking (for RHEL Server) - Extended Update Support
                176: Red Hat Developer Toolset (for RHEL Server)
                180: Red Hat Beta
                182: Red Hat EUCJP Support (for RHEL Server) - Extended Update Support
                201: Red Hat Software Collections (for RHEL Server)

It is assumed that the following repositories have been synchronized at this point:

• Red Hat Enterprise Linux Server (Kickstart): This allows Satellite to kickstart a host.
• Red Hat Enterprise Linux Server (RPMs): This provides ongoing content and errata.
• Red Hat Enterprise Linux Server - Satellite Tools (RPMs): This provides supporting software, such as Puppet and katello-agent.
• Red Hat Enterprise Linux Server - Optional (RPMs): This provides optional software, not included in the main distribution.
• Extra Packages for Enterprise Linux - 3rd party (non-Red Hat) software, useful for Red Hat Enterprise Linux users.

It is assumed that Example Corp. has created a content view named RHEL7_w_EPEL which contains the aforementioned repositories and it has been published in the Library environment.

Hypervisor setup

It is assumed that the hosts hypervisor{1..25}.example.com have been reported via virt-who and have 1 virtual Datacenter subscription attached. In the event this hasn't been done yet, this can be done via the UI or via hammer.

List the subscriptions.

# hammer subscription list --organization Example
[
  {
    "ID": 18,
    "UUID": "2c91809352db8ab10152db9c9c770d57",
    "Name": "Extra Packages for Enterprise Linux",
    "Contract": null,
    "Account": null,
    "Support": null,
    "Quantity": "Unlimited",
    "Consumed": 0,
    "End Date": "2046-02-05T17:10:15.000+0000",
    "Attached": 0
  },
  {
  "ID": 196,
  "UUID": "2c918093561eaa39015630f5d0561dcb",
  "Name": "Red Hat Enterprise Linux for Virtual Datacenters, Premium",
  "Contract": [REDACTED],
  "Account": [REDACTED],
  "Support": "Premium",
  "Quantity": 25,
  "Consumed": 0,
  "End Date": "2017-05-28T03:59:59.000+0000",
  "Attached": 0
  },

And attached to the hypervisor via the following.

# hammer host subscription attach \
  --host hypervisor1.example.com \
  --subscription-id 196

The process should be repeated for any hypervisor which does not have a subscription attached.

Activation Key Setup

As stated above, we'd want to satisfy the following requirements when creating an activation key:

• attach a valid subscription.
• configure a host with the proper lifecycle environment and content View
• [Optional] attach subscriptions for custom (non Red Hat) content.

Let's focus on attaching a valid subscription. As we've previously attached subscriptions to our hypervisors, we want our activation key to 'use the subscription of the hypervisor'. This is Use Case 2 from above.

Let's create that key via hammer:

[root@satellite:] ~ #ORG=Example

[root@satellite:] ~ #hammer activation-key create \
  --organization "$ORG" \
  --name 'ak-auto-key'
Activation key created

By default, activation keys have auto-attach = True, so all that is needed is to create the key (and again with NO subscriptions attached to it).

Next, we need to create an activation key to connect the host to content:

# hammer activation-key create \
  --organization "$ORG" \
  --content-view RHEL7_w_EPEL \
  --lifecycle-environment Library \
  --name ak-RHEL7_w_EPEL

Additionally, we can set other parameters related to content on this key, such as the release version. It makes sense to set release version, product content and SLA on this key as those parameters are intrinsically tied to the content view.

And create an activation key for EPEL. Custom products do not necessarily need to be placed on their own key. However, as stated above, using the UNIX model of doing 'one thing well' makes the keys easier to understand.

You may ask: "Why do I need a subscription to access non-Red Hat content?":

It allows you to accurately count which hosts are using your custom content using the same tools and workflow that you used for Red Hat subscriptions.

While the number of subscriptions is uncapped/unlimited, it is important that any host that wishes to use your custom product MUST also have your custom subscription attached.

# hammer activation-key create --organization "$ORG" --name ak-EPEL
# hammer activation-key add-subscription \
  --organization "$ORG" \
  --name "ak-EPEL" \
  --subscription-id 18

With our keys created, we can register a host. On a client (which was installed from CD on one of the hypervisors in the cluster):

Firstly, install the katello-ca-consumer-latest RPM which configures the client for Satellite 6:

[root@client ~]# yum -y install http://satellite.example.com/pub/katello-ca-consumer-latest.noarch.rpm

We'll present our activation keys in comma separated form.

[root@client ~]# subscription-manager register --org Example \
 --activationkey=ak-auto-key,ak-RHEL7_w_EPEL,ak-EPEL
The system has been registered with ID: 3df5b055-18bb-42ea-b015-4d7fb19c409f

Installed Product Current Status:
Product Name: Red Hat Enterprise Linux Server
Status:       Subscribed

And now let's look at the attached subscriptions to see if we received the desired subscriptions.

[root@client ~]# subscription-manager list --consumed
Subscription Name:   Red Hat Enterprise Linux for Virtual Datacenters, Premium (DERIVED SKU)
Provides:            Red Hat EUCJP Support (for RHEL Server) - Extended Update Support
                     Red Hat S-JIS Support (for RHEL Server) - Extended Update Support
                     Oracle Java (for RHEL Server)
                     Red Hat Enterprise Linux Resilient Storage (for RHEL Server) - Extended Update Support
                     Red Hat Enterprise Linux High Availability (for RHEL Server) - Extended Update Support
                     Red Hat Enterprise Linux Atomic Host
                     Red Hat Beta
                     Red Hat Enterprise Linux Load Balancer (for RHEL Server) - Extended Update Support
                     Red Hat Enterprise Linux Scalable File System (for RHEL Server) - Extended Update Support
                     dotNET on RHEL (for RHEL Server)
                     Red Hat Developer Toolset (for RHEL Server)
                     Red Hat Enterprise Linux Atomic Host Beta
                     Red Hat Software Collections Beta (for RHEL Server)
                     Red Hat Software Collections (for RHEL Server)
                     Red Hat Enterprise Linux High Performance Networking (for RHEL Server) - Extended Update Support
                     Red Hat Enterprise Linux Server
                     Red Hat Enterprise Linux Server - Extended Update Support
                     Oracle Java (for RHEL Workstation)
SKU:                 RH00049
Contract:            10998398
Pool ID:             2c918093561eaa39015630f5d0561dcb
Provides Management: No
Available:           Unlimited
Suggested:           1
Service Level:       Premium
Service Type:        L1-L3
Status Details:      Guest has not been reported on any host and is using a temporary unmapped guest subscription.
Subscription Type:   Standard (Temporary)
Ends:                01/18/2017
System Type:         Virtual


Subscription Name:   Extra Packages for Enterprise Linux
Provides:            Extra Packages for Enterprise Linux
SKU:                 1455383415560
Contract:            
Account:             
Serial:              4283435491484917608
Pool ID:             2c91809352db8ab10152db9c9c770d57
Provides Management: No
Active:              True
Quantity Used:       1
Service Level:       
Service Type:        
Status Details:      Subscription is current
Subscription Type:   Standard
Starts:              02/13/2016
Ends:                02/05/2046
System Type:         Physical

The Status Details: Guest has not been reported on any host and is using a temporary unmapped guest subscription from above tells us that this guest hasn't been reported yet via virt-who. Assuming that virt-who is running, within 24 hours the temporary subscription will expire and the guest will use its hypervisor's subscription. Next, confirm the host has access to the correct Lifecycle environment and Content. This can be done one of two ways:

Via subscription-manager

[root@client ~]# subscription-manager identity
system identity: 3df5b055-18bb-42ea-b015-4d7fb19c409f
name: client.example.com
org name: Example
org ID: Example
environment name: Library/RHEL7_w_EPEL

Via yum

[root@client ~]# yum repolist -v
Setting up Package Sacks
pkgsack time: 0.006
Repo-id      : Example_Extra_Packages_for_Enterprise_Linux_EPEL_7_-_x86_64
Repo-name    : EPEL 7 - x86_64
Repo-revision: 1484616271
Repo-updated : Mon Jan 16 20:24:31 2017
Repo-pkgs    : 20,083
Repo-size    : 21 G
Repo-baseurl : https://satellite.example.com/pulp/repos/Example/Library/RHEL7_w_EPEL/custom/Extra_Packages_for_Enterprise_Linux/EPEL_7_-_x86_64/
Repo-expire  : 1 second(s) (last: Tue Jan 17 13:05:56 2017)
  Filter     : read-only:present
Repo-filename: /etc/yum.repos.d/redhat.repo

Repo-id      : rhel-7-server-rpms/7Server/x86_64
Repo-name    : Red Hat Enterprise Linux 7 Server (RPMs)
Repo-revision: 1484616124
Repo-updated : Mon Jan 16 20:22:04 2017
Repo-pkgs    : 13,604
Repo-size    : 17 G
Repo-baseurl : https://satellite.example.com/pulp/repos/Example/Library/RHEL7_w_EPEL/content/dist/rhel/server/7/7Server/x86_64/os/
Repo-expire  : 1 second(s) (last: Tue Jan 17 13:05:56 2017)
  Filter     : read-only:present
Repo-filename: /etc/yum.repos.d/redhat.repo

repolist: 33,687

Conclusion

Activation keys are powerful tools that allow you to customize subscription behavior. Hopefully this blog post has helped you understand their behavior.

Further reading

• Subscription-manager for the former Red Hat Network User: Part 1
• Subscription-manager for the former Red Hat Network User: Part 2 - Subscription-manager learns grep
• Subscription-manager for the former Red Hat Network User: Part 3 - Understanding virt-who
• Subscription-manager for the former Red Hat Network User: Part 4 - Understanding Subscription Manifests
• Subscription-manager for the former Red Hat Network User: Part 5 - working with subscriptions that require virt-who
• Subscription-manager for the former Red Hat Network User: Part 6 - understanding and improving the renewal experience
• Subscription-manager for the former Red Hat Network User: Part 7 - understanding the Red Hat Content Delivery Network
• Subscription-manager for the former Red Hat Network User: Part 8 - Product Certificates
• Activation Key Enhancements with Red Hat Satellite 6.1
• Red Hat Satellite Virtual Instances Guide