Simplifying Activation Key Usage in Red Hat Satellite 6

The Problem

Activation Keys have the following functions in Red Hat Satellite 6:

  • Subscribing a client with a valid subscription
  • Allocating the freshly subscribed client to the correct lifecycle environment
  • Allocating the freshly subscribed client to the correct Content View
  • Enabling or disabling specific repositories
  • Allocating the client to a host collection

Note that although Content View and Lifecycle Environment are also specified in a Hostgroup definition, these are only used at deployment time. The repositories used after deployment has completed are the ones specified in the activaiton key.

This results not only in proliferation of activation keys, but also proliferation of hostgroups. Consider for example a simple Standard Operating Environment with:

  • 5 host profiles (base, webserver, app server etc)
  • 3 lifecycle environments (dev, test, prod)
  • 2 content views (for example, a base CV and a CCV used for a specific profile)

With this configuration we will need a minimum of 6 (3×2) activation keys. Additionally, each of our 5 host profiles can be deployed into any one of the lifecycle environments, so we will need 15 (5×3) hostgroups.

The obvious way of simplifying this is to leave the lifecycle environment blank in the hostgroup definition and fill it in at deployment time. This reduces the hostgroup count back to 5, so we have a logical mapping of host profiles to hostgroup.

This now introduced a second problem, which is that we can no longer specify an activation key per hostgroup, as we are only selecting lifecycle environment at deployment time.

The Solution

The solution is to not specify the activation key in the hostgroup at all, but instead determine it dynamically at deployment time based on the Content View and Lifecycle Environment specified in the host. We can do this as we have access to this information via Foreman parameters during the kickstart process.

Simply create Activation Keys using the naming convention:

ak_<lifecycle_environment_name>_<content_view_name>

Then use the following registration snippet in your kickstarts (replacing the standard subscription_manager snippet:

<%#
kind: snippet
name: subscription_manager_auto
oses:
- RedHat 4
- RedHat 5
- RedHat 6
- RedHat 7
%>


# add subscription manager
yum -t -y -e 0 install subscription-manager
rpm -ivh <%= subscription_manager_configuration_url(@host) %>

echo "Registering the System"
<% ak_key_name="ak_" + @host.info['parameters']['kt_env'].to_s + "_" + @host.info['parameters']['kt_cv'] %>

subscription-manager register --org="<%= @host.rhsm_organization_label %>" --name="<%= @host.name %>" --activationkey="<%= ak_key_name %>"
subscription-manager repos --enable=rhel-*-satellite-tools-*-rpms
echo "Installing Katello Agent"
yum -t -y -e 0 install katello-agent
chkconfig goferd on
Spread the love

One comment

  1. Another approach could be to set the “kt_activation_keys” parameter on an Organisation/Location/Domain/Subnet/Operating System/Host Group/Host in that order of inheritance.

    Though obviously, they are slightly different use-cases.

Leave a Reply to Sean Cancel reply

Your email address will not be published. Required fields are marked *