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 (<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 <noreply@anthropic.com>
246 lines
8.1 KiB
Markdown
246 lines
8.1 KiB
Markdown
# 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_<projekt> -N "" -C "<projekt>@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_<projekt>.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 '<INHALT DER .pub-DATEI>' >> ~/.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_<projekt>
|
|
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" > ~/.<projekt>_test_dbpw && chmod 600 ~/.<projekt>_test_dbpw
|
|
|
|
sudo mariadb -e "CREATE DATABASE IF NOT EXISTS <projekt>_test CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
|
|
CREATE USER IF NOT EXISTS '<projekt>_test'@'localhost' IDENTIFIED BY '$PW';
|
|
GRANT ALL PRIVILEGES ON <projekt>_test.* TO '<projekt>_test'@'localhost';
|
|
FLUSH PRIVILEGES;"
|
|
```
|
|
|
|
| Was | Schema | Beispiel |
|
|
|---|---|---|
|
|
| Datenbank | `<projekt>_test` | `polytrader_test` |
|
|
| Benutzer | `<projekt>_test`@`localhost` | `polytrader_test` |
|
|
| Passwortdatei | `~/.<projekt>_test_dbpw` (Rechte 600) | |
|
|
|
|
Die Rechte enden **an der eigenen Datenbank** — `GRANT ALL ON <projekt>_test.*`, nie global.
|
|
|
|
### 4.2 Verzeichnisse
|
|
|
|
| Zweck | Ort |
|
|
|---|---|
|
|
| Quellcode | `~/RiderProjects/<projekt>` |
|
|
| Publish/Testlauf im Benutzerkontext | `~/<projekt>-test` |
|
|
| Installation als Dienst | `/opt/<projekt>` |
|
|
|
|
### 4.3 systemd-Dienste
|
|
|
|
Unit-Name = Projektname: `<projekt>.service`. Eigenes Dienstkonto je Projekt:
|
|
|
|
```bash
|
|
sudo useradd --system --home-dir /opt/<projekt> --shell /usr/sbin/nologin <projekt>
|
|
```
|
|
|
|
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 <projekt>
|
|
sudo rm -f /etc/systemd/system/<projekt>.service /etc/logrotate.d/<projekt>
|
|
sudo systemctl daemon-reload
|
|
|
|
# Dateien
|
|
sudo rm -rf /opt/<projekt> ~/<projekt>-test
|
|
sudo userdel <projekt>
|
|
|
|
# Datenbank (nur wenn nicht mehr gebraucht)
|
|
sudo mariadb -e "DROP DATABASE <projekt>_test; DROP USER '<projekt>_test'@'localhost';"
|
|
rm -f ~/.<projekt>_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`.
|