jklein
b39f36ff5c
A JMAP webmail client for the stalwart chart (Gitea #65): StatefulSet, one PVC at /app/data, Service plus headless Service, Ingress at a host root, two OnePasswordItems, three probes, computed limits, replicas plus scaleDown, strict values.schema.json. Everything below was measured against the source at tag 1.12.0 rather than read out of the documentation, which was wrong about three of them. THE DEFINING PROPERTY: THE VOLUME BEATS THE CHART, FOR EVERY VALUE, SILENTLY. configManager.get resolves "admin override > env var > default", the admin dashboard may write any key of CONFIG_ENV_MAP, and nothing reports that it just disconnected the chart - so a helm upgrade can succeed and change nothing. Upstream documents this for the server URL only; it is true of everything. Exactly three values escape it (SESSION_SECRET(_FILE), ADMIN_PASSWORD, BULWARK_TELEMETRY). The value that closes it, bulwark.adminConfigReadOnly, defaults to false because its price is threefold: it freezes the settings policy (and with it the only way to move Web Push off the vendor relay), it freezes an override that ALREADY exists instead of removing it, and on a fresh install it stops admin.json from being written at all - so the admin dashboard never comes up and its login answers HTTP 500 while the pod stays Ready. OIDC-only sign-in, with the real way back out of a lockout: not helm upgrade with OAUTH_ONLY=false (oauthOnly goes through the same precedence chain) but removing the override in the admin dashboard. That is why ADMIN_PASSWORD is set - the dashboard is the door. It generates no random password and logs nothing, so the #65 analogy does not apply. SESSION_SECRET_FILE and OAUTH_CLIENT_SECRET_FILE are both used - the better path garage (#81) and keycloak (#83) did not have - in one projected volume mounted WITHOUT subPath, because both are re-read on every use and a subPath mount is never refreshed, and at mode 0440 because secret files are owned by root and fsGroup only supplies the group. Two backup statements, both at the value: without the session secret the synchronized settings are unreadable out of an intact volume, and if the dashboard's OAuth setup was ever used the client secret sits in config.json on that volume in cleartext. Probes: all three a plain GET on /api/health, with the limit written at the readiness value - it carries process, HTTP acceptance, a free event loop and Next.js routing, and nothing about the reported state or about Stalwart. No ConfigMap, so the checksum/config rule (#82) has nothing to attach to, and values.yaml says so explicitly; the op:// paths are covered by checksum/secret-ref. Renovate: no versioningTemplate, measured rather than assumed. 315 tags in eight shapes (releases, a second v-prefixed family of the same images, an -always flavour, floating minors and names, commit SHAs, betas, attestations) and plain docker versioning excludes all six unwanted ones. Dry runs at 1.12.0, 1.11.0 and 1.10.0 are recorded in the block. Part of #89 - deliberately not "Fixes", because one binding decision of the issue was changed out of necessity and wants ratification rather than an automatic close: the plan specifies HEAD /api/health for all three probes, and a Kubernetes probe cannot send HEAD at all (HTTPGetAction has no method field; the kubelet always issues GET). The alternative, an exec probe, would mean starting a Node process every few seconds in an image that carries no curl and no wget. GET is used instead and is marginally more capable than HEAD, so every limit the issue argues is unchanged - but the decision is the maintainer's to confirm.
51 lines
2.2 KiB
YAML
51 lines
2.2 KiB
YAML
{{- /*
|
|
ONE claim, mounted at /app/data, holding all FOUR of Bulwark's directories as
|
|
subdirectories of it:
|
|
|
|
admin config.json, policy.json, admin.json (the password hash),
|
|
plugin-config/, plugins/, themes/, branding uploads
|
|
admin-state admin-state.json (login timestamps), audit.log, the bootstrap
|
|
setup token
|
|
settings the encrypted per-account user settings
|
|
telemetry consent and instance id
|
|
|
|
ONE VOLUME AND NOT FOUR, because a snapshot is atomic per volume and never
|
|
across volumes - the durability lesson garage (#81) was built on. Split up, a
|
|
backup can capture an audit log that records logins the configuration does not
|
|
know about yet, or settings encrypted against a secret the configuration has
|
|
since been repointed from. There is no argument on the other side here: this is
|
|
a few hundred kilobytes of JSON plus an append-only log, not an object store.
|
|
|
|
Bulwark creates all four subdirectories itself on start (ensureConfigDir and
|
|
ensureStateDir, both mkdir -p). It has to: the image's own `mkdir -p
|
|
/app/data/...` ran in a layer that this mount covers. fsGroup is what makes the
|
|
freshly provisioned volume writable for uid 1001.
|
|
|
|
DELIBERATELY NOT null-SAFE: an erased size yields an invalid PVC that is
|
|
rejected at apply time, which is loud. A chart-side fallback would silently size
|
|
somebody's volume - and on an existing release it could not help anyway, because
|
|
a PVC cannot shrink. Same reasoning as garage's storage block and satisfactory's
|
|
documented exception (Gitea #39).
|
|
|
|
NEVER RENAMED. A renamed PVC makes Kubernetes provision a new, empty volume and
|
|
orphans the data - here that means admin.json, the only copy of the admin
|
|
password hash, and audit.log, which by its nature cannot be reconstructed.
|
|
*/ -}}
|
|
apiVersion: v1
|
|
kind: PersistentVolumeClaim
|
|
metadata:
|
|
name: {{ .Release.Name }}-{{ .Chart.Name }}-pvc
|
|
labels:
|
|
app: {{ .Release.Name }}-{{ .Chart.Name }}-sfs
|
|
spec:
|
|
accessModes:
|
|
# ReadWriteOnce, and the single replica follows from it rather than the other
|
|
# way round - see the bulwark.replicas helper.
|
|
- ReadWriteOnce
|
|
resources:
|
|
requests:
|
|
storage: {{ .Values.storage.amount }}
|
|
{{- if .Values.storage.storageClass }}
|
|
storageClassName: {{ .Values.storage.storageClass }}
|
|
{{- end }}
|