Bisher genügte die device_id für ein neues Agent-Secret. Passt ein
mitgeschickter Fingerprint nicht, wird abgelehnt; fehlt er, wird bis
TUXFLOTTE_AGENT_BOOTSTRAP_FINGERPRINT_PFLICHT=1 nur protokolliert.
platform-docs roadmap/agent-zugang-haertung.md
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Migration 0079: Setup Mode und Drittanbieter-CA im Hardware-Snapshot,
firmware_* an devices aus dem Agent-Check-in. Gerätelisten und
Hardware-Endpunkt liefern firmware + secure_boot_stufe.
platform-docs roadmap/secure-boot-verschluesselung.md Schritt 3
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Erstkontakt-Probelauf 25.10.2026: neue Organisationen hatten kein Präfix,
Geräte hießen tuxflotte-0001. Jetzt beim Anlegen hostname_praefix aus dem
Namen (Kleinbuchstaben, Umlaute ausgeschrieben, a-z0-9-, höchstens 20
Zeichen) und hostname_stellen 2 (Nutzerwunsch, vorerst). Bestehende
Organisationen unverändert. Neuinstallation erkennt jetzt auch Namen mit
mehr Ziffern als "stellen" (ab dem 100. Gerät), statt umzubenennen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bisher ließen sich Organisationen gar nicht entfernen. Jetzt archivieren:
nur ohne aktive Geräte; Medien (enrollment_sessions) widerrufen,
Aktivierungscodes deaktiviert, laufende Einladungen zur Personalisierung
zurückgezogen; die Organisation fehlt danach in der Liste und im
Admin-Dashboard. Daten bleiben erhalten (Migration 0076, archived_at).
Endgültiges Löschen später als eigener Punkt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Befund Erstkontakt 25.10.2026: Eine neue Einladung ohne "Bestehenden
Zugang behalten" sperrte das Konto sofort (auch am Bildschirmschoner einer
laufenden Sitzung); Zurückziehen hob die Sperre nicht auf. Jetzt merkt sich
das Konto die sperrende Einladung (Migration 0075, gesperrt_durch). Wird
sie zurückgezogen, ersetzt, läuft ab oder scheitert am Gerät, ist das
Konto wieder frei; eine ersetzende Einladung übernimmt die Sperre. Von
Hand gesperrte Konten bleiben gesperrt. Die Liste meldet
gesperrt_durch_einladung.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Seit 5210186 (Ausrollstufe stabil heißt testing) prüften Spiegel-Bau und
stand.json-Laden gegen AUSROLLSTUFEN. Der Spiegel heißt aber weiter
"stabil", sein Archiv wurde nicht mehr gebaut und Geräte von
Testing-Organisationen fielen auf den Git-Weg (ansible-content-stabil über
Gitea) zurück. Gefunden am frisch installierten Gerät im
Erstkontakt-Probelauf (ansible_weg=git).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Beim Erstkontakt-Probelauf blockierte das in Liebherr archivierte
Liebherr-83 die Neuinstallation derselben Hardware für eine neue
Organisation. Der alte Datensatz bleibt als Verlauf, sein Fingerabdruck
bekommt das Suffix :archiv:<id>. Aktive Geräte anderer Organisationen
bleiben weiterhin gesperrt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Migration 0074: organizations.org_wlan (Optionen der Rolle, Passwort
verschlüsselt). GET/PUT /api/v1/organizations/{id}/org-wlan; im
Auftragskatalog gilt es für org-wlan, solange OE/Gruppe nichts festlegt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Je eingerichtetem Konto mit der Adresse ein Link, auch auf mehreren
Geräten; Begrenzung je Konto mit dem Kiosk-Weg geteilt, Konten an der
Grenze still übergangen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Kunden-Admin trägt die Adresse ein (nur mit Merkmal), der Link (7 Tage,
einmalig) führt zu Anmeldename und Passwort; Stand-Seite per abgeleitetem
Token. Migration 0072: Stand eingeladen, Code-Spalten optional, laufende
Codes zurückgezogen. Code-Endpunkte entfernt; Passwort-vergessen-Kiosk
bleibt bis zur Umstellung der Rolle.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
DELETE /api/v1/organizations/<org>/enrollment-sessions/<id> entfernt nur
nicht mehr nutzbare Medien (widerrufen, abgelaufen, aufgebraucht).
archive_device() entzieht jetzt auch das Agent-Secret: ein gelöschtes Gerät
checkte bisher weiter ein (Liebherr-47, 03.10.2026).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
_geraete_ampel(): rot bei Fehlern im letzten gemeldeten Lauf oder Platte
>= 95 %, gelb bei knappen Ressourcen oder länger/nie nicht gemeldet, mit
Gründen; für Kunden- und Admin-Dashboard. Tabelle plattform_ereignisse:
neue Stände vorab/stabil schreibt der Spiegel-Thread, Deploy/Migration/
Boot-Medium die Wrapper auf anode. Admin-Dashboard liefert die letzten 30.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Für postinstall.sh: liest tuxflotte_agent_commit aus roles/agent/defaults/main.yml
im aktuellen Spiegel-Stand der Stufe des Geräts.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Der Agent meldet seit 54f76f1, ob er den Ansible-Stand als Archiv von
anode, per Git oder per Git-Rückfall bezogen hat. Nur die drei bekannten
Werte werden gespeichert; Gerätelisten liefern das Feld mit.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Hintergrund-Thread spiegelt ansible-content (vorab), -stabil und
provisioning-agent alle 60 s nach data/spiegel, Archiv (tar.gz + SHA-256)
je Stand, die letzten drei je Stufe bleiben abrufbar
- Check-in liefert zusätzlich ansible_stand {commit, sha256}; ansible_repo
bleibt als Rückfall
- GET /api/v1/agent/ansible/<commit>.tar.gz und
/api/v1/agent/fassung/<commit>/<datei> nur mit Agent-Secret
(Authorization + X-Tuxflotte-Geraet), nur zustehende Stände
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Beides war über anode.tuxflotte.de ohne Anmeldung erreichbar (Durchsicht
18.10.2026, ADR-0046 Abschnitt 'Unabhängig davon'). Health-Check des
Deploys läuft seit infra 7c7069b über /health.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Check-in liefert persoenliche_konten (anlegen mit Hash, aktiv, sperren,
entfernen). /api/v1/agent/persoenliche-konten nimmt die Ergebnisse an:
angelegt löscht den Hash und merkt ohne "Bestehenden Zugang behalten" die
übrigen Konten zum Entfernen vor. Ein Code ohne Kästchen sperrt bestehende
Konten sofort. Sperren/Entsperren je Konto. Eine Neuinstallation beendet
alle Personalisierungen des Geräts. Migration 0065 um gesperrt, entfernen,
geraet_meldung und Status fehlgeschlagen ergänzt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Code je Gerät (7 Tage, nur Hash gespeichert), Einreichen mit Domänen- und
Anmeldenamenprüfung (Passwort kommt nur als SHA-512-crypt), Bestätigung
binnen einer Stunde, verfallene Vorgänge verlieren Hash und Adresse. Die
Platzhalterseite /personalisierung entfällt, das Formular liegt in der
Kundenplattform.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bauplan Schritt 1 (platform-docs roadmap/veyon-schluesselverteilung-
diskussion-2026-10-14.md). Paar beim ersten Bedarf erzeugt (RSA 4096,
PKCS#8/SPKI-PEM wie veyon-cli), privat Fernet-verschluesselt. Optionen:
veyon_schluesselname, veyon_public_pem, veyon_raum, veyon_lehrer; nur
Lehrergeraete zusaetzlich veyon_private_pem und veyon_rechner
(<hostname>.local, ohne sich selbst). Lehrer = Haekchen veyon_lehrer an
irgendeiner aktiven Gruppe. Fehler brechen den Check-in nicht ab.
Getestet gegen eine Wegwerf-Datenbank mit allen Migrationen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
adminandClaude Opus 5.5