Thomas Stallinger
d496adad09
Neue scripts/lib/reporting.sh (tuxflotte_report_installation_event())
meldet best-effort an POST /api/v1/devices/{device_id}/installation-events
(device_fingerprint-authentifiziert, siehe provisioning-server-Commit
51fbf0f) - ein Fehlschlag beim Melden selbst darf die eigentliche
Installation nie aufhalten.
Vier Meldepunkte:
- "activation_confirmed" direkt nach erfolgreichem Provisioning-Handshake
(15_server_handshake.sh)
- "installation_started" direkt nach bestaetigtem Commit Point
(installer.sh)
- "installation_completed" ganz am Ende von backend_postinstall(), vor dem
finalen Reboot (backend.sh)
- "installation_failed" zentral in boot-autostart.sh (einziger Ort, an dem
der echte Exit-Code von installer.sh bekannt ist, ohne jedes Modul
einzeln instrumentieren zu muessen) - Detail = letzte 40 Logzeilen,
enthalten bereits die eigentliche [FEHLER]-Meldung des gescheiterten
Moduls. Nur bei STATUS != 0, nicht bei einem kontrollierten Abbruch an
einem Commit-Gate (STATUS = 0).
Nutzer-Wunsch (01.09.2026, nach dem ersten echten Hardware-Test):
Fehlschlaege waehrend der Installation sichtbar machen, ohne am
Bildschirm mitschreiben zu muessen ("das ist kein Flow... fuer die
Weiterentwicklung eines irgendwann fehlerfreien Betriebs sind fuer uns
diese Meldungen Gold wert").
Live in QEMU end-to-end verifiziert: alle drei Erfolgs-Meilensteine
korrekt in device_installation_events angekommen (activation_confirmed,
installation_started, installation_completed), vollstaendiger Durchlauf
bis zum echten Mint-Cinnamon-Login-Bildschirm nach Reboot bestaetigt.
77 lines
3.9 KiB
Bash
Executable File
77 lines
3.9 KiB
Bash
Executable File
#!/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]}"
|
|
|
|
# Nutzer-Wunsch (01.09.2026): Fehlschlaege sollen sich melden, ohne dass am
|
|
# Bildschirm mitgeschrieben werden muss ("Gold wert" fuer die eigene
|
|
# Fehlersuche). Nur bei echtem Fehlschlag (STATUS != 0) - ein kontrollierter
|
|
# Abbruch an einem Commit-Gate (Nutzer sagt "N") beendet installer.sh
|
|
# ebenfalls, aber mit "exit 0", das ist kein Fehler. Detail = die letzten
|
|
# Logzeilen (enthalten bereits die eigentliche [FEHLER]-Meldung des
|
|
# gescheiterten Moduls) - best effort, siehe reporting.sh.
|
|
if [[ "${STATUS}" -ne 0 ]]; then
|
|
# shellcheck source=lib/reporting.sh
|
|
source /opt/tuxflotte/scripts/lib/reporting.sh
|
|
tuxflotte_report_installation_event "installation_failed" "$(tail -n 40 "${LOG_FILE}" 2>/dev/null)"
|
|
fi
|
|
|
|
# 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
|