Ops AI Showcases

# ManualTestDnsEdge — Analyse
Status: firing · Severity critical
edge: metrics-ui
host: metrics-guest

## 1. Was passiert?
Der Smoke-Test für DNS und Host-Erreichbarkeit von metrics-ui schlägt fehl.
Die Virtualisierungsebene ist intakt: der Plattform-Gast metrics-guest läuft,
es liegen keine Hypervisor-Shutdown-Logs vor. Read-only Host-Triage bestätigt
`systemctl is-system-running: running`.

## 2. Wahrscheinliche Ursache
1. **DNS oder Edge-Pfad:** Gast ist hoch, SSH-RO geht — der Smoke (HTTPS am Edge)
   scheitert trotzdem. Problem liegt eher an Auflösung/Proxy als an Power-State.
2. **Nebenbefund Zertifikat:** Journal zeigt abgelaufene Client-Zertifikate —
   relevant für Agenten, nicht zwingend für den Edge-Smoke.
3. **Dienst trotz OS up:** Web-UI lokal down, während das OS läuft.

## 3. Runbook — Fix-Schritte
1. DNS-Auflösung für die Edge-Rolle prüfen.
2. Upstream-Health am Gast (Listen-Port / Ready-Endpoint).
3. Smoke erneut auslösen — Apply bleibt Mensch + Snapshot-Gate.

## 5. Nicht tun
- Gast blind neu starten, obwohl Power-State bereits running ist.
- Hypervisor neu booten ohne Hypervisor-Evidenz.
- App-Config ändern, bevor Edge vs. Upstream getrennt ist.

LLM Follow-up
CRIT · ManualTestDnsEdge
edge: metrics-ui / host: metrics-guest

Hypothese
Gast läuft; Smoke scheitert eher an DNS/Edge-Pfad oder lokalem Upstream —
nicht am Hypervisor-Power-State. Abgelaufene Client-Zertifikate sind Nebenbefund.

Nächster Check
1. DNS für metrics-ui prüfen
2. Upstream Ready am metrics-guest
3. Smoke erneut — kein Blind-Apply

Vollbericht: E-Mail [Homelab Analyse]

# ManualTestDnsOps — Analyse
Status: resolved · Severity critical
edge: secrets-ui
host: secrets-guest

## 1. Was passiert?
DNS/Host-Smoke ist wieder grün. Der Gast läuft; keine Shutdown-Logs.
Read-only Triage zeigt aber wiederkehrende Fehler einer Snapshot-Unit
und abgelaufene Client-Zertifikate — Smoke ok, Betriebshygiene nicht.

## 2. Wahrscheinliche Ursache
1. **Transienter Smoke / Test-Trigger:** resolved + Gast running widerspricht
   einem echten Dauerausfall.
2. **Hintergrund:** Snapshot-Job und Zertifikatsablauf können später echte
   Alerts auslösen, erklären den resolved-Status aber nicht.

## 5. Nicht tun
- Edge- oder App-Config debuggen, solange Smoke grün und Gast stabil ist.
- Snapshot-Job-Fehler dauerhaft ignorieren (Datenrisiko).

LLM Follow-up
CRIT · ManualTestDnsOps
edge: secrets-ui / host: secrets-guest

Hypothese
Smoke wieder ok. Nebenbefunde (Snapshot-Unit, Zertifikate) verdienen Follow-up —
sind aber nicht die Ursache des resolved-Status.

Nächster Check
1. Snapshot-Unit Status/Logs
2. Zertifikatsrotation planen
3. Kein Hypervisor-Reboot ohne Evidenz

Vollbericht: E-Mail [Homelab Analyse]

# WazuhRule40112 — Analyse
Status: resolved · Severity critical
edge: git-ui
host: git-guest

## 1. Was passiert?
SIEM meldet erfolgreichen Root-SSH-Login aus dem Ops-Netz. Evidenz zeigt zuvor
`Certificate invalid: expired`, danach akzeptierten Public-Key. Gast läuft stabil;
Ressourcen grün. Parallel OIDC-Init-Fehler (Upstream 502) — separat vom SSH-Event.

## 2. Wahrscheinliche Ursache
1. **Abgelaufenes Client-Zertifikat + Fallback-Key:** Login aus Ops-Netz nach
   fehlgeschlagenem Zertifikatsversuch.
2. **Geplanter Wartungs-Login:** Quelle im Management-Pfad, Alert resolved.
3. **OIDC 502 unklar korreliert:** IdP-Upstream prüfen, nicht SSH blind sperren.

## 5. Nicht tun
- Gast neustarten — löst weder Zertifikat noch OIDC-502.
- SSH aus dem Ops-Netz sperren ohne Bestätigung, dass der Login illegitim war.
- Git-App-Config ändern, bevor der IdP-Upstream geprüft ist.

LLM Follow-up
CRIT · WazuhRule40112
edge: git-ui / host: git-guest

Hypothese
Root-SSH aus Ops-Netz nach abgelaufenem Client-Zertifikat; Alert resolved.
OIDC-502 ist paralleler Nebenbefund am IdP-Upstream.

Nächster Check
1. Zertifikatsstatus / Rotation
2. IdP Discovery/Upstream Health
3. Kein Blind-Block der Ops-Quelle

Vollbericht: E-Mail [Homelab Analyse]

# Grafana Alloy Upgrade 1.17.1 → 1.18.0

Minor-Sprung mit **echten Breaking Changes** in der OTel-Konfiguration.
Ohne Config-Anpassung startet Alloy nicht oder verhält sich unerwartet.

## 1. Upgrade-Pfad
- v1.18.0

## 2. Breaking Changes / Migrationen (kumulativ)

| Breaking Change | Release | Was tun? |
| --- | --- | --- |
| OTel HTTP Timeouts: Default von `0s` auf Upstream-Limits (`idle/read 1m`, `write 30s`) | v1.18.0 | Explizit `0s` setzen, falls unbegrenzt gewünscht |
| Kafka `resolve_canonical_bootstrap_servers_only` ist No-Op | v1.18.0 | Argument entfernen; Bootstrap-Adressen direkt auflösbar halten |
| Splunk HEC `batcher`-Block entfernt | v1.18.0 | Felder nach `sending_queue.batch` verschieben |

## 4. Homelab-Risiko
**Mittel bis hoch** wegen Config-Breaks. Snapshot vor Apply. Kurze Downtime beim Restart.
Falsche Migration → Alloy startet nicht. Kein Blind-`podman pull` — SoT bump zuerst.

# Keycloak Upgrade 26.2 → 26.7.0

Fünf Minor-Releases auf einmal: Security, WebAuthn/Passkeys, Deprecations,
Template-Änderungen. Direktupgrade möglich — aber kumulativ prüfen.

## 1. Upgrade-Pfad
26.2 → … → 26.7.0 (Patches zwischen den Minors mit abgedeckt)

## 2. Breaking Changes / Migrationen (Auswahl)

| Breaking Change | Release | Was tun? |
| --- | --- | --- |
| Neues `locale`-Feld in User-Profile-Registration | 26.3.x | Custom Themes prüfen |
| Twitter-IdP deprecated | 26.7.0 | Social-Login ersetzen/entfernen |
| Fine-Grained Admin Permissions v1 / Token Exchange v1 deprecated | 26.7.0 | Clients/Provider migrieren |
| Client-Initiated Renegotiation default aus | 26.4.x | Nur bei Bedarf explizit wieder an |
| DB-Migration kann bei großen Realms lange dauern (ohne Progress-UI) | kumulativ | Snapshot/PBS; Logs beobachten |

## 4. Homelab-Risiko
**Mittel bis hoch.** Snapshot vor Apply Pflicht. Geplante Downtime für DB-Migration.
Themes und Custom Provider vor dem Sprung in Staging prüfen — kein Autopilot-Apply.

# Forgejo Upgrade 15.0.4 → 16.0.2

**Major-Upgrade.** API-/Config-Breaks und automatische DB-Migration beim Start.

## 1. Upgrade-Pfad
- v15.0.5 / v15.0.6 (letzte 15er Patches)
- v16.0.0 (Major, Breaking)
- v16.0.1 → v16.0.2 (Stabilisierung)

## 2. Breaking Changes / Migrationen (kumulativ)

| Änderung | Release | Was tun? |
| --- | --- | --- |
| API-Änderungen | v16.0.0 | Integrationen/Skripte gegen v16 prüfen |
| Legacy-Features entfernt/deprecated | v16.0.0 | `app.ini` bereinigen |
| DB-Schema-Migration beim Start | v16.0.0 | Backup/Snapshot; genug Disk; Logs beobachten |

## 4. Homelab-Risiko
Kurze Downtime unvermeidbar. Bei großen Repos länger. **Snapshot vor Apply.**
Stop → Backup → Binary/Image → Start (Migration) → Smoke. Fail → Snapshot-Rollback.

# fleet-control — OS-Update-Zusammenfassung (Pending)
Kurz: **19 Pakete** → keine Security-Flags, kein Reboot. Risiko **mittel**
(Score 20), Signal auf PostgreSQL-Core.

## 1. Was ändert sich? (Auswahl)
| Paket | Aktuell | Kandidat | Repo |
| --- | --- | --- | --- |
| postgresql / -server / -contrib | 13.23-2.el9_7 | 13.23-3.el9_8 | appstream |
| ruby / ruby-libs | 3.0.7-166.el9_7 | 3.0.7-167.el9_8 | appstream |
| rubygems / bundler / … | Revisions-Bump | Revisions-Bump | appstream |

Nur Revision (`-2` → `-3`), keine Major-Bumps erkennbar.

## 2. Risiken
| Signal | Detail |
| --- | --- |
| `core_packages` | postgresql-* |
| `security_count` | **0** |
| `risk_level` | mittel (20) |

## 3. Empfehlung
> Snapshot + Apply jetzt — Revisionsupdates, kein Reboot; trotzdem Snapshot-Gate.

# tutor-guest — OS-Update-Zusammenfassung (Applied / History)
**Kurz:** 114 Paketupdates, davon 40 Sicherheits-Updates, kein Reboot —
Risikostufe **hoch** (Score 100).

| Anzahl Pakete | Sicherheits-Updates | Reboot notwendig? |
| --- | --- | --- |
| 114 | 40 | Nein |

## 1. Änderungen
1. **Kern- und Laufzeitlibs** — glibc (moderate), glib2/expat/libarchive/libnghttp2 (important)
2. **Auth-Stack** — krb5-libs, pam/pam-libs
3. **Sprachen** — python3 / python3-libs Security
4. **tzdata** — major bump

## 2. Risiken
| Signal | Erklärung |
| --- | --- |
| `security_packages=40` | viele Advisories im Batch |
| `large_batch=114` | höhere Fehlerwahrscheinlichkeit |
| `severity_important:*` | u. a. expat, glib2, krb5, pam, python3 |

## 3. Empfehlung
> **Snapshot + Apply** — Security hoch, kein Reboot nötig; vorher Guest-Snapshot.
Apply bleibt Mensch hinter Snapshot-Gate (kein Autopilot).

# overlay-gateway — OS-Update-Zusammenfassung (Applied / History)
**Kurz:** 3 Pakete, 0 bestätigte Security, kein Reboot. Risiko **low** (Score 15).

## 1. Was ändert sich?
1. `openssh`, `openssh-clients`, `openssh-server`: 9.9p1-23 → 9.9p1-25
2. Quelle: baseos
3. Keine weiteren Kern-/Laufzeitpakete im Batch

## 2. Risiken
| Signal | Detail |
| --- | --- |
| `core_packages=openssh*` | kritischer Dienst, aber keine belegten Advisories im Manifest |
| `security_count=0` | als Non-Security klassifiziert |
| `risk_level` | low (15) |

## 3. Empfehlung
> Snapshot + Apply — kleiner Batch; History bleibt im Dashboard als Last Applied sichtbar.