Linux servers for business

A business ends up with Linux servers for ordinary reasons. An application required it, a developer built something on it, a phone system or a monitoring tool shipped as a Linux appliance. Nobody made a strategic decision; machines accumulated.

The question that then arrives — which distribution should we standardise on — is the one most discussed and the one that matters least. Every mainstream option is technically capable of running a business workload.

What decides whether a Linux estate is an asset or a liability is duller: how long the release you chose is supported, whether the people here can administer it confidently, and whether anything ensures it is still being patched three years after the person who built it moved on.

Lifecycles, because they differ enormously

Linux distributions differ far more in support duration than in capability, and the difference directly determines how often you will be rebuilding servers.

Red Hat Enterprise Linux delivers a ten-year life cycle across three production phases, structured as five years of Full Support followed by five years of Maintenance Support. Beyond that, an Extended Life Cycle add-on can extend eligible releases by up to six further years, taking supported life to fourteen years or more on eligible minor releases.

Ubuntu LTS releases arrive every two years and receive five years of standard security maintenance. An Ubuntu Pro subscription extends that: years six to ten through expanded security maintenance covering both the Main and Universe repositories, and years eleven to fifteen through a legacy add-on.

The practical consequence is a planning one. A five-year cycle means rebuilding or upgrading roughly every four years to stay comfortably inside support. A ten-year cycle means doing it half as often. For an estate of a few servers that difference is minor; for one of thirty it is a recurring project.

Choosing, honestly

Four factors decide this, and none of them is a technical merit argument.

The first is worth checking before anything else. Many commercial applications certify against specific distributions and versions, and running outside that list means the vendor may decline to support a problem — which is exactly when you need them.

The second matters more than businesses expect. The two mainstream families differ in package management, service configuration, firewall tooling and default security frameworks. Someone fluent in one is competent but slower in the other, and slower under pressure is where mistakes happen.

A general recommendation, stated as a default rather than a rule: standardise on one distribution and one release across the estate unless a specific application forces otherwise. Mixed estates multiply the patching work, the tooling and the knowledge required, and they do it permanently.

The operational practices that decide the outcome

A Linux server that is built well and then ignored is worse than a Windows server that is patched, because the ignoring is easier — nothing prompts, nothing nags, and it keeps working for years while accumulating unpatched vulnerabilities.

Patching that happens without anyone remembering

1. 1

   Enable automatic security updates

   Both mainstream families provide a mechanism for applying security updates unattended. For most business workloads this is the correct default: the risk of an update causing a problem is lower than the risk of a server sitting unpatched for a year.

2. 2

   Separate security updates from everything else

   Automatic security updates are a different proposition from automatic feature updates. Take the first automatically, schedule the second.

3. 3

   Decide the reboot policy explicitly

   Kernel and core library updates need a restart to take effect. A server patched but never rebooted is still running the vulnerable code. Either schedule restarts or use live patching where the distribution supports it, but decide which.

4. 4

   Monitor for servers that stop updating

   The failure mode is silent: a repository becomes unreachable, a disk fills, an update fails and the mechanism stops. Alert on last-successful-update age, not on update failures.

Access, which is where the findings are

• Disable password authentication for SSH and use keys. Password authentication on an internet-reachable server is subjected to continuous automated guessing.
• Disable direct root login. Administration should be through a named account with elevation, so actions are attributable to a person.
• Do not share a service account between people. It defeats every audit trail downstream.
• Remove access on departure, on the servers as well as in the directory. Keys placed on individual machines outlive directory accounts.
• Keep the host firewall on with a default-deny inbound policy. A server that only needs to serve one port should only accept one port.

The keys point deserves emphasis because it is the common gap. SSH keys are frequently added directly to individual servers, which means there is no central list of who can log into what. Offboarding then misses them, and the access persists silently. Centralised authentication, or at minimum a managed and audited key distribution, is what makes revocation reliable.

The things that quietly break servers

• Disks filling. Logs and package caches grow, and a full root filesystem takes down services in confusing ways. Monitor free space with enough warning to act, not at ninety-five percent.
• Time drift. Certificate validation, authentication and log correlation all depend on accurate time. Ensure NTP is running and actually synchronised, which is not the same as configured.
• Undocumented local changes. A configuration edited by hand at 2am and never recorded is the reason the rebuild does not work. Configuration management is the structural answer; a written change log is the minimum one.
• Services installed and forgotten. Anything listening that nothing uses is attack surface with no benefit.

Backup, specifically for Linux

The general principle applies here as anywhere: a backup that has never been restored is an assumption. Two Linux-specific points are worth adding.

First, backing up a database by copying its files while it is running produces a copy that may not be consistent and may not restore. Databases need their own dump or snapshot mechanism, quiesced properly, and that is a different job from the filesystem backup.

Second, what makes a Linux server valuable is usually the configuration rather than the operating system, and the configuration is scattered across the filesystem. A rebuild from a base image plus a data restore only works if the configuration is captured somewhere — which is the strongest practical argument for configuration management even in a small estate.

When Linux is the wrong answer

Being direct about this matters, because Linux is frequently chosen for licence savings by businesses that cannot support it.

• If nobody in the business can administer it and no support arrangement is in place, the licence saving is being converted into an outage risk.
• If the workload is a Windows application, virtualising Windows on a Linux hypervisor to avoid a Windows licence does not avoid the guest licence.
• If the estate is otherwise entirely Windows with centralised management, adding a small number of Linux machines means a second set of tooling, patching and monitoring for a handful of servers.

The reverse also holds. Where the workload is naturally Linux — web platforms, most open-source infrastructure, containers, telephony — running it on Linux administered by people who know Linux is straightforwardly correct, and the licence saving is a genuine benefit rather than a deferred cost.