enhancement: Keep the agent correct after fly update #30

Blocker: no. Ship this in the same release as the monitoring agent.

Part of the monitoring agent (contract v0.2.1). Order: #26 → #27 → #28 → #29 → #30, with #9.

Defect

• fly update replaces the binary, but it does not restart the agent. The agent continues with the old binary.
• A second fly update sees the new binary and does nothing. The agent gets the new version only at its next restart.
• fly update operates as root. Thus, the new binary belongs to root. The contract says that the binary belongs to the server user.
• Without --yes and without a terminal, fly update cannot ask the question. It shows "Update cancelled." and exits with 0. A script then thinks that the update is done.

Cost

• The version on the server page is not the version on the disk.
• A person or a script thinks that the server is up to date, but it is not.

Benefit of the fix

• fly update is idempotent. When the server is up to date, it does nothing. When it is not, it installs the latest release, and the agent runs that release.

Fix

1. Keep the current rule: if the current version is the latest release or newer, show a message and exit with 0.
2. After fly update replaces the binary, restart the agent if fly-agent.service exists.
3. If the binary is up to date but the agent still runs a replaced binary, restart the agent. To find this, read the link /proc/<agent PID>/exe. It ends with (deleted) for a replaced binary.
4. Before the rename, give the new binary the owner of the old binary.
5. If there is no terminal and no --yes, stop with an error and exit with 1.
6. Use the shared update code of enhancement: Run agent.update and agent.restart one time only #29.

Caution

• The control plane updates each agent that is not on its target version, also an agent that is newer. After fly update installs a release that is newer than the target, the next FlyWP update batch moves the server back to the target.
• To prevent this, set the target to each new release. As an alternative, change the control plane to update only the agents that are older than the target.

Completion checks

• On a test server, after sudo fly update, the agent reports the new version.
• A second sudo fly update does nothing and exits with 0.
• After sudo fly update, ~fly/.fly/bin/fly belongs to fly.
• fly update < /dev/null without --yes exits with 1.
• On a server without the agent, fly update operates as before.