CentOS 8: Why extended support is better than rushed migration

Still using CentOS 8 even though it’s now unsupported, and in spite of the obvious risks? Well, in a way it’s understandable. Red Hat took everyone by surprise when it cut the official support window for CentOS 8 from ten years to two years, leaving you with just a year’s notice that the OS is going end of life.

A year sounds like a long time, but it flies by in the life of a busy sysadmin – and it’s not a particularly long period of time to test system migration. But if the recently discovered LUKS bug pushed you into action, we want to use this article to tell you to stop and wait. A rushed, ill-considered migration can be catastrophic.

Read on to see what you should think about before you migrate, and why extended lifecycle support may well be a better option than rushing through a migration process.

CentOS 8 migration options

Just in case you’ve not yet considered your options around CentOS 8, here’s a quick refresh. Now that CentOS 8 is end of life you won’t get future patches and updates for it which means your machines will be vulnerable to new exploits – unless you try to build a patch yourself.

Switching to CentOS 9 isn’t an option – there won’t be a CentOS 9, and for a large section of CentOS 8 users CentOS Stream isn’t an option either. Your choices are then between Linux distributions that are not binary compatible with CentOS (e.g. Ubuntu, SUSE), or those that are (e.g. RHEL, Oracle Linux, RockyLinux or AlmaLinux).

As discussed in a previous article, binary compatibility can make your life a lot easier when switching, and it’s arguably recommended to switch to a binary compatible distribution as long as you can find a vendor that you feel happy with.

In theory, switching is easy. In reality…

If you’re switching to an OS that’s binary compatible with CentOS 8 the process should be relatively simple. Each distribution would be different in how you perform the switch – but the good news is that many binary distros that are binary compatible with CentOS 8 offer a simple path to switching.

It typically requires as little as running a script. Vendors including Oracle and RHEL have scripts available to switch machines running CentOS 8 to their respective distros. Likewise, both the AlmaLinux and the RockyLinux projects supply a simple script that you can run to switch. In theory, anyway, switching is really easy and you could probably switch even large fleets with little effort.

But, as any experienced technology professional knows, the devil is in the detail. Yes, there’s a good chance the switch will go flawlessly. But there are also a myriad of small but significant problems that can stop you in your tracks.

Some of the problems you could run into

There is always a risk involved when migrating away from your existing distribution. That’s the case even where the new distribution is a binary compatible distribution. Countless things can go wrong.

It could be a small quirk of the application you’re running which depends on everything in the OS being exactly so. Or, it could be a driver that is deployed on the system to support a particular hardware device that may no longer be supported.

Indeed, the root problem may be as simple as an application or service that won’t let you install it properly on the new system or that won’t run on the new system at all because it specifically searches for the “CentOS 8” text in the distribution name (a very common scenario).

These are technically-speaking small problems, but nonetheless real dangers, because migration could fail. Applications that are critical to your business can rely on simple checks to ensure that they are compatible with a given distribution – and then just refuse to start for no good reason.

Fixing it is a simple code change, but until the application developers modify the code you won’t be able to use the application in your new distribution, even if that distribution is otherwise binary compatible.

How to prepare for OS migration

So you could easily end up in a situation where your application simply won’t run after you’ve performed the migration. Due diligence demands that you test before you migrate, and it’s not that we’re suggesting that you’re considering doing no testing before your migration.

The real question is – do you have time to perform testing? With time, resource, and budget constraints being what they are, testing is easily neglected. There are numerous things you have to consider.

It starts, of course, with a full backup. You likely already have backups in place, but it does lead to the next question: how confident are you that your backups will successfully restore if you need them to? This is something you may or may not have tested – and which you’ll need to do before migration.

Next, you need to test every application you depend on for your workloads. For some CentOS users, this can be quite a complex process, particularly where applications are interdependent. Errors won’t necessarily reveal themselves as soon as you reboot after migration, you may only become aware of these errors through actual usage, and that may only happen over time.

In other words, there’s just no quick way to do an OS migration quickly, even though the practical steps involved in migration may be as simple as running a script.

 And, anyway, your your CentOS 8 systems are already running on borrowed time.

Don’t wait and take a risk, but don’t rush either

 You can’t sit around running CentOS 8 without active support for even a moment longer. The LUKS vulnerability is a significant risk and won’t be the last vulnerability that emerges. On the other hand, rushing a migration is clearly unwise. But there is an alternative that can buy you some time.

If your organization relies on a specific application or hardware device that is only supported on CentOS 8, then your best choice is to extend your support to ensure security updates continue to be available – by deploying TuxCare’s Extended Lifecycle Support (ELS) service, for example.

In some ways, you don’t really have a choice at this point because EOL for CentOS 8 is already in the rearview mirror. By running CentOS 8 without official support you’ll be in breach of any compliance standards you’re subject to within just a couple of weeks. So yes, currently you’re still within the acceptable delay of 30 days between vulnerability announcement and patch deployment, but this will change soon (in a matter of days now, rather than weeks or months).

Whether you opt for TuxCare’s ELS service, a similar service from another provider, or choose to hire a third party to build patches, you need to do something. TuxCare is priced affordably, straightforward to set up, and won’t interfere with your workloads.