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>
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>
Neues Unterkommando "image test" und ein Menuepunkt im Image-Menue.
Geprueft wird in Sekunden, statt erst beim mehrere Gigabyte grossen
Download zu scheitern:
Registry - Erreichbarkeit, Anmeldung und ob das Konto ueberhaupt
Zugriff auf das Repository hat. Umgesetzt ueber den
Docker-Registry-v2-Ablauf: WWW-Authenticate auswerten,
Token beim genannten realm holen, damit /tags/list
abfragen. Dadurch wird "Anmeldung stimmt, aber keine
Berechtigung" von "Anmeldung falsch" unterschieden.
Downloads - HTTP-Basic gegen die Tarball-URLs. HTTP 404 ohne 401
bedeutet: Zugangsdaten sind richtig, nur Version oder
Dateiname passen nicht - das wird auch so gemeldet.
Es wird nichts gespeichert: die Zugangsdaten gehen per temporaerer
.netrc an curl und stehen damit nicht in der Prozessliste (geprueft).
Fehlt curl, weicht die Registry-Pruefung auf podman/docker login in
eine Wegwerfdatei aus (--authfile bzw. DOCKER_CONFIG), die gespeicherte
Anmeldung des Systems bleibt unberuehrt.
Beim Testen gegen die echten Dienste gefunden und behoben:
- "docker.io" ist nicht der API-Host der Registry; angesprochen wird
registry-1.docker.io. Vorher lieferte /v2/ nur eine 302.
- Die Schlussauswertung zaehlte auch Pruefungen als bestanden, die
wegen --only gar nicht gelaufen waren.
Verifiziert gegen die echten Endpunkte: Docker Hub anonym inkl.
Tag-Liste von checkmk/check-mk-raw (HTTP 200), registry.checkmk.com
und download.checkmk.com jeweils mit falschen Zugangsdaten (HTTP 401,
korrekt als abgelehnt gemeldet).
Dokumentiert als Abschnitt 8.4 in beiden Sprachfassungen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Abschnitt 5.1 existierte, war aber praktisch unsichtbar: alle Verweise
darauf benutzten den Anker von Kapitel 5, sprangen also an den
Kapitelanfang. Dasselbe galt fuer die uebrigen Unterabschnitts-
Verweise (8.2, 10.4, 11.3, 14.2 sowie "Variante B" in Kapitel 6) -
insgesamt 13 Stellen in beiden Dateien.
Beim Nachrechnen der Anker fiel ausserdem auf, dass Leerzeichen NICHT
kollabiert werden: aus "Variante B - Podman-Quadlet" wird
"variante-b--podman-quadlet-..." mit doppeltem Bindestrich, weil der
Gedankenstrich entfaellt und zwei Leerzeichen stehen bleiben. Vier
Anker waren deshalb zunaechst weiterhin falsch und sind korrigiert.
Bestaetigt wird die Regel durch die schon vorhandenen Anker des
Inhaltsverzeichnisses (#1-ueberblick--architektur).
Zusaetzlich zur Auffindbarkeit:
- 5.1 steht jetzt als Untereintrag im Inhaltsverzeichnis.
- Zwei neue Zeilen in der Fehlersuche-Tabelle: die dnf-Meldung
"not registered with an entitlement server" und der Fall, dass
sich epel-release nicht installieren laesst.
Geprueft: in beiden Dateien loesen alle Verweise gegen alle 62 Anker
auf (## bis ####).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Beide Hinweise standen bisher nur in Abschnitt 5.1. Wer Kapitel 5 von
oben nach unten abarbeitet, lief aber vorher schon in den dnf-Fehler.
Deshalb jetzt im Hauptablauf selbst:
- Ein hervorgehobener "Schritt 0" gleich zu Beginn des Kapitels mit
den Pruefbefehlen (subscription-manager status, dnf repolist) und
der Registrierung ueber die kostenlose Developer-Subskription.
Dazu der Hinweis, dass RHEL 9 Simple Content Access nutzt und
"subscription-manager attach" entfaellt, sowie die Feststellung,
dass Rocky/Alma/CentOS Stream/Fedora nichts davon brauchen.
- Direkt beim epel-release-Befehl der Vorbehalt, dass EPEL eine
funktionierende Subskription voraussetzt: das Paket konfiguriert
nur die Quelle, Abhaengigkeiten kommen weiter aus BaseOS/AppStream.
EPEL ist damit kein Ersatz fuer die Registrierung. Bleibt
podman-compose deswegen unerreichbar, fuehrt der Quadlet-Weg aus
Kapitel 6 ohne Compose zum Ziel.
Die Aufzaehlung dessen, was install.sh tut, entspricht jetzt dem
tatsaechlichen Ablauf: Repository-Pruefung zuerst, dialog mit Rueckfall
auf newt.
Beide Sprachfassungen gepflegt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Auf einem frisch installierten RHEL liefert dnf ohne Registrierung gar
keine Pakete - weder podman noch git oder dialog. Das ist jetzt in
beiden READMEs als Kapitel 5.1 beschrieben, mit drei Wegen:
1) kostenlose Developer Subscription for Individuals (bis 16 Systeme,
kleine Produktivnutzung eingeschlossen). RHEL 9 nutzt Simple
Content Access, ein "subscription-manager attach" entfaellt.
2) Installations-DVD als lokales Repository - ohne Konto und offline,
aber ohne Sicherheitsupdates, daher nur als Ueberbrueckung.
3) Wechsel auf Rocky Linux oder AlmaLinux.
Dazu eine Tabelle, welche Pakete das Projekt wirklich braucht und aus
welchem Repository sie kommen, sowie der Hinweis, dass EPEL hier nicht
weiterhilft (es setzt die Basis-Repositories voraus) - in dem Fall ist
der Quadlet-Weg ohne podman-compose die Loesung.
install.sh:
- rhel_repo_check prueft vor der Installation, ob ueberhaupt ein
nutzbares Repository vorhanden ist, und nennt sonst die drei Wege,
statt den nackten dnf-Fehler stehen zu lassen.
- "dialog" ist nicht mehr zwingend: es liegt in AppStream, bei
Fehlschlag wird "newt" (whiptail, BaseOS) versucht. Vorher brach die
Installation ab, wenn dialog fehlte - obwohl die Skripte whiptail
ohnehin unterstuetzen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
README_en.md als vollstaendige englische Fassung der Dokumentation, in
beiden Dateien oben aufeinander verlinkt. Die Skripte selbst bleiben
deutsch; woertliche Programmausgaben und Menue-Abbildungen stehen
deshalb auch im englischen Text unveraendert, mit kurzer Erlaeuterung.
Beim Uebersetzen aufgefallen und in README.md behoben:
- Unterkapitel trugen nach dem Einfuegen neuer Kapitel noch die alten
Nummern: 9.1-9.4 in Kapitel 10, 11.1/11.2 in Kapitel 14 und
14.1-14.7 in Kapitel 17.
- Leerer Codeblock in Kapitel 9 (Rest einer frueheren Einfuegung).
- Verrutschte Zeile im Menue-Kasten des Hauptmenues.
Beide Dateien haben denselben Aufbau: 22 Kapitel, 27 Unterkapitel,
136 Codebloecke, 117 Tabellenzeilen; alle internen Verweise aufgeloest.
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