No products installed. - missing redhat.repo file

No products installed after subscribing hosts

Expected outcome:
Populated redhat.repo file

Foreman and Proxy versions:
Installed Packages


Foreman and Proxy plugin versions:

Distribution and version:
CentOS 7.7

Other relevant data:


I have a lifecycle Library->tst->dev->prd

I’ve added synched yum repos for CentOS7.7 and EPEL7. I created content views for each and then I created a composite view called CentOS_Full which has been promoted to all lifecycles, I also did this for each of the members of the composite view.

I then created Activation keys for the tst and dev lifecycles that links to the composite view and the respective lifecycle environment. There are packages available in each content view/repository.

After installing subscription-manager and the katello-ca-consumer I successfully register the host using the activation key, but I get “No products installed.”

What am I missing?


I do not have that much experience with composite views, but I usually forget to add the subscriptions to the activation key under Content > Activation Keys, my-key > Subscriptions tab.

Thanks for the reply. I didn’t see it until now. I have them added to the Subscriptions tab and no luck. The registered system isn’t seeing the repos.


I am missing experience with CentOS depoyment via Katello, but from what I understand I would take the following guess what’s happening here:
The ‘No products installed’ message is fine for CentOS. This should only relate to RedHat Products (which subscription-manager is mainly built around) and you should be able to savely ignore that.
Due to this, though, auto-attach most likely will not work. You have to assign subscriptions and configure repository overrides with your activation keys to get the repositories.
If you want to make sure your CCV/CV setup is working in general, you can use sudo subscription-manager repos --list-disabled to see if any repos are available. If this returns the repos you are expection your contentview setup is working and you probably only need to adjust the activation keys.

Side note: If you only access your content/repos through CCVs, there is no need to promote individual CVs to the lifecycle environments. There is no harm in promoting them, but skipping that step if you do not access them directly can save quite some time when updating the repos :slight_smile:


Thanks for reply.

So here’s my output of a host that’s registered with an Activation Key and has subscriptions added with enabled products. Do I still have to overrride?

[root@fmch02 yum.repos.d]# subscription-manager repos --list-disabled
This system has no repositories available through subscriptions.

Here’s some additional info pulled with hammer:

hammer activation-key list --organization

2 CentOS7_Full_DEV 1 of Unlimited dev CentOS7_Full
3 CentOS7_Full_LIB 1 of Unlimited Library CentOS7_Full
1 CentOS7_Full_TST 1 of Unlimited tst CentOS7_Full
------------------ ---------------- ----------------------- -------------

hammer content-view list --organization

6 CentOS6 CentOS6 false
8 CentOS6_Full CentOS6_Full true
3 CentOS7 CentOS7 false 2020/02/20 18:19:17 4, 1, 3, 2
7 CentOS7_Full CentOS7_Full true 2020/02/20 18:21:26 11, 12, 13, 14, 19
2 Default Organization View 4b66f64b-7321-480f-b9a7-1402a3a4a074 false 2020/02/20 00:44:52
4 EPEL6 EPEL6 false
5 EPEL7 EPEL7 false 2020/02/20 18:19:30 10
---------------- --------------------------- -------------------------------------- ----------- --------------------- -------------------

[root@fman02]# hammer host info --id ‘10’
Id: 10
Organization: example
Location: ussd
Cert name:
Managed: no
Installed at:
Last report:
Uptime (seconds): 3232777
Global Status: Warning
IPv4 address: X.X.X.X
IPv6 address:
MAC: 00:50:56:b7:aa:97
Network interfaces:

  1. Id: 10
    Identifier: eth0
    Type: interface (primary, provision)
    MAC address: 00:50:56:b7:aa:97
    IPv4 address: X.X.X.X
    IPv6 address:
    Operating system:
    Architecture: x86_64
    Operating System: CentOS 7
    Build: no
    Custom partition table:

All parameters:

Additional info:
Owner: Admin User
Owner Id: 4
Owner Type: User
Enabled: yes
Model: VMware Virtual Platform
Content Information:
Content View:
ID: 7
Name: CentOS7_Full
Lifecycle Environment:
ID: 2
Name: Library
Content Source:
Kickstart Repository:
Applicable Packages: 0
Upgradable Packages: 0
Applicable Errata:
Enhancement: 0
Bug Fix: 0
Security: 0
Subscription Information:
UUID: cafd7786-eff7-4cfb-a844-6afe5698c378
Last Checkin: 2020-03-16 14:48:36 UTC
Release Version:
Autoheal: true
Registered To:
Registered At: 2020-03-12 22:24:56 UTC
Registered by Activation Keys:
1) CentOS7_Full_LIB
System Purpose:
Service Level:
Purpose Usage:
Purpose Role:
Purpose Addons:
Host Collections:

You most likely have to attach subscriptions to those activation keys. I know it’s conter-intuitive, but Katello generates “virtual” subscriptions for every non-RedHat product that emulates the behaviour of RedHat subscriptions.
You can find those via hammer subscription list --organization yourorg. You can then assign those to the activation key using hammer activation-key add-subscription --organization yourorg --name youractivationkey --subscription-id yourproductsid. If you want to fine-tune which repos are enabled on your hosts by default, you can use hammer activation-key content-override, but I don’t know how to use that hammer command. In the UI, this is under “Content” -> “Activation keys” -> Select One -> “Repository Sets”.


Should it look differently than it already is for subscriptions?

That indeed looks correct at first glance.
Could you provide hammer content-view info --name CentOS7_Full --organization yourorg?

Thanks for your help.

Here is the output:

ID: 7
Name: CentOS7_Full
Label: CentOS7_Full
Composite: true
Description: CentOS7_Full
Content Host Count: 3
Force Puppet: false
Solve Dependencies: false
Organization: example
Yum Repositories:

  1. ID: 11
    Name: CentOS7.7_Updates
    Label: CentOS7_7_Updates
  2. ID: 12
    Name: CentOS7.7_Plus
    Label: CentOS7_7_Plus
  3. ID: 13
    Name: CentOS7.7_Extras
    Label: CentOS7_7_Extras
  4. ID: 14
    Name: CentOS7.7_OS
    Label: CentOS7_7_OS
  5. ID: 19
    Name: EPEL7Server
    Label: EPEL7Server
    Container Image Repositories:

OSTree Repositories:

Puppet Modules:

Lifecycle Environments:

  1. ID: 5
    Name: prd
  2. ID: 4
    Name: dev
  3. ID: 3
    Name: tst
  4. ID: 2
    Name: Library
  5. ID: 5
    Version: 1.0
    Published: 2020/02/20 18:21:26
  6. ID: 3
    Name: CentOS7 1.0
  7. ID: 4
    Name: EPEL7 1.0
    Activation Keys:
  8. CentOS7_Full_DEV
  9. CentOS7_Full_LIB
  10. CentOS7_Full_TST

I was only able to get the repos when I added the subscriptions to the content host directly.

Content host -> Host -> Add subscription

For some reason the Activation Key isn’t working as I expect it to.

I’ll confirm this behavior. Build products, build download content views, build composite content views for my environments, build the life cycle environments, publish the composite content views, build activation keys (turning off auto-attach, manually selecting subscriptions, and disabling repositories that shouldn’t be available to a particular key.)

@imtheforeman, take a look at CentOS host cannot subscribe to repositories. Is there any possibility that you’ve fallen into that issue?

@jkalchik I don’t see any indication that I’ve fallen into that issue. I check the host log and everything is clean with no errors. The expiration dates are all 2049 for my products. It just doesn’t register any products until I add them directly to the host. The frustrating part is that I built everything with hammer commands for reproducibility and the first environment I built works fine. Activation keys provide subscriptions as expected. The only difference is that with the current env I added Host Groups and setup more of the pxe booting environment, but I don’t think that impacts the Activation Keys.

I use host groups as well (and moving up the tree for parameters,) and those all seem to work pretty well. I am going to have to get PXE booting working one of these days.

Ok so I feel like I’m gas lighting myself. The redhat.repo file appears but is empty.

That is “normal” behaviour. The redhat.repo file is autocreated by subscription-manager.
Have you tried disabling auto-attach for the activation-key?
hammer activation-key update --auto-attach no --name CentOS7_Full should do the trick. Then resubscribe the system with the updated key.
If that still does not work, please provide output for the following commands:

subscription-manager status
subscription-manager identity
subscription-manager list --available
subscription-manager list --consumed


Ok, so everything seems to be working as expected. I didn’t have to disable the auto attach and when I looked this morning all repos were in the redhat.repo file. Is it recommended to remove auto attach for the keys? What’s the best way to add a new reopo to a host when the activation key gets a new subscription? Re-register with --force?

That’s funny. Using the methodology I described above, /etc/yum.repos.d/redhat.repo is populated with descriptions of all repositories visible through a lifecycle environment (disabled as appropriate by overrides in activation keys.)

-rw-r--r--. 1 root root 8475 Mar 17 09:53 redhat.repo

That’s from a freshly installed content host.

As I mentioned I am missing experience with CentOS via Katello. For RHEL it is recommended to leave it on and if you don’t experience any further problems with it, you can leave it on I would suppose.

Sorry, I was probably unprecise here: What I meant is that the file is there, even if the system is not correctly subscribed and has no repos available. In that case, it is normal that it’s empty.

That is an option, but probably not the best one.
My recommendation would be to nuse subscription-manager attach --pool poolid.
You can get the poolid from one of your systems via subscription-manager list --available. As long as you are not using RedHat Virtual Datacenter/Per-Hypervisor Licences, the poolid should be the same for all systems. So for CentOS or third-party/custom repositories, that should be the case.


1 Like