Give box-firewall.service RemainAfterExit so its state means something

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) <noreply@anthropic.com>
This commit is contained in:
claude-bot-andresmgsl 2026-07-17 14:05:23 +00:00
parent 3e1143f1d3
commit 043e556027
2 changed files with 16 additions and 0 deletions

View file

@ -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

View file

@ -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]