fix(ical-proxy): pin the image so a new build actually rolls

:latest never rolls. The tag moves when a build publishes, but nothing
tells the Deployment: the pod template is unchanged, so Kubernetes has
no reason to replace anything.

Nothing else covers it either. This image is deliberately not enrolled in
Flux image automation — kubernetes/infrastructure/image-automation/README.md
lists ghcr.io/konairius/ical-proxy as having "only main, latest, and
main-<sha> commit builds; no release tags", so no ImagePolicy watches it.
The two pods have been running a 21-day-old image while :latest moved
underneath them, and the only way to pick up a new build was a manual
restart, which leaves no record anywhere.

Pinning makes the rollout a git change. Flux applies the new pod
template, Kubernetes rolls it, and what is RUNNING becomes recoverable
from this repo instead of "whatever :latest meant the last time a pod
happened to restart".

main-99a912b is the merge of konairius/ical-proxy#12, which adds the
summary_match and summary_replace parameters. The waste calendar needs
them to strip "| Abfuhrkalender - Landkreis Amberg-Sulzbach" from every
collection — the feed repeats the whole calendar's name on each event,
and no consumer can shorten it after the fact.

Bumping this tag is now a manual, reviewed edit. Format is
main-<short-sha>, from docker/metadata-action type=sha with the branch
as prefix.

kubernetes/apps/ical-proxy/deployment.yaml

@@ -17,7 +17,33 @@ spec:
     spec:
       containers:
         - name: ical-proxy
-          image: ghcr.io/konairius/ical-proxy:latest
+          # Pinned to a commit build rather than :latest.
+          #
+          # :latest never rolls. The tag moves when a build publishes, but
+          # nothing tells the Deployment about it: the pod template is
+          # unchanged, so Kubernetes has no reason to replace anything, and
+          # this image is deliberately NOT enrolled in Flux image automation
+          # — see kubernetes/infrastructure/image-automation/README.md, which
+          # lists ghcr.io/konairius/ical-proxy as having "only main, latest,
+          # and main-<sha> commit builds; no release tags", so there is no
+          # ImagePolicy watching it. The pods therefore sat on a 21-day-old
+          # image while :latest moved underneath them, and the only way to
+          # pick up a new build was a manual restart.
+          #
+          # A pinned tag makes the rollout a git change: Flux applies the new
+          # pod template and Kubernetes rolls it, which is also what makes
+          # what is RUNNING recoverable from this repo rather than "whatever
+          # :latest meant the last time a pod happened to restart".
+          #
+          # main-99a912b is the merge of konairius/ical-proxy#12, which adds
+          # the summary_match/summary_replace parameters this deployment
+          # needs to strip "| Abfuhrkalender - Landkreis Amberg-Sulzbach"
+          # from every waste collection.
+          #
+          # Bumping this is a manual, reviewed edit. The tag format is
+          # main-<short-sha> (docker/metadata-action type=sha with the branch
+          # as prefix).
+          image: ghcr.io/konairius/ical-proxy:main-99a912b
           ports:
             - containerPort: 8080
               name: http

kubernetes/apps/trmnl/renderer.yaml

@@ -29,6 +29,14 @@ data:
   # The app re-reads schedules.json every 60 s, so edits here take
   # effect without a restart once the init container has rewritten it.
   #
+  # lang is "de", not null. It calls Home Assistant's own
+  # _selectLanguage() for the screenshot session, so the rendered page
+  # is localised by HA rather than by hand. With it left null the
+  # dashboard grew a German weekday array, a German month array and a
+  # fifteen-entry weather-condition dict — reimplementing translations
+  # HA already ships. The instance itself stays language "en"; this
+  # only affects the render session.
+  #
   # model_id is 1 — TRMNL X (name "v2", 1872x1404, 16 colours) — and it
   # is an INTEGER, not a name. Confirmed against the running server:
   # GET /api/screens returns model_id as a number, and upstream's
@@ -60,8 +68,8 @@ data:
         "rotate": null,
         "zoom": 1,
         "wait": null,
-        "theme": "trmnl-eink",
-        "lang": null,
+        "theme": "Graphite E-ink Light",
+        "lang": "de",
         "dark": false,
         "invert": false,
         "timestamp": false,
@@ -107,6 +115,27 @@ metadata:
   namespace: trmnl
   labels:
     app.kubernetes.io/name: trmnl-renderer
+  annotations:
+    # BOTH sources need this, and for the same reason: the init
+    # container writes /data/schedules.json ONCE, at pod start. Nothing
+    # re-reads either source afterwards.
+    #
+    # The app re-reads schedules.json every 60s, which makes it look
+    # self-updating — but only the FILE, and the file is only rewritten
+    # by the init container. So a ConfigMap or Secret change lands in
+    # git, updates the object, and the running renderer keeps the old
+    # values indefinitely.
+    #
+    # Both halves were hit repeatedly in practice and each time needed
+    # `kubectl delete pod` by hand: the theme name, the schedule's lang
+    # field, and every re-mint of the BYOS tokens. A fix that depends on
+    # someone remembering to restart a pod is not deployed.
+    #
+    # Named per-resource rather than the blanket
+    # reloader.stakater.com/auto: "true", matching terminus.yaml and
+    # mosquitto-deployment.yaml.
+    configmap.reloader.stakater.com/reload: trmnl-renderer-schedule
+    secret.reloader.stakater.com/reload: trmnl-renderer-secrets
 spec:
   replicas: 1
   # RWO PVC, and two renderers would push conflicting screens for the
@@ -142,9 +171,16 @@ spec:
         # proxy that exchanges a Terminus username+password for these
         # tokens, but that would mean shipping the Terminus PASSWORD
         # into the cluster and doing a network call at every pod start.
-        # Stock Terminus disables session expiry and issues effectively
-        # permanent tokens, so they are minted once out of band and kept
-        # in OpenBao — the password never enters the cluster.
+        # Tokens are therefore minted once out of band and kept in
+        # OpenBao — the password never enters the cluster.
+        #
+        # That only works because Terminus is configured with
+        # API_ACCESS_TOKEN_PERIOD = 10 years (see terminus.yaml). It is
+        # NOT, as an earlier version of this comment claimed, because
+        # stock Terminus issues permanent tokens — the stock default is
+        # 1800s, and this deployment demonstrated it by having the
+        # webhook start failing with "expired JWT access token" about
+        # thirty minutes after seeding.
         - name: render-schedule
           image: gitea.renner.uno/gitea_admin/alpine-jq:2026-07-30
           command:
@@ -154,13 +190,18 @@ spec:
               set -eu
               # obtained_at is stamped at write time, in MILLISECONDS.
               # It is not cosmetic: the scheduler derives token age from
-              # it, and a literal 0 in the template made the app treat
-              # freshly-minted tokens as ancient and refuse to push —
+              # it, and a literal 0 made the app treat freshly-minted
+              # tokens as ancient and skip the webhook entirely —
               #   "BYOS tokens ... expired beyond the refresh window"
-              # — with no render attempt and no error, just a warning at
-              # startup. Stamping it here is honest enough: stock
-              # Terminus disables session expiry and issues effectively
-              # permanent tokens, so age is not load-bearing.
+              #
+              # Stamping it "now" is only safe because Terminus is
+              # configured with API_ACCESS_TOKEN_PERIOD = 10 years (see
+              # terminus.yaml). Against the 30-minute default it would be
+              # actively harmful: the app would believe a stale token had
+              # 30 fresh minutes left, skip its proactive refresh, and
+              # then be unable to recover, because refreshing requires a
+              # still-valid token. If that setting is ever reverted, this
+              # must become a real mint time carried alongside the tokens.
               jq --arg at "$BYOS_ACCESS_TOKEN" \
                  --arg rt "$BYOS_REFRESH_TOKEN" \
                  '(.[].webhook_format.byosConfig.auth.access_token) = $at

kubernetes/apps/trmnl/terminus.yaml

@@ -18,6 +18,64 @@ data:
   # pool (fd99::/120) and the LAN ULA — without it every IPv6 client,
   # including the device and Traefik, is rate-limited as if it were remote.
   RACK_ATTACK_ALLOWED_SUBNETS: "10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,127.0.0.1,::1,fc00::/7"
+  # 10 years, against a default of 1800s (30 minutes).
+  #
+  # Documented upstream in doc/configuration.adoc:
+  #   API_ACCESS_TOKEN_PERIOD — "The amount of time, in seconds, the JWT
+  #   access token remains valid before needing to refresh your access
+  #   token." Default: 1,800 seconds (30 minutes).
+  # Corroborated on this instance: a token minted here was rejected about
+  # thirty minutes later, i.e. the documented default behaving as written.
+  #
+  # This exists for the renderer, which pushes screens to /api/screens with
+  # a JWT held in OpenBao. At the default period that arrangement cannot
+  # work unattended, and it fails in a way that has no recovery: minting a
+  # replacement token via POST /api/jwt requires a still-VALID access token
+  # in the Authorization header, so once one expires it cannot be refreshed
+  # from itself. Observed exactly that on first deploy —
+  #   [webhook] Webhook failed: 400 {"error":"expired JWT access token"}
+  #   [webhook] BYOS auth: refresh failed (400) {"error":"expired JWT ..."}
+  # — the refresh attempt being rejected by the very expiry it was trying
+  # to repair.
+  #
+  # The renderer's own code assumes "stock Terminus disables session
+  # expiration and issues effectively permanent tokens". That is simply not
+  # true of this deployment, so the assumption is made true here rather
+  # than worked around in the client.
+  #
+  # The trade is deliberate: a long-lived JWT with full Terminus API rights
+  # now sits in OpenBao. Accepted because the alternative was putting the
+  # Terminus account PASSWORD into the cluster so an init container could
+  # mint a short-lived token on every pod start, which is a strictly worse
+  # secret to hold. The token is revocable by rotating the account's
+  # credentials; it grants access only to this LAN-only instance.
+  #
+  # NOTE: the period is fixed at mint time. Changing this does not extend
+  # tokens that already exist — they must be re-minted afterwards.
+  API_ACCESS_TOKEN_PERIOD: "315360000"
+  # The OTHER half of the same problem, and the reason the first fix
+  # did not hold. Terminus has TWO independent expiries: the JWT's own
+  # lifetime (above) and the SESSION behind it. Raising only the token
+  # period left the session at its defaults, so pushes kept working for
+  # a while and then failed with
+  #   HTTP 401 {"error":"This session has expired, please login again"}
+  # which is a different error, from a different mechanism, than the
+  # "expired JWT access token" the first fix addressed.
+  #
+  # Documented in doc/configuration.adoc:
+  #   SESSION_EXPIRATION_ENABLED — "Determines if your browser session
+  #   or JWT API token is expired or not." Default: true.
+  #   SESSION_INACTIVITY_LIMIT 1800s, SESSION_LIFETIME_LIMIT 86400s.
+  #
+  # Disabling it is exactly the state the renderer's own code assumes
+  # ("stock Terminus disables session expiration and issues ~100-year
+  # tokens") — an assumption that is false by default and has to be
+  # made true here, same as the token period.
+  #
+  # Same trade as above, and it is the deciding one for an unattended
+  # appliance: a session that expires needs a human with a password to
+  # restore it, and this panel has neither.
+  SESSION_EXPIRATION_ENABLED: "false"
 ---
 apiVersion: apps/v1
 kind: Deployment
@@ -26,6 +84,20 @@ metadata:
   namespace: trmnl
   labels:
     app.kubernetes.io/name: terminus
+  annotations:
+    # terminus-config is consumed via envFrom, and env vars are read ONCE at
+    # container start — Kubernetes does not hot-reload them. The ConfigMap is
+    # a plain resource, not a configMapGenerator, so editing it does not
+    # change the pod template hash and Flux will not roll the pods either.
+    # Without this annotation a ConfigMap-only change (such as raising
+    # API_ACCESS_TOKEN_PERIOD) applies to git and to the ConfigMap object
+    # while the running app keeps the old value indefinitely — a silent
+    # no-op, with the manifest and reality disagreeing.
+    #
+    # Named per-ConfigMap rather than the blanket `reloader.stakater.com/
+    # auto: "true"`, matching mosquitto-deployment.yaml: enrolling anything
+    # further stays a visible, reviewable edit to this line.
+    configmap.reloader.stakater.com/reload: terminus-config
 spec:
   replicas: 1
   # RWO PVC shared by both containers in this pod, and APP_SETUP runs

kubernetes/infrastructure/openbao/rotation/kustomization.yaml

@@ -59,3 +59,22 @@ resources:
   - review-bot.yaml
   - claude-oauth.yaml
   - mosquitto-health.yaml
+# NOT ROTATED, deliberately — recorded here because the whole point of this
+# directory is that unrotated credentials should be a visible choice:
+#
+#   homelab/apps/trmnl/renderer → BYOS_ACCESS_TOKEN / BYOS_REFRESH_TOKEN
+#     Terminus API JWTs used by the e-ink renderer to push screens. Terminus
+#     is configured with API_ACCESS_TOKEN_PERIOD = 10 years
+#     (kubernetes/apps/trmnl/terminus.yaml), so nothing will ever expire
+#     these or prompt a rotation. That is deliberate: the alternative was
+#     holding the Terminus account password in-cluster to mint short-lived
+#     tokens per pod start. There is no rotator because minting requires the
+#     account password, which is exactly what we declined to store.
+#     Rotate BY HAND whenever the Terminus account password changes, by
+#     re-running POST /login and re-seeding both keys.
+#
+#     HA_ACCESS_TOKEN in the same path is a dedicated Home Assistant
+#     long-lived token. `ha-token` mode in secret-rotator already handles
+#     this class (see home-assistant.yaml) — enrolling it is a genuine
+#     follow-up, not a limitation, and would leave only the BYOS pair
+#     unrotated.