upaas bind-mounts an existing host directory and sets no container user. A directory made with mkdir as root left pixad unable to write /var/lib/pixa, so the container exited at startup.
Dockerfile: no USER; alpine's su-exec package; the new deploy/docker-entrypoint.sh is the ENTRYPOINT. As root, it gives /var/lib/pixa (the directory, not its contents) to pixad when pixad does not own it, then runs the server as pixad through su-exec. The server never runs as root.
README.md: a "Running under upaas" section.
upaas code the README relies on where its own README is silent, at upaas main97a17e5: buildMounts in internal/docker/client.go bind-mounts the host path as given, and Docker refuses a missing one; CreateContainer in the same file sets no user; checkHealthAfterDelay in internal/service/deploy/deploy.go waits 60 seconds after a deploy, then fails it unless IsContainerHealthy reports healthy.
Checked once by hand: on a root-owned host directory bind-mounted at /var/lib/pixa, the first run fetched and cached an image from an allowed host, and a second run with the same key served it from the cache without fetching it again.
Judgement call: the image's user is now root, so the health probe and docker exec run as root.
Judgement call: the script sits in deploy/, since REPO_POLICIES.md keeps the root for config files and bin/ is build output here.
Judgement call: the README names PIXA_ALLOWLIST_HOSTS and PIXA_CACHE_MAX_BYTES as the variables a deployment usually sets.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/pixa/issues/129, the last unit of https://git.eeqj.de/sneak/pixa/issues/17.
upaas bind-mounts an existing host directory and sets no container user. A directory made with `mkdir` as root left `pixad` unable to write `/var/lib/pixa`, so the container exited at startup.
- `Dockerfile`: no `USER`; alpine's `su-exec` package; the new `deploy/docker-entrypoint.sh` is the `ENTRYPOINT`. As root, it gives `/var/lib/pixa` (the directory, not its contents) to `pixad` when `pixad` does not own it, then runs the server as `pixad` through `su-exec`. The server never runs as root.
- `README.md`: a "Running under upaas" section.
upaas code the README relies on where its own README is silent, at upaas `main` `97a17e5`: `buildMounts` in `internal/docker/client.go` bind-mounts the host path as given, and Docker refuses a missing one; `CreateContainer` in the same file sets no user; `checkHealthAfterDelay` in `internal/service/deploy/deploy.go` waits 60 seconds after a deploy, then fails it unless `IsContainerHealthy` reports `healthy`.
Checked once by hand: on a root-owned host directory bind-mounted at `/var/lib/pixa`, the first run fetched and cached an image from an allowed host, and a second run with the same key served it from the cache without fetching it again.
- Judgement call: the image's user is now root, so the health probe and `docker exec` run as root.
- Judgement call: the script sits in `deploy/`, since `REPO_POLICIES.md` keeps the root for config files and `bin/` is build output here.
- Judgement call: the README names `PIXA_ALLOWLIST_HOSTS` and `PIXA_CACHE_MAX_BYTES` as the variables a deployment usually sets.
Model: opus-5-5
upaas bind-mounts an existing host directory and sets no container
user, so a directory made with mkdir as root left pixad unable to
write /var/lib/pixa, and the container exited at startup.
The image now starts as root: deploy/docker-entrypoint.sh gives
/var/lib/pixa to pixad when pixad does not own it, then runs the
server as pixad through su-exec (alpine's package), so the server
never runs as root. README.md gains a "Running under upaas" section:
port, volume, environment variables, health check, first-run step.
Model: opus-5-5
PASS: the container now starts on a root-owned upaas volume with the server running only as pixad, and the upaas section is accurate against upaas main.
Model: opus-5-5
PASS: the container now starts on a root-owned upaas volume with the server running only as `pixad`, and the upaas section is accurate against upaas `main`.
Model: opus-5-5
clawbot
merged commit 50123b2a6d into next2026-09-28 15:12:48 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #129, the last unit of #17.
upaas bind-mounts an existing host directory and sets no container user. A directory made with
mkdiras root leftpixadunable to write/var/lib/pixa, so the container exited at startup.Dockerfile: noUSER; alpine'ssu-execpackage; the newdeploy/docker-entrypoint.shis theENTRYPOINT. As root, it gives/var/lib/pixa(the directory, not its contents) topixadwhenpixaddoes not own it, then runs the server aspixadthroughsu-exec. The server never runs as root.README.md: a "Running under upaas" section.upaas code the README relies on where its own README is silent, at upaas
main97a17e5:buildMountsininternal/docker/client.gobind-mounts the host path as given, and Docker refuses a missing one;CreateContainerin the same file sets no user;checkHealthAfterDelayininternal/service/deploy/deploy.gowaits 60 seconds after a deploy, then fails it unlessIsContainerHealthyreportshealthy.Checked once by hand: on a root-owned host directory bind-mounted at
/var/lib/pixa, the first run fetched and cached an image from an allowed host, and a second run with the same key served it from the cache without fetching it again.docker execrun as root.deploy/, sinceREPO_POLICIES.mdkeeps the root for config files andbin/is build output here.PIXA_ALLOWLIST_HOSTSandPIXA_CACHE_MAX_BYTESas the variables a deployment usually sets.Model: opus-5-5
PASS: the container now starts on a root-owned upaas volume with the server running only as
pixad, and the upaas section is accurate against upaasmain.Model: opus-5-5