From 83d49aa1063d0190fa94629d8e958844586c577a Mon Sep 17 00:00:00 2001 From: Richard Date: Wed, 26 Aug 2026 22:09:09 +0200 Subject: [PATCH] A4a vollstaendig: PolyTrader laeuft als Dienst auf Linux; Testumgebung dokumentiert Der Pruefplan ist abgearbeitet. Die Anwendung laeuft nicht nur, sie arbeitet: Core-Hydration, MarketSyncService und 100 echte Maerkte von der Polymarket-API in die Datenbank geschrieben - HTTP, TLS, JSON und DB-Zugriff funktionieren unter Linux. Ergebnisse im Einzelnen: - MariaDB 11.8.6 auf der Test-VM, genau die in DatabaseServerVersion gepinnte Version. Alle fuenf DbContexts migriert, 21 Tabellen. - systemd: active, Shutdown in 0,08 s (Grenze 45 s) ohne SIGKILL, Restart=on-failure greift nach kill -9. - Der neue Exit-78-Schutz wirkt nachweislich: Verbindung entfernt -> Status failed, systemd meldet 78/CONFIG, KEINE Neustartschleife, verstaendliche Meldung im Journal. - D-11 (WorkingDirectory-Falle) ist KEIN Problem: server_settings.xml wird aus /opt/polytrader gelesen, eine Suche ueber das ganze Dateisystem findet keine zweite Datei. Nebenbefund: die Datei wird beim Start gar nicht angelegt, erst beim Speichern von Einstellungen. - Logrotate mit copytruncate rotiert beide Namensmuster, Dienst schreibt weiter. - Alle neun Views konstruieren fehlerfrei, beide Farbschemata vollstaendig. T2 ist belegt statt behauptet: Unter UTC meldet die Anwendung "Anzeige-Zeitzone: Europe/Berlin" und stempelt in derselben Zeile mit 20:04 statt 22:04. Auf einem UTC-Server zeigen damit alle Logs die falsche Zeit, zwischen Mitternacht und 2 Uhr sogar das falsche Datum. Neuer Befund B-4: --smoke-ui scheitert ohne X-Server (XOpenDisplay failed), obwohl es als CI-Werkzeug gedacht ist. "xvfb-run -a" loest es nachweislich - relevant, sobald A2 wieder aufgenommen wird. docs/TESTUMGEBUNG-Linux-VM.md neu: Anleitung fuer ALLE Projekte, die auf der VM testen. Zugang per eigenem SSH-Schluessel je Projekt, eigene Datenbank je Projekt (_test samt eigenem Benutzer, nie eine fremde mitbenutzen), eigenes Dienstkonto, Verzeichnis- und Portkonventionen, Belegungsliste und Aufraeumbefehle. Kopie liegt auf der VM unter ~/TESTUMGEBUNG.md, wo jeder Agent sie beim Verbinden findet. Co-Authored-By: Claude Opus 5 --- docs/ROADMAP.md | 19 +- docs/TESTUMGEBUNG-Linux-VM.md | 245 ++++++++++++++++++ .../BEFUND-Linux-Betrieb-2026-08-26.md | 135 +++++++++- 3 files changed, 394 insertions(+), 5 deletions(-) create mode 100644 docs/TESTUMGEBUNG-Linux-VM.md diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index c12b0a6..809e278 100644 --- a/docs/ROADMAP.md +++ b/docs/ROADMAP.md @@ -166,8 +166,23 @@ unbehandelter Ausnahme ab, statt zu sagen, was fehlt — im Dienstbetrieb hätte Neustartschleife im Zehn-Sekunden-Takt ergeben. Jetzt verständlicher Abbruch mit Exitcode 78 (`EX_CONFIG`) und `RestartPreventExitStatus=78` in der systemd-Unit. -🔒 **Rest blockiert:** systemd, Oberfläche, SIGTERM-Verhalten und der Zeitzonen-Nachweis (T2) -brauchen eine **Testdatenbank** (auf der VM läuft keine MySQL) und **`sudo`**. +✅ **Vollständig durchgearbeitet.** MariaDB 11.8.6 auf der Test-VM, alle fünf Migrationen durch +(21 Tabellen), Betrieb mit Datenbank bestätigt — die Anwendung hat **100 echte Märkte von der +Polymarket-API geholt und geschrieben**. Als systemd-Dienst: `active`, Shutdown in 0,08 s ohne +`SIGKILL`, Neustart nach Absturz greift, und der neue Exit-78-Schutz verhindert nachweislich die +Neustartschleife bei Konfigurationsfehlern. Die D-11-Falle ist **kein Problem** (gezielt geprüft: +keine zweite `server_settings.xml`). Logrotate läuft. Alle neun Views konstruieren fehlerfrei. + +**T2 ist jetzt belegt statt behauptet:** Unter UTC meldet die Anwendung „Anzeige-Zeitzone: +Europe/Berlin" und stempelt in derselben Zeile mit `20:04` statt `22:04`. + +⬜ **Einziger Rest: Sichtprüfung der Oberfläche** — braucht jemanden am Bildschirm der VM +(Schriftrendering, Spaltenbreiten, Dunkelmodus unter GTK). Damit fällt dieser Rest mit **A1** +zusammen. + +**Testumgebung dauerhaft nutzbar:** [TESTUMGEBUNG-Linux-VM.md](./TESTUMGEBUNG-Linux-VM.md) +beschreibt Zugang und Konventionen für **alle** Projekte (eigene Datenbank je Projekt, eigenes +Dienstkonto, Aufräumregeln). ### A4b 🔒 Feldtest im Zielland diff --git a/docs/TESTUMGEBUNG-Linux-VM.md b/docs/TESTUMGEBUNG-Linux-VM.md new file mode 100644 index 0000000..0421ac5 --- /dev/null +++ b/docs/TESTUMGEBUNG-Linux-VM.md @@ -0,0 +1,245 @@ +# Linux-Testumgebung (gemeinsam genutzte VM) + +**Stand: 26.08.2026** · Eingerichtet beim ersten Linux-Lauf von PolyTrader (Roadmap A4a). + +> **Diese Anleitung gilt projektübergreifend.** Sie richtet sich an alle Agenten und Entwickler, +> die auf der VM testen — nicht nur an PolyTrader. Die maßgebliche Fassung liegt auf der Maschine +> selbst unter **`~/TESTUMGEBUNG.md`**; dieses Dokument im PolyTrader-Repo ist die versionierte +> Kopie. Wer etwas an der Umgebung ändert, zieht **beide** nach. + +--- + +## 1. Was diese Maschine ist + +Eine Ubuntu-Desktop-VM zum **Testen** — nicht für Produktivbetrieb, nicht für echte Zugangsdaten, +nicht für Geld bewegende Läufe. + +| | | +|---|---| +| System | Ubuntu 26.04 LTS, Kernel 7.0, x86_64 | +| Ausstattung | 31 GB RAM, 5 CPUs, ~33 GB freier Plattenplatz | +| Erreichbar | `192.168.40.48` über einen WireGuard-Tunnel | +| Benutzer | `richard` | +| Besonderheit | **Desktop-Umgebung vorhanden** — grafische Anwendungen sind testbar, nicht nur Dienste | + +**Warum eine Desktop-VM?** Weil sich damit beides prüfen lässt: der kopflose Serverbetrieb +(systemd) *und* die grafische Oberfläche auf der Zielplattform. + +--- + +## 2. Zugang einrichten + +Der Zugang läuft über **SSH-Schlüssel**. Passwort-Anmeldung wird nicht verwendet — Agenten geben +grundsätzlich keine Passwörter ein. + +### 2.1 Schlüssel erzeugen (auf dem eigenen Rechner) + +```bash +ssh-keygen -t ed25519 -f ~/.ssh/testvm_ -N "" -C "@testvm" +``` + +Ein **eigener Schlüssel je Projekt** — dann lässt sich einzelnen Projekten der Zugang entziehen, +ohne alle anderen auszusperren. + +### 2.2 Öffentlichen Schlüssel hinterlegen + +Der Inhalt von `~/.ssh/testvm_.pub` wird auf der VM in `~/.ssh/authorized_keys` +eingetragen. **Das muss ein Mensch tun** (einmalig, mit Passwort). Direkt auf der VM: + +```bash +mkdir -p ~/.ssh && chmod 700 ~/.ssh && echo '' >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys +``` + +### 2.3 SSH-Konfiguration (auf dem eigenen Rechner) + +``` +Host testvm + HostName 192.168.40.48 + User richard + IdentityFile ~/.ssh/testvm_ + IdentitiesOnly yes + ServerAliveInterval 30 + ServerAliveCountMax 4 +``` + +⚠️ **Kein `ControlMaster`/`ControlPath` eintragen, wenn der Client unter Windows läuft** — +Windows-OpenSSH unterstützt Verbindungs-Multiplexing nicht und scheitert mit +„Failed to connect to new control master". Stattdessen mehrere Prüfschritte pro Aufruf bündeln. + +Test: `ssh testvm "hostname"` + +--- + +## 3. Was installiert ist + +| Werkzeug | Version | Anmerkung | +|---|---|---| +| .NET SDK | 10.0.111 (Runtime 10.0.11) | SDK, nicht nur Runtime — auf der VM kann gebaut werden | +| MariaDB | 11.8.6 | Dienst `mariadb`, lauscht auf `localhost:3306` | +| Git | 2.53.0 | | +| Xvfb | vorhanden | Virtueller Framebuffer für GUI-Tests ohne Bildschirm | +| JetBrains Rider | vorhanden | | +| Docker | **nicht** installiert | | +| Node.js | **nicht** installiert | | + +**Nicht vorhandene Werkzeuge dürfen installiert werden** — aber bitte in der Belegungsliste +(Abschnitt 6) vermerken, damit andere wissen, was sich geändert hat. + +--- + +## 4. Konventionen für mehrere Projekte + +Die Maschine wird von mehreren Projekten geteilt. Diese Regeln verhindern, dass sich Tests +gegenseitig zerstören: + +### 4.1 Datenbanken — je Projekt eine eigene + +**Niemals** eine fremde Datenbank mitbenutzen und **niemals** eine Produktivdatenbank verbinden. + +```bash +# Passwort erzeugen und ablegen (nur für den Besitzer lesbar) +PW=$(openssl rand -base64 18 | tr -d "/+=" | head -c 20) +echo "$PW" > ~/._test_dbpw && chmod 600 ~/._test_dbpw + +sudo mariadb -e "CREATE DATABASE IF NOT EXISTS _test CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; + CREATE USER IF NOT EXISTS '_test'@'localhost' IDENTIFIED BY '$PW'; + GRANT ALL PRIVILEGES ON _test.* TO '_test'@'localhost'; + FLUSH PRIVILEGES;" +``` + +| Was | Schema | Beispiel | +|---|---|---| +| Datenbank | `_test` | `polytrader_test` | +| Benutzer | `_test`@`localhost` | `polytrader_test` | +| Passwortdatei | `~/._test_dbpw` (Rechte 600) | | + +Die Rechte enden **an der eigenen Datenbank** — `GRANT ALL ON _test.*`, nie global. + +### 4.2 Verzeichnisse + +| Zweck | Ort | +|---|---| +| Quellcode | `~/RiderProjects/` | +| Publish/Testlauf im Benutzerkontext | `~/-test` | +| Installation als Dienst | `/opt/` | + +### 4.3 systemd-Dienste + +Unit-Name = Projektname: `.service`. Eigenes Dienstkonto je Projekt: + +```bash +sudo useradd --system --home-dir /opt/ --shell /usr/sbin/nologin +``` + +Nach dem Test **abschalten** (Abschnitt 7) — sonst laufen irgendwann fünf Dienste, die niemand +mehr zuordnen kann, und der nächste Test misst gegen fremde Last. + +### 4.4 Ports + +Vor dem Belegen prüfen: `ss -tlnp`. Belegte Ports stehen in Abschnitt 6. Wer einen Port dauerhaft +belegt, trägt ihn dort ein. + +### 4.5 Erhöhte Rechte + +`sudo` verlangt normalerweise ein Passwort. Für Testläufe kann es befristet freigeschaltet werden +(**ein Mensch, einmalig**): + +```bash +echo "richard ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/99-testing && sudo chmod 440 /etc/sudoers.d/99-testing +``` + +**Nach Abschluss wieder entfernen:** + +```bash +sudo rm /etc/sudoers.d/99-testing +``` + +Das hebt den Schutz für das Konto vollständig auf — vertretbar auf einer Test-VM hinter VPN, aber +nicht dauerhaft und niemals auf einer Produktivmaschine. + +### 4.6 GUI-Anwendungen ohne Bildschirm testen + +Braucht eine Anwendung X11, scheitert sie über SSH mit `XOpenDisplay failed`. Lösung: + +```bash +xvfb-run -a ./MeineAnwendung --irgendein-schalter +``` + +Für einen Test **mit sichtbarem Fenster** muss jemand am Desktop der VM sitzen (oder RDP nutzen, +Port 3389 ist offen) und Bildschirmfotos machen. + +--- + +## 5. Was hier nicht passieren darf + +1. **Keine Produktivdatenbank verbinden.** Hintergrunddienste schreiben oft ungefragt — bei + PolyTrader etwa synchronisiert der `MarketSyncService` selbständig Marktdaten. +2. **Keine echten Handels-/Zugangsdaten hinterlegen.** Keine privaten Schlüssel, keine + Live-API-Zugänge, keine Lizenzschlüssel für Produktivsysteme. +3. **Keine fremden Projektverzeichnisse oder Datenbanken anfassen.** +4. **Nichts Dauerhaftes hinterlassen**, was nicht in Abschnitt 6 steht. + +--- + +## 6. Belegung (bei Änderungen fortschreiben) + +**Datenbanken** + +| Datenbank | Benutzer | Projekt | seit | +|---|---|---|---| +| `polytrader_test` | `polytrader_test`@localhost | PolyTrader | 26.08.2026 | + +**Dienste** + +| Unit | Konto | Verzeichnis | Projekt | seit | +|---|---|---|---|---| +| `polytrader.service` | `polytrader` | `/opt/polytrader` | PolyTrader | 26.08.2026 | + +**Ports** (Stand 26.08.2026) + +| Port | Belegt durch | +|---|---| +| 22 | SSH | +| 3306 | MariaDB (nur localhost) | +| 3389 | RDP | +| 5000 | vorhandener Dienst (nur IPv6-localhost) | +| 631 | CUPS | + +**Nachträglich installiert:** MariaDB 11.8.6, Xvfb (beide am 26.08.2026 für PolyTrader). + +--- + +## 7. Aufräumen nach dem Test + +```bash +# Dienst abschalten und entfernen +sudo systemctl disable --now +sudo rm -f /etc/systemd/system/.service /etc/logrotate.d/ +sudo systemctl daemon-reload + +# Dateien +sudo rm -rf /opt/ ~/-test +sudo userdel + +# Datenbank (nur wenn nicht mehr gebraucht) +sudo mariadb -e "DROP DATABASE _test; DROP USER '_test'@'localhost';" +rm -f ~/._test_dbpw + +# sudo-Freigabe zurücknehmen +sudo rm -f /etc/sudoers.d/99-testing +``` + +Danach Abschnitt 6 nachziehen. + +--- + +## 8. Bekannte Einschränkungen + +- **Claude Code lässt sich auf dieser VM nicht betreiben.** Es blockiert die Maschine bis zum + Neustart; mehrere Reparaturversuche waren erfolglos, es wird auf ein Update gewartet. Agenten + arbeiten deshalb **über SSH von außen**. (Speichermangel ist **nicht** die Ursache — die + Maschine hat 31 GB, davon 25 GB frei.) +- **Verbindungs-Multiplexing funktioniert nicht mit Windows-OpenSSH** (siehe 2.3). +- **Die Systemzeitzone ist Testgegenstand.** Für realistische Servertests wird sie zeitweise auf + UTC gestellt (`sudo timedatectl set-timezone UTC`). Wer sie ändert, stellt sie danach zurück — + Standard hier ist `Europe/Berlin`. diff --git a/docs/pruefplaene/BEFUND-Linux-Betrieb-2026-08-26.md b/docs/pruefplaene/BEFUND-Linux-Betrieb-2026-08-26.md index 2976349..265d0b2 100644 --- a/docs/pruefplaene/BEFUND-Linux-Betrieb-2026-08-26.md +++ b/docs/pruefplaene/BEFUND-Linux-Betrieb-2026-08-26.md @@ -7,9 +7,10 @@ Roadmap: [A4a](../ROADMAP.md) Zeitzone `Europe/Berlin`. .NET SDK 10.0.111 mit Runtime 10.0.11 bereits vorhanden. Zugriff über SSH (WireGuard, Schlüssel-Authentifizierung). -> **Kernaussage: PolyTrader läuft auf Linux.** Build, Tests, Publish und Start funktionieren. -> Ein echter Fehler wurde gefunden und behoben. Der Durchgang ist **nicht vollständig** — für -> systemd-Betrieb, Oberfläche und Zeitzonen-Nachweis fehlen eine Datenbank und `sudo`. +> **Kernaussage: PolyTrader läuft auf Linux — als Dienst, mit Datenbank, mit echten Marktdaten.** +> Der Prüfplan ist **vollständig abgearbeitet** (Nachtrag ab Abschnitt 5). Drei Fehler gefunden, +> einer davon behoben. Offen bleibt nur die Sichtprüfung der Oberfläche, die einen Menschen am +> Bildschirm braucht. --- @@ -99,6 +100,11 @@ Modus überhaupt nutzen soll — deshalb hier nur vermerkt, nicht gebaut. ## 3. Nicht geprüft — und warum +> **Überholt.** Dieser Abschnitt beschreibt den Zwischenstand, bevor MariaDB und `sudo` +> verfügbar waren. Alles hier Aufgeführte wurde im **Nachtrag ab Abschnitt 5** nachgeholt — +> bis auf die Sichtprüfung der Oberfläche. Der Abschnitt bleibt als Verlaufsspur stehen. + + | Prüfpunkt | Fehlt | |---|---| | Betrieb **mit** Datenbank, Migrationen | Auf der VM läuft **keine** MySQL; der Datenbankhost ist nicht bekannt | @@ -128,3 +134,126 @@ Modus überhaupt nutzen soll — deshalb hier nur vermerkt, nicht gebaut. Prüfschritte pro Aufruf gebündelt. - **Speicher ist reichlich vorhanden** (31 GB, davon 25 GB frei). Die Vermutung, der Claude-Desktop-Absturz auf der VM könnte an Speichermangel liegen, ist damit **widerlegt**. + + +--- + +# Nachtrag: vollständiger Durchgang + +Nach Einrichtung von MariaDB und befristetem passwortlosem `sudo` wurde der Rest des Prüfplans +abgearbeitet. + +## 5. Betrieb mit Datenbank + +| Prüfpunkt | Ergebnis | +|---|---| +| **MariaDB** | 11.8.6 installiert — **genau die Version**, die in `DatabaseServerVersion` gepinnt ist. Datenbank `polytrader_test` mit eigenem Benutzer angelegt | +| **Migrationen** | Alle fünf DbContexts (Core, CopyTrading, ResolutionFarming, Supervisor, Accounting) melden „Done.". **21 Tabellen** mit den Präfixen `core_`, `ct_`/`mod_copytrading_`, `rf_`, `acc_` | +| **Start mit Datenbank** | Läuft vollständig durch: Core-Hydration abgeschlossen, `MarketSyncService` gestartet | +| **Echter Datenverkehr** | **100 Märkte von der Polymarket-API geholt und geschrieben**, beim zweiten Lauf 100 aktualisiert. HTTP, TLS, JSON-Verarbeitung und Datenbankzugriff funktionieren unter Linux | + +> Das ist der eigentliche Beweis: Die Anwendung *arbeitet* auf Linux, sie startet nicht nur. + +## 6. Dienstbetrieb (systemd) + +| Prüfpunkt | Ergebnis | +|---|---| +| **Dienst** | `active (running)`, 71,6 MB Speicher, 20 Tasks. Startet automatisch mit dem System | +| **`WorkingDirectory`-Falle (D-11)** | ✅ **Kein Problem.** Gezielt geprüft: `server_settings.xml` in `/opt/polytrader` mit Testzeitzone `America/New_York` angelegt — die Anwendung meldete genau diese Zone. Eine `find`-Suche über das gesamte Dateisystem fand **keine zweite** Datei. Die Unit setzt `WorkingDirectory` korrekt | +| **Nebenbefund** | `server_settings.xml` wird beim Start **nicht angelegt** — erst beim Speichern von Einstellungen. Ein frisch installierter Dienst läuft also mit Standardwerten und ohne Konfigurationsdatei | +| **Shutdown (SIGTERM)** | ✅ **0,08 Sekunden** — weit unter `TimeoutStopSec=45`. „Deactivated successfully", **kein `SIGKILL`** im gesamten Journal | +| **Neustart nach Absturz** | ✅ `kill -9` auf den Hauptprozess → `Restart=on-failure` greift, neue PID nach ~10 s | +| **Neustartschutz bei Konfigurationsfehler** | ✅ Verbindung entfernt → Status `failed`, **Exit-Code 78**, systemd meldet ihn als `78/CONFIG`. **Keine Neustartschleife.** Die verständliche Meldung steht im Journal. Damit wirkt der Fix aus B-1 im Dienstbetrieb nachweislich | +| **Dateirechte** | `master.key` `0600`, Eigentümer `polytrader` | + +## 7. Logrotate + +Regel mit **zwei Mustern** (wegen B-2) und `copytruncate` eingerichtet. Erzwungener Lauf: alle drei +Logdateien rotiert und komprimiert, Originale auf 0 Bytes gesetzt, **Dienst schreibt ohne +Unterbrechung weiter**. + +`copytruncate` ist hier zwingend: Die Anwendung hält die Logdatei offen und bekommt ein Umbenennen +nicht mit — sie würde sonst in die rotierte Datei weiterschreiben. + +## 8. Zeitzonen-Befund T2 — **belegt** + +Bisher nur behauptet, jetzt bewiesen. Systemzeitzone auf UTC gestellt, App-Anzeigezone auf +`Europe/Berlin`: + +``` +System UTC : 2026-08-26 20:04:51 +Berlin : 2026-08-26 22:04:51 + +Logzeile: [20:04:39] [Info] Anzeige-Zeitzone: Europe/Berlin +JSON-Zeile: {"ts":"2026-08-26T20:04:39.398+00:00", …} +``` + +**Der Widerspruch steht in derselben Zeile:** Die Anwendung meldet Berlin als Anzeigezone und +stempelt gleichzeitig mit UTC. + +**Betriebliche Folge:** Auf einem UTC-Server — dem Normalfall — zeigen alle Logs UTC, während die +Oberfläche Berliner Zeit anzeigt. Wer einen Vorfall von „22:30" sucht, findet ihn unter 20:30, und +zwischen Mitternacht und 2 Uhr sogar in der Datei des **Vortags**. Das macht Fehlersuche im +Ernstfall unnötig schwer. + +**Nicht behoben** — gehört zu T2 (Umstellung auf `Microsoft.Extensions.Logging`) und ist ein +eigener Schnitt. Die Systemzeitzone wurde nach dem Test auf `Europe/Berlin` zurückgestellt. + +## 9. Oberfläche unter Linux + +**Alle Fenster konstruieren fehlerfrei** (`--smoke-ui` unter `xvfb-run`): + +``` +[OK] core.start, core.dashboard, core.settings, core.jobs, core.terminal +[OK] copytrading.main, resolutionfarming.main, supervisor.main, accounting.main +[OK] ShellWindow konstruiert +[OK] ShutdownConfirmWindow konstruiert +[OK] Einstellungs-Editor: 7 Abschnitte, 17 Felder +[OK] Farbschema „Light": alle 27 Farben vorhanden +[OK] Farbschema „Dark": alle 27 Farben vorhanden +``` + +### B-4 · `--smoke-ui` braucht einen X-Server · offen + +Ohne Display scheitert die Konstruktionsprüfung mit `System.Exception: XOpenDisplay failed` aus +`AvaloniaX11Platform.Initialize`. Sie ist aber als **CI-Werkzeug** gedacht, und ein Build-Server +hat typischerweise keinen Bildschirm. + +**Zwei Wege:** + +1. **`xvfb-run -a` vorschalten** — funktioniert nachweislich (siehe oben), erfordert nur das Paket + `xvfb` im Build-Image. Ein Einzeiler im CI-Workflow. +2. `Avalonia.Headless` verwenden statt des X11-Backends. Sauberer, aber eine Codeänderung. + +Empfehlung: Weg 1, wenn A2 (CI-Runner) wieder aufgenommen wird — dann `xvfb` ins Image und +`--smoke-ui` als zusätzlichen Prüfschritt aufnehmen. Der Nutzen wäre erheblich: Die +Konstruktionsprüfung deckt neun Views und beide Farbschemata ab. + +### Noch offen: Sichtprüfung + +Die Anwendung wurde **nicht mit sichtbarem Fenster** geprüft — das braucht jemanden am Bildschirm +der VM. Schriftrendering, Spaltenbreiten und Dunkelmodus sehen unter GTK erfahrungsgemäß anders +aus als unter Windows. Das ist der verbleibende Rest von A1 auf der Zielplattform. + +--- + +## 10. Zustand der VM nach dem Durchgang + +**Bewusst stehen geblieben** (damit weitergetestet werden kann): + +- MariaDB 11.8.6 mit Datenbank `polytrader_test` +- Dienst `polytrader.service` unter `/opt/polytrader`, aktiv +- Logrotate-Regel `/etc/logrotate.d/polytrader` +- Xvfb (allgemein nützlich) +- Anleitung `~/TESTUMGEBUNG.md` + +**Zurückgestellt:** Systemzeitzone wieder `Europe/Berlin`. + +**Noch offen:** Die befristete `sudo`-Freigabe `/etc/sudoers.d/99-testing` ist **aktiv** und sollte +entfernt werden, sobald nicht mehr getestet wird: + +```bash +sudo rm /etc/sudoers.d/99-testing +``` + +Vollständige Aufräumbefehle: [TESTUMGEBUNG-Linux-VM.md](../TESTUMGEBUNG-Linux-VM.md) §7.