Red Hat Patch Management — RHEL Patching Without Satellite

Red Hat Enterprise Linux (RHEL) ships one of the most structured security advisory feeds in the Linux ecosystem. Every update in BaseOS and AppStream is tagged as a Security Advisory (RHSA), Bug Fix Advisory (RHBA), or Enhancement Advisory (RHEA), complete with severity ratings and mapped CVE identifiers. On a single server, dnf can filter by advisory type, severity, or individual CVE out of the box.

Where teams get stuck is fleet coordination. Red Hat’s first-party answer is Red Hat Satellite, which brings content views and repository mirroring at the cost of a dedicated server footprint, Smart Management licensing, and a RHEL-only worldview. If your infrastructure mixes RHEL 8, 9, or 10 with Rocky Linux, AlmaLinux, Ubuntu, or SUSE, running Satellite still leaves half your fleet outside the console.

This guide covers the native dnf workflow on RHEL, subscription and Extended Update Support (EUS) mechanics, dnf-automatic timers, kernel live patching with kpatch, and how to run a unified Linux patch management process across RHEL and non-RHEL hosts without operating Satellite. For a command-order runbook on a single host, see RHEL patching step by step.

Four ways to patch RHEL, compared

Core RHEL Patching Commands with dnf

On RHEL 8, 9, and 10, dnf (Dandified YUM) is the package manager and yum is a compatibility symlink to it. Before trusting dnf output on a RHEL host, always confirm that the subscription and repositories are active — an unregistered RHEL machine reports zero available updates and looks clean while falling months behind on RHSAs.

# 1. Confirm registration and enabled repositories
sudo subscription-manager status
sudo dnf repolist

# 2. Summarize and list pending security advisories (RHSAs)
sudo dnf updateinfo summary
sudo dnf updateinfo list --security
sudo dnf updateinfo list --security --sec-severity=Critical

# 3. Apply all security advisories, or only the minimum version that fixes them
sudo dnf upgrade --security -y
sudo dnf upgrade-minimal --security -y

# 4. Apply a single CVE or RHSA out of band
sudo dnf upgrade --cve CVE-2026-12345 -y
sudo dnf upgrade --advisory RHSA-2026:1234 -y

# 5. Check whether the update requires a system reboot or service restart
sudo dnf needs-restarting -r
sudo dnf needs-restarting -s

Two details separate RHEL’s dnf behavior from Debian/Ubuntu’s apt:

• Advisory-driven filtering is native. Because Red Hat’s repository metadata (updateinfo.xml) maps every package build to an RHSA, RHBA, or RHEA, dnf upgrade --security installs only packages referenced by a security advisory. You can further narrow the run with --sec-severity=Critical or --sec-severity=Important when operating under an emergency change window.
• upgrade vs upgrade-minimal. If openssl has three newer builds in the repository — one fixing an RHSA and two later RHBA bug-fix releases — dnf upgrade --security jumps to the newest build of openssl, whereas dnf upgrade-minimal --security stops at the exact build that resolves the security advisory. During production freezes, upgrade-minimal minimizes unexpected behavior changes.

For legacy RHEL 7 systems running under Extended Life Cycle Support (ELS), the equivalent commands use yum and yum-plugin-security (sudo yum updateinfo list security, sudo yum update --security -y), and needs-restarting -r comes from the yum-utils package.

Subscription Management, EUS, and Repository Hygiene

Most “RHEL host missed a critical patch” incidents trace back to subscription or repository state rather than dnf itself:

1. Simple Content Access (SCA) and expired certificates. Even with SCA enabled in the Red Hat Hybrid Cloud Console, a host whose local entitlement certificate failed to refresh (rhsmcertd stopped, or outbound HTTPS to subscription.rhsm.redhat.com blocked) silently stops seeing new errata. Monitoring subscription-manager status across the fleet is mandatory.
2. BaseOS and AppStream both matter. RHEL 8+ splits the OS into rhel-9-for-x86_64-baseos-rpms (kernel, glibc, systemd, OpenSSH) and rhel-9-for-x86_64-appstream-rpms (runtimes, web servers, databases, tools). If AppStream is disabled or pointed at a stale mirror, userland CVEs in PostgreSQL, Nginx, or Python go unpatched while kernel updates continue to land.
3. Extended Update Support (EUS) minor-release locking. Production clusters that pin a specific minor release (for example, RHEL 9.4 EUS) use sudo subscription-manager release --set=9.4 and enable the *-eus-rpms repositories. If a team locks the release version without switching to the EUS repos, the host stops receiving updates the day RHEL 9.5 ships. Conversely, when EUS ends for that minor stream, the release lock must be cleared (subscription-manager release --unset) or advanced to the next EUS release.
4. Third-party repositories (EPEL, vendor repos). Packages installed from EPEL or vendor repositories may not publish updateinfo security metadata. If your automated job only ever runs dnf upgrade --security, packages from repositories without advisory metadata will never be upgraded until a full dnf upgrade runs in a maintenance window.

Automating Single-Host Updates with dnf-automatic

For unattended per-host patching between maintenance windows, RHEL provides dnf-automatic. Unlike Debian’s unattended-upgrades, dnf-automatic ships multiple systemd timer units whose behavior overrides or complements /etc/dnf/automatic.conf:

sudo dnf install -y dnf-automatic

Configure /etc/dnf/automatic.conf to restrict unattended runs to security advisories:

[commands]
upgrade_type = security
random_sleep = 300
download_updates = yes
apply_updates = yes

[emitters]
emit_via = stdio

Then enable the timer that matches your operational policy:

# Downloads and installs updates according to upgrade_type in automatic.conf
sudo systemctl enable --now dnf-automatic-install.timer

# Inspect timer schedule and recent run logs
systemctl list-timers 'dnf-automatic*'
journalctl -u dnf-automatic-install.service --since "7 days ago"

Be careful with the unit names: dnf-automatic-download.timer only downloads packages, dnf-automatic-notifyonly.timer only emits notifications, and dnf-automatic-install.timer forces installation regardless of apply_updates in the config file.

While dnf-automatic works well on a handful of standalone servers, its limits show up quickly in production fleets:

• No cross-host staging: Every server with the timer enabled pulls from the repository on the same day. If an upstream package introduces a regression, staging and production take the hit together.
• No service restart or reboot orchestration: dnf-automatic updates packages on disk, leaving running daemons linked against deleted shared libraries (needs-restarting -s) and kernels waiting for a reboot (needs-restarting -r).
• No centralized audit evidence: Proving to a SOC 2 or PCI DSS auditor that 80 RHEL hosts patched a critical CVE within SLA requires scraping /var/log/dnf.log or dnf history across every machine.

Kernel Updates, Reboots, and kpatch Live Patching

A kernel or glibc update installed by dnf sits inert on disk until the system reboots. After every patch run, check both levels of restart state:

# Exit 1 if kernel, glibc, systemd, dbus, or linux-firmware changed since boot
sudo dnf needs-restarting -r

# List systemd units whose processes still map old shared libraries
sudo dnf needs-restarting -s

When an OpenSSL or libcurl update lands without a kernel change, restarting the services listed by dnf needs-restarting -s (for example, sudo systemctl restart nginx sshd) completes remediation immediately with zero host downtime.

For hosts where reboot windows are weeks apart, RHEL supports kernel live patching via kpatch. Live patch modules (kpatch-patch-*) splice function replacements into the running kernel in memory:

sudo dnf install -y kpatch kpatch-dnf
sudo dnf kpatch auto
sudo dnf upgrade --security -y
sudo kpatch list

Keep two constraints in mind: kpatch only covers Red Hat-selected Critical and Important kernel CVEs, and each kpatch-patch package is built for an exact uname -r kernel release within a supported minor stream. Live patching bridges the gap until your next scheduled maintenance window — it does not eliminate periodic reboots.

Rollback and Version Locking with dnf history

Before rolling patches across production RHEL servers, document the rollback path. dnf records every transaction in /var/lib/dnf/history.sqlite:

# List recent transactions with user, date, and altered package count
sudo dnf history list

# Inspect the exact before/after NEVRA versions in transaction 42
sudo dnf history info 42

# Revert transaction 42 (downgrades updated packages, removes newly installed deps)
sudo dnf history undo 42 -y

If a specific package must be held back across the fleet while an application team validates a breaking change, use the versionlock plugin rather than skipping security updates altogether:

sudo dnf install -y python3-dnf-plugin-versionlock
sudo dnf versionlock add postgresql-server
sudo dnf versionlock list

Always pair a version lock with an expiration date in your change tracker so pinned packages do not silently accumulate CVEs for quarters.

Red Hat Satellite vs Lightweight Fleet Patch Management

Red Hat Satellite (built on Foreman, Katello, Pulp, and Candlepin) was designed for a specific problem: managing hundreds or thousands of RHEL-only servers in environments that mirror Red Hat’s CDN locally and promote frozen content views through Dev, QA, and Production.

For many infrastructure teams today, Satellite is the wrong shape for three reasons:

1. Mixed-distro reality: Production estates rarely run 100% RHEL. Cost-sensitive workloads run on Rocky Linux or AlmaLinux, cloud-native workloads run on Ubuntu or Amazon Linux, and legacy workloads sit on CentOS or SUSE. Satellite only manages Red Hat-family systems.
2. Operational overhead: Running Satellite means patching, backing up, and upgrading a heavy control plane (PostgreSQL, Pulp content storage, Foreman Ruby/Dynflow workers) and optional Capsule servers per network segment.
3. Licensing cost: Satellite requires Red Hat Smart Management subscriptions on top of your RHEL base entitlements.

If you are evaluating alternatives to Satellite or migrating off legacy Spacewalk, our guide on Red Hat Satellite and Spacewalk alternatives for mixed Linux fleets compares Uyuni, SUSE Multi-Linux Manager, Foreman with Katello, and SaaS/self-hosted options in detail.

How SysWard Patches RHEL Fleets

SysWard gives you centralized RHEL patch management, live CVE correlation, and compliance evidence without running a Satellite server:

• Package-level CVE matching: The SysWard agent reports every installed RPM (name, epoch, version, release, arch) and pending dnf updates, correlating them against Red Hat security data and NVD feeds. See Linux vulnerability management for how findings are ranked.
• Security-only or full updates by group: Organize RHEL, Rocky, AlmaLinux, Ubuntu, and Debian hosts into environment groups (dev, staging, prod-eu) and schedule maintenance windows so staging patches days before production.
• Reboot and lock visibility: Hosts where needs-restarting -r exits non-zero are flagged in the dashboard, and package locks (versionlock) can be managed without SSH-ing into individual machines.
• Audit-ready history: Every patch job records the initiating user, start/end timestamps, package versions before and after, and any failure output — ready to export for SOC 2 and PCI DSS compliance.
• SaaS or self-hosted appliance: Run against SysWard’s cloud control plane or deploy the self-hosted appliance inside your private network behind an HTTP/HTTPS proxy.

SysWard’s free tier includes 5 servers with every feature enabled — start free, no credit card required.