Added repo to CV, client not receiving it

Foreman 2.3.1 with Katello, only using CentOS clients for now.

I created a bunch of Products with CentOS repos, a content view, assigned them to the activation key and deployed the system perfectly.

I then wanted to add a couple of new repos. I created 3 repos, Zabbix, Wazuh and NeoFetch. I updated the CV and promoted it, I updated the activation key. I have auto-attach enabled, which, if I’m reading right, should automatically have the client join the custom created repos that don’t have subscriptions.

On the client, I ran yum clean && subscription-manager refresh
and the new repos do not show up.

The only way for me to have these new repos show up is to manually go to the host and add them. I hear forcing a presubscription would also work, but neither of these is how it’s supposed to go I assume. I did see a previous issue with subscriptions ending in 2050+ but this is not the case, they all expire in 2049.

What am I missing? Thanks for the help!

Hey @mdiorio ,

Thanks for raising this.

Could you check if you have the repo listed and enabled in this?

subscription-manager repos

Hi @sajha

No, to does not show up there. The repos will not refresh unless I go to the host, content, and manually add the repos to the host there.

That’s incorrect. You need to add subscriptions. Otherwise it won’t see the repositories. Changing the activation key won’t change active subscriptions/repository sets. Auto-attach won’t do anything on CentOS and won’t change it either.

Thus, if those repositories are part of a new subscription & product you’ll need to add a subscription to existing hosts to get access to those repositories.

@gvde Here’s what I did:

Create a new Product: Microsoft
Create new repos within the product:

  • Yum Repo, Microsoft CentOS 7
  • Yum Repo, Microsoft CentOS 8

Update the content view to include the new repository. Promote the content view to DevTestStage
Update the Activation Key for new systems to receive the repo.

The CentOS 7 box has no knowledge of Subscriptions here.

So the correct answer here is to manually go to the Host Collection, go to Subscription Management and add the subscription there to update existing clients?

You don’t distinguish properly between products/subscriptions and repositories.

A new product implicitly creates a new product subscription.

A new repositories belongs to a product and can only be used if the host has the matching subscription.

A content view contains a set of repositories. It’s just a view on this set of repositories. A host using that content view can only use those repositories in the view for which is has a subscription. All other repositories in the view for which the host does not have a subscription are not available.

A repository set contains all repositories available to a host by subscriptions. In the set you can enable or disable repositories which are part of the host’s subscriptions.

A activation key is used during activation/registration of a host. It assigns subscriptions and allows you to define a initial repository set, i.e. it allows you to enable/disable the repositories the host can use within those subscriptions.

The subscription manager’s subscription modules attach/list with default options only really work with RedHat subscription. For others, you can only see the subscription a host consumed or which are available:

# subscription-manager list --consumed
# subscription-manager list --available

You can then add subscriptions via attach using the pool id shown in the available list:

# subscription-manager attach --pool=...

Of course assigning subscriptions is much nice via foreman web gui.

Thus, to answer you question: yes, you have to assign the subscription to the hosts which need those repositories. Either directly to the host or via a host collection.

However, please note, that by default adding a subscriptions automatically enables all repositories in that product to the host. In other words: by default they are added as enabled to the repository set of the host(s).

This can be a problem in your case: your two repositories “Microsoft CentOS 7” and “Microsoft CentOS 8” will both be enabled on the hosts which may not be want you want. You either have to disable the repository in the repository set of the hosts or you use content views to make only the correct repositories available to hosts.

1 Like

I have all the repositories set to apply to the correct architecture and OS version, so that should take care of that.

Thank you - Coming from Spacewalk 5, so this has been a slight learning curve. It’s just similar enough to be deceiving.

1 Like

Something is still very wrong here.

This is in the content host view of the machine in question, showing everything is as expected there.

subscription-manager list --consumed shows all the correct repos as consumed including Katello, and EPEL. subscription-manager repos is missing Katello and EPEL. yum repolist also fails to list Katello and EPEL repos.

I can see the Katello and EPEL pem files being pulled down to the client in the rhsm logs. In messages, I can see the subscriptions being added.

I have no idea why these repos are not being added to yum.

If it is not showing in subscription-manager repos, then the repository is probably not in the content view/lifecycle environment of the content host.

Go to the content host page, tab “Repository Sets” (I guess that was your second screenshot). Check the box “Limit to Lifecycle Environment”. This will only show the repositories actually available to the host.

They ARE showing in List to Lifecycle Environment. That was my second screen shot and why this is baffling.

So I’ve narrowed it down. It only impacts repositories that I have OS restrictions on.

For example, EPEL.

I have one Product, EPEL. Within that product, I have two repositories. One for CentOS 7, one for CentOS 8. Each repo I have OS restrictions enabled to rhel7 and rhel8. Can I assume that the restriction does not apply to CentOS then?

That was it - looks like that is only for RHEL subscriptions unfortunately.