admin
2b22a23d60
Campaign 10's R-156 found papra writing its database into the container's writable layer while the volume the template preserves stayed empty — a backup that completes, verifies, and contains nothing. papra was never the point: nothing anywhere checked that the folder a template preserves is the folder the app writes to. All 53 templates have now been measured live. 43 CLEAN / 3 BROKEN / 7 UNDETERMINED. UNDETERMINED is counted separately, each with its reason, and never folded into CLEAN. FIXED (neither app is deployed anywhere, so nothing was stranded): - gramps-web mounted /app/data, /app/media, /tmp — and /app/data is a path the application never writes. Its accounts database and ITS FAMILY TREE both landed in the writable layer while gramps_data was tarred nightly as an empty directory. Now persists the eight paths the image's own environment names, matching upstream's reference compose. Proven: users.sqlite and the family-tree files survive a redeploy byte-identical, same inode. - wishlist mounted wishlist_data:/data, another path the app never writes; prod.db landed in the ANONYMOUS volume from the image's VOLUME directive — absent from ResolveDockerVolumeNames, so never backed up, and orphaned by a redeploy. Now mounts /usr/src/app/data + /usr/src/app/uploads. Proven: prod.db byte-identical, same inode, across a redeploy. Every corrected path confirmed by two independent sources — the shipped image's own environment/Config.Volumes and upstream's reference compose — never inferred from a directory name. papra is NOT fixed. It is live on one box, and changing the mount target makes the next compose up recreate the container and destroy the writable layer its documents live in. The fix is prepared and proven in the scratch guest (current: db.sqlite differs after a redeploy, so a real account created via the API is lost; fixed: byte-identical, it survives). Referred to the operator with the two options; no migration written. NEW GATE scripts/check-volume-persistence.py — the third catalog gate and the only RUNTIME one. This class is invisible to static analysis, measured not assumed: a static audit of all 53 composes reports the catalog clean AND reports papra clean. Exit 0 clean / 1 REFUSED / 2 undecided. It refuses to report at all unless it has just re-proven itself in both directions against two canary templates that differ only in which path the volume mounts at, so every run carries a live demonstration of R-156 and of its fix. No docker exec anywhere (Campaign 7 §1.1). 44 fixture tests driving check(), the function __main__ calls; every rule red-proofed. Enforcement is convention, not CI — this repo has no CI. Stated plainly in the report; raising it is proposed as R-160. Report, per-app evidence, proofs and proposed register entries (R-158..R-161, NOT filed — felhom.eu is fenced this session): audits/persistence-sweep-2026-08-02/
61 lines
2.4 KiB
YAML
61 lines
2.4 KiB
YAML
# Wishlist - Családi kívánságlista megosztás
|
|
# Domain: ${SUBDOMAIN}.${DOMAIN}
|
|
# Database: None (file-based)
|
|
# RAM: ~30M (mem_limit: 128M) | Pi-compatible: Yes
|
|
#
|
|
# Environment variables:
|
|
# DOMAIN - Your domain (e.g., demo-felhom.eu)
|
|
|
|
services:
|
|
wishlist:
|
|
image: ghcr.io/cmintey/wishlist:v0.66.0
|
|
container_name: wishlist
|
|
restart: unless-stopped
|
|
environment:
|
|
- TZ=Europe/Budapest
|
|
volumes:
|
|
# Storage layout. The image declares `VOLUME /usr/src/app/data` and
|
|
# `VOLUME /usr/src/app/uploads` (docker image inspect → Config.Volumes), and upstream's own
|
|
# compose mounts exactly those two. `/data` — what this template used to mount — is a path
|
|
# the application never writes.
|
|
#
|
|
# The consequence, measured 2026-08-02: `prod.db` landed in the ANONYMOUS volume docker
|
|
# created for the image's VOLUME directive. An anonymous volume survives a restart, which is
|
|
# what makes it deceptive — but it is absent from ResolveDockerVolumeNames
|
|
# (felhom-controller internal/appbackup/appdata.go, which only returns <project>_<name> for
|
|
# volumes DECLARED here), so DumpAppVolumes never backs it up, and `compose down` + `up`
|
|
# orphans it and creates a fresh empty one. Meanwhile `wishlist_data` was tarred every night
|
|
# as an empty directory.
|
|
- wishlist_data:/usr/src/app/data
|
|
- wishlist_uploads:/usr/src/app/uploads
|
|
networks:
|
|
- traefik-public
|
|
deploy:
|
|
resources:
|
|
limits:
|
|
memory: 128M
|
|
healthcheck:
|
|
# A wishlist képfájlban nincs wget és nincs curl — csak node. A korábbi
|
|
# wget próba ezért soha nem futott le, a konténer véglegesen unhealthy
|
|
# maradt, és a Traefik nem irányított rá forgalmat (404).
|
|
test: ["CMD", "node", "-e", "const http=require('http');http.get('http://127.0.0.1:3000',r=>process.exit(r.statusCode<500?0:1)).on('error',()=>process.exit(1))"]
|
|
interval: 30s
|
|
timeout: 5s
|
|
retries: 3
|
|
start_period: 30s
|
|
labels:
|
|
- "traefik.enable=true"
|
|
- "traefik.http.routers.wishlist.rule=Host(`${SUBDOMAIN}.${DOMAIN}`)"
|
|
- "traefik.http.routers.wishlist.entrypoints=websecure"
|
|
- "traefik.http.routers.wishlist.tls=true"
|
|
- "traefik.http.routers.wishlist.tls.certresolver=letsencrypt"
|
|
- "traefik.http.services.wishlist.loadbalancer.server.port=3000"
|
|
|
|
volumes:
|
|
wishlist_data:
|
|
wishlist_uploads:
|
|
|
|
networks:
|
|
traefik-public:
|
|
external: true
|