Patching Linux and Windows

You can patch from three places:

• The Fix buttons on the dashboard, for one node or the whole fleet.
• The Patch a node group runbook, for one node group at a time. A node group is a named set of nodes, such as Windows, Linux or Ring0-Pilot. See Runbooks.
• A workflow such as Patch Tuesday: pilot ring, then broad ring. See Workflows and approvals.

All three run the same patch action on each node.

What a patch does#

Patching never upgrades the Salt agent itself and never restarts the node. Salt agent packages are also left out of the pending count on Linux nodes. Agent upgrades come only with a tested Gardience release.

Readiness check before patching#

Before Patch a node group, Patch to the tested set and Fix a CVE, Gardience checks each machine and patches only the ones that can take updates now. The others are left out of the run, each with its reason in the run log and in the audit log, so a machine with a full disk is reported up front instead of failing half-way through an update.

Another package run holding the lock (for example Ubuntu's automatic updates) does not count: the patch waits for it. A machine that does not answer the check, or whose agent does not have it yet, is patched as before: the check removes known failures and never blocks a run on its own. An admin can turn it off under Settings > Patch readiness check.

When an update fails#

Most failed update runs are stale package metadata or a package run that was interrupted. So when an update fails on a machine that answered (Patch, Patch to the tested set, and Fix a CVE, from the Patching page, runbooks, schedules, workflows, the API, or gdn), Gardience repairs the package metadata and tries once more on that machine:

The repair removes nothing that is not downloaded again. Both tries are in the audit log (patch.retried) and in the run's result, which says "worked on the second try" or "failed again". A second failure stands: Gardience does not loop. Machines that did not answer are not retried; they run when they reconnect.

Third-party Windows applications#

Windows Update does not update applications such as 7-Zip, Chrome, Zoom or Adobe Reader. Patching > App updates shows every application with a newer version in the public winget catalog, across all your Windows machines and grouped by application: its name, the versions installed now, the version it updates to, and which machines have it. Gardience checks every Windows machine once a day (changing nothing), and Check now checks again on demand.

Tick the applications to update and choose Update. Each one installs silently on every Windows machine that has it (the application may close while it updates), and Gardience checks again when the run finishes. The update is the Update Windows apps runbook, so it goes through your approvals, change windows, locks, and change tickets like any patch run, and each machine's result is in the audit log. The runbooks List Windows app updates and Update Windows apps (Automation > Runbooks) do the same on a node group you choose, with package ids you list (for example 7zip.7zip Google.Chrome).

It needs winget, which comes with Windows 10 and 11 and Windows Server 2025 (on Windows Server 2016 to 2022, install App Installer first); a machine without it says so. Gardience uses the public winget catalog only, never the Microsoft Store, and runs winget as the Salt agent's system account. The Salt agent itself is never offered or updated here, under any of its publisher names; only a tested Gardience release moves it.

Fix one node#

1. Open Overview > Dashboard.

2. Find the node and choose a button in the Fix column:

   • Install updates appears when the node has pending updates.
   • Apply baseline appears when the node does not pass the baseline. See Security baseline controls.
   • Reboot appears when a Windows node reports that it needs a restart.
3. Gardience starts the job right away and shows its progress at the top of the page. When the job ends, Gardience rescans the node and reloads the page.

A fix runs only if your role allows that action on that node. Your rights are read when you sign in, so a role change applies at your next sign-in. Fixes are recorded in the audit log under your name.

If the button is refused:

• "That node is locked": an admin locked the node. Unlock it in Machines > Inventory first. See Change windows and locks.
• "Your role is not allowed to run this": ask an operator or admin.
• "Your session was not started from the Gardience sign-in": sign out and sign in again.

Fix many nodes at once#

To fix every non-compliant node, choose Fix all N non-compliant above the table. Gardience then does two things:

1. It starts Install updates on every node with pending updates. This runs in the background without an approval step.
2. It requests Apply baseline on every node that does not pass the baseline.

Fix all does not reboot nodes.

The second-person approval#

Applying the baseline or rebooting more than one node at a time needs a second person, unless you are an admin. The baseline can switch off SSH password sign-in, and a fleet reboot takes services down, so people with other roles cannot do either alone. Admins run these fixes directly; to require a second person for admins too, turn on Admins need a second person too under Administration > Settings > Approvals.

When you request it:

1. Gardience creates a run named "Fix all: baseline on N nodes" (or "reboot") with the status "awaiting approval", and sends a notification if a webhook is set in Administration > Settings.
2. A different person with the admin or approver role opens Automation > Workflows and approvals and chooses Approve or Reject on that run. The person who asked cannot approve it.
3. If it is approved, the fix starts on all the nodes. If it is rejected, nothing runs.

A request that nobody decides within 7 days expires. A request that is waiting when the Gardience service restarts (an upgrade, for example) keeps waiting.

The same rule covers one-node fixes done in quick succession. If you apply the baseline or reboot single nodes more than three times within 10 minutes, the fourth and later requests also wait for a second person (for admins only when the setting above is on).

Tested patch sets: the broad ring gets exactly what the pilot tested#

Vendors publish updates all the time. If the pilot ring is patched on Tuesday and the broad ring on Thursday, a plain patch on Thursday would install whatever is newest on Thursday, including updates the pilot never tested. Tested patch sets prevent that.

• After every patch run, Gardience checks the patched machines again for vulnerabilities and pending updates right away, so a fixed CVE leaves the list, and a needed restart shows, without waiting for the next daily check. Linux machines show restart needed when a newer kernel is installed than the one running, or the system asks for a restart; Windows machines when Windows Update says so.
• Every successful Patch a node group run records what its machines installed: for Linux, each package and the exact version, per OS release (for example Debian 12 or Rocky 9); for Windows, the updates (KB numbers). The sets are listed under Patching > Tested patch sets.
• The runbook Patch to the tested set installs a set on a node group: each package of that OS release that is installed on the machine and older than the tested version is brought to exactly that version. Nothing newer is installed, and packages the pilot did not update are left alone. On Windows, only the set's updates are installed.
• The workflow Patch Tuesday, tested set does it end to end: patch the pilot ring (the set is recorded), verify it, wait for a second person's approval, then install the pilot's set on the broad ring and verify that.

Packages still come from each machine's own repositories; no mirror is needed. If a repository no longer offers a tested version (some Linux repositories keep only the newest), that package is skipped on that machine and the run says so: run a new pilot. The Salt agent is never part of a set.

Offline nodes and change windows#

When a fix targets nodes that cannot take it right now, Gardience holds the work instead of failing:

• A node that does not answer a quick check is held as offline. Its fix runs when it reconnects.
• A node in a node group whose change window is closed is held until the window opens.

For a one-node fix, the page tells you if the work was held. For a fix on many nodes, Gardience sends one notification saying how many nodes started, how many were held and how many could not start. Held work appears in Automation > Change control. See Held work.

Reboots#

• Windows nodes restart 5 seconds after the job reaches them.
• Linux nodes restart 3 seconds after the job reaches them.
• The dashboard shows "Reboot pending" for Windows nodes. For Linux, Security > Vulnerabilities marks machines waiting for a restart (a newer kernel installed than the one running, or core packages updated), from its daily check. Reboot Linux nodes after patching with the Reboot a node group runbook or the Patch, reboot, wait, verify workflow.
• When a reboot runs from a runbook or workflow, the step succeeds only once each node has restarted and its agent has reconnected. A node that is not back within 20 minutes fails the step.

A fix that is still "running" after 30 minutes is shown as "timeout". If a node restarts in the middle of a job and the job ends without a result, Gardience closes the job and rescans the node.

Related#

• Patch and compliance dashboard
• Workflows and approvals
• Held work
• Change windows and locks