Created attachment 1082927 [details] Activation Key page One can override the 'enable' setting for products, both custom and RH, in the activation key's "Product Content" page.
Moving 6.2 bugs out to sat-backlog.
I think an effective way to solve this issue would be to allow the user to define major OS release version and/or architecture for a custom products repos. This way you can have a single Custom Product, but the client (subscription-manager) will enable the correct repo based upon os/architecture. EPEL ---- EPEL EL6 x86_64 repo ---- EPEL EL7 x86_64 repo As a point of comparison, if you put both RHEL6 and RHEL7 content in the same content view and register a RHEL6 host to use it, only the RHEL6 repos show up. This is due to the 'required tags' field in the product/entitlement certs. rct cat-cert /etc/pki/product-default/69.pem +-------------------------------------------+ Product Certificate +-------------------------------------------+ Certificate: Path: /etc/pki/product-default/69.pem Version: 1.0 Serial: 12750047592154746560 Start Date: 2016-01-04 13:07:32+00:00 End Date: 2035-12-30 13:07:32+00:00 Subject: CN: Red Hat Product ID [b0918f42-730b-4ee9-b4ee-9504e60fcb1a] Issuer: C: US CN: Red Hat Entitlement Product Authority O: Red Hat, Inc. OU: Red Hat Network ST: North Carolina emailAddress: ca-support Product: ID: 69 Name: Red Hat Enterprise Linux Server Version: 7.3 Arch: x86_64 Tags: rhel-7,rhel-7-server Brand Type: Brand Name: Effectively the customer is asking for the same, but for custom products. Then they can have all the repos in a Custom product (and Content View) and they dont have to worry about activation key sprawl.
In our case it would be important to allow disabling in the product not in the activation key. E.g. right now we create activation keys using hammer, then we have to call hammer to deactivate all active repositories on that newly created key and enable the ones we want afterwards.
*** Bug 1444156 has been marked as a duplicate of this bug. ***
*** Bug 1634108 has been marked as a duplicate of this bug. ***
*** Bug 1804101 has been marked as a duplicate of this bug. ***
Connecting redmine issue https://projects.theforeman.org/issues/29951 from this bug
Upstream bug assigned to paji
*** Bug 1853497 has been marked as a duplicate of this bug. ***
Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/29951 has been resolved.
We had tried allowing the user to disable/enable custom repos by default. But due to the way Candlepin works this would change the enablement of the repos retroactively for all clients, and there was no way to only change enablement at registration. This was considered dangerous/confusing and not acceptable by PM, and so we ended up reverting the change upstream (https://github.com/Katello/katello/pull/8947) and implementing https://bugzilla.redhat.com/show_bug.cgi?id=1526564 as an alternate approach.
I wouldn't consider https://bugzilla.redhat.com/show_bug.cgi?id=1526564 an alternate approach as it doesn't fix the reported issue in this bz. Customers still need to run bulk actions on every registered host to disable a newly added custom repository. If a customer forgets this they may install packages on clients that shouldn't be there. >> this would change the enablement of the repos retroactively for all clients That is true. But having the option to override the default behaviour at least leaves the choice to the customer. We can add a warning message for changing the option.
Hello, Would it be possible to reconsider this BZ? I fully agree with Stefan above and would also suggest to have an option to override the default behavior. Maybe adding a warning when adding a custom repo to an AK, that this does not enable it automatically: what do you think? Kind Regards, Cisco.
I'm going to defer to @rjerrido for further comment..
If I am understanding the request (and the PRs 8805/8947), the concern here is that repositories provided custom products are enabled by default, both in entitlement and SCA mode. The question, I will ask in response is 'will the users be OK with disabling these repositories by default (and enabling repos via AK)?', because that is the only alternative.
Hi @rjerrido I asked this to my customer and the answer was clearly, that if a) any new (custom) repository is by default: disabled for EXISTING systems and b) the new (custom) repository is by default disabled for all Activation Keys i.e. you have to 'override to enabled' to make it available to new deployments. well then that is exactly what should happen, yes. Hope that clarifies it. Kr, Cisco. (In reply to Rich Jerrido from comment #50) > If I am understanding the request (and the PRs 8805/8947), the concern here > is that repositories provided custom products are enabled by default, both > in entitlement and SCA mode. > > The question, I will ask in response is 'will the users be OK with disabling > these repositories by default (and enabling repos via AK)?', because that is > the only alternative.
I agree with cisco in #51. If we cant have a a switch for each repo it is better to disable the custom repos by default and leave it to the customer to set it to enabled in the activation key. I think more customer input is required and I will ask our TAMs to check with their customers.
Hello, we are eager to have any update about this proposal, if it's viable and what could be a possible timeline. Thanks in advance, Cisco.
I understand that changing the default behaviour also affects pulp and subscription-manager. If we can not change the default behaviour we should at least give our customers the option to set a new repository to disabled or enabled. Same as we offer the option to set the arch and os-release for custom repositories.
*** Bug 1983713 has been marked as a duplicate of this bug. ***
*** Bug 1985907 has been marked as a duplicate of this bug. ***
Customer in Public Sector is interested in this enhancement. Is there an ETA on this RFE?
Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team. Thank you.
With legacy entitlement modes going away, I think the absence of this or a similar feature will be one of the biggest pain points for upstream users. So I think this should be kept open for more discussion.
Yet Another Customer who wants this feature.
Our company need this feature too, would be great to finally see it released.
+1 Our company need this feature too.
This feature is critical for customers who are preparing to enable Simple Content Access. Whether the decision is to change new custom repos to disabled by default for existing systems and activation keys or to provide an option to set it to disabled or enabled, it is critically important that this feature enhancement be added ASAP. I have heard some conjecture about how content views can be leveraged as an alternative to disabling new repos across your entire inventory, but this is not a good alternative. We wrote a custom script to identify the different permutations of subscription sets that our hosts have and we have over 100 unique subscription sets across our hosts. I do not believe that this would be an unusual result for customers. It would be untenable to tightly restrict repository visibility for the sole purpose of fencing off repositories by managing over 100 content views because the project team doesn't want to implement a simple RFE. The current enabled by default with no option to change it for custom repositories was not disruptive to this point, due to subscriptions being a gatekeeper of sorts while Simple Content Access is disabled. However, once SCA is enabled and that "gatekeeper" is removed, this design choice becomes unreasonable for customers. With SCA enabled, there should be a way to add a custom repository to your environment without having to then manually go and disable it on every existing host and activation keys OR create additional content views that have to be perpetually managed.
+1 to have this feature added. The switch to Simple Content Access will be incredibly disruptive unless we are able to add new repositories as disabled by default.
Also +1 we're moving to SCA and having all of the repos enabled by default is not working for us.
For folks who are having issues preparing for SCA due to custom repos having been set to enabled by default, please feel free to look at this gist of a script that we wrote to assist in our transition (ongoing) https://gist.github.com/JRNC/62ebe4b9045ed06420f26be0d878e7e0. This script will identify and group hosts in Satellite that share the same exact set of subscriptions and create a host collection per grouping. This is helpful for teams that are preparing to enable Simple Content Access; however, need to first disable all of the unsubscribed repositories that set themselves to enabled by default. Instead of disabling unsubscribed repositories host by host, this will trim it down, so that you can disable unsubscribed repositories host collection by host collection. I hope that this can help some folks.
(In reply to James Riley from comment #90) > For folks who are having issues preparing for SCA due to custom repos having > been set to enabled by default, please feel free to look at this gist of a > script that we wrote to assist in our transition (ongoing) > https://gist.github.com/JRNC/62ebe4b9045ed06420f26be0d878e7e0. This script > will identify and group hosts in Satellite that share the same exact set of > subscriptions and create a host collection per grouping. This is helpful for > teams that are preparing to enable Simple Content Access; however, need to > first disable all of the unsubscribed repositories that set themselves to > enabled by default. Instead of disabling unsubscribed repositories host by > host, this will trim it down, so that you can disable unsubscribed > repositories host collection by host collection. I hope that this can help > some folks. Disclaimer, I am not a Red Hat employee and the script is being made public to help out the community (no support or guarantee of proper functionality).
Updating with the current state of how we're addressing this: We're going to flip the default enablement for custom repositories (e.g. repositories that are part of custom products). Previously, custom products were enabled by default. Now, they're going to be disabled by default. However, we need to do this with minimal disruption to existing hosts. This will be done with a migration that adds content overrides so that repo enablement on a given host will remain the same after upgrade. This change will apply to all users, but it's in the context of Simple Content Access soon becoming the only supported entitlement management strategy. Verification Criteria: When I create a new custom repository, it's disabled by default (e.g. `subscription-manager repos` shows `Enabled: 0` for that repo) and I can't install packages from it) When I upgrade Satellite, the enablement of my existing repos on my existing hosts is not affected. Any repos that were previously "Enabled" are now "Enabled (Overridden)" subscription-manager repos shows `Enabled: 1` for these repos I am able to easily add content overrides ("Override to Enabled" / "Override to Disabled") on existing hosts I am able to easily add content overrides ("Override to Enabled" / "Override to Disabled") on activation keys
*** Bug 1938365 has been marked as a duplicate of this bug. ***
I agree the current configuration of having 3rd part products enabled by default is bad, as we are using simple content management, and I almost got burned by adding a several related new 3rd party repositories that we need for a very small number of hosts, some of which contain newer version of packages that are on most to every one of our Red Hat boxes, and we almost via our automated updates cycle sent these newer 3rd party versions of packages out to all of our RHEL boxes, instead of only having it go out to the small number of boxes that needed the 3rd party repos version to work with other third party packages from those repositories. For the rest of this please note I am currently a satellite noob, that is learning on the fly, so I may not understand things fully. Anyone from Red Hat please feel free to tell me this should be opened as a separate Bug or to suggest some other documentation to read. Is what is being asked for and what is being delivered truly what we as customers want. Yes, by default I want third party repos turned off to avoid the situation I just described, but if you are doing this directly to each host's settings it's not what I really want. What I really want is for it to be set at the Activation key level (and/or the host group level if supported) to off by default and have the hosts in the activation key level take whatever setting is at the Activation Key level (or be overridden by host group host level setting) unless I explicitly set that setting as an override at the individual host level. That way if I add a repo for some third-party package, It's disabled and if I want it to be on for certain hosts I can go in and override those settings at the host level but if I the repo to be available for all hosts (or if supported certain host groups), I can go into my activation key/s (or host group/s) and set it to enable and have all of the hosts that are part of that grouping be enabled. (Please don't let my comments if they take too much work to implement delay the rollout of having it off by default as for Simple content management hosts like my company is using having third part repos off by default and having to mess around with each host is a much better situation than having Red Hattell me that we are having problems because of a particular unsupported package overwrote the Red Hat version, when it did not need to be, and then having to turn off the repo for most systems and work test/implement the rollback of the systems that didn’t need the third part version to the Red Hatversion.
Hi Alexander, One thing to keep in mind is that activation keys affect hosts ONLY at registration time. If you add a repo override (Override to Disabled or Override to Enabled) to an activation key, the host will get that override when it's registered. But, when you need to change the host's access to that repo AFTER registration, changing the activation key won't accomplish that. You'll have to go change it explicitly for the host, or change the AK and then re-register the host. If you need to change repo overrides for multiple hosts after registration, you can also use bulk content host actions (Hosts > Content Hosts). Contrast that with hostgroups, where a change to a hostgroup's attributes will affect all hosts that are part of that hostgroup. However, repo overrides cannot be set at the hostgroup level. With this change to custom product default enablement, none of that is any different. The only difference is that for both hosts and AKs, custom products will be disabled by default and you'll have to create overrides if you want to enable them. Any more questions / comments are welcome.
(In reply to Jeremy Lenz from comment #99) Thank you for your reply. I think I have a better understanding of how things work now and why my suggestion won't work.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: Satellite 6.14 security and bug fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2023:6818
I get a 404 at the suggested link https://access.redhat.com/errata/RHSA-2023:6818 Please add some discussion of what the solution is, in this bug context.
Please see https://bugzilla.redhat.com/show_bug.cgi?id=1265120#c93 for an explanation of the implemented changes.