Why CentOS 7 is a problem now

Why CentOS 7 is a problem now

CentOS 7 is out of support. There are no more security fixes, and the public repositories were moved to an archive. The next serious vulnerability will not be patched for CentOS 7, and if you handle card data you will fail PCI DSS on patch timeliness and EOL remediation.

This picks up from a server you can already reach over SSH. It stands alone if you landed here from search.

Before you start

• CentOS 7 reached end of life on 30 June 2024. The CentOS project says this directly. After that date there are no more updates. Its mirrors were removed from mirror.centos.org and archived on vault.centos.org. Those vault repos exist for reference. They do not receive fixes.
• Real‑world impact: the OpenSSH “regreSSHion” bug (CVE‑2024‑6387) was disclosed on 1 July 2024. Red Hat shipped fixes for supported RHEL on 3 July 2024. CentOS 7, being EOL, received no official update. This is what EOL looks like in practice.
• Compliance impact: PCI DSS v4.0 requires critical patches within one month (Requirement 6.3.3). It also requires that you document vendor EOL and have an approved remediation plan for outdated tech (Requirement 12.3.4). That plan became a mandatory control on 31 March 2025. As of today, CentOS 7 is more than two years past EOL. You cannot meet 6.3.3 without vendor patches, and running CentOS 7 without a documented and executed remediation plan conflicts with 12.3.4.
• There is no paid “ELS” for CentOS 7. Red Hat offered an Extended Life Cycle Support add‑on for RHEL 7.9 customers through 30 June 2028. That applies to RHEL 7.9 only. It does not cover CentOS 7.
• How long you realistically have: if the system is internet‑facing, you are on borrowed time. The next pre‑auth remote flaw can hand over root. If you are in PCI scope, the answer is “you are already late”. Treat migration as work to schedule now.
• Hostworld context: if you run your VPS with us, you manage it in Virtualizor from our client area. You can deploy a new AlmaLinux 9 or Ubuntu 24.04 VPS, or rebuild an existing VPS to a supported OS, then use the VNC console if you need out‑of‑band access. If you need help at any point, open a support ticket and we will look at your VPS with you.

Step 1: Decide where you are moving to

Your two stable target platforms on our Linux VPS line are AlmaLinux 9 and Ubuntu 24.04 LTS. Pick the one your applications support best and that your team is comfortable with.

• AlmaLinux 9 has security maintenance through May 2032, according to the AlmaLinux project.
• Ubuntu 24.04 LTS has standard maintenance to May 2029. Extended Security Maintenance runs to May 2034, and a Legacy add‑on runs to May 2039.

If you want the closest continuity from a RHEL‑like environment, AlmaLinux 9 is a straightforward choice. If your tooling expects Ubuntu, 24.04 LTS gives a long runway.

Step 2: Choose migration approach

You have two routes. Fresh build and migrate services and data. Or in‑place major upgrade.

• Fresh build is the cleanest. Deploy a new VPS on AlmaLinux 9 or Ubuntu 24.04, bring services up there, test, then cut over. This avoids years of drift and lets you retire CentOS 7 with confidence.
• In‑place upgrade is possible from CentOS 7 to AlmaLinux 9, but it is a two‑step path using the AlmaLinux ELevate tooling: CentOS 7 to AlmaLinux 8, then AlmaLinux 8 to AlmaLinux 9. A direct multi‑major jump is not supported. Skipping the CentOS 7 repo switch to a vault mirror stalls the process. Expect to handle third‑party and EPEL packages, and to remove leftover el7 packages before the 8 to 9 step.

Red Hat’s Leapp guidance, which ELevate builds on, is clear: run a pre‑upgrade analysis, expect “inhibitors” that intentionally stop unsafe upgrades, and have a full, restorable backup. Common blockers include active NFS mounts during upgrade, LUKS‑encrypted devices, and insufficient GRUB embedding space on BIOS‑boot systems. Problems created by an in‑place major upgrade may require a clean reinstall to fix. Plan with that in mind.

If you can, prefer a fresh build. If you must upgrade in place, slow down, back up, and test the upgrade path on a clone.

Step 3: Build a new VPS on a supported OS

In Hostworld, deploy or rebuild your VPS in Virtualizor to AlmaLinux 9 or Ubuntu 24.04. Keep the CentOS 7 server up while you prepare the new one so you can test before cutover.

Update the new server fully

Run a full system update so you start from the latest patched state.

• AlmaLinux 9: this refreshes repository metadata and upgrades all installed packages.

sudo dnf upgrade -y

• Ubuntu 24.04: this updates the package index and then upgrades all packages, including kernel updates.

sudo apt update
sudo apt full-upgrade -y

Check what OS you are on

Confirm the new server is running the OS you expect. This helps avoid migrating onto the wrong base.

• AlmaLinux 9: this prints the operating system name and version from the standard release file.

cat /etc/os-release

• Ubuntu 24.04: this does the same on Ubuntu.

cat /etc/os-release

Prepare to copy data

Plan what to migrate: application files, configuration, logs you must retain, and databases. For files, rsync over SSH is reliable. For databases, use your database’s native export and import process as appropriate for your stack, then validate on the new server.

Example file copy using rsync. This preserves permissions and copies only differences:

• AlmaLinux 9: this synchronises a directory from the old host to the new host over SSH. Replace placeholders with your details.

rsync -avz -e "ssh -p 22" [email protected]:/path/to/data/ /path/to/destination/

• Ubuntu 24.04: same command and behaviour on Ubuntu.

rsync -avz -e "ssh -p 22" [email protected]:/path/to/data/ /path/to/destination/

Recreate services and test

Recreate your services on the new server and test them while traffic still points to the old one. Confirm that logging, backups and monitoring work on the new OS. When you are happy, plan your cutover window. Update DNS or your load balancer to direct users to the new server.

If you host with us and want a second VPS for the migration window, you can order a London VPS here: Linux VPS. You manage the VPS lifecycle in Virtualizor from our client area.

Step 4: If you must upgrade CentOS 7 in place

If a fresh build is not possible, follow the two‑step path documented by the AlmaLinux project. Do not attempt a direct 7 to 9 jump.

1. Back up in a way you can restore. Take a full, restorable backup and verify it. Plan how you will roll back if the upgrade leaves the system unbootable. Red Hat’s own guidance notes that some issues created by a major in‑place upgrade require a clean reinstall to resolve.
2. Switch CentOS 7 YUM to a vault mirror. Because the normal CentOS 7 repos are offline, the ELevate guide instructs switching YUM to use an archived vault repo first. They provide an el7.repo file for this. Skipping this step stalls the upgrade because required packages will not resolve.
3. Run the ELevate pre‑upgrade checks and fix inhibitors. Expect the process to stop you if it detects unsafe conditions. Common examples include active NFS mounts, LUKS‑encrypted devices, or insufficient GRUB embedding space on BIOS‑boot systems. Clear these before proceeding.
4. Perform the 7 to 8 transition. Follow the ELevate documentation for the CentOS 7 to AlmaLinux 8 step. Reboot when prompted and validate that the system comes back, services start, and the package set is consistent.
5. Clean up el7 leftovers and third‑party repos. ELevate calls out handling of EPEL and removing leftover el7 packages before the 8 to 9 step. Resolve these so the next transition is not blocked.
6. Perform the 8 to 9 transition. Use the documented AlmaLinux 8 to 9 ELevate path. Reboot and retest thoroughly.
7. Update fully on the new OS. Once you land on AlmaLinux 9, bring the system current:

• AlmaLinux 9: this upgrades all packages on your now‑AlmaLinux 9 host.

sudo dnf upgrade -y

• Ubuntu 24.04: not applicable to an AlmaLinux in‑place upgrade. For completeness, if you rebuilt to Ubuntu instead, bring it current as shown earlier.

If anything blocks you during planning or testing, open a support ticket. Tell us what you have tried and where it failed. We will review options for your VPS and help you choose a safe path.

Step 5: Re‑check security posture and compliance

Once you are on a supported OS, patch cadence is back in your control.

• AlmaLinux 9: bring the host up to date and schedule regular updates.

sudo dnf upgrade -y

• Ubuntu 24.04: bring the host up to date and schedule regular updates.

sudo apt update
sudo apt full-upgrade -y

Document the move in your PCI materials if you are in scope. Requirement 6.3.3 is met when you install critical patches within one month of release, which you can now do because vendor fixes exist. Requirement 12.3.4 expects you to review technology at least annually, document vendor EOL, and have an approved plan to remediate. Your migration is that remediation. Keep the record.

Why this matters, in plain terms

• No fixes after EOL. CentOS 7 has had no security updates since 30 June 2024. The OpenSSH regreSSHion bug on 1 July 2024 was a pre‑auth RCE. Supported platforms received coordinated patches within days. CentOS 7 did not. That pattern will repeat.
• Archived repos are a dead end. The move from mirror.centos.org to vault.centos.org preserves history. It does not provide fixes. You cannot patch your way out of EOL on CentOS 7.
• Compliance deadlines are real. PCI DSS v4.0’s one‑month patch window and the EOL remediation control are both active. CentOS 7 is now a compliance problem, not a theoretical one.
• There is no CentOS 7 ELS. Buying time is not an option on CentOS. Red Hat’s ELS only covered RHEL 7.9.

What next

If you want a clean start, deploy a new VPS on AlmaLinux 9 or Ubuntu 24.04 and migrate on your schedule: Linux VPS. Manage power, rebuilds, VNC console and ISO mounting in Virtualizor from the Hostworld client area.

For broader context and related tasks, see our VPS guides. If you hit a blocker at any point, open a support ticket so we can review your VPS and advise on a safe path.

The next step in this playbook is to plan your cutover and rehearse it. Write down the order you will stop services, copy the last changes, and update DNS or the load balancer. Then test it on a quiet window.