TuxCare ELS for CentOS 7: keep cPanel servers patched past EOL

CentOS 7 reached end of life on 30 June 2024. Nearly two years later, a large share of cPanel servers in production still run it — every host that ever sold an "old-school stable" plan, every reseller box that nobody wants to touch, every server with a kernel-mode driver that won't recompile cleanly on EL9. None of those servers are getting security updates from upstream.

TuxCare Extended Lifecycle Support (ELS) for CentOS 7 plugs that gap. It is a paid backport stream that keeps the kernel and the userspace stack — glibc, OpenSSL, OpenSSH, Python, GCC, and a curated list of around 80 packages — patched against CVEs for a contracted period after the distro's official EOL. This article walks through what ELS actually covers, how to wire it onto a CentOS 7 cPanel server, and the math on whether it's worth buying versus finishing the migration to AlmaLinux on cPanel.

What ELS for CentOS 7 actually covers

ELS is not "just KernelCare for CentOS 7". The KernelCare component is bundled, but the value sits in the userspace.

The covered package list, as of the current contract year:

• Kernel — the EL7 3.10 series, via KernelCare live patches
• glibc — Heartbleed-class concern; every long-lived service uses it
• OpenSSL 1.0.2 — the EL7 default, far below upstream
• OpenSSH server and client
• Python 2.7 and 3.6 — both reached upstream EOL years ago
• GCC runtime libraries (libstdc++, libgcc)
• Bash, sudo, util-linux, systemd, NSS, curl, expat, libxml2
• Apache httpd and nginx as shipped in the CentOS repos (not EasyApache 4's httpd — see below)
• MariaDB 5.5 / 10.x as shipped by CentOS

What ELS does not cover:

• EasyApache 4 — Apache, PHP, and modules installed by EA4 are cPanel's responsibility and patched through cPanel's own update channel as long as your cPanel license is active. ELS does not touch them.
• MySQL/MariaDB installed by cPanel — same story. cPanel ships its own RPMs.
• Imunify360, JetBackup, CSF, and other third-party hosting stack — patched by their respective vendors.
• Custom-compiled software under /opt or /usr/local.

In practice this is the right division of responsibility. The CentOS base OS gets ELS; the hosting stack on top stays on its existing patch streams.

When ELS is the right call

ELS is a runway product, not a destination. Three scenarios where it pencils out:

1. You are mid-migration off CentOS 7 and need to keep the remaining servers safe for the 6–18 months it takes to drain them. The licence is roughly the cost of one engineering day; the audit and incident exposure of running unpatched EL7 in 2026 is much higher.
2. A specific server cannot be migrated — proprietary kernel module, a Plesk install with an extension that hasn't shipped an EL9 build, a legacy customer app that won't survive a PHP version jump. ELS lets that one server stay safely on EL7 indefinitely.
3. Compliance requires "vendor-supported OS" — PCI-DSS 4.0, HIPAA, ISO 27001 audits all increasingly want to see an active support contract for the OS. ELS is the supported-OS contract for CentOS 7 past EOL.

If none of those apply, finish the migration. Paying for ELS on a server you could have already moved is paying twice — for the migration eventually, and for the ELS subscription each year until you do.

Step 1 — Verify the server is on a supported CentOS 7 minor

ELS targets the final CentOS 7.9 point release and the kernels that shipped with it. Check:

cat /etc/redhat-release
uname -r

You want CentOS Linux release 7.9.2009 (Core) and a 3.10.0-1160.x.x.el7 kernel. Older 7.6/7.7 builds need a yum update to roll forward to 7.9 against the CentOS Vault repos before ELS is registered — TuxCare's repository expects the 7.9 base.

If yum update against vault.centos.org is broken (it often is — repos move around), point the base repos at a working mirror first:

sed -i 's|^mirrorlist=|#mirrorlist=|g' /etc/yum.repos.d/CentOS-*.repo
sed -i 's|^#baseurl=http://mirror.centos.org|baseurl=https://vault.centos.org|g' /etc/yum.repos.d/CentOS-*.repo
yum clean all
yum update -y

Step 2 — Install the TuxCare repository and agent

The unified TuxCare repo handles ELS, KernelCare, and Extended Support for PHP from a single installer. One command:

curl -s -L https://repo.tuxcare.com/script/els-7-setup | bash

This drops tuxcare-els.repo into /etc/yum.repos.d, installs the GPG key, and pulls in the kcare package. The installer is idempotent — re-running it is the recommended way to repair a half-broken repo.

Step 3 — Register the licence

If you bought ELS directly from TuxCare, register with the activation key from the portal:

kcarectl --register ACTIVATION-KEY-HERE

If you activate ELS through a reseller and the licence is IP-locked (the model used when you enable TuxCare ELS via panellicense), no key is needed — the agent contacts the activation server and pulls down its entitlement against your server's public IP:

kcarectl --update

The first sync downloads the kernel patchset and registers your server with TuxCare's CVE feed. It typically takes 20–60 seconds.

Step 4 — Enable userspace patching

The userspace half is what makes ELS different from a bare KernelCare licence. It runs as a separate daemon — libcare-ctl — and patches glibc, OpenSSL, and OpenSSH into running processes without a service restart.

yum install libcare -y
systemctl enable --now libcare
libcare-ctl info

The info output lists every patched process by PID and shows which userspace CVEs have been applied. Long-lived processes — Exim, Dovecot, PHP-FPM workers, the cPanel daemon itself — pick up the patch in-place; new processes start against the patched libraries automatically.

Step 5 — Pull the userspace package backports

The other half of userspace ELS is RPM-level backports for the curated package list. These look like normal yum update operations against the TuxCare repo:

yum --enablerepo=tuxcare-els check-update
yum --enablerepo=tuxcare-els update

The first command lists what's available — typically two to six packages with active CVE patches at any given moment. The second installs them. Hosts on a normal patch cadence should put this command on a weekly cron.

Step 6 — Verify CVE coverage

Run the bundled scanner to confirm there are no open CVEs against the kernel or the covered userspace packages:

kc-prod-scanner -v

A clean run reports No vulnerabilities found. If anything shows up, it's almost always one of:

• The userspace daemon isn't running — systemctl status libcare
• A long-lived process started before the patch was applied and hasn't been restarted (some patches require a process restart; the scanner flags it)
• A package outside the ELS list (typically EasyApache or a third-party RPM) — patch through its own channel

What ELS costs versus migrating

Rough industry pricing for ELS for CentOS 7 sits in the $100–200/server/year range at retail, with volume discounts from resellers pulling it lower for fleets of 20+. KernelCare alone (kernel only, no userspace, no package backports) is cheaper — around $45–65/server/year — but it is not a substitute for ELS once you care about glibc and OpenSSL.

Compare against migration cost:

For a fleet you plan to migrate within 12 months, ELS is a 12-month insurance policy — buy it, finish the migration, drop the renewal. For a fleet you cannot migrate (compliance, legacy customer apps, kernel module dependencies), ELS becomes a permanent line item.

Common mistakes

1. Buying ELS instead of KernelCare on a server you've already migrated to AlmaLinux. ELS is the EL7-EOL product. On AlmaLinux 8 or 9 you want a KernelCare licence, not ELS.
2. Assuming ELS patches EasyApache PHP. It does not. PHP coverage is a separate TuxCare product — Hardened PHP via CloudLinux, or standalone TuxCare ELS for PHP for non-CloudLinux servers.
3. Forgetting libcare. Installing only kcare gives you kernel patches but no userspace coverage. Confirm libcare-ctl info reports patched processes after registration.
4. Letting the CentOS Vault repos stay broken. A server that can't yum update against the vault can still install the TuxCare repo, but RPM-level ELS backports won't apply cleanly. Fix the base repos first.

FAQ

Next steps

• If migration is the plan and ELS is the bridge, work through the CentOS 7 to AlmaLinux migration on cPanel so you know what's waiting on the other side.
• For the kernel-only subset of what ELS covers, see KernelCare live patching on cPanel — the install steps overlap, but the licensing is different.
• TuxCare ELS, KernelCare, and the bundled CloudLinux options sit on the licensing pricing page — pick the SKU that matches the OS the server will be on six months from now.