docs/03-flux.md: clarify that podinfo/hello-app pointing at the same
<VM_IP> in Caddy isn't a routing choice - there's only one VM right now,
doubling as both control plane and workload node, and Traefik is what
actually does per-hostname routing once the request lands there.
index.html: drop the specific "Dell T630" hardware reference from the
public-facing tagline in favor of a generic "Home server".
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
An earlier commit (22acad8) pointed these at git.boglabob.com under the
assumption it was a canonical alias target for the server. Checking the
real zone file shows every other hostname (git, photos, music, etc.) is
a CNAME straight to the bare apex boglabob.com instead - git.boglabob.com
isn't special, just one more independent CNAME. Fix podinfo/hello-app to
match.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
/tmp doesn't exist in the kaniko executor:debug image (confirmed - no
standard FHS layout there at all), so the wget -O target failed with
"No such file or directory". Write into github.workspace instead, which
is known to exist since the build step already uses it.
Also adds the step-7 desktop-vs-k8s clarification from earlier.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
- Distinguish the runner registration token from FORGEJO_TOKEN explicitly
(easy to mix up, causes a confusing "registration token not found" error)
- Split register/daemon into two commands: register is one-shot and exits,
running only it under --restart unless-stopped silently loops forever
instead of ever listening for a job
- Add --userns=keep-id, needed so the container can open the rootless
Podman socket (owned by k8s's host UID, not the container's remapped one)
- Note that <FORGEJO_USER>/<FORGEJO_TOKEN> are placeholders to replace,
not literal syntax, since bash reads a bare <word> as redirection
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
The two commands under step 4 show what imperative Helm install would
look like for comparison, not something to actually run - helm isn't
installed anywhere in this project since Flux handles it declaratively.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
Previous version listed commands with light justification; this
explains the actual mechanism at each stage - qemu:///system vs
session, why pools mediate permissions, COW overlays, what cloud-init's
two data files are for, what each virt-install flag does, what a
kubeconfig actually contains, and (the deepest gap) what flux bootstrap
concretely does under the hood: the controllers/CRDs involved, what
GitRepository and Kustomization objects actually do on their reconcile
loops, why apps.yaml gets picked up automatically, and how the auth
Secret works - with kubectl/flux commands to go verify each claim
against the already-bootstrapped cluster rather than take it on faith.
Rename k8s's key from the custom k3s_homelab to the default
id_ed25519 - the custom name had no real justification (k8s is a
fresh account with nothing to collide with) and caused a real bug:
OpenSSH only auto-offers default-named keys, so ssh commands lacking
an explicit -i silently failed to authenticate. Also add the
never-actually-documented kubectl install step, and mkdir -p ~/.kube
before the first redirect into it, in both SETUP.md and QUICKSTART.md.
Debian's libvirt-daemon-system doesn't auto-create a default storage
pool (network exists but inactive) - added explicit pool-define/build/
start and net-start steps. Also fixed --cloud-init user-data=~/... not
expanding (tilde only expands at start of a shell word, not after =),
and noted why --os-variant may need to be an older release than the
actual image if osinfo-db is stale.
Disk images under k8s's home directory aren't readable by the
libvirt-qemu user that actually runs VMs under qemu:///system. Use
libvirt's own default storage pool (vol-create-as/vol-upload) instead,
so libvirtd handles file ownership rather than k8s directly, and pin
LIBVIRT_DEFAULT_URI=qemu:///system throughout.
