tuxflotte-installer/boot-medium/config/includes.chroot/opt/tuxflotte/scripts/lib/logging.sh

#!/usr/bin/env bash

log_info() {
  echo "[INFO ] $*"
}

log_warn() {
  echo "[WARN ] $*" >&2
}

log_error() {
  echo "[ERROR] $*" >&2
}

log_success() {
  echo "[ OK  ] $*"
}

# Live gefunden (01.09.2026, echter Hardware-Test): "[[ -t 1 ]]" ist auf
# der echten Konsole IMMER falsch, weil boot-autostart.sh installer.sh
# grundsaetzlich durch "| tee -a logfile" schickt (fuer die persistente
# Logdatei, siehe Phase 2) - installer.sh selbst schreibt deshalb nie
# direkt auf ein tty, sondern immer in eine Pipe. Ergebnis: die geplante
# Fettschrift/Farb-Hervorhebung war auf dem echten Geraet nie aktiv, ganz
# unabhaengig vom Terminal, das der Kunde tatsaechlich vor sich hat.
# boot-autostart.sh prueft "[[ -t 1 ]]" deshalb VOR dem Aufbau dieser Pipe
# (an der Stelle noch zuverlaessig) und exportiert das Ergebnis als
# TUXFLOTTE_TTY_LIVE - hier nur noch auswerten, mit "-t 1" als Fallback
# fuer direkte, nicht ueber boot-autostart.sh gestartete Läufe (z.B.
# manuelles Testen von installer.sh per SSH).
_tuxflotte_console_is_live() {
  if [[ -n "${TUXFLOTTE_TTY_LIVE:-}" ]]; then
    [[ "${TUXFLOTTE_TTY_LIVE}" == true ]]
  else
    [[ -t 1 ]]
  fi
}

# Klar abgesetzte Fortschrittsanzeige fuer die tty-Konsole des Boot-Mediums
# (kein Desktop, kein Kiosk-Browser - die Terminal-Ausgabe selbst ist die
# einzige UI, die eine Person vor dem Geraet sieht). Gilt fuer Dev- UND
# Produktiv-Build gleichermassen, nicht nur zum Debuggen - siehe Plan
# "Klare Fortschrittsanzeige auf der Konsole". Format/Stil bewusst an die
# bestehenden Banner in 17_device_status.sh angelehnt (Titel + "="-Linie
# gleicher Laenge, keine Sonderzeichen, die auf einer rohen VT-Konsole
# fehlen koennten).
declare -A TUXFLOTTE_STEP_LABELS=(
  [00_preflight.sh]="Vorbereitung"
  [05_network.sh]="Netzwerkverbindung wird hergestellt"
  [10_hardware.sh]="Hardware wird erkannt"
  [12_enrollment_auth.sh]="Aktivierungscode wird geprüft"
  [15_server_handshake.sh]="Verbindung zu anode wird hergestellt"
  [17_device_status.sh]="Gerätestatus wird abgerufen"
  [20_profile_selection.sh]="Bereitstellungsvorlage wird ausgewählt"
  [25_installation_confirm.sh]="Installationsbestätigung"
  [30_runtime_blueprint.sh]="Installationsplan wird aufgelöst"
  [40_backend.sh]="Golden Image wird geladen und installiert"
  [20_storage.sh]="Speicher-Zusatzprüfung"
  [99_finish.sh]="Abschluss"
)
readonly -a TUXFLOTTE_STEP_ORDER=(
  00_preflight.sh 05_network.sh 10_hardware.sh 12_enrollment_auth.sh
  15_server_handshake.sh 17_device_status.sh 20_profile_selection.sh
  25_installation_confirm.sh 30_runtime_blueprint.sh 40_backend.sh
  20_storage.sh 99_finish.sh
)
TUXFLOTTE_STEP_COUNT=0

log_step() {
  local module_name="$1"
  local label="${TUXFLOTTE_STEP_LABELS[$module_name]:-$module_name}"
  local total="${#TUXFLOTTE_STEP_ORDER[@]}"
  local bold="" reset=""

  TUXFLOTTE_STEP_COUNT=$((TUXFLOTTE_STEP_COUNT + 1))

  # Klartext-Fallback ohne Terminal (z.B. wenn stdout in eine Log-Datei
  # umgeleitet wird) - kein tput-Aufruf, ncurses-bin ist bewusst nicht Teil
  # des schlanken Paketsatzes, rohe ANSI-Codes reichen und sind ueberall
  # ohne Zusatzpaket verfuegbar.
  if _tuxflotte_console_is_live; then
    bold=$'\033[1m'
    reset=$'\033[0m'
  fi

  local title
  title="[${TUXFLOTTE_STEP_COUNT}/${total}] ${label}"

  printf '\n%s%s%s\n' "${bold}" "${title}" "${reset}"
  printf '%s\n\n' "$(printf '=%.0s' $(seq 1 ${#title}))"
}

# Kompakte Alternative zu log_step() fuer den unbeaufsichtigten
# Auto-Modus (echte Kunden-Installation, siehe run_module_quiet() in
# utils.sh). Live-Rueckmeldung des Nutzers (01.09.2026) nach dem ersten
# erfolgreichen Hardware-Test: die bisherige Fülle an [INFO]/[WARN]-Zeilen
# je Modul ist "nicht schön für das menschliche Auge" - Vorschlag:
# ein Kreisel waehrend ein Modul laeuft, ein gruener Haken wenn fertig,
# Details nur bei einem Fehlschlag. Ein einziges Ergebnis pro Modul statt
# einer ganzen Log-Wand ist genau das ("dann sind es nicht soviel
# Zeichen").
# Reines ASCII statt Unicode-Braille/Haken-Zeichen (⠋⠙.../✓/✗): live gefunden
# (01.09.2026, QEMU-Regressionstest) - die vt-Konsolenschriftart des
# Boot-Mediums deckt diese Codepoints nicht ab, gerendert wurde nur ein
# generischer Ersatz-Kasten statt eines Haekchens. ASCII-Zeichen sind auf
# jeder Konsolenschriftart garantiert vorhanden, unabhaengig von Hardware/
# Zeichensatz.
_TUXFLOTTE_SPINNER_FRAMES=(\| / - \\)

# Setzt TUXFLOTTE_CURRENT_TITLE statt den Titel per "echo"+Command-
# Substitution zurueckzugeben - Command-Substitution laeuft in einer
# Subshell, deren Variablenaenderungen (hier: der TUXFLOTTE_STEP_COUNT-
# Zaehler) beim Verlassen verloren gehen. Live gefunden (01.09.2026, QEMU-
# Regressionstest): mit "title=\"\$(log_module_title ...)\"" blieb der
# Zaehler wegen genau dieser Subshell dauerhaft bei 1 stehen ("[1/12]" bei
# jedem Modul statt hochzuzaehlen).
log_module_title() {
  local module_name="$1"
  local label="${TUXFLOTTE_STEP_LABELS[$module_name]:-$module_name}"
  local total="${#TUXFLOTTE_STEP_ORDER[@]}"

  TUXFLOTTE_STEP_COUNT=$((TUXFLOTTE_STEP_COUNT + 1))

  TUXFLOTTE_CURRENT_TITLE="[${TUXFLOTTE_STEP_COUNT}/${total}] ${label}"
}

log_module_ok() {
  local title="$1"

  if _tuxflotte_console_is_live; then
    printf '\r%s \033[1;32m[OK]\033[0m\n' "${title}"
  else
    printf '%s [OK]\n' "${title}"
  fi
}

log_module_failed() {
  local title="$1"

  if _tuxflotte_console_is_live; then
    printf '\r%s \033[1;31m[FEHLER]\033[0m\n' "${title}"
  else
    printf '%s [FEHLER]\n' "${title}"
  fi
}