Activation keys are used with traditional and Salt clients to ensure that your clients have the correct software entitlements, are connecting to the appropriate channels, and are subscribed to the relevant groups. Each activation key is bound to an organization, which you can set when you create the key.
In Uyuni, an activation key is a group of configuration settings with a label. You can apply all configuration settings associated with an activation key by adding its label as a parameter to a bootstrap script. We recommend you use an activation key label in combination with a bootstrap script. When the bootstrap script is executed all configuration settings associated with the label are applied to the system the script is run on.
An activation key can specify:
System types or add-on entitlements
Packages to be installed
System group assignment
In the Uyuni Web UI, as an administrator, navigate to.
Click the Create Key button.
Activation Key Detailspage, in the
Descriptionfield, enter a name for the activation key.
Keyfield, enter the distribution and service pack associated with the key. For example,
SLES12-SP4for SUSE Linux Enterprise Server 12 SP4.
Base Channelsdrop-down box, select the appropriate base software channel, and allow the relevant child channels to populate. For more information, see reference:admin/setup-wizard.adoc#vle.webui.admin.wizard.products and administration:custom-channels.adoc.
Select the child channels you need (for example, the mandatory SUSE Manager tools and updates channels).
We recommend you leave the
Contact Methodset to
We recommend you leave the
Universal Defaultsetting unchecked.
Click Create Activation Key to create the activation key.
Configuration File Deploymentcheck box to enable configuration management for this key, and click Update Activation Key to save this change.
You can combine activation keys when executing the bootstrap script on your traditional clients. Combining keys allows for more control on what is installed on your systems and reduces duplication of keys for large or complex environments.
Combining activation keys works only on traditional clients. Salt clients do not support combined activation keys. If you use a combined key with a Salt client, only the first key is used.
You can specify multiple activation keys at the command prompt, or in a single autoinstallation profile.
At the command prompt on the Uyuni Server, use the
`rhnreg_ks command, and separate the key names with a comma.
To specify multiple keys in a Kickstart profile, navigate to and edit the profile you want to use.
Be careful when combining activation keys, as conflicts between some values could cause client registration to fail. Check that these values do not have conflicting information before you begin:
Software child channels
If conflicts are detected, they are handled like this:
Conflicts in base software channels: registration fails.
Conflicts in system types: registration fails.
Conflicts in the
enable configurationflag: configuration management is enabled.
If one key is system-specific: registration fails.
Reactivation keys can be used once only to re-register a client and regain all Uyuni settings. Reactivation keys are client-specific, and include the system ID, history, groups, and channels.
To create a reactivation key, navigate to
Systems, click the client to create a reactivation key for, and navigate to the tab.
Click Generate New Key to create the reactivation key.
Record the details of the key for later use.
Unlike typical activation keys, which are not associated with a specific system ID, keys created here do not show up on the page.
For Salt clients, after you have created a reactivation key, you can use it as the
management_key grain in
/etc/salt/minion.d/susemanager.conf. For example:
grains: susemanager: management_key: "re-1-daf44db90c0853edbb5db03f2b37986e"
salt-minion process to apply the reactivation key.
You can use a reactivation key with a bootstrap script. For more information about bootstrap scripts, see client-configuration:registration-bootstrap.adoc.
For traditional clients, after you have created a reactivation key, you can use it with the
rhnreg_ks command line utility.
This command re-registers the client and restore its Uyuni settings.
On traditional clients, you can combine reactivation keys with activation keys to aggregate the settings of multiple keys for a single system profile.
rhnreg_ks --server=<server-url>/XMLRPC \ --activationkey=<reactivation-key>,<activationkey> \ --force
If you autoinstall a client with its existing Uyuni profile, the profile uses the reactivation key to re-register the system and restore its settings. Do not regenerate, delete, or use this key while a profile-based autoinstallation is in progress. Doing so causes the autoinstallation to fail.
Avoid using the
SUSE Manager Default parent channel.
This setting forces Uyuni to choose a parent channel that best corresponds to the installed operating system, which can sometimes lead to unexpected behavior.
Instead, we recommend you create activation keys specific to each distribution and architecture.
If you are using bootstrap scripts, consider creating an activation key for each script. This helps you align channel assignments, package installation, system group memberships, and configuration channel assignments. You also need less manual interaction with your system after registration.
Using activation keys might result in automatic downloading of software at registration time, which might not be desirable in environments where bandwidth is constrained.
These options create bandwidth usage:
Assigning a SUSE Product Pool channel results in the automatic installation of the corresponding product descriptor package.
Any package in the
Packagessection is installed.
Any Salt state from the
Configurationsection might trigger downloads depending on its contents.
If you do not enter a human-readable name for your activation keys, the system automatically generates a number string, which can make it difficult to manage your keys.
Consider a naming scheme for your activation keys to help you keep track of them. Creating names which are associated with your organization’s infrastructure makes it easier for you when performing more complex operations.
When creating key labels, consider these tips:
OS naming (mandatory): Keys should always refer to the OS they provide settings for
Architecture naming (recommended): Unless your company is running on one architecture only, for example x86_64, then providing labels with an architecture type is a good idea.
Server type naming: What is this server being used for?
Location naming: Where is the server located? Room, building, or department?
Date naming: Maintenance windows, quarter, etc.
Custom naming: What naming scheme suits your organizations needs?
Example activation key label names:
When creating activation keys you also need to keep in mind which software channels are associated with it. Keys should have a specific base channel assigned to them. Using the default base channel is not recommended. For more information, see the client operating system you are installing at client-configuration:registration-overview.adoc.