Patch Management

This chapter contains various topics related to patch management.

1. Retracted Patches

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 SUSE Manager. The only way to install a retracted package, is to do it manually with zypper install and specifying the exact package version. For example:

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 SUSE Manager. 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. SUSE Manager does not provide a way to downgrade such a patch or package.

1.1. Channel Clones

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 SUSE Manager 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 (Software  Manage  cloned channel  Patches  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 Software Channels.

1.2. Patch sharing

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.

Example:

  1. Consider two Content Lifecycle Management projects prj1 and prj2

  2. Both of these projects have 2 environments dev and test

  3. Both of these projects have a vendor channel set as a source channel

  4. All channels in this scenario (four cloned channels in total) are aligned to the latest state of the vendor channels

  5. Vendor retracts a patch in the source channel and the nighly job synchronizes it to your SUSE Manager

  6. None of the four channels see this change because they are using a patch clone, not the patch directly.

  7. 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.