42 Commits

Include renames

Author	SHA1	Message	Date
jklein	73c2ec704f	feat!: NetworkPolicy in the last five charts - the sweep is complete ... matrix-synapse, paperless-ngx, freesailarr, valkey, stalwart. One major each. All 29 installable charts plus template-chart now render a policy, and ci/run-networkpolicy-test.sh passes over all 30 with 206 assertions held. MATRIX-SYNAPSE renders TWO policies, one per workload, and the split is the decision in that file. Synapse federates - it must be able to reach any homeserver on the internet, so 443 and 8448 go to any destination - while the delegation nginx serves two static JSON documents and calls nobody, so its egress is DNS and nothing else. A single policy over both pods would have to permit the union, handing full federation reach and the database port to an nginx whose job is to return a constant, and it would read as one decision rather than as a widening. networkPolicy.egress.extraPorts deliberately does not reach the delegation policy for the same reason. PAPERLESS-NGX names the two pods of its own release that this object does NOT cover: the valkey subchart's pod, which carries its own labels and needs no cover because the valkey chart ships a tighter policy of its own; and the consume CronJob's pods, whose pod template carries NO LABELS AT ALL, so no podSelector can match them. That second one is a real gap in the convention. It is tolerable only because the job moves files between mounted volumes and reaches the SMB share through a CSI volume the node mounts - the pod opens no connection of its own - and if that ever changes the CronJob needs labels before it can need a policy. FREESAILARR is ten containers in one pod behind a VPN, and simpler than that sounds: they share a network namespace, so all inter-container traffic is localhost and no policy sees any of it. Because the namespace belongs to gluetun, everything the *arr containers send is encapsulated before it leaves, so three rules describe the whole outbound surface - DNS, UDP 51820 for the tunnel, and 443 for gluetun's server-list API, which cannot go through the tunnel because it runs before the tunnel exists. The tunnel rule is the one that can break this chart and also the best covered: gluetun's health server answers 200 only while the tunnel is up and all three of its probes address it, so a blocked 51820 is a pod that never goes Ready - in the install-test, which brings up a real tunnel. VALKEY AND STALWART, the two charts that had a policy before this issue, are pulled onto the convention without a single rule changing. What changed: - the reasoning moved out of "#" comments, which are part of the rendered object and travel into the cluster, into template comments. Both files failed the new check; that is what it is for. - stalwart gains networkPolicy.ingressController, which fixes a hole its own comment described without being able to solve: it advised putting the controller's namespace into allowedNamespaces, which is namespace-granular and would have opened the http port to every pod in kube-system. - stalwart's example was WRONG and is corrected. It suggested ["ingress-nginx"]; measured on 2026-10-14, ingress-nginx is gone from this cluster entirely and the controller is rke2-traefik in kube-system. A policy written against the old one would have been accepted, looked strict, and silently blocked all web traffic. Their justified specifics are untouched: valkey stays Ingress-only, because it opens no outbound connection and an egress rule would constrain nothing while making the object look stricter; and it keeps 6379 restricted by source with no probeSources at all, which is safe only because all three of its probes are exec probes and put no packet on the network. The convention was written to accommodate both, and homeassistant and satisfactory now invoke valkey's rule in the other direction. ONE CHANGE TO THE TEST, forced by a structural fact rather than by convenience: the rendered-comment assertion now skips documents from a SUBCHART. A dependency is fetched from the Helm registry, not from the copy in this repository, so the policy paperless-ngx and stalwart bundle is whatever valkey version is PUBLISHED - and nothing in the parent chart can change its rendered comments. Holding the parent responsible would have made the test unfixable until valkey's next release and would fail a chart for a file its own diff does not contain. The subchart's own pull request is where it is caught, because this test runs over every chart including valkey itself. All twelve failure paths were re-run against the change. Part of #5	2026-10-14 14:46:11 +00:00
jklein	7003f3674c	feat(freesailarr)!: eight image updates and a trustedNetworks value for the *arr apps ... Collapses the eight open Renovate PRs for this stack into one change, and answers what two of them turned out to carry. The eight tags: qbittorrent 5.2.3 -> 5.2.4, bazarr 1.6.0 -> 1.6.2, sonarr 4.0.19 -> 4.0.20, flaresolverr v3.5.0 -> v3.5.2, recyclarr 8.7.1 -> 8.7.3, prowlarr 2.5.2 -> 2.6.5, radarr 6.3.0 -> 6.4.4, seerr v3.4.1 -> v3.5.0. gluetun, the busybox init image and the digest-pinned mediathekarr have no update pending and are untouched. Major rather than patch, because prowlarr 2.6.3 and radarr 6.4.3 are not plain bumps: they removed the hard-coded trusted proxy networks (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, fc00::/7, fe80::/10, read in Startup.cs at the previously pinned tags) and replaced them with a TrustedNetworks setting whose own default is string.Empty - ForwardedHeadersConfigurator returns before registering a single KnownNetwork while it is empty. Behind an in-cluster ingress controller that means the forwarded headers are ignored: the client address the app reports is the controller's pod IP, the scheme reads as http behind TLS termination, and under "Disabled for Local Addresses" a proxied request stops counting as local. So a <app>.trustedNetworks value is added for prowlarr, radarr AND sonarr, rendered as <APP>__SERVER__TRUSTEDNETWORKS and only when non-empty - an empty variable cannot be told apart from an unset one by the app, but looks handled to a reader of the manifest. The env form was verified per app rather than inferred: all three bind ServerOptions to <App>:Server next to a plain AddEnvironmentVariables(). A helper suppresses the chart's entry when the app's own env block already carries the variable, for the reason the UrlBase helper states - two identically named variables in one container are not a defined state. sonarr is included because it is already in the empty state: 4.0.19, the version this chart shipped before, has no hard-coded networks either. It arrived in what the convention classes as a plain app-version bump, so nothing reviewed or documented it. Repairing two and knowingly leaving the third would be the same silent pattern. The default is empty, and this therefore does NOT restore the behaviour from before the upgrade. That is deliberate and follows upstream's reason - trusting X-Forwarded-For from any private network is a spoofing vector - and it is made visible instead of reinstated: NOTES.txt warns in exactly the combination that costs something, the app published through an Ingress or an HTTPRoute and the value empty, and stays quiet otherwise. AllowedHosts, added by the same upstream releases, is deliberately not exposed. Its default is string.Empty as well and the app then accepts any host, so there is nothing to repair; the trap is documented instead, because if it is ever set the app appends only localhost, 127.0.0.1, [::1] and its own hostname - neither the pod IP nor the Service DNS name - and the kubelet probes the pod by IP, which an incomplete list answers with HTTP 400. At default values the rendered manifest changes in exactly eight lines, the image tags; the new value renders nothing until it is set.	2026-10-12 22:00:23 +00:00
jklein	f202fdc3fc	fix(freesailarr): redirect the bare /qbittorrent prefix in Gateway mode ... qBittorrent has no base-path setting, so the chart serves it under a prefix and strips that prefix before the request reaches it. For the slashed form that is correct. For the BARE form - /qbittorrent, no trailing slash - the request is rewritten to "/" and qBittorrent answers 200 with its login page, while the browser's document URL keeps the prefixless form. Every relative link in that page therefore resolves against the host root, and on the shared host the root is seerr: the login form comes up unstyled and does nothing while a different application answers its assets and XHRs. Nothing reports an error at any level. The shared-domain HTTPRoute now carries a second rule for qBittorrent: an Exact match on qbittorrent.ingress.path with a RequestRedirect filter that replaces the full path with the slashed form, statusCode 301. The Gateway API ranks an Exact path match above every prefix match, so it wins over both qBittorrent's own PathPrefix rule and seerr's "/" wherever it is emitted - the rules' length-descending order stays a rendering convention. 301 rather than 308 because only 301 and 302 are Core in that API; an Extended value an implementation declines makes it set Accepted=False on the WHOLE route, which would take the four neighbouring apps' routing down with it, and that would also contradict decision 1 of Gitea #114. statusCode is written out because it defaults to 302. The rule is guarded on the app being qbittorrent and its path not being "/", and it reads the path from the value, never a literal. The INGRESS BRANCH IS UNCHANGED, deliberately. The remedy there is an nginx configuration-snippet annotation, and the chart cannot ship it: snippets are ignored unless the controller runs with allow-snippet-annotations=true, off by default since ingress-nginx 1.9 and only switched on by accepting annotation risk level "Critical". A shipped annotation would be a silent no-op on every cluster keeping the default. The working snippet, that price, and why a third Ingress object with pathType: Exact is not a substitute - buildLocation in ingress-nginx controller-v1.14.5 returns a regex location in its enforceRegex branch before reaching the PathTypeExact branch, and enforceRegex is computed once per nginx server over every location of the hostname, one of which carries rewrite-target - are all written out in values.yaml instead. ci/run-httproute-match-test.sh gains a third assertion, per HTTPRoute object: a rule stripping a prefix with ReplacePrefixMatch requires a rule in the same route matching that path Exactly and carrying a RequestRedirect filter. This is what stops the gap reappearing; bulwark is the second rewrite-target chart and meets the same check when group 3 of Gitea #114 lands. 37 assertions over 15 charts, up from 36. Both fail paths were exercised: the rule deleted, and the redirect pointed at a path other than the one stripped. Minor and not major: with the Ingress branch untouched and httpRoute.enabled defaulting to false, no existing release's render changes by a byte and no value becomes required. Shown by an empty helm template diff against origin/main in both Ingress shapes, shared-domain and per-app hosts. Fixes #118	2026-10-12 20:06:09 +00:00
jklein	bd1fdc09a0	feat: Gateway-API as an alternative to the Ingress in five annotation charts ... Group 2 of the #114 sweep: the charts whose behaviour hangs off an nginx annotation - calibre-web-automated, outline, paperless-ngx, zipline (proxy-body-size) and freesailarr (rewrite-target). Each gets the form the pilot (cyberchef, PR #115) fixed and group 1 (PR #116) repeated: an httpRoute block off by default, a template rendering ONLY an HTTPRoute with parentRefs - no Gateway, no gatewayClassName, no Certificate, no implementation-specific policy object - render aborts on both modes at once (naming both value paths), on an empty parentRefs and on a missing hostname, empty hostnames meaning [ingress.domain], a schema entry closed against unknown keys with an open parentRef definition, and a NOTES.txt that names the active mode and what the mode costs. Minor, additive, defaults unchanged: `helm template` with each chart's CI values is byte-identical to origin/main for all five. The upload limit is DOCUMENTED, not rebuilt (decision 2 of the issue). The Gateway API knows no body size; a policy object would bind the chart to one implementation. So the Gateway branch of NOTES.txt says, per chart and in the chart's own terms, that the value is NOT ENFORCED and names where to set it: an e-book library (calibre), an upload service (zipline), the web-UI half of the document intake while the consume directory keeps no limit at all (paperless), and the open #12 pair (outline). Four findings that were not in the plan, each argued in the file it changes: freesailarr gated freesailarr.sharedIngressApps on ingress.enabled, and that list is read by the <APP>__SERVER__URLBASE variables as well as by the routing objects. In Gateway mode it would have come out EMPTY while the route served radarr, sonarr and prowlarr under their prefixes: UrlBase unset, assets and API calls linked at the host root, broken UI behind a Ready pod. The helper's two guards (seerr/mediathekarr only at "/", no duplicate paths) would have gone unenforced there too. Fixed with freesailarr.published (ingress.enabled OR httpRoute.enabled) - the same shape as sure.publishedOverTls in group 1, and identical to ingress.enabled while httpRoute.enabled is false. Measured: on origin/main with ingress.enabled: false the render emits ZERO URLBASE variables; with this change in Gateway mode it emits three. paperless-ngx was the last chart in the repository rendering its Ingress UNCONDITIONALLY. Without an ingress.enabled switch there is no second value path for the mutual-exclusion abort to name, and the Ingress plus its unconditional required() on clusterIssuer would have kept rendering in Gateway mode - a value demanded for nothing, which is issue #114's "Folge 1" and README guideline 12. The switch was added, defaulting to true, so the render is unchanged. paperless-ngx PAPERLESS_URL had no required() of its own: it relied on the Ingress template's, which stops firing the moment the Ingress is switchable. With httpRoute.hostnames set and ingress.domain empty it would have rendered "https://" and refused every login POST as a CSRF failure. It now carries its own required(), naming what the value is for. calibre-web-automated claimed, in values.yaml and in its schema, that ingress.domain is read nowhere but in the Ingress template. The HTTPRoute reads it, so the claim now holds only while both modes are off. Corrected rather than left standing - the same correction garage needed in group 1. freesailarr is where the Gateway API is LESS machinery than what it replaces, not a translation of it. rewrite-target applies per Ingress OBJECT, so qBittorrent (no base path, prefix must be stripped) needed a second Ingress on the shared host, which then had to repeat the first object's TLS secret name, omit the cert-manager annotation conditionally so only one Certificate is requested, and match an ImplementationSpecific regex path for the rewrite's capture group. A URLRewrite filter applies per RULE: one route, one rule per app, the filter on qBittorrent's rule, a plain PathPrefix. All four crutches gone. It is also the only chart without httpRoute.hostnames - it has no ingress.domain either, and a chart-global hostname list could not say which of the ten apps it belonged to, so the hostnames stay in ingress.host and <app>.ingress.host. CI: one render overlay per chart under ci/httproute/, so the assertion is not vacuum-green - ci/run-httproute-match-test.sh goes from 20 held assertions over 10 charts to 36 over 15. freesailarr's overlay moves bazarr onto a host of its own, so the shared-host route AND the per-app route are both rendered; without that the per-app branch would be exercised by nothing. The install-test fixtures stay in Ingress mode: the install runs one configuration per chart, cyberchef already pays that price against the real Gateway-API CRDs, and for paperless-ngx that fixture is the only install of the valkey-subchart path anywhere. README also carries a stale figure fixed here: the HTTPRoute test was still documented at the pilot's 4 assertions over 2 charts, although group 1 had taken it to 20 over 10. Not proven, by construction: that traffic flows. No Gateway controller runs in CI. Not run locally either: k3d, Docker, Trivy. The Gateway branch of NOTES.txt is EXECUTED by the render test (a template error in it fails the job, verified) but its text is printed by no pipeline stage - helm template does not emit notes, and the install-test installs in Ingress mode. Part of #114	2026-10-12 18:15:29 +00:00
jklein	e0b552d93e	Replace the obsolete no-dependencies rationale in every chart helper ... The doc comments on the resources and defaultedDict helpers justified the copy-per-chart with "charts in this repo deliberately have no dependencies". That rule fell with #214: a dependency is admissible now, just expensive, and it sits in the README as guideline 14, not 13. The justification still holds, but its reason is a different one - sharing the helper would mean a library chart, a second artefact to publish, version and pull for something that changes about once a year. searxng got that wording in PR #38; this carries it to 21 further charts, 40 occurrences in all. rss-bridge is deliberately left out. Its install-test fails on the Gitea runner for a reason that predates this branch, and touching the chart would keep it in the install-test matrix and the check red. Its copy of the sentence is carried by #51, which has to open the chart anyway. Comments only: every touched chart renders byte-identical against its ci/<chart>/test-values.yaml. Each published chart takes a patch bump, appVersion and +up suffix untouched; template-chart is never published and takes none, but is corrected because every new chart inherits from it. Two repo files carried the same claim at no version cost: validate-charts.yml explained the all-charts quantity render test with it, and change-app-version.yml still counted nine images for freesailarr - MediathekArr made it ten.	2026-09-27 10:27:57 +00:00
jklein	78d7020dab	freesailarr: MediathekArr as the tenth container, off by default (3.1.0+up1.0.0) ... MediathekArr fakes a Usenet indexer towards Prowlarr and a SABnzbd downloader towards Sonarr/Radarr and fetches from the ARD and ZDF media libraries. Both consumers already share gluetun's network namespace, so they reach it over 127.0.0.1 - no service, no DNS, no ingress detour. Purely additive: the flag defaults to false and a default render is byte-identical to 3.0.5 (verified against the previous chart for both the default values and the CI values). The four things that fail silently without them: - A START GATE on gluetun. MediathekArr fetches its ruleset once at start and never retries; started before the tunnel it answers every Newznab search with 0 results while the container is up, Ready and quiet. Kubernetes cannot order two regular containers and an initContainer would deadlock, so the wait sits in front of the image entrypoint: poll gluetun's health server on 127.0.0.1:9999 and exec the entrypoint afterwards; on timeout the container exits rather than starting blind, because a crash loop is visible and an empty indexer is not. The startup probe budget (300s) deliberately outlasts the gate (180s). - incomplete/ AND complete/ ON THE SHARED DOWNLOADS CLAIM, not in an emptyDir. An emptyDir counts against the container's ephemeral-storage limit, and one large download would have the kubelet evict the whole pod with all ten containers - the trap ytdlp-web-player documents. - THE COMPLETE PATH SONARR SEES. The claim is mounted at /downloads exactly as sonarr/radarr mount it, and the chart sets DOWNLOAD_COMPLETE_PATH itself, so the SABnzbd complete_dir it reports is the same absolute path on both sides. - TWO PORTS: 5007 (SABnzbd role and UI, primary) and 5008 (Newznab role for Prowlarr), both declared to gluetun's firewall and both on one Service. The SABnzbd API is at /download/api - /api on 5007 answers with a misleading Newznab validation error. Further details: - Image pinned by digest (tag + digest): "latest" is a 2024 build, "beta" moves. Single-arch linux/amd64. The built-in helm-values manager cannot follow that pair, so renovate.json5 gets the chart's first customManagers block; verified by dry-run with two fixtures, since a matching and a broken rule look identical while the pin is current. - Hardened as measured: non-root, uid/gid from puid/pgid, readOnlyRootFilesystem: true, all capabilities dropped, no PUID/PGID. - Probes on measured 200 endpoints (there is no health endpoint): readiness and startup on /download/, liveness as an exec covering BOTH ports, because one container runs two processes and a wedged Newznab half is exactly what makes searches come back empty. - No ingress by default: the UI links its assets with root-absolute paths, so it can only be served at the root of a host; on the shared domain that root belongs to seerr. A sub-path fails the render instead of producing a broken UI. - values.yaml and NOTES.txt document the geo MARKER PROCEDURE (not a table of series), the escape route of a German exit and its price for the whole stack, the fail_message: null trap, and the HLS question as an open question. - CI: mediathekarr enabled in ci/freesailarr/test-values.yaml, install timeout raised to 1200s for the extra image and the gate. Fixes #245	2026-09-08 23:20:16 +02:00
jlab-renovate[bot]	df5e15b2b6	Update docker.io/linuxserver/bazarr Docker tag to v1.6.0	2026-08-30 01:20:22 +00:00
jlab-renovate[bot]	ed1e59b691	Update docker.io/linuxserver/prowlarr Docker tag to v2.5.2	2026-08-30 01:18:21 +00:00
jklein	4bc508db61	Merge pull request #206 from jk-cluster/renovate/docker.io-linuxserver-sonarr-4.x ... Update docker.io/linuxserver/sonarr Docker tag to v4.0.19	2026-08-30 01:16:20 +00:00
jklein	3407890335	Merge pull request #210 from jk-cluster/renovate/docker.io-linuxserver-radarr-6.x ... Update docker.io/linuxserver/radarr Docker tag to v6.3.0	2026-08-30 01:15:18 +00:00
jklein	746e44b365	Merge pull request #212 from jk-cluster/renovate/ghcr.io-recyclarr-recyclarr-8.x ... Update ghcr.io/recyclarr/recyclarr Docker tag to v8.7.1	2026-08-30 01:14:39 +00:00
jklein	972a572460	Merge pull request #213 from jk-cluster/renovate/ghcr.io-seerr-team-seerr-3.x ... Update ghcr.io/seerr-team/seerr Docker tag to v3.4.1	2026-08-30 01:14:13 +00:00
jlab-renovate[bot]	fd681dc12f	Update ghcr.io/seerr-team/seerr Docker tag to v3.4.1	2026-08-30 00:09:29 +00:00
jlab-renovate[bot]	ed4456618a	Update ghcr.io/recyclarr/recyclarr Docker tag to v8.7.1	2026-08-30 00:09:16 +00:00
jlab-renovate[bot]	4314660057	Update docker.io/linuxserver/radarr Docker tag to v6.3.0	2026-08-30 00:08:22 +00:00
jlab-renovate[bot]	107397c3c2	Update docker.io/linuxserver/sonarr Docker tag to v4.0.19	2026-08-30 00:06:40 +00:00
jlab-renovate[bot]	131609fca1	Update docker.io/linuxserver/qbittorrent Docker tag to v5.2.3	2026-08-30 00:06:18 +00:00
jklein	ce73bc1111	freesailarr: no exponential notation in computed limits (3.0.2+up1.0.0) ... The null-safe fallback helpers from #99 route values through fromYaml, which parses every number as float64. Go's "%v" switches float64 to exponential notation from about 1e6 upwards, so a bare byte count like 1048576 reached the suffix check inside multiplyQuantity as "1.048576e+06" and the render aborted with `unsupported resource quantity suffix "e+06"`. Both printf "%v" sites in multiplyQuantity now go through a new formatNumber helper that forces plain decimal notation and trims the padded zeros. The second site is the quiet half of the bug: a fractional limitFactor together with a bare number produced no error at all, just an invalid quantity such as "1.4999985e+06" that only the API server rejects on apply. limitFactor is typed "number" in this chart's values.schema.json, so a fractional factor is an ordinary, schema-valid input. All ten resource paths of the stack are affected and were verified one by one (gluetun, qbittorrent and its configInit init container, prowlarr, flaresolverr, radarr, recyclarr, sonarr, seerr, bazarr). The VPN, firewall and container structure is untouched: rendering the chart with its default values is byte-identical to main. Teil von #157	2026-08-29 01:08:07 +02:00
jklein	69a280399c	ci: run the freesailarr install-test for real instead of skipping it ... freesailarr was excluded from the install-test because gluetun never becomes healthy without a real Wireguard key and no app container behind its kill switch can become Ready. The green "Install-test freesailarr pass" was a 25-second SKIP on the most complex chart in the repo - a signal that proved nothing. With a CI-only Mullvad key in 1Password the reason is gone: - ci/run-install-test.sh learns a general rule: ci/<chart>/fixtures.env.yaml is rendered with envsubst before it is applied, restricted to the variable names a chart declares in REQUIRED_ENV. A missing or empty declared variable fails the run loudly and names the variable - it never skips the chart. - The install-test job loads the key from 1Password Connect for freesailarr only, following the pattern publish-helm-chart.yml documents: values via steps.<id>.outputs.*, mapped into the step's own env, quoted, with ":?" guards that name the missing op:// field before a cluster is created. - Fixtures for freesailarr: three media claims, the gluetun secret template with variable names only, firewallOutboundSubnets so the kill switch does not block cluster DNS, and INSTALL_TIMEOUT=900 for nine containers. freesailarr/Chart.yaml goes 3.0.0+up1.0.0 -> 3.0.1+up1.0.0. That bump is deliberately empty of content: the install-test matrix follows changed chart directories, and without it this PR could not run the test it adds.	2026-08-26 14:30:42 +02:00
jklein	65c35dff46	freesailarr: two measured details from the k3d end-to-end run ... Both are documentation only - the rendering is byte-identical to the previous commit. The *arr probes: with a UrlBase set, radarr/sonarr/prowlarr answer the bare /ping with 307 and Location: /<urlbase>/ping, not 200. The probes keep passing because the kubelet counts 200-399 as success (9/9 Ready, 0 restarts), so the probe paths stay at /ping and are valid in both ingress shapes. Recorded so nobody reads the 307 as a fault. Bazarr under a sub-path without its manual base URL: it does not answer 404. It returns its index page for every unknown path, so /bazarr/ and /bazarr/<asset> both come back as 200 text/html of identical length - the page loads, the assets silently arrive as HTML, and nothing looks like an error. The content type is the tell, not the status code.	2026-08-25 21:10:49 +02:00
jklein	fc768efaf5	freesailarr: shared domain with sub-paths, qBittorrent save path (3.0.0+up1.0.0) ... Adds a second, optional ingress shape and fixes the download target of qBittorrent. The existing per-app-host shape stays the default and renders unchanged. Shared domain (#167) Setting ingress.host moves every app without a host of its own into one Ingress object with one path each (<app>.ingress.path, default /<app>), one TLS secret and therefore one DNS name and one certificate for the whole stack. A per-app host always wins and keeps its own object, so mixed operation needs no extra values. The apps differ in what they can do under a sub-path, and the chart follows that rather than pretending they are alike: - radarr, sonarr, prowlarr get <APP>__SERVER__URLBASE from the chart, but only when their own env block does not already carry the variable. - bazarr has no environment variable for its base path and stays one documented manual step (Settings -> General -> Base URL). - qbittorrent has no base path at all and renders a second object on the same host with a prefix-stripping rewrite. It repeats the same TLS secret name and deliberately omits the cert-manager annotation, so both objects state their own TLS while only one certificate is requested. - seerr has no base path either and cannot be rewritten, so it is pinned to "/" and a fail refuses any other path. A second fail refuses two apps claiming the same path. qBittorrent save path (#166) Without Session\DefaultSavePath qBittorrent writes to its built-in default /config/Downloads - the 1Gi config volume. It fills within minutes, every torrent goes to "errored" and qBittorrent can no longer write its own metadata to BT_backup, so a restart in that state costs the torrent list. The init container (renamed qbittorrent-config-interface -> qbittorrent-config-seed, since it no longer only sets the interface) now seeds qbittorrent.savePath, default /downloads. Unlike the interface binding it is inserted ONLY when the key is absent and never replaced: a path changed in the WebUI is a legitimate operator decision and must survive a restart. This is the reason for the major bump: an installation that never set the path writes somewhere else after the upgrade. Documentation NOTES.txt and the media block in values.yaml now spell out why a shared claim with three subPaths does not produce hardlinks: the kernel compares the vfsmount in do_linkat, not the superblock, so two bind mounts of one filesystem are EXDEV - while stat reports the same device number on both sides and suggests the opposite. The layout that would work (one claim, one mount, categories as sub-directories) is named as a possibility; the chart cannot express it today. README.md gains the shared domain as the second admissible ingress shape of the style guideline.	2026-08-25 20:55:43 +02:00
jklein	39e9613ee3	freesailarr: one volume entry per media claim (2.0.2+up1.0.0) ... media.downloads, media.movies and media.tv rendered three fixed volume entries, one per category. Two categories on the same existingClaim therefore produced two pod volumes with an identical claimName, and such a pod never starts: it stays in Init:0/1 without a single kubelet event (measured on RKE2/Longhorn, RWO and RWX alike). The volume list is now deduplicated by claim name. A new mediaVolumeName helper names the entry after the first ENABLED category in the fixed order downloads, movies, tv that carries the claim; the other categories mount that same entry and differ only in their subPath. The restriction to enabled categories matters because the three entries render under different conditions - a canonical owner whose entry is not rendered would be a dangling reference. With three distinct claims the chart renders byte-identically to 2.0.1, hence a patch bump. Also corrected in the values documentation, after measuring instead of assuming: the kubelet creates missing subPath directories itself, but they inherit the claim root's mode, and fsGroup cannot be relied on to fix that - Longhorn's fsGroupPolicy (ReadWriteOnceWithFSType) skips fsGroup on RWX claims entirely. What has to hold is that the claim root is writable for PUID/PGID. No chown or init container was added.	2026-08-24 21:01:53 +02:00
jlab-renovate[bot]	38ea281c96	Update docker.io/qmcgaw/gluetun Docker tag to v3.41.3	2026-08-24 14:34:52 +00:00
jklein	a37588c2fe	freesailarr: schema, null-safe fallbacks, seccompProfile, NOTES.txt ... Retrofits the repo-wide groundwork that #59 deliberately left out to keep the reviewed scope. Chart 2.0.0+up1.0.0 - a major, because seccompProfile changes runtime behaviour; appVersion stays the freely chosen marker 1.0.0. values.schema.json (#68). The largest schema in the repo: nine app blocks with probes, resources, security contexts, env and image. additionalProperties is false on every chart-owned level; the objects that go verbatim into the pod spec stay open. It rejects a mistyped app name, a mistyped key at any depth and ingress.domain - the key #59 removed, which until now would have been accepted in silence. Null safety (#99), both halves, because they cover different cases. The defaultedDict helper catches a key WITH a chart default, where Helm's coalescing deletes the null before the schema ever sees it; the widened ["object","null"] types catch a key WITHOUT one, where the null survives into validation. Measured on the old chart: radarr.securityContext: null rendered "securityContext: null" - the whole hardening gone - and securityContext.capabilities: null dropped the capability block entirely, so the container kept every default capability instead of dropping ALL. Both render green. The fallback table reproduces THIS chart's defaults including its deviations: the five linuxserver.io containers keep runAsNonRoot unset and a writable root filesystem so their s6 init can drop to PUID/PGID, flaresolverr keeps its numerically pinned uid, gluetun keeps NET_ADMIN, and recyclarr keeps its exec probes. Restoring the "clean" standard there would put the linuxserver containers back on the image's uid 911 - the failure calibre-web-automated hit. The sync between table and values.yaml is not left to discipline: rendering with every block of the silent class explicitly set to null is byte-identical to rendering the defaults, which is how a drift shows up. seccompProfile RuntimeDefault (#84) in the pod context, so it covers the init container too. Trivy's KSV-0104 drops from ten findings to none. NOTES.txt (#43) covering what actually bites: the pod is not Ready until the tunnel is up, the two fields the 1Password item needs, the warning when firewallOutboundSubnets is unset, the immutable volumeClaimTemplates, and the measured fact that imports do not hardlink across the media categories. Also, from point 5 of the plan: checksum/config does not apply - the chart has no ConfigMap - but checksum/secret-ref does, and was missing. Helm never sees the secret's contents, yet it does see which op:// item the OnePasswordItem points at, so repointing secrets.gluetunSecretRef now restarts the pod instead of leaving the old credentials running. README: the #43 status line was stale (it still claimed only homeassistant ships NOTES.txt), and the mandatory-icon rule now records freesailarr as a documented exception - #59 dropped the icon and did not amend the rule.	2026-08-24 16:06:20 +02:00
jklein	020e54d1ff	Write the busybox image without the library/ namespace ... docker.io/busybox and docker.io/library/busybox resolve to the same image on Docker Hub, and the short form is the spelling the rest of the fleet will use when the remaining unqualified official images (paperless-ngx, matrix-synapse, minecraft-server) are qualified in the #84 follow-up. Verified: the rendered output differs in exactly this one line, and a Renovate lookup against the real chart files (44.41.0, official container, dry-run lookup) still extracts all ten images through helm-values with no skipReason and no warnings - docker.io/busybox included, whose candidate list stays empty because 1.38.0 is current.	2026-08-24 15:37:10 +02:00
jklein	9cdbe097f6	Qualify the Docker Hub image names, drop the gluetun branding ... main qualified five charts' image references in 6c73ef8 on the same day this chart would otherwise arrive carrying the pattern that was just cleared out. The seven Docker Hub names now say where they come from: qmcgaw/gluetun, the five linuxserver.io images and the busybox init image, the last as docker.io/library/busybox since it is an official image. The three ghcr.io names were already qualified - checked rather than assumed. Verified with Renovate 44.41.0 in the official container (RENOVATE_PLATFORM= local, RENOVATE_DRY_RUN=lookup) that the prefixed form still resolves under the built-in helm-values manager, since that manager is the only thing keeping these images updated: it extracts all ten, datasource docker, no skipReason and no warnings, and returns concrete candidates for eight of them. A control run against the unqualified form produced byte-identical results, so the prefix changes nothing about what Renovate offers. Trivy's trusted-registry check (KSV-0125) drops from ten findings to none, which is what the registry list in ci/trivy/data/ksv0125.yaml documents as the point of writing images this way. Chart metadata: the icon was gluetun's logo and the description opened with a list of four of the nine projects, both suggesting a "main app" the stack does not have. The description now names none of them, and the icon field is omitted rather than filled with another project's logo - every other chart's icon is its one upstream's, and this chart has no such upstream. helm lint --strict notes "icon is recommended" as INFO and still exits 0. Rendered output differs in exactly the seven image prefixes and nothing else.	2026-08-24 15:23:35 +02:00
jklein	09fe3c2be6	Decouple appVersion from gluetun in wording and value ... The previous commit moved every image tag into values.yaml but left appVersion described as a marker "for the gluetun line", to be updated together with gluetun.image.tag. That still asserts a coupling the chart does not have, and the value v3.41.1 confirmed it at a glance. appVersion is now 1.0.0 (version 1.0.0+up1.0.0): the chart's own version marker, freely chosen and tied to no upstream. The texts say that instead of the old coupling in Chart.yaml, values.yaml and the two README passages. The README's remaining true statement is kept but generalized - renovate-bump-chart bumps the patch level on an unchanged appVersion for all nine images alike, which is not a gluetun special case. Also corrected on the way: the busybox init image comment claimed it was "pinned independently of appVersion (which tracks gluetun)". Neither half holds any more - appVersion tracks nothing, and every image in the chart is pinned the same way. No functional change: the rendered gluetun image is qmcgaw/gluetun:v3.41.1 before and after.	2026-08-24 15:10:14 +02:00
jklein	af5f9ed79b	Pin gluetun in values too, so Renovate proposes it there ... The chart bundles nine independently versioned upstreams, and eight of them were already pinned in values.yaml while only gluetun took its tag from appVersion. That split had no upside: it made gluetun the one image Renovate could not reach through the built-in helm-values manager, and it implied a "main app" the stack does not have. gluetun now carries gluetun.image.repository/tag like every other image, and the StatefulSet renders it from there. No tag comes from appVersion any more. Renovate picks all nine up through helm-values - the manager the repo already relies on for sidecar images - and ci/renovate-bump-chart.sh bumps the chart version with each update. Consequences, all documented where they bite: - renovate.json5 deliberately gets no app-version block for this chart. One would either duplicate the helm-values updates or rewrite an appVersion that selects no image. The absence is commented so it does not read as an oversight. - freesailarr leaves the change-app-version.yml choice list. That workflow rewrites appVersion and republishes, which for this chart would change no deployed image at all. - appVersion becomes a hand-maintained marker for the gluetun line. Since renovate-bump-chart.sh bumps the patch level on an unchanged appVersion, a gluetun update has to be paired with a hand edit of appVersion, or the +up suffix stops describing what the chart deploys. Noted in Chart.yaml, values.yaml and README.	2026-08-24 15:01:34 +02:00
jklein	e4f70bc856	Correct two firewall claims the runtime test disproved ... FIREWALL_INPUT_PORTS does not open the app ports inside a pod network. gluetun detects the pod's own subnet and inserts an INPUT accept for it ahead of the per-port rules, and every packet arriving at the pod IP matches that rule by destination. Measured with the packet counters: 50 fresh requests moved the subnet rule from 306 to 356 packets while every --dport rule stayed at 0 since container start. A port that listens but is not in the list (gluetun's control server on 8000) is reachable from another pod all the same. The variable is kept - it is the explicit statement of which ports are meant to be reachable, and the subnet detection is gluetun's behaviour rather than a guarantee of this chart - but the comments no longer claim the traffic would be dropped without it. Second correction, same run: the /tmp/gluetun emptyDir fixed the "open ... permission denied" failure, but gluetun also chowns the file, which needs CAP_CHOWN. With all capabilities but NET_ADMIN dropped that logs "chown /tmp/gluetun/ip: operation not permitted" on every VPN restart. The file is written and the public IP is persisted, so this is a log line rather than a failure, and granting CHOWN to silence it would widen the container's capabilities for nothing. Noted where the mount is declared.	2026-08-24 14:38:03 +02:00
jklein	bc6577f321	Document what the media subPaths actually buy ... The runtime test contradicted the assumption behind the change. Kubernetes turns every volumeMount into its own bind mount, and link()/rename() across two mount points fails with EXDEV even when both sides are the same claim on the same device: in the radarr container /downloads and /movies both report device 65025 and resolve to the same PV directory, yet linking between them fails with "Cross-device link", while the identical link succeeds when the claim root is mounted once and the categories are sub-directories under it. It is not a property of subPath - two plain mounts of the same claim without any subPath fail the same way, so the chart never supported cross-category hardlinks and this change does not regress anything. But the comment claimed a benefit the chart does not deliver, so it now states the measurement instead: subPath buys the layout (one claim, one sub-directory per category), not hardlinked imports. Getting those needs a single mount containing all categories, which is a change to the mount layout rather than a values setting.	2026-08-24 14:08:24 +02:00
jklein	cdb66a32f4	Per-app ingress and service, media subPaths ... Three review changes to the freesailarr chart. Ingress: the chart no longer derives hosts as <app>.<ingress.domain> from one Ingress object. The global ingress.domain is gone; every app carries its own <app>.ingress.host and renders its own Ingress <release>-<chart>-<app>-ingress with its own TLS secret tls-<release>-<chart>-<app>-ingress. The hosts are therefore independent and may live in unrelated domains. The host is required, but the required() call sits inside the loop over the *enabled* app ingresses, so switching an app's ingress off must not make the chart demand a host for it. clusterIssuer, className and annotations stay global defaults and are overridable per app; an explicitly set per-app value wins (nil check instead of "default", so an empty override is honoured). Media: media.<category>.subPath mounts a sub-directory of the claim instead of its root, default null (claim root = previous behaviour). The same existingClaim may back all three categories with different subPaths. That is the point rather than cosmetics: Radarr and Sonarr import by moving, and a move within one filesystem can be a hardlink instead of a copy - across volume boundaries every import duplicates the file. Services: the collective Service with named ports is replaced by one ClusterIP Service <release>-<chart>-<app>-service per enabled app that listens on a port, flaresolverr included; recyclarr serves no port in daemon mode and gets none. Each ingress points at its own app's service. All containers share gluetun's network namespace, so the services differ only in their port - they provide stable per-app DNS names, not network separation. The StatefulSet's governing serviceName no longer names a removed object.	2026-08-24 13:45:38 +02:00
jklein	d4f03cdfd9	Give gluetun a writable /tmp/gluetun ... gluetun logs "clearing public IP data: open /tmp/gluetun/ip: permission denied" every few seconds and never persists its public IP. It creates /tmp/gluetun with mode 0644, i.e. without the execute bit needed to enter the directory; it runs as root, but with all capabilities except NET_ADMIN dropped there is no DAC_OVERRIDE left to paper over the missing bit. An emptyDir provides the path with usable permissions.	2026-08-24 13:41:47 +02:00
jklein	adc87c2cc1	Bind the qBittorrent session to the VPN interface ... qBittorrent had no network interface configured, so libtorrent listened and announced on every interface of the shared pod network namespace - including eth0 (the pod IP) and loopback. gluetun's kill switch drops exactly those packets, so trackers answered with "skipping tracker announce (unreachable)" or timed out, no peers were found and torrents stalled at 0 bytes in stalledDL. Beyond the stall this is a leak: without the binding qBittorrent also listens on the pod IP, i.e. reachable past the tunnel. The setting only exists in the persisted config file, which qBittorrent creates itself on first start, so an init container seeds it before the app comes up. The edit is idempotent and preserves existing user settings: it replaces the keys if present, inserts them into the [BitTorrent] section if missing, and creates file or section if needed. The interface is configurable via qbittorrent.networkInterface (default tun0); emptying it drops the init container.	2026-08-24 13:41:47 +02:00
jklein	5e2d8e4083	Allow writable root filesystem for the linuxserver.io containers ... With readOnlyRootFilesystem the s6-overlay init cannot rewrite /etc/passwd, so the containers silently kept the image's built-in uid/gid 911 instead of the configured PUID/PGID (verified at runtime) - breaking ownership on the shared media volumes. Drop the now-unneeded /run and /tmp emptyDirs; deviation documented in values.yaml.	2026-08-24 13:41:47 +02:00
jklein	265190d175	Calibrate gluetun liveness more tolerant than readiness ... Short tunnel re-negotiations recover internally; a kubelet restart only prolongs the outage while the kill switch already blocks all egress. Liveness budget 60s, readiness stays at 30s.	2026-08-24 13:41:47 +02:00
jklein	0a5035ae83	Clean stale VPN state synchronously before gluetun starts ... Replace the upstream-recommended postStart hook, which runs concurrently with the entrypoint and loses the race (observed: it deleted the ip rule the restarted gluetun had just created, leaving the container in a permanent CrashLoop behind the kill switch). A command wrapper now removes stale table-51820 rules and the leftover tun device deterministically before exec'ing /gluetun-entrypoint, covering container restarts after unclean exits.	2026-08-24 13:41:47 +02:00
jklein	818a71f7b6	Clean up stale ip rules on gluetun container start ... An uncleanly exited gluetun leaves its ip rule in the shared pod network namespace; the restarted container then fails forever with 'adding ip rule 101: file exists' while the kill switch keeps blocking all egress. Apply the upstream-recommended Kubernetes fix: a postStart hook dropping table-51820 rules.	2026-08-24 13:41:47 +02:00
jklein	2211226c8e	Allow writable root filesystem for flaresolverr ... The image copies and patches the chromedriver binary to the hardcoded path /app/chromedriver at startup (no env override exists) and writes chromedriver caches under /app, so readOnlyRootFilesystem cannot hold; deviation documented in values.yaml. Reverts the HOME=/tmp workaround, which only covered the cache path, not the binary patching.	2026-08-24 13:41:46 +02:00
jklein	bce2b147a8	Set HOME=/tmp for flaresolverr ... The image's home is /app on the read-only root filesystem, but flaresolverr writes chromedriver caches under $HOME (/app/.local); pointing HOME at the /tmp emptyDir keeps the root filesystem read-only.	2026-08-24 13:41:46 +02:00
jklein	1ed70e31dd	Pin flaresolverr runAsUser/runAsGroup to 1000 ... The image declares its non-root user by name only, which the kubelet's runAsNonRoot check cannot verify (CreateContainerConfigError); pinning the uid/gid numerically satisfies the check.	2026-08-24 13:41:46 +02:00
jklein	d1933e0b53	Fix gluetun image tag: Docker Hub tags carry a v prefix ... The issue plan listed qmcgaw/gluetun:3.41.1, but the published tag is v3.41.1. appVersion is the exact image tag per the style guide, so appVersion becomes v3.41.1 and the chart version 1.0.0+upv3.41.1 (precedent: matrix-synapse, satisfactory, calibre-web-automated).	2026-08-24 13:41:46 +02:00
jklein	914c2d0205	Add freesailarr chart: gluetun-tunneled media automation stack ... Single-pod StatefulSet running gluetun (appVersion 3.41.1) as Wireguard VPN gateway with qbittorrent, prowlarr, flaresolverr, radarr, recyclarr, sonarr, seerr and bazarr sharing its network namespace. Config volumes via volumeClaimTemplates, media libraries as existing claims, per-app enable/ingress toggles, computed FIREWALL_INPUT_PORTS, hardened security contexts with documented per-image deviations. Wires up publish workflow, change-app-version choice, install-test exclusion and README overview.	2026-08-24 13:41:46 +02:00