Record the #116/#117 storage and viewer work

#117 done: stowage was dead on an arm64 digest pin, not a MinIO fault.
#116 staged: rustfs runs on 9010/9011, buckets not mirrored, no cutover.

Also logs the ISP port 80/443 interception that made three external
reachability measurements worthless, so the next session does not repeat them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-11 22:05:23 +04:00
parent 0cc6302245
commit b2cd11dd1c
2 changed files with 65 additions and 5 deletions
+47
View File
@@ -20,3 +20,50 @@ Produced: `decisions/audit-phase1.md`, `caveats/audit-open.md`, `ROADMAP.md`, an
One existing test asserted the bug: `test_name_binding.test_conflict_flags_and_stays_unnamed` relied on
orphan flags leaking into every chapter, because it never created panel rows. It now creates them.
## 2026-08-11 Orchestrator half committed and deployed [no task]
Command: `pytest -q --ignore=test_api.py`, then `docker compose up -d --build orchestrator` on homesrv.
Outcome: finished. 108 tests pass. Commits `1c60710` (orchestrator half) and `94bd4d8` (minio pin) in
`/mnt/server/home/kami/docker-apps`. Orchestrator and minio both answer health on homesrv.
The rebuild recreated `minio` as a side effect and it crash-looped with `exec format error`: the
compose pin was the arm64 manifest digest of `minio/minio:latest` and homesrv is amd64. Repinned to the
amd64 digest. Nothing about Phase 1 caused this, but any compose action that recreates minio would have
hit it, so it was latent, not new.
Still unrun against a real chapter.
## 2026-08-11 S3 viewer and storage swap, tasks #116/#117 [#116 #117]
Command: docker compose on homesrv, `dig`, `openssl s_client`. No pipeline, no GPU.
Outcome: partial. Viewer works, storage swap staged and unfinished.
#117 needed no new software. `stowage` at `~/docker-apps/stowage` was already configured against the
manga MinIO and had been dead since 2026-07-19 with `exec /sbin/tini: exec format error`: its digest
pin was the arm64 manifest. Repinned to amd64 `sha256:91be7f13`, chowned `data/` to uid 65532 for the
new image, and it serves. MinIO had the identical bug, repinned to `sha256:a1a8bd4a`. A sweep of all
470 local images on homesrv found exactly those two arm64; nothing else in the homelab is affected.
#116 is staged, not done. `rustfs` runs alongside MinIO on `127.0.0.1:9010/9011`, pinned
`sha256:19b105cc`, data at `/mnt/hdd2/rustfs`. Buckets are empty: the `mc` mirror of
`audio layers manga panels raw video` (350M, all in `manga`) has NOT run. `/mnt/hdd2/minio/data` is
untouched and is the rollback. RustFS is `1.0.0-beta.12`, labeled `build-type=prerelease`. Cutover
would give rustfs 9000/9001 and repoint `MINIO_ENDPOINT=minio:9000` in the orchestrator plus
`stowage/config.yaml`; `transport.py:95` needs no change if rustfs takes `192.168.1.104:9000`.
Side quest, unrelated to the pipeline: the shared 41-domain cert stopped renewing. Root cause was DNS,
not nginx. Every `*.kvmx.ru` name pointed at a hard A record for `109.229.102.117` while the line had
moved to `109.229.127.149`; the Mercusys DDNS at `kvmx-home.mercusysddns.com` was correct the whole
time but nothing in the zone referenced it. Fixed with `CNAME * -> kvmx-home.mercusysddns.com` at
reg.ru. Certificate now issues.
Two measurement traps worth remembering. The ISP transparently intercepts ports 80 and 443 by
Host/SNI, so `curl` from workpc to ANY address returns kvmx.ru content and proves nothing about
external reachability; bare TCP connects also succeed against arbitrary addresses and then hang. Three
wrong root causes came out of trusting those probes before checking them.
Also patched `~/scripts/migrate-kvmx-https.sh:54` on homesrv. `need_stream_module` used
`sudo -n nginx -V` and `sudo -n nginx -T`; the NOPASSWD rule covers only `nginx -t`, so it reported
"stream module is not loaded" whenever it meant "could not ask for a password". Both checks now run
without sudo. `bash -n` passes and both conditions evaluate true.
+18 -5
View File
@@ -17,17 +17,30 @@ Verification: CPU-only self-checks and the orchestrator test suite. 108 orchestr
(`test_api.py` is excluded on workpc because fastapi is not installed in this venv). No GPU work ran
and no pipeline ran, so none of this is confirmed against a real chapter.
The orchestrator changes are edited in place on the SSHFS mount and are NOT committed. Its git root is
`/mnt/server/home/kami/docker-apps`. Its container also needs a rebuild or restart to pick them up.
The orchestrator half is committed as `1c60710` in `/mnt/server/home/kami/docker-apps` and the
container is rebuilt and serving. `94bd4d8` in the same repo repins minio to its amd64 digest, which
the rebuild exposed.
## Next
1. Commit the orchestrator half in `/mnt/server/home/kami/docker-apps` and restart the container.
2. Run one labeled chapter end to end and record the baseline numbers from `ROADMAP.md`, especially the
1. Run one labeled chapter end to end. Record the baseline numbers from `ROADMAP.md`, above all the
share of narrated lines with a named speaker. That number is the check on the largest Phase 1 fix.
3. Start Phase 2 from `ROADMAP.md`. Set SQLite `busy_timeout` before any concurrency work
2. Start Phase 2 from `ROADMAP.md`. Set SQLite `busy_timeout` before any concurrency work
(`caveats/audit-open.md#sqlite-locking`).
## Storage and viewer, tasks #116/#117
[#117] is done. `stowage` serves the manga buckets. It was never a MinIO problem: the container had
been dead since 2026-07-19 on an arm64 digest pin. Details in `JOURNAL.md`.
[#116] is staged and unfinished. `rustfs` runs on `127.0.0.1:9010/9011` with empty buckets. The next
step is the `mc` mirror of the six buckets, then verify object counts and sizes against MinIO, then
decide on cutover. Nothing is repointed yet and MinIO still serves every read and write.
Two things to weigh before cutover, neither settled. RustFS is `1.0.0-beta.12`, labeled
`build-type=prerelease`. Swapping storage before the baseline chapter run also adds a variable to the
run that is meant to produce the baseline.
## Open questions
Four Phase 1 items have no Vikunja task and were not created, because writing to the tracker was not