Description of problem: foreman-protector blocks lots of updates (both RHEL and Satellite packages) Version-Release number of selected component (if applicable): rubygem-foreman_maintain-0.4.8-1.el7sat.noarch satellite-maintain-0.0.1-1.el7sat.noarch yum-3.4.3-161.el7.noarch How reproducible: always Steps to Reproduce: 1. I have installed 6.6 on RHEL 7.6 2. # yum upgrade | tee Loaded plugins: foreman-protector, langpacks, product-id, search-disabled-repos, : subscription-manager WARNING: Excluding 11574 updates due to foreman-protector. Use foreman-maintain packages install/update <package> to safely install packages without restrictions. Resolving Dependencies --> Running transaction check ---> Package numactl-libs.x86_64 0:2.0.9-7.el7 will be updated ---> Package numactl-libs.x86_64 0:2.0.12-3.el7 will be an update ---> Package rubygem-foreman_maintain.noarch 1:0.4.8-1.el7sat will be updated ---> Package rubygem-foreman_maintain.noarch 1:0.4.9-1.el7sat will be an update --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: numactl-libs x86_64 2.0.12-3.el7 rhel-7-server-rpms 30 k rubygem-foreman_maintain noarch 1:0.4.9-1.el7sat Sat6-CI_Red_Hat_Satellite_6_6_Composes_Satellite_Maintenance_Next_RHEL7 139 k Transaction Summary ================================================================================ Upgrade 2 Packages Total download size: 169 k Is this ok [y/d/N]: Exiting on user command Your transaction was saved, rerun it with: 3. # foreman-maintain packages unlock 4. # yum upgrade | tee Loaded plugins: langpacks, product-id, search-disabled-repos, subscription- : manager Resolving Dependencies --> Running transaction check ---> Package GeoIP.x86_64 0:1.5.0-13.el7 will be updated [...] ---> Package python-syspurpose.x86_64 0:1.24.13-3.el7_7 will be installed --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: kernel x86_64 3.10.0-1062.1.2.el7 rhel-7-server-rpms 50 M [...] python-syspurpose x86_64 1.24.13-3.el7_7 rhel-7-server-rpms 266 k Transaction Summary ================================================================================ Install 2 Packages (+6 Dependent packages) Upgrade 316 Packages Total download size: 582 M Is this ok [y/d/N]: Exiting on user command Your transaction was saved, rerun it with: yum load-transaction /tmp/yum_save_tx.2019-09-24.05-36.Z6p5FG.yumtx Actual results: In locked (default) state, I only see 2 package updates. In unlocked I can see 316 upgradable packages. Expected results: IMO we should not block updates on Satellite system - e.g. we are blocking 98 security related updates in my case: # yum upgrade --security | grep 'for security' 98 package(s) needed (+0 related) for security, out of 318 available
Created attachment 1618546 [details] full `yum upgrade` output on unlocked system
For those who stumbled on the same problem https://access.redhat.com/solutions/4591281
See this RFE which I wrote up to attempt to address some of the pain we are causing our customers with the package locking: https://bugzilla.redhat.com/show_bug.cgi?id=1773648 Installation of BaseOS updates should not necessitate an execution of 'satellite-installer --upgrade'. This may be hard to determine but if we could only run the --upgrade step if packages were We are taking a possible ~5-10 second package installation into in some cases a 15+ minute run of the installer as well as outage inducing restart. As an extreme but illustrating example: # foreman-maintain packages unlock ... Running unlocking of package versions ===================================== Unlock packages: [OK] ------------------------------------- # time yum -y install zsh Loaded plugins: product-id, search-disabled-repos, subscription-manager Resolving Dependencies ... Installed: zsh.x86_64 0:5.0.2-34.el7_8.2 Complete! real 0m5.179s **** 5 seconds. Now, with the installer: # foreman-maintain packages lock ... Running locking of package versions =================================== Lock packages: [OK] ----------------------------------- # time foreman-maintain packages install -y zsh .... Installed: zsh.x86_64 0:5.0.2-34.el7_8.2 Complete! [OK] ------------------------------------ Running satellite-installer --upgrade --disable-system-checks: Upgrading, to monitor the progress on all related services, please do: foreman-tail | tee upgrade-$(date +%Y-%m-%d-%H%M).log ... Upgrade completed! Package versions are being locked. [OK] -------------------------------------------------------------------------------- Check status of version locking of packages: Automatic locking of package versions is enabled in installer. Packages are locked. [OK] -------------------------------------------------------------------------------- real 16m40.003s *** 16 minutes and an outage just to install a package from the BaseOS repository.
`satellite-maintain packages [install|update]` is the recommended way of installing packages from Satellite 6.6+ [1] While we're exploring if it is easy to detect if packages are installed exclusively from baseOS repos, it should not stop customers from using `satellite-maintain packages` method. Please keep us updated if this is deemed as a blocker. [1] https://access.redhat.com/documentation/en-us/red_hat_satellite/6.6/html/administering_red_hat_satellite/chap-red_hat_satellite-administering_red_hat_satellite-maintaining_a_red_hat_satellite_server#installing-and-updating-packages-on-satellite-server
Patel, Any company taking security and control serious uses an OS Configuration manager to configure the OS used on the Satellite server. The proposed 'satellite-maintain packages [install|update]` is not supported by OS Configuration tools like Puppet and Ansible. Peter
All, while we wait for this BZ and the RFE mentioned in Comment #10 to be implement, everyone is free to disable the package locking in satellite-maintain, simply run: # satellite-maintain packages unlock and yum will behave as normal and will still be supported. While we recommend utilizing the package locking provided by satellite-maintain, we realize that in some environments it is not a desired solution to ensure that Satellite packages are upgraded without running the upgrade routine.
A very simple workaround, that we also use in the Nagios plugin for checking for updates [1] is to disable foreman-protector on the command line. So, for example: # yum update --disableplugin=foreman-protector Note: This can only be considered a workaround to avoid having to run satellite-maintain for unlocking or install/update packages. Oliver [1] https://github.com/matteocorti/check_updates/blob/16a0ea72cd0c137884f0d1e2a3a50470934a8f58/check_updates#L1187
Hello, The recommended way to do the Satellite or Capsule upgrades are using satellite-maintain and any changes in Base OS may result in the need to run the installer. Considering this I am closing this bugzilla. If you think this is still an issue request to reopen or raise new bugzilla. Thank You, Amit Upadhye.
This is a documentation reference: Managing Packages on the Base Operating System of Satellite or Capsule https://access.redhat.com/documentation/en-us/red_hat_satellite/6.10/html-single/administering_red_hat_satellite/index#installing-and-updating-packages-on-satellite-server
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days