Skip to main content

Patch management for Linux OS devices

Automate Linux patch scanning, approval, and deployment with granular policy controls.

Updated this week

SuperOps extends its robust patch management capabilities to Linux devices, allowing you to manage your entire fleet—Windows, macOS, and Linux—from a single pane of glass. You can automate scanning, approve patches based on severity and category, and schedule deployments to ensure your infrastructure remains secure and compliant.

Supported Linux Distributions

SuperOps supports patch management for the following Linux distributions:

  • Ubuntu

  • Debian

  • RHEL (Red Hat Enterprise Linux)

  • CentOS

  • Fedora

  • SUSE

  • openSUSE

Configuring Linux Patch Policies

Patch management behavior is defined through policies, which can be applied globally, per client, per site, or per asset. To begin managing patches for your devices, you must first configure the appropriate policies.

  1. From the main dashboard, click the Settings icon on the left-hand navigation bar.

  2. Select Policy Management to view and manage all asset policies.

  3. Scroll through the list and click on Linux Workstation Policies (or Linux Server Policies) to configure its specific settings.

    Screenshot 0
  4. Select Patch Management from the left-hand menu. This section allows you to define rules for scanning, approving, and deploying patches for all Linux workstations.

    Screenshot 1

The configuration page offers several key sections:

  • Schedule Scan Timing: Define how often the SuperOps agent scans assets for missing patches (e.g., daily).

  • Approval configurations: Use the Category × Severity matrix to automate patch approvals. You can set specific combinations (e.g., Critical Security Updates) to Approve, Manual (requires technician approval), Reject, or Defer.

Deferrals, Overrides, and Schedules

Further down the policy page, you can refine your control over patch releases and set deployment schedules.

  1. Scroll down to view the Patch Defer and Patch Override sections.

    • Patch Defer Deployment: Delay the installation of specific patch categories for a set number of days. This allows you to test stability on a smaller subset of devices before a broad rollout.

    • Patch Override: Manually approve or reject specific patches globally by referencing their package key, name, or version.

    Screenshot 2
  2. To create a new deployment schedule, click the Schedule button in the "Schedule to deploy the approved patches" section. This opens a window where you can name the schedule, set its frequency, and add specific conditions for when patches should be installed.

    Screenshot 3

Managing Patches Globally

After configuring your policies, you can view and manage the patch status for your entire fleet from the global Patch Management view.

  1. Navigate to the main Patch Management module from the left-hand navigation bar to get a global view of all patches.

  2. In the 'All Patches' view, click on the Linux filter at the top to see only the patches relevant to your Linux devices.

  3. The screen displays a comprehensive list of Linux patches, including their version, severity, and the number of associated assets. You can inspect which devices are pending an update by clicking the link in the 'Install Pending Assets' column.

  4. You can take action instantly for a specific patch by approving, directly installing, or rejecting a patch with a single click.

    Screenshot 4

Once you have configured your Linux patch policies, ensure your assets are assigned to the correct policy hierarchy. You can monitor the deployment progress and compliance status directly from the Asset details page or the global Patch Management view.


📝 Note:


What’s common across all Linux patching in SuperOps

  • Agent sends both: raw (“actual”) + normalized (“derived”) Category and Severity.

Only new patches are synced to the server (no historical backfill).
Unknown values map to Category = Others / Severity = Others.

  • If Patch Title is empty, SuperOps shows Version instead (common on Fedora).


Differences based on distro


Ubuntu / Debian (APT)
Category: always Others
Severity mapping:
low → Low, medium → Medium, critical → Critical
high / emergencyOthers
UX note: can show “Reboot required” banner (Ubuntu).

SUSE / openSUSE (zypper)
Software Updates

  • Category: Software (default)

  • Severity: Others (default)

OS Updates

  • Category mapping: security→Security, recommended→Recommended, optional→Optional, feature/document/yast→Others

  • Severity mapping: critical→Critical, important→Important, moderate→Medium, low→Low, unspecified→Others



RHEL (dnf) — non-Fedora
Software Updates

  • Category: Others (default)

  • Severity: Others (default)

OS Updates

  • Category: Bugfix / Security / Enhancement

  • Severity mapping: low→Low, moderate→Medium, important→Important, critical→Critical


Fedora (dnf)
Category (OS updates): Bugfix / Security / Enhancement / Newpackage / Others
Severity: Low / Medium / Important / Critical
Extra behaviors:
Dependencies are present only for Fedora OS update patches.
After install, terminal-reported “pending updates” may not reflect until an asset reset/refresh.

Did this answer your question?