Agent and tray updates
The Outpost agent keeps itself and the tray app up to date. You do not schedule agent updates or push them from the console. This page explains how an update reaches an endpoint, what protects the endpoint from a bad build, and how to update one endpoint immediately when you need to.
How an update reaches an endpoint
Section titled “How an update reaches an endpoint”Every 4 hours, and shortly after it starts, the agent asks the Outpost update service whether a newer build is published for its release track. When there is one, the agent:
- Downloads the new build.
- Checks its SHA-256 hash and its Ed25519 signature against the public key built into the agent. A build that fails either check is not installed.
- Keeps the current build aside, installs the new one, and restarts its service.
The endpoint shows offline for a moment while the agent restarts. Updates need no administrator action on the endpoint and no restart of the computer.
On Windows, the update includes the watchdog service. The tray app is checked on the same 4-hour cycle and replaced the same way. Because one copy of the tray serves every user of the computer, the agent, not the tray, installs tray updates.
When an update fails
Section titled “When an update fails”A new build is on probation until it proves it runs:
- A build that runs for 10 minutes confirms itself, and the update is done.
- A build that is still unconfirmed after 15 minutes is rolled back to the previous build.
- On Linux, FreeBSD, OpenBSD, and macOS, a build that restarts more than 5 times during probation is rolled back at once.
On Windows the watchdog service makes this decision. On the other platforms the agent makes it each time it starts. A version that was rolled back is not installed again on that endpoint. While an update is on probation, no further update is installed on top of it.
Release tracks
Section titled “Release tracks”Endpoints take their builds from a release track. Every Outpost starts on the stable track. Outpost can place an organization on a release candidate track to receive builds before general release, and its endpoints then take both agent and tray builds from that track. The track is not a setting in the console.
Update one endpoint now
Section titled “Update one endpoint now”Two actions on an endpoint’s Actions menu, under Agent, run the update check on demand:
| Action | What it does |
|---|---|
| Check for agent update | Asks the agent whether a newer build is available. Changes nothing. The check starts as soon as you choose the action. |
| Update agent now | Asks the agent to download and install the newest build on its track now. You confirm first, because the agent restarts its service if it installs something. |
Both need the endpoint:action permission.
The dialog follows the request from start to finish. It shows the agent’s own report under Report, and after an install, whether the agent has reconnected. The same result appears on the endpoint’s Commands tab, and View in Commands takes you there.
If the endpoint is offline, the request waits. The dialog shows This endpoint is offline. The request is queued and expires in 15 minutes if it does not reconnect.
An agent from before the update action was added answers with This agent cannot be updated from here. Update it with a new installer once, and the action works from then on.
To update from the endpoint itself, run outpost-agent update as an
administrator or root. See Agent command reference.
Related
Section titled “Related”Content is licensed CC BY 4.0. Code samples are MIT. Outpost and the Outpost mark are trademarks of Outpost Business Solutions, PBC and are not covered by either license.