arnol/homelab-showcase
Watch
1
0
Fork
You've already forked homelab-showcase
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Showcase nachgezogen: restliche Portfolio-Dateien auf aktuellen Stand

arnol 2026-08-07 19:05:44 +02:00
commit 704e8c1aaa
1 changed files with 45 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

45
02-AdGuard-CT100.md

@ -144,6 +144,51 @@ dns:
**Manueller Schritt an der Fritzbox:** Heimnetz → Netzwerk → Netzwerkeinstellungen → IPv6-Adressen bearbeiten → DNS-Server → eigenen DNSv6-Server eintragen. **Die ULA-Adresse verwenden** (`fd23:...`, per `ip -6 addr show eth0` im Container ermitteln — steht als "scope global dynamic mngtmpaddr"), **nicht** die GUA (`2a02:...`) — die ULA bleibt stabil, die GUA kann sich bei einem ISP-Präfixwechsel ändern und die Konfiguration stillschweigend brechen.
## 9. Query-Log-Retention (der "stille Wachser")
Der netzwerkweite Resolver protokolliert **jede** DNS-Anfrage aus dem gesamten LAN — genau der
Log-Typ, der unbemerkt wächst, weil niemand ihn täglich ansieht. Bei diesem Durchlauf gefunden:
`querylog.json` bei mehreren hundert MB, Retention stand auf `interval: 90d` (Standard-Vorschlag von
AdGuard Home, nie bewusst gesetzt).
```yaml
# /opt/AdGuardHome/AdGuardHome.yaml
querylog:
interval: 7d # vorher: 90d
```
```bash
pct exec 100 -- systemctl stop AdGuardHome
pct exec 100 -- sed -i 's/interval: 90d/interval: 7d/' /opt/AdGuardHome/AdGuardHome.yaml
pct exec 100 -- systemctl start AdGuardHome
```
⚠️ **NICHT TUN: nach dem Ändern des Intervalls erwarten, dass die alte, große Datei sofort
schrumpft.** AdGuard rotiert beim nächsten Start die bisherige Datei nach `querylog.json.1`
(Standard-Log-Rotationsmuster) und beginnt eine neue, leere `querylog.json` — die Altlast
bleibt als `.1`-Datei liegen, bis der *nächste* Rotationszyklus sie ersetzt. Für sofortige
Platzrückgewinnung die `.1`-Datei manuell löschen (reine Altdaten, keine laufende Datei):
`pct exec 100 -- rm /opt/AdGuardHome/data/querylog.json.1`. DNS-Auflösung/Blocking läuft davon
komplett unberührt weiter (`dig`-Verifikation direkt danach: Blocking + normale Auflösung beide
sofort wieder da).
### Nachtrag: `size_memory` täuscht einen hängenden Log vor
AdGuards `querylog.size_memory` (Standard 1000) puffert Einträge im Arbeitsspeicher und schreibt sie
erst gebündelt auf die Platte — die Datei auf der Platte kann deshalb minutenlang unverändert wirken,
obwohl AdGuards eigene Web-UI (die direkt aus dem Live-Puffer liest) völlig normal weiterläuft. Kein
Bug, keine Aktion nötig — vor einem Neustart erst im UI selbst gegenprüfen, nicht nur die Datei-`mtime`.
**Realer Vorfall, unabhängig davon:** `querylog.json` wuchs innerhalb weniger Tage deutlich schneller
als üblich, und der AdGuard-Prozess peakte dabei nahe ans Container-Speicherlimit heran. Ursache:
**nicht** ein AdGuard-Problem selbst, sondern ein Notify-Flood eines separaten Docker-Image-Watchers
auf dem Monitoring-Container (siehe `08-monitoring.md`) — die Registry-Abfragen dieses Watchers allein
machten einen Großteil der geloggten Zeilen aus, zeitlich exakt deckungsgleich mit dem Vorfall. Nach
dessen Behebung fiel die Anfragerate um mehr als eine Größenordnung. **Lehre:** ein
Ressourcen-Ausreißer bei AdGuard muss nicht an AdGuard selbst liegen — erst per `IP`/`QH`-Auswertung
des Query-Logs den tatsächlichen Verursacher finden (`python3` über die JSON-Zeilen, `Counter` nach
Client und Domain), bevor an CPU/RAM-Zuteilung gedreht wird.
## Verifikation
```bash