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.
25 lines
1.1 KiB
Bash
Executable File
25 lines
1.1 KiB
Bash
Executable File
#!/bin/sh
|
|
set -e
|
|
|
|
# Steuert SSH-Zugang ueber einen Build-Parameter (scripts/build_boot_medium.sh
|
|
# --dev), nicht ueber einen fest gebackenen Zustand. Der Marker
|
|
# /etc/tuxflotte-dev-build wird von build_boot_medium.sh vor dem lb-build-Lauf
|
|
# gesetzt/entfernt - siehe dort.
|
|
|
|
if [ -e /etc/tuxflotte-dev-build ]; then
|
|
echo "Dev-Build: SSH-Debug-Zugang wird aktiviert (tuxflotte/test123)."
|
|
id tuxflotte >/dev/null 2>&1 || useradd -m -s /bin/bash tuxflotte
|
|
echo "tuxflotte:test123" | chpasswd
|
|
usermod -aG sudo tuxflotte
|
|
# Debians trixie-sshd_config-Default hat PasswordAuthentication live
|
|
# entdeckt bereits deaktiviert (nur publickey angeboten) - fuer den
|
|
# Testzugang per Passwort explizit wieder aktivieren.
|
|
mkdir -p /etc/ssh/sshd_config.d
|
|
echo "PasswordAuthentication yes" > /etc/ssh/sshd_config.d/90-tuxflotte-dev.conf
|
|
rm -f /etc/tuxflotte-dev-build
|
|
else
|
|
echo "Produktiv-Build: SSH bleibt deaktiviert, keine gebackenen Zugangsdaten."
|
|
rm -f /etc/systemd/system/multi-user.target.wants/ssh.service
|
|
ln -sf /dev/null /etc/systemd/system/ssh.service
|
|
fi
|