This chapter contains various topics related to patch management.
When a new patch gets released by the vendor, it might happen that the patch has undesirable side effects (security, stability) in some scenario that was not identified by testing. When this happens (very rarely), vendors typically release a new patch, which may take hours or days, depending on the internal processes in place by that vendor.
SUSE has introduced a new mechanism (2021) called "retracted patches" to revoke such patches almost immediately by setting their advisory status to "retracted" (instead of "final" or "stable").
A patch is "retracted," when its advisory status attribute is set to "retracted." A package is "retracted," when it belongs to a "retracted" patch.
A retracted patch or package cannot be installed on systems with Uyuni. The only way to install a retracted package, is to do it manually with
zypper install and specifying the exact package version.
zypper install vim-8.0.1568-5.14.1
Retracted status of patches and packages is depicted with the icon in the Web UI of Uyuni. For example, see:
list of packages in a channel
list of patches in a channel
When a patch or package, that has been installed on a system, gets retracted, the icon is also displayed in the installed packages list of that system. Uyuni does not provide a way to downgrade such a patch or package.
When using cloned channels, you must pay attention to the propagation of the retracted advisory status from the original channels to the clones.
Upon cloning vendor channels into your organization, channel patches will be cloned as well.
When the vendor retracts a patch in a channel and Uyuni synchronizes this channel (for example, with the nightly job), the "retracted" attribute will not get propagated to the cloned patches and will not be observed by the clients subscribed to cloned channels. To propagate the attribute to your cloned channels use one of the following ways:
Patch Sync (). This function allows you to align the attributes of patches in your cloned channel to their originals.
Content Lifecycle Management. For more information about cloned channels in the context of Content Lifecycle Management, see client-configuration:channels.adoc.
When you create multiple vendor channel clones in your organization, the patches are not cloned multiple times, but are shared between cloned channels. As a consequence, when you synchronize your cloned patch (either using the patch sync function or with Content Lifecycle Management mentioned above), all channels using the cloned patch will observe that change.
Consider two Content Lifecycle Management projects
Both of these projects have 2 environments
Both of these projects have a vendor channel set as a source channel
All channels in this scenario (four cloned channels in total) are aligned to the latest state of the vendor channels
Vendor retracts a patch in the source channel and the nighly job synchronizes it to your Uyuni
None of the four channels see this change because they are using a patch clone, not the patch directly.
As soon as you synchronize your patch (either you build any of these two projects, or you use the Patch Sync function on any of the four cloned channels), due to the patch sharing, ALL of the cloned channels will see the patch as retracted.