LibrePortal/scripts/cli/commands/updater/cli_updater_verify.sh
librelad c3494f7d19 Make CFG_SEARXNG_THEME actually apply
The hook substituted `simple_style: auto`, a line that only exists in SearXNG's
full bundled settings.yml. The file generated here is the minimal
`use_default_settings: true` form with no ui: block at all, so the sed matched
nothing and the theme setting had never taken effect on any install.

It could not have worked even with the right pattern: the entrypoint chowns
settings.yml to searxng:searxng (uid 977) mode 644 on first start, so the
host-side docker user cannot write to it. The edit now runs inside the
container via docker exec, targeting the real key path
ui.theme_args.simple_style.

Three shapes are handled so the hook stays correct on repeat installs and
alongside hand edits: substitute in place when simple_style already exists,
nest theme_args inside an existing ui: block rather than appending a second one
(a duplicate YAML key SearXNG refuses to load), and otherwise append the whole
block. All three were exercised against the running container and produce valid
YAML with exactly one ui: block. awk rather than `sed a\` for the nesting case,
since busybox sed does not expand \n in appended text.

The value is validated against auto|light|dark|black before being written.
SearXNG checks it at startup and exits on anything else, so an unrecognised
CFG_SEARXNG_THEME would have taken the app down instead of merely looking
wrong; it is now reported and the default left alone.

Verified end to end on a base install and a --local instance: both come up,
serve 200, and report Dark as the selected style on /preferences, each with its
own settings.yml and secret_key. The instance's cloned hook correctly reads
CFG_SEARXNG_PROBE_THEME and targets its own container, since the container name
is built from $app_name. Both test installs were removed afterwards.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-19 19:58:08 +01:00

119 lines
5.5 KiB
Bash

#!/bin/bash
# Upgrade verification — "did that rung actually land?"
# ---------------------------------------------------------------------------
# A stepped upgrade is only as safe as its verification. Stepping 31 -> 32 -> 33
# is arithmetic; knowing that 32 FINISHED before touching 33 is the whole ball
# game, because the dangerous state is invisible from the outside: Nextcloud
# runs its migration on boot and can sit in maintenance mode, or fail halfway,
# while Docker cheerfully reports the container healthy. Advance a rung then and
# you have skipped a migration on live data.
#
# So "the container is up" is explicitly NOT accepted as proof for an app that
# declares a verifier. Contract:
#
# <app>_upgrade_verify <app> <expected-tag> <deadline-epoch> -> 0 = verified
#
# It must poll until the deadline and return 0 ONLY when it can positively
# confirm the app is serving at the expected version with no migration
# outstanding. Any other outcome — unhealthy, indeterminate, timed out — must
# return non-zero. Uncertainty is a failure here, not a maybe: the engine
# aborts and restores rather than guessing, which is the only honest reading
# when the alternative risks someone's data.
#
# Apps with no verifier fall back to updaterVerifyGeneric, which is deliberately
# conservative and is NOT sufficient for a stepped upgrade — the engine refuses
# to ladder an app that has not declared a real one.
# Container name for an app's ANCHOR service — the one whose image carries the
# app's own version. Read from the compose rather than assumed, because
# "<app>-service" is a convention and not every app follows it: matrix names its
# anchor service matrix-synapse and stoat names its api, so the assumption
# inspected a container that does not exist, found no state at all, and the
# generic verifier could only ever time out on exactly the stateful apps that
# most need verifying. Falls back to the convention when there is no compose.
_updaterPrimaryContainer() {
local app="$1"
local compose="${containers_dir%/}/$app/docker-compose.yml"
local fallback; fallback="$(printf '%s-service' "${app//_/-}")"
[ -f "$compose" ] || { printf '%s' "$fallback"; return 0; }
local up; up="$(printf '%s' "$app" | tr '[:lower:]' '[:upper:]')"
# The service block that owns the bare <APP>_VERSION_TAG sentinel, then that
# block's container_name (compose's own answer for what the container is
# called). Service name is the fallback: compose defaults to it.
local name
name="$(awk -v key="#LIBREPORTAL|${up}_VERSION_TAG|" '''
/^[[:space:]]{2,4}[a-zA-Z0-9_-]+:[[:space:]]*(#|$)/ {
s=$1; sub(/:.*/,"",s); gsub(/[[:space:]]/,"",s)
if (found && cname=="") { print svc; exit }
if (found) exit
svc=s; cname=""
}
index($0,key) { found=1 }
found && /^[[:space:]]*container_name:/ {
cname=$2; gsub(/["']/,"",cname); print cname; exit
}
END { if (found && cname=="") print svc }
''' "$compose" 2>/dev/null | head -1 | tr -d "[:space:]")"
[ -n "$name" ] && printf '%s' "$name" || printf '%s' "$fallback"
}
# Generic health: running, not restarting, healthcheck (if any) reporting
# healthy, and STILL true after a settle period — a crash-loop looks perfect
# in the instant between restarts. Good enough for a single in-place update,
# never good enough to justify climbing another rung.
updaterVerifyGeneric() {
local app="$1" deadline="${3:-$(( $(date +%s) + 120 ))}"
local c; c="$(_updaterPrimaryContainer "$app")"
local stable_needed=3 stable=0
while [ "$(date +%s)" -lt "$deadline" ]; do
local state health restarts
state="$(dockerCommandRun "docker inspect --format '{{.State.Status}}' $c" 2>/dev/null | tr -d '\r')"
health="$(dockerCommandRun "docker inspect --format '{{if .State.Health}}{{.State.Health.Status}}{{else}}none{{end}}' $c" 2>/dev/null | tr -d '\r')"
restarts="$(dockerCommandRun "docker inspect --format '{{.RestartCount}}' $c" 2>/dev/null | tr -d '\r')"
if [ "$state" = "running" ] && { [ "$health" = "healthy" ] || [ "$health" = "none" ]; }; then
stable=$((stable + 1))
[ -z "${_uv_restarts:-}" ] && _uv_restarts="$restarts"
# A restart during the settle window means it is looping, not up.
[ "$restarts" != "$_uv_restarts" ] && stable=0 && _uv_restarts="$restarts"
(( stable >= stable_needed )) && { unset _uv_restarts; return 0; }
else
stable=0
fi
sleep 5
done
unset _uv_restarts
return 1
}
# Does this app ship a real verifier? The stepped engine requires one.
updaterHasVerifier() {
local app="$1"
declare -F "${app}_upgrade_verify" >/dev/null 2>&1
}
# updaterVerifyUpgrade <app> <expected-tag> [timeout-secs]
# Dispatches to the app's verifier, falling back to the generic check. Returns
# 0 only on positive confirmation.
updaterVerifyUpgrade() {
local app="$1" expected="$2" timeout="${3:-600}"
local deadline=$(( $(date +%s) + timeout ))
if updaterHasVerifier "$app"; then
isNotice "Verifying $app is serving $expected (up to ${timeout}s)…"
if "${app}_upgrade_verify" "$app" "$expected" "$deadline"; then
isSuccessful "$app verified at $expected."
return 0
fi
isError "$app did NOT verify at $expected — treating as failed."
return 1
fi
isNotice "$app has no upgrade verifier; using the generic health check."
updaterVerifyGeneric "$app" "$expected" "$deadline"
}