I have a host that was connected to foreman via an activation key. That key does have Auto Attach enabled. The host is running Centos7. The content in that activation key and the content view assigned to that host has both Centos 7 repos and Rocky8 repos.
On the host I ran yum check-update. I saw both Rocky8 repos and Centos 7 repos coming back and rpms for both OS on this one host.
I was under the impression that Auto Attach on the Activation Key does some magic to determine the host os and only attach the correct repos to it?
Just to make sure it was not a case of updating Foreman after attaching the host I just removed the host from foreman and cleaned up subscription manager. Then re-added the host using the same activation key. After that I re-ran yum check-update.
SAME RESULT…
Does your org have simple content access turned on?
If so then you won’t see a subscriptions tab on the activation key, and custom products will all be enabled by default. You’ll have to modify your activation key to override the (un-)desired repositories to disabled, or turn off SCA.
Yes, I do have simple content access enabled. Under Activation Key I do see repositories under the Repository Sets tab.
So what you are saying is with SCA enabled I have to modify my activation keys to only provide the repos I want to provide based on the host os. Meaning SCA negates the Auto Attach feature???
And yes it basically says that SCA invalidates Auto Attach. The fix is to set the Restrict to OS feature on the repo it self.
I set that to rhel-8 on the Rocky8 repos. I will have to test and see how that shows up now on a Rocky8 host but on a Centos7 host I am back to only seeing Centos7 rpms.
Auto Attach only works with RedHat products. No other repositories are supported. If you have subscription management you would have to add/remove subscriptions. With SCA enabled (i.e. without subscription management) it’s like you have all possible subscriptions added.
Either way, you’ll always see this:
# subscription-manager list
No installed products to list
With SCA I would recommend to split up the content views for each OS, i.e. a CV for Rocky8, one for CentOS 7, etc. With SCA clients have access to all repositories in the assigned CV. There is no additional layer with the subscription management anymore. This means, any client can enable any repository in the content view, whether it fits or not.
A EL8 client could enable a EL7 repository if it’s in the content view.
A Rocky client could enable a AlmaLinux or CentOS Stream 8 repository if it’s in the content view.
So unless you are absolutely sure none of your users will mix this up, I would rather make sure by using separate content views for each OS/major.
And another thing to remember with SCA: whenever you add a new repository to a product and put it into a content view, you must make sure to disable this repository on all clients using this content view. Otherwise, the new repository will be enabled by default…
What you are all saying is that with SCA enabled I increase the number of activation keys and content views I have. Or I dump SCA and go back to the old way where Auto Attach takes care of things correctly?
Is there a plan to make SCA the only solution and do away with Auto Attach?
Unless I was seeing things, AutoAttach was working for our Centos 6 and 7 hosts on a much older version.
Regardless, this is a new build and if SCA is going to be the future I might as well build for that. Though I must say if you have multiple versions of Linux in your environment it kinda makes a mess of the content views and activation keys.
You have probably used subscription management and made sure that either host received the correct subscriptions.
The problem with autoattach is that it only works if you have standardized repositories and that’s only true for RedHat repositories. With anything, else you are completely free to create products and assign repositories as you want which makes it difficult to decide which subscription to assign. Noone has to create a separate product for each os/major. You could have a centos product containing all version of centos. Or a el8 product containing all os repositories for various el8 derivates…
