Skip to main content

max / makenotwork

pom: deploy the Hetzner node as pom@, and make the account exist The node's ssh_target was root@alpha-west-1, which never authenticated. sandod runs as `sando` on fw13 and that user's ssh config maps the host to port 2200, the box's own sshd, so Tailscale SSH never saw the connection and root would have needed sando's key in its authorized_keys on production. `pom` was already the user the unit runs as, and was a nologin system account with no home. It now has both, sando's key pinned with restrict,from="100.103.89.95", and a sudoers grant scoped to the three systemctl verbs sandod uses. That is makenotwork@alpha-west-1's arrangement on the same machine, tightened by the from= clause. bootstrap-pom-node.sh ran there with DEPLOY_USER=pom: /opt/pom owned by pom, the running 0.4.1 seeded as releases/preexisting-0.4.1, ExecStart moved to current/pom by a drop-in. The node is on the version it went in on. The loopback health_url is honest on this node, and the comment now says why rather than leaving it to be re-derived: this instance binds 0.0.0.0, so 127.0.0.1:9100 answers with pom's own JSON. That is the check astra failed.
Co-Authored-By
Claude Opus 5 (1M context) <noreply@anthropic.com>
Author: Max Johnson <me@maxj.phd> · 2026-08-16 17:04 UTC
Signed with PGP, not checked
Commit: 0576d7067f653fd68d11ae4de856da4fb530a57f
Parent: 2beeb21
1 file changed, +20 insertions, -15 deletions
M sando/pom-topology.toml +20 -15
@@ -87,23 +87,28 @@
87 87 [[tier.node]]
88 88 name = "hetzner"
89 89 platform = "linux/x86_64"
90 - # STILL root@, and it does not work: measured 2026-08-15, `Permission denied
91 - # (publickey)`. Not Tailscale SSH, whatever this line used to say. sandod runs
92 - # as the `sando` user on fw13 and that user's ~/.ssh/config maps `alpha-west-1`
93 - # to port 2200, which is the box's own sshd; Tailscale SSH is 22 and never sees
94 - # the connection, so reaching root this way would mean sando's key in root's
95 - # authorized_keys on a production box.
90 + # `pom@alpha-west-1` as of 2026-08-16, and the account it names now exists.
91 + # This was `root@alpha-west-1`, which never worked: sandod runs as the `sando`
92 + # user on fw13 and that user's ~/.ssh/config maps `alpha-west-1` to port 2200,
93 + # the box's own sshd. Tailscale SSH is 22 and never saw the connection, so
94 + # reaching root that way would have meant sando's key in root's authorized_keys
95 + # on a production box.
96 96 #
97 - # DECIDED 2026-08-15 (Max): become `pom@alpha-west-1` instead, matching
98 - # `makenotwork@alpha-west-1` on the same machine — a service user holding
99 - # sando's key and a sudoers grant scoped to `systemctl reload-or-restart
100 - # pom.service`, and no root login for a deploy daemon anywhere.
97 + # The account matches `makenotwork@alpha-west-1` on the same machine, which is
98 + # the house pattern: the service user the unit already runs as, holding sando's
99 + # key and a sudoers grant scoped to the three systemctl verbs sandod uses. It
100 + # was a nologin system account until the cutover gave it a home and a shell.
101 + # Sando's key is pinned there with `restrict,from="100.103.89.95"`, which is
102 + # tighter than makenotwork's bare key line and still allows the rsync leg.
101 103 #
102 - # Left as root@ until that account exists, because the `pom` user there is a
103 - # nologin system account today and a target nothing can log into is worse than
104 - # one that is honestly wrong. The rename and the account land in one pass, with
105 - # `bootstrap-pom-node.sh DEPLOY_USER=pom` doing the node half.
106 - ssh_target = "root@alpha-west-1"
104 + # Node half done by `bootstrap-pom-node.sh DEPLOY_USER=pom`: /opt/pom owned by
105 + # pom, the running 0.4.1 seeded as releases/preexisting-0.4.1 with `current`
106 + # pointing at it, ExecStart moved by /etc/systemd/system/pom.service.d/
107 + # 20-release-root.conf. The node came out of it on the version it went in on.
108 + ssh_target = "pom@alpha-west-1"
107 109 release_root = "/opt/pom"
108 110 service_name = "pom.service"
111 + # Loopback is honest here, unlike astra's: this instance binds 0.0.0.0, and
112 + # 127.0.0.1:9100 on the node answers with pom's own health JSON rather than
113 + # some other daemon's index page. Verified 2026-08-16, before the first promote.
109 114 health_url = "http://127.0.0.1:9100/api/health"