Crumbforest Login 03.12.00: Statement zum Offline-Stand

Von: Branko → OZMAI, Crew
Stand: 9. Oktober 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3, keine automatische Geltung, kein Brain-Status)
Charakter: ZUSAMMENFASSUNG + STATEMENT. Fasst die Inbox-Einträge vom 8. und 9.10. zusammen (ab 2026-10-08_TLS-GATE-V3-11-0-…, letzter 2026-10-09_TLS-GATE-AUDIT-ABLEHNUNGEN-MIT-VERSUCH-…). Ersetzt keine Aussage. Bei Widerspruch gilt der jeweilige Einzeleintrag.
Quelle: Repo TLS-Gate-Mock-Pipeline (git.crumbforest.org), dort auch als docs/crumbforest_login_031200_statement.md (31ade6f). Tag v3.12.0 = 5e064de (8.10.). Darauf main = deb4098 mit sieben Commits ohne eigenen Tag (04c6095 … deb4098, im CHANGELOG unter „Unveröffentlicht“).
Belege (Stand deb4098): lokal alle Suiten grün, u. a. test_katalog 103, test_orders 119, test_inventory 70, test_stammdaten 32, test_matrix_mockup 20, test_login_instance 5. VM gegen MariaDB nach Image-Neubau: run 87, p3 48, p4 54, p5 31, p6 22, p7 50.

Legende: ✅ real/gebaut · 🧪 gebaut, getestet, nicht live · 🛠 spezifiziert · ⬜ OPEN · ❓ UNKNOWN

Keine Zugangsdaten, keine Kunden-Domains, keine Reseller-IDs, keine Ausgaben aus echten Läufen. Alle Demo-Daten sind synthetisch (example.test, *.test).

0. Zum Namen

„03.12.00“ steht für Version 3.12.0. Das Datum 03.12.(19)76 kommt nur in Brankos Wortspiel vor und ist keine Angabe im System.

Genau genommen: Der Tag v3.12.0 endet bei 5e064de (Stammdaten-Seite, Matrix-Abgleich, Demo-Mockup). Katalog-CRUD, Löschen mit Audit, Instanzname, Storno-Grund, Versionsstempel und Ablehnungen mit Versuch liegen danach auf main, ohne eigenen Tag. Dieses Statement bestätigt den Stand deb4098 unter dem Namen 3.12.0. ⬜ Ob dafür ein eigener Tag gesetzt wird (z. B. v3.12.1 oder v3.13.0), ist offen.

1. Kernaussage

Bis auf den Lauf mit aktivem SOAP-Zugang ist der Stand offline in einem Netz tragbar:
Anmeldung, Gruppen, Katalog, Buchungen, Registrar-Spiegel und Audit laufen aus der eigenen DB (SQLite oder MariaDB), ohne bei jedem Aufruf den Registrar zu fragen.
Belegt ist das mit Mockup, Fake-Registrar und Suiten. Gegen den echten Registrar gibt es dazu nur Brankos Aussage (§5).

Bild (Branko, nicht OZMAI-Geltung): Brücke = Tunnel = Stern = Krümel. Der Login war die erste Brücke. Erst über ihn lassen sich weitere Brücken anbinden oder Tunnel bauen. Die „Sternenkarte“ (Graph-Snapshot .codebase-memory/) zeigt die Dateien als Sterne und die Aufrufe als Verbindungen.

2. Die Kette: was offline steht

Reihenfolge nach der Modulkette #login → #crew → #schluessel → #ca → #hosting → #ssl (v3.6.0). Die Kette wird angezeigt und sperrt nichts.

Glied Stand Offline-fähig Beleg
Login (Passwort + TOTP, MFA-Modus je Gruppe code/qr, 2FA selbst erneuern, Login-Doktor) 🧪 ✅ v3.1.0–v3.4.0, p3/p4
Instanzname auf der Anmeldeseite (Dev) 🧪 ✅ aa786ba, test_login_instance 5
Crew (Gruppen, Rollen admin/group_admin/user/readonly, users.php) 🧪 ✅ v3.0.0 ff.
Schlüssel (SOAP-Zugänge je Gruppe, versiegelt, CLI-Guard) 🧪 Zugang ja, Aufruf nein v3.0.0
CA (Node-CA, CRL, mTLS-Sensor) 🧪 ✅ v3.0.0, LAUF_NODE_CA.md
Stammdaten: Katalog, Kategorien, Freigaben, Buchungen je Person 🧪 ✅ v3.9.0, katalog.php, stammdaten.php
Dashboard (Kacheln aus Stammdaten, nur lesend) 🧪 ✅ v3.8.0, v3.10.1
Registrar-Spiegel (registrar_inventory + Ereignisse, bestand.php) 🧪 Lesen ja, Aktualisieren braucht SOAP v3.11.0/3.11.1
SSL (Order, Replace, Renew, Deploy-ZIP, ssl_outbox) 🧪 lokal, ✅ live laut Branko nein, braucht den Registrar v3.2.0, v3.6.1, §5
Audit (audit_log, auditlog.php, Suche in Aktion und Kontext) 🧪 ✅ durchgehend

3. Entscheidungen aus dem Verlauf (mit Quelle)

# Entscheidung Quelle Stand
E1 Das Bestandssystem des Registrars bleibt führend, TLS-Gate spiegelt nur und schreibt dort nichts zurück Branko, 8.10. ✅
E2 Der erste Abgleich je Zugang ist die Baseline (ein Ereignis), danach werden nur Änderungen protokolliert (new, changed, gone, back). Die Ereignistabelle ist append-only Entwickler, v3.11.0 🧪
E3 Fail closed beim Abgleich: nur source soap, ab 2000 Zeilen gilt die Liste als abgeschnitten (auch --force hilft nicht), eine leere oder halbierte Liste geht nur mit --force durch Entwickler, v3.11.0 🧪 mutationsgetestet
E4 Abweichung statt Automatik: Eine unbekannte Produkt-ID wird gemeldet und nie angelegt. Sonderfälle pflegt der Mensch per SQL-Import, mit Audit Branko, 8.10. 🧪
E5 „Aktualisieren“ im Web ab Rolle user, höchstens alle 5 Minuten je Zugang, sonst gilt der Spiegel Entwickler, v3.11.1 🧪
E6 Eine Vorgabe gilt erst als bestätigt, wenn sie als Vorgabe geprüft ist: Brankos Matrix liegt wörtlich als Datei vor, 17 von 17 Zeilen am Mockup, mit Gegenproben, die rot werden können Branko, 8.10. 🧪
E7 „Kein Sprint, sondern eine Stammdaten-SOT“: Die Stammdaten werden am Ende von extern per SQL abgefragt und mit den alten Subsystemen abgeglichen. Die Baum-Modellierung entsteht vorab manuell im Dev-Modus, die Seite Katalog ist nur Hilfsmittel Branko, 9.10. 🛠
E8 Slug nach dem Anlegen fest Entwickler, von Branko bestätigt 9.10. ✅
E9 Keine inaktiven Datensätze vorhalten. Löschen ist endgültig, der gelöschte Datensatz steht im Audit Branko, 9.10. 🧪
E10 Löschen wird abgelehnt, solange etwas darauf zeigt, auch beendete Buchungen, denn sie bleiben die Quelle der Berechnung. Für diesen Fall bleibt nur das Abschalten Branko, 9.10. 🧪
E11 Die Regeln sind einfache SQL-Abfragen im Anwendungscode, ohne Trigger und ohne Kaskaden, damit das Konstrukt später auch in Rust laufen kann Branko, 9.10. 🧪 (Ausnahme: der Append-only-Trigger am Spiegel von v3.11.0 besteht weiter)
E12 Storno und verworfene Vorgänge gehören ins Audit und müssen abfragbar sein. Der Storno-Grund ist jetzt Pflicht und steht in cli.order_cancel (grund, von, registrar_ref) Branko, 9.10. 🧪
E13 Eine Ablehnung im Audit trägt den versuchten Wert (von → nach) und zählt, was im Weg stand Branko-Befund, 9.10. 🧪
E14 Instanzname auf der Anmeldeseite im Dev an, per Instanz-.env abschaltbar (LOGIN_INSTANCE=0). Im Betrieb ohne die Variable aus Branko, 9.10. 🧪
E15 CSS und JS mit Versionsstempel, damit eine ausgelieferte Änderung im Browser auch ankommt Entwickler nach Branko-Befund, 9.10. 🧪
E16 Live-Ausgaben werden nicht geteilt. Gearbeitet wird mit Mockup, Fake und Format-Beispielen, ein Live-Ergebnis gilt nur als Brankos Aussage Branko (Datenschutz) ✅ Arbeitsregel
E17 MFA-Standard für neue Gruppen ist qr (Env TLSGATE_MFA_DEFAULT) Branko, v3.7.0 🧪 ⚠ Wirkung auf Root-Gruppen nicht mit der Crew besprochen

4. Prüfmaßstäbe aus dem Verlauf (Branko, nicht OZMAI-Geltung)

  • Version vermerkt ≠ Funktion vorhanden. In der VM stand die Schema-Version 5, der Code fehlte (v3.11.1).
  • Grüne Regeln ≠ bestätigte Vorgabe. Erst der Matrix-Abgleich Zeile für Zeile bestätigt die Matrix.
  • Ausgeliefert ≠ gesehen. Die HTTP-Prüfung war grün, der Browser zeigte trotzdem die alte CSS.
  • Fehlermeldung ≠ Ort. „Anmeldung fehlgeschlagen“ kam von ozm01, getestet werden sollte ozm03. Geklärt hat das erst das Audit der anderen Instanz.
  • Spiegel = Aussage zu einem Zeitpunkt. last_seen_at hält fest, wann zuletzt gesehen wurde. Ein Lauf ohne Änderung bestätigt nichts neu.
  • Abschalten hält einen Zustand fest, Löschen mit Audit eine Feststellung. Wo Monitor-Dienst und externe SQL-Berechnung nachsehen, folgt aus dieser Wahl (E9/E10).

5. Was live belegt ist (nur Brankos Aussage)

  • ✅ 9.10.: v3.11.1 auf einer echten VM neu gebaut, echter SOAP-Zugang. Der Import über den Registrar hat funktioniert, zwei Orders wurden ausgeführt, der Bestand wurde abgeglichen. Im Audit ist alles lückenlos nachvollziehbar, von der neuen Order-ID bis zum ZIP-Download.
  • Damit ist die offene Frage aus v3.6.1 („liefert die API live eine neue Order-ID?“) aus Brankos Sicht beantwortet.
  • Ausgaben liegen dem Entwickler nicht vor und werden nicht angefordert (E16).

6. Klicktest-Instanz ozm03 (DEMO)

  • ✅ Frisch aufgebaut im Modus mock, kein SOAP-Zugang aktiv. Branko schaltet den echten nach seinem Vortest selbst auf. Bis dahin zeigt die Kette „schluessel: fehlt“.
  • ✅ 24 Produkte freigegeben, 12 Kategorien, 18 aktive Buchungen aus demo_matrix.sh, 12 synthetische Bestandszeilen an einem abgeschalteten Demo-Zugang.
  • ✅ „Crumbforest Login“ hat Branko selbst auf katalog.php angelegt (16:37, catalog.product_add). Gebucht ist es für alle drei Konten: beim Admin über #admin (eingerechnet), bei beiden Demo-Usern über #container (mit Preis). Die Buchungen stehen auf offered: Das Aktivieren durch die User ist der nächste Klicktest.
  • ✅ Klicktest Firefox: „das klickt sich soweit gut“. Die Regel kategorie_in_gebrauch hat beim Klicken gegriffen („so macht das ja alles Sinn“).

7. Was fehlt: der letzte SOAP-Schritt und weiteres

  • ⬜ Lauf mit aktivem SOAP-Zugang auf dem aktuellen Stand deb4098 (Brankos Lauf vom 9.10. war v3.11.1). Als erster Schritt ist sync --dry-run vorgesehen.
  • ❓ Laufzeit und Statuswerte beim Web-Abgleich mit dem echten Bestand (mehr als 600 Zeilen). Die Werte zertifizierung_laeuft und ssl_ok stammen aus einem Beispiel mit fünf Zeilen.
  • ❓ Ob SSL-4 aus sslListExtended der ID 4 der Produktliste entspricht. Bisher Kandidat mit Fragezeichen, deshalb zählt die Löschsperre beide Schreibweisen.
  • ⬜ Storno beim Registrar gibt es im Code nicht. ❓ Ob ein per sslReplace ersetzter Vorgang als „ersetzt“ abfragbar ist, ist nicht geprüft.
  • ⬜ Order-Pool, Überwachung der Zertifizierung (DCV, CNAME), pipe-bar an die Bash. Cron je SOAP-Gruppe mit JSON im Dateisystem, DB nur bei Änderung.
  • ⬜ Verknüpfung der Bestandszeilen mit Stammdaten (User lesen, Admin schreiben). Benachrichtigung der Crew bei Abweichung ist nicht gebaut.
  • ⬜ „Keine inaktiven Datensätze“ für registrar_inventory.gone_at ist nicht entschieden.
  • ⬜ Freigabe nur für die eigene Gruppe des Admins. Instanz ozm00 mit Admin an der Wurzel und lesendem NetBox-Zugriff.
  • ⬜ Der Schalter für den Instanznamen ist nur in der Dev-VM verdrahtet, in der Ansible-Rolle nicht.
  • ⬜ Chain sperrt nichts und ist keine Weiterleitung. user_cli/Bash werden neu konzipiert (Branko, 8.10.).
  • ❓ „Alle Orders freigeben“ wurde als Freigabe aller Katalogprodukte umgesetzt. Ob das gemeint war, ist offen.

8. Einordnung als Prüffall (Branko, nicht OZMAI-Geltung)

Offline heißt hier: Die eigene DB ist die Quelle für jede Entscheidung, die sie tragen kann. Der Registrar wird nur gefragt, wenn sich draußen etwas geändert haben kann (Aktualisieren, Sync, Order). Jede Brücke nach draußen hinterlässt eine Spur im Audit, jede abgelehnte auch.

Bestätigt ist dieser Stand durch Tests, Mockup und Klicktest, nicht durch Geltung. Ob eine gespiegelte Zeile oder ein Stammdatensatz später für eine Entscheidung taugt, entscheidet die Crew.