jlab-cluster/helm-charts
3
0 Fork 0
Code Issues 15 Pull Requests 3 Actions Packages Wiki Activity

paperless-ngx: unquotierter CronJob-Zeitplan bricht das Rendern ab, oidcSecretRef wird von keinem Template gelesen #11

New Issue
Closed
opened 2026-09-16 16:03:25 +02:00 by jlab-bot · 1 comment
jlab-bot commented 2026-09-16 16:03:25 +02:00
Member
Copy link
Copy source

Migriert aus jk-cluster/helm-charts#185 — urspruenglich angelegt von jk-cluster-bot am 2026-08-28.

Verweise der Form #123 im folgenden Text beziehen sich auf die GitHub-Nummerierung, nicht auf die Nummern in diesem Repo. Geschlossene Issues wurden nicht mitgezogen und sind weiterhin nur auf GitHub lesbar.

Zwei Befunde am selben Chart, beide aus derselben Familie: Werte, die etwas anderes tun als sie versprechen. Der erste bricht das Rendern ab, der zweite tut überhaupt nichts.

1. Der Zeitplan des Consume-CronJobs ist nicht quotiert

paperless-ngx/templates/paperless-consume.cronjob.yaml, Zeile 7:

  schedule: {{ .Values.smbConnection.cronJob }}

Die Vorgabe "0 0,12 * * *" rendert sauber, weil sie mit einer Ziffer beginnt. Ein Zeitplan, der mit * anfängt — und das ist die verbreitetste Schreibweise überhaupt, etwa */15 * * * * — bricht das Rendern ab: YAML liest den führenden * als Alias-Anker.

Tückisch daran: Anführungszeichen in der Werte-Datei helfen nicht. Helm reicht den Zeichenketten-Inhalt durch, und im gerenderten Manifest steht der Stern wieder nackt da. Der Betreiber schreibt also einen korrekt quotierten Wert und bekommt trotzdem einen YAML-Fehler, dessen Meldung auf das Template zeigt statt auf seinen Wert.

Behebung: {{ .Values.smbConnection.cronJob | quote }}. Ein Wort.

2. secrets.oidcSecretRef wird von keinem Template gelesen

Der Wert existiert in values.yaml, aber:

git grep -c oidcSecretRef origin/main -- paperless-ngx/templates/
→ keine Fundstelle

Kein Template liest ihn, es wird kein OnePasswordItem daraus erzeugt, keine Variable gesetzt. Wer ihn setzt, richtet ein 1Password-Item ein, verweist darauf, bekommt keine Fehlermeldung — und wundert sich, warum die Anmeldung über den externen Anbieter nicht funktioniert. Das ist die unangenehmste Sorte Fehler: er sieht nach erfolgreicher Konfiguration aus.

Zu entscheiden: entweder den Wert entfernen (dann ist es eine breaking values change → Major) oder die OIDC-Anbindung tatsächlich implementieren (dann additiv → Minor). Die zweite Frage ist keine Chart-Frage, sondern eine Betriebsentscheidung: wird paperless-ngx überhaupt an den Anbieter angebunden?

Einordnung

Beide verstoßen gegen „Values that must not lie" aus der README. Der erste ist laut, aber irreführend; der zweite ist still, was ihn schlimmer macht.

Gefunden bei

Umsetzung von #157/#43 für paperless-ngx (PR #183). Der Entwicklungs-Agent hat beides bewusst nicht mitrepariert, damit der PR eine Sache tut, und hat den Zeitplan-Fall in der neuen NOTES.txt als Falle dokumentiert. Beide Befunde wurden anschließend unabhängig an der Quelle gegengeprüft.

Bei der Umsetzung mitnehmen

  • Prüfen, ob dasselbe Quotierungsproblem an weiteren Stellen im Repo steht — überall, wo ein Wert direkt in ein YAML-Skalar gerendert wird, das mit *, &, {, [ oder % beginnen kann.
  • Prüfen, ob andere Charts ebenfalls Secret-Refs anbieten, die kein Template liest. Der Fund war hier Zufall; systematisch gesucht wurde nicht.
> Migriert aus [`jk-cluster/helm-charts#185`](https://github.com/jk-cluster/helm-charts/issues/185) — urspruenglich angelegt von **jk-cluster-bot** am 2026-08-28. > > Verweise der Form `#123` im folgenden Text beziehen sich auf die **GitHub-Nummerierung**, nicht auf die Nummern in diesem Repo. Geschlossene Issues wurden nicht mitgezogen und sind weiterhin nur auf GitHub lesbar. --- Zwei Befunde am selben Chart, beide aus derselben Familie: Werte, die etwas anderes tun als sie versprechen. Der erste bricht das Rendern ab, der zweite tut überhaupt nichts. ## 1. Der Zeitplan des Consume-CronJobs ist nicht quotiert `paperless-ngx/templates/paperless-consume.cronjob.yaml`, Zeile 7: ```yaml schedule: {{ .Values.smbConnection.cronJob }} ``` Die Vorgabe `"0 0,12 * * *"` rendert sauber, weil sie mit einer Ziffer beginnt. Ein Zeitplan, der mit `*` **anfängt** — und das ist die verbreitetste Schreibweise überhaupt, etwa `*/15 * * * *` — bricht das Rendern ab: YAML liest den führenden `*` als Alias-Anker. Tückisch daran: **Anführungszeichen in der Werte-Datei helfen nicht.** Helm reicht den Zeichenketten-Inhalt durch, und im gerenderten Manifest steht der Stern wieder nackt da. Der Betreiber schreibt also einen korrekt quotierten Wert und bekommt trotzdem einen YAML-Fehler, dessen Meldung auf das Template zeigt statt auf seinen Wert. **Behebung:** `{{ .Values.smbConnection.cronJob | quote }}`. Ein Wort. ## 2. `secrets.oidcSecretRef` wird von keinem Template gelesen Der Wert existiert in `values.yaml`, aber: ``` git grep -c oidcSecretRef origin/main -- paperless-ngx/templates/ → keine Fundstelle ``` Kein Template liest ihn, es wird kein `OnePasswordItem` daraus erzeugt, keine Variable gesetzt. Wer ihn setzt, richtet ein 1Password-Item ein, verweist darauf, bekommt keine Fehlermeldung — und wundert sich, warum die Anmeldung über den externen Anbieter nicht funktioniert. Das ist die unangenehmste Sorte Fehler: er sieht nach erfolgreicher Konfiguration aus. **Zu entscheiden:** entweder den Wert entfernen (dann ist es eine breaking values change → Major) oder die OIDC-Anbindung tatsächlich implementieren (dann additiv → Minor). Die zweite Frage ist keine Chart-Frage, sondern eine Betriebsentscheidung: wird paperless-ngx überhaupt an den Anbieter angebunden? ## Einordnung Beide verstoßen gegen „Values that must not lie" aus der README. Der erste ist laut, aber irreführend; der zweite ist still, was ihn schlimmer macht. ## Gefunden bei Umsetzung von #157/#43 für `paperless-ngx` (PR #183). Der Entwicklungs-Agent hat beides bewusst nicht mitrepariert, damit der PR eine Sache tut, und hat den Zeitplan-Fall in der neuen `NOTES.txt` als Falle dokumentiert. Beide Befunde wurden anschließend unabhängig an der Quelle gegengeprüft. ## Bei der Umsetzung mitnehmen - Prüfen, ob dasselbe Quotierungsproblem an weiteren Stellen im Repo steht — überall, wo ein Wert direkt in ein YAML-Skalar gerendert wird, das mit `*`, `&`, `{`, `[` oder `%` beginnen kann. - Prüfen, ob andere Charts ebenfalls Secret-Refs anbieten, die kein Template liest. Der Fund war hier Zufall; systematisch gesucht wurde nicht.
jlab-bot commented 2026-10-04 21:26:35 +02:00
Author
Member
Copy link
Copy source

Nachgeprüft am 2026-10-04: beide Defekte unverändert vorhanden

1. Der Zeitplan — reproduziert, nicht nur gelesen. paperless-ngx/templates/paperless-consume.cronjob.yaml:7 steht weiter unquotiert:

schedule: {{ .Values.smbConnection.cronJob }}

Gemessen mit helm template … --set smbConnection.enabled=true --set smbConnection.cronJob='*/15 * * * *':

Error: YAML parse error on paperless-ngx/templates/paperless-consume.cronjob.yaml:
yaml: line 6: did not find expected alphabetic or numeric character

Der Wert wurde dabei als saubere Zeichenkette übergeben — die Behauptung des Issues, dass Quotieren im Wert nicht hilft, ist damit mitbelegt.

Warum es überlebt hat: das Template steht hinter {{- if .Values.smbConnection.enabled }}, und die Vorgabe ist false. In der Standardkonfiguration und in jeder Fixture, die SMB auslässt, wird der CronJob gar nicht gerendert. Wer das behebt, liefert einen Testfall mit, der ihn gefangen hätte.

2. oidcSecretRef — unverändert von keinem Template gelesen (values.yaml:16). Dazu eine Einordnung, die der Issue-Body noch nicht hatte:

Die OIDC-Anbindung ist implementiert, nämlich als öffentlicher Client mit PKCE — paperless-server.sfs.yaml rendert "OAUTH_PKCE_ENABLED": true und "oauth_pkce_enabled": true und kein secret. Der Wert ist also kein fehlendes Feature, sondern ein Rest.

Ihn echt zu machen wäre teuer: paperless liest die gesamte Konfiguration aus einer JSON-Umgebungsvariablen (SOCIALACCOUNT_PROVIDERS = json.loads(os.getenv("PAPERLESS_SOCIALACCOUNT_PROVIDERS", "{}"))) und kennt keine _FILE-Variante. Ein secretKeyRef kann kein Fragment in eine JSON-Variable einsetzen — es bliebe das Geheimnis inline in der Pod-Spezifikation oder das ganze JSON von Hand im Tresor, womit die required()-Prüfungen des Charts totes Holz wären.

Und die Betriebsfrage dahinter ist inzwischen beantwortet: mit #83 läuft Keycloak, und Keycloak kann einen Client pro Client als öffentlich mit PKCE anlegen. Es gibt also keine Anbieter-Beschränkung, die einen vertraulichen Client erzwingt — der Wert kann entfernt werden. Das ist ein Major-Bump, weil ein bestehender Eintrag danach am strengen Schema scheitert; die Laufzeit ändert sich nicht, denn heute tut er nichts.

Ein Detail, das die Sache unangenehmer macht: der Kommentar an oidc.provider.tokenAuthMethod nennt client_secret_basic als Beispiel. Wer das setzt, verlangt vom Anbieter eine Authentifizierung mit Client-Secret und bekommt sie nicht. Die zwei Werte zusammen lesen sich wie eine funktionierende Secret-Anbindung.

## Nachgeprüft am 2026-10-04: beide Defekte unverändert vorhanden **1. Der Zeitplan — reproduziert, nicht nur gelesen.** `paperless-ngx/templates/paperless-consume.cronjob.yaml:7` steht weiter unquotiert: ``` schedule: {{ .Values.smbConnection.cronJob }} ``` Gemessen mit `helm template … --set smbConnection.enabled=true --set smbConnection.cronJob='*/15 * * * *'`: ``` Error: YAML parse error on paperless-ngx/templates/paperless-consume.cronjob.yaml: yaml: line 6: did not find expected alphabetic or numeric character ``` Der Wert wurde dabei als saubere Zeichenkette übergeben — die Behauptung des Issues, dass Quotieren im Wert **nicht** hilft, ist damit mitbelegt. **Warum es überlebt hat:** das Template steht hinter `{{- if .Values.smbConnection.enabled }}`, und die Vorgabe ist `false`. In der Standardkonfiguration und in jeder Fixture, die SMB auslässt, wird der CronJob gar nicht gerendert. Wer das behebt, liefert einen Testfall mit, der ihn gefangen hätte. **2. `oidcSecretRef` — unverändert von keinem Template gelesen** (`values.yaml:16`). Dazu eine Einordnung, die der Issue-Body noch nicht hatte: Die OIDC-Anbindung **ist** implementiert, nämlich als **öffentlicher Client mit PKCE** — `paperless-server.sfs.yaml` rendert `"OAUTH_PKCE_ENABLED": true` und `"oauth_pkce_enabled": true` und **kein** `secret`. Der Wert ist also kein fehlendes Feature, sondern ein Rest. Ihn echt zu machen wäre teuer: paperless liest die gesamte Konfiguration aus **einer** JSON-Umgebungsvariablen (`SOCIALACCOUNT_PROVIDERS = json.loads(os.getenv("PAPERLESS_SOCIALACCOUNT_PROVIDERS", "{}"))`) und kennt keine `_FILE`-Variante. Ein `secretKeyRef` kann kein Fragment in eine JSON-Variable einsetzen — es bliebe das Geheimnis inline in der Pod-Spezifikation oder das ganze JSON von Hand im Tresor, womit die `required()`-Prüfungen des Charts totes Holz wären. **Und die Betriebsfrage dahinter ist inzwischen beantwortet:** mit #83 läuft Keycloak, und Keycloak kann einen Client **pro Client** als öffentlich mit PKCE anlegen. Es gibt also keine Anbieter-Beschränkung, die einen vertraulichen Client erzwingt — der Wert kann **entfernt** werden. Das ist ein Major-Bump, weil ein bestehender Eintrag danach am strengen Schema scheitert; die Laufzeit ändert sich nicht, denn heute tut er nichts. **Ein Detail, das die Sache unangenehmer macht:** der Kommentar an `oidc.provider.tokenAuthMethod` nennt `client_secret_basic` als Beispiel. Wer das setzt, verlangt vom Anbieter eine Authentifizierung mit Client-Secret und bekommt sie nicht. Die zwei Werte zusammen lesen sich wie eine funktionierende Secret-Anbindung.
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
inhouse-chart
Inhouse-Chart aus der JLab-Git-Paketregistry
 renovate
Von Renovate angelegt
No labels
Milestone
No items
No Milestone
Assignees
Clear assignees
jklein (Justin Klein) jlab-bot (jlab-git-bot) jlab-renovate-bot (jlab-renovate-bot)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: jlab-cluster/helm-charts#11