Help with fastest way to update redhat.repo upon Content view promotion

Support
1

Problem:
One issue that keeps plaguing me with foreman is when I need to upgrade some packages.
For example I sync a repo. I see all the packages including the newly synced ones.
I promote the content view for the newly synced packages. I see the number of packages updated in that content view for the repo and it matches, and the intended update is there.
I go to server and try to update, show no updates
I’ve read that when you sync/update a “custom view” repo, it switches to disabled in the activation key! So I re-enable (override to enabled) there. I think I found somewhere this started after version 3.7?
Go to server, no updates. Run subscription-manager refresh no updates. Run yum clean all and subscription manager refresh still nothing. What I see is the redhat.repo file doesn’t update to match the activation key of enabled repos, until some time later?
Is there a way to force this update? What always works because I am impatient because this needs to happen “now”, is to force resubscribing the systems, but that seems not right.

I’m obviously doing something wrong because this seems like the way it should work.
Advice appreciated!

Expected outcome:
Update repo
Promote
Server sees new packages immediately.

Foreman and Proxy versions:
3.8/3.8 and 3.13/3.13

Distribution and version:
Rocky 9

2

Hi @kevins7189

Running subscription-manager repos should do the trick. If not, you can also try dnf uploadprofile --force.

From the web UI, you can also “Refresh applicability” from a host’s details page and it will run a REX job that does the same.

Another thing to keep in mind is that activation keys only affect hosts at time of registration. So changing something about an activation key after a host is already registered will not do anything. This is by design.

If you need to change something about hosts after they are registered, you can do so in the Foreman web UI, either from the host’s details page or thru bulk actions on the host list pages. (Or you can re-register with the activation key as many do, but I don’t recommend that because it’s not how it’s designed.)

Not quite. It doesn’t “switch” to disabled. Rather, what happens is that when you add a new custom product or repository, it’s disabled by default. You must add an override to enable it, either on the activation key or (after host registration) on the host itself. You can do this via Repository Sets in the web UI.

3

Thank you for the reply, unfortunately, running subscription-manager repos does not update the redhat.repo file on the host, which I presumed is the list of enabled/disabled repos matching the activation key, so then doesn’t apply the enabled overrides from the activation key.
But you are saying that the activation key only applies at subscription time, so that implies the only way to update it, add to it, or remove from it, is to re-subscribe.
I thought the activation key was tied to changes in the content view/lifecyle promotion. At least it used to be?

4

If the host is properly registered to Foreman, (and there are changes to the repos), it should.
If you do subscription-manager config, can you please share the output values for the following?

  • manage_repos
  • package_profile_on_trans
  • prefix
  • server.hostname - should be the url of your Foreman server

The redhat.repo file is managed by subscription-manager, but again, the activation key only comes into play at registration time. Activation keys describe hosts only at registration. Any time after that, do not rely on a host to match the attributes of an activation key.

You can change a host any time you want. Or are you referring to changing activation keys? If you change an activation key, it will not affect any existing hosts. It will only affect hosts registered with that activation key thereafter. This is why it works to re-register hosts, but it shouldn’t be necessary because, like I mentioned, you can change a host any time you want without reregistering.

The activation key has never been kept in sync with any changes, of anything else, and should not be expected to.

5

Appreciate the reply!
So to be clear if I wanted to update a set of hosts, or all hosts, or one host, to add a new repo/product, or enable/disable an existing, those changes have to be made to the activation key, and hosts resubscribed. Is that correct?
Even though all those same changes are made to the content view that the hosts are subscribed to, and promoted, those changes won’t be seen by the host(s).
I go into the activation key for that content view, and have to manually enable/disable changes there. Then like I have seen the host has to resubscribe to get the redhat.repo enabled field to become synced with foreman.

I guess I thought that when hosts subscribe to a Content View, then changes to the Content View via lifecycle promotion, would reflect on the host when it refreshes via subscription manager or rhsmcertd.

6

That’s one way to do it, but since activation keys aren’t really designed to update existing hosts, I would instead do something like the following.

  1. Publish/promote the new content to the host’s content view, like you normally do
  2. In Hosts > Content hosts, search for something like “content_view = <my_content_view>” and select all items. You can also search in many other ways: see GitHub - wvanbergen/scoped_search: Easily search you ActiveRecord models with a simple query language that converts to SQL.
  3. Select action > Manage repository sets – Override the new repository to Enabled. This will take care of all your existing hosts.
  4. For the future, edit the activation key repository sets to also override the new repo to Enabled. This will take care of future hosts registered with that activation key.

This is true, but the repository still must be enabled (e.g. show “enabled = 1” in subscription-manager repos or redhat.repo). Thereafter, your hosts will see immediate changes when the repository is updated in the content view.

7

If you need an update quicker than 4 hours, I would do the suggestions Jeremy pointed out. You could also adjust the rhsmcertd settings in /etc/rhsm/rhsm.conf and restart rhsmcertd but if you set it too low on your hosts, you can either cause performance issues on the Foreman server or ddos it depending on how many hosts you have.

8

Fantastic!, the steps you listed work perfectly. I totally forgot about the content hosts part.
I will look at rhsmcertd but doing subscription-manager refresh is sufficient for now.
Thanks again!

1 Like