max / makenotwork

Say what is wrong with pom's deploy script before someone runs it It did not work as written for the 0.4.0 deploy and the deploy was done by hand. It cross-compiles, which the native-per-architecture rule forbids and which cargo-zigbuild is not installed to do; it reaches hetzner on a port that refuses this machine's key; and it copies configs over the live ones with no diff and no backup, which is exactly how prod's [targets.mnw.tests] block would have been deleted. Documented rather than rewritten. Fixing it properly means building on each host natively, which changes what the script is, and that deserves its own pass rather than being folded into a deploy.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: Max Johnson <me@maxj.phd> · 2026-07-30 02:27 UTC

Commit: f5fc98178a243790f19bc1c84fd9b1c8f51c501b

Parent: bca468b

1 file changed, +28 insertions, -0 deletions

M pom/deploy/deploy.sh +28

			@@ -1,4 +1,32 @@
1	1		#!/usr/bin/env bash
	2	+	#
	3	+	# STALE. Did not work as written when pom 0.4.0 went out on 2026-07-29, and the
	4	+	# 0.4.0 deploy was done by hand instead. Read this before trusting it.
	5	+	#
	6	+	# Three problems, in order of how much they matter:
	7	+	#
	8	+	# 1. It cross-compiles, which the ecosystem rule forbids: builds are native per
	9	+	# architecture. `cargo zigbuild --target aarch64-...` from fw13 is a cross
	10	+	# build for astra, and cargo-zigbuild is not installed here anyway (only zig
	11	+	# itself). What 0.4.0 actually did: build on astra for astra, build on fw13
	12	+	# for hetzner. Both ends are now x86_64 glibc 2.39 for the hetzner leg, so
	13	+	# that one needs nothing but `cargo build --release`; confirm with
	14	+	# `objdump -T target/release/pom \| grep -o 'GLIBC_[0-9.]*' \| sort -uV \| tail -1`
	15	+	# against the target's `ldd --version` before shipping.
	16	+	# 2. It reaches hetzner on port 2200, which refused this machine's key for both
	17	+	# root and max. The route that worked is Tailscale SSH on 22 as root.
	18	+	# 3. It copies pom-<host>.toml over /etc/pom/pom.toml and pom.service over the
	19	+	# unit, with no diff and no backup. That is how a live-only config block gets
	20	+	# deleted: prod's config carried a [targets.mnw.tests] block this repo did
	21	+	# not have, so running this would have silently dropped prod's remote CI
	22	+	# check. Fixed in MNW@f92eb501, but the hazard is structural, not that one
	23	+	# block. Diff live against the file before installing either.
	24	+	#
	25	+	# What 0.4.0 did instead, per host: back up the binary, /etc/pom/pom.toml, and
	26	+	# pom.db + WAL; `systemctl stop pom`; install the binary; start; then confirm
	27	+	# migrations in the journal and that /api/health, /status.json and /api/versions
	28	+	# all answer 200.
	29	+	#
2	30		set -euo pipefail
3	31
4	32		ASTRA_HOST="max@100.106.221.39"