Subscribe to GEN
Login to GEN
CentOS Linux 7 reached end of life on 30 June 2024, and CentOS Linux 8 on 31 December 2021. A great many servers still run both, doing important work and receiving no security fixes. Most of our CentOS work is moving those servers in place to AlmaLinux, Rocky Linux or Red Hat Enterprise Linux, with their configuration, data and applications intact, rather than rebuilding them from nothing.
Where a server cannot move yet, we keep it running and contain it until it can. Service levels run from a next business day response to 30 minutes, 24 hours a day, every day of the year, from in-house UK engineers. There is no contract, no minimum term and no notice period: you buy hours at our published rates and draw against them.
For many years CentOS Linux was the natural choice for anyone who wanted Red Hat Enterprise Linux without the subscription. It was rebuilt from RHEL's own sources, so software written and certified for RHEL ran on it unchanged, and it was free to use in production. Hosting platforms, control panels, phone systems, appliances and countless in-house servers were built on it, which is why so much of it is still in service.
That model has ended. When a CentOS release reaches end of life, the mirror network stops serving it and its content moves to the vault at vault.centos.org, so an unmodified CentOS 7 server can no longer even run yum. More importantly, no further security fixes are published for it, whichever repository it points at.
CentOS Stream continues, but as a continuously delivered distribution that sits upstream of RHEL rather than a rebuild of it. It is a capable distribution in its own right, and suits people who want to see what is coming in RHEL, but it is not a like-for-like replacement for CentOS Linux on a server that is expected to stay put for years. For most CentOS estates the natural home is one of the RHEL compatible rebuilds, or RHEL itself.
CentOS calls have changed since end of life. Fewer are about a single fault, and more are about a server that has stopped being maintainable. These are the ones that arrive most often.
Could not retrieve mirrorlist or Cannot find a valid baseurl for repo on every yum command. The mirrors no longer serve CentOS 7 or 8, so the repository files need pointing at the vault, along with any third party repositories that have since moved or closed. That restores access to packages, not to security fixes, and we say so.
An ELevate or Leapp pre-upgrade report ending in inhibitors: kernel drivers the next release has dropped, SSH root login settings, unanswered questions in the answer file, or packages with no counterpart in the target. We work out why each one is there and resolve it, rather than forcing past it.
An application vendor that supports its software only on RHEL. Convert2RHEL moves the server onto RHEL in place, and we check the vendor's supported versions against the target before anything changes, so the answer is known first rather than discovered afterwards.
Applications that need a newer PHP, Python or OpenSSL than CentOS 7 provides, and connections that fail because the other end now demands TLS the old libraries cannot offer. Bolting newer versions on piecemeal usually makes the eventual move harder, so we plan the two together.
Phone systems, control panels and appliances built on CentOS, where the operating system belongs to the product. These follow the product's own upgrade path where one exists, and we support them where one does not. Telephony is covered under Asterisk and FreePBX support.
A security audit, an insurer's questionnaire or a customer assessment that has flagged an unsupported operating system. We give you a plan for each server, whether migrate, rebuild or contain until it can move, and a written record of the outcome.
The applications on top, from Apache, nginx and PHP-FPM to MariaDB, PostgreSQL and containers, are covered on our Linux support page. We support the operating system and the stack as one system, because that is how the fault behaves.
There are three serious destinations for a CentOS Linux server, and all of them are good ones. They share the same heritage, the same packaging and very largely the same behaviour, so the choice turns on governance, cost and what your software vendors support, rather than on technical merit.
Free to use in production, aiming for application binary compatibility with RHEL, and governed by the AlmaLinux OS Foundation, a non-profit with a community board. It is what we run on our own servers, and its migration tooling takes CentOS 7 and 8 across in place. See AlmaLinux support.
Free to use in production, built to be bug-for-bug compatible with RHEL, and run as a community project under the Rocky Enterprise Software Foundation. We rate it highly: we chose AlmaLinux for our own servers, but Rocky Linux is an equally sound home for a CentOS estate. See Rocky Linux support.
The original, sold by subscription with Red Hat's own support behind it, and the right choice where a vendor certifies only on RHEL or a contract requires vendor support for the operating system. Many organisations settle on a mixed estate: RHEL where certification demands it, a free rebuild elsewhere. See RHEL support.
Oracle Linux is also an ELevate target, and CentOS Stream suits development work and anyone following where RHEL is heading. We choose our partnerships carefully, and work only with vendors who leave us completely free in what we advise and recommend, so the recommendation for each server rests on what it runs and nothing else.
A rebuild means a new server, every application reinstalled, and weeks of finding out what the old one did that nobody wrote down. An in-place migration keeps the server's identity, configuration, data and applications, and replaces the operating system underneath them. For most CentOS servers that is the quicker, cheaper and less disruptive route, provided it is done with care.
From CentOS 7. The ELevate project, built on the Leapp upgrade framework, takes CentOS 7 in place to AlmaLinux 8, Rocky Linux 8 or Oracle Linux 8, and then onwards to 9. The repositories are pointed at the vault and the server brought fully up to date on the last CentOS 7 packages first, because Leapp expects a current system. Reaching a 9 series release is two upgrades rather than one, and we plan it that way: the server is verified and back in service on 8 before the second step is scheduled.
From CentOS 7 to RHEL. Red Hat's Convert2RHEL converts CentOS 7 to RHEL 7 in place, replacing the CentOS packages with Red Hat signed equivalents, after which Leapp upgrades RHEL to the later major versions. A RHEL subscription needs to be in place before it starts.
From CentOS 8. CentOS 8 converts in place to the same major version: AlmaLinux 8 with almalinux-deploy, Rocky Linux 8 with migrate2rocky, or RHEL 8 with Convert2RHEL. These are conversions rather than upgrades, and the move to 9 follows as a separate, planned step.
Every CentOS migration we carry out follows the same sequence, whatever the target. The tooling is well made; what decides the outcome is the preparation around it.
An inventory of the server: installed packages, enabled repositories, third party and hand-built software, kernel modules, storage, networking and what the business uses it for. Then the pre-upgrade report, run against the real system, so the risks are known before the window.
Leapp will not proceed while an inhibitor stands, and each one is resolved on its merits. A dropped driver may mean a hardware check, a third party package may need an equivalent in the target, and an SSH setting may need an explicit decision. We do not skip checks to get a clean report.
Nothing changes until a hypervisor snapshot or, on physical hardware, a full disk image has been taken and checked. A backup job reporting success is not the same thing, so we confirm the image can actually be used.
An agreed window, with the application owner available, a named engineer carrying out the work, and a decision point agreed in advance at which we roll back rather than press on into the working day.
Services started and tested, SELinux contexts, firewalld rules and network interfaces checked, logs read, and the application proven by the people who use it, all before the window closes.
If verification fails, the snapshot or image goes back and the server returns to service as it was. The upgrade is re-planned with what was learned, and a written record covers what was changed and what was found.
An in-place upgrade is the right answer for most CentOS servers, but not for all of them, and we will say so before the work starts rather than after it fails. A server that may have been compromised is never upgraded: its state cannot be trusted, and an upgrade would carry whatever is on it onto the new release. A server that is mostly hand-built software, or has been patched and modified for years outside the package manager, gives the upgrade tooling too little to work with. CentOS 6 and earlier have no practical in-place route to a current release at all.
A rebuild does not have to be a leap in the dark. We build the replacement on AlmaLinux, Rocky Linux or RHEL alongside the original, move the data and configuration across, test it in parallel, and cut over when it is proven, with the old server kept untouched as the way back.
Some servers cannot move yet: the application is waiting on its vendor, the hardware is due for replacement, or the budget is next year's. We support CentOS 7 and 8 for as long as that remains the sensible decision, and CentOS 5 and 6 as well. We are also straight about what it means. An unsupported operating system receives no security fixes. Every vulnerability found in its kernel, OpenSSL, OpenSSH or anything else it ships stays open for good, and no amount of care makes it patched. What care can do is reduce what it is exposed to.
Repository files pointed at vault.centos.org with the mirrorlist lines disabled, so yum works and dependencies resolve again, and the packages the server depends on copied locally so a rebuild does not rely on the vault staying where it is. It restores what was published, and nothing newer.
The server on its own network segment, away from desktops and from every system that has no reason to reach it, so a compromise there cannot travel far.
firewalld on the host and a firewall in front of it, both allowing only the connections the server genuinely needs, outbound as well as inbound.
Nothing published straight to the internet. Where users outside must reach it, a current, patched reverse proxy or VPN stands in front, so the old software is never the first thing an attacker meets.
Regular images of the server, verified by restoring them, so a hardware failure or an incident becomes a restore rather than a rebuild from memory.
Monitored by Oversight, and kept on a maintenance plan that keeps the move on the agenda rather than letting containment become permanent.
Containment is covered in more depth on our legacy system support page, alongside the other operating systems in the same position. If a CentOS server is down now, raise it on the HelpDesk.
CentOS Linux 7 reached end of life on 30 June 2024, and CentOS Linux 8 on 31 December 2021. Neither receives security fixes any more, and their packages have moved from the mirror network to the CentOS vault. GEN support both after end of life, and move them in place to AlmaLinux, Rocky Linux or RHEL.
After end of life the CentOS mirror network stopped serving CentOS 7, and its content moved to vault.centos.org, so an unmodified server fails with errors such as Could not retrieve mirrorlist or Cannot find a valid baseurl for repo. Pointing the repository files at the vault makes yum work again, but the vault holds only what was already published: it brings no new security fixes.
Yes. The ELevate project, built on Leapp, upgrades CentOS 7 in place to AlmaLinux 8, Rocky Linux 8 or Oracle Linux 8, and then onwards to 9, keeping the server's configuration, data and applications. GEN assess the server first, resolve every inhibitor, and image or snapshot it before anything changes, so there is always a way back.
Yes. Red Hat's Convert2RHEL converts CentOS 7 to RHEL 7 in place, after which Leapp upgrades RHEL to later major versions, and it converts CentOS 8 to RHEL 8. It needs a RHEL subscription, and is usually chosen where an application vendor certifies its software only on RHEL.
All three are sound, RHEL compatible homes for a CentOS server. AlmaLinux and Rocky Linux are free and community governed; RHEL is sold by subscription with Red Hat's own support behind it. The choice usually turns on what your application vendors certify and on cost. GEN run AlmaLinux on their own servers, rate Rocky Linux highly, and support all three.
Not a like-for-like one. CentOS Stream continues, but as a continuously delivered distribution that sits upstream of RHEL rather than a rebuild of it. It suits development work and anyone following where RHEL is heading; a server that is expected to stay put for years is usually better on AlmaLinux, Rocky Linux or RHEL.
An inhibitor is a problem found by Leapp's pre-upgrade check that is serious enough to stop the upgrade, such as a kernel driver the next release no longer includes, a setting whose default behaviour changes, or a question that needs an answer in the answer file. ELevate and Leapp will not continue until each is resolved. GEN resolve them on their merits rather than overriding the checks.
Not in the way a supported system is. CentOS 7 receives no security fixes, so every vulnerability found in it stays open. It can be run more safely by containing it: its own network segment, firewalling in both directions, no direct internet exposure, and verified images. GEN support CentOS for customers who cannot move yet, 24 hours a day with response times down to 30 minutes and no contract, and plan the move for when they can.
Our engineers are UK based and in-house, with no offshore outsourcing: the specialist who takes your case is the specialist who works it, and they hold the production experience to match the equipment in front of them. Risk is assessed before anything is changed, the SAPR method is applied to every fault, and five shifts a day mean an overnight handover is a conversation between two engineers rather than a note left in a ticket. Our AI runs on our own hardware in our own data centres, and it never writes a word you read.
There is no support contract, no minimum term and no notice period. You buy hours at our published rates, use them when you need them, and what you do not use carries over. How GEN support works sets all of it out in full.
