Jaroslav Beneš
ddad585e4b
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>
58 lines
2.4 KiB
YAML
58 lines
2.4 KiB
YAML
# LLeMbas, and nothing else.
|
|
#
|
|
# Deliberately no reverse proxy in here. Which one to use, where the certificate
|
|
# comes from and what else the host already serves are all decisions this file
|
|
# cannot make -- and baking one in would mean anybody who already runs Caddy or
|
|
# Traefik has to unpick it first. What this does is publish on loopback, which is
|
|
# what a proxy on the same host proxies to.
|
|
#
|
|
# **TLS is not optional in practice.** The service worker and the microphone both
|
|
# require HTTPS or localhost, so over plain http on a LAN address the app cannot
|
|
# be installed and cannot dictate. See deploy/README.md.
|
|
|
|
services:
|
|
lembas:
|
|
build: .
|
|
image: lembas:latest
|
|
restart: unless-stopped
|
|
|
|
environment:
|
|
# Generate once and keep it: rotating this signs every user out *and*
|
|
# makes stored upstream API keys unreadable, because they are encrypted
|
|
# with it. `lembas secret-key` prints one.
|
|
#
|
|
# Required with no default on purpose. A compose file with a key in it is
|
|
# a key in everybody's git history, and one that quietly generated a
|
|
# temporary one would lose every stored credential on the next restart.
|
|
LEMBAS_SECRET_KEY: ${LEMBAS_SECRET_KEY:?set LEMBAS_SECRET_KEY in .env}
|
|
LEMBAS_DATA_DIR: /data
|
|
LEMBAS_HOST: 0.0.0.0
|
|
LEMBAS_PORT: 8080
|
|
LEMBAS_LOG_LEVEL: ${LEMBAS_LOG_LEVEL:-info}
|
|
LEMBAS_ALLOW_SIGNUP: ${LEMBAS_ALLOW_SIGNUP:-true}
|
|
|
|
# 127.0.0.1 rather than 0.0.0.0: the session cookie is deliberately not
|
|
# marked `secure` so a localhost install can sign anybody in at all, which
|
|
# means a network attacker on plain http could steal a session. Publishing
|
|
# this on a LAN interface without a proxy in front is the one configuration
|
|
# that turns that from a note into a problem.
|
|
ports:
|
|
- "127.0.0.1:8080:8080"
|
|
|
|
volumes:
|
|
# The database, the uploads, the encryption at rest. A named volume rather
|
|
# than a bind mount so it survives `docker compose down` -- `down -v` is
|
|
# the command that deletes it, and that asymmetry is the point.
|
|
- lembas-data:/data
|
|
|
|
# One worker, and that is not a shortcut. The generation registry, the stop
|
|
# mechanism, the terminal sessions and the schedule ticker are all
|
|
# in-process; two of these would mean two tickers and every schedule firing
|
|
# twice. Scaling this service is not supported -- see PLAN.md's first known
|
|
# limit.
|
|
deploy:
|
|
replicas: 1
|
|
|
|
volumes:
|
|
lembas-data:
|