Credentials und Fingerprint mit umask 077 angelegt (kein kurzes
Lesefenster vor dem chmod). platform-docs roadmap/agent-zugang-haertung.md
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Damit landen spätere shim-/GRUB-Updates in EFI/tuxflotte, das die
Firmware startet (vorher EFI/ubuntu bzw. EFI/debian).
roadmap/secure-boot-verschluesselung.md
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Fassung "freigegeben" der Ausrollstufe, Secret per curl --header @datei
(0600, per trap gelöscht) statt auf der Kommandozeile.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Nicht mehr genutzt seit dem eigenen Boot-Medium (ADR-0025). Die Testdateien
enthielten u. a. ein WLAN-Passwort im Klartext; es bleibt in der Historie,
die Abhilfe ist ein Passwortwechsel, nicht dieses Entfernen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
GNU tar uebernimmt beim Auspacken ohne --xattrs-include nur user.*;
security.capability (cap_net_raw an ping u.a.) ging beim Staging-Auspacken
in package_golden_image.sh verloren, image_deploy.sh entpackte zudem ganz
ohne --xattrs. Befund Liebherr-83 15.10.2026 (ping fuer Benutzer kaputt).
Rundlauf mit setcap/tar im User-Namespace geprueft. Wirkt erst mit neu
gepackten Golden Images und neuem Boot-Medium; bestehende Geraete repariert
ansible-content grundsystem.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bisher kam das Org-WLAN (TUXFLOTTE_WIFI_SSID/-PSK) nur aufs Geraet, wenn
ueber genau dieses WLAN installiert wurde - export_connection_profile()
uebernimmt nur das aktive Profil. Per Kabel installierte Geraete hatten
kein WLAN (Liebherr-83, 14.10.2026). Jetzt immer
tuxflotte-installations-wlan.nmconnection per nmcli --offline, ohne
permissions, PSK in der Datei; Doppel mit dem exportierten Profil wird
entfernt. Eigener Dateiname, damit der absent-Zweig der Rolle org-wlan
ihn nicht loescht.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Der Symlink wurde fuer die chroot-Phase durch eine Kopie der resolv.conf
des Installationsnetzes ersetzt und nie zurueckgesetzt. Installierte
Geraete verloren dadurch nach einem Ortswechsel die Namensaufloesung
(Liebherr-83, 14.10.2026: Agent "Name or service not known"). Jetzt
Symlink-Ziel bzw. Datei sichern und in image_deploy_unbind_mounts()
zurueckspielen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Im installierten System stand neben dem vergebenen Namen noch der der
Referenz-VM in /etc/hosts (Befund 13.10.2026, VM 107).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Statt filesystem.squashfs als root zu entpacken und neu zu packen, kommt
installer.conf in eine kleine Schicht /live/tuxflotte-kunde.squashfs
(live-boot legt alle /live/*.squashfs alphabetisch uebereinander).
mksquashfs -all-root braucht kein root; Bau in Sekunden statt ~1 Minute,
kein GB-Arbeitsplatz mehr. installer.conf (WLAN-PSK) im Live-System jetzt
600 statt 644. Lokal-Test-Pruefung ueber die Dateiliste. Behebt nebenbei
einen set -e-Abbruch, wenn weder Diagnose-Hash noch WLAN gesetzt waren.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bare-Metal-Fund (21.09.2026) - das war die eigentliche, finale Ursache der
WLAN-Persistenz-Bugkette von heute: image_deploy_fix_network_interface_name()
war urspruenglich nur fuer den ens18(Referenz-VM)-vs-echte-Hardware-Namen-
Mismatch gedacht, prüfte aber nicht, ob das tatsaechliche Provisionierungs-
interface ueberhaupt Ethernet war. Bei einer WLAN-Provisionierung ersetzte
die Funktion den hartcodierten Ethernet-Namen in /etc/network/interfaces
durch den WLAN-Interface-Namen (z.B. wlp9s0) - mit zwei Folgen: (1)
ifupdowns simples "iface X inet dhcp" kann WPA/WPA2 gar nicht aushandeln,
(2) NetworkManagers ifupdown-Plugin (managed=false) markierte das WLAN-
Interface dadurch dauerhaft als "unmanaged", wodurch das eigentlich korrekt
exportierte/kopierte WLAN-Profil (05_network.sh) nie zum Einsatz kam.
Live auf betroffener Bare-Metal-Hardware verifiziert: Entfernen der
fehlerhaften ifupdown-Zeile + NetworkManager-Neustart aktivierte das
gespeicherte WLAN-Profil sofort, Agent-Checkin lief direkt danach durch.
Jetzt per TUXFLOTTE_NETWORK_TYPE-Pruefung auf Ethernet beschraenkt - WLAN
wird bereits vollstaendig ueber das NetworkManager-Keyfile-Profil abgedeckt,
braucht diesen Fix nicht.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWKevK2QUK5tsGmqfSD6Yy
Bare-Metal-WLAN-Debugging (21.09.2026): das installierte Zielsystem hat nach
ADR-0026 kein Benutzerkonto und kein bekanntes Passwort - Fehlersuche direkt
nach dem ersten Boot war deshalb nur per Offline-Mount der Zielplatte
moeglich. Analog zum --dev-Mechanismus des Boot-Mediums jetzt root/12345 per
SSH erreichbar, aber NUR wenn ANODE_URL auf einen Lokal-Test-Build hindeutet
(http://, nicht https:// wie im Produktivpfad) - der Produktivpfad bleibt
unveraendert ohne jeden bekannten Zugang.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWKevK2QUK5tsGmqfSD6Yy
Der erste Fix (cb2cc3b, "GENERAL.FILENAME") war ebenfalls falsch - empirisch
mit echtem nmcli auf VM 107 geprueft: nmcli lehnt "GENERAL.FILENAME" fuer
die Detailansicht ("connection show <name>") explizit als ungueltiges Feld
ab, genau wie zuvor "connection.filename". FILENAME existiert nur als
Spalte der LISTEN-Ansicht ("nmcli connection show" ohne Namensargument,
alle Verbindungen) - jetzt korrekt darueber gefiltert statt ein
nicht-existentes Detail-Feld abzufragen.
Empirisch verifiziert (VM 107, echtes nmcli):
- Testweise angelegtes WLAN-Profil: FILENAME zeigt korrekt auf
/etc/NetworkManager/system-connections/test-wifi.nmconnection
- Echte aktive Ethernet-Verbindung: FILENAME zeigt auf
/run/NetworkManager/system-connections/... (nicht persistent, harmlos -
bestaetigt gleichzeitig, dass die bisherige Warnung fuer
automatisch erzeugte Ethernet-Profile OHNE explizites Speichern korrekt
und erwartet ist, nur WLAN-Profile muessen tatsaechlich exportiert werden)
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWKevK2QUK5tsGmqfSD6Yy
Bare-Metal-Fund (21.09.2026, Mint+Ubuntu): frisch installierte Geraete
hatten nach dem ersten Reboot keine WLAN-Verbindung mehr - Agent konnte sich
dadurch nie melden (bestaetigt: agent/bootstrap lief, aber niemals ein
agent/checkin danach). Ursache: export_connection_profile() fragte
"connection.filename" ab - das ist kein gueltiges nmcli-Feld (gehoert zur
connection.*-Eigenschaftsgruppe, die den Dateipfad nicht kennt), lieferte
deshalb IMMER eine leere Zeile. Der tatsaechliche Pfad steht im
laufzeitbezogenen GENERAL-Abschnitt (GENERAL.FILENAME). Die "WARNUNG:
NetworkManager-Profil konnte nicht exportiert werden."-Zeile erschien
seitdem (01.09.2026) bei JEDEM Testlauf, wurde aber bisher als harmlos
abgetan statt als eigentliche Ursache erkannt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWKevK2QUK5tsGmqfSD6Yy
Bare-Metal-Fund (21.09.2026, unmittelbar nach dem letzten Fix): die
ttyS0-Umleitung aus Commit 23edd3a war an --local-test-anode-url gebunden -
aber dieses Flag steht sowohl fuer die serielle Proxmox-Testumgebung (VM 107,
kein Bildschirm) als auch fuer Bare-Metal-Tests mit echtem Monitor. Auf
echter Hardware blieb dadurch tty1 von tuxflotte-installer.service
unbeeinflusst (Conflicts zeigte jetzt auf serial-getty@ttyS0 statt
getty@tty1) - der Anwender sah nur noch live-configs Standard-Autologin-
Loop auf dem Bildschirm, waehrend der eigentliche Installer unbeobachtet
auf ttyS0 lief. Neues eigenstaendiges Flag --serial-installer-console
entkoppelt das sauber - NUR fuer die VM-107-Testumgebung gedacht, Bare-Metal-
Tests bleiben wie vorgesehen auf tty1.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWKevK2QUK5tsGmqfSD6Yy
Bare-Metal-Runde 21.09.2026: haendisches ssh.service-Unmasking+root-Passwort-
Setzen live an der Konsole hat die Fehlersuche direkt beschleunigt (SSH statt
serieller/lokaler Konsole mit US-Layout auf physischer Hardware). Jetzt fest
im Dev-Build-Hook: root/12345 zusaetzlich zu tuxflotte/test123, PermitRootLogin
aktiviert. --local-test-anode-url impliziert automatisch --dev, da diese
Builds per Definition reine Testartefakte sind (build_customer_iso.sh bricht
ohnehin ab, falls lokale Test-Spuren im Quell-Image gefunden werden) - kein
Risiko, dass das in eine echte Kunden-ISO durchsickert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWKevK2QUK5tsGmqfSD6Yy
Bare-Metal-Fund (21.09.2026): get_ethernet_devices() filtert Interfaces mit
NM-Status "unavailable" heraus - direkt nach dem Boot kann das noch bis zu
ein paar Sekunden dauern, bis die Link-Verhandlung mit Switch/Router
abgeschlossen ist. Da establish_network_connection() sofort erfolgreich
zurueckkehrt, sobald der Anwender WLAN-Zugangsdaten eingibt, bekam Ethernet
nie eine zweite Chance. try_ethernet() bekommt jetzt ein kurzes,
eigenstaendiges Nachfass-Fenster (4 Versuche a 2s) bevor auf die
interaktive WLAN-Abfrage zurueckgefallen wird.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWKevK2QUK5tsGmqfSD6Yy
Bare-Metal-Test (21.09.2026, Debian) fand zwei echte UX-Bugs:
- run_module() im normalen (nicht-Auto-)Modus rief das Modul nackt auf
("$module" ohne ||-Absicherung) - ein sauberer, bereits klar gemeldeter
fatal()-Fehlschlag im Modul loeste zusaetzlich den generischen ERR-Trap
aus errors.sh aus ("Unerwarteter Fehler in Zeile 199"), obwohl der
eigentliche Grund eine Zeile darueber schon klar stand. Jetzt wird der
Exit-Code abgefangen und sauber weitergereicht, kein zweiter,
verwirrender Fehler mehr.
- connect_wifi() nutzte "nmcli --ask", dessen generischer "Password:"-
Prompt keinen Bezug zur gewaehlten SSID hatte - fuer den Anwender nicht
eindeutig, was genau erwartet wird. Eigener Prompt mit SSID-Bezug und
Doppelpunkt, Passwort direkt per "password" statt "--ask" uebergeben.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWKevK2QUK5tsGmqfSD6Yy
Golden Image bekommt permanent GRUB_TERMINAL=serial (harmlos ohne
seriellen Port, Voraussetzung fuer qm-terminal-Verifikation ohne
Passwort-Reset-Umweg). Die tty1-gebundene Installer-Phase wird nur bei
--local-test-anode-url auf ttyS0 umgebogen, ueber einen Trap immer wieder
auf den Produktivstand zurueckgesetzt, damit ein Produktiv-Build nie
versehentlich die Testvariante ausliefert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWKevK2QUK5tsGmqfSD6Yy
Live gefunden (19.09.2026, direkt im Anschluss an den git-Fix, gleicher
QEMU-Testlauf): "Executable 'flatpak' was not found on the system" -
sechs Rollen (brave/onlyoffice/libreoffice/gdevelop/turbowarp/auto-update)
nutzen das community.general.flatpak-Modul, ohne selbst sicherzustellen,
dass flatpak ueberhaupt installiert ist. Auf Mint/Ubuntu bisher
unauffaellig (dort vermutlich schon im Golden Image vorhanden), auf dem
neuen schlanken Debian-Backend fehlte es komplett - ein fataler
Task-Fehler blockierte wieder den gesamten restlichen ansible-pull-Lauf.
flatpak zur bestehenden jq/curl/python3/ansible/git-Absicherung in
backend_postinstall() ergaenzt (alle drei Backends).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWKevK2QUK5tsGmqfSD6Yy
Live gefunden (19.09.2026, direkt nach dem Netzwerk-Interface-Fix - erster
Testlauf mit tatsaechlich erfolgreichem Agent-Checkin): "Failed to find
required executable 'git' in paths: ...". Netzwerk und Checkin liefen
korrekt, aber OHNE git konnte ansible-pull nie ein einziges Merkmal
anwenden - das ansible-Debian-Paket zieht git nicht zwingend als
Abhaengigkeit, und package_golden_image.sh's Bereinigung hatte es aus dem
Golden Image entfernt.
git zur bestehenden jq/curl/python3/ansible-Nachinstallations-Pruefung in
backend_postinstall() ergaenzt (alle drei Backends).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWKevK2QUK5tsGmqfSD6Yy
Live gefunden (19.09.2026, erster QEMU-E2E-Testlauf, Debian): Der Agent
checkte nach dem Reboot nie ein, weil das Golden Image ein statisches
/etc/network/interfaces (ifupdown) mit dem Interface-Namen der Proxmox-
Referenz-VM ("ens18") mitbringt - auf der QEMU-Testhardware heisst das
Interface "ens3", auf echten Rechnern waere es z.B. "enp2s0"/"eno1". Das
Zielsystem bekam dadurch nie eine IP-Adresse.
image_deploy_fix_network_interface_name() ersetzt den hartcodierten Namen
durch den tatsaechlich erkannten (aus /run/tuxflotte/network/state.env,
von 05_network.sh bereits zuverlaessig ermittelt - Live-Medium und
Zielsystem laufen zwangslaeufig auf derselben Hardware, der Name ist
deterministisch identisch, kein Raten noetig). Bewusst konservativ: nur
wenn genau ein Ethernet-Interface-Name im Golden Image gefunden wird,
sonst wird nichts angefasst. Kein Fatal-Fehler, falls die Datei fehlt
(NetworkManager-basierte Golden Images sind unbetroffen).
Reales Risiko auch fuer Bare-Metal-Rollouts (nicht nur QEMU-Tests) -
betrifft potenziell jede Zielhardware, deren Interface-Name von der
Proxmox-Referenz-VM abweicht.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWKevK2QUK5tsGmqfSD6Yy
Behebt die Ursache des vorherigen Fixes (25f6987) strukturell: statt zwei
Baumkopien manuell in Sync zu halten, kopiert der Build sie jetzt selbst
per rsync (mit Ausschlussliste fuer die bewusst host-seitigen Build-
Skripte und das nicht ausgelieferte Fedora-Backend). Jede kuenftige
Aenderung an scripts/lib/backends landet dadurch automatisch im naechsten
Boot-Medium-Build, die Drift-Klasse aus 25f6987 kann strukturell nicht
mehr auftreten.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWKevK2QUK5tsGmqfSD6Yy
Live in QEMU gefunden (19.09.2026, erster Testlauf der neuen Lokal-Test-ISO
mit custom-Partitionierung): "image_deploy_partition_custom: command not
found" - die Custom-Partitionierungsfunktionen (Commit 020aa66) wurden nur
in scripts/lib/image_deploy.sh ergaenzt, die zweite, tatsaechlich ins
Boot-Medium gepackte Kopie unter boot-medium/config/includes.chroot/...
blieb auf dem Phase-1/2-Stand stehen. Genau die Sync-Falle, die im Roadmap-
Dokument als Risiko benannt wurde.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWKevK2QUK5tsGmqfSD6Yy
image_deploy_partition_custom()/_format_custom()/_mount_custom() sowie eine
um extra_partitions erweiterte image_deploy_write_fstab() ergaenzen das
bisherige starre ESP+Root-Layout um eine variable Anzahl zusaetzlicher
Partitionen (Mountpoint/Prozentanteil-der-Gesamtplatte/Dateisystem), ohne
das bestehende scheme:"single" in irgendeiner Weise zu veraendern (eigene
Funktionen statt Erweiterung der bestehenden).
Alle drei Backends (mint/debian/ubuntu-image) verzweigen in backend_launch()
auf das Schema aus der Bereitstellungsvorlage und validieren extra_partitions
zusaetzlich defensiv in backend_validate() (Prozentsumme, doppelte
Mountpoints, Dateisystem-Whitelist ext4/btrfs - zfs/Fedora bewusst nicht).
Gegenstueck (API+GUI+DB) ist in provisioning-server/kundenplattform bereits
committet. Teil von platform-docs/roadmap/e2e-testrunde-lokale-
adressierung.md Phase 3.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWKevK2QUK5tsGmqfSD6Yy
--local-test-anode-url an build_boot_medium.sh macht anode per Klartext-
HTTP direkt im LAN erreichbar statt ueber Pangolin/Internet (anode hat
kein LAN-gueltiges TLS-Zertifikat, Split-Horizon-DNS auf https://
anode.tuxflotte.de wuerde daher an Zertifikatsfehlern scheitern).
--embed-golden-image backt das Golden-Image-Archiv direkt auf die ISO
(includes.binary, ausserhalb des squashfs), damit auch das beim
Deployment kein Netzwerktransfer mehr ist. Beide Flags sind rein additiv
und beeinflussen den Produktivpfad (kein Flag) nicht.
Betrifft beide Skriptbaum-Kopien (scripts/backends und boot-medium/
config/includes.chroot/...), da es dafuer kein Sync-Tooling gibt.
Siehe platform-docs/roadmap/e2e-testrunde-lokale-adressierung.md fuer
den vollstaendigen Plan inkl. offener Verifikationspunkte (toram-
Verhalten bei includes.binary, exakter Live-Medium-Mountpunkt).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DWKevK2QUK5tsGmqfSD6Yy
- config/chroot: LB_PROPOSED_UPDATES="false" (explicit default alongside
the existing backports/updates flags)
- new hooks/normal/5050-dracut.hook.chroot: adapts the live medium for
dracut-live instead of initramfs-tools (removes initramfs-tools/live-boot
packages, fixes hardcoded /run/live/medium path for Calamares)
Both files were live-build-generated config left uncommitted in the
working tree, found while checking for unfixed work before shutting
down idle sessions.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BmjSLwQhrnVK3FX2VX9Tbw
Der generische apt_chroot_with_retry() aus dem vorherigen Commit war fuer
apt-get purge falsch: ein echter Testlauf zeigte, dass der erste Versuch
beim Transaktionsende-Absturz laut dpkg.log fast immer schon fast alle
Pakete entfernt hat - ein zweiter Versuch mit der IDENTISCHEN,
vollstaendigen TRIM_PACKAGES-Liste scheiterte dann an 'Paket X kann nicht
gefunden werden' fuer jedes bereits entfernte Paket (apt-get bricht bei
einem einzigen unbekannten Namen die gesamte Kommandozeile ab). Neue
apt_purge_with_retry() prueft vor jedem Versuch per dpkg-query neu, was
von TRIM_PACKAGES wirklich noch installiert ist, und purgt nur das.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011HDFX6o1ZMxKVFLYiMjERR
apt-get purge/autoremove scheitert im chroot reproduzierbar (4x live
beobachtet, mit jeweils voellig unterschiedlichen Paketen/Triggern) am
Ende der jeweiligen dpkg-Transaktion mit einem knappen, unuebersetzten
'E: Sub-process returned an error code' (exit 100) - kein paketspezifisches
Problem, sondern etwas Generisches am Transaktionsende. Root Cause trotz
intensiver Diagnose (3 volle Testlaeufe gegen golden-linux-mint/103 +
interaktive chroot-Session) nicht gefunden - ausgeschlossen: OOM-Kill,
AppArmor-DENIED, kaputte dpkg-Datenbank, devpts-Rechte-Varianten.
Laut dpkg.log ist die eigentliche Paketarbeit beim Absturz jedes Mal schon
vollstaendig fertig, ein 'dpkg --configure -a' danach ist immer sofort
sauber. Pragmatischer Workaround statt weiterer Root-Cause-Suche:
apt_chroot_with_retry() versucht den jeweiligen chroot-Aufruf bis zu
dreimal - der zweite Versuch sieht dann 'nichts mehr zu tun' und liefert
exit 0.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011HDFX6o1ZMxKVFLYiMjERR
Zwei Bugs behoben, die den Mount-Incident vom 11.09.2026 verursacht haben
(rm -rf gegen einen noch teilweise gemounteten Pfad hat echte
Geraetedateien auf dem Build-Host geloescht, u.a. /dev/null):
1. mount --rbind /dev -> normaler --bind + eigene, frische devpts-Instanz
nur fuer dev/pts. --rbind hat die STAGING_DIR-Devpts-Instanz 1:1 mit der
des eigenen Terminals geteilt - beim Aufraeumen war der Sub-Mount
dadurch 'busy', was zu einem manuellen Lazy-Unmount (umount -l)
verleitet hat.
2. unmount_chroot_binds() nutzt jetzt nirgends mehr umount -l/-R (Lazy-
/rekursiver Unmount) - stattdessen normaler umount mit begrenztem Retry
je Mount. cleanup() prueft zusaetzlich UNABHAENGIG per mountpoint -q
nach, bevor rm -rf auf STAGING_DIR laeuft, und verweigert das Loeschen,
falls doch noch etwas eingehaengt ist, statt stillschweigend
weiterzumachen.
Gleichzeitig wird damit das inhaltlich bereits fertige, bisher nur
uncommitted auf controller liegende Trimming-Feature (echter Testlauf
11.09.2026, 37 Pakete/910MB) mit committed - siehe Kommentar im Skript fuer
die vollstaendige Paketauswahl-Analyse.
Noch offen: naechster echter Testlauf des reparierten Mount-/Unmount-
Zyklus gegen golden-linux-mint/103 (bisher nur syntaktisch/statisch
geprueft, nicht real gegen chroot+apt getestet).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011HDFX6o1ZMxKVFLYiMjERR
Live gefunden (09.09.2026, beim Vorbereiten eines Kolibri/Veyon-Tests
auf golden-linux-mint): ansible ist auf KEINEM der drei Golden-Images
(Mint/Debian/Ubuntu) tatsaechlich installiert - nur zufaellige
bash-completion-Stub-Dateien vom bash-completion-Paket vorhanden
(taeuschen bei einer oberflaechlichen Pruefung echte Installation vor),
keine echten Binaries. Der Provisioning-Agent ruft aber ansible-pull
bei JEDEM Checkin auf.
Bisher durch den fruehen 'nichts zu tun'-Ausstieg in agent.py
maskiert (kein ansible-pull-Aufruf ohne zugewiesene
Blueprints/Auftraege) - seit der heutigen Webapp-Aenderung
(webapp-shortcuts-Rolle immer getaggt, siehe admin/provisioning-agent)
haette das ab sofort auf JEDEM Geraet fehlgeschlagen.
Fix in backend_postinstall() aller drei Backends (mint-image/
debian-image/ubuntu-image): ansible-pull-Verfuegbarkeit zusaetzlich zu
jq/curl/python3 sichergestellt, Paket 'ansible' (nicht nur
'ansible-core') gewaehlt, weil es die community.general-Collection
gleich mitbringt (von brave/onlyoffice/libreoffice/gdevelop/turbowarp
gebraucht - sonst waere ein zusaetzlicher ansible-galaxy-Schritt
noetig). Boot-Medium-Payload-Kopie synchronisiert.
Noch zu tun: Boot-Medium neu bauen+deployen (wie beim GRUB-Timeout-Fix
heute frueher), dann echten Neu-Deploy-Test fahren, um den Fix
tatsaechlich zu beweisen statt nur den Code zu lesen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLk93dhDMrkPXefVdknMV9
Bei Phase 1 (Debian-E2E-Test, 08.09.2026) gefunden: live-builds
Standardvorlagen setzen weder fuer GRUB (UEFI-Pfad) noch fuer
Isolinux (BIOS-Pfad) einen Timeout - GRUB-Default ist -1 (wartet
unendlich auf Tastendruck), Isolinux' 'timeout 0' bedeutet ebenfalls
'Timeout deaktiviert', nicht 'kein Timeout'. Fuer echte
unbeaufsichtigte 'Stick rein, warten'-Installationen ohne
anwesenden Techniker waere das ein Show-Stopper.
Fix per live-build-Standard-Override-Mechanismus
(config/bootloaders/<name>/, gleiches Muster wie schon beim
Splash-Bild): beide Bootloader auf 10s gesetzt, danach automatischer
Start des Standard-Eintrags (default=0 bzw. 'menu default' sind
bereits gesetzt).
Verifiziert: Timeout-Werte im tatsaechlich gebauten ISO per
xorriso-Extraktion bestaetigt (set timeout=10 / timeout 100). QEMU-
Boot mit unveraendertem Menue lief 100+s mit durchgehend >100% CPU
(kein Idle-Warten am Menue) - Bildschirm-Screendump zur visuellen
Bestaetigung blieb in dieser Sandbox-Umgebung technisch unzuverlaessig
(bekanntes Problem, siehe Ubuntu-E2E-Debugging vom selben Tag),
statische Config-Verifikation + CPU-Aktivitaets-Nachweis reichen als
Ersatz.
Noch offen: neues Boot-Medium muss noch auf anode deployed werden
(gebaute ISO liegt lokal, altes Basis-Image auf anode ist noch ohne
diesen Fix) - reines 'git pull' reicht dafuer nicht, siehe bestehende
Lehre in project_independent_boot_medium.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VLk93dhDMrkPXefVdknMV9
Desktop kommt bei Debian per Ansible-Blueprint nach dem ersten Boot -
Debian erlaubt das grosszuegiger als Mint/Ubuntu. Reiner
Kommentar-Update, keine Verhaltensaenderung (Boot-Medium-ISO muss dafuer
nicht neu gebaut werden).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LpNs8yZeQkHgMWx6WNT1QH
Strukturell identisch zu backends/mint-image/backend.sh (image_deploy.sh
ist bereits komplett distributionsunabhaengig, postinstall.sh ist per
Symlink geteilt - beides beim Anlegen bestaetigt, keine Mint-spezifische
Annahme gefunden). Referenz-VM ist "golden-debian" (VM 104 auf
tuxflotte-pve).
WICHTIG, noch offen: golden-debian ist aktuell ein schlankes, headless
Debian-13-Basissystem OHNE Desktop-Umgebung - anders als golden-linux-mint
(volle Cinnamon-Desktop). Ob das Absicht ist (Desktop kommt per
Ansible-Blueprint nach dem ersten Boot, urspruengliche ADR-0024-Idee) oder
noch unvollstaendig, ist NICHT entschieden - GOLDEN_IMAGE_URL zeigt
deshalb bewusst auf ein als "-base" benanntes Archiv statt den Stand als
fertiges Desktop-Image zu behaupten.
Ausserdem gefunden: boot-medium/config/includes.chroot/opt/tuxflotte/ ist
eine manuell gepflegte Kopie von backends/+scripts/+config/, kein
automatischer Sync aus dem Top-Level-Repo - die vorherige
target_disk_rank-Aenderung an backends/mint-image/backend.sh fehlte hier
deshalb zunaechst und wird mit diesem Commit nachgezogen.
Siehe platform-docs/roadmap/multi-distro-merkmal-workspace-creator.md,
Phase 1 (zweite Referenz-Distribution).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LpNs8yZeQkHgMWx6WNT1QH
adminandClaude Opus 5.5