Some of the most critical systems in your infrastructure are also the oldest. If you operate in energy, manufacturing, or government, chances are you have hosts still running Red Hat Enterprise Linux 5 or CentOS 5. Not because anyone forgot to upgrade them, but because upgrading them is not an option. The OS is frozen by compliance requirements, tied to certified industrial equipment, or locked to software that would break on anything newer.
Those hosts still generate logs. Your security team still needs them. Your auditors still ask for them. And until now, collecting them meant workarounds: syslog relays, custom scripts, or simply accepting a blind spot.
With the just-released NXLog Agent 6.15, RHEL 5 and CentOS 5 are now officially supported platforms. You install it, enroll it in NXLog Platform, and manage it like any other endpoint in your fleet.
Why RHEL 5 still matters in 2026
Red Hat ended standard support for RHEL 5 in 2017. Yet these systems persist in production for reasons that have nothing to do with negligence:
- Compliance-frozen environments
-
In regulated industries, a validated system configuration can be expensive to re-certify. Changing the OS means repeating audits, revalidation, and downtime the business cannot absorb.
- OT and industrial control systems
-
Equipment vendors certify their software against a specific OS version. Upgrading the OS voids the certification, or breaks the software outright. Your expensive hardware sits idle simply because the controller cannot run anymore.
- Hardware and software dependencies
-
Some applications do not run on newer kernels or libraries, and replacing them means replacing the hardware and processes around them. Manually working around this, more often than not, leads to broken systems or unmaintainable franken-builds, which in turn leads to more breakage you are not monitoring.
These environments are often the ones with the strictest logging requirements. The systems you cannot patch are exactly the systems you need to watch most closely.
What NXLog Agent 6.15 delivers
NXLog Agent 6.15, out now, brings RHEL 5 and CentOS 5 into the officially supported platform list. Support came directly from customer requests: organizations in regulated environments asked for it, and the release ships with those scenarios verified.
Installation works the way you would hope: take a standard 64-bit (x86_64) RHEL 5 or CentOS 5 system, install the NXLog Agent RPM, and you are done. No dependency hunting, no compatibility shims, no custom builds.
Because RHEL 5 predates the libraries current software depends on, NXLog Agent for these systems is a dedicated legacy build. It ships with a focused subset of the modules available on modern platforms rather than the full catalog. That subset still covers what most teams reach for: local file and syslog collection, the common forwarding protocols, and the core processing modules. For the complete list of supported modules and the latest details, see the RHEL installation page in the documentation.
Within that scope, NXLog Agent behaves the way it does on any supported Linux version:
-
Local log collection from files, syslog, and other system sources.
-
Parsing and forwarding to NXLog Platform, your SIEM, or any other destination NXLog Agent supports.
-
The same configuration language you already use across the rest of your Linux fleet: no special dialect, no separate tooling.
In NXLog Platform, it is just another agent
This is where legacy support stops being a checkbox and starts saving you work. Once enrolled, a RHEL 5 host appears in the NXLog Platform agents view alongside your modern systems: the same status monitoring, the same remote management, the same configuration deployment.
From one central console you can:
-
Monitor agent status, events per second, memory, and CPU load.
-
Deploy and update configurations remotely, with no SSH sessions into fragile legacy boxes.
-
Apply the same collection policies you use everywhere else.
The OS version becomes a footnote in a column, not a barrier to visibility. Your 2007-era host gets the same treatment as the machine you provisioned last week.
Close the gap before your next audit
If part of your infrastructure has been unreachable for log collection, this release removes the excuse. You get:
- Coverage for compliance
-
Compliance frameworks do not exempt old systems from logging requirements. Now you can meet them without complex workarounds.
- Visibility where risk is highest
-
Unpatched, internet-isolated systems still fail, get misconfigured, and get targeted. Their logs are how you find out.
- One pipeline instead of two
-
Retire the scripts and relays you built to work around the gap. One NXLog Agent, one management plane, every OS generation.
NXLog Agent 6.15 with RHEL 5 and CentOS 5 support is available now, so the legacy hosts you could not reach before can finally join the same logging pipeline as the rest of your fleet.
