Unable to identify what controls the default “enabled vs. disabled” status of a repository as displayed within the “Repository Sets” section of an activation key. For example, within repositories contained in a given Red Hat Enterprise Linux for architecture product, the BaseOS and AppStream repositories have a default status of Enabled, whereas the Supplementary repository is Disabled. Where is this defined and how can it be changed?
Expected outcome:
I understand that this setting can be overridden within an activation key, but for our environment this is not a viable option. We are experimenting with the use of content views (which we have not used before) and our expectation is that by placing a repository within a content view, there ought to be a way to set the default enabled/disabled status of that repository without requiring manipulation of activation keys.
There are some metadata which are only provided by Red Hat Repositories which also only RHEL consumes, so these repositories are controlled by these as this mechanism ensures the are only used by the correct OS version. This is not available for other repositories (which Red Hat calls Custom) which are then default disabled to not be incorrectly assigned. So as you already mentioned activation keys are meant to handle the state for systems globally and to not handle it per system.
Default enablement of Red Hat products is defined in upstream metadata, and can be enabled or disabled depending on the repository. (In practice, only the BaseOS/AppStream repos are enabled by default and everything else is disabled.)
Default enablement of custom products is defined by Katello and is always disabled.
Default enablement cannot be changed by the user.
If you want to control access to your content, there are several ways to do so.
If you’re adding a new repository and want something other than its default enablement, then yes, you must add a content override to your hosts and activation keys. This is supported and encouraged.
If you don’t want hosts to have access to content, don’t put it in your content view. If it needs to be in the content view, and its default enablement is Enabled, add a content override to your hosts and activation keys to disable it.
If you’re using RHEL with custom repositories, you can use the “Restrict to OS Version” or “Restrict to Architecture” features.
Please note that when adding content overrides to activation keys, changes will not affect existing hosts that are already registered. However, do NOT reregister your hosts. It is entirely possible, and in fact easy, to add content overrides to existing hosts by using the web UI (Hosts > Content Hosts > Select Action > Repository sets.)
Okay, I think I understand now, but for our environment it doesn’t work the way we’d like. We don’t allow user accounts on our Satellite, and access to the Satellite is controlled by a front-end system that handles user authentication. That system manages activation keys on the user’s behalf via the Satellite REST API. Activation key names are hashed and (theoretically) only discoverable by the user authenticating to the front-end system, and those names are used during registration as the only (loose) form of Satellite authentication available (short of enabling user accounts on the Satellite) to ensure that users can’t register with someone else’s key.
Given this design, where we have thousands of users, each with at least one activation key, we don’t wish to perform any post-create management of activation keys to control access to content (nor do we manage content for individual hosts on the user’s behalf). This is why we would hope that the content view itself would offer the same “fallback” management of content as keys and host records.
You mentioned that “Default enablement of Red Hat products is defined in upstream metadata”. To answer the specific question I posed, and for my own sanity and understanding (not that I’m looking to alter it), can you be more specific? Is it somewhere in the metadata files within the repodata directory of a repository? Because I looked there and couldn’t find it, and I searched quite extensively in every other place I could think of, but all in vain.
Repository sets / content overrides can be added at activation key creation time. In this way you could have your activation key both assign a content view and override your repo to enabled, while avoiding the need to add the content override after creation.
It’s interesting that you use activation keys in this way. I don’t know that I’ve come across this before. Also note that a user with access to the host can manage content overrides via the subscription-manager command line, for any repo in the host’s content view.
I think it’s somewhere in the imported manifest, and ends up in the Candlepin database as product content. Not sure if it’s published to the repository or not.
