Linux servers

Marshal patches Linux servers in every edition, next to Windows Server: the same agent, maintenance windows, ordering, parallel limits, reboots, health checks, halts, compliance, dashboard and reports. Built 2026-10-14.

Supported

• Distributions: Ubuntu 22.04 and 24.04, Debian 12 and 13, RHEL, Rocky and Alma 8, 9 and 10. Others with apt or dnf and systemd will usually work but are not tested.
• CPUs: amd64 and arm64 (one static binary each).
• Needs: systemd, curl, and apt or dnf. The agent runs as root, because it drives the package manager and reboots.

How patching works

There is no catalogue and no approval per package. Each customer has a Linux policy (customer settings, Linux servers):

Policy	What the install window applies
Security upgrades only (default)	upgrades marked as security: apt from a -security pocket, dnf with a security advisory
All upgrades	everything the package manager offers

• Scan (daily, after each run, or Scan for updates): the agent refreshes the package lists (apt-get update, dnf check-update --refresh) and reports every upgrade waiting, with the installed and available version and whether it is a security upgrade (dnf also gives a severity). The list replaces the server’s previous one (server_packages). The server page shows it under Package upgrades: Next install (what the policy installs) or All.
• Install (install window or manual run): the console sends the policy, not a package list. The agent refreshes the lists and upgrades at that moment:
  • apt, all: apt-get upgrade --with-new-pkgs (new dependencies such as a new kernel come in; nothing is removed).
  • apt, security: apt-get install --only-upgrade <the security packages> (and their dependencies).
  • dnf, all: dnf upgrade; security: dnf upgrade --security.
  • Changed configuration files are kept (--force-confold); apt waits up to 10 minutes for another apt to finish.
  • The result lists each package upgraded (from, to) and each one that was not.
• Reboot needed: Ubuntu’s /run/reboot-required (with the packages that asked for it), needs-restarting -r on the RHEL family, and otherwise a newer kernel in /boot than the one running. After an install that needs one, the reboot is owed and done in the reboot window, as on Windows. Unlike Windows, a pending reboot Marshal did not cause (e.g. from unattended upgrades) does not stop a Linux install.
• Reboot: a systemd timer runs systemctl reboot 15 seconds later. After the boot the agent checks the tag’s required services (systemctl is-active <name>) and reports failed units. Tag required services hold Windows service names and systemd unit names alike: use tags per OS.
• Compliance and reports: a Linux server counts what its policy would install. Security upgrades count as important (critical when a dnf advisory says so), others as missing. So under the security policy, a server with only non-security upgrades waiting is up to date.
• Updates page: Windows only. Linux packages are per server.

Install

Add servers makes an install script as for Windows; its Linux tab has the one-liner:

curl -fsSL -k --pinnedpubkey 'sha256//…' 'https://console:8443/agent/v1/install/<token>/linux' | sudo sh

It trusts only the console’s agent API key (or, when the web address has a trusted certificate, it is curl -fsSL https://marshal.example/install/<token>/linux | sudo sh). The script it runs:

1. picks the build for the CPU, downloads it from the console or the first route’s proxy cache (Marshal CA only) and checks its SHA-256;
2. installs /opt/marshal-agent/marshal-agent, writes the install parameters to /var/lib/marshal-agent/install.json (root only; the agent takes them and deletes the file, token included);
3. installs the marshal-agent systemd service and /usr/local/sbin/marshal-agent-uninstall, and starts it.

No .deb or .rpm. The server shows up under its customer like a Windows one (pending approval unless the token approves).

Running it

• Logs: journalctl -u marshal-agent, and /opt/marshal-agent/logs/agent-YYYY-MM-DD.log.
• Data: /var/lib/marshal-agent (state, key and certificate, jobs; 0700).
• Self-update: the rings update Linux agents too (builds for linux-amd64 and linux-arm64, signed like the Windows one). The new binary is swapped in and the agent exits for systemd to start it; a systemd timer rolls it back if the new version doesn’t check in within 10 minutes.
• Removal: Remove in the console: at its next check-in the agent says goodbye and runs the uninstall script from a systemd timer, which removes the service, the binary and the data. By hand: sudo marshal-agent-uninstall.

Not covered

Advisory-by-advisory approval, holding single packages back (use apt-mark hold / dnf versionlock on the server), snaps and flatpaks, livepatch, SUSE (zypper), and distributions without systemd.