Thomas Stallinger
bc13169418
Neuer Service tuxflotte-installer.service startet installer.sh beim Boot direkt auf tty1 (Type=idle, Conflicts=getty@tty1.service) - kein manuelles Anmelden/sudo mehr noetig, egal ob Auto-Modus oder interaktiver Test-/Entwicklungslauf. Wrapper boot-autostart.sh spiegelt die Ausgabe zusaetzlich nach /var/log/tuxflotte-installer.log. log_step() (scripts/lib/logging.sh) gibt vor jedem Modul einen klar abgesetzten "[n/12] <Label>"-Block aus - gilt fuer Dev- UND Produktiv-Build gleichermassen (die tty-Konsole ist die einzige UI, die eine Person vor dem Geraet sieht, kein Kiosk-Browser mehr). scripts/build_boot_medium.sh buendelt lb clean/config/build (loeste die bisherigen Hand-Aufrufe ab) und steuert per --dev-Flag einen SSH- Debug-Zugang (tuxflotte/test123) - ohne --dev bleibt SSH deaktiviert, keine gebackenen Zugangsdaten (Produktiv-Default). Zwei echte, live gefundene Bugs unterwegs behoben: - Debians trixie-sshd_config deaktiviert PasswordAuthentication per Default - fuer den Dev-Testzugang explizit wieder aktiviert. - Ein ExecStopPost, der getty@tty1.service nach Dienstende neu startet, ist unzuverlaessig (Race mit dem eigenen TTY-Teardown, Job wurde angestossen, blieb aber inactive/dead). Geloest durch einen deterministischen Fallback in boot-autostart.sh selbst: die Konsole faellt nach installer.sh in eine interaktive Shell statt auf einen eventuell nie zurueckkehrenden getty zu warten. Live verifiziert in der enterprise-QEMU-VM (zwei frische Enrollment- Sessions, echte anode-Aktivierung, "Bekanntes Geraet erkannt"-Pfad): Boot laeuft ohne jede manuelle Anmeldung direkt in installer.sh, alle 12 Fortschritts-Banner erscheinen korrekt nummeriert, Commit-Gate und kontrollierter Abbruch funktionieren, SSH-Login mit Passwort funktioniert, Fallback-Shell nach Programmende reagiert auf Eingaben.
37 lines
1.7 KiB
Bash
Executable File
37 lines
1.7 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"
|
|
|
|
/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
|