Second Docker-side prereq uncovered running a real deploy on a fresh
Debian trixie VM: images pulled fine but 'docker compose up --build'
bailed with 'compose build requires buildx 0.17.0 or later'. Debian's
buildx is stuck at 0.13, so the compose-plugin install must be paired
with a buildx plugin install.
- Prereqs list now requires docker compose version AND docker buildx
version to be verified before enrolling.
- Install section renamed to 'Installing Compose v2 and Buildx on a
worker', covers both plugins with arch-aware curl incantations and
uname -m → compose-arch / buildx-arch mapping (compose uses x86_64,
buildx uses amd64 — footgun).
- Adds a troubleshooting row for the buildx-too-old case and one for
wrong-arch binary ('Invalid Plugins: ... exec format error').
Both uncovered on the live VM run; docs now match reality.
docs(swarm): spell out Compose v2 plugin prerequisite
Caught on a fresh Debian trixie VM: 'Docker Engine + Compose plugin' as
a one-liner prerequisite is a common setup trap because trixie (and
plenty of other distros) ship only the legacy 'docker-compose' (v1), not
the 'docker compose' subcommand that the DECNET deployer calls.
Adds two explicit install paths (Docker's apt repo for online boxes,
standalone binary via scp for lab/air-gapped networks), calls out why
legacy v1 does not work, and documents the exact failure signature
(exit 125 + docker help text) so the next person who hits it on the
worker side knows immediately what's wrong. Cross-references from the
troubleshooting table.
docs(swarm): drop known-limitation about master-side NIC mismatch
Agent now relocalizes master-built configs before dispatch (commit in
main repo: fix(swarm): relocalize master-built config on worker before
deploy). The wiki claimed this was a known limitation requiring
per-worker INI files; that workaround is no longer needed. Updated the
troubleshooting row to describe the new failure mode (worker can't
detect its own default route) instead of the old one.
docs(swarm): fix forwarder flag name (--log-file not --log-path)
The forwarder takes --log-file; --log-path is the listener flag. Caught
by ANTI running the command from the worker bootstrap section verbatim
and getting 'No such option: --log-path Did you mean --log-file?'.
docs(swarm): add SWARM Mode page and cross-link from Deployment Modes
Comprehensive walkthrough for the newly-landed SWARM control plane:
- Architecture diagram (master: swarmctl/listener/ingester/api; worker:
agent/forwarder) with ports cheat sheet
- Step-by-step setup (CA bootstrap, enrollment, bundle shipment, agent +
forwarder startup, check, first swarm deploy)
- Full command reference for swarmctl, listener, agent, forwarder, and
the swarm enroll/list/check/decommission subcommands
- Log-pipeline end-to-end story (RFC 5424 on worker → RFC 5425 mTLS on
6514 → master.json → ingester → dashboard), including tcpdump-based
plaintext-leak check and source_worker provenance note
- Operational concerns: master crash resume (no dup/loss), worker crash,
CA rotation, cert rotation, teardown
- Security posture summary
- Known limitations (get_host_ip master-side bug, no web UI yet,
round-robin only, single master)
- Troubleshooting matrix
Deployment-Modes: trimmed the old 'swarm is not implemented, drive it
from Ansible' section and replaced with a link to the new page.
_Sidebar: added SWARM-Mode under User docs.
