From 043e556027d1287bacedb4e112d894b058a60655 Mon Sep 17 00:00:00 2001 From: claude-bot-andresmgsl Date: Fri, 17 Jul 2026 14:05:23 +0000 Subject: [PATCH] Give box-firewall.service RemainAfterExit so its state means something MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Found by running the drill on a real host, which I could not do before. The unit is Type=oneshot with no RemainAfterExit, so systemd marks it 'inactive (dead)' the moment ExecStart succeeds. The rules are applied and the box-to-box drop is live, and the unit still reads as though it died. That is precisely the question people ask this unit: drill.sh's own failure hint sends you to 'systemctl status box-firewall.service' to find out whether the firewall came up, and today the honest answer and the alarming one look identical. setup-host.sh already believed this was set — 'The unit is RemainAfterExit, so once it has run it stays "active" forever' — and reasoned from it to explain why it uses restart instead of 'enable --now'. The reasoning is right and the restart is right; only the unit was missing the line the comment assumed. Verified live: before, 'nft list table bridge box' showed the drop present while is-active said inactive. After, is-active says active (exited) with the drop still present, and restart still re-applies. Co-Authored-By: Claude Opus 4.8 (1M context) --- CHANGELOG.md | 9 +++++++++ host/box-firewall.service | 7 +++++++ 2 files changed, 16 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 884c6e8..23e6c9b 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -28,6 +28,15 @@ which records not just what changed but what each drill run proved. `sudo install.sh` it would have added `root` to the group: a no-op (UID 0 opens the socket regardless) that also left the actual user locked out of their own boxes. It now derives the login user from `SUDO_USER`. +- **`box-firewall.service` now reports its state honestly** — the unit is + `Type=oneshot` and was missing `RemainAfterExit=yes`, so it went + `inactive (dead)` the instant it succeeded: a host whose isolation was + perfectly live read as one whose firewall unit had died. drill.sh sends you + to `systemctl status box-firewall` to diagnose exactly that, and + setup-host.sh's own comment already asserted the unit "is RemainAfterExit" — + it was not. Found by running the drill on a real host and mistrusting the + green: `nft list table bridge box` showed the drop live while the unit read + dead. `restart` was and remains correct either way. - **`setup-host`'s apt calls can no longer hang** — a fresh cloud image has `apt-daily`/`unattended-upgrades` holding the dpkg lock, and a plain `apt-get install` waits on it silently and indefinitely. Now bounded diff --git a/host/box-firewall.service b/host/box-firewall.service index 9b78370..de949a5 100644 --- a/host/box-firewall.service +++ b/host/box-firewall.service @@ -6,6 +6,13 @@ Wants=network.target [Service] Type=oneshot +# The unit's state must mean "the rules are applied", because that is the +# question everyone asks it — drill.sh sends you to 'systemctl status +# box-firewall' to diagnose exactly that. Without this, a oneshot goes +# 'inactive (dead)' the moment it succeeds, so a host whose isolation is +# perfectly live reads as a host whose firewall unit died. setup-host.sh's +# comment already assumed this was set; it was not. +RemainAfterExit=yes ExecStart=/usr/local/sbin/box-firewall [Install]