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>
"firewall open" kannte nur eine Richtung. Wer die Event Console wieder
abschaltet oder einen Eintrag aus FW_EXTRA_PORTS streicht, behielt die
Freigabe - der Port stand offen, ohne dass noch etwas dahinter lauscht.
"firewall close" bietet an, was offen ist, zu diesem Aufbau gehoert und
gerade nicht gebraucht wird. Dazu zaehlen die bekannten Ports des Stacks
und alles, was "firewall open --apply" selbst geoeffnet hat; das merkt
sich firewall-opened.conf, damit ein gestrichener FW_EXTRA_PORTS-Eintrag
nicht in Vergessenheit geraet.
Drei Sicherungen, weil hier das Aussperren droht:
- SSH wird nie geschlossen: Port 22, der Port aus "sshd -T" und der
Port der laufenden Sitzung aus SSH_CONNECTION
- fremde Freigaben bleiben unberuehrt - wer 3306 fuer seine Datenbank
offen hat, behaelt sie
- Sammelregeln wie "80,443/tcp" werden gemeldet statt geloescht, sonst
faellt ein noch gebrauchter Port mit weg
Bei ufw wird bewusst nicht nach Regelnummern geloescht. Die Nummern
verschieben sich beim ersten Loeschen, und da je Port ein eigener
Aufruf erzeugt wird, haette der naechste die falsche Regel getroffen -
im Test waere so eine 443er-Freigabe gefallen. Geloescht wird ueber die
Regelangabe, bei nftables ueber den Handle, bei iptables mit derselben
Angabe, mit der die Regel eingetragen wurde.
Nebenbei: fw_state_del liess die Datei stehen, wenn der letzte Eintrag
entfernt wurde - "grep -v" liefert dann 1. Unter "set -e" brach damit
ausserdem der Ablauf ab, noch vor dem Neuladen der Firewall.
In der Oberflaeche liegt das unter Einstellungen > Firewall als
"Nicht mehr benoetigte Ports schliessen".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Symptom war ein scheinbar haengender Browsh: Logo, "Waiting for Firefox
to connect...", danach schwarz. Ursache ist nicht der Browser - Browsh
laeuft (Strg+Q kehrt ins Menue zurueck) - sondern die Startseite. Auf
http://127.0.0.1:81 antwortet nichts, solange der Proxy-Manager-Container
nicht laeuft, und ein Terminal-Browser zeigt dann keine Fehlerseite,
sondern gar nichts.
cmd_browser prueft die Startseite deshalb vorher und nennt die Ursache
statt stumm zu starten. Unterschieden werden: Proxy Manager
abgeschaltet (NPM_ENABLED=off), Container fehlt, Container gestoppt,
Container laeuft aber antwortet nicht, tote Checkmk-Oberflaeche auf
Port 5000 und externe Adressen. Jeweils mit dem passenden naechsten
Kommando. Ueberspringen mit --no-check; in der Oberflaeche erscheint
dieselbe Diagnose als Dialog mit der Wahl, trotzdem zu starten.
Dabei gefunden und behoben - an drei Stellen dieselbe Falle:
curl gibt mit -w '%{http_code}' im Fehlerfall selbst schon "000" aus.
Das zusaetzliche "|| echo 000" haengte einen zweiten Wert an, sodass
der Vergleich nie zutraf. Betroffen waren die neue Erreichbarkeits-
pruefung sowie http_code() und die Registry-Erreichbarkeit im
Zugangsdaten-Test ("image test") - dort waere ein nicht erreichbarer
Endpunkt als "unerwartete Antwort" statt als "nicht erreichbar"
gemeldet worden. Jetzt wird der Fehler der Zuweisung abgefangen.
Alle vier Diagnosezweige im Terminal durchgespielt, der
Zugangsdaten-Test zur Gegenprobe erneut gegen Docker Hub gelaufen.
Dokumentiert als Abschnitt 11.3 in beiden Sprachfassungen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
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>
duffyduckandClaude Opus 5