Linux & Open Source · Software · YoctoIT tech page

Patching

Satellite, SUSE Multi-Linux Manager and Landscape: CVEs prioritized and windows coordinated across the whole estate.

FOCUS · PATCHES AS A PROCESSTests, waves and reports: the Linux estate updated every month — without anyone noticing
Request the Free Assessment Learn more
YoctoIT material for clients and partners · Linux is a trademark of Linus Torvalds; the distributions and products mentioned are trademarks of their respective owners.
01 · What it is

Patch management di flotta, made clear.

Fleet patching is the least glamorous, most life-saving trade: the tools (Satellite for RHEL, Multi-Linux Manager for SUSE and mixed, Landscape for Ubuntu) serve the content; the process does the rest — CVEs prioritized by exposure, tests on the minor environments, production waves in agreed windows, and the report that proves.

4/mese
the typical waves: test → pre-prod → prod A → prod B
CVSS+contesto
the real priority: the score corrected for the real exposure
Report
the baseline proven: the audit served every month
Patch management di flotta
OFFICIAL LINUX BRANDING · PATCHING
CONSOLE REALE · RED HAT SATELLITE · FONTE: RED HAT DOCS
REAL CONSOLE · RED HAT SATELLITE · SOURCE: RED HAT DOCS
02 · How to use it well

The things that make the difference.

The process

The month's CVEsthe constant flow
Triage & priority
Tests on the rings
Production waves
what · proof · application
Satellite / MLM / Landscapethe tools per distro
The compliance reportthe evidence, as standard
The hygiene that doesn't make the news

One process, three tools

RHEL, SUSE and Ubuntu in the same cycle: the mixed estate with a single calendar.

The rings that save

The bad patch dies in test: production receives only the proven.

Livepatch where needed

The kernel patched without a reboot on the systems that can't stop: the windows saved.

The governed exception

The system that can't be patched right away: compensations, a deadline and tracking — not oblivion.

03 · In depth

Patch management: the process, not the event

Enterprise Linux patching is a process: the windows by criticality (the CVSS 9 doesn't wait for the monthly round), the rings (test→staging→prod: the bad patch dies in test), the fleet tools (Landscape, Multi-Linux Manager, Satellite: local repos, content staging, reports), the live patching for the kernels that can't reboot, the rollback ready (LVM/Btrfs snapshots or images); the metric that counts: the exposure time to the critical CVEs, measured.

  • Anelli — test→staging→prod: the regression stopped earlier
  • Priorità CVSS — the critical right away, the rest at a rhythm: the risk leads
  • Repo staged — the content frozen per ring: prod installs the validated
  • Live patching — kpatch/Livepatch/kGraft: the hot kernel for the 24/7
  • Rollback — a snapshot before every round: the undo in minutes
  • Report — the CVE exposure measured: the data for the audit and for NIS2
04 · Numbers and lifecycle

The numbers that matter.

<72h
the critical ones in production: our standard
3
the process's minimum rings
100%
of the estate in the exposure reports
mensile
the ordinary round: the rhythm that isn't skipped
Patching is the most underrated trade: rings, windows and reports managed by our NOC — the exposure under control.
05 · Use cases

Where it really pays off.

Mixed estates

Three distros, one process, one report.

NIS2 & audits

The patching evidence, produced by the process.

24/7 systems

Livepatch and waves: updated without downtime.

Unapplied patches are the number one cause: our process applies them — every month, with the proof.