How to use multiple activation keys with Satellite 6.

Solution Verified - Updated -


  • Red Hat Enterprise Linux
  • Red Hat Satellite 6.x


  • System registered with multiple activation keys only uses content view and life cycle environment of last activation key only.
  • Is it possible to attach multiple content views to content host ?
  • Use of Multiple activation key to register a system fails to attach multiple content views to content host.


  • It is not possible to attach multiple content views and life cycle environment to a content host when more that one activation key is used to register a content host.
  • Hence when multiple activation keys are used to register a system to Satellite 6, content view and life cycle environment of last activation key is attached to content host.
  • Which means that contents from content view attached to last activation key which is promoted in same life cycle environment will be available for content host.
  • For an example, There are three content views CV1, CV2 and CV3 promoted to life cycle environment env1,env2 and env3 respectively. CV1 and env1 is attached to activation key AK1, CV2 and env2 is attached to activation key AK2 while CV3 and env3 is attached to activation key AK3. Conisder following command is used to register a content host :
# subscription-manager register --org orgname  --activationkey AK1,AK2,AK3
  • Now content host registered to Satellite 6 can have access to contents from CV3 which is promoted to env3.
  • So if there is an requirement that a content host needs contents from multiple content views then composite view can be used in such scenario.
  • There are some limitation while using composite view which are as follows :
    • Content views assigned to composite view must be promoted in same life cycle environment.
    • Composite view must also be promoted in same life cycle environment
    • Same life cycle environment must be assigned to activation key.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.


Explains my problem perfectly - thanks.

However, as a feature/feedback - this means that for more than a few combination views, it quickly becomes a scalability problem to handle patch management. As multiple views have to be updated & promoted.

Much better than have AK1 pickup CV1 and AK2 for CV2, therefore a seperate machine with AK1 & AK3 could pickup promotions to CV1 at the same time/window without having to double the labour overhead. Not so bad for only a couple of cases, but problematic when I have many cases to build.

The alternative is to make all pools available to all machines, however in a highly controlled environment with many actors this is undesirable.

So CVs aside, if there are different subscriptions attached to each of the AKs, are all 3 subs assigned to the client or just the last one? (or some other combination?)

The "subs" in my case, are actually products repositories which blurs it a little. But for analogy purposes you could say yes.

Machine1 : Sub for OS + Sub for App 1 Machine2: Sub for OS + Sub for App 2

However I am given the requirement that Machine1 should have repositories for OS & App1 (but nothing else),Machine2 should have OS + App2 (but nothing else).

Ideally - AK1 = OS, AK2=App1, AK3=App2.

Therefore Machine1 has AK1+AK2, Machine2 as AK1+AK3 etc.

In this manner an OS patch cycle is promoted to the CV against AK1 and it's covered across the estate.

However in reality, I need to provision AK1 = OS+App1, AK2 = OS+App2,

Therefore for each OS patching cycle, I need to promote and update multiple CV's for each AK.

The easy answer of allowing AK1 = OS + App1 + App2 breaks the requirement I've been given :(

The client receives the union of all subscriptions on the activation keys presented at registration time. Subscriptions don't 'conflict' per se (so the 'rightmost wins' logic doesn't apply), making it important when using multiple activation keys to not attach too many subscriptions.

Generally, you want to follow the 'UNIX way' and have 1 AK per 'purpose' and then combine as needed for desired effect. Note: It is not required to attach a subscription to each activation key. More content on activation keys is covered in Activation Key Enhancements with Red Hat Satellite 6.1

That's what I would have expected, and would suit me down to the ground.

However I didn't seem to get much joy when trying this. Pools associated with the latter keys would be attached, but would never show up in yum. Searching around on the problem led me to this page.

The above document, appears to imply that only 1 key/cv can be used? From your comment, should I take it that the above is incorrect?

A system can use exactly 1 content view. Thus if you are using multiple activation keys, the rightmost CV wins.

If you want to use content from 2 (or more) content views, you have the option of using a composite content view, which allows you to combine 2 (or more) content views into one unit.


I have a content view named RHEL6_Core_Build, and a content view named 3rd_Party_App. I want to build a system that includes both.

To solve this, I'd create a composite content view named RHEL6_w_App, add the RHEL6_Core_Build and 3rd_Party_App views & publish and promote the RHEL6_w_App view to the lifecycle environments that need it.

Lastly, I'll create an activation key with RHEL6_w_App listed as the Content View. Hope this clarifies it for you.

This is what I've currently done for Postgres. I created a RHEL 6 Core CV, then created a Postgresql93-rhel6 cv and then composite view rhel6_w_app(ppostgres) of those two CVs. and same for RHEL7.

Could I just have created one Postgres CV and added RHEL6 and RHEL7 in a composite CV? Then when I create my AV_w_App, i just choose to install which version?

I'm using Postgres Repos for Postgres Product. But should I use Puppet Module and install that way? Which is preferred?

Hi Rich, sorry to vent on this design decision and I realize I'm late to this party on this thread. Iwas hoping this'd have changed now and was reevaluating our layouts. The fundamental issue with the single CV per guest is the unnecessary management, complexity and overhead it creates. Oh, and that pulp is slow as hell. In a multi-capsule, several product, several architecture, stable state OS, full development plus 3rd party stuff corporate environment, this is a horrible design limitation in practice.

We're still on 6.3.5 because going to 6.4 requires a puppet upgrade and we just don't have the resources for that right now. We end up with one "frozen" CV of the OS repos promoted on a certain date to cover monthly patching, then we have an EPEL CV for it, a "UNIX" repo that holds code from our team/custom packages and then many other CVs for third party products. These all have to be rolled into one enormous and unwieldy composite content view.

We then have to multiply that by RHEL 5,6,7,8(coming), CentOS(7 and 8) and x86_64, i686, s390x and ppc64. Our primary RHEL7 x86_64 CV now has 71,364 packages in it. If we need to do a small tweak to a single package it takes hours to publish / promote that one tweak to library, dev, qa and prod on 7 capsules. publishing anything of note requires tons of time and the knowledge / memory of "oh, yeah, this one hadoop CV is in 10 other composite CVs and they all need to be published too now".

Sorry, at this point I'm venting at what is, to me, the worst design issue still facing Satellite. The composite content views are a horrible solution in practice especially in a large, diverse environment.

Allowing guests to access more than one (I've been asking for since 6.1) would dramatically alleviate the complexity and management of the repos. Currently, there seems to be absolutely no point to multiple activation key support because they typically are used to make software available to the guest, If I put in 3 activation keys, all in the same lifecycle environment, I certainly expect to see the repos they all represent. As things stand, I end up attached to 3 pools but only see content from one, makes no sense at all. Sure, if I have a licensed layered product multiple content views could assign the license but the software still has to be part of the right-most CV???