Repository Sets in Activation Keys

[dweff]

In Section 3.6: Guided Exercise: Automate with Activation Keys at timestamp 2:08, Jesse Scott is setting up the Activation Keys for the OperationsServers.
I noticed that when he's working on the Repository Sets tab, he's manually disabling all the repositories not needed for the Host Collection he's working with. Since those repositories are already not available to the Host Collection (checking the "Limit to Environment" box makes them disappear), is this a case of a belt and suspenders approach?

[jessescott · Accepted solution]

Hi @dweff!

Thank you for taking the RH403 course in the Red Hat Learning Subscription. I've been on the road for training deliveries lately and just noticed that you have a question here regarding the class.

In the student guide for the course, step 6.3 in the activity tells us to 'Disable the following RHEL 8 repositories' - Red Hat Enterprise Linux 8 x86_64 - AppStream (RPMs) and Red Hat Enterprise Linux 8 x86_64 - BaseOS (RPMs). In the video, you see me select the checkboxes for those two repositories before selecting 'Override to Disabled'.

In this case, the writer of the guided exercise provided that step for a couple of reasons.:

1. If all of the previous activities have been done prior to doing this one, those two repositories are already enabled. Since we don't need those RHEL 8 repositories for the RHEL 9 hosts that we're targeting later, the activity has us disable them.

2. Often, guided exercises will have us go the extra mile to follow a 'belt and suspenders' approach like this to show that there are a few different ways to handle the task at hand. The step is giving us a chance to practice using that particular option.

In this case, like you mention, there are a few other ways to NOT see the two repositories be enabled. Either they were not previously enabled to begin with for the host collection or we have used the 'Limit to environment' option to only see the repositories that apply to the environment we are targeting.

In this recording, I'm following the steps like they are written in the student guide. I really like your 'belt and suspenders' comparison, though. If the question is, "Are we using the 'Override to Disabled' option to be absolutely certain that we have those repositories disabled (even though some other option would have made them already unavailable)?", the answer is simpler than this. We had not used the 'Limit to environment' approach in previous steps (as they are written) and this way gave us a way to practice the 'Overide to...' options that were discussed earlier in the course.

Hope this helps, and thank you for your question!

[Travis]

@jessescott made an excellent point and very well said. One of the other things to keep in mind here is we want to be very specific in approaches here too. In this instance, yes, things are easy as RHEL8 vs. RHEL9, but I've been in other situations where you don't want default repositories too or want to further limit.

This can also be accomplished with Content Views, so even if a repository is enabled, there is no content to consume as the CV prevents the content regardless of all the repositories that are enabled from being seen or installed.

In a worst case scenario, I've seen some customers and administrators go back and manually enable and attempt to force installation of packages. I haven't seen recently but on some RHEL6 and RHEL7 systems, they forced a 64-bit system to subscribe to the 32-bit repositories and then did yum upgrades with force and broke an entire system by forcing 32-bit packages to be installed.

So for environments where high-availability is concerned, it is better to be safer and even wear additional pants with another set of belt and suspenders which might be content views and lifecycle environments that way there are multiple levels of control and administrators of the system must go through a bunch of hoops to "break" the system.