86092cf08a
Two of the Operator's five split children from the audit remediation intent were correctly sent "zurück zur Planung" by Review, both for the same root cause: the Builder cited "docs/review/reviewer- systemaudit-2026-09-01.md Finding F3/F4" as justification, but that document exists and has nothing to do with either finding -- the real source was docs/research/full-system-aufit.md (2026-09-11). Fixed directly rather than re-running Builder and risking the same fabrication again: - hosts/nix-gc.nix: nix.gc.dates is now per-host again (blunix=daily, fixing the actual disk-space incident; pinix=weekly, preserving the SD-card-wear reasoning the file's own comment already documented, which a blanket "daily" for both silently violated). - forgejo.nix: corrected the Codeberg-mirror-disable comment's citation to the real source document. Also, for the two "no_changes" children (Builder correctly declined rather than guess): - traefik/default.nix + fail2ban.nix: LLDAP's own failed-login log line carries no client IP at all (verified live), so no filter against it could ever ban anything -- added Traefik accessLog (Common Log Format, filtered to 4xx/5xx only) and a fail2ban jail matching that instead. The failregex is derived from CLF structure, not a live-captured line (accessLog was just turned on in this same change) -- flagged in-file to re-verify against a real 401 entry after deploy, before trusting it in production. - GoToSocial data removal (gotosocial-orphaned-data-cleanup) still needs a manual `rm -rf /var/lib/gotosocial` -- confirmed orphaned (no gotosocial.service unit or module on blunix, 117M, matches the audit), but deleting it is outside what this session does unprompted. agents/builder.md: added an explicit rule against citing an unverified source/finding in comments or commit messages, naming this exact incident, so the underlying behavior (not just these two symptoms) doesn't recur. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016w25covboHfcYuLXBAvX3g
55 lines
2.2 KiB
Nix
55 lines
2.2 KiB
Nix
{ config, ... }:
|
|
let
|
|
# Free-Space-Schwellen und Rückhaltedauer aus dem Phase-1-Preflight
|
|
# (docs/intent/nix-gc-plattform.md, 2026-09-05): blunix hat kaum Reserve
|
|
# (29G Store auf einer 37G-Platte), pinix deutlich mehr Puffer, läuft
|
|
# aber auf einer SD-Karte -- deshalb dort weiterhin nur wöchentliches GC
|
|
# statt eines aggressiveren Zeitplans (SD-Karten-Schreibverschleiß).
|
|
#
|
|
# gc.dates ist seit docs/intent/nix-gc-daily.md (2026-09-11,
|
|
# docs/research/full-system-aufit.md Punkt 1: 208 nixos-rebuild-Läufe
|
|
# und 34 Generationen in <48h auf blunix, "No space left on device")
|
|
# ebenfalls pro Host statt eines einzigen gemeinsamen Werts: nur blunix
|
|
# bekommt den täglichen Zeitplan, der genau dieses Problem behebt;
|
|
# pinix behält die o.g. SD-Karten-Begründung unverändert bei. Ein
|
|
# vorheriger Versuch, dates für beide Hosts gemeinsam auf "daily" zu
|
|
# setzen, widersprach genau diesem Kommentar und wurde im Review
|
|
# zurückgewiesen.
|
|
perHost = {
|
|
blunix = {
|
|
minFreeGiB = 1;
|
|
maxFreeGiB = 3;
|
|
gcDates = "daily";
|
|
};
|
|
pinix = {
|
|
minFreeGiB = 2;
|
|
maxFreeGiB = 6;
|
|
gcDates = "weekly";
|
|
};
|
|
};
|
|
thresholds =
|
|
perHost.${config.networking.hostName}
|
|
or (throw
|
|
"nix-gc.nix: kein min-free/max-free-Eintrag für Host ${config.networking.hostName} definiert");
|
|
gib = n: n * 1024 * 1024 * 1024;
|
|
in
|
|
{
|
|
# Nur in hosts/blunix/localServices/default.nix und
|
|
# hosts/pinix/localServices/default.nix importiert -- ausdrücklich nicht
|
|
# über hosts/globalServices/default.nix, das auch tnix importiert. tnix
|
|
# bleibt bewusst außen vor (Laptop, manuell verwaltet).
|
|
nix.gc = {
|
|
automatic = true;
|
|
dates = thresholds.gcDates;
|
|
options = "--delete-older-than 30d";
|
|
};
|
|
|
|
nix.settings.min-free = gib thresholds.minFreeGiB;
|
|
nix.settings.max-free = gib thresholds.maxFreeGiB;
|
|
|
|
# Beide Optionen sind unabhängig vom tatsächlich aktiven Loader gültig
|
|
# (grub auf blunix, generic-extlinux-compatible auf pinix) -- die jeweils
|
|
# ungenutzte bleibt wirkungslos, kein bedingtes Schalten nötig.
|
|
boot.loader.grub.configurationLimit = 10;
|
|
boot.loader.generic-extlinux-compatible.configurationLimit = 10;
|
|
}
|