diff --git a/STATUS.md b/STATUS.md index 523bd9a..fa3ad72 100644 --- a/STATUS.md +++ b/STATUS.md @@ -2,13 +2,13 @@ -## Issues (57 open, 42 closed) +## Issues (56 open, 43 closed) -Verteilung: M1 11 · M2 16 · M3 4 · M4 11 · M5 15 +Verteilung: M1 10 · M2 16 · M3 4 · M4 11 · M5 15 Bedeutung der Meilensteine: siehe [roadmap.md](roadmap.md). -### M1 (11) +### M1 (10) | Issue | Priorität | Status | Title | |---|---|---|---| @@ -22,7 +22,6 @@ Bedeutung der Meilensteine: siehe [roadmap.md](roadmap.md). | [0103](docs/issues/0103-wiki-zugang-ohne-gruppe-endet-stumm.md) | medium | open | Wiki: Anmeldung ohne Gruppe endet stumm — `wiki-anwender` hat null Mitglieder | | [0004](docs/issues/0004-overmind-02-e1000e-nic-hang-beobachtung-nach.md) | low | waiting | OVERMIND-02: e1000e-NIC-Hang — Beobachtung nach EEE-Fix + Firmware-Update | | [0072](docs/issues/0072-gitops-34-dsgvo-datenschutz-compliance-konkretisieren.md) | low | open | DSGVO/Datenschutz-Compliance konkretisieren | -| [0077](docs/issues/0077-gitops-42-grafana-dashboard-fuer-clamav-scan-ergebnisse.md) | low | open | Grafana-Dashboard für ClamAV-Scan-Ergebnisse (Issue #19) | ### M2 (16) diff --git a/docs/issues/0002-game-01-host-von-cfgmon-aus-nicht-erreichbar-2.md b/docs/issues/0002-game-01-host-von-cfgmon-aus-nicht-erreichbar-2.md index 746c09f..54d4293 100644 --- a/docs/issues/0002-game-01-host-von-cfgmon-aus-nicht-erreichbar-2.md +++ b/docs/issues/0002-game-01-host-von-cfgmon-aus-nicht-erreichbar-2.md @@ -65,3 +65,42 @@ Neuer Silence gesetzt (sorb, 2026-08-15): **ID `3c8f1a2e`**, gültig bis **2026- ⚠️ **Damit ist der 2026-09-14 die faktische Frist dieses Issues** — nicht nur eine Aufräumnotiz. + +## Gemessen 2026-08-20 — der Host ist privat da, die Exporter sind es nicht + +Die Empfehlung von 2026-08-01 („in den vSwitch aufnehmen") ist **umgesetzt**: Der Host +liegt im privaten Netz unter **10.0.0.4**. Gemessen aus einem Pod im matrix-Cluster, +mit Kontrollen, damit ein stiller Fehlschlag nicht wie ein Befund aussieht: + +| Ziel | Ergebnis | +|---|---| +| `10.0.0.4:22 / :80 / :443` | **offen** — Host im vSwitch, privat erreichbar | +| `10.0.0.4:9100` (node-exporter) | zu | +| `10.0.0.4:8080` (cadvisor) | zu | +| Kontrolle `10.0.0.3:3100` (CFGMON/Loki) | `ready` — privater Egress des Testpods funktioniert | +| Kontrolle öffentliches Ziel | erreichbar — es ist keine NetworkPolicy | + +**Damit ist die Frage „genügt eine Umstellung der Targets auf die private IP?" +beantwortet: nein.** Die Exporter lauschen nicht auf der privaten Schnittstelle — genau +die Zusatzbedingung, die dieses Issue oben vermutet hat („Exporter binden nur +127.0.0.1"). Eine reine Ziel-Änderung in `prometheus.yml` zeigte danach auf geschlossene +Ports; der Alarm bliebe, nur die Adresse wäre eine andere. + +**Was tatsächlich zu tun ist**, in dieser Reihenfolge: + +1. Auf dem Game-Host die beiden Exporter an die private Adresse binden — node-exporter + `--web.listen-address=10.0.0.4:9100`, cadvisor entsprechend. Nicht auf `0.0.0.0`: + Das öffnete sie wieder öffentlich, was dieses Issue ausdrücklich vermeiden will. +2. Erst danach in `threadnet-operating:monitoring/prometheus/prometheus.yml` die Targets + von `157.90.155.206` auf `10.0.0.4` umstellen (Zeilen 49–58). +3. Gegenprobe aus dem Cluster oder von CFGMON, dass die Ports antworten — **vor** dem + Deploy, sonst tauscht man einen stillen Alarm gegen einen anderen. + +Schritt 1 liegt auf dem Game-Host und damit außerhalb dessen, was aus diesem Repo +erreichbar ist. + +⚠️ Nicht geprüft werden konnte der **Laufzeitzustand** der Alarme: Durch den +Entwicklungstunnel zeigen `cfgmon.lab` und `git.lab` beide auf `10.58.73.17`, und die +dort antwortende Prometheus-Instanz führt andere Jobs — sie ist nicht der +operating-Stack. Ob die `TargetDown`-Alarme seit dem Ablauf der Silences (2026-08-04) +tatsächlich alle vier Stunden feuern, ist deshalb offen. diff --git a/docs/issues/0077-gitops-42-grafana-dashboard-fuer-clamav-scan-ergebnisse.md b/docs/issues/0077-gitops-42-grafana-dashboard-fuer-clamav-scan-ergebnisse.md index 22ad8be..d420c1d 100644 --- a/docs/issues/0077-gitops-42-grafana-dashboard-fuer-clamav-scan-ergebnisse.md +++ b/docs/issues/0077-gitops-42-grafana-dashboard-fuer-clamav-scan-ergebnisse.md @@ -1,7 +1,7 @@ --- type: issue id: "0077" -status: open +status: done created: 2026-07-29 milestone: M1 priority: low @@ -30,3 +30,53 @@ Kein Server-seitiger Code nötig, rein Grafana/Loki-Dashboard-Arbeit. --- *Migriert aus Gitea `sorb/axion1337.chat-gitops#43` — dort erstellt am 2026-07-29 von sorb.* + +## Umgesetzt 2026-08-20 — mit zwei Korrekturen am eigenen Text + +Dashboard **„ClamAV — blockierte Inhalte"** liegt in +`threadnet-operating:monitoring/grafana/dashboards/security/clamav-blocks.json` +(Commit `7ee42f9`, uid `threadnet-clamav`, Ordner *Security*). Provisionierung +greift automatisch — kein Handgriff in der Oberfläche. + +### Der vorgeschlagene Selektor hätte nie funktioniert + +Das Issue schlägt `{app="synapse-main"}` vor. **Das Label `app` existiert in dieser +Loki nicht.** Gemessen an der laufenden Instanz (`10.0.0.3:3100`, erreichbar nur aus dem +Cluster): Vorhanden sind `compose_project, compose_service, container, instance, job, +service_name`; Cluster-Logs liegen unter + +``` +job="loki.source.kubernetes.k8s_logs" instance="/:" +``` + +Die vorgeschlagene Query hätte ein dauerhaft leeres Panel ergeben — grün, ohne je etwas +zu zeigen. Genau deshalb sind **alle acht Queries** des Dashboards vor dem Commit gegen +die echte Loki gelaufen, nicht nur geschrieben. + +⚠️ Nebenbei: Über den Entwicklungstunnel antwortet `cfgmon.lab:3100` eine **andere** +Loki (`host=dokploy-host`, ein einziger Job `system`). Wer von außen prüft, misst leicht +die falsche Instanz — die richtige ist nur aus dem Cluster erreichbar. + +### Der Issue-Text kennt nur die halbe Wahrheit + +Er stammt aus der Zeit vor dem Client-seitigen Scannen und nennt nur das Synapse-Modul. +Heute gibt es zwei Quellen, und die zweite ist die wichtigere: + +| Quelle | Meldung | Reichweite | Treffer (7 Tage) | +|---|---|---|---| +| `clamav-http-scanner` | `ClamAV flagged an upload/download: ` | Senden **und** Empfangen, **auch verschlüsselte Räume** | **7** | +| Synapse-Modul | `ClamAV rejected an upload: ` | nur unverschlüsselte Uploads | 0 | + +Die Null beim Modul ist kein Fehler, sondern die Folge davon, dass der Client den Upload +gar nicht erst startet. Ein Dashboard nur auf dem Modul hätte „ClamAV blockiert nichts" +suggeriert, während in Wirklichkeit sieben Dateien abgewiesen wurden. + +### Ein Panel, das im Issue nicht stand + +**Fail-open.** Ist `clamd` nicht erreichbar, lässt der Scanner Dateien bewusst durch +(`ClamAV scan failed … treating file as clean`). Jeder Treffer ist eine **ungeprüft +durchgelassene** Datei — deshalb rot ab dem ersten. Aktueller Stand: 0 in sieben Tagen, +der Scanner war durchgehend erreichbar. + +**Panels:** drei Kennzahlen (Client / Modul / Fail-open), Verlauf über Zeit mit allen +drei Reihen, Aufschlüsselung nach Signatur, Rohzeilen beider Quellen.