← Back to Articles

Linux Patch Management: RHEL, Ubuntu, and CentOS Strategies

January 7, 2024•Patch Management•4 min read

It's 2 AM and a critical CVE just dropped affecting the kernel running on 400 of your production servers. Half run RHEL 9, a quarter are on Ubuntu 22.04, and the rest are CentOS Stream boxes you inherited from a team that no longer exists. How you handle the next few hours depends entirely on the patch management strategy you built before this moment. Let's build that strategy now.

The Core Challenge: Heterogeneous Fleets

Most enterprise environments aren't running a single distribution. Mergers, team preferences, and application requirements create mixed fleets — and each distribution handles package management, repository structure, and update cadences differently. A mature patch management strategy must account for all of them without creating three entirely separate workflows.

The goal is a unified policy with distribution-specific execution.

RHEL: Leveraging Satellite and DNF

Red Hat Enterprise Linux offers the most opinionated enterprise patching ecosystem. If your organization has RHEL subscriptions, Red Hat Satellite (or the upstream Foreman/Katello) is the cornerstone.

Pin content views to control rollout timing:

# Create a content view snapshot for Q1 patches
hammer content-view publish --name "RHEL9-Production" --organization "YourOrg"

# Promote to dev first, then staging, then production
hammer content-view version promote --content-view "RHEL9-Production" \
  --to-lifecycle-environment "Dev" --organization "YourOrg"

On individual hosts, dnf provides granular control:

# Apply only security errata
sudo dnf update --security

# Check which advisories are available
sudo dnf updateinfo list --sec-severity=Critical

Key strategy: Use content view snapshots as "gates." Dev gets patches on day one, staging after three days of soak time, and production after seven. This mirrors a change management process auditors love.

Ubuntu: APT, Unattended-Upgrades, and Livepatch

Ubuntu's approach leans on unattended-upgrades for automated security patching and Canonical's Livepatch service for rebootless kernel fixes.

Configure unattended-upgrades for security-only patches:

# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    // Deliberately exclude -updates to avoid non-security changes
};
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Mail "secops@yourcompany.com";

For kernel patching without downtime:

sudo canonical-livepatch enable YOUR_TOKEN
sudo canonical-livepatch status --verbose

Key strategy: Enable unattended-upgrades for security origins only, but pair it with a weekly manual review of held-back packages. Livepatch buys you time between maintenance windows, but it's not a substitute for eventual reboots — track your reboot debt.

CentOS Stream: The Pragmatic Middle Ground

With CentOS Linux reaching end-of-life, CentOS Stream is now a rolling-release preview of RHEL. This changes patch management significantly: there are no traditional errata.

# Standard update — no --security flag with errata metadata
sudo dnf update

# Use dnf versionlock to prevent critical packages from updating unexpectedly
sudo dnf install python3-dnf-plugin-versionlock
sudo dnf versionlock add kernel-5.14.0-362.el9

Key strategy: Because CentOS Stream lacks errata classification, compensate with aggressive testing automation. Run updates through a CI pipeline with integration tests before touching any environment beyond dev.

Unifying the Workflow

Regardless of distribution, every environment benefits from these principles:

  1. Inventory first. You can't patch what you can't see. Tools like Ansible, SUSE Manager, or even a simple ansible -m setup fact-gathering playbook create your baseline.

  2. Automate scanning. Use OpenSCAP or Nessus to identify vulnerability exposure before and after patching.

  3. Staged rollouts. Never patch everything simultaneously. Canary → Dev → Staging → Production.

  4. Rollback readiness. Ensure dnf history rollback or filesystem snapshots (Btrfs/LVM) are tested and documented.

# RHEL/CentOS rollback example
sudo dnf history list
sudo dnf history undo 45

Final Thought

Patch management isn't a tooling problem — it's a discipline problem. The best toolchain in the world fails if there's no policy defining SLAs for critical versus moderate CVEs, no staged rollout process, and no post-patch validation. Build the policy first, then automate the execution. Your 2 AM self will thank you.

Have questions about linux patch management: rhel, ubuntu, and centos strategies? I'm always happy to talk shop — reach out or connect with me on LinkedIn.

← Back to Articles