mirror of
https://github.com/alexbelgium/hassio-addons.git
synced 2026-08-22 04:43:33 +02:00
988cecb122
* fix(birdnet-pi): restore the ingress Caddy site, ingress returned 502 nginx forwards ingress traffic to 127.0.0.1:8082 (rootfs/etc/nginx/servers/ ingress.conf:11), a site appended to the Caddyfile by helpers/caddy_ingress.sh. The upstream script $HOME/BirdNET-Pi/scripts/update_caddyfile.sh regenerates /etc/caddy/Caddyfile from scratch and 02-caddy.sh runs it immediately before `exec caddy run`, so 91-nginx_ingress.sh injected a call to caddy_ingress.sh into that script to re-add the site. The injection was anchored on `sudo caddy fmt --overwrite`. Since 2026.07.10-1 the Dockerfile strips `sudo ` from every BirdNET-Pi script at build time (Dockerfile:110), so the shipped line is `caddy fmt --overwrite` and the anchor stopped matching. sed reports success when a pattern matches nothing, so this failed silently: Caddy came up listening only on :8081 and every ingress request got connection-refused on 8082. Confirmed by extracting the script from the published ghcr.io/alexbelgium/birdnet-pi-amd64 image - it contains no `sudo`. - 91-nginx_ingress.sh: make the anchor accept the line with or without `sudo`, skip the injection when it is already there (cont-init re-runs on restart), and verify afterwards, falling back to appending the call if the anchor is ever gone again. - caddy_ingress.sh: return early when a `:8082` site already exists. The script now runs from more than one place, and a duplicate site address makes Caddy refuse to start. - 02-caddy.sh: re-add the ingress site just before starting Caddy if it is missing, so a future upstream change to update_caddyfile.sh cannot silently bring back the 502. - 91-nginx_ingress.sh: drop /ingress_url when ingress is off, so that marker is a truthful signal for the check above even across an in-container restart. Verified with a harness that replays the boot sequence (build-time sudo strip, 81-modifications.sh, 91-nginx_ingress.sh, 02-caddy.sh) against the real upstream update_caddyfile.sh: master ends with no :8082 site, this branch ends with exactly one, on fresh boot, on restart, and when the `caddy fmt` anchor is removed entirely; standalone mode still gets no ingress site. Closes #2928 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(birdnet-pi): harden the ingress-site recovery check in 02-caddy.sh Review feedback on the pre-start check: - Require /etc/caddy/Caddyfile to exist and silence grep's stderr. `! grep` is also true for grep's exit code 2, so an unreadable or missing Caddyfile read as "ingress site missing" and would have produced an ingress-only Caddyfile out of an error state. Letting caddy fail on the missing config is easier to diagnose. - Report a failure of caddy_ingress.sh instead of swallowing it. Do not exit: /custom-services.d scripts are LSIO longruns that s6 restarts when they return, so exiting would flap the service and take the WebUI down on 8081 as well, which is strictly worse than ingress alone being broken. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>