Skip to main content

max / makenotwork

Install the mt companion on prod-1 only; testnot-1 has no mt Checked both boxes. testnot-1 has no multithreaded at all: no unit, no /opt/multithreaded, no database, and the deploy user's sudo grant covers only the three makenotwork.service verbs. The companion block added for it would have failed the install step of every promote, and companions install after the symlink swap, so it would fail on the expensive side of the swap. Standing an instance up there is real work with real secrets — role, database, .env, unit, routing — not a config line, and it is not a prerequisite for shipping mt to prod. mt is still built and gated on the host tier from the server's sha; what is lost is exercising the mt binary itself on testnot before prod sees it. Tracked separately. prod-1 needs no setup: the wrapper and the sudoers grant are already there from mnw-cli, and the grant is scoped to the installer script rather than to a named companion.
Co-Authored-By
Claude Opus 5 (1M context) <noreply@anthropic.com>
Author: Max Johnson <me@maxj.phd> · 2026-08-03 15:28 UTC
Signed with PGP, not checked
Commit: 2fccc2d02303c94116e804f79c1f3101614a537b
Parent: 2e2e3e1
2 files changed, +31 insertions, -16 deletions
M sando/sando.toml +18 -13
@@ -145,16 +145,17 @@
145 145 # binary can satisfy between restarts. The node binds HOST=127.0.0.1 PORT=8080
146 146 # (/etc/mnw/makenotwork.env); verified serving 200 on 2026-07-21.
147 147 health_url = "http://127.0.0.1:8080/health"
148 - # Companion: multithreaded (the forum) is built from this same sha and installed
149 - # after the server is up. It is on testnot FIRST, unlike mnw-cli, because this is
150 - # the tier where the 48h burn-in runs — a forum that fails to boot on the new
151 - # binary should fail here, not on prod. Needs the node-side wrapper + sudoers
152 - # grant (deploy/install-companion.sh, deploy/mnw-companion.sudoers) and an
153 - # existing multithreaded.service; see multithreaded/deploy/README.md.
154 - [[tier.node.companion]]
155 - name = "multithreaded"
156 - install_path = "/opt/multithreaded/multithreaded"
157 - service_name = "multithreaded.service"
148 + # NO multithreaded companion here, deliberately. Checked on the box 2026-08-03:
149 + # testnot-1 has no mt at all — no multithreaded.service, no /opt/multithreaded,
150 + # no database, and the deploy user's sudo grant covers only the three
151 + # makenotwork.service verbs. A companion block would therefore fail the install
152 + # step of every promote, and it fails AFTER the symlink swap, which is the
153 + # expensive half of the failure.
154 + #
155 + # Standing an mt instance up here is real work with real secrets (role, database,
156 + # .env, unit, routing), not a config line, and it is not a prerequisite for
157 + # shipping mt to prod: mt is still built and gated on the host tier by the same
158 + # sha, and testnot still burns in the server. Tracked separately.
158 159
159 160 # ---- B: prod-1 ----
160 161 [[tier]]
@@ -196,9 +197,13 @@
196 197 # Companion: multithreaded, same sha as the server, same host. This is what
197 198 # retires multithreaded/deploy/deploy-hetzner.sh (cross-compiled on macOS, scp'd
198 199 # to root@, 41 commits behind when found). mt now rides the whole ladder — native
199 - # build on fw13, the migration_dry_run gate against its own dump, burn-in on
200 - # testnot, node_health — instead of a laptop and an scp. Design:
201 - # wiki sando-mt-pom-pipelines.
200 + # build on fw13, the migration_dry_run gate against its own dump, the test and
201 + # lint gates, and the server's burn-in on testnot — instead of a laptop and an
202 + # scp. Design: wiki sando-mt-pom-pipelines.
203 + #
204 + # prod-1 is the only node that installs it, because it is the only node that runs
205 + # mt (see the note on testnot-1 above). It already has the wrapper and the
206 + # sudoers grant, from mnw-cli.
202 207 [[tier.node.companion]]
203 208 name = "multithreaded"
204 209 install_path = "/opt/multithreaded/multithreaded"
M multithreaded/deploy/README.md +13 -3
@@ -7,6 +7,10 @@
7 7 | production | alpha-west-1 | x86_64 | Sando, as a companion of the MNW server |
8 8 | astra | astra | aarch64 | `deploy/deploy.sh` |
9 9
10 + There is no mt on testnot-1, so nothing installs there. The binary is still built
11 + and gated from the same sha as the server, and testnot still burns the server in;
12 + what testnot cannot do is exercise mt itself before prod sees it.
13 +
10 14 Sando builds only on its configured `build_host` (fw13, x86_64) and refuses to
11 15 compile anywhere else, so it cannot produce the aarch64 binary astra needs. That
12 16 is the same constraint that sent pom to Bento. Astra keeps its own script.
@@ -46,9 +50,11 @@
46 50
47 51 ### One-time node setup
48 52
49 - Per node hosting mt (`testnot-1`, `prod-1`), as root. Both steps come from
50 - `sando/deploy/`; this is the same wrapper and grant mnw-cli uses, so a node that
51 - already hosts mnw-cli has them.
53 + None on prod-1. It already carries `/usr/local/lib/mnw/install-companion.sh` and
54 + the `/etc/sudoers.d/mnw-companion` grant, from mnw-cli, and the grant is on the
55 + script rather than on a particular companion.
56 +
57 + Any future node hosting mt needs both, as root, from `sando/deploy/`:
52 58
53 59 ```
54 60 sudo install -d /usr/local/lib/mnw
@@ -57,6 +63,10 @@
57 63 sudo visudo -cf /etc/sudoers.d/mnw-companion
58 64 ```
59 65
66 + The sudoers file names `makenotwork` as the deploy user, matching prod-1's
67 + `ssh_target`. A node Sando reaches as a different user needs that name changed to
68 + match, or the install is denied.
69 +
60 70 mt also needs what it has always needed on the box, none of which Sando touches:
61 71 the `multithreaded` postgres role and database, `/opt/multithreaded/.env`, and
62 72 `multithreaded.service` installed and enabled (`deploy/multithreaded.service`).