On pod start the nzbget container raced gluetun: /etc/resolv.conf points at
10.128.0.1 (reachable only via the WireGuard tunnel), so for the ~20s gluetun
needs to establish the tunnel every DNS lookup from nzbget returned EAI_AGAIN.
Any in-queue download that had articles fetched during that window dropped
below the HealthCheck threshold (~97.9%) and was auto-cancelled — even items
that would otherwise complete (saw 97.6-97.8% health = "very nearly fine").
Override the nzbget container's entrypoint to poll DNS resolution and only
exec /init once it succeeds. That's the direct test of "tunnel is up + DNS
works", which is what nzbget needs.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
nzbget's usenet downloads (NNTP/563) were egressing DIRECT: the HTTP_PROXY env
pointed at a standalone gluetun that isn't even running, and NNTP ignores HTTP
proxies anyway. Adopt the qbittorrent pattern instead: run gluetun as a sidecar
in the nzbget pod so the shared netns + kill-switch force ALL traffic through
the tunnel, regardless of protocol.
- Add gluetun sidecar (own AirVPN device via gluetun-wireguard-nzbget secret,
FIREWALL_INPUT_PORTS=6789 to keep the WebUI reachable, DOT=off + DNS_ADDRESS
per the AirVPN-blocks-DoT gotcha).
- Remove the useless HTTP_PROXY/NO_PROXY envs from nzbget.
- Delete the standalone gluetun chart/values/application (was not running; only
nzbget referenced it).
Trade-off: if the tunnel drops, downloads stop (no leak) rather than falling
back to direct — same behaviour as qbittorrent.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Bump Server1.Connections 30->50 for headroom (Newshosting cap is 100, but
TLS-on-arm overhead makes maxing it counterproductive). Add global
ArticleCache=700 (MB RAM buffer, within the 2Gi limit) and WriteBuffer=1024
(KB/conn) to reduce write thrash on the contended SSD, which is the more
likely throughput ceiling than connection count at our ~100-300 Mbit line.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
nzbget does not expand OS env vars in nzbget.conf (its ${...} only
references other nzbget options), so the previous secretKeyRef-as-env
approach left the literal ${NEWSHOSTING_USER} in the config and auth
failed with 400 DENIED.
Add initContainers support to the chart and an init step that seds the
Server1 (newshosting) block into nzbget.conf on every start: non-secret
settings in git, username/password from the usenet-creds Secret. Rotating
the secret + restarting re-renders the creds; no password lands in git.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Reuse the existing nzbget chart as the usenet downloader. Newshosting
username/password come from the out-of-band `usenet-creds` Opaque secret
(same pattern as gluetun-wireguard), exposed as env and referenced in
nzbget.conf via ${NEWSHOSTING_USER}/${NEWSHOSTING_PASS} so no plaintext
provider password lands in the config file.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
gilgamezh