docker_vm — RZ-Setup im Container durchspielen

Ziel: ein Container, der sich wie die RZ-Node verhält (Debian Trixie, nginx, MariaDB, php-fpm), mit mehreren Betriebs-Usern, in dem
native_php und native_bash_cli so laufen wie dort — und in dem sich der 500er und der fehlende QR nachstellen lassen, bevor wieder
auf der Node getestet wird. Nur Mockdaten, kein echter Registrar, keine CA.

Stand: P0 bis P6 abgenommen (1.10.). Quelle der Software: ../native_php, ../native_bash_cli (unverändert, nur kopiert).

1. Was geprüft ist (Trixie-Image, 2026-10-01, aarch64)

• Entscheidung: PHP 8.4 aus dem Debian-Archiv. Der Code läuft laut composer.json ab 8.1 und ist unter 8.2 und 8.5 grün; 8.4 ist die echte Zielversion und wird in P3 geprüft.
• php8.4-cli bringt sodium, openssl, PDO, ctype mit. mbstring fehlt in einer Minimalinstallation, der Code ruft aber mb_strlen, mb_str_split
  (Auth.php:307,314) und mb_substr (SslHandler.php:25) auf, und composer.json führt ext-mbstring nicht. Auf einer Node ohne php-mbstring gäbe
  das einen fatalen Fehler = HTTP 500 beim Passwortwechsel. Hypothese, nicht belegt — der 500er im View kann trotzdem etwas anderes sein. P3 stellt es nach.
• Docker Desktop läuft hier auf aarch64, die RZ-Node ist vermutlich x86_64. Im Code ist nichts architekturabhängig; das Image wird nicht an arm64 gebunden.

2. Aufbau: ein Container, drei Dienste

docker_vm/
  Dockerfile              debian:trixie + Pakete, COPY der beiden native_*-Verzeichnisse nach /opt/tlsgate-src (Vorlage, nicht lauffähig)
  compose.yml             ein Dienst, Port 18080 -> 80, benannte Volumes: /var/lib/mysql, /home
  provision/
    instance.sh <name>    legt EINE Instanz an (idempotent), siehe 4.
    templates/            pool.conf, vhost.conf, mariadb-grants.sql mit Platzhaltern
  fake-soap/              Fake-Registrar (nur im Container, 127.0.0.1:443): WSDL, Szenarien je Order-Nummer, Fake-CA
  tests/                  run.sh = P2, p3.sh = P3, lib.sh = gemeinsame Hilfen (von außen per curl, nach innen per docker exec)
  PLAN.md  README.md

Init-System (Entscheidung nach einem kleinen Spike, P0): Ziel ist systemd als PID 1, weil die RZ-Node so läuft (systemctl reload php8.4-fpm, journalctl).
systemd im Container braucht unter Docker Desktop --cgroupns=host bzw. --tmpfs /run. Ergebnis P0: systemd läuft. Nötig ist cgroup: host mit /sys/fs/cgroup rw und tmpfs auf /run, /run/lock, /tmp — ohne privileged
(--cgroupns=private allein bricht ohne Ausgabe mit Exit 255 ab; privileged startet zwar, meldet aber degraded). Klappt es auf einem anderen Host nicht, fällt P0 auf einen schlanken
Supervisor (mariadbd, php-fpm8.4 -F, nginx -g 'daemon off;') zurück. Das ändert nichts an Pools, Vhosts und Rechten — nur systemctl fehlt dann im Test.

3. Benutzer und Verzeichnisse

Je Instanz, alles unter dem Heimverzeichnis (/home/<name>):

app/        native_php (Webroot = app/public, src/ bin/ database/ templates/ davor unerreichbar)
bin/        native_bash_cli (dashboard.sh, soap_cli.php, …), später SSH-Bash
state/      0700, Besitzer <name>: root.key (0400), Dateien, keine SQLite (MariaDB)
logs/       php-fpm error + slow, nginx access/error der Instanz, 0750 <name>:adm

• php-fpm-Pool je Instanz: eigener User/Gruppe, Socket /run/php/<name>.sock (<name>:www-data 0660), clear_env = yes, Konfiguration (TLS_GATE_STATE_DIR,
  TLSGATE_DB_*) nur als env[...] in der Pool-Datei (root-lesbar), open_basedir auf app/ + state/ + /tmp, eigener error_log in logs/.
• disable_functions im Pool ist Pflicht (docs/SECURITY.md, AUD-33): Ein Web-User, dem alles gehört, ist auch CLI-Operator des Guards. Ohne exec, shell_exec,
  system, passthru, proc_open, popen im Pool kann ein Webshell-Fund bin/user_cli.php aufrufen. P3 prüft das.
• nginx: ein server je Instanz, server_name <name>.localhost, Root app/public, fastcgi_pass auf den Socket der Instanz. Im Test per
  curl --resolve ozm01.localhost:18080:127.0.0.1. TLS gehört nicht zu diesem Plan (die Vorlage deploy/nginx.conf.example bleibt Referenz).

3a. Abweichungen vom ersten Entwurf (P1)

• nginx-Logs liegen doch in /home/<name>/logs/, aber als www-data:<name> 0640 vorab angelegt: nginx öffnet sie als root, so kann die Instanz sie lesen, die andere nicht. php-error.log gehört der Instanz.
• Drittes Volume /root/.provision (Zugangsdaten je Instanz). Ohne es passten nach compose down die DB-Passwörter in mysql nicht mehr zu den Dateien. Benutzer und UIDs sind nicht im Volume: instance.sh legt sie mit fester UID neu an (ozm01 = 2001, ozm02 = 2002).
• Immer ein Pool vorhanden: php-fpm startet ohne Pool nicht, systemd meldete degraded. Das übernimmt der Pool fakesoap des Fake-Registrars (vorher ein Leerlauf-Pool idle).
• TLSGATE_COOKIE_SECURE=0 im Pool: die Testinstanz hat kein TLS, der __Host--Cookie der App braucht https. Im Betrieb entfernen.
• /home/<name> ist 710 <name>:www-data: nginx darf hinein, eine andere Instanz nicht. app/ und bin/ gehören root und sind für den Web-User nicht schreibbar.
• disable_functions im Pool: exec, passthru, shell_exec, system, proc_open, popen, pcntl_exec, pcntl_fork, dl, putenv, mail — der Web-Code nutzt keine davon (geprüft per grep).

4. Datenbank — die Entscheidung

Frage war: eine DB für alle, oder eine je User? Antwort: ein MariaDB-Server, ein Schema je Instanz, kein gemeinsames Schema für Mandantendaten.

Begründung aus dem Code, nicht aus Geschmack:
- Jede Instanz hat einen eigenen Wurzelschlüssel (state/root.key). Zugänge (soap_credentials) und TOTP-Secrets sind damit versiegelt und an <group_id>|<label>
gebunden. Ein gemeinsames Schema würde Zeilen enthalten, die die jeweils andere Instanz nicht öffnen kann — das ist beabsichtigt, aber dann ist es kein gemeinsamer Bestand.
- Mandanten (Gruppen, Reseller) liegen schon in der Instanz (groups, users). „Ein Reseller mit Schreibrechten“ ist eine Zeile in groups, kein zweiter DB-User.
- „Eine DB für alle“ gilt deshalb für das Betriebsmittel: ein Prozess, ein Backup, ein Monitoring — nicht für das Schema.

Je Instanz zwei DB-Benutzer (schließt den offenen Punkt „DML-only-Grants“):

Der Web-Prozess kann dadurch keine Tabelle ändern und keine Trigger anfassen (die Audit-Tabellen sind per Trigger append-only; unter MariaDB 11.8 ist das neu zu belegen, siehe 7).

Gemeinsam wird erst etwas, wenn echte Mehr-Node-Logs gebraucht werden: ein eigenes Schema ozm_logs mit INSERT-only für jede Instanz. Das ist ein Feature von
native_php, nicht von diesem Container, und bleibt hier ungebaut. ozm02 reicht aber, um die Frage vorher greifbar zu machen: Welche Logs der zweiten Instanz sieht die erste (soll: keine)?

4.3 Was ozm02 konkret prüft

1. Isolation: ozm01 kann weder ozm02/state/, noch dessen Socket, noch dessen Schema lesen (Datei-, Socket- und DB-Rechte).
2. Der Guard: ozm02 darf bin/user_cli.php auf seiner Instanz als Besitzer ausführen, auf der von ozm01 nicht (Exit 3).
3. Logs: Audit, php-fpm-, nginx-Logs liegen je Instanz getrennt; ein Fehler in ozm02 taucht nicht in den Logs von ozm01 auf.
4. Schreibrechte „Reseller“: eine Gruppe vom Typ Reseller in ozm02 kann (noch) kein SSL bestellen (Auth::sslAllowed()), siehe docs/SECURITY.md; Test prüft, dass das so bleibt.

5. Phasen mit Abnahme

tests/run.sh führt P1 bis P5 maschinenlesbar aus (gruen: N rot: M), damit ein Stand reproduzierbar ist. Die Suites aus native_php/tests/ laufen zusätzlich
im Container als ozm01 gegen MariaDB (TLSGATE_DB_DRIVER=mysql) mit PHP 8.4.

5a. Befunde aus P2

1. Echter Fehler, behoben: UPDATE … RETURNING in Auth::accountFail() ist SQLite-Syntax. Unter MariaDB lieferte jeder Fehlversuch bei einem bestehenden Konto (falsches Passwort, falscher TOTP-Code) einen PDOException = HTTP 500; nur unbekannte Konten kamen durch. Gefunden, weil der Test einen falschen Code schickt. Behoben in main und native_php (UPDATE, dann SELECT); tests/test_sql_portable.sh verhindert die Rückkehr (und schlägt auf dem alten Code an). Betrifft jede Installation mit TLSGATE_DB_DRIVER=mysql.
2. Port-Falle: Auf dem Host lauscht oft serve.sh auf 127.0.0.1:8080 und überdeckt das Docker-Mapping. Der Container nutzt deshalb 18080, und der Test prüft zuerst, dass auf dem Port wirklich nginx antwortet.
3. QR nur beim ersten Mal (Absicht, Auth::enrollmentData()): belegt, der zweite Login zeigt den Code-Schritt ohne QR und ohne Secret. Ein neuer QR geht nur über user reset-mfa (dann zeigt der nächste Login ihn wieder). Seit v3.1.0 geht ein neuer QR auch angemeldet über mfa.php (Passwort, QR, erster Code; das alte Secret gilt bis dahin), Alltagsbefehle: HANDBUCH §4.
4. Abmelden ist nur POST mit CSRF-Token (GET → 405). Ein TOTP-Code gilt nur einmal (Replay-Sperre): zwei Logins im selben 30-s-Fenster scheitern, der Test wartet aufs nächste Fenster.
5. Bash-Dashboard: ohne erreichbares SOAP fällt es auf den Mock zurück. Mit installiertem php-soap versucht es dafür zuerst die echte WSDL (BWA_SOAP_WSDL-Standard) mit Dummy-Zugang; der Test setzt deshalb eine unerreichbare WSDL, damit nichts den echten Registrar erreicht.

5b. Befunde aus P3 (Fake-Registrar)

Der Fake (docker_vm/fake-soap, WSDL im Stil des echten Dienstes, rpc/encoded) liefert je Order-Nummer eine andere Datenform: FAKE-1 Text und Chain, FAKE-NOCHAIN, FAKE-NIL, FAKE-OBJ (Struktur), FAKE-LIST, FAKE-NEST, FAKE-STRUCT, FAKE-ERR (2303), FAKE-FAULT. Bis v3.1.0 durfte die Instanz per TLSGATE_SOAP_HOSTS nur dorthin (instance.sh ozm01 fake); der Modus ist abgeschafft, weil er das Anlegen eines echten Zugangs verhinderte. Den Fake-Zugang legt der Test selbst an (cred add).
1. Der 500 der Node ist nachgestellt: eine SOAP-Struktur (stdClass) in validationDNS wirft im alten e() Error: Object of class stdClass could not be converted to string, das <dt> ist schon ausgegeben. Mit Listen allein (v3.0.1) lief es. Behoben in v3.0.2.
2. Weiterer echter Fehler, behoben: 21 Stellen in den Templates castelten selbst mit (string) vor ->e() und umgingen damit den Fix. Eine Struktur in domain, status oder reseller gab weiterhin einen 500 (result_details.php:24). Die Casts sind weg, tests/test_view.sh verbietet sie.
3. Ohne php-mbstring fiel die ganze Detailansicht aus, nicht nur der Fehlerpfad: SslController.php:86 ruft mb_substr im Normalfall, Auth.php mb_strlen/mb_str_split beim Passwortwechsel. Folge: fataler Fehler mitten in der Seite (HTTP 500), composer.json und Doktor kannten die Abhängigkeit nicht. Jetzt meldet bootstrap.php fehlendes mbstring/sodium sofort mit 503 und Paketnamen (Log + Antwort), composer.json verlangt ext-mbstring, der Doktor prüft es.
4. Kein stiller Mock: ohne Zugang und ohne TLSGATE_MOCK=1 zeigt die Konsole „SOAP nicht verfügbar“, nie Beispieldaten; mit mock sind sie als Mock gekennzeichnet.
5. Falle im Test, nicht im Code: opcache prüft Zeitstempel nur alle 2 s; wer View.php austauscht und sofort anfragt, bekommt noch den alten Stand. Der Test wartet drei Sekunden.

5c. Befunde und Entscheidungen aus P4

• ssh: openssh-server im Image, Port 2222. sshd: kein root, kein Passwort, kein Tunnel/Forwarding, AllowGroups ssh-instances. instance.sh nimmt die Instanz in die Gruppe auf und setzt authorized_keys (Besitzer root, der User kann seine Schlüssel nicht ändern) aus /root/.provision/ssh/<name>.pub; ohne diese Datei kein Zugang. Die Login-Shell kennt dashboard.sh im PATH und fragt nur den Fake-Registrar. Schlüssel sind Wegwerf-Testschlüssel (docker_vm/.demo-key, gitignored).
• Fehler im Image, behoben: Mein Aufräumen der systemd-Units entfernte systemd-user-sessions; /run/nologin blieb stehen, PAM wies jeden ssh-Login ab („Access denied by PAM account configuration“). Jetzt aktiviert.
• Isolation belegt (je Richtung): fremdes Home, root.key, Logs, php-fpm-Socket und /root/.provision sind nicht les-/erreichbar; ozm01_app öffnet ozm02 nicht und umgekehrt; verschiedene root.key; verschiedene Benutzerdaten (Admin von ozm01 kann sich am Vhost von ozm02 nicht anmelden).
• Guard: ozm02 darf user_cli.php auf der eigenen Instanz; mit dem State-Pfad von ozm01 Exit 3, keine Daten.
• Reseller: Admin-Rolle in Reseller-Gruppen ist verboten (nur group_admin); die Konsole zeigt „Noch nicht freigeschaltet“, ein POST getOrder liefert nichts, beim Registrar kommt kein Aufruf an.
• Beobachtet, kein Fehler: Die App sperrt eine IP nach 10 Fehlversuchen in 15 min (Auth::IP_MAX_FAILS); der Test setzt die Zähler vor dem Abschnitt zurück. group add mit bereits vorhandenem Slug endet mit einem PDOException-Stacktrace statt einer Meldung (kleiner Schönheitsfehler; behoben in v3.2.1).
• Fund im Bash-Dashboard, behoben: Gegen den (Fake-)Live-SOAP zeigte dashboard.sh in „Expire (Rest)“ und „Gültig ab/bis“ rohe Unix-Zeitstempel ohne Resttage und Farbe: days_left() rief date -d "$exp", das nur ISO-Datum versteht; die API liefert laut SOAP-Doku Unix-Sekunden (0 = kein Datum), nur der Mock ISO. Neu to_epoch/fmt_ts (Unix, ISO, openssl-Format; GNU- und BSD-date, LC_ALL=C für Monatsnamen), in Liste, Details und Cross-Check eingesetzt. In native_bash_cli/ (einzige Abweichung vom Stand 3dec8a8, siehe dessen README) und in bin/dashboard.sh; test_dates.sh (16 Prüfungen), p4.sh prüft es per ssh.
• Image, zwei weitere Funde: systemd-user-sessions startet im Container nicht von selbst (Boot-Links entfernt) → /run/nologin blockiert ssh; jetzt Drop-in ssh.service.d (Wants=/After=). calls.log des Fake-Registrars muss www-data gehören, sonst schreibt der Dienst still nichts. P2 ist jetzt unabhängig vom Zustand (deaktiviert den Zugang fake).
• Hinweis: Ein Neubau des Images erzeugt neue ssh-Hostschlüssel; bekannte Einträge dann mit ssh-keygen -R "[127.0.0.1]:2222" entfernen.

6. Nicht Teil dieses Plans

Rust, Node-CA, echte SOAP-Aufrufe, TLS-Terminierung, ein gemeinsames Mandantenschema, SSH-Zugang für die Instanzen (steht langfristig an; der Aufbau mit /home/<name>/bin
ist dafür vorbereitet), Entfernen der Bestelltabellen aus dem Schema.

7. Offene Punkte und Risiken

1. systemd im Container kann unter Docker Desktop scheitern → Supervisor-Fallback (2).
2. MariaDB statt MySQL 8: Die Trigger der Audit-Tabellen (append-only) und die CHECK-Prüfung des Migrators sind bisher nur gegen ein MariaDB-Docker auf :3307 belegt. In 11.8.6 neu prüfen.
3. Der echte 500er der Node fehlt uns. Ohne error_log der Node bleibt P3 eine Nachstellung. Wenn möglich, vorher von der Node holen: journalctl -u php8.4-fpm, /var/log/nginx/error.log,
   php -v && php -m und sudo -u <user> php bin/TLS-doktor.bash. Das ist die schnellste Abkürzung und kostet keinen Bau.
4. QR im Browser ist nur während der Einrichtung vorgesehen. Auth::enrollmentData() liefert Secret und otpauth-URI nur, solange der User eine offene Anmeldesitzung hat
   und totp_enabled = 0. Wer vorher per user_cli.php enroll (Terminal-QR) eingerichtet hat oder schon einmal angemeldet war, sieht im Browser nie wieder einen QR; ein neuer kommt dann
   nur über user_cli.php (Code neu erzeugen). Das passt zu deiner Beobachtung („nach dem Enroll kam nichts mehr“) und ist laut Code Absicht, kein Fehler — P3(c) belegt es im Container.
   Falls im RZ vor dem ersten Login schon kein QR kam, ist das ein anderer Fehler (z. B. Qr::svg oder mbstring).
5. ext-mbstring gehört in composer.json und in den Doktor, sobald P3(b) bestätigt ist (Änderung in native_php, nicht im SOT).
6. Zugangsdaten im Pool stehen im Klartext in der Pool-Datei (root-lesbar). Für den Test ist das gewollt; für den Betrieb ist LoadCredential bzw. ein Secret-Mount der nächste Schritt.