Redhat.repo

Support
1

Problem: All RPM repo availables in foreman are seen on fresh build host

**Expected outcome:**only repo used during install or selected with activation key

**Foreman and Proxy versions:**3.7.0

Foreman and Proxy plugin versions:

**Distribution and version:**RedHat 8

Other relevant data:

If I use the defaultview with an activation key, the repos in redhat.repo at the end of installation includes all existing RPM repos in foreman (wich means almalinux, and all other rpm distributions synced in foreman).
If I use a Content View the redhat.repo is correct. But we don’t want to use content view. All our hosts needs to be up to date automatically, with dnf-automatic. We don’t want to have to manage Content View versions to manages the updates.
Is there a simple way to do this, or should I do a --remove-all and then add my own .repo ?
Regards,
JF

2

Hi @Jean-Francois,

Since Default Organization View includes all repos, it is expected that all repos are visible in your case. And content views is our recommendation to manage your content.

With that being said, If you really don’t want to use content views, you can use the activation key Repository Sets tab to override/disable, for whatever repos you don’t want the host to see.

Info about Restricting Hosts’ Access to Content.

1 Like
3

I tryed this, but the unwanted repo are still present in the redhat.repo file. They are just disabled.

4

And it’s not possible to have an auto-updated Content View ?
It seems auto-update is not really compatible with foreman.

5

You can easily create a cronjob (or systemd timer) that runs the hammer content-view command, to achieve scheduled content view publishes (/promotes) :slightly_smiling_face:

1 Like
6

What is the harm if a repo is in your redhat.repo file and disabled?

7

I don’t want Almalinux repo in the redhat.repo file. Even if it is disabled.

8

The way to not have something in your redhat.repo file is not to have it in your host’s content view. If it’s available to your host through Katello (even if disabled via an override), it will end up in redhat.repo.

1 Like
9

Yes, your right, but the Content View locks the packages versions, and I don’t want that.
I want all hosts to be up to date everyday, automatically.

10

Asking again, why?

11

Because the distribution installed this way is RedHat, not Alma.

12

This was also kind of part of the whole switch from by default enabled to by default disabled (for custom products) discussion (if you have the time, it’s a long one):

Before the switch you could make sure the host only sees what it needs / should see by adding subscriptions, since the switch you have to use content-views for the same result.
So to have the least trouble, I don’t know how often your sync-plan(s) run, but if it’s daily, create several CVs and then a (or many) cronjob which run when you expect the syncs to have finished.
In my case that resulted in 7 sync-plans for 228 repos, with 8 CVs and 4 cronjobs per CV (publish, promote-1, promote-2, cleanup of old versions)

Looks like this for example:

0  3 * * *   root  hammer content-view publish --organization ORG --name "EL8" --async 2>&1 | /usr/bin/logger -t cron-katello-cv-publish-el8
0  5 * * *   root  hammer content-view version promote --organization ORG --content-view "EL8" --from-lifecycle-environment Library --to-lifecycle-environment DEV --async 2>&1 | /usr/bin/logger -t cron-katello-cv-promote-el8
0  7 * * *   root  hammer content-view version promote --organization ORG --content-view "EL8" --from-lifecycle-environment DEV --to-lifecycle-environment PROD --async 2>&1 | /usr/bin/logger -t cron-katello-cv-promote-el8
0  10 * * *  root  if [ $(hammer --no-headers --csv content-view version list --organization ORG --content-view "EL8" | wc -l) -ge 10 ]; then for i in $(hammer --no-headers --csv content-view version list --organization ORG --content-view "EL8" | awk -F, {'print $1'} | tail -n3); do hammer content-view version delete --organization ORG --id ${i} --async; done; fi 2>&1 | /usr/bin/logger -t cron-katello-cv-cleanup-el8

Tbh with this solution it currently runs pretty smoothly.

There was also a beginning to look into extending the “Restrict to architecture/OS version” (currently only for RHEL), which could also help in this case, but this hasn’t had that much progress up to now (somewhere at the end of the mentioned thread)

1 Like