x14 sendete 105 Metriken, aber KEINE apache-Metriken und keine Logs. Der
Installer meldete Erfolg. Telegraf selbst nannte den Grund:
W! [inputs.tail] Directory "/home/users" is not readable but is followed
by wildcards, make sure you set read permissions or globbing will not work!
Drei Ursachen, alle behoben:
1. `setfacl -m u:telegraf:x` auf der Glob-Wurzel ist FALSCH. Eine Wildcard wird
per readdir expandiert — dafuer braucht das Verzeichnis `r-x`, nicht nur `x`.
Neue Logik: Muster werden mit `set -f` gelesen, dann je Treffer die Datei mit
`r` und JEDE Ebene zwischen Wurzel und Datei mit `r-x` belegt.
Gemessen: alte ACL -> 1 Warnung, 1 Punkt (nur /var/log/apache2);
neue ACL -> 0 Warnungen, 4 Punkte (alle 3 Dateien inkl. User-Homes).
2. Der Gegentest war blind: er las jede gefundene Datei per `head -c 1` als
telegraf. Das konnte nicht fehlschlagen, weil die Datei vom ROOT-Shell
expandiert wurde — die Glob-Wurzel blieb unlesbar, Telegraf bekam 0 Treffer,
die Meldung sagte trotzdem "alle N Logdateien lesen". Jetzt wird die
GLOB-AUFLOESUNG gemessen: dasselbe Muster im Dienstkontext expandieren und die
Trefferzahl vergleichen. 0 von 0 zaehlt als Fehler, nicht als Erfolg.
3. `for p in $_pfadquelle` ohne `set -f` expandiert die Muster im Root-Shell.
_pattern war danach ein konkreter Dateiname, der Wildcard-Zweig lief nie, und
die ACL landete nur auf den Dateien. Real passiert: "ACL auf 3 Datei(en)",
"kein Glob-Muster gefunden", 0 Treffer im Dienst.
Verifiziert mit echtem Telegraf 1.40.0 und REALEN KeyHelp-Rechten
(/home/users/<user> 0700, logs 0750, Dateien 0640).
Der Trace auf x14 endete exakt hier:
+ envsubst ${NODE_NAME} ... ${APACHE_ERROR_FILES}
root@x14:/home/mm#
Ohne "< \$2.tmp" liest envsubst STDIN. Bei sh install.sh vom Terminal ist stdin
die Konsole -> der Installer wartet auf Eingabe, nach der letzten Meldung
"Schreibe Konfiguration ...". Genau das Bild: Stillstand, ^C, kein Fehler.
Bei curl | sh waere es schlimmer: envsubst wuerde den Rest des Skripts fressen.
Ein frueherer Patch von mir hat die Redirection verschluckt; alle Laeufe mit
vorhandener telegraf.conf (x22) liefen trotzdem, weil dort nur der Fallback
subst_vars() aktiv war. Erst der Erstinstall (x14) traf envsubst.
Verifiziert: vorher Haenger bei envsubst, jetzt vollstaendiger Durchlauf mit
CONFIG_VERSION-Marker und allen Confs.
Zwei reale Fehler, beide still:
1. setfacl -R lief nur ab dem logs/-Verzeichnis. /home/users/<user> ist auf
Panel-Hostern chmod 700 — ohne Durchgangsrecht (x) auf den ELTERNTEIL kommt
telegraf nicht bis zur Datei. Die Meldung sagte trotzdem "ACL gesetzt".
Fix: x auf allen Elternverzeichnissen bis zur Wurzel + Default-ACL, damit
neu angelegte Domain-Ordner erben.
2. Der Gegentest brach beim ERSTEN Treffer ab. Das war
/var/log/apache2/keyhelp/access.log (root:adm, immer lesbar) -> Meldung
"Gegentest OK", waehrend ALLE Domain-Logs in den User-Homes unlesbar
blieben. Fix: jeden Logpfad pruefen und die Anzahl der Fehlschlaege melden.
Verifiziert in Debian-12 mit KeyHelp-aehnlichen Rechten (Home 700, Logs 640).
setfacl -R lief ueber die GANZE Panel-Wurzel (/home/users) — dort liegen auch
Mails, Webinhalte und Backups. Das Recht auf die Logs waere damit teuer und
wirkungslos zugleich. Jetzt werden die logs/-Verzeichnisse eingesammelt
(find -maxdepth 3), und jeder setfacl-Lauf hat ein Timeout von 120 s, damit
ein langsamer Lauf nicht wie ein Haenger aussieht.
x14 blieb nach der letzten Erfolgsmeldung stehen (Abbruch per ^C, kein Fehler).
Ursache: grant_apache_log_access() ruft apt-get install acl auf — OHNE
apt-get update davor und OHNE Timeout. Bei veralteten Paketlisten kann apt in
eine Rueckfrage laufen und unbegrenzt warten. Direkt danach haette der naechste
fetch gehangen: fetch() hatte ueberhaupt kein curl-Timeout.
Fix:
- apt-get update vor dem acl-Install, timeout 180 auf allen Paketmanager-Aufrufen
- fetch() mit -m 30 + 3 Versuchen statt unbegrenztem Warten
- alle weiteren curl-Aufrufe (keyring, Binary, Re-Exec) mit -m/--connect-timeout
- Fortschrittsmeldung vor der ACL-Phase: ein Haenger sah wie ein Absturz aus
Bei `sh install.sh` oder `< eingabe` ist stdin eine Datei — dort kann kein
Unterbefehl das Skript wegfressen. Der Re-Exec war dort unnoetig und kostete
einen Download. Nur `curl … | sh` (echte Pipe) braucht den Neustart.
Auf einem frischen System fehlt curl haeufig — genau dort, wo apt laeuft und
der Schutz am noetigsten ist. Der Re-Exec scheiterte deshalb still und der
Installer lief ohne Schutz weiter.
Jetzt: curl -> wget -> busybox wget -> lokale Quelle (NETBIRD_TG_SOURCE).
Ist keiner verfuegbar, wird das ausdruecklich gemeldet statt still uebergangen.
x14 brach mitten in der Installation ab: der Installer gab seinen eigenen
Quelltext aus ("; then", Kommentarzeilen) und blieb stehen.
Ursache: Bei `curl ... | sh` liest die Shell das Skript aus STDIN. apt startet
auf Ubuntu `needrestart` (Meldung "Scanning processes... / Scanning linux
images..."), und das liest stdin — damit war der Rest des Skripts weg. Die
Shell setzte mitten im Quelltext fort. Bei x22 trat es nicht auf, weil Telegraf
dort schon installiert war (kein apt-Lauf).
Fix, drei Schutzschichten:
1. Re-Exec: laeuft das Skript ueber eine Pipe, laedt es sich frisch von der
Quelle und startet sich neu — mit stdin auf /dev/null. NICHT per cat von
stdin kopieren: die Shell puffert bereits, die Kopie waere unvollstaendig.
2. NEEDRESTART_MODE=a + DEBIAN_FRONTEND=noninteractive fuer alle apt-Aufrufe.
3. </dev/null an jedem Paketmanager (apt, dnf, yum, apk).
Bisher wurden NUR access.log gesammelt — real nachgemessen: 31 logfile-Labels,
0 davon error.log. Bei einem KeyHelp-Host mit PHP/CMS fehlten damit genau die
Fehler, fuer die man ins Monitoring schaut.
Error-Logs jetzt in einem EIGENEN Input (name_override=apache_error), roh nach
Loki, mit Tags logtype=error und logfile=<pfad>. Getrennt vom Access-Grok, weil
das Format nicht passt:
[Mon Sep 14 00:10:01.123456 2026] [core:error] [pid 9] AH00124: ...
Liefen sie durch den Access-Parser, entstuenden keine Metriken, aber der
Aggregator wuerde sie in leere Gruppen einordnen.
DREI STILLE FALLEN dabei gefunden und behoben:
1. processors.rename hatte namepass=["journal"] — apache_error behielt das
Feld value, jede Panel-Query mit {.message} haette es nicht gefunden.
2. outputs.loki namepass enthielt apache_error nicht — Input sammelt ein,
Output verwirft, keine Fehlermeldung, Panels leer (wie bei journal damals).
3. outputs.prometheus namedrop ebenso — sonst wandern Textzeilen in die TSDB.
Verifiziert gegen echte KeyHelp-Formate: access=2 Metriken, error=4 Rohzeilen,
Feld heisst message, 0 Error-Zeilen als Metrik.
Zwei Fehler, gleiche Wurzel — die Werte aus /etc/default/telegraf wurden nur
vom Auto-Updater gelesen, nicht von einem manuellen --update-only:
1. Abbruch "Kein Token", obwohl der Token auf der Maschine liegt. Der Weg
fuer eine Reparatur auf einer laufenden Node war damit verschlossen.
2. Stiller: ohne --name fiel NODE_NAME auf den Hostnamen zurueck. Auf einem
KeyHelp-Host (x22 vs x22.idx.wf-keyhelp) waere die Node unter falschem
Label registriert worden; ein PVE-Knoten haette seine Rolle verloren
(kein pvesh-Drop-in mehr).
Fix: Token, NODE_NAME, ROLE, COLLECTOR, PVE_* aus der Datei nachladen, aber
nur wenn die Kommandozeile nichts anderes sagt (NAME_GIVEN/ROLE_GIVEN).
Zusaetzlich ein zweiter, ernster Fund aus dem Test:
APACHE_FILES blieb leer, wenn ROLE=apache gesetzt war, Apache aber nicht
erkannt wurde. Die Conf rendert dann zu "files = " -> ungueltiges TOML ->
Telegraf startet nicht -> ALLE Metriken der Node aus. Berechnung jetzt
unabhaengig vom Guard, plus Sicherheitsnetz vor dem Rendern.
mm