Agent updates

Agents can be updated from the admin page. The server decides when an agent updates, but cannot decide what it installs: agents only accept builds signed with your release key.

Release a new version

On the computer that holds release.key:

VERSION=0.2.0 deploy/build.sh

This produces bin/fleetd-agent-0.2.0-amd64.release and bin/fleetd-agent-0.2.0-arm64.release. Version numbers are MAJOR.MINOR.PATCH and must increase.

Upload the files in Settings → Agent releases. If the server has release_key configured, it rejects bundles signed with any other key right away.

Roll it out

  1. Open one machine's page, pick the new version and click Update agent.
  2. Wait for it to come back online with the new version. The result is logged under Alerts → History.
  3. In Settings → Agent releases, click Update older agents to update every online machine that runs an older version on the same architecture.

There is no automatic rollout on purpose: a bad build updated everywhere at once could take every machine offline, and an offline agent cannot be fixed from the admin page.

What the agent checks

An agent refuses a release, and reports why, if:

  • it is not signed by the release_key in its config, or the file was altered;
  • it is for another CPU architecture;
  • it is not newer than the running version (no downgrades to old, vulnerable builds);
  • the new program does not run, or reports a different version than the one signed.

Otherwise it replaces itself atomically, keeps the previous binary as fleetd-agent.old, exits, and systemd or procd starts the new version.

Agents without release_key in their config do not accept remote updates.

Roll back by hand

mv /usr/local/bin/fleetd-agent.old /usr/local/bin/fleetd-agent && systemctl restart fleetd-agent

On OpenWrt the binary is /usr/bin/fleetd-agent.

Updating the server

Replace /usr/local/bin/fleetd-server and restart it. The database schema is upgraded on start. Agents reconnect by themselves within a minute.