#!/usr/bin/env bash
set -Eeuo pipefail

# Wird von tuxflotte-installer.service beim Boot direkt auf tty1 gestartet -
# unabhaengig davon, ob config/installer.conf einen Auto-Modus-
# Aktivierungscode mitbringt (personalisierte Kunden-ISO, siehe
# scripts/build_customer_iso.sh) oder nicht (generisches Test-/
# Entwicklungsabbild): installer.sh fragt in letzterem Fall selbst
# interaktiv nach (12_enrollment_auth.sh, 05_network.sh-WLAN-Auswahl), auf
# genau dieser Konsole - der Service leitet dafuer TTYPath=/dev/tty1 durch.
#
# Schreibt zusaetzlich zur journal-Ausgabe (StandardOutput=journal+console
# im systemd-Unit) in eine Logdatei - per SSH/Konsole nachtraeglich
# einsehbar, ohne journalctl zu brauchen.
LOG_FILE="/var/log/tuxflotte-installer.log"
BANNER_FILE="/opt/tuxflotte/banner.txt"

# Begruessungsbanner (Tuxflotte-Schriftzug + Flotten-Grafik, 80 Spalten) -
# reine Optik, ins Logfile mitschreiben schadet nicht, aber nicht fatal
# wenn die Datei mal fehlt (set -e: "if" statt "&&", sonst wuerde ein
# fehlendes Banner das ganze Skript beenden).
if [[ -r "${BANNER_FILE}" ]]; then
    { cat "${BANNER_FILE}"; echo; } | tee -a "${LOG_FILE}"
fi

# TUXFLOTTE_TTY_LIVE steuert, ob log_module_ok()/log_module_failed()
# (logging.sh) Kreisel/Haken mit ANSI-Fettschrift/Farbe zeigen oder einen
# reinen Klartext-Fallback. "-t 1" selbst ist hier IMMER falsch: das
# systemd-Unit setzt "StandardOutput=journal+console" (siehe
# tuxflotte-installer.service) - fd1 dieses Prozesses ist deshalb ein
# Journal-Socket, kein rohes tty-Zeichengeraet, ganz unabhaengig von der
# "installer.sh | tee"-Pipe weiter unten. journald spiegelt die Bytes
# trotzdem unveraendert (inkl. ANSI-Escapes) auf die echte Konsole - live
# gefunden (01.09.2026, QEMU-Regressionstest): mit "-t 1" als Kriterium
# blieb die geplante Fettschrift/Kreisel-Darstellung auf der echten Konsole
# deshalb IMMER inaktiv (Klartext-Fallback), obwohl ein Mensch am Geraet
# echte ANSI-Codes zu sehen bekommen haette. Da dieses Skript ausschliesslich
# ueber genau dieses systemd-Unit gestartet wird, ist "immer aktiv" hier die
# richtige, zuverlaessige Antwort - "-t 1" bleibt in logging.sh als Fallback
# fuer andere Aufrufkontexte (z.B. installer.sh manuell per SSH-Pty).
export TUXFLOTTE_TTY_LIVE=true
export TUXFLOTTE_LOG_FILE="${LOG_FILE}"

/opt/tuxflotte/scripts/installer.sh 2>&1 | tee -a "${LOG_FILE}"
STATUS="${PIPESTATUS[0]}"

# Live gefunden (31.08.2026): ein ExecStopPost, der beim Dienstende
# getty@tty1.service neu startet, ist unzuverlaessig (Race mit dem eigenen
# TTY-Teardown dieses Dienstes - der Job wurde angestossen, blieb aber
# "inactive/dead"). Stattdessen: diese Konsole faellt nach installer.sh
# (egal ob Erfolg, kontrollierter Abbruch an einem Commit-Gate, oder
# Fehler) deterministisch in eine interaktive Root-Shell - kein Race,
# garantiert nutzbare Konsole fuer Fehlersuche/manuellen Neustart. Im
# Erfolgsfall mit tatsaechlichem Deployment loest 40_backend.sh ohnehin
# selbst einen Reboot aus, wodurch diese Shell nie sichtbar wird.
{
    echo
    echo "Tuxflotte-Installer beendet (Exit-Code: ${STATUS})."
    echo "Diese Konsole steht fuer Fehlersuche/manuellen Neustart zur Verfuegung."
    echo
} | tee -a "${LOG_FILE}"

exec /bin/bash --login