Skip to content

SmallWorlds v1.2.43

Latest

Choose a tag to compare

@github-actions github-actions released this 17 Aug 13:03
· 15 commits to main since this release

Important

Stalwart is no longer installed by default. An overlay that relied on the base for it loses its mail server at this bump. To keep it, add to your overlay's root kustomization.yaml:

  - https://raw.githubusercontent.com/stephan271/smallworlds/v1.2.43/infrastructure/kubernetes/apps/stalwart.yaml

and a stalwart/kustomization.yaml referencing tenants/stalwart at this tag, as for any other optional app.

Mail is opt-in

Mail is an opt-in capability (docs/adr/0049), but the mail server was installed unconditionally — every community ran one whether or not it wanted mail. Nothing in the cluster requires it: onboarding hands out action-token links out of band, and alerting is moving to HTTP push. This is the first piece of that ADR to reach the manifests.

Stalwart leaves the master kustomization and joins OPTIONAL_APPS. Its namespace stays in namespaces.yaml, exactly as every other optional app already behaves. In the Operator Console it moves from a platform service (Required: true) to a community application, and out of the always-installed list its overlay renderer writes, so the renderer and prepare-community-repo.sh still agree file for file.

Bulwark is webmail, not a mail server, so it needs one. It can now be pointed at a mail server outside the cluster — typically another Stalwart on a host with a real IP and PTR, which is often the better deployment anyway. doc/tenant-other.md gains "Bulwark against a mail server outside the cluster" with the three values to patch and the real constraints (JMAP rather than IMAP; an auth scheme shared with this Keycloak; CORS on the external server). prepare-community-repo.sh warns when Bulwark is selected without Stalwart rather than silently shipping a webmail client nobody can log into.

Local installs default to Let's Encrypt

Certificates and internet exposure used to be one question, so a LAN cluster could only have self-signed certificates. They are independent: DNS-01 resolves the challenge through a TXT record, needing no inbound connection and no public A record, so a cluster nobody can reach still gets publicly trusted certificates. The wizard now asks separately — certificates default to letsencrypt, exposure still defaults to no.

This matters more than a browser warning suggests. Every app validates Keycloak's certificate against its own trust store with no override, so with self-signed certificates single sign-on does not work at all — Immich reports only Error in OAuth discovery: TypeError: fetch failed, naming neither TLS nor Keycloak. Devices that pin a certificate (the pod archive) must also be re-pinned at every renewal, on every member's hardware. Self-signed remains available for throwaway clusters, and the prompt now says what it costs.

Two related fixes: the Hetzner token was withheld from any LAN-only install, which with ACME as the default would leave cert-manager holding an empty token while the issuer reported Ready and every certificate sat pending with nothing saying why. It is now withheld only when the install does no DNS at all. And doc/local-deployment.md claimed HTTP-01 in two places when both bootstraps have always used DNS-01; its conversion recipe also claimed an issuer's type cannot be changed in place, when a merge patch nulling selfSigned while adding acme is accepted.

Removed

The golden-image rebuild workflow. It needed a Hetzner Cloud token as a repository secret — a token that cannot be scoped to a resource, so the trade was full account control in CI in exchange for staging boot speed. It never made that trade: no secret was ever set, and every scheduled run failed one second in. Nothing depended on it; test-pr-locally.sh falls back to a plain image, and admin-tools/build-golden-image.sh stays for manual runs.

Bootstrap inputs

Unchanged from v1.2.42: k3s v1.36.2+k3s1, Argo CD v3.4.5, both digests re-verified against their official sources.