The clock is winding down on CentOS 8

TuxCare is adding support for CentOS 8
TuxCare is adding support for CentOS 8

An IT environment is a complex set of interconnected operating systems, applications, networking, databases, and a whole lot more. When it’s running smoothly, think of it like a finely tuned piano. When an operating system vendor suddenly announces a support change like the one that has happened with CentOS 8, the music no longer sounds as good.

The major blow here is that support for CentOS 8 was initially announced to be available until 2029. So cutting it back to 2021 is a massive change.

Especially in the Enterprise space, where issues like compliance, security, and availability are paramount, losing support for an established operating system is a hard blow. It basically means that, past the end-of-life date, you’re on your own to deal with new vulnerabilities, resolve compatibility issues or deployment problems. And any downtime means your business is affected.

When you expect an operating system to go end-of-life in a few years, you have ample time to find the right path forward, to plan the migration, and to account for interactions with other systems. You have the expectation that the transition will happen smoothly. On the other hand, it’s a whole different story when you’re presented with a fait accompli and have to scramble to get everything ready in the space of a few months. For an Enterprise, things don’t usually happen on this time scale.

You may think that your systems are fine as they are, so there is no problem and you don’t need to worry about this – or that your organization has the skill sets and available resources to create its own patches for new threats that will inevitably appear. But that is a very slippery slope. There is an in-depth analysis of this very issue which you can find here if you want to dig deeper. Also, if you want to get an idea of the financial risk associated with having unpatched systems, you should check out this calculator.

Some of the risks involved with having unsupported systems – i.e., systems running past their end-of-life – include:

  • Loss of compatibility and reliability. The operating system is not just the kernel; it includes many associated utilities and runs many third-party applications. Losing the centralized source of updates and relying on homemade patches can lead to you not being able to run other software or having some unintended consequence somewhere else on the system.
  • Security. Without regular updates and fixes, security holes will accumulate quickly. New vulnerabilities appear all the time, and supported systems receive updates just as often. After some time, an unpatched system will be like a Swiss cheese full of holes, which endangers the other systems in the infrastructure, even if they are not running CentOS 8.
  • Compliance. Compliance standards will often have clauses that stipulate how long a known vulnerability can exist in a system before being patched or how often patching has to occur. Without patches, this is impossible to meet. Depending on the industry, loss of compliance can directly translate into a loss of business opportunities.

And this just scratches the surface of these issues. There is so much more to unpack behind this deceptively simple change in support.

To be fair, CentOS will continue to exist beyond version 8, but it will have a different form. And let’s be perfectly clear here – RedHat has the right to change the project direction however it sees fit. It’s just the consequence of this change that we are addressing.

CentOS has historically existed as a release built directly from a stable RedHat Enterprise Linux (RHEL). CentOS 8 from RHEL 8, for example. So it would have the exact same packages and versions as RHEL.

This matters because you could target one specific version of RHEL – the de facto standard Enterprise Linux distribution – for your application development and use it in the respective CentOS release without issue, minus RHEL’s licensing cost. Using open-source language, CentOS will move from being downstream from RHEL to being upstream.

The new direction will see CentOS transition to CentOS Stream, where there isn’t a fixed release of RHEL that serves as its base. Instead, CentOS Stream will be released ahead of RHEL, with newer versions of packages, as a sort of testbed before those packages are included in RHEL. This has the unfortunate side effect of possible loss of binary compatibility, and this changes everything.

While some use cases will not be affected by this change, it’s expected that those will be a minority. Red Hat’s own CTO has said that CentOS Stream is not a replacement for CentOS 8.

In an ironic twist of fate, users that did not update CentOS 7 to 8 will continue to have support until 2024. So why not downgrade to CentOS 7? Well, for a start, there is no supported downgrade path. And the unsupported ways risk leaving systems in a “Frankenstein” state with packages from both 8 and 7. That is a direct path to having issues further down the road.

Alternative distributions to replace CentOS 8 can be found in two groups: RHEL-derivatives that are binary compatible with it and non-binary compatible distributions.

Being binary compatible has the (considerable) advantage of requiring substantially less effort and changes to existing infrastructure, as similarities between distributions mean tools and scripts that worked before will continue to work or require minimal changes.

RHEL itself is, obviously, the first option. However, because of the community backlash against the changes to CentOS, RedHat announced that there would be a free licensing option for 16 or fewer system installations, so this would be a good option for some cases.

However, most Enterprise deployments have (far) more than 16 systems, so charges would apply if they go with RHEL.

Enterprise IT teams will naturally look for another free Linux distribution to replace CentOS 8. And there are quite a few possibilities in this space, and this abundance of options ironically makes a choice more difficult.

There are already established distributions like Oracle Linux and “younger” alternatives like AlmaLinux or RockyLinux. These are all binary compatible with RHEL and derive from it, so things like package management, tooling, and monitoring would be easier to adjust.

There are other alternatives that are not binary compatible with RHEL, like Debian or Ubuntu, that are common names in this space. However, due to their inherently different architecture, these would force changes to other infrastructure elements separate from the systems they are deployed on.

Some of the things that are affected when migrating to a new operating system include:

  • Monitoring and management systems need to be reconfigured to cope with differences in the underlying operating system.
  • Development efforts are required to adjust applications and scripts.
  • Coping with different package management mechanisms – RPM on CentOS, RHEL, and related distributions, PKG on Debian, and Ubuntu.
  • Time consumed and the risks associated with the migration process can, for example, require a complete system reinstall, given the difference between RHEL-based and Debian-based distributions.

Making the decision will have far-reaching implications and require extensive testing of both the operating system and the applications and workloads running on top. It should not be done hastily under penalty of finding some unsolvable issue a few months in the future that will force yet another migration. Your business would suffer twice, your IT teams would have to work double, and your users would not be happy with the downtime – again.

There is an alternative that can provide you with the time you need to plan correctly. If official vendor support is no longer available, replace it with a third-party support offering.

An extended support service offers patches for critical bugs and security issues that arise, protecting against vulnerabilities and eliminating the risk associated with running an End-of-Life operating system. Instead of receiving your patches from the CentOS vendor, you’ll receive them from the extended support service provider.

This way, you can, at your own pace, test and identify the correct Linux distribution to migrate to, all the while remaining protected and compliant.

TuxCare’s Extended Lifecycle Support (ELS) for CentOS 8 provides that support. Actually, TuxCare’s ELS has a faster patch availability time for important vulnerability fixes, with patches typically available within two working days instead of three for CVSS 7.5 or higher vulnerabilities. It also has 24/7 support available to assist in your Linux administration-related issues.

TuxCare extends CentOS 8 support for four more years beyond its announced end-of-life, essentially reducing the pressure on when to commit to an alternative – four more years to find an alternative rather than four more months.

If your organization is in this situation or is waiting to see which alternative distribution ends up being the best option, consider signing up for TuxCare’s ELS to buy yourself more time to make your choice. You will inevitably have to choose, and the question is if you want to decide yourself in your own time or be forced into a quick decision you may end up regretting.

You might also like