ADR-0006: Der zitierte Befehl (epiphany --application-mode --profile=...)
wurde nachweislich nie ausgeliefert - ADR-0004s eigene, einen Tag später
datierte Folgeuntersuchung (Fund 2) stellte fest, dass --application-mode
für skriptgesteuerte Einrichtung unbrauchbar ist. Der tatsächlich seit dem
allerersten Commit ausgelieferte Befehl (start-kiosk.sh) nutzt nur
--profile, nie --application-mode. Diese Diskrepanz wurde beim ersten
Lesen von ADR-0004/0006 in einer früheren Session bereits bemerkt, aber
nie zu Ende verfolgt - jetzt korrigiert, an beiden Stellen (Entscheidung +
Konsequenzen), inkl. Verifikation gegen den echten Code.
ADR-0004: 'grouped-window-list@cinnamon.org' war von Anfang an falsch
dokumentiert - der Code verwendet seit demselben Ausgangscommit bewusst
das einfache 'window-list@cinnamon.org' (Begründung stand nur als
Code-Kommentar: die gruppierte Variante brachte ungewollte Pinned-Apps-
Starter mit). Kein späterer Kurswechsel, sondern ein Autorenfehler im
ADR selbst.
ADR-0018: kleinere Wortwahlkorrektur ('gestrichelte' -> 'durchgezogene'
Konturlinien - das SVG hat kein stroke-dasharray, die Linien sind nicht
gestrichelt).
Alle 19 ADRs vollständig neu gelesen (nicht nur grep-Stichproben),
Cross-Referenzen und Struktur erneut geprüft - sonst keine weiteren
Funde.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Dokumentiert die Session-Arbeit vom 20.08.2026: Kontakt-/Stammdaten je
Organisation, neue organisationsgebundene Rolle ist_organisationsadmin
(strikt getrennt von is_superuser - Kernentscheidung dieses ADRs), den
live gefundenen und gefixten bytes-vs-str-psycopg-Bug bei der
Kontolöschung.
09-data-model-v1.md um die fünf neuen Organization-Kontaktfelder
ergänzt. benutzer/ist_organisationsadmin bewusst nicht dort aufgenommen
- lebt in kundenplattforms eigener Datenbank, war schon vorher nicht
Teil dieses Dokuments (ADR-0011).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Dokumentiert die Session-Arbeit vom 19.08.2026: pics/tuxflotte-
beschriftet-schatten.svg (bereits als 'das Logo' in
13-live-provisioning-boot.md referenziert) als static/tuxflotte-logo.svg
im kundenplattform-Header eingebunden, Navigationstext '/geraete' auf
'Flotte' umbenannt (Kundenportal + Admin), Scope bewusst auf Nav-Text
begrenzt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Dokumentiert die Session-Arbeit vom 19.08.2026: Checkbox-Diff-Verwaltung
der Gruppen-Mitgliedschaft direkt in /geraete, als Gegenstück zur
bestehenden Verwaltung von der Gruppen-Seite aus. Keine neue anode-API,
wiederverwendet die bereits generische Gruppen-API aus ADR-0012.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ADR-0016 übernahm ADR-0009s verkürzte Dateinamen (boot-grub.cfg/
isolinux-live.cfg) ungeprüft - die tatsächlichen Dateien heißen laut
Git-Historie seit ihrer Anlage mit mint-Präfix (mint-boot-grub.cfg/
mint-isolinux-live.cfg). Jetzt korrekt benannt, mit Hinweis auf die
Diskrepanz zu ADR-0009s Kurzform.
13-live-provisioning-boot.md: Vorwärtsverweis auf ADR-0016 an der
Stelle ergänzt, die die ursprüngliche 01.08.2026-Korrektur beschreibt -
für Leser, die von dort aus nachvollziehen wollen, dass die Korrektur
zunächst nicht überall ankam.
Restliche 15 ADRs erneut gegen die letzte Fassung geprüft: alle
vorherigen Korrekturen (0003, 0009, 0011, 0012, 0013, 0015) live und
korrekt formatiert bestätigt, keine neuen Befunde.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Dokumentiert den tuxflotte-installer-Commit 517c2de: die 01.08.2026-
Sicherheitskorrektur (Standard = lokal booten statt Auto-Install, siehe
ADR-0009) war nicht vollständig umgesetzt - Fedoras GRUB-Configs
(EFI-BOOT-grub.cfg, boot-grub2-grub.cfg) defaulteten weiterhin echt auf
den unbeaufsichtigten Install-Eintrag, Mints nicht-EFI-Zweig hatte gar
keinen lokalen-Boot-Eintrag (vermutlich unerreichbar, trotzdem
abgesichert). Gefunden bei der Live-Gegenlese aller ADRs gegen anode.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Live gegen anode geprüft: GET /installers/fedora-workstation/ks.cfg ist
weiterhin erreichbar (200), Datei zuletzt am 04.08.2026 verändert -
lange nach der hier ursprünglich geplanten Entfernung. Grund: ADR-0009
hält fest, dass das Fedora-Backend im Code bleibt (nicht rückgebaut),
nur der Fokus verschob sich auf Mint. Endpunkt bleibt entsprechend
bestehen, für eine mögliche künftige Fedora-Wiederaufnahme.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Wichtigster Fund: 13-live-provisioning-boot.md widersprach sich selbst
zum GRUB-Standardeintrag - ein noch nicht korrigierter Abschnitt
('Auto-Eintrag ist Index 0 und damit Standardauswahl') stand neben der
bereits vorhandenen Korrektur weiter oben im selben Dokument ('Standard
ist von lokaler Festplatte booten', Erkenntnis vom 01.08.2026). Ein
Reader des älteren Abschnitts hätte das sicherheitsrelevante Verhalten
bei destruktiven Installationen falsch verstanden. Jetzt konsistent,
mit Verweis auf die Korrektur. ADR-0003 (Ursprungsentscheidung, dort
unkorrigiert) bekam denselben Nachtrag.
Kleinere Korrekturen: zwei Anführungszeichen-Inkonsistenzen (ADR-0009,
ADR-0011) - gerade Anführungszeichen für eigene Zusammenfassungen des
Autors statt der sonst durchgängigen „..."-Form, während echte wörtliche
Zitate (Terminal-Fehlermeldungen, Anaconda-Doku) unangetastet bleiben,
weil die Originalschreibweise dort bewusst erhalten werden soll.
Alle ADR-Querverweise (0001-0015) auf Gültigkeit geprüft, keine toten
Verweise gefunden.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Anführungszeichen vereinheitlicht auf „..." (Dokument nutzte
durchgängig gerade Anführungszeichen, alle Nachbar-ADRs die
deutsche Form) - inkl. Wechsel zu Backticks für die zitierten
Code-Literale (quelle-Werte), analog zu ADR-0012s Formulierung
derselben Werte.
- Konsequenzen-Absatz präzisiert: 'Der Admin-Bereich hat zwei
Zugriffswege' war irreführend, da einer der beiden Wege explizit
NICHT der Admin-Bereich ist, sondern das Kundenportal. Jetzt
'OEs sind plattformweit über zwei Wege verwaltbar'.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Dokumentiert die direkte Folgeanfrage zu ADR-0012: OE-Spalte + Verschieben
in der Admin-Geräteliste, anklickbare Herkunfts-Links (quelle_id in
resolve_katalog_overrides()), neue bewusst schlanke Admin-OE-Ansicht
(nur Merkmale-Editor, kein CRUD - OE-Struktur bleibt Kunden-Self-Service),
plus den dabei gefundenen und gefixten Routing-Bug im geteilten
Auftragskatalog-Template.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Anführungszeichen-Inkonsistenz behoben (gerade statt „..." an einer Stelle)
- Entscheidungs-Absatz zu Gruppen verweist jetzt vorwärts auf den
Self-Service-Nachtrag, statt für sich allein veraltet zu wirken
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Dokumentiert nachträglich das Phase-4/5-Ergebnis des Self-Service-ISO-
Plans (04.-07.08.2026, laut Memory 'Phasen 1-5 abgeschlossen', bislang
komplett undokumentiert): Hintergrund-Thread-Orchestrierung in
provisioning-server, iso_builds-Statustabelle, Alt-Build-Aufräumung
wegen anodes begrenztem Plattenplatz, PSK-Verschlüsselung in
Kundenplattforms eigener DB statt provisioning-server, getrennte
Aufladen-/Neubau-Aktionen, gestreamter Download-Proxy.
13-live-provisioning-boot.md um den Mint/Casper-Payload-Mechanismus
ergänzt (Pendant zum dort bereits beschriebenen Fedora/Dracut-Weg,
inkl. des gefundenen Casper-ORDER-Bugs: neue Hook-Skriptnamen werden
nie ausgeführt, nur das Überschreiben eines bereits referenzierten
Pfads funktioniert).
09-data-model-v1.md um iso_builds als neues Kernobjekt ergänzt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Dokumentiert nachträglich eine bereits deployte, live-verifizierte
Session-Arbeit: De-/Reprovisionieren (serverseitiger Credential-Entzug,
Agent-Self-Heal mit deprovisioned_at-Gate), Löschen als Soft
Delete/Archivierung, Hardware-/Log-Leseendpunkte. Bislang komplett
undokumentiert in platform-docs gewesen.
09-data-model-v1.md um devices.deprovisioned_at/archived_at ergänzt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Die im ADR offen gelassene Möglichkeit ('sollte künftig Self-Service für
Gruppen nötig werden...') wurde noch am selben Tag umgesetzt - Notiz
ergänzt, analog zum Nachträglich-präzisiert-Muster in ADR-0010.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Dokumentiert die in dieser Session umgesetzte Konfigurationsvererbung:
OEs als Baum mit exklusiver Geräte-Mitgliedschaft und geschützter
Standard-OE 'Neue Geräte', Gruppen flach mit Mehrfachmitgliedschaft,
Konfliktregel 'mehr gewinnt'. Bewusst nach der Umsetzung geschrieben statt
davor (abweichend vom sonstigen ADR-Vorher-Muster in diesem Repo, auf
Wunsch des Kunden für diese Iteration).
09-data-model-v1.md erweitert um Organisationseinheit, Gruppe, OE-/
Gruppen-Merkmal-Override als Kernobjekte, inkl. relationalem Schema und
Löschregeln.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Dokumentiert die Entscheidung, die Auftragskatalog-Web-UI nicht in
provisioning-server einzubauen, sondern als eigenständigen Dienst mit
eigener DB, eigenem Service-Token und Backend-for-Frontend-Muster zu
bauen. Sicherheits-/Mehrmandanten-/Verfügbarkeitsgründe siehe Kontext.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The catalog isn't a second pool independent of workspaces - a
workspace is just a preset selection from catalog-eligible Merkmale.
Clarifies that the present/absent default for a catalog-eligible
Merkmal with no explicit device_merkmale row must follow workspace
membership, not hardcode to absent; an explicit row always overrides
that default in either direction. The first implementation got this
wrong (hardcoded absent default), which would have silently removed
any already workspace-composed Merkmal the moment it got flagged
catalog-eligible. Fixed in provisioning-server/app.py in the same
pass.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ADR-0010 decides that an Auftrag is technically a Merkmal, not a new
parallel entity: it reuses the existing Merkmal/Blueprint/ansible-role
mechanism from ADR-0002, but adds a device-level, independently
toggleable assignment path (device_merkmale) alongside the existing
workspace-level one. Deselecting an Auftrag needs to actually revert
it, so checkin will need to declare a full present/absent state per
catalog entry rather than just an additive list; that role-level and
API-level work is deferred, this only settles the data model.
Also adds a single generic, append-only event log
(device_merkmal_events) for both selection changes and agent-reported
execution results, instead of several purpose-specific tables, so
future event types don't require schema changes. Extends
09-data-model-v1.md and the glossary accordingly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
d-i preseed/early_command produced no trace anywhere (no log, no
syslog/installer-debug mention) -- Ubiquity runs its install steps via
its own Python plugin system (plugininstall.py), not the classic
debian-installer shell components that early_command/late_command are
bound to. Decided not to build a custom Ubiquity plugin or a
pre-ubiquity live-filesystem hook for this; organizational,
install-time-fixed parameters (partitioning, filesystem, branding) go
back to being baked into the personalized preseed at ISO-generation
time in the portal instead.
Also fixes a real safety bug in the test boot menus: the destructive
auto-install entry was the default (would run automatically on
timeout). Corrected to the opposite -- default is "boot from local
disk" (safe, nothing happens), the destructive install requires
actively selecting it from the menu. Verified in both the UEFI
grub.cfg and the BIOS isolinux config.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Real hardware confirms the whole chain: personalized ISO installs
unattended, WLAN works during install (unlike every tested Fedora
variant), live contact with anode during install works, and the WLAN
profile survives the reboot and reconnects automatically in the
installed system. Remaining open items are deliberate follow-up work
(Provisioning Agent implementation, install-time vs first-boot data
flow as a design choice, an optional slim Debian-netinstall backend
later) rather than open technical questions.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A long, multi-line, heavily-quoted ubiquity/success_command preseed
value produced no log output at all -- not even its first echo --
despite the same bash script running cleanly standalone (bash -n and
actual execution both clean). Root cause traced to debconf's preseed
line-continuation handling, not the script itself. Fix: base64-encode
the whole script and reduce success_command to a single short line
with no special characters (`in-target bash -c 'echo <b64> | base64
-d | bash'`). With that, WLAN connects via nmcli during install, curl
reaches anode, and the .nmconnection file lands correctly on the
target disk (verified pre-reboot via ubiquity/reboot boolean false).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
First real success in this whole investigation: Ubiquity's automatic
mode still boots via boot=casper, the same live environment as the
normal interactive session, so it doesn't share Fedora's
installer-vs-live driver split. No hidden second FAT/ESP grub.cfg copy
either, unlike Fedora. Real test on the same notebook (Intel AX210)
connected WLAN via nmcli in ubiquity/success_command and got a genuine
response from anode's /health endpoint during installation.
One follow-up finding: the WLAN connection didn't survive the reboot
into the installed system, likely because nmcli talked to the live
session's own NetworkManager instance (shared /run under chroot)
rather than writing a profile that persists on the target disk --
needs an explicit file write into the chrooted
/etc/NetworkManager/system-connections/ instead.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
After three independent, structurally different dead ends on the same
test hardware (missing anaconda dracut module, missing wpa_supplicant,
missing iwlwifi, an unexplained DVD hang that persisted even with
Ethernet plugged in), the user decided to move on from Fedora rather
than keep debugging. Not a verdict against Fedora as a backend in
general -- specific to this test hardware and these official media.
The architecture worked out in this ADR (personalized ISO, no network
directives during install, Provisioning Agent handles WLAN/handshake
on first boot) carries over unchanged to Mint/Ubuntu; only the
installer stack changes (Subiquity/autoinstall or Ubiquity/preseed
instead of Anaconda/kickstart).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Tested with no network line in the kickstart at all, then again with an
Ethernet cable plugged in -- still hangs identically, which rules out
the already-found missing iwlwifi driver as the sole explanation this
time. Investigation stopped here by user decision, not for lack of a
next diagnostic step (an rd.break=initqueue session was staged and
ready). Fedora has now failed in three independent, structurally
different ways (live+kexec, netinstall, DVD) on this test hardware --
Ubuntu/Mint with the same personalized-ISO test setup is the obvious
next candidate, not pursued in this session.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Real hardware test (Intel AX210) shows the tested Fedora Everything
netinstall initrd ships no iwlwifi driver at all -- three kickstart
variants all hung identically at dracut-initqueue regardless of syntax,
confirming the cause was never the kickstart itself. Documents the
kexec test series (ADR-0009), the DB-driven kickstart success on
netinstall, and the resulting architecture: a personalized installer
ISO per workspace/backend/media-variant with the kickstart baked in,
no live-session/kexec transition, WLAN and blueprint application moved
to the Provisioning Agent's first boot on the fully installed target
system instead of the constrained installer environment.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Instead of customers flashing a different physical stick per workspace/
distro combination, one slim generic bootstrap medium (no live desktop
needed) stages the server-built personalized distro ISO into a small
partition on the target disk and boots it directly via GRUB loopback/
iso-scan (the same pattern Ventoy uses in production). The staging
partition is deliberately ephemeral - the real install's own
partitioning step wipes it along with the rest of the disk, keeping
Tuxflotte's own disk-touching code to a throwaway staging area only,
clearly inside the boundary already drawn against reimplementing the
actual install logic.
Also records the assessment that this is a genuine architectural
simplification, not just an Anaconda-specific workaround: it removes
the entire class of live-desktop/EROFS friction from recent days and
fits the project's own "orchestrate native installers" philosophy
better than the live-kiosk approach did.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Replaces the vague "separate netinstall media" fallback with a
concrete design: move the workspace/backend decision to the
self-service portal, before boot, and bake the finished kickstart/
autoinstall/preseed config into a personalized, distro-specific,
much smaller installer ISO at build time. Sidesteps the live-session
vs. native-installer-automation tension entirely, and the open
early-boot networking question from the two-stage-reboot plan, since
no runtime config fetch is needed. Consistent with backend_postinstall()
already being scoped to the installed system's first boot, not the
install phase.
Names the real cost honestly: demotes the interactive kiosk mode to
an optional secondary path, and requires real per-distro ISO-build
infrastructure server-side.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Further research showed the live-session-invocation limitation isn't
Fedora-specific: Ubuntu/Subiquity autoinstall and Ubiquity/preseed are
also strictly kernel-boot-parameter-triggered, and Calamares has no
unattended mode at all regardless of timing. Rather than switching
distros, the live session can instead set the right boot parameter
for a second boot and reboot into the installer's normal automated
mode - potentially avoiding a Fedora/Anaconda departure entirely.
Records the agreed test order: confirm Mint's actual installer,
test Fedora+kickstart-via-reboot first (lowest cost), then Mint/Ubuntu
with the same pattern, with the original ADR-0009 ultima ratio last.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Real test on Fedora 44 / Anaconda 44.30-2.fc44 (bypassing the liveinst
wrapper, which explicitly rejects kickstart on live media) confirmed
the documented restriction firsthand rather than just by reading
about it: --liveinst --kickstart in text mode silently drops rootpw/
user directives (require full manual re-entry, no error), and cmdline
mode exits cleanly with CmdlineError naming Installation Destination,
Root password, and User creation as unfinished despite being fully
specified in the kickstart.
Reimplementing install logic to bypass Anaconda entirely was
considered and explicitly rejected. Next step is re-evaluating
Ubuntu/Debian-based installer media instead of Anaconda's live mode;
switching Fedora to the officially supported inst.ks=/liveimg pattern
(separate netinstall media) remains a last resort.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The previous Auto-Modus-Gate rule unconditionally forced new devices
into the interactive flow because no better mechanism was known yet.
Enrollment Sessions (11-device-enrollment.md) already solve planned
bulk rollouts, but not a single, spontaneously booted new device.
New devices in auto mode now go on hold after the identification
handshake and wait for a customer to confirm registration and assign
a workspace via the future management UI, reusing the same
fail-closed poll mechanism already planned for the interactive flow's
kiosk communication (ADR-0007). Devices covered by an active
Enrollment Session are unaffected and remain fully unattended.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Kiosk UI: Chromium was evaluated as an Epiphany alternative (ADR-0005)
after ADR-0004's application-mode approach turned out unusable
end-to-end, then abandoned after four distinct real-boot failures in a
row (ADR-0006) in favor of a hardened plain --profile Epiphany launch.
ADR-0004 amended with the actual fix history (profile directory
creation, application-mode's undocumented web-app requirement,
--private-instance/--profile conflict on the target's Epiphany 50.1
vs. the 43.1 used for local testing). ADR-0007 resolves ADR-0004's
open question: the kiosk web UI and installer.sh never talk directly,
only via the provisioning server.
WLAN autoprovisioning: customer profile gets an "Autoprovisionierung"
flag plus WLAN credentials, driving self-service generation of a
personalized ISO with the credentials baked in as a NetworkManager
profile — works from device one, no persistent on-stick state needed.
Personalizing the build this way also motivated giving the ISO its
own volume label (TUXFLOTTE) instead of the source Fedora label.
Also folds in the EROFS root-cause writeup and the Ubuntu-live-medium
alternative noted for a future ISO rework, and brings
roadmap/installer-roadmap.md's checkboxes in line with actual status.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Moves from a Fedora DVD/netinst base (GRUB boots straight into Anaconda
via a static inst.ks= URL, bypassing installer.sh entirely) to a real
live medium. installer.sh runs as an application inside the live
session; backend_launch() starts the native installer explicitly at
the end instead of a boot-time kickstart parameter.
The boot menu offers two entries: a default with a countdown that
leads to an unattended flow, and a manual entry for the branded
interactive flow. The unattended flow is gated on
device.registration_status == "existing" - unknown devices always
fail closed into the interactive enrollment path. Device registration
now documents that this is a condition of registering a device.
Also notes the tension with the installer roadmap's long-term
minimal-medium vision: distribution packages still aren't bundled and
are pulled per install, but the live environment itself makes the
medium larger, accepted for the UX it enables.
Details: architecture/13-live-provisioning-boot.md.
Introduces the Merkmal-Backend-Blueprint realization model: a Merkmal
describes one distribution-independent workspace feature, a Blueprint
realizes exactly one Merkmal for exactly one backend (usually an
Ansible role applied post-first-boot via ansible-pull), and a
Bereitstellungsvorlage bundles workspace + backend + org-specific
installation directives (partitioning, encryption, secure boot).
Replaces the old flat profile model (profiles/profile.json/
distribution+version) throughout the provisioning API, data model,
interactive provisioning flow, and device enrollment docs with
templates/Bereitstellungsvorlage terminology. Moves 02-workspace-model.md
and 04-backend-model.md into architecture/, archives the superseded
flat organization-model.md.
