hermes
a6fb61d0ea
Provisions a LAN-only browser code editor (Atheos) in an Alpine 3.23 LXC on the scotty PVE node, with armistace/blog cloned and ready to edit. Built via the AI-DLC workflow; the full process trail is in aidlc-docs/. Deliverables - scripts/provision.sh rebuild the guest from scratch (re-runnable) - scripts/update-atheos.sh move Atheos to latest upstream and RE-PIN - scripts/build-and-test.sh captures evidence for every acceptance criterion - files/atheos.conf nginx vhost (socket path byte-matches the FPM pool) - files/ssh-config ~atheos/.ssh/config deploy-key alias - RUNBOOK.md operational guide (START AT STEP 1) - docs/security-notes.md credential model + wider-web hardening TODOs - docs/resiliency-notes.md what a non-PoC deployment would need Design decisions - D1 no git identity is configured by the agent; the operator sets it. Git will refuse the first commit until then, which is deliberate (requirement FR-11). - D2 Atheos pinned to commit f90cd18 (build 611) with a verified tarball sha256, plus update-atheos.sh as the deliberate escape hatch. - D3 nginx :80, web root /var/www/atheos, php-fpm over a unix socket. - D6 git auth is a per-repository DEPLOY KEY scoped to armistace/blog, not a personal access token (a PAT's write:repository scope reaches every repo the account can write). Verified on the live guest (40 checks, 0 failures) - AC-2 Atheos served over HTTP 200 by nginx+php-fpm; socket paths byte-match - AC-3 20 posts + themes/cleanblog present; owned by the php-fpm user - AC-4 all five writable paths writable as the service user - AC-5 remote targets armistace/blog; deploy key authenticates over SSH - AC-6 survival proven with a real container restart, marker byte-identical - AC-8 no python/pelican/pip/make and no DB engine - scope boundary enforced - FR-11 git identity is empty; deploy key mode 600 owned by the service user Traps documented in the RUNBOOK (each cost real debugging time) - The Gitea SSH user is `gitea`, NOT `git` (app.ini SSH_USER=gitea). With `git`, sshd answers "Invalid user git" and rejects before reading authorized_keys, which is indistinguishable from a bad key. - The Gitea SSH endpoint is the LAN address (:22 is not forwarded publicly). - `uptime` and `free` report the PVE HOST inside an LXC without lxcfs, so a container that just restarted can claim days of uptime.
4.3 KiB
4.3 KiB
Requirement Verification Questions — atheos-blog-lxc
Project: Alpine LXC running Atheos, wired to Gitea, with armistace/blog cloned and ready.
Stage: INCEPTION — Requirements Analysis
Date: 2026-09-29
Answer each question by writing your choice after the [Answer]: tag (e.g. [Answer]: B).
Option X) Other is always available — describe it after the tag.
0. CRITICAL FINDING — please read before answering Q1
Reconnaissance found that armistace/blog is a Pelican static site, not a folder of markdown:
src/content/*.md ← ~20 posts (the actual writing)
src/themes/cleanblog/ ← theme
src/pelicanconf.py ← build config
src/Makefile ← `make html`, `make serve-global`, `make github`
requirements.txt ← pelican[markdown], markdown-markup-emoji
So there are two different needs, and they need different tools:
- Atheos = a browser editor. It edits files and does git (its
codegitcomponent). It can edit the.md, commit and push — but it cannot build or publish the site. - Publishing the site = running
make html(+make github/pelican), which needs Python + pelican, not PHP.
Q1. How important is it that this box can also BUILD/PUBLISH the site?
- A) Editor only — I'll build/publish elsewhere (CI or another box). Atheos just edits + commits.
- B) Also include Pelican — install Python + pelican + make so I can run
make html/make serveon this box to preview and regenerate the site. - C) Also include Pelican AND a local preview server — so I can click through the built site from the browser on this LXC before pushing.
- X) Other (please describe after [Answer]: tag below)
[Answer]:
Q2. Does Atheos's git integration need to work non-interactively (credentials pre-wired), or will you supply them when you first push?
- A) Bake in the git identity + let me push over HTTPS with a Gitea token (I'll give you / you use an existing scoped token) so push works immediately without a prompt.
- B) Clone read-only / leave push to me — set up the clone and git config, but leave the credential to me (e.g. via SSH key I install myself, per my point 4).
- C) Use SSH from the start — configure the remote as
git@git.aridgwayweb.com:armistace/blog.gitand just wait for the key I'll add. - X) Other (please describe after [Answer]: tag below)
[Answer]:
Q3. Which PVE node should host the LXC, and on which storage?
- A) janeway (.225) — 3.3 GB RAM free,
extrastorage 874 GB free. (Recommended: roomy.) - B) data (.42) — only ~0.95 GB RAM free and no swap; a 20 GB guest is fine on disk but the node is tight. (Not recommended.)
- C) You pick whatever is healthiest at build time.
- X) Other (please describe after [Answer]: tag below)
[Answer]:
Q4. Should the container be reachable only on the LAN, or exposed via NPM
(nginx proxy manager) with a hostname like blog-ide.aridgwayweb.com?
- A) LAN only — browse to
http://<lxc-ip>/. Simplest, nothing new exposed. - B) Add an NPM proxy host — I get a hostname; you add the proxy host + DNS (you own NPM).
- C) LAN now, NPM later — build LAN-only, leave a RUNBOOK section for adding NPM.
- X) Other (please describe after [Answer]: tag below)
[Answer]:
Q5. Extensions (AI-DLC security/resiliency baseline). Your usual choice is to opt OUT for a LAN-only PoC, and I document the "what to do if this ever moves external" TODOs instead. Confirm?
- A) Opt out of both, document the TODOs (your standing preference).
- B) Enable security-baseline too.
- C) Enable resiliency-baseline too.
- D) Enable both.
- X) Other (please describe after [Answer]: tag below)
[Answer]:
Notes / assumptions I'll carry unless you say otherwise
- Q6 (implicit, shout if wrong): "downloads … ready for me to use" = the repo is cloned to a path Atheos can open as a project, on the correct branch, with git identity configured — not that the container does anything to the blog's remote. The blog stays a separate repo; this project's repo holds the provisioning.
- LXC defaults I propose: 2 vCPU, 1 GB RAM, 20 GB root, Alpine 3.23,
onboot=1, unprivileged. - I will not touch
armistaceSSH keys — that's your point 4.