CentOS Patch Management — Best Practices & Automation

CentOS sits in an awkward place in the Linux landscape. The classic stable-clone CentOS Linux is end-of-life — version 7 stopped getting updates in June 2024, version 8 ended in 2021 — and CentOS Stream, the rolling upstream-of-RHEL successor, isn’t the same product most teams adopted. Many production fleets still run CentOS 7 in places nobody has had budget to migrate, and many have already moved to Rocky Linux or AlmaLinux. Patch management has to account for all of these states at once.

This page covers the actual commands for patching CentOS hosts, the migration paths to Rocky and AlmaLinux, what dnf-automatic and yum-cron give you, and where a fleet-aware tool like SysWard fits.

Core CentOS Patching Commands

The package manager moved from yum (CentOS 7) to dnf (CentOS 8 and later, including Stream). The commands have parallel shapes but differ in defaults and output. The CentOS 8+ / Stream flow:

# List available updates
sudo dnf check-update

# Apply all updates
sudo dnf upgrade -y

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

# Check whether a reboot is required (exit 1 if yes)
sudo dnf needs-restarting -r

On CentOS 7, the equivalent is yum:

sudo yum check-update
sudo yum update -y
sudo yum --security update -y
sudo needs-restarting -r

dnf upgrade and dnf update are aliases on modern releases. --security filters to advisories tagged as security; --bugfix and --enhancement filter to those categories. Combine with --cve <CVE-ID> to apply the package that addresses a specific CVE.

For one-off package upgrades: sudo dnf upgrade <package> (or yum update <package> on 7). To roll back a specific upgrade, sudo dnf history shows the transaction list and sudo dnf history undo <id> reverses the named transaction.

CentOS 7 EOL: What Still Works

CentOS Linux 7 reached its end-of-life on June 30, 2024. After that date there are no more official patches — the upstream repos still exist but no new advisories flow through them. Servers still running CentOS 7 in 2026 are running against a frozen package set; the workflow is identical to before EOL, but yum check-update will only show updates that were published before June 2024.

A few realities of life on CentOS 7 post-EOL:

• Existing packages still install from the official mirrors and the EPEL repo, but neither receives new security advisories for CentOS 7.
• Third-party ELS programs (TuxCare, others) provide paid extended support for CentOS 7 with their own update channels. If you can’t migrate immediately, this is the bridge that keeps the host patchable.
• Migration to Rocky or AlmaLinux is the long-term answer for most fleets. Both ship in-place migration scripts that swap the repo configuration without rebuilding the host.
• CentOS Stream is not a 1:1 successor for the stable-clone model. It’s the upstream of RHEL, not a downstream rebuild. Teams that ran CentOS for its stability profile usually move to Rocky or AlmaLinux instead.

Migrating to Rocky Linux or AlmaLinux

Both Rocky and AlmaLinux ship migration scripts that convert a CentOS Linux installation to their respective distros in place. The Rocky Linux flow:

# As root, from a CentOS 8 / 8 Stream 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

AlmaLinux’s almalinux-deploy is structurally similar. Both scripts rewrite the repo configuration, swap a handful of distro-identifying packages, and run a dnf distro-sync to align with the new distro’s package versions. The installed application versions are largely preserved — the goal is to keep your workload running, not to rebuild it.

Before running either migration:

1. Take a snapshot of the VM, or a full backup of a bare-metal host. Migrations are usually clean, but “usually” isn’t “always.”
2. Confirm third-party repos (EPEL, Remi, vendor repos) have packages compatible with the target distro. EPEL works against Rocky and Alma directly. Some vendor repos pin to RHEL only — verify before migrating.
3. Pilot on a non-critical host first. The script handles edge cases well, but kicking the tires on staging before production is cheap insurance.

The migration covers CentOS 8 / 8 Stream → Rocky 8 / AlmaLinux 8 and CentOS 9 Stream → 9. For CentOS 7, the upgrade path involves either an in-place ELS migration tool or a clean reinstall onto a newer major release.

Automating with dnf-automatic

dnf-automatic is the DNF-era replacement for yum-cron. It applies updates on a systemd timer with no central coordination. Configuration lives in /etc/dnf/automatic.conf:

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

[emitters]
emit_via = stdio

[base]
debuglevel = 1

Enable the timer:

sudo systemctl enable --now dnf-automatic.timer
sudo systemctl list-timers dnf-automatic.timer

For CentOS 7, yum-cron is the equivalent and lives in /etc/yum/yum-cron.conf with knobs for update_cmd = security and apply_updates = yes.

The trade-off with dnf-automatic is the same as with unattended-upgrades on Debian/Ubuntu: it applies updates correctly per host, but it has no fleet view. You can’t easily answer “are all production hosts pointed at the security pocket and actually running the timer?” without an external tool walking every host.

Patching Cadence and Maintenance Windows

A workable cadence for a CentOS / Stream / Rocky / Alma fleet looks like:

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.
2. Routine updates monthly in a defined change window. Roll through staging before production; the package manager’s transaction history gives you a clean rollback path if something breaks.
3. Kernel and glibc upgrades on a reboot window. dnf needs-restarting -r flags hosts that need a reboot to pick up new code. Fleet-wide reboot tracking is where per-host tooling stops being enough.

The exact cadence depends on your compliance posture and tolerance for risk, but the three-track structure holds across most production environments.

How SysWard Fits

SysWard treats CentOS, CentOS Stream, Rocky Linux, and AlmaLinux as a unified fleet. The agent inventories packages on each host, matches them against live CVE feeds, and surfaces what’s exploitable on which hosts. During a CentOS-to-Rocky migration window, both distros sit in the same view, which makes it easier to confirm the migrated hosts pick up the right patches afterward.

The pieces that matter for fleet CentOS-family patching:

• One fleet view across CentOS 7, Stream, Rocky, and Alma — no separate dashboards per distro.
• CVE matching against installed packages, not against a generic advisory list. A CVE in httpd doesn’t show up on a host where httpd isn’t installed.
• Group rollouts for staging-before-prod patching, regional rollouts, and held groups during a freeze window.
• Audit trail capturing every patch event — host, package, before/after version, actor — for SOC 2 / PCI-DSS evidence.
• Migration visibility during a CentOS-to-Rocky transition: both source and destination hosts in the same inventory.

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

Ready to automate this?

SysWard handles CentOS, Stream, Rocky, AlmaLinux, RHEL, Ubuntu, and more from one dashboard — start free for 2 servers, no card required. See also Rocky Linux patch management and Red Hat patch management for distro-specific guidance, or Linux patch management for cross-distro fundamentals.