How to prepare your RHEL server for an in-place upgrade

When it’s time to upgrade your Red Hat Enterprise Linux (RHEL) server, an in-place upgrade is one of the easiest, not to mention recommended, methods. An in-place upgrade means you don’t have to rebuild your environment from scratch, and you get all of the latest RHEL features, patches and security updates. Here’s what you need to know about preparing for an in-place upgrade.

Plan the upgrade

The first step is to review the servers you need to upgrade to confirm that they meet the upgrade requirements. To use the LEAPP upgrade tool, a server must be 64-bit Intel or AMD, 64-bit ARM, 64-bit IBM Z, or IBM POWER (little endian).

Next, consider the applications running on each server you’re upgrading. Applications installed from a Red Hat repository are updated along with the operating system, but custom or third-party applications often require manual updates. For example, there’s an upgrade path specially designed for SAP HANA, so it’s vital to know each server’s mission critical software and to confirm the supported upgrade path with the vendor or provider.

Prepare for downtime. With an upgrade comes necessary downtime. At the very least, there’s the time it takes for the server to complete all the updates, but you should allow time for testing and verification, too.

Understand the new security landscape. During an upgrade, SELinux is put into permissive mode, and it’s important for you to understand security changes in the RHEL release you’re moving to. Starting with RHEL 8.8, on a system running in FIPS mode, the upgrade proceeds in FIPS mode, but you should verify all security policies (especially those specific to your organization) after an upgrade.

Finally, perform a full system back up before upgrading. There are many options for this, including LVM snapshots, virtual machine snapshots, Relax-and-Recover, RAID splitting, or whatever back-up solution your organization already uses.

Ideally, you’ll spend the bulk of your time upgrading in theory before you spend any time on actually upgrading. The more you plan, the easier the upgrade process should be. For a full guide on planning for your upgrade, Red Hat releases upgrade guides specific to the source and target version. Review the appropriate upgrade guide for your systems, and make sure your systems are ready.

Prepare for the upgrade

The next step is to prepare your server for the actual upgrade. This step often involves actual changes to your server, so even though these are steps you’re doing to prepare for an upgrade it’s still part of the upgrade process.

If you’re using Red Hat Satellite, then you must verify that your server is registered with your Satellite server. On a server with Simple Content Access (SCA) enabled, use subscription-manager status to verify that the Content Access Mode is set to Simple Content Access.

During an in-place upgrade, the software packages on your server are replaced with the updated versions of those packages from the repository for the target version of RHEL. To access those packages, you must add the new repositories to your server using subscription-manager, or in the Content section of your Satellite admin panel.

Once repositories have been added, you must also install or update leapp, the tool you use for in-place upgrades.

To help avoid any surprises, review the preparation steps in your upgrade guide, confirming each step relevant to your system. It’s important to remember that many systems are unique, and may require different adjustments for the upgrade process. This is why you planned your upgrade, though. You’ve accounted for unique requirements, and during the preparation step you put that plan into action.

Get a pre-upgrade report

One of the best features of the leapp command is its ability to generate a pre-upgrade report. Using leapp preupgrade, you get a complete view of everything that will change on your system in order to complete the upgrade. Every planned change is ranked by leapp according to how much of an impact the change is likely to have on your system, with High being very likely to result in a deteriorated system state and Low being a simple change for the OS but a possible impact on applications. The Info ranking has no foreseen impact on the system or applications.

Before you upgrade, run leapp preupgrade. It provides you with valuable insight into what your system will look like after the upgrade, and could alert you to something you’ve overlooked, or else confirm what you need to verify afterwards.

Upgrade

Ideally, by this point the upgrade itself is the easy part of the process. You’ve planned, you’ve prepared your server, and you’ve run and reviewed the pre-upgrade report. You’ve reviewed the upgrade guide and application documentation, and you’ve made a list of what you need to verify post-upgrade.

All that’s left to do now is to upgrade. That’s the leapp command again:

leapp upgrade

Verify

After the upgrade is complete, it’s time to review the system state. This is essentially the planning process in reverse. As you verify the post-upgrade state of your server, you review all the potential problem areas and all the mission critical functions of the system. Whether you have custom scripts, Ansible playbooks, a QA team, or just a text file full of notes, this is your chance to second guess everything. Make sure your security policies are in place, that your services are running, and that you can put the server back into production with confidence.

In-place upgrades

In-place upgrades are convenient and fully supported. RHEL has some great commands like subscription-manager and leapp to help you perform the upgrade with ease, and services like Red Hat Satellite to help you scale the process. Approach the process methodically, and you’ll upgrade with confidence every time.