Linux patch management is the process of finding missing updates on your Linux servers, getting them from a trusted repository, installing them in a controlled order and proving afterwards that they were applied. In practice that means working with each distribution’s own package manager (dnf or yum, apt, zypper), its own advisory format and its own repositories, often across hundreds of servers and sometimes with no internet access at all.
This guide covers how patching works on RHEL and its rebuilds, Ubuntu and Debian, and SUSE. It also covers repositories and mirrors, kernel updates and reboots, offline and air-gapped Linux patching, and how to automate security patches without losing control.
What Linux patch management involves
Whatever the distribution, a Linux patch cycle has the same five steps:
- Scan. Find which packages and advisories each server is missing.
- Source. Make the updates available from a repository the server trusts, whether the vendor’s CDN or a local mirror.
- Approve and schedule. Decide what goes in, test it, and assign maintenance windows.
- Deploy. Install the updates and handle reboots or service restarts.
- Verify and report. Confirm what was installed, record failures and keep evidence for audits.
One distinction matters more than any other: advisory-level versus package-level patching. Enterprise distributions publish advisories (Red Hat’s RHSA, RHBA and RHEA errata, SUSE’s patches, Ubuntu Security Notices, Debian’s DSA and DLA). An advisory groups the packages that fix a problem and lists the CVEs it addresses. Package-level patching only tells you that openssl was updated. Advisory-level patching tells you that a specific advisory, and its CVEs, was remediated. Auditors and security teams usually ask the second question.
Why Linux patching is harder than it looks
Windows servers get most updates on a predictable monthly cycle from one vendor. Linux does not work that way, and the difference shows up quickly at enterprise scale.
- Distribution sprawl. Many estates run RHEL in production, Ubuntu in the cloud and a few older CentOS servers being moved to Rocky or AlmaLinux. Each has different repositories, commands and advisory formats.
- Unpredictable timing. Vendors release fixes when they are ready, not on a fixed day. Critical fixes can land at any time.
- Uneven advisory data. Some sources cover security and bug fixes; others only cover security. Third-party repositories often have no advisory metadata at all.
- Script drift. Linux teams are good at scripting, so patching often grows into a collection of cron jobs and shell scripts. They work until the person who wrote them leaves, or an auditor asks for a report.
- Connectivity. Servers in secure zones, plants and regulated networks often cannot reach vendor repositories, so every cycle depends on a local mirror.
The problem is rarely that administrators don’t care about patching. It is that patching several distributions by hand, at scale, is too much work to keep up with.
Patching by distribution: dnf, apt and zypper
| Family | Package tool | Advisory source | Security-only update | Reboot check |
|---|---|---|---|---|
| RHEL, Rocky, AlmaLinux, Oracle Linux, CentOS | dnf (yum on older releases) | Errata (RHSA, RHBA, RHEA and rebuild equivalents) | dnf upgrade --security | dnf needs-restarting -r |
| Ubuntu, Debian | apt | Ubuntu Security Notices; Debian DSA and DLA | Security pocket or unattended-upgrades | /var/run/reboot-required |
| SUSE Linux Enterprise | zypper | SUSE patches (SUSE-SU and others) | zypper patch --category security | zypper needs-rebooting |
RHEL, Rocky Linux, AlmaLinux and Oracle Linux
The Enterprise Linux family shares one model. Packages come from dnf repositories, and update metadata (updateinfo) links packages to errata. Use dnf updateinfo list --security to see missing security advisories, dnf upgrade --security to apply only those, or dnf upgrade --advisory=<ID> to apply one advisory. On RHEL 7 and CentOS 7 the equivalent commands run through yum.
RHEL content needs an active subscription. Rocky Linux and AlmaLinux are free rebuilds with their own repositories and advisories. Oracle Linux also publishes free errata. Because dnf records every transaction, dnf history and dnf history undo give you a rollback path, as long as the previous package versions are still in a repository you can reach.
If you still have CentOS servers, note that CentOS Linux 7 reached end of life on June 30, 2024. It no longer receives updates from the CentOS project, so those servers need a migration plan or another source of fixes.
Ubuntu and Debian
Ubuntu and Debian use apt. Run apt update to refresh package lists and apt list --upgradable to see what is pending. Security fixes are published to a separate security pocket, and the unattended-upgrades package can install them automatically. On Ubuntu servers it is typically set up for security updates out of the box.
For Ubuntu patch management at scale, the gaps are control and evidence. Unattended upgrades on every server means no staged rollout and no central record. Most enterprises stick to LTS releases, turn automatic installs off or limit them, and drive updates centrally. apt has no built-in transaction undo, so plan rollback through snapshots or by pinning previous versions.
SUSE Linux Enterprise Server
SUSE uses zypper and a patch-based model close to errata. zypper list-patches --category security shows what is missing and zypper patch --category security applies it. SLES is split into modules and extensions, each with its own repository. When you remediate an advisory, make sure every module and extension each server uses is mirrored and patched.
Amazon Linux and CentOS migrations
Amazon Linux follows the Enterprise Linux model (yum or dnf, with security advisories). Cloud instances often get patched through cloud-native tools, while on-prem servers use something else. That split is how coverage gaps appear. Treat cloud and data-center Linux as one estate with one patch policy and one report.
Repositories and mirrors
Pointing every server straight at the vendor CDN is the simplest setup. It is also the hardest to control. Each server can see whatever was published that morning, so test and production may end up installing different package versions.
Most enterprises put local repositories in the middle:
- Consistency. Test, staging and production install the same versions, because they all pull from the same synced content.
- Bandwidth. Remote sites download each package once from a nearby mirror instead of once per server.
- Rollback. Keeping older package versions in the mirror makes downgrades possible.
- Isolation. Servers never need outbound internet access, only access to the internal mirror.
Typical options are vendor tools (Red Hat Satellite, Canonical Landscape, SUSE’s management server and RMT), self-built mirrors (reposync and createrepo for dnf, apt-mirror or aptly for apt), or a patch platform that manages repositories for you. The common mistake with self-built mirrors is dropping the advisory metadata during sync. Without it you can still install packages, but you can no longer report by advisory.
Kernel updates, reboots and live patching
Most Linux updates take effect when the affected service restarts. Kernel updates, and updates to core libraries such as glibc, need a reboot to take effect. A server that installed a kernel fix but was never rebooted is still running the vulnerable kernel. Scanners will report it, and they will be right.
- Check reboot status after every cycle (
dnf needs-restarting -r,/var/run/reboot-required,zypper needs-rebooting) and report it, not just install status. - Schedule reboots inside the maintenance window, in sequence for clustered or load-balanced services.
- Keep at least one previous kernel installed so you can boot back if a new kernel causes problems.
Live patching (kpatch on RHEL, Canonical Livepatch, Oracle Ksplice, SUSE Live Patching) applies some kernel security fixes to the running kernel without a reboot. It buys time for systems that cannot restart often. It does not cover every kind of fix, and it does not replace regular reboots onto a fully updated kernel. Treat it as a way to stretch the interval between reboots, not to eliminate them.
Offline and air-gapped Linux patching
Servers in OT networks, defense, healthcare, finance and other secure zones often have no route to the internet. They still need patches, and the auditor still asks for proof. Offline Linux patching works when you build it around three parts: a local repository inside the isolated network, one controlled way to bring content across, and records of what was installed.
How to set it up
- Inventory what you must mirror. Every distribution, major version, architecture and (for SLES) module or extension that any isolated server uses.
- Sync on the connected side. Pull content from official vendor sources on a schedule, keeping advisory metadata and GPG signatures intact.
- Cross the gap one way. Use a single documented path into the isolated zone, whether a one-way transfer, a controlled sync window or approved media. Avoid ad-hoc USB copies.
- Verify before use. Keep package signature checking on (
gpgcheck=1for dnf, signed repositories for apt and zypper), so servers reject anything that was altered. - Serve internally. Point isolated servers only at the internal mirror, over HTTPS.
- Record everything. Missing advisories at the start of the cycle, approvals, what was installed where and when, and which servers failed.
The hidden cost is infrastructure. Building it yourself usually means a mirror server per distribution, sync scripts per repository, certificates per mirror and manual work to keep advisory metadata through each sync. Every new distribution or major version adds to the pile. If RHEL is your main platform, our guide to offline RHEL patching without Satellite compares Satellite, self-built mirrors and managed repositories in detail. For the broader picture across Windows and Linux, see air-gapped patch management.
How to automate security patches in Linux
Automation removes the manual effort and the missed servers. It should not remove control. A sound approach looks like this:
- Scan on a schedule and record missing advisories per server, not just pending package counts.
- Prioritize by risk. Weigh severity, exposure (internet-facing first) and business impact. Use vulnerability scanner findings to decide what goes first.
- Stage the rollout. QA first, then staging, then production, with success criteria before each stage moves on.
- Run inside maintenance windows tied to approved change requests, with rolling updates across clusters so services stay up.
- Check readiness first. Disk space, repository access and dependency conflicts cause most failed runs, so check them before the window opens.
- Plan rollback. Keep previous package versions available, record transaction IDs where the package manager supports them, and take snapshots where it doesn’t.
- Report automatically. Compliance by OS, environment and advisory, exported in a form auditors accept.
Configuration management tools such as Ansible, Puppet and Chef can run updates across many servers, and many teams start there. They give you execution, but scheduling, approvals, advisory-level reporting and repository management are left for you to build. For a closer look at the benefits and tradeoffs, see automating Linux patching: benefits and considerations.
Choosing a Linux patch management tool
| Approach | Good fit | Watch for |
|---|---|---|
| Native commands and scripts | Small estates, one distribution | No central reporting; scripts to maintain; hard to prove compliance |
| Vendor tools (Satellite, Landscape, SUSE’s management server) | Estates built mostly on one vendor’s Linux | One tool per vendor; Windows and Unix need something else |
| Configuration management (Ansible, Puppet, Chef) | Teams already automating with them | Approvals, reporting and repositories are your own work |
| Cross-platform patch platform | Mixed Linux, Windows and Unix estates; regulated or isolated networks | Check advisory-level support, local repository management and on-prem deployment |
Whatever you evaluate, ask these questions: Does it report by advisory and CVE, or only by package? Does it manage local repositories and work with no internet access? Does it support rollback? Can it run entirely on your own infrastructure? Can the same console cover your Windows and Unix servers?
How JetPatch helps
JetPatch Linux patch management patches RHEL, Rocky Linux, AlmaLinux, CentOS 7, Ubuntu LTS, Debian, SUSE Linux Enterprise Server and Amazon Linux from one console, using each distribution’s native package manager (yum, dnf, apt or zypper).
- Advisory-level patching. Enterprise Linux patches map to RHSA, RHBA and RHEA advisories with CVE references, so you can show which advisory was remediated.
- Local repository management. The Unified Linux Repository runs every distribution in its own container on a single Docker host, with an Nginx reverse proxy for HTTPS and cron-scheduled syncs from vendor sources.
- Air-gapped ready. Isolated servers pull packages from the local repository only, with no external connectivity needed during patching. JetPatch is installed software with no telemetry.
- Shorter windows and safer rollback. Optional pre-download stages patches before the window opens. Transaction-based rollback is supported for RHEL, Rocky, AlmaLinux, CentOS, SUSE and Amazon Linux (not currently Ubuntu or Debian).
- Governed rollouts and evidence. Remediation Plans with staged rollouts, maintenance windows and ServiceNow or Jira approval gates, plus CSV and PDF compliance reports.
The same console patches Windows Server and Unix (Solaris and AIX). For Windows, you can keep your existing WSUS, which JetPatch integrates with, or replace WSUS with the JetPatch repository.
FAQ
What is Linux patch management?
Linux patch management is the process of finding missing updates on Linux systems, sourcing them from trusted repositories, installing them in a controlled way and recording the result. In enterprises it covers several distributions, each with its own package manager and advisory format.
How can I automate security patches in Linux?
For a single server, dnf-automatic, unattended-upgrades or zypper can install security updates on a schedule. Across an enterprise, use a central tool that scans for missing advisories, stages rollouts from test to production, runs inside maintenance windows and reports the results. Keep a rollback plan for every cycle.
How do I install only security updates on RHEL or Ubuntu?
On RHEL, Rocky and AlmaLinux, run dnf upgrade –security, or dnf upgrade –advisory with a specific advisory ID. On Ubuntu, security fixes come from the security pocket, and unattended-upgrades can be limited to it. On SUSE, use zypper patch –category security.
Can you patch Linux servers without internet access?
Yes. Servers pull updates from a local repository inside the isolated network, and that repository is refreshed from vendor sources through one controlled path. Keep advisory metadata and package signatures intact so you can still verify packages and report by advisory.
Do Linux kernel updates require a reboot?
Yes. A new kernel only takes effect after a reboot. Live patching tools can apply some kernel security fixes to a running system, but they do not cover every fix, so regular reboots onto updated kernels are still needed.
What should a Linux patch management tool support?
Look for support for every distribution you run, advisory-level reporting with CVE references, local repository management for isolated sites, rollback and staged rollouts. If you also run Windows or Unix servers, one console for all of them reduces tool sprawl.
Want to see advisory-level Linux patching and local repositories on your own distributions? Request an evaluation and test JetPatch in your environment, connected or air-gapped.
