#!/bin/bash
# Keepalived-Health-Check (chk_edgeguard).
#
# WICHTIG (Incident 2026-08-03): Dieser Check entscheidet mit, ob ein Node die
# VIP übernehmen bzw. per Preempt zurückholen darf. Er darf NUR dann "gesund"
# (exit 0) melden, wenn der Node Traffic WIRKLICH bedienen kann — nicht nur
# "edgeguard-api-Prozess up". Sonst reißt ein frisch gebooteter / mitten im
# Deploy befindlicher Node (haproxy noch nicht bereit) die VIP an sich, obwohl
# er nichts bedient → Cluster-Ausfall, bis der Node hart abgeschaltet wird.
#
# ALLE Bedingungen müssen erfüllt sein, sonst exit 1 → Instanz geht in FAULT →
# kein (Re-)Preempt, der gesunde Peer behält/bekommt die VIP.

# 1) edgeguard-api antwortet auf den Health-Endpoint (Unix-Socket oder Loopback)?
curl -sf --max-time 2 --unix-socket /run/edgeguard/api.sock \
    http://localhost/api/v1/system/health > /dev/null 2>&1 \
    || curl -sf --max-time 2 http://127.0.0.1:9443/api/v1/system/health > /dev/null 2>&1 \
    || exit 1

# 2) haproxy-Prozess aktiv? Während Boot/Restart kurz false → Node bleibt in dem
#    Fenster Backup (kann nicht preempten).
systemctl is-active --quiet haproxy 2>/dev/null || exit 1

# 3) haproxy hört wirklich auf dem oeffentlichen TLS-Port :443 (bindet = bedient)?
#    Faengt "Prozess up, aber Config kaputt / Port nicht gebunden" ab. :443 ist
#    architektur-bedingt immer gebunden (Public-TLS + ACME-Webroot + Mgmt-FQDN-
#    Fallback), also ein verlaessliches Ready-Signal.
ss -H -ltn 2>/dev/null | awk '{print $4}' | grep -Eq ':443$' || exit 1

exit 0