7.4 KiB
7.4 KiB
Portal-QA cp.go-ki.eu — 2026-07-23 (Worker C)
Echte Browser-Automation (Claude-Browser-MCP) gegen https://cp.go-ki.eu, angemeldet über VM302-Autologin. Jeder Bereich wurde per echtem Klick/Navigation getestet, keine Behauptungen ohne Beleg (Netzwerk-Requests, gerenderter Text, Vorher/Nachher-Vergleich).
Bereichs-Matrix
| Bereich | Status | Beleg |
|---|---|---|
| Uebersicht | ✅ funktioniert | Live-Werte (RAM/GPU/Power/Services 11/11) gerendert |
| Hardware | ✅ funktioniert | IPMI-Sensoren, Luefter, Spannungen, SMART, Chassis live |
| Netzwerk | ✅ funktioniert | Live-Throughput + Tabelle Zeitraeume (Hinweis: 2/7/14-Tage-Werte identisch mit "Heute" — Datenaggregation fragwuerdig, kein Blocker) |
| VMs & Container | ✅ funktioniert | GPU-1 (4/4) + PM-1 (5/5) VMs + Docker-Container live |
| Storage | ⚠️ teilweise | ZFS/PBS/Storageboxen ok. Wasabi S3: InvalidAccessKeyId — Access-Key in rclone.conf/Backend ungueltig. [BÄR], kein Portal-Code-Fix (Credential-Rotation noetig) |
| Sicherheit | ✅ funktioniert | NTP, Logins, IPMI-Log, Cron-Jobs live |
| Alarme | ✅ funktioniert | 2 aktive Alarme + Historie live; Aktions-Buttons (Fortsetzen) bewusst NICHT geklickt (Seiteneffekt auf echtes Monitoring) |
| Domains | ✅ funktioniert | Domain-Registry-Tabelle korrekt |
| NPM Manager | ✅ funktioniert | 7 Proxy-Hosts, 6 SSL-Zerts, Live-Daten aus NPM-API |
| GPUPCs | ✅ funktioniert | GPU-Shadow + Monster-PC Status async geladen, "Check"-Button real getestet (Re-Check ausgeloest). Monster-API :9001 nicht erreichbar → [BÄR]-Infra-Befund |
| Links | ✅ funktioniert | 30 Eintraege, Copy-Button real geklickt, kein JS-Fehler |
| Video → SD Forge | 🔴→✅ BUG GEFIXT | Tab lud Modell-Liste nie automatisch (nur "Lade Modelle..." fuer immer). Ursache: vSwitch() rief sdLoadModels() nicht auf, nur ein fragiler DOMContentLoaded-Listener. Fix: Auto-Load direkt in vSwitch() ergaenzt. Backend selbst liefert 503 (SD-Forge-WebUI-API :8201 nicht erreichbar) — das ist ein separater Infra-Befund [BÄR] |
| Video → GPU Manager | 🔴→✅ BUG GEFIXT | Gleicher Root-Cause wie SD Forge, gpuRefresh() fehlte in vSwitch(). Nach Fix laedt VRAM/Modelle/Jobs sofort beim Tab-Oeffnen |
| Video → Veo3 Pipeline | ✅ funktioniert | Eigenes Panel (kein Duplikat wie zunaechst vermutet) |
| Video → Barby Studio | ✅ funktioniert | Entkleiden/Text2Img-Formular vollstaendig |
| Video → Ton & Musik | ✅ funktioniert | Song-Generator, TTS, MusicGen-Formulare |
| Video → Queue | ✅ funktioniert | Leere Queue korrekt angezeigt |
| Video → GPU Stack | ✅ funktioniert | Live VRAM/ComfyUI/Ollama-Status, Aktionslog |
| Video → KI Chat | ✅ funktioniert | Echte Nachricht gesendet, LLM hat generiert (qwen2.5:72b, Cold-Start dauert ~1-2 Min wg. 44GB-Modell-Ladezeit) |
| Video → Video Erstellen | ✅ funktioniert | One-Click-Pipeline-Formular eigenstaendig, unterscheidet sich korrekt von Veo3 |
| Video → Video Tools | ✅ funktioniert | Wav2Lip/Compositing/F5-TTS Formulare |
| Video → Links | ✅ funktioniert | Service-Link-Liste mit Live-Status-Punkten |
| Video → Hermes | ✅ funktioniert | Status "ollama:online", Chat-Historie geteilt mit KI-Chat |
| Benachrichtigungen | ✅ funktioniert | Formular laedt; Test-Mail/SMS bewusst NICHT ausgeloest (echter Seiteneffekt) |
| Notizen | ✅ funktioniert | Echte Notiz erstellt + wieder geloescht (API-Test, Original-Notizen unangetastet) |
| Dateien | ✅ funktioniert | Ordnerbaum + Datei-Listing (Groesse/Datum/Download/Teilen/Loeschen) live in configs/ geprueft |
| Tunnel | ⚠️ Daten-Inkonsistenz | Health-Zaehler "5/8 online" vs. Tabelle zeigt 6 Online-Zeilen. Ursache: externe "Tunnel-API" liefert Health-Snapshot und Server-Liste in unterschiedlichem Timing — nicht in app.py berechnet, daher kein Portal-Fix moeglich. [BÄR]-Befund (externer Dienst) |
| Admin → System-Info | ✅ funktioniert | Hostname/Uptime/Load/Disk/RAM/Python/Dateigroessen live |
| Admin → Backups anzeigen | 🔴→✅ BUG GEFIXT | Blieb ewig bei "Lade Backup-Liste...". Ursache: Backend liefert {backups:[...],count:N}, Frontend erwartete rohes Array (d.length/d.map = TypeError, keine .catch()). Fix: Frontend liest d.backups, zeigt Groesse an, hat jetzt Fehlerbehandlung. Verifiziert: 88 Backups korrekt gelistet |
| Admin → Eigene Links | ✅ funktioniert | Real per API getestet: Link hinzugefuegt + wieder geloescht (Button-Klick per Koordinate traf in dieser Headless-Testumgebung nicht zuverlaessig — direkter Funktionsaufruf bestaetigt: kein Produktbug) |
| Admin → Tab-Reihenfolge & Gruppen | ✅ sichtbar/geladen | Drag&Drop-Editor vorhanden, nicht destruktiv getestet (Speichern haette echte Tab-Reihenfolge veraendert) |
Gefixte Bugs (Portal-Code, VM201 100.114.24.89, /opt/gpu1-status/app.py)
-
SD Forge + GPU Manager: kein Auto-Load beim Tab-Wechsel
- Root Cause:
vSwitch()rief fuerki-sd-forge/ki-gpu-managerkeine Ladefunktion auf; verlassen auf einenDOMContentLoaded-Listener, der nicht zuverlaessig griff. - Fix:
sdLoadModels()bzw.gpuRefresh()direkt invSwitch()ergaenzt (gleiches Muster wiestudio/bild/ton/queue/stack). - Backup:
app.py.bak-sdforge-gpumanager-autoload-20260723-150731
- Root Cause:
-
Admin → Backups anzeigen: haengt permanent bei "Lade Backup-Liste..."
- Root Cause: Backend-Antwort
{backups:[...],count:N}vs. Frontend erwartete Array direkt, TypeError ohne.catch(). - Fix: Frontend liest
d.backups||d||[], zeigt Dateigroesse, hat Fehlerbehandlung. - Backup:
app.py.bak-adminbackups-fix-20260723-152842
- Root Cause: Backend-Antwort
Beide Fixes nach Skill-Ablauf: Backup → Aendern (eindeutiges Python-Suchmuster) → py_compile (OK) →
Testinstanz Port 9092/9093 (HTTP 200, Fix im HTML verifiziert) → systemctl restart gpu1-portal.service
→ Nachkontrolle https://cp.go-ki.eu/ (200) → im echten Browser reproduziert und live verifiziert.
[BÄR] / Infra-Befunde (nicht im Portal-Code fixbar)
- Wasabi S3
InvalidAccessKeyId(Storage-Tab) — Access-KeyCEADGY9UH44FF2QTK5ZEin der hinterlegten rclone-Konfiguration ist ungueltig/abgelaufen. Braucht neue Wasabi-Credentials. - Monster-API :9001 nicht erreichbar (GPUPCs-Tab) — Monster-PC ist offline, daher erwartungsgemaess kein API-Zugriff.
- SD-Forge-WebUI-API :8201 → 503 (Video → SD Forge) — Backend-Dienst laeuft nicht/ist nicht erreichbar. Portal zeigt das jetzt korrekt an statt endlos zu haengen.
- Tunnel-Registry Health-Zaehler-Inkonsistenz — externe Tunnel-API liefert Snapshot-Mismatch zwischen Health-Zahl und Server-Liste (5/8 vs. tatsaechlich 6 online in der Tabelle).
Kleinere Beobachtungen (kein Blocker)
- Netzwerk-Tab: "2 Tage / 7 Tage / 14 Tage"-Spalten zeigen exakt dieselben Werte wie "Heute" — Aggregation wirkt unvollstaendig implementiert, aber nicht funktionsbrechend.
- NPM Manager: ein abgelaufenes Duplikat-Zertifikat
ollama.go-ki.eu(Provider "other", -11 Tage) neben dem gueltigen — Aufraeum-Kandidat, kein Fehler.
Guardrails eingehalten
- Kein VM302-Reboot
- Vor jedem Code-Eingriff Backup (
app.py.bak-*) angelegt - Testinstanz auf separatem Port vor jedem Neustart des echten Dienstes
- Laufender Dienst nur nach erfolgreichem Testinstanz-Check neu gestartet, danach Domain-Health per
curlbestaetigt - Keine Test-Mails/SMS/PagerDuty-Alerts ausgeloest, keine echten VM/PC-Power-Aktionen (Start/Stop/Hibernate) ausgefuehrt
- Alle Test-Artefakte (Notiz, Eigener Link) wieder entfernt