Sat6 Activation Keys - One or one per RHEL version?
Hey all. I am trying to figure out if I need an activation key per RHEL version, for example one key for RHEL 5, one for RHEL6, etc.
Currently I have on key and have all three RHEL versions product content enabled. This is a replication of how we have our activation key set in Satellite 5.
However, when I view a host's product content I see that it shows it gets content for each RHEL version.
For example, a host that I have registered is RHEL 6, but the product content tab shows
RHEL 5 Server
RHEL 6 Server
RHEL 7 Server
And all the other child channels that I selected to Yes.
Is this causing any issue and should I have an activation key per RHEL version?
Responses
I think its a matter of housekeeping. In my orgs case, I maintain a lot of Activation keys. Typically our activation keys are in the format: act-rhel7-server-app-lifecycle-location-arch
This allows me to use a corresponding Host Group such as rhel7-server-arch/application/lifecycle to assign it accordingly.
ymmv, but I like order in my chaos. I found that when I used your method there was just too much stuff flying around, and room for uncertainty.
As Will mentioned there is a LOT of TIMTOWTDI (there is more than one way to do it) with Activation Keys. As long as you ensure that the proper subscriptions are attached and your systems get wired up to the correct content, that is all that matters.
I am a fan of having my keys do one thing well, so I use 2-3 keys per host.
- A key to attach subs. (Because you might want to use different keys to attach subs to physical systems versus virtual)
- A key to connect the systems to content (setup content view, lifecycle env, release version, etc)
- A key to attach your custom (non-Red Hat) subscriptions.
Then provide them all during registration : subscription-manager register --org Example --activationkey subs_key,content_key,custom_key
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
