fix(manage-server): wipe /bins volume on upgrade so new binaries take effect #2

Merged

amiryahaya merged 1 commit from fix/upgrade-wipe-bins-volume into main

2026-07-02 21:01:22 +02:00

amiryahaya commented

2026-07-02 21:00:30 +02:00

Owner

Summary

Mirrors the fix already merged in the source-of-truth triton repo (scripts/deploy/manage-server/upgrade.sh, commit a0ead5ba).

upgrade.sh recreated the manage-server container via --force-recreate, but the triton-manage-bins named volume (mounted at /bins) persists across container recreates by design — a named volume is only auto-populated from the image's baked content on true first creation. So every upgrade silently kept serving whatever worker/agent binaries were baked into the image at first install, forever — diagnosed via a real production install where a newly-published image's binaries (a new Windows sshagent build) never appeared after upgrading to the new image.

Fix: explicitly stop + remove the container, remove the triton-manage-bins volume, then recreate — the fresh volume auto-populates from the new image on next start.

Safety: /bins holds only binaries reproducible from the image (or re-synced from the license server if configured) — no trust material lives there. Confirmed the gateway's self-signed CA and its private key live entirely in Postgres (manage_ca table, triton-manage-db-data volume — pkg/manageserver/ca/postgres.go), never touched by this.

Note on scope: manage-server/upgrade.sh in this repo had already drifted from the triton source-of-truth independently — it has macOS-specific runtime detection (auto-starting Podman machine) and TLS path fixups not present in the triton copy. Applied this fix to the file's current structure as-is; did not attempt to reconcile that broader pre-existing divergence between the two repos in this PR.

Test plan

bash -n syntax check clean
shellcheck --severity=warning — zero new findings (same pre-existing SC2034 note on the health-check loop, unrelated to this change)
Full end-to-end test against a real podman compose project mimicking this file's structure (two services + named volume): confirmed the volume is correctly wiped and freshly repopulated from the image on up -d --no-deps, and that the unrelated db service/container is never touched throughout the sequence
Verified both branches of the new logic (volume exists → removed; volume absent → skipped) against real podman volume inspect/rm

🤖 Generated with Claude Code

## Summary Mirrors the fix already merged in the source-of-truth `triton` repo (`scripts/deploy/manage-server/upgrade.sh`, commit a0ead5ba). `upgrade.sh` recreated the manage-server container via `--force-recreate`, but the `triton-manage-bins` named volume (mounted at `/bins`) persists across container recreates by design — a named volume is only auto-populated from the image's baked content on true first creation. So every upgrade silently kept serving whatever worker/agent binaries were baked into the image at *first install*, forever — diagnosed via a real production install where a newly-published image's binaries (a new Windows sshagent build) never appeared after upgrading to the new image. Fix: explicitly stop + remove the container, remove the `triton-manage-bins` volume, then recreate — the fresh volume auto-populates from the new image on next start. **Safety:** `/bins` holds only binaries reproducible from the image (or re-synced from the license server if configured) — no trust material lives there. Confirmed the gateway's self-signed CA and its private key live entirely in Postgres (`manage_ca` table, `triton-manage-db-data` volume — `pkg/manageserver/ca/postgres.go`), never touched by this. **Note on scope:** `manage-server/upgrade.sh` in this repo had already drifted from the `triton` source-of-truth independently — it has macOS-specific runtime detection (auto-starting Podman machine) and TLS path fixups not present in the `triton` copy. Applied this fix to the file's current structure as-is; did not attempt to reconcile that broader pre-existing divergence between the two repos in this PR. ## Test plan - [x] `bash -n` syntax check clean - [x] `shellcheck --severity=warning` — zero new findings (same pre-existing SC2034 note on the health-check loop, unrelated to this change) - [x] Full end-to-end test against a real `podman compose` project mimicking this file's structure (two services + named volume): confirmed the volume is correctly wiped and freshly repopulated from the image on `up -d --no-deps`, and that the unrelated `db` service/container is never touched throughout the sequence - [x] Verified both branches of the new logic (volume exists → removed; volume absent → skipped) against real `podman volume inspect`/`rm` 🤖 Generated with [Claude Code](https://claude.com/claude-code)

amiryahaya added 1 commit

2026-07-02 21:00:30 +02:00

fix(manage-server): wipe /bins volume on upgrade so new binaries take effect 6f96407af2

Mirrors the same fix in the source-of-truth triton repo
(scripts/deploy/manage-server/upgrade.sh). A named volume only
auto-populates from the image's baked content on true first creation —
--force-recreate recreates the container but never refreshes the
volume, so every upgrade silently kept serving whatever worker/agent
binaries were baked in at first install.

Explicitly stop+rm the container, remove the triton-manage-bins volume,
then recreate — the fresh volume auto-populates from the new image on
next start. Safe: /bins holds only binaries reproducible from the image
(or re-synced from the license server), no trust material — the gateway
CA lives in Postgres (triton-manage-db-data), untouched by this.

This file had already drifted from the source-of-truth copy independently
(macOS-specific runtime detection / TLS path fixups not present there) —
applied this fix to its current structure as-is; did not attempt to
reconcile that broader pre-existing divergence.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

amiryahaya merged commit aed6ca29e6 into main

2026-07-02 21:01:22 +02:00

amiryahaya referenced this pull request from a commit

2026-07-02 21:01:23 +02:00

Merge pull request 'fix(manage-server): wipe /bins volume on upgrade so new binaries take effect' (#2) from fix/upgrade-wipe-bins-volume into main