TuxCare ELS: Continuing to Support Older Linux Versions in a Controlled Manner

What TuxCare Adds to ELS

When regular maintenance for a Linux distribution ends, a server will not necessarily continue to receive security updates from the previous package sources. This is particularly problematic if a specialized application is still tied to the old environment. Extended support can provide time for a controlled transition without reversing the end of regular support.

TuxCare Endless Lifecycle Support for OS provides security updates and selected bug fixes for supported older distributions. According to the vendor, the offering includes the kernel and a distribution-specific selection of important packages. It does not install a new major version of Linux: The server remains on its current distribution version and receives additional maintenance for the covered components.

This can be an important interim solution for operations: Instead of having to immediately migrate an incompatible application, you can prepare for the migration while applying available security patches for the supported packages. However, this requires that the packages actually needed, the architecture, and the chosen solution are compatible.

The Package Cover This is not the same as ensuring the security of the entire server. An application, extension, or service that you install yourself from a different package source may fall outside the scope of the operating system. Configuration errors and unnecessarily exposed services are not eliminated by a subscription; they must still be checked and secured.

The severity level is also relevant for covered packages: TuxCare provides security fixes for high and critical risks with a CVSS score of 7 or higher. For medium risks with a CVSS score between 4.0 and 6.9, the provider states that patches may be considered if no mitigation is available and there is sufficient customer demand. TuxCare also reserves the right to offer a mitigation instead of a direct code fix. A covered package therefore does not mean that every known vulnerability within it will be fixed.

Therefore, it is not just a matter of whether the distribution is on a support list. For Linux Security It identifies which components are in use on a specific server, whether appropriate patches are available, and whether they have actually been installed. ELS complements the patching process but does not replace either the inventory or a migration plan.

Check Coverage and Server Inventory

Before choosing TuxCare ELS, there is a Server Inventory. Record the distribution, exact version, architecture, and currently running kernel. Also document the configured package sources and any services accessible publicly or from other networks. This allows you to compare the list of vendors with the actual system, rather than just checking off the name of the distribution.

For an older web server, for example, the inventory should include the web server package, cryptographic libraries, the PHP runtime, and any required PHP extensions. For each item, note where the package comes from and which version is installed. An extension from a third-party repository may have different maintenance requirements than a package from the original distribution.

Compare these components individually with the current package list for the distribution in question. Also check the architecture and the terms of the intended offering. A supported distribution does not mean that every package installed on it or every version of a runtime is automatically covered by ELS for OS. Even for covered packages, the handling of individual vulnerabilities depends, among other things, on their severity.

Programs you’ve compiled yourself and separately installed runtime environments are particularly easy to overlook. A container image also comes with its own components: Maintaining the host operating system does not guarantee that the packages in the image are up to date. For such components, you need separate verification and a dedicated update process.

ELS for OS and ELS for Applications are separate offerings. Whether an older PHP version can be maintained through an additional offering depends, among other things, on the version, package format, architecture, and distribution channel. The article on CloudLinux Alt-PHP and Its Security Features; this means it is not covered by a TuxCare OS subscription.

Understanding Support Timeframes Correctly

The end of support is only meaningful in the context of the respective maintenance phase. The end of regular maintenance does not always mean that all paid or supplemental services end at the same time. To make an informed decision, you should therefore note both the time period and the packages, architectures, and contract terms covered.

The currently available TuxCare documentation specifies a guaranteed ELS runtime for supported operating systems of 25 years as of the respective original end-of-support date specified. As examples, it lists June 30, 2049, for CentOS 7 and May 31, 2048, for Ubuntu 18.04. These are the vendor’s specifications regarding the support period; they do not constitute a guarantee for every installed application.

For Ubuntu 18.04, Canonical distinguishes between several phases: Standard support ended in May 2023; Ubuntu Pro is supported through May 2028. The current overview lists May 2033 for additional legacy coverage. These offerings cannot be compared solely based on their end dates, as the package scope, architecture, and contract terms for the specific server are also important factors.

For example, with an Ubuntu web server, check whether the required packages are actually included in the selected maintenance release and how the updates fit into the existing operational process. A longer timeframe is of little help if a critical runtime or extension falls outside the agreed scope.

The deadlines listed are based on dynamic manufacturer websites as of November 4, 2026. It is not always possible to verify retroactively whether all current information was already in effect as of that date. Therefore, please check the deadlines and package lists again before publication or signing a contract, and keep the respective Number of retrievals That's for sure. Even a long-term support commitment is no guarantee of an overall secure server.

Setting Up a CentOS 7 Server in Practice

Suppose a CentOS 7 web server needs to continue running an older line-of-business application temporarily. Before you TuxCare ELS By selecting this option, you capture the actual system status and the application's dependencies. The key factor is not only whether CentOS 7 is supported, but also whether the required components for the existing architecture are covered.

You can run the following commands in a shell on the server. They retrieve the distribution identifier, the machine architecture, and the version of the running kernel; they do not modify any packages or package sources. Record the output in the server inventory and compare it with the current CentOS 7 guide.

cat /etc/os-release
uname -m
uname -r

Add this Server Inventory configured package sources, installed package versions, and publicly accessible services. For a web server, this includes, in particular, the web server package, cryptographic libraries, the PHP runtime, and extensions. Also note which components come from third-party sources or were compiled in-house; they must not be considered part of the OS coverage without verification.

For CentOS 7, TuxCare lists a valid license key, root access, and HTTPS connections as prerequisites. The guide also distinguishes between architectures: It describes userspace coverage for aarch64 and i686, but kernel live patching only for x86_64. This limitation applies to the CentOS 7 guide and cannot be generalized to other distributions.

Next, for the specific application, check each required package against the current list and resolve any remaining gaps with the respective vendor. Even a supported, running kernel does not, in and of itself, guarantee that the application is supported or that all available updates are installed and active.

Set Up a Repository and Roll Out Updates

Plan the setup as a controlled Test Chain: First, make sure the license, architecture, and required packages are compatible. Next, verify that the server is allowed to access the targets required for its distribution via HTTPS. For registration and repository setup, follow the current, distribution-specific official instructions, as prerequisites and target addresses may change.

For CentOS 7, TuxCare describes how to register the system, add the package source, and add a PGP key. The repository then allows you to obtain the appropriate packages; however, it does not automatically install all available updates. After setup, check to make sure the repository is integrated as expected and that the package manager offers the appropriate updates.

A proxy or restrictive outbound firewall rules must be taken into account during planning. For multiple systems, a local mirror may be an option after consultation with TuxCare. Do not blindly copy destination addresses from a general FAQ: Before deployment, verify them against the current documentation for the selected distribution and the intended deployment method.

First, test available updates in a test environment that is as similar as possible to the production environment for the business application. During this process, verify the application’s startup, key business processes, and interfaces. Afterward, proceed with operational approval and installation on the production system; document the package versions, timing, and results, rather than simply marking the successful repository activation as the final step.

If an expected update isn't available yet, also check the Rollout Status. For multiple platforms, TuxCare releases updates in stages; after publication in the stable repository, this may take up to 14 additional days. If necessary, the provider describes a workaround: Use it only in accordance with the current instructions for the respective distribution and specific release, and only after operational approval. The rollout duration does not imply a guaranteed total timeframe for a patch.

Also, have a fallback plan and an appropriate maintenance window in place. License keys do not belong in published sample commands, tickets, or unprotected logs. For the actual registration, you should follow the manufacturer’s current instructions and provide access credentials only through the designated procedures.

A Comparison of Maintenance Options

The choice between TuxCare ELS and extended vendor support depends on the actual package inventory and the terms of the contract. The table provides examples for preliminary selection; it is not a general commitment for every architecture or package. The research date is November 4, 2026; the dynamic vendor information and package lists must be rechecked prior to publication.

Standard support for Ubuntu 18.04 ended in May 2023. Canonical lists support for Ubuntu Pro through May 2028 and, in its current overview of additional legacy coverage, through May 2033. TuxCare currently lists May 31, 2048, as the ELS end date for Ubuntu 18.04. These dates describe different offerings; a later end date does not automatically imply the appropriate package coverage.

Therefore, compare the Scope of Maintenance for each required package and the architecture actually used. For Ubuntu, the Main and Universe components—as well as the requirements for Pro and a potential Legacy add-on—are particularly relevant. Also note how available CVE fixes can be verified and whether the existing release and update processes align with the offering.

In both examples, the migration target remains a planning decision, not a feature of the maintenance contract. If the line-of-business application is not yet operational on a supported platform, a suitable maintenance alternative can provide time for testing. If none of the offerings address a critical dependency, this gap must be addressed separately before continued operation can be justified.

Check CVE reports and backports

If a scanner continues to report a vulnerability after an update, first check the exact distribution and version, as well as the name, architecture, and installed version of the affected package. Also determine which package source it comes from. A finding for a distribution package cannot be readily applied to a self-compiled application or a package from a third-party repository.

The reason for apparent contradictions may be a Backport be: In this case, a security fix is incorporated into an older development branch without its visible upstream version number matching that of the latest release. An older version number alone therefore does not prove that the package is vulnerable, nor that the scanner's report must be incorrect.

Compare the specific CVE and the installed package version with the information for your distribution in the TuxCare CVE Tracker. „In Testing“ means that a fix is still being tested; „In Rollout“ means it is being distributed via rollout repositories. „Released,“ on the other hand, indicates that the fix has been fully released to all users. Even then, you must verify that the correct version has actually been installed; „Not Vulnerable“ means that the TuxCare version is not affected.

If an expected update is missing from the package manager, check not only the package source and version but also the Rollout Status. For multiple platforms, staggered distribution following publication in the stable repository may take up to 14 additional days. A potential bypass may only be incorporated into the process in accordance with the current, distribution- and release-specific original instructions and upon operational approval; this does not result in a guaranteed total patch timeframe.

Next, examine the scanner’s database and analysis. TuxCare provides OVAL data for a range of ELS products; you must verify for yourself whether your tool is using the correct data for the specific system and interpreting it correctly. Document the package version, CVE status, and scan time. If the comparison remains unclear, continue to treat the finding as open and clarify it with the relevant departments or the vendor.

Scheduling Patch Operations and Restarts

Setting up a repository is the beginning of the patching process, not the end. Determine who will regularly check for available updates, who will approve them, and how failed updates will be detected. Compare the package versions that are actually installed with the available updates and record any discrepancies for each system.

Whenever possible, test updates first on a comparable test system running the same application and using the relevant package sources. In particular, test the startup, login, and key interfaces of the line-of-business application. Only after receiving operational approval should you roll out the packages in a controlled manner; the results and any errors should be documented in the installation report.

Also, plan for changes Maintenance window. Even after a successful package update, running processes may still use old libraries until they are restarted. Applications may also need to be restarted; a system reboot may be required if kernel changes are involved. After the reboot, verify both the service functionality and the expected package and operating status.

KernelCare Live Patching is a complementary product and should be distinguished from regular ELS package updates. It can apply supported kernel patches while the system is running, but it does not replace all updates or every service or system restart. Check the product, distribution, and architecture: For CentOS 7, TuxCare documents kernel live patching only for x86_64. Further basics are explained in the article on KernelCare Patch Feed.

The issue of uname -r shows the currently running kernel, but not the server's complete update status. For example, an installed kernel package may not become active until after a reboot; conversely, the output does not indicate whether libraries and applications have been updated and restarted.

Choose a temporary solution or migration

Whether TuxCare ELS is sufficient for a specific server depends on that server’s actual components and risks. Compare the required packages with the available coverage and identify any gaps in applications, runtime environments, and third-party software. ELS for OS covers a distribution-specific selection; support for the operating system does not imply maintenance for every application running on it.

Also check for any remaining CVE vulnerabilities within the packages covered. According to TuxCare, medium-risk vulnerabilities are only considered for a patch under additional conditions; furthermore, the vendor may provide a mitigation rather than a direct code fix. Therefore, for each specific vulnerability, assess whether a fix or a mitigation is available and whether the remaining risks are acceptable for your operations.

A temporary solution may be appropriate if a line-of-business application is currently tied to the old platform and the remaining risks are manageable. However, also consider the manufacturer’s available maintenance options: For Ubuntu 18.04, depending on your needs, Ubuntu Pro and, if necessary, the Legacy add-on are viable alternatives. Review the packages, architecture, and contract terms—not just the respective end date.

For a publicly accessible service with an unmaintained application or an unsupported runtime, ELS alone may not be sufficient. Therefore, limit access to only those networks and services that are actually needed, remove unnecessary permissions, and monitor administrative access. These Network Limitation It reduces the attack surface, but does not replace missing security updates.

Keep the continued operation temporary and define a migration goal, including the responsible parties and a verifiable deadline. Plan application tests on the target platform, the data migration, and the verification of all relevant interfaces. A fallback plan should specify the conditions under which you would abort the migration and how you would revert to the previous operating state.

Review the plan regularly in light of new package vulnerabilities, changes in vendor dependencies, and operational overhead. If required components can no longer be maintained or if necessary access cannot be sufficiently restricted, simply extending the operating system support period may not be sufficient. In such cases, migration, application replacement, or controlled decommissioning must be reevaluated.