Three things in one setup run, two of them mine.
The server image was 1.11.1 while the host's CLI is 1.11.2, and a
1.11.2 client looks up the domain entry at a UUID 1.11.1 does not
have. So `system domain set-displayname` and `set-image` both failed
with "Item not found", which says nothing about versions. The CLI had
been warning about the mismatch on every single call. Image bumped to
1.11.2; the README says to keep them together and which one to move.
The onboarding token asked for `--rw`, and the flag is spelled
`--readwrite`. The script swallowed stderr and reported a bare warning,
so a step that leaves every invite failing closed said nothing about
why. It now passes the right flag, and if it still fails it says what
the CLI said and prints the command to retry by hand.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Kanidm out of the box presents itself: its own name, its own mark. A
neighbour landing on a login page that belongs to nobody in particular
is right to hesitate about typing a password into it.
The setup script now sets the vel's display name and logo on both the
instance and the portal client. The logo comes from the content repo -
the same images/logo.svg site.yaml already uses as the favicon - so
the login page and the site are branded from one place, and the
branding follows the content rather than this repo.
Left alone deliberately: account recovery by email, and easter eggs.
Both are decisions, not decoration, and the README says so.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The mailer moves in. Portal decides what to send and publishes it on
this NATS; gdo is what hands it to a mail server, and it belongs here
rather than shared, so the vel's mail leaves on the vel's own terms. It
has no mail server of its own and relays through the host's - on kasse,
Klingenberg Bygg's postfix - which is the one thing this stack borrows
and the one line that changes if the vel ever gets a host of its own.
Also:
- portal v0.5.2, four releases on from the v0.3.36 this pinned.
- The Kanidm setup makes the onboarding service account and its token.
The vel's desks invite neighbours, and portal needs a token to do it;
without one every invite fails closed. It goes in
idm_people_on_boarding, which may create a person and issue a first
credential reset and nothing else, plus idm_people_pii_read so an
invite finds someone who already has an account instead of making
them a second one.
- The deploy workflow runs. It was pointed at a `tomtervel` runner
label that has never existed, so every push queued and did nothing.
It now runs on kasse's host runner, which is not root and may run one
argumentless script that pulls this repo and brings the stack up.
- The hosts default to vel.klingenbergbygg.no and
id.vel.klingenbergbygg.no, which is where this actually runs. Both
already resolve to kasse.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The vel keeps its own identity+bus so it can later lift onto a host of its own
unchanged. On kasse it runs in isolation fronted by kasse's host Caddy: kanidm
publishes 127.0.0.1:8443 (shared Kanidm is on 8310) and nats publishes
127.0.0.1:4223 (kasse's shared platform NATS owns 4222). README documents the
two conf.d site blocks (portal -> :3050, id -> https://localhost:8443 with
tls_insecure_skip_verify), the reload port, and the app@ handoff.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- caddy -> profiles: [edge]: on kasse the host Caddy already owns 80/443 and
reverse-proxies vel.klingenbergbygg.no -> 127.0.0.1:3050, so the bundled
Caddy is off by default (use `--profile edge` only on a standalone host)
- portal publishes 127.0.0.1:3050 so the host Caddy reaches it; the existing
conf.d/vel.klingenbergbygg.no target is unchanged
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- bootstrap.sh / kanidm-setup.sh: docker compose -> podman compose; run rootful
(as root) so Caddy can bind 80/443 and Kanidm sees a stable source IP
- compose.yml: remove the in-compose act_runner (it mounted docker.sock) — the
host gitea-runner already covers it; pin the project network to 172.18.0.0/16
so Kanidm's X-Forwarded-For trust (172.16/12) stays valid under Podman, whose
default pool hands out unmatched 10.89.x addresses
- README / deploy.yml: podman + host-runner notes
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
One Kanidm group per committee, named as the content names them, plus
kasserer, styret, komiteer and nabohjelp.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
One host, four containers, content fetched from tomtervel/questions.
bootstrap.sh renders configs from .env and recovers the Kanidm admin;
kanidm-setup.sh creates the portal client and the desk groups. An
optional runner profile lets the content repo's reload reach this host.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
blandClaude Opus 5.5