Rocky Linux Patch Management — CVE-Aware Fleet Updates

Rocky Linux arrived as the community-led answer to Red Hat’s decision to convert CentOS Linux into the upstream-of-RHEL Stream model. It’s a bug-for-bug RHEL clone, freely distributed, with a release and support cadence that mirrors Red Hat’s. For fleets that ran CentOS Linux for its stability profile, Rocky is the closest like-for-like successor — and that means the patching workflow is the same shape as on RHEL or any other downstream rebuild.

This page covers the actual dnf commands for patching Rocky, how it fits next to RHEL and AlmaLinux in a mixed fleet, the migration paths from CentOS, and where SysWard fits on top.

Core Rocky Linux Patching Commands

The Rocky patching workflow is identical to RHEL’s because the package manager and repo layout are intentionally identical. The four commands that matter:

# Refresh the package metadata and list available updates
sudo dnf check-update

# Apply all available updates
sudo dnf upgrade -y

# Apply only security advisories
sudo dnf upgrade --security -y

# Check whether a reboot is required after the update
sudo dnf needs-restarting -r

dnf upgrade and dnf update are aliases. The --security flag filters to advisories tagged as security; --bugfix and --enhancement filter to those categories. To target a specific CVE, --cve <CVE-ID> applies only the package that addresses it.

For one-off package upgrades: sudo dnf upgrade <package>. The transaction history is your rollback path:

sudo dnf history                 # list transactions
sudo dnf history info <id>       # what changed in a transaction
sudo dnf history undo <id>       # reverse it

RHEL Compatibility and Mixed Fleets

Rocky’s compatibility goal is bug-for-bug parity with RHEL. In practical terms:

• Packages built for RHEL run on Rocky without modification, and vice versa.
• Repo layouts are equivalent — BaseOS, AppStream, PowerTools / CRB, EPEL on top.
• Subscription mechanics differ — Rocky doesn’t require subscription-manager, and there’s no Red Hat customer portal to register against.

For mixed Rocky/RHEL fleets, this compatibility means a single patch management workflow covers both. The same dnf upgrade --security runs on both, the same CVE feed matches the installed packages on both, and the same group rollouts work across both. The differences are operational: Red Hat customers have access to RHEL’s official errata feed and Red Hat Insights; Rocky users rely on the Rocky errata team and community channels.

Migrating from CentOS to Rocky

Rocky ships migrate2rocky.sh for in-place migration from CentOS Linux 8 / 8 Stream. The basic flow:

# As root, on a CentOS host
curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh
chmod +x migrate2rocky.sh
sudo ./migrate2rocky.sh -r
sudo reboot

What the script actually does: swaps the CentOS repo configuration for Rocky’s, replaces a handful of distro-identifying packages (release packages, branding), and runs dnf distro-sync to align package versions with Rocky’s current point release.

Before running it:

1. Snapshot the VM or take a full backup of bare-metal hosts. Migrations are usually clean, but the recovery path matters more than the success path.
2. Confirm third-party repos have packages compatible with Rocky. EPEL works directly. Some vendor repos pin to RHEL only — check before migrating.
3. Pilot on a non-critical host first. The script handles edge cases well; running it once on staging exposes the ones that affect your specific package mix.

For CentOS 7 (which reached EOL in June 2024), there’s no in-place upgrade to Rocky 8 — the path is a clean reinstall onto Rocky 8 or 9. For CentOS 9 Stream → Rocky 9, the same migrate2rocky.sh flow applies with -r (or the equivalent for 9).

Automating with dnf-automatic

dnf-automatic is the per-host automation primitive. Install and enable:

sudo dnf install -y dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

Configuration lives in /etc/dnf/automatic.conf:

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

[emitters]
emit_via = stdio

The systemd timer triggers it daily by default. Logs go to the journal:

journalctl -u dnf-automatic.service --since "24 hours ago"

Like every per-host automation tool, dnf-automatic applies updates correctly on the box it runs on but offers no fleet-wide picture. To answer “are all Rocky hosts in production picking up security updates on the right cadence?” you need an external inventory.

Patching Cadence and Maintenance Windows

A workable Rocky patching cadence has three tracks running in parallel:

1. Security advisories within days for critical CVEs, within weeks for the rest. dnf-automatic handles per-host application; central inventory confirms the fleet picture matches what the policy says it should be.
2. Routine updates monthly in a defined change window, rolling through staging before production.
3. Kernel and glibc upgrades on a reboot window. dnf needs-restarting -r flags hosts pending a reboot. Fleet-wide reboot tracking is where per-host tooling stops being sufficient.

Major version upgrades (Rocky 8 → 9) are their own change event. Rocky doesn’t ship a sanctioned in-place 8 → 9 upgrade path — the standard approach is a clean reinstall onto 9, restoring from configuration management. Pilot on a non-critical host first, and time the move to align with the 8.x EOL schedule.

Common Pitfalls

• Stale dnf cache: dnf upgrade works against the local metadata cache. dnf clean expire-cache forces a refresh if you suspect a stale view.
• EPEL drift: if EPEL is enabled, its packages can sometimes outpace the base repos and create conflicts. Pin EPEL to the appropriate release if you hit this.
• Locked packages: dnf versionlock (from the dnf-plugins-core package) pins a version. Same problem as apt-mark hold on Debian — easy to set, easy to forget.
• Reboot debt: hosts that never reboot stack up kernel updates that aren’t running. A monthly reboot window prevents the surprise outage.
• Mixed CentOS / Rocky inventory during migration: tracking which hosts are on which distro during a multi-month migration is most of the operational risk. Central inventory is the only reliable way.

How SysWard Fits

SysWard treats Rocky, AlmaLinux, RHEL, and CentOS Stream as one fleet. The agent inventories packages on each host, matches them against live CVE feeds, and surfaces what’s exploitable across the lot. Rollouts run via the local dnf with group scheduling, hold windows, and audit logging that per-host tools don’t provide.

For Rocky fleets specifically:

• One view across Rocky, RHEL, and AlmaLinux — no separate dashboards per RHEL-family distro.
• CVE matching against installed packages — a CVE in httpd only shows up on hosts where httpd is installed.
• Group rollouts for staging → prod, regional rollouts, and held groups during a freeze window.
• Migration visibility during a CentOS → Rocky transition: both distros appear in the same inventory, which makes confirming post-migration patch state straightforward.
• Audit trail for every patch event — host, package, before/after versions, actor.

For more on the CentOS-to-Rocky decision, the CentOS to Rocky Linux migration post on the blog covers the trade-offs and timeline.

Ready to automate this?

SysWard handles Rocky Linux alongside RHEL, AlmaLinux, CentOS Stream, Ubuntu, Debian, and SUSE from one dashboard — start free for 2 servers, no card required. See also CentOS patch management and Red Hat patch management for closely-related distro workflows.