An update script that stopped where nobody could see it

Found by running it rather than by reading it. Under `set -euo pipefail` the tag
resolution added in the last commit dies when no release tag exists -- grep exits
1 when nothing matches, and `head -1` closing the pipe early can hand it a
SIGPIPE besides. That is every host until the first release is tagged, which is
every host today. It printed "== fetching ==" and stopped: fetched, not reset,
not restarted, and exit status swallowed by the pipe it was being read through.
The fallback comment two lines above claimed to handle exactly this case.

And the consequence of moving to SSH: install.sh takes REPO_URL from the running
checkout's origin, so whoever pushes over SSH now hands the deployment a URL the
service user cannot use -- it has no key and should not have one, being a
credential that can push to the repository sitting on a box to do a read-only
job. The clone would have failed loudly, with "Permission denied (publickey)"
from an account nobody was thinking about. It is refused up front with the fix
named instead.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Jaroslav Beneš
2026-08-06 21:00:27 +02:00
parent 0c438a6333
commit 32a3b54f1f
3 changed files with 31 additions and 2 deletions
+8 -1
View File
@@ -44,11 +44,18 @@ Everything is overridable from the environment:
| `SERVICE_USER` | `lembas` | system account to run as |
| `HOME_DIR` | `/home/lembas` | that account's home |
| `PREFIX` | `/srv/lembas` | install root (bind mount of `HOME_DIR`) |
| `REPO_URL` | this checkout's `origin` | so a fork deploys itself |
| `REPO_URL` | this checkout's `origin` | so a fork deploys itself. **Must be https** — see below |
| `LEMBAS_BRANCH` | `main` | branch to fetch, and what the `edge` channel follows |
| `LEMBAS_CHANNEL` | `stable` | `stable` follows release tags, `edge` follows the branch tip |
| `INSTALL_UPDATE_HELPER` | `0` | `1` lets the web interface deploy that branch as root |
**The deployment fetches over HTTPS, on purpose.** The service user has no SSH
key and should not have one: a credential that can push to the repository,
sitting on a box, to do a read-only job. If you push over SSH your checkout's
`origin` is an `ssh://` URL, which is the one thing that cannot work here — so
the installer refuses it and names the fix rather than letting the clone fail
with `Permission denied (publickey)` from an account you were not thinking about.
## Channels
| | follows | for |