ansible: manage the Caddy apt repo + signing key on kai-server so it self-heals #455
Labels
No labels
burndown-2026-06
coherence-core
consult
headless
interactive
P0
P1
P2
P3
P4
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
coilyco-flight-deck/infrastructure#455
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Why
The docker-ce converge (infrastructure#450) failed at
apt-get update- not on the docker repo (that fetched fine) but on an unrelated stale source:Caddy is a real running service on kai-server (v2.10.2, active+enabled). Its signing key
ABA1F9B8875A6661expired; upstream rotated to155B6D79CA56EA34(no expiry). Because the key was hand-installed and unmanaged, it expired silently and now any apt operation on the box fails - it just happened to surface via the docker converge.Fix (object-level, done out of band)
Refresh
/usr/share/keyrings/caddy-stable-archive-keyring.gpgfromhttps://dl.cloudsmith.io/public/caddy/stable/gpg.key. Verified: refreshed key validates the repo (Get: InRelease+Packages, no errors).Meta (this issue)
Add an ansible
caddyrole (or fold into an existing one) that manages the Caddy apt repo + keyring the same way thedockerrole manages docker's -get_urlthe current key to a keyring path,deb822_repositorythe source. Then a rotated/expired upstream key self-heals on the next converge instead of silently breaking the whole fleet's apt. Same authoring-vs-rollout pattern as the docker role.Gate to kai-server (where Caddy runs) like the docker role. Origin: surfaced during the docker-ce converge, infrastructure#450.
WARD-RESERVATION: held 🔒
reservation details
Holder: container
engineer-codex-infrastructure-455on hostkais-macbook-pro-2.local.Reserved by
ward agent --harness codex(reserved 2026-07-10T11:32:38Z). Concurrentward agentruns are blocked until it finishes or the reservation goes stale (1h TTL).--forceoverrides.Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).
run seed context — what this run is carrying (ward#609)
coilyco-flight-deck/infrastructure#455· branchissue-455· harnesscodex· workflowdirect-mainengineer-codex-infrastructure-455· wardv0.580.0· dispatched2026-07-10T11:32:38ZStatic container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.580.0).
— Codex, via
ward agentWARD-OUTCOME: done
details
workflow: direct-to-main; review summary: skipped by ~/.ward/config.yaml default. review gate skipped by ~/.ward/config.yaml default. Felt like a straightforward role-add plus one merge/doc-size cleanup. Confidence: high. Surprises: Forgejo CI stayed queued after the push, and the repo-verb helper required a synced clean tree. Follow-ups: none.