ee9ca6db33dca972ce281520a2353313a1a37409
10
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  duffyduckandClaude Opus 5
|
58308264c6 |
Absturzschleife des Proxy Managers: IP-Bereich-Abruf abschaltbar
Das Containerprotokoll eines Kunden zeigte, was hinter dem 502 steckte: der Dienst stuerzt in einer Schleife ab. [IP Ranges] Fetching https://ip-ranges.amazonaws.com/ip-ranges.json Uncaught Error: Client network socket disconnected before secure TLS connection was established ... node --abort_on_uncaught_exception ... index.js Starting backend ... [und das immer wieder] Beim Start holt der Proxy Manager IP-Bereiche von AWS und Cloudflare - gebraucht wird das nur fuer Zugriffslisten mit deren Adressbereichen, auf einem internen Server also nie. Der Code faengt Fehler dabei ab, dieser kommt aber asynchron vom TLS-Socket und laeuft am catch vorbei; weil node mit --abort_on_uncaught_exception laeuft, bricht der Prozess ab, s6 startet neu, und nginx davor antwortet durchgehend mit 502. Am Abbild nachgesehen und ausprobiert: - IP_RANGES_FETCH_ENABLED=false verhindert den Abruf; im Protokoll steht dann "IP Ranges fetch is disabled by environment variable", das Backend laeuft. - Scheitert der Abruf sauber (DNS-Fehler, Verbindung abgelehnt), faengt der Code ihn ab und der Dienst laeuft weiter - der Absturz haengt also wirklich an der gekappten TLS-Verbindung. - initTimer() laeuft unabhaengig vom Schalter und versucht es alle sechs Stunden erneut. Das steht als Hinweis samt extra_hosts in der README. Neu: NPM_IP_RANGES_FETCH, Vorgabe false. Und die Fehlermeldung erkennt den Fall selbst - sie zaehlt Startversuche und Ausnahmen im Containerprotokoll und nennt den Schalter, statt den Benutzer weiter auf "startet noch" warten zu lassen. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
duffyduckandClaude Opus 5
|
eb29db0130 |
no_proxy vergleicht Namen, keine Adressen - NPM_API_HOST
Der Kern des Problems, und die Stelle, an der man am laengsten sucht: "no_proxy=localhost" deckt eine Anfrage an 127.0.0.1 NICHT ab, und umgekehrt genauso wenig. An curl 7.88 nachgemessen: no_proxy an 127.0.0.1 an localhost localhost ueber den Proxy direkt 127.0.0.1 direkt ueber den Proxy In Firmennetzen steht oft nur "localhost" in der Ausnahmeliste - dann laeuft ausgerechnet der Zugriff auf die Schnittstelle des Proxy Managers ueber den Proxy, obwohl no_proxy dem Anschein nach gesetzt ist. Deshalb NPM_API_HOST: damit laesst sich die Schnittstelle als "localhost" ansprechen, ohne die Ausnahmeliste zu aendern - was im Kundennetz oft nicht in der eigenen Hand liegt. Vorgabe bleibt 127.0.0.1, denn das kommt ohne Namensaufloesung aus und zeigt immer auf IPv4. "noproxy" prueft jetzt beide Schreibweisen einzeln und sagt, welche fehlt, statt nur "geht nicht" zu melden: http://127.0.0.1:81/ geht an den Proxy http://localhost:81/ direkt [ WARN ] Nur 'localhost' ist ausgenommen, 127.0.0.1 nicht. Bis das geaendert ist, hilft sofort: cmk-manage.sh config set NPM_API_HOST localhost Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
duffyduckandClaude Opus 5
|
4456f8c3ea |
Extern geliefertes Zertifikat verwenden, statt es zu kopieren
Liefert eine fremde Stelle das Zertifikat in ein Verzeichnis und
ersetzt es dort beim Erneuern - gleicher Dateiname, neuer Inhalt -,
passt der uebliche Weg nicht: der Proxy Manager kopiert hochgeladene
Zertifikate nach /data/custom_ssl/npm-<id>/ und bekommt von einer
ersetzten Datei nichts mit.
Das Verzeichnis wird deshalb schreibgeschuetzt als /certs in den
Container gehaengt (neuer Mount in der compose-Datei, Vorgabe
./data/npm/external-certs), und "cert external" ersetzt die beiden
Dateien unter custom_ssl durch Verweise darauf. Am Abbild
jc21/nginx-proxy-manager:2 nachgemessen: nginx liefert danach das
externe Zertifikat, und ein Austausch der Datei wirkt - allerdings erst
nach einem Neuladen.
Genau das ist der Haken, und er ist belegt: ohne Neuladen liefert nginx
weiterhin das alte Zertifikat. Dafuer gibt es
cert external --refresh vergleicht den SHA256-Fingerabdruck mit
dem zuletzt gesehenen und laedt nur bei
Aenderung neu
cert external --watch on traegt das als taeglichen cron-Eintrag ein
Vor dem Umstellen wird geprueft, ob beide Dateien lesbar sind, ob
Zertifikat und Schluessel zusammengehoeren (Vergleich der oeffentlichen
Schluessel - das faengt auch EC-Schluessel) und wie lange es noch gilt.
Beide Faelle sind durchgespielt: ein fremder Schluessel wird abgelehnt,
ein in fuenf Tagen ablaufendes Zertifikat gemeldet.
"cert external --off --id N" nimmt es zurueck und legt wieder eigene
Kopien an. In der Oberflaeche ist aus dem Menuepunkt "Zertifikat" ein
kleines Menue geworden.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
duffyduckandClaude Opus 5
|
b912578f27 |
Firewall-Pruefung: welche Ports offen sein muessen - und welche nicht
Auf RHEL ist firewalld ab Werk aktiv und gibt in aller Regel nur SSH
frei. Der Stack laeuft dann sauber, ist aber von aussen nicht zu
erreichen: die Agents kommen nicht durch den Receiver auf 8000, und im
Browser passiert nichts. Das war bisher nur eine Handvoll statischer
Beispielzeilen in der README und in install.sh.
Neu ist "cmk-manage.sh firewall". Erkannt werden firewalld, ufw,
nftables und iptables; welche Ports noetig sind, ergibt sich aus der
Konfiguration statt aus einer festen Liste:
- ohne Proxy Manager wird 5000 zum Pflichtport, mit ihm soll es zu
bleiben - offenes 5000 wird deshalb ausdruecklich angemerkt
- der Admin-Port kommt aus NPM_ADMIN_PORT, nicht fest aus 81
- FW_ROLE unterscheidet single/central/remote: eine Remote-Site
braucht 6557 eingehend, die Zentrale baut die Verbindungen selbst
auf und braucht dafuer nichts. Steht FW_ROLE=remote bei
CMK_LIVESTATUS_TCP=off, ist der Port zwar offen, es lauscht aber
niemand - auch darauf weist der Bericht hin.
- Event Console ueber FW_EC_SYSLOG / FW_EC_SNMPTRAP / FW_EC_TCP,
Agent dieses Hosts ueber FW_AGENT, alles Weitere (Grafana, NSCA)
ueber FW_EXTRA_PORTS
Syslog und SNMP-Traps laufen ueber UDP, eine TCP-Freigabe nuetzt ihnen
nichts. Ports werden deshalb durchweg als nummer/protokoll gefuehrt -
beim Pruefen wie beim Erzeugen der Regeln. Bestehende Regeln werden
entsprechend gelesen: Portbereiche (6556-6558 bzw. 6556:6558) werden
aufgeloest, firewalld-Dienstnamen und Rich Rules zaehlen mit, bei
firewalld alle aktiven Zonen statt nur der Standardzone, und eine
ufw-Regel ohne Protokoll zaehlt fuer TCP und UDP - so wie ufw sie
anlegt.
"firewall open" zeigt die passenden Kommandos, --apply setzt sie nach
Rueckfrage, --source begrenzt sie auf ein Quellnetz (fuer Port 80 mit
Warnung, weil Lets Encrypt von aussen prueft). Ohne Befund ist der
Rueckgabewert 1, damit sich das auswerten laesst. In der Oberflaeche
steckt derselbe Bericht unter "Firewall pruefen".
Nebenbei: env_set hat Werte mit Leerzeichen samt Anfuehrungszeichen in
die laufende Umgebung exportiert. In der Datei gehoeren sie hin, im
Wert nicht - das fiel erst mit den Beschreibungen in FW_EXTRA_PORTS auf.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
duffyduckandClaude Opus 5
|
4d2e234c36 |
Bezugsweg als Schalter, schlankes "Image holen", up holt selbst
Drei zusammenhaengende Vereinfachungen aus der Bedienung heraus:
1. CMK_IMAGE_SOURCE bestimmt, woher ein fehlendes Image kommt:
auto erst Registry, dann Downloadportal (Vorgabe)
registry nur Registry
download nur Tarball
"auto" ist die sinnvolle Vorgabe, weil Registries nur die juengsten
Patchstaende vorhalten - genau die aeltere Version, die eine
Migration braucht, liegt dann nur noch im Archiv. Der Wechsel
geschieht ohne Rueckfrage.
2. "image get" holt ueber diesen Weg, ohne dass Edition und Version
erneut abgefragt werden. Im Menue fragt "Image holen" entsprechend
nur noch nach dem Bezugsweg; der eingestellte ist gekennzeichnet.
Der vollstaendige Assistent bleibt als eigener Punkt daneben, fuer
den Fall, dass Edition oder Version geaendert werden sollen.
3. "up" beschafft ein lokal fehlendes Image selbst, bevor compose
startet. Vorher lief compose in einen nackten Pull, der bei einer nur
im Downloadportal vorhandenen Version scheitern musste - genau der
Fall mit 2.4.0p9. Mit "up --no-fetch" bleibt das aus.
Durchgespielt mit einer absichtlich nicht existierenden Version: up
erkennt das fehlende Image, versucht die Registry, weicht auf das
Downloadportal aus, bricht nach beiden Fehlschlaegen ab - und ruft
compose gar nicht erst auf. Mit --no-fetch geht es direkt zu compose.
Nebenbei: im Auswahlmenue erschien der eingestellte Bezugsweg doppelt
(einmal als "wie eingestellt", einmal unter seinem Namen) - zwei
Eintraege mit derselben Kennung. Jetzt wird der eingestellte nur noch
gekennzeichnet.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
duffyduckandClaude Opus 5
|
9c99429c15 |
Proxy-Hosts ueber die API statt ueber den Terminal-Browser
Drei zusammenhaengende Befunde aus der Praxis, alle am laufenden
Container nachgeprueft:
1. Die Standardzugangsdaten admin@example.com/changeme stimmen nicht
mehr. In backend/setup.js von v2.15.1 steht, dass das erste Konto
nur angelegt wird, wenn INITIAL_ADMIN_EMAIL und
INITIAL_ADMIN_PASSWORD gesetzt sind - sonst kommt der
Einrichtungsassistent. Meine README war an der Stelle falsch.
Die beiden Werte stehen jetzt als NPM_ADMIN_EMAIL/-PASSWORD in der
.env und werden von compose und der Quadlet-Unit durchgereicht.
Gegen einen frisch gestarteten Container geprueft: das Konto ist
sofort da und die Anmeldung an der API liefert ein Token.
2. Die Weboberfliche laesst sich im Terminal-Browser kaum bedienen
(JSON-Fehler bei Proxy-Hosts, keine Datei-Uploads). Da der Proxy
Manager ohnehin lokal laeuft, gibt es jetzt
proxy status | list | certs | add | del
Damit legt "proxy add --domain X" in einem Zug an: Zertifikat
erzeugen bzw. bei Let's Encrypt anfordern, hochladen, Proxy-Host
anlegen, HTTPS erzwingen, HTTP/2 und Websockets setzen. Der Zielport
ist frei waehlbar (--forward-port), nicht auf 5000 festgelegt.
Im Menue unter "proxy" und in den Einstellungen unter NGINX Proxy
Manager.
3. Let's Encrypt nimmt in 2.15 die E-Mail des angemeldeten Kontos; ein
letsencrypt_email im Aufruf gibt es nicht mehr. Entsprechend
umgesetzt und im Fehlerfall erklaert.
Beim Testen gegen die echte Instanz gefunden und behoben:
- Wieder "set -e": ein grep ohne Treffer beendete das Skript still,
"proxy add" tat daraufhin gar nichts. Vier Stellen abgesichert.
- Die Listenantwort laesst sich nicht an "{" zerlegen, weil
"meta":{...} ebenfalls Klammern enthaelt - dadurch fehlte das
Schema in der Ausgabe. Die Eintraege werden jetzt einzeln geholt.
- --update legte jedes Mal ein neues Zertifikat an. Ein vorhandener
eigener Eintrag gleichen Namens wird jetzt wiederverwendet.
Durchgespielt: Anmeldung, Anlegen mit selbstsigniertem Zertifikat,
Liste, Zertifikatsliste, --update, Loeschen, Neuanlage mit anderem
Zielport und alle Fehlerfaelle. Gegengeprueft, dass Port 443 danach
tatsaechlich mit unserem Zertifikat antwortet (CN=checkmk.test.local)
und Port 80 per 301 dorthin umleitet.
Dokumentiert als Kapitel 10.1 bis 10.3 in beiden Sprachfassungen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
duffyduckandClaude Opus 5
|
2d645bcc0b |
Fehler in der Oberflaeche abfangen, Backups planbar machen
Der Anlass: "Backup erstellen" bei fehlendem Container beendete die
ganze TUI mit einer Fehlerzeile in der Shell.
Ursachen waren zwei, beide behoben:
1. die() in GUI-Pfaden. Neue Helfer gui_need_container/gui_need_sites
melden das Problem im Dialog und kehren zurueck. Interaktives wie
Shell und Terminal-Browser laeuft jetzt ueber gui_run_interactive
in einer Subshell mit Weiter-mit-ENTER.
2. "set -e". Schon ein Rueckgabewert != 0 aus einer Menuefunktion
beendete das Skript, weil Menuezweige keine Bedingung sind. 47
"|| return" auf "|| return 0" gestellt und 37 Menuezweige mit
"|| true" abgesichert. Ausserdem schlug ein "clear" ohne TERM fehl
und riss alles mit - drei Aufrufe abgesichert.
Jeder Hauptmenuepunkt wurde einzeln durchlaufen und kehrt sauber zurueck.
Neu: Backup-Jobs
Der Menuepunkt heisst jetzt "Backup erstellen / planen" mit Untermenue
(manuell erstellen, Jobs verwalten, Automatik ein/aus, Zeitplan
anzeigen, Job sofort ausfuehren). Dieselben Jobs liegen auch in den
Einstellungen unter "Backup-Jobs".
Manuelle Backups nehmen weiterhin immer BACKUP_DIR aus der .env.
Jeder Job hat dagegen sein eigenes Zielverzeichnis, seinen eigenen
Zeitplan, eigene Optionen und eine eigene Aufbewahrung, nach der er
sein Zielverzeichnis selbst aufraeumt.
Vollstaendig auch per Parameter:
job list | status | add | set | del | enable | disable
| run | run-all | auto [on|off]
mit --name --sites --cron --dir --keep --no-rrds --no-logs --stop
--disabled.
"job auto on" erzeugt aus den aktiven Jobs /etc/cron.d/checkmk-backup,
eine Zeile je Job mit dessen eigenem Zeitplan. Ohne root werden die
Zeilen ausgegeben statt kommentarlos zu scheitern. Der Schalter steht
als BACKUP_AUTO in der .env, die Jobs in backup-jobs.conf.
Nebenbei behoben: "local f; f=... tmp" fuehrte tmp als Kommando aus,
wodurch job_put und job_remove nichts schrieben.
Dokumentiert als Abschnitt 15.1 in beiden Sprachfassungen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
duffyduckandClaude Opus 5
|
4bbd1de4f6 |
Schalter: NGINX Proxy Manager abschaltbar (externer NGINX)
Wer die HTTPS-Terminierung bereits mit einem NGINX auf einem anderen
System loest, braucht den Container nicht. NPM_ENABLED=off sorgt dafuer,
dass er gar nicht erst angelegt wird: compose bekommt dann nur noch den
Checkmk-Dienst genannt.
NPM_ENABLED=off -> compose up -d checkmk
NPM_ENABLED=on -> compose up -d checkmk nginx-proxy-manager
Das gilt auch fuer "pull" - abgeschaltet wird nicht einmal das Image
geladen. Beim Abschalten wird ein vorhandener Container gestoppt UND
entfernt, damit ihn weder eine Restart-Regel noch ein Reboot wieder
hochzieht.
Die Daten bleiben in jedem Fall erhalten: Konfiguration, Datenbank und
Zertifikate liegen in den Bind-Mounts unter ./data/npm, nicht im
Container. Vor dem Abschalten werden beide Verzeichnisse mit Groesse
angezeigt; beim Einschalten wird die vorhandene Konfiguration samt
Zertifikaten unveraendert wieder aufgenommen.
Bedienung:
- Menuepunkt "Proxy Manager betreiben" unter Einstellungen -> npm
- cmk-manage.sh npm-enable [on|off] (ohne Argument: Stand anzeigen)
- config set NPM_ENABLED off
"npm-enable off" gibt gleich die noetige Firewall-Regel und eine
Beispielkonfiguration fuer den externen NGINX aus - Port 5000 muss dann
fuer dessen IP erreichbar sein. Der Agent-Receiver auf Port 8000 ist
davon nicht betroffen, den sprechen die Agents ohnehin direkt an.
Damit der Schalter auch nach einem Reboot gilt, ruft die von install.sh
erzeugte systemd-Unit jetzt cmk-manage.sh auf statt compose direkt.
Bei Quadlet wird die Unit nginx-proxy-manager.container uebersprungen
und entfernt, solange der Schalter auf "off" steht.
Verifiziert mit einem compose-Stub, dass in beiden Schalterstellungen
genau die erwarteten Dienste uebergeben werden, sowie ueber das Menue.
Dokumentiert als Abschnitt 12.4 in beiden Sprachfassungen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
duffyduckandClaude Opus 5
|
1693330162 |
Terminal-Browser, konfigurierbarer Admin-Port und Einstellungsmenue
Der NGINX Proxy Manager laesst sich jetzt auch dann einrichten, wenn
seine Oberflaeche auf Port 81 aus dem Netz nicht erreichbar ist.
browser
Terminal-Browser in einem eigenen Container, gestartet mit
"run --rm -it --network host" - damit erreicht er 127.0.0.1 genau wie
der Proxy Manager selbst. Engines: browsh und carbonyl (rendern einen
echten Browser und koennen JavaScript, das die Adminoberflaeche
benoetigt) sowie links2/w3m/lynx und eine Shell mit curl/jq/openssl
fuer Diagnose. Werkzeug-Image unter containers/browser/.
Bewusst kein Compose-Dienst: ein Browser ist interaktiv, und
podman-compose behandelt Profile unzuverlaessig.
npm-port
Port der Adminoberflaeche frei waehlbar. Das Image bindet fest auf 81
("listen 81 default;"), eine Umgebungsvariable dafuer gibt es in 2.15.1
noch nicht. Ein abweichender Port wird deshalb ueber den nginx-
Erweiterungspunkt /data/nginx/custom/http.conf bereitgestellt. Nur der
markierte Block wird verwaltet, eigene Eintraege bleiben erhalten.
Port 81 lauscht weiterhin lokal und ist per Firewall zu sperren.
config
Alle Werte der .env sind menuegefuehrt bzw. ueber config get/set
aenderbar - der Editor bleibt als Menuepunkt erhalten. Geprueft wird
beim Setzen: Portbereich und Kollisionen, Site-Namen, vollqualifizierte
Image-Namen, installierte Runtime, Zahlen- und URL-Felder.
Fehlerbehebungen
- ui_*-Funktionen initialisieren sich selbst; eine von aussen gesetzte
UI_BIN fuehrte unter "set -u" zum Abbruch.
- Eine nicht installierte CMK_RUNTIME machte das gesamte Werkzeug
unbenutzbar, auch den Aufruf zum Korrigieren. Jetzt wird gewarnt und
selbst gesucht.
- env_set setzt Werte mit Leerzeichen in Anfuehrungszeichen und laesst
optional leere Werte zu.
README auf 22 Kapitel erweitert: Kapitel 11 (Terminal-Browser inkl.
NPM-API als Fallback fuer den Zertifikats-Upload), Kapitel 12 (Admin-Port)
und Abschnitt 14.3 (Einstellungsmenue).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
duffyduck
|
b4956f780f | .env .gitignore |