Description of problem: I'm using a Fedora box to build RHEL container and images (with mkosi, but this doesn't really matter). I use a developer subscription on the box. But the system tself is just Fedora and all the 'rhel-*' repositories are disabled. subscription-manager dnf plugin emits the warning on every dnf operation: This system is registered with an entitlement server, but is not receiving updates. You can use subscription-manager to assign subscriptions. This doesn't cause problems, but is rather annoying. I think the warning could be conditionalized to only emit the warning if os-release indicates that the system is a RHEL system. Version-Release number of selected component (if applicable): subscription-manager-1.29.38-1.fc39.x86_64 How reproducible: deterministic Steps to Reproduce: 1. sudo dnf install subscription-manager 2. sudo subscription-manager register ... 3. sudo dnf update Actual results: Updating Subscription Management repositories. This system is registered with an entitlement server, but is not receiving updates. You can use subscription-manager to assign subscriptions. Last metadata expiration check: 0:06:17 ago on Sun Oct 29 13:30:32 2023. ... Expected results: The same but without the warning.
One short-term remedy could be to disable the DNF plugin shipped by subscription-manager by default through /etc/dnf/plugins/subscription-manager.conf
I found that some subscription-manager commands re-enable the plugin: $ sudo subscription-manager list [sudo] password for rishi: No installed products to list WARNING The yum/dnf plugins: /etc/dnf/plugins/subscription-manager.conf were automatically enabled for the benefit of Red Hat Subscription Management. If not desired, use "subscription-manager config --rhsm.auto_enable_yum_plugins=0" to block this behavior. $ cat /etc/dnf/plugins/subscription-manager.conf [main] enabled=1 # When following option is set to 1, then all repositories defined outside redhat.repo will be disabled # every time subscription-manager plugin is triggered by dnf or yum
(In reply to Debarshi Ray from comment #2) > I found that some subscription-manager commands re-enable the plugin: There's an option for that in /etc/rhsm/rhsm.conf, i.e. "auto_enable_yum_plugins" (which defaults to "1") ... > $ sudo subscription-manager list > [sudo] password for rishi: > No installed products to list > > WARNING > > The yum/dnf plugins: /etc/dnf/plugins/subscription-manager.conf were > automatically enabled for the benefit of Red Hat Subscription Management. If > not desired, use "subscription-manager config > --rhsm.auto_enable_yum_plugins=0" to block this behavior. ... which is even explicitly mentioned here ;-)
(In reply to Pino Toscano from comment #3) > (In reply to Debarshi Ray from comment #2) > > I found that some subscription-manager commands re-enable the plugin: > > There's an option for that in /etc/rhsm/rhsm.conf, i.e. > "auto_enable_yum_plugins" (which defaults to "1") ... > > > $ sudo subscription-manager list > > [sudo] password for rishi: > > No installed products to list > > > > WARNING > > > > The yum/dnf plugins: /etc/dnf/plugins/subscription-manager.conf were > > automatically enabled for the benefit of Red Hat Subscription Management. If > > not desired, use "subscription-manager config > > --rhsm.auto_enable_yum_plugins=0" to block this behavior. > > ... which is even explicitly mentioned here ;-) Sorry for the incomplete stream of consciousness. Yes, I already edited /etc/rhsm/rhsm.conf. Now I am grappling with the follow-up problem that subscription-manager pulls in /usr/bin/dnf-3 and /usr/bin/dnf4 through python3-dnf: https://github.com/fedora-silverblue/issue-tracker/issues/521 This is a problem because we don't want DNF on Fedora Silverblue.
I attempted to disable the DNF support to see if 'subscription-manager register' on the host will still upgrade UBI OCI containers to RHEL, but it didn't work: From 72975545559821159ceb3915848cfe733849b633 Mon Sep 17 00:00:00 2001 From: Debarshi Ray <rishi> Date: Thu, 11 Jan 2024 16:57:42 +0100 Subject: [PATCH] Disable DNF plugin on Fedora --- subscription-manager.spec | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/subscription-manager.spec b/subscription-manager.spec index 637c4080df77..d20e914c1bc9 100644 --- a/subscription-manager.spec +++ b/subscription-manager.spec @@ -6,8 +6,16 @@ # Plugin for container (docker, podman) is not supported on RHEL %if 0%{?rhel} %global use_container_plugin 0 +%global use_dnf 1 %else %global use_container_plugin 1 +%global use_dnf 0 +%endif + +%if 0%{?rhel} > 8 +%global create_libdnf_rpm 1 +%else +%global create_libdnf_rpm 0 %endif %global dmidecode_arches %{ix86} x86_64 aarch64 @@ -23,9 +31,6 @@ %global use_inotify 0 %endif -%global use_dnf (0%{?fedora} || (0%{?rhel})) -%global create_libdnf_rpm (0%{?fedora} || 0%{?rhel} > 8) - %global python_sitearch %python3_sitearch %global python_sitelib %python3_sitelib %global __python %__python3 @@ -96,7 +101,7 @@ Name: subscription-manager Version: 1.29.39 -Release: 1%{?dist} +Release: 2%{?dist} Summary: Tools and libraries for subscription and repository management %if 0%{?suse_version} Group: Productivity/Networking/System @@ -186,6 +191,7 @@ BuildRequires: openssl-devel BuildRequires: gcc BuildRequires: %{py_package_prefix}-setuptools BuildRequires: gettext +BuildRequires: glib2-devel %if 0%{?suse_version} BuildRequires: distribution-release @@ -734,6 +740,9 @@ rmdir %{python_sitearch}/subscription_manager-*-*.egg-info --ignore-fail-on-non- rm -f /var/lib/rhsm/cache/rhsm_icon.json %changelog +* Thu Jan 11 2024 Debarshi Ray <rishi> 1.29.39-2 +- Disable DNF plugin on Fedora + * Thu Nov 23 2023 Pino Toscano <ptoscano> 1.29.39-1 - tito: drop bz requirement (ptoscano) - Translated using Weblate (Chinese (Simplified) (zh_CN)) (jsefler) -- 2.43.0
It seems to me that disabling the DNF plugin through /etc/rhsm/rhsm.conf and /etc/dnf/plugins/subscription-manager.conf doesn't work either. I tried to disable the plugin, then unregistered my host with 'subscription-manager unregister', rebooted the host, registered it again with 'subscription-manager register', created a new UBI OCI container, tried to install the vulkan-loader RPM that's only present in RHEL, and it doesn't see it.
(In reply to Debarshi Ray from comment #6) > It seems to me that disabling the DNF plugin through /etc/rhsm/rhsm.conf and > /etc/dnf/plugins/subscription-manager.conf doesn't work either. What do you mean exactly? Do you still get the Subscription Management messages in dnf commands? > I tried to disable the plugin, then unregistered my host with > 'subscription-manager unregister', rebooted the host, registered it again > with 'subscription-manager register', created a new UBI OCI container, tried > to install the vulkan-loader RPM that's only present in RHEL, and it doesn't > see it. Does it see other RHEL content? After you start the container and run eg `dnf update`, what does /etc/yum.repos.d/redhat.repo contain?
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
It's been a year, so it's time for me to finally pick this up again. :P (In reply to Zbigniew Jędrzejewski-Szmek from comment #0) > Version-Release number of selected component (if applicable): > subscription-manager-1.29.38-1.fc39.x86_64 > > [...] > > Steps to Reproduce: > 1. sudo dnf install subscription-manager > 2. sudo subscription-manager register ... > 3. sudo dnf update > > Actual results: > Updating Subscription Management repositories. > This system is registered with an entitlement server, but is not receiving > updates. You can use subscription-manager to assign subscriptions. > Last metadata expiration check: 0:06:17 ago on Sun Oct 29 13:30:32 2023. > ... > > Expected results: > The same but without the warning. I believe that the very specific bug described here has somehow gotten fixed since Zbigniew filed it, even with subscription-manager-1.29.38-1.fc39. To clarify, the specific bug reported here is that after a Fedora host has been registered with subscription-manager(8), running dnf(8) on the Fedora host starts with this message: $ sudo dnf update Updating Subscription Management repositories. This system is registered with an entitlement server, but is not receiving updates. You can use subscription-manager to assign subscriptions. Last metadata expiration check: ... Currently on a stock Fedora 39 (with both subscription-manager-1.29.38-1.fc39 and later) and 40 with DNF4, I see: $ sudo dnf update Updating Subscription Management repositories. Last metadata expiration check: ... On Fedora 41, with DNF5, I see: $ sudo dnf update Updating and loading repositories: Repositories loaded. I don't know if subscription-manager's DNF plugin works with DNF5 or not, but a UBI container on a Fedora 41 host does get upgraded to RHEL, so the overall purpose is served. For whatever is worth, inside a RHEL 9.5 UBI container, I see: ⬢ $ sudo dnf search nautilus Updating Subscription Management repositories. subscription-manager is operating in container mode. Last metadata expiration check: ... Long story short, this informational text is still there with DNF4, but not with DNF5: "Updating Subscription Management repositories." ... and this longer warning text is gone: This system is registered with an entitlement server, but is not receiving updates. You can use subscription-manager to assign subscriptions. Zbigniew, would you agree?
However, there is another related problem that still exists. On a Fedora 40 host, where subscription-manager-1.29.41-1.fc40.x86_64 is merely installed without registering the host, running dnf4(8) on the Fedora host starts with this message: $ sudo dnf update Updating Subscription Management repositories. Unable to read consumer identity This system is not registered with an entitlement server. You can use subscription-manager to register. Last metadata expiration check: ... A lot of folks don't like those "Unable to read ..." and "This system is not registered ..." messages because it makes them think that something is wrong. This is a problem because we want toolbox to have a weak dependency on subscription-manager to upgrade UBI containers to RHEL, and since toolbox is installed by default on a few Fedora variants, lots of people get to see those messages. Interestingly, it's absent on Fedora 41 with subscription-manager-1.30.4-1.fc41.x86_64 and dnf5(8): $ sudo dnf update Updating and loading repositories: Repositories loaded. This begs some questions. Is the DNF plugin working with DNF5 or not? If it's working and the message is still not showing, then maybe there's nothing to be done? If it's not working, then will the message start showing once it's made to work? Maybe we can ignore DNF4 because DNF5 is the future? Shall we use a separate bug for this problem?
> Is the DNF plugin working with DNF5 or not? Nope, that is why you don't see anything related to subscription-manager when using dnf5 in F41+. Ideally there ought to be one, however it requires rewriting it from scratch in a different language (C++). Since this not a trivial task, and dnf5 is not a priority so far (only available in Fedora, and Fedora systems usually don't have content when registering), then no work was done for it.
(In reply to Pino Toscano from comment #14) > > Is the DNF plugin working with DNF5 or not? > > Nope, that is why you don't see anything related to subscription-manager > when using dnf5 in F41+. Ideally there ought to be one, however it requires > rewriting it from scratch in a different language (C++). Since this not a > trivial task, and dnf5 is not a priority so far (only available in Fedora, > and Fedora systems usually don't have content when registering), then no > work was done for it. I see, okay! Thanks for explaining that, Pino. This means that this bug has been suppressed until subscription-manager's DNF plugin starts working with DNF5. Since, UBI containers are still getting upgraded to RHEL on Fedora hosts with DNF5, I am wondering if one way of fixing this problem for the long term is to skip installing the plugin on Fedora. That would keep the code simple by avoiding conditions to not show the warning texts on Fedora hosts.
Here's an initial pull request: https://github.com/candlepin/subscription-manager/pull/3509
Thank you for the pull request. Based on the description, it seems to DTRT, but I don't understand the spec to know all the consequences. > Maybe we can ignore DNF4 because DNF5 is the future? Yes, pretty much. On recent fedora it's not even possible to install dnf4, because the dnf5 package has Obsoletes:dnf < 5. It sounds like the functionality provided by subscription-manager plugin is unavailable on F41+. That doesn't sound great.
Thanks for checking in, Zbigniew. I know it's been a while and you probably don't remember all the details. :) (In reply to Zbigniew Jędrzejewski-Szmek from comment #17) > It sounds like the functionality provided by subscription-manager plugin is > unavailable on F41+. That doesn't sound great. See comment 12. Regardless of whether it's a Fedora 39/40 (with DNF4) or Fedora 41 (with DNF5) host, subscription-manager is able to upgrade UBI OCI containers to RHEL. My understanding is that subscription-manager's DNF plugin is for managing the content on the host, which is unnecessary and unwanted on Fedora hosts. So from a purely Fedora perspective, everything is alright, no? The DNF plugin definitely needs to work with DNF5 for future RHEL versions, and I am assuming Pino and the other subscription-manager folks know that. :)
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.
(In reply to Debarshi Ray from comment #16) > Here's an initial pull request: > https://github.com/candlepin/subscription-manager/pull/3509 The pull request is ready for review. Scratch build for Fedora 41: https://koji.fedoraproject.org/koji/taskinfo?taskID=129685506 Scratch build for Fedora 40: https://koji.fedoraproject.org/koji/taskinfo?taskID=129686046 I tested these two builds on Fedora 40 and 41 Silverblue and Workstation. I verified that: * No DNF executable gets pulled into Silverblue, because which dnf and rpm --query --all | grep --ignore-case dnf come up empty. * No DNF warnings on Workstation when using dnf update, etc.. * If libdnf-plugin-subscription-manager is present from a previous installation of subscription-manager then it gets removed after an update. There was one instance where a UBI container was refusing to get upgraded to RHEL even when the Fedora host was registered, but it started working before I could investigate in detail. What's the best way to debug these cases? Check /run/secrets inside the container and /usr/share/rhel/secrets on the host?