Use > Server patching > Patch management for Red Hat Linux Enterprise > Best practices for managing minor RHEL releases

Best practices for managing minor RHEL releases

The current SA model differentiates between Red Hat platforms based on the major version number. A major version is denoted by a whole number version change. For example, Red Hat Enterprise Linux 5.0 and Red Hat Enterprise Linux 6.0 are both major versions of Red Hat Enterprise Linux while RHEL 6.6 and 7.1 are considered minor releases.

SA follows Red Hat practices and allows managing of packages and upgrades between minor versions. A customer with a Red Hat Enterprise Linux 7.0 can use SA to patch the system and upgrade to Red Hat Enterprise Linux 7.2 minor release.

The most common use cases that involves the SA Red Hat patching mechanism are upgrade scenario and keeping a point-release up to date. This chapter is only addressed to customers that want to keep a minor release up to date or want to upgrade to another minor release.

Guidelines for upgrading a RHEL minor release

This involves importing the content into SA, setting a proper value for repo.restrict custom attribute, scanning the managed servers and then remediating a policy. The guidelines in this section apply to both software policies and dynamic patch policies, unless otherwise specified.

Let’s take the following scenario: a Red Hat Enterprise Linux Server 7 needs to be upgraded to the Update 2 minor version.

Importing minor release packages

Red Hat Enterprise Linux minor releases are an aggregation of enhancement, security, and bug fix errata since the last major release.

To be able to upgrade the managed servers at Update 2 you will have to import the 7.2 content repository. The upgrade operation does not need to go through all subsequent releases. In our case we don’t need to upgrade the system at 7.1 release and then at 7.2 release. You can upgrade directly to 7.2.

For the import process, besides configuring redhat_import.conf you need to add at the end of the file the following three lines:

[rhel-7-server-rpms{7.2-x86_64}]
platform=Red Hat Enterprise Linux Server 7 X86_64
enabled=1

This assigns a platform for the Update 2 content repository and enables it for import.

Setting up repo.restrict custom attributes

By default, the Red Hat Importer tool imports packages in specific folders. Each minor release version will be imported in its own path. For example, the packages for Red Hat Enterprise Linux 7 Update 2 will be stored in /RHSM/Packages/Red Hat Enterprise Linux 7 Server (RPMS) (7.2-x86_64) folder. Similarly, content for 7.1 and 7.0 will be imported in their own custom folder.

Note This step is mandatory for dynamic policies. For software policies, although not mandatory, having a repo.restrict in place is recommended when remediating the content software policy.

Typically, a content repository can have thousands of packages but not all of them are eligible for upgrade. The scan procedure queries the managed server for the RPMs already installed. Then it will mark only RPMs with newer version than the ones installed for upgrade.

The scan mechanism by default – builds an RPM repository with all available RPM packages in SA Software Repository. If you have content imported for 7.1 and 7.2, the repo will contain packages for both releases. The repo.restrict custom attribute comes in handy when you want to upgrade some machines at Update 1 and some others at Update 2. It will help you restrict the folders in the SA Library that the server has access to. All other folders will be inaccessible to the server. This gives you folder-level control over which versions of RPMs can be applied to a given server, allowing you to precisely upgrade to a specific version per each managed server.

In other words, please set the repo.restrict custom attribute value to the path where Update 2 packages are located. This can be set per device, or per device group. You can even set it on the dynamic patch policy/software policy if you are sure that the policy will be attached only on devices that need to be upgraded to the 7.2 release.

For more information about repo.restrict, see Manage Red Hat patches.

Scaning managed servers

This step only applies to dynamic patch policies. Once the custom attribute is set you need to create a dynamic patch policy , attach it on the devices that need to be upgraded and then run a patch compliance scan. This will trigger the actual scanning for building the recommended RPMs to install.

Remediating the patch policy

In case the patching happens with dynamic patch policies you can remediate the recommended patches – discovered in the previous step - by starting a remediation job against the dynamic patch policy previously attached to the managed servers. For more information, see Policy management.

For patching with static software policy things are a little bit different. You can’t benefit from the scanning procedure that occurred in the previous step. You will have to remediate all packages imported from the minor content repository. Fortunately – redhat_importer tool already groups all imported packages into a software policy. Using the default configurations for the importer the policy you can find the policy in SA Client under /RHSM/Content/ Red Hat Enterprise Linux 7 Server (RPMs) (7.2-x86_64) Policy.

The remediation job for this policy will determine the eligible packages for upgrade in the analyze phase and install them.

Note HPE recommends upgrading minor releases through dynamic patch policies because it offers better performance.

Keeping a minor release up to date

Patching a Red Hat minor release with fixes, updates and security errata involves exactly the same steps used for upgrading. Just make sure that repo.restrict custom attribute restricts the SA repo to the packages corresponding to your particular minor version.

Send Help Center feedback