An update you can ask for, and a boundary that stays where it was
The button cannot do the work, and that is the whole design. The service runs as an unprivileged account, cannot restart itself, and should not be able to: a web application that can restart its own service is one whose worst day is much worse. So /admin/updates writes a file, and an opt-in systemd .path unit runs deploy/update.sh as root. Three properties hold it up, and each is a thing that could have been got wrong. The request file carries nothing that reaches a command line -- no branch, no ref, no arguments -- because the branch is baked into the unit at install time, so pressing the button is always "deploy the branch this host was configured with" and can never be "deploy something else". It is off unless somebody passes INSTALL_UPDATE_HELPER=1, and re-running the installer without it removes both units and the marker. And without the helper the page says so and prints the manual command rather than writing a file nothing is watching, which would be a button that reports success and does nothing. The card that says all of this is rendered whether or not there is anything to apply. It was inside the "there is an update" branch first, so an administrator could not discover the helper was missing until the day they needed it, which is the worst possible moment. Opening the page makes no network request; Check is the one thing that fetches. And it shows the log between, not a count: "3 behind" is a number somebody has to go and look up, while the subjects are what decides whether this is worth restarting for right now. Docker is one stage, because there is nothing to build -- no Node, no compiled assets. It bakes no secret key (one in an image is one every copy shares, and rotating it makes stored API keys unreadable), no data, and no .git, so /admin/updates inside a container correctly reports that it was not installed from a checkout. Compose publishes on loopback and refuses to start without a key. TLS in front is a constraint rather than a recommendation: the service worker and the microphone both require HTTPS or localhost. The image was built and run before this was committed, which is how the missing COPY of LICENSE was found -- pyproject declares it and the build backend reads it, so the failure reads like a packaging problem and is one line. deploy/lxc-install.sh creates an unprivileged Debian container and runs the existing installer inside it. A wrapper, not a second install path: a parallel installer is two things to keep correct and one of them rots. /healthz opens the database rather than only proving the socket is listening -- a process that is up with a database it cannot open answers every page with a 500 -- and says nothing about what is here, being reachable without signing in. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -20,7 +20,7 @@ lembas info # paths + counts, useful when confused
|
||||
lembas secret-key # generate LEMBAS_SECRET_KEY
|
||||
lembas create-admin # create or promote an admin
|
||||
|
||||
pytest # 2062 tests, ~2min
|
||||
pytest # 2081 tests, ~2min
|
||||
# PLAN.md tracks what is and is not built
|
||||
ruff check . # lint (line length 100)
|
||||
python scripts/build_artwork.py # regenerate artwork (SVG + PWA icons;
|
||||
@@ -91,6 +91,8 @@ src/lembas/
|
||||
admin_prompts.py the prompt fragment editor and its preview
|
||||
admin_branding.py the name, the logo, the wording and the themes
|
||||
admin_extraction.py what a file may cost, and what finds it afterwards
|
||||
admin_updates.py what is running, what is available, and a button that
|
||||
writes a file rather than doing the work
|
||||
branding.py /branding.css and the assets behind it, both unauthenticated
|
||||
admin_suggestions.py the cards offered on the new-chat screen
|
||||
admin_tools.py custom HTTP tools and MCP servers
|
||||
@@ -143,6 +145,8 @@ src/lembas/
|
||||
sharing.py one visibility rule for every library store
|
||||
usage.py what an account spent this month, and whether it may spend
|
||||
more -- written even when the reply failed
|
||||
updates.py the running commit, the remote's, and the request file the
|
||||
helper watches for
|
||||
prompts.py every injected prompt fragment, and {{variables}}
|
||||
metrics.py tokens, context percentage and tokens/second
|
||||
tokens.py the chars/4 estimate, for endpoints that report none
|
||||
@@ -181,7 +185,10 @@ src/lembas/
|
||||
js/canvas.js the canvas panel's three behaviours
|
||||
js/composer.js the menu / and @ open, and the mirror that marks them
|
||||
assets/ SVG masters and PWA icons (generated)
|
||||
deploy/ systemd unit, nginx vhost, install/update scripts
|
||||
deploy/ systemd unit, nginx vhost, install/update scripts, the
|
||||
opt-in update helper, and an LXC bootstrap
|
||||
Dockerfile one stage; no secret and no data baked in
|
||||
docker-compose.yml loopback only, one replica, TLS proxy expected in front
|
||||
docs/notes/ the rest of "Things that will bite you", by topic
|
||||
```
|
||||
|
||||
@@ -1678,10 +1685,31 @@ inlined and themed. If the mark changes, update both.
|
||||
## Deployment
|
||||
|
||||
`deploy/` holds a systemd unit template, an nginx vhost template, and
|
||||
install/update scripts. Both templates are parameterised (`__PREFIX__`,
|
||||
install/update scripts. Every template is parameterised (`__PREFIX__`,
|
||||
`__SITE_HOST__`, …) and substituted at install time, so nothing host-specific is
|
||||
committed here. See `deploy/README.md`.
|
||||
|
||||
**The update button cannot do the work, and that is the design.** The service
|
||||
runs unprivileged and cannot restart itself; a web application that *can* is one
|
||||
whose worst day is much worse. So `/admin/updates` writes a file and an **opt-in**
|
||||
systemd `.path` unit runs `deploy/update.sh` as root. Three properties hold it
|
||||
together: the request file carries nothing that reaches a command line (the
|
||||
branch is baked into the unit at install time, so the button is always "deploy
|
||||
the branch this host was configured with"), it is off unless
|
||||
`INSTALL_UPDATE_HELPER=1`, and without it the page says so and prints the manual
|
||||
command. `services/updates.py` runs git with a fixed argv and `shell=False` --
|
||||
which is not the "nothing executes on this machine" rule being bent, since that
|
||||
rule is about a *model's* commands and this is an administrator pressing a
|
||||
button.
|
||||
|
||||
**Docker is one stage and bakes nothing.** No secret key (one in an image is one
|
||||
every copy shares, and rotating it makes stored API keys unreadable), no data,
|
||||
and no `.git` -- so `/admin/updates` inside a container correctly says it was not
|
||||
installed from a checkout. `docker-compose.yml` publishes on loopback and expects
|
||||
a TLS proxy: the service worker and the microphone both require HTTPS or
|
||||
localhost, so plain http on a LAN address is a constraint rather than a
|
||||
preference.
|
||||
|
||||
This repository is **public**. Keep deployment-specific hostnames, ports and
|
||||
internal infrastructure detail out of it — those belong in whatever private
|
||||
notes describe the machine.
|
||||
|
||||
Reference in New Issue
Block a user