Test-Handout — cruncher als erste CA im Raum

Stand: 2026-10-17 · Von: Branko / Ansiblekatze
FĂŒr: die Katze im Container (wer auf cruncher arbeitet) und OZMAI
Ablage: Kopie von Ansible-Crumbforest:docs/2026-10-17_TEST-HANDOUT-CRUNCHER-ERSTE-CA.md (Commit 9ed76b4); dort wird weitergeschrieben.
Charakter: Testplan. Es ist noch nichts gebaut. §1 ist geprĂŒft (Befehle stehen dabei), alles andere ist Vorhaben.
Bezug: docs/2026-09-25_ZUSTAND-CRUNCHER-CONTAINER-KRUEMEL.md (Zugang, Host-Vertrag OZM-Inbox, Grenzen),
OZMAI-Inbox 2026-10-16_TLS-GATE-RC1-WURZEL-PARKPLATZ-BRUECKEN-ZU-PUNKTEN_BRANKO.md (Container endet am Punkt)


0. Worum es geht

Der Lab-Container auf dem OZM-Parkplatz (Pelikan-Koffer crumbcase00: LTE-MikroTik, cruncher = RPi5 + NVMe + Hailo-8L) soll die
erste CA werden: SchlĂŒssel fĂŒr GerĂ€te im Raum erzeugen, an das RZ melden, und Alarm schlagen, wenn das, was im Raum per ARP
auftaucht, nicht zu NetBox/Ansible passt. Entscheidung Branko, 17.10.

Getestet wird, ob das geht, ohne das Exponat auf derselben Kiste zu stören und ohne den Raum aufzuzeichnen.

Wer Rolle
GĂ€rtner (Branko, der den Raum hĂ€lt) hĂ€lt den CA-SchlĂŒssel, stellt aus, widerruft
cruncher (Container) trĂ€gt die CA im Raum des GĂ€rtners, prĂŒft, vergleicht ARP ↔ NetBox, meldet ĂŒber sich ans RZ
RZ-Instanz (24/7) liest die Meldung (Resonanz im Audit), stellt nie aus
Museum nutzt einen Login per QR-Code (benutzen, weitergeben, freigeben), findet ihn im Audit

1. Einstand (geprĂŒft 2026-10-17, ~17:30, ĂŒber nullfeld)

Zugang: Mac → nullfeld (10.42.0.1) → cruncher wg0 10.42.0.19, SSH-SchlĂŒssel, ProxyJump (wie im Zustandsdokument vom 25.09.).

PrĂŒfung Ergebnis
Erreichbar ĂŒber nullfeld ja, uptime 12 Tage, Debian 12.15, Kernel 6.12.93+rpt-rpi-2712
ansible-playbook playbooks/{cruncher-hailo,ozm-inbox-host,cruncher-qdrant}.yml --limit cruncher --check --diff je changed=0 — kein Drift
ansible-playbook netbox-raspis.yml --limit cruncher --check --diff changed=1: nur comments RAM 8054 → 8063 MB (wechselnder Messwert in der Quelle der Wahrheit, driftet bei jedem Lauf)
systemctl --failed keine
Hailo /dev/hailo0 da (Modus 0666, fĂŒr alle les-/schreibbar)
qdrant 127.0.0.1:6333 readyz 200
OZM-Inbox-Export ozm-inbox-export inactive / disabled — wie vorgesehen
Exponat hexapi Up 12 Tage
Last ~1,2 keine Arbeit: ein Kernel-Worker hĂ€ngt in mmc_rescan → mmc_attach_sdio (Zustand D, SD/SDIO-Suche); CPU fast leer
/etc/hosts Tippfehler 127.0.1.1 chruncher → sudo: unable to resolve host cruncher
NVMe einmal ausgefallen und zurĂŒckgesetzt (6.10., 13:29, controller is down; will reset), seitdem live
Offen nach außen (0.0.0.0) mosquitto 1883, influxdb 8086, uvicorn 8080, docker-proxy 8000 (hexapi), pironman5 34001; UFW inactive — offen seit 25.09., erst kartieren
ninja.sh „WER FRISST CPU/RAM“ listet nach PID statt nach CPU — zeigt nicht, wer frisst

Lesart: sauberer Einstand fĂŒr das, was Ansible verwaltet. FĂŒr eine CA reicht das noch nicht (§3).

2. Grenzen — gelten fĂŒr jeden Test

  1. Keine node-weiten Störungen. Das Exponat teilt sich die Kiste: kein DISK_FULL, READ_ONLY_FS, RESTART_NODE, POWER_LOSS, kein Reboot.
    „Container offline“ wird simuliert, indem nur die Melde-Unit gestoppt oder der Meldeweg auf nullfeld-Seite gesperrt wird.
  2. Der Container berichtet ĂŒber sich, nie ĂŒber den Raum. Keine Aufzeichnung, wer im Raum war; nichts aus einem KrĂŒmel-Repo.
    Maschinen sind #readonly gegenĂŒber KrĂŒmeln.
  3. Der CA-SchlĂŒssel liegt nie im Klartext auf der Platte und nie in einem Repo, einer Inbox oder einem Ticket.
  4. Ports des Exponats nicht anfassen, bevor kartiert ist, wer mit 1883/8086/8000/8080 spricht.
  5. Jede Änderung ĂŒber Ansible, --check --diff zuerst. Evidence als append-only JSONL-Receipt am Runner, kein Auto-Finding.

3. Vorbedingungen (P0) — vor dem ersten CA-Test

# Was GrĂŒn heißt
P0.1 /etc/hosts korrigieren (cruncher) — per Ansible sudo ohne Warnung
P0.2 NetBox-Kommentar ohne wechselnde Messwerte (RAM, Uptime raus oder gerundet) netbox-raspis.yml --check = changed=0
P0.3 NVMe beobachten: smartctl/nvme smart-log nachinstallieren, Resets zÀhlen Zahl der Resets bekannt; bei einem zweiten: CA nicht auf diese Platte
P0.4 Kartierung 1883/8086/8000/8080/34001 (wer spricht mit wem), dann WG-scoped UFW-Kante Liste der Gegenstellen; Exponat lÀuft nach UFW weiter
P0.5 Versiegelung festlegen: wie die Node-CA im Ursprungs-Repo (TLS-Gate-Mock-Pipeline:bin/node_ca.php, ca.key.sealed, WurzelschlĂŒssel, Zweck ca) oder Hardware-Token Entscheidung des GĂ€rtners, schriftlich
P0.6 Zweitkopie des versiegelten CA-SchlĂŒssels an einem zweiten Ort beim GĂ€rtner Widerruf möglich, auch wenn der Container weg ist
P0.7 /dev/hailo0 nicht fĂŒr alle schreibbar (udev-Regel, Gruppe) Modus 0660

4. TestfÀlle

Format je Fall: Ziel · DurchfĂŒhrung · grĂŒn · rot · UNKNOWN. Kein Fall gilt als bestanden, solange er nicht gelaufen ist.

T1 Erreichbar ĂŒber nullfeld — Ziel: Weg Mac → nullfeld → cruncher steht. · ssh + hostname. · grĂŒn: Antwort. · Stand: grĂŒn (17.10.)

T2 Kein Drift — --check aller cruncher-Playbooks und netbox-raspis.yml. · grĂŒn: ĂŒberall changed=0. · Stand: rot (1 kosmetisch, P0.2)

T3 CA erzeugen — SchlĂŒssel on-node erzeugen und sofort versiegeln; Zweitkopie (P0.6). · grĂŒn: kein Klartext-SchlĂŒssel auf der
Platte (Suche nach PRIVATE KEY außerhalb des Siegels leer), nur root liest das Siegel, Zweitkopie öffnet sich mit dem WurzelschlĂŒssel
des GĂ€rtners. · rot: Klartext irgendwo, Siegel fĂŒr andere lesbar. · UNKNOWN: Versiegelung nicht entschieden.

T4 Zertifikat ausstellen — fĂŒr ein TestgerĂ€t (Kamera-Attrappe, z. B. thinkpad im Koffer). · grĂŒn: Zertifikat prĂŒft gegen den
öffentlichen CA-Teil — auch vom RZ aus, das nur den öffentlichen Teil hat. · rot: RZ braucht dafĂŒr mehr als den öffentlichen Teil.

T5 ARP ↔ NetBox — drei FĂ€lle im Koffer-LAN: (a) bekanntes GerĂ€t mit Zertifikat, (b) bekannte MAC ohne Zertifikat, (c) unbekannte MAC.
· grĂŒn: (a) still, (b) Befund „anwesend, nicht ausgewiesen“, (c) Alarm „unbekannt im Raum“. · rot: (c) still, oder (a) Alarm.
· Hinweis: ARP ist Anwesenheit, keine IdentitĂ€t (MAC fĂ€lschbar) — IdentitĂ€t ist das Zertifikat.

T6 Meldung ans RZ — was der Container meldet, ist eine feste Liste: Zustand des Containers, ausgestellte Zertifikate (öffentlich),
CRL, ARP/NetBox-Abweichungen als Ereignis. · grĂŒn: jedes Feld der Meldung steht auf der Liste; kein Personen-, Kamera-Bild- oder
KrĂŒmel-Bezug. · rot: ein Feld, das den Raum beschreibt.

T7 Widerruf — Testzertifikat widerrufen, neue CRL, RZ sieht den Widerruf. Zweiter Durchgang mit der Zweitkopie bei „Container weg“
(simuliert). · grĂŒn: beide Wege fĂŒhren zur selben CRL im RZ. · UNKNOWN: ohne P0.6.

T8 Schweigen — Melde-Unit stoppen (nicht die Kiste). · Was zeigt das RZ? · grĂŒn: „letzter Stand von , seit still“ —
UNKNOWN mit Zeitfenster, kein Life-Safety-Alarm. · rot: RZ zeigt weiter grĂŒn, oder schlĂ€gt Life-Safety-Alarm.

T9 Museum: QR — zwei verschiedene QR-Codes. (a) Einladung: einmal benutzbar, ohne Geheimnis, im Audit auffindbar.
(b) TOTP-Secret (TLS-Gate MFA-Modus qr): nur fĂŒr die Person, die einrichtet, nur in diesem Moment. · grĂŒn: (a) zweimal benutzt =
abgelehnt + Audit; (b) erscheint nie auf einem Bildschirm, den andere sehen. · rot: ein QR, der beides ist.

5. FĂŒr die Katze im Container

  • Zugang nur ĂŒber nullfeld (ProxyJump), SchlĂŒssel ~/.ssh/crumbforest_cruncher; Ansible mit ANSIBLE_SSH_ARGS="-F <config>"
    (Inline-ProxyCommand bricht, siehe Zustandsdokument).
  • Erst lesen, dann --check --diff, dann erst Ă€ndern — jede Änderung als Playbook im Repo.
  • Verboten auf dieser Kiste: alles aus §2.1. Im Zweifel still sein und fragen.
  • Ergebnis je Testfall als Zeile in einem append-only Receipt (ts, testfall, ergebnis grĂŒn/rot/UNKNOWN, beleg), nichts ĂŒberschreiben.

6. Fragen an OZMAI

  1. Klasse des Schweigens (T8): Ist „UNKNOWN mit Zeitfenster“ fĂŒr den Container richtig — oder gehört er zu einer Klasse, deren
    Schweigen Alarm ist? Wer legt die Klasse fest, und wo steht sie?
  2. Meldeliste (T6): Reicht eine feste Feldliste (Whitelist) als Grenze „berichtet ĂŒber sich, nie ĂŒber den Raum“?
  3. Der GĂ€rtner hĂ€lt den SchlĂŒssel: Ist das eine Person (Branko) oder eine Rolle, die weitergegeben werden kann — und wie wird
    die Übergabe bezeugt?