1. Specifics of Linux vs Windows patching

1.1. Key differences

• Patch sources
  Windows: a single logical source → Microsoft (WSUS / Windows Update / catalog).
  Linux: multiple distributions (Red Hat, Ubuntu, Debian, SUSE, Rocky, Alma, etc.), each with its own repositories and URLs.
• Package managers
  RPM: yum / dnf (Red Hat, CentOS, Rocky, Alma, Oracle Linux), zypper (SLES/OpenSUSE).
  DEB: apt (Debian, Ubuntu).
  .rpm and .deb packages are not interchangeable; there is no generic exe concept.
• Versioning & URLs
  Each version has its own repository path.
  Ubuntu example: bionic (18.04), focal (20.04), jammy (22.04), etc.
  To patch jammy (22.04), you must point to the jammy repositories, not to bionic or focal (otherwise you mix metadata and create inconsistencies).
  Same logic for RHEL 7/8/9, Debian 10/11/12, SLES 12/15, etc.
• Release cadence
  Windows: monthly Patch Tuesday (plus out-of-band updates).
  Linux: no single global calendar; updates are released as soon as they are available per distribution.
• Recommended strategies
  Windows: patch lists to control exactly which KBs and classifications are installed.
  Linux: repository snapshots to freeze a consistent state (metadata + dependencies) at a given date.

1.2. Practical advice

• Do not copy your Patch Tuesday logic 1:1 to Linux: build a strategy per distribution and per repository.
• Document clearly:
  • which OS versions are associated with which repositories;
  • which branches (prod / pre-prod / test) consume which snapshots.

---

2. Choosing the Linux scan method

Tanium Patch provides two scan methods for Linux:

• Repository Scan
• Tanium Scan for Linux (TSL)

We do not create new repositories here; we only explain how to use repositories that already exist (on the OS or already configured in Tanium).

2.1. Repository Scan – concept

• The Linux endpoint talks directly to its repositories:
  • those configured on the OS (/etc/yum.repos.d, /etc/apt/sources.list, etc.);
  • or a list of repositories pushed by Tanium.
• Tanium only:
  • triggers the scan;
  • launches installation through the native package manager.

Key idea: Repository Scan = the Linux server uses its usual repo configuration, Tanium only orchestrates.

2.2. Tanium Scan for Linux (TSL) – concept

• Only the Tanium Server talks to the repositories.
• It downloads and caches repository metadata, then distributes a “client DB” to the endpoints.
• Endpoints run local scans with their native package manager using that metadata.

Advantages:

• Repository snapshots possible (freeze state at a given date).
• Uses the linear chain to optimize bandwidth (one leader downloads, peers fetch from the leader).

Key idea: TSL = Tanium centralizes repo information, enables snapshots, and saves bandwidth.

2.3. Simple rule of thumb

• Single or few servers directly on the Internet / in the cloud
  → Repository Scan, simple and close to the repos.
• On-prem environment with many servers, rings, strong consistency requirements
  → Tanium Scan for Linux + snapshots.

---

3. Scenario 1 – Single Linux server directly on the Internet

Goal: patch a single Linux server (Ubuntu, RHEL, etc.) that already has repositories configured and direct Internet access.

3.1. Prerequisites

On the server:

• apt update / yum repolist / dnf check-update run without error.
• Repositories are already configured by the OS team.

In Tanium:

• The server shows up correctly in the console.
• Patch module is enabled.
• Non-Windows Patch process is running:
  • Question: Patch - Is Process Running [Non-Windows] = Yes.
  • If not, run the action Patch - Start Patch Process [Non-Windows] on this server.

3.2. Configure the scan (Repository Scan + OS repos)

1. Go to Modules → Patch → Scan Management → Scan Configurations.
2. Click New Scan Configuration.
3. Settings:
   • Name: Linux RepoScan – <ServerName>.
   • Operating System: Linux.
   • Scan Method: Repository Scan.
   • Use repositories configured on endpoint: checked.
4. Target:
   • Only this server (dedicated Computer Group or filter by computer name).
5. Schedule:
   • Initial scan.
   • Then once per day or per week depending on requirements.

3.3. Deploy patches on this server

Option A – Deploy all missing patches

1. Go to Modules → Patch → Deployments → New Deployment.
2. OS = Linux.
3. Select the option to deploy all missing patches (label depends on your Patch version).
4. Target = this server.
5. Schedule: immediate or within a defined window, with or without automatic reboot.

Option B – Targeted deployment via Patch List

1. In the Linux Patch view, filter on this server and severity (High/Critical) or specific CVEs.
2. Add these patches to a Patch List (for example Linux – Critical – SoloServer).
3. Create a new Deployment based on this Patch List:
   • OS = Linux.
   • Patch List = Linux – Critical – SoloServer.
   • Target = this server.
   • Schedule + reboot according to your policy.

---

4. Scenario 2 – Linux fleet with rings and snapshots (on-prem)

Goal: patch an on-prem Linux fleet with multiple servers using rings (pilot → pre-prod → prod) and snapshots to guarantee consistency.

Assumptions:

• Linux repositories are already configured and working in Tanium.
• You can use Tanium Scan for Linux (TSL).

4.1. Define rings and Computer Groups

Example:

• Ring 0 – Pilot
  A few non-critical servers per distribution/version.
  Computer Group: Linux-Ring0-Pilot.
• Ring 1 – Pre-prod
  Pre-production / UAT servers.
  Computer Group: Linux-Ring1-Preprod.
• Ring 2 – Prod
  Production fleet.
  Computer Group: Linux-Ring2-Prod.

4.2. Configure a single TSL scan for Linux

1. Ensure Enhanced Linux Support is enabled in Patch.
2. Go to Scan Configurations → New Scan Configuration.
3. Settings:
   • Name: Linux – TSL – Global.
   • Operating System: Linux.
   • Scan Method: Tanium Scan (Tanium Scan for Linux).
4. Repositories:
   • Select only the existing Linux repositories (RHEL, Ubuntu, Debian, etc.).
5. Target:
   • Linux-Ring0-Pilot, Linux-Ring1-Preprod, Linux-Ring2-Prod (or a global group like Linux-All).
6. Schedule:
   • Initial scan.
   • Then regular scans (for example 1–2 times per day).

4.3. Use snapshots

Goal: ensure Ring 0, Ring 1 and Ring 2 all apply exactly the same patch content.

1. Verify that snapshots exist per distribution/version/date (for example RHEL8-2025-11, Ubuntu22-2025-11).
2. In the TSL scan configuration, enable snapshot usage for deployments if available.

Result: all deployments can rely on a given snapshot to freeze content.

4.4. Ring-based patching cycle

Ring 0 – Pilot

1. Create a Deployment in Patch:
   • OS = Linux.
   • Source: all missing patches from a snapshot, or a Patch List + snapshot.
   • Snapshot = the monthly snapshot (e.g. RHEL8-2025-11).
   • Target = Linux-Ring0-Pilot.
   • Specific maintenance window for Ring 0.
2. Deploy and verify results on pilot servers.

Ring 1 – Pre-prod

1. Clone the Ring 0 deployment.
2. Change:
   • Target = Linux-Ring1-Preprod.
   • Maintenance window = pre-prod window.
3. Use the same snapshot.

Ring 2 – Prod

1. Clone the Ring 1 deployment.
2. Change:
   • Target = Linux-Ring2-Prod.
   • Maintenance window = production window (often night/weekend).
3. Always use the same snapshot.

4.5. Production checks

• Monitor Needs Attention endpoints in Patch before triggering a production ring.
• Check compliance per Computer Group (Ring 0, 1, 2).
• In case of errors:
  • check patch-process.log on an impacted endpoint;
  • run apt/yum/zypper commands locally to confirm OS-level behavior;
  • verify repository URLs are reachable from the endpoints.