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>
This commit is contained in:
2026-09-20 17:36:21 +02:00
co-authored by Claude Opus 5
parent c04b3171d9
commit 9c99429c15
7 changed files with 632 additions and 21 deletions
+89 -10
View File
@@ -1038,7 +1038,7 @@ Zugang
Checkmk (direkt) : http://10.0.0.5:5000/cmk/
Checkmk (über Proxy) : https://<FQDN>/cmk/
Agent-Receiver : 10.0.0.5:8000
NGINX Proxy Manager : http://10.0.0.5:81/ (Erstlogin: admin@example.com / changeme)
NGINX Proxy Manager : http://10.0.0.5:81/
```
Der Port der Adminoberfläche folgt `NPM_ADMIN_PORT` aus der `.env`; die Ausgabe
@@ -1050,16 +1050,92 @@ Anmeldung an Checkmk: Benutzer `cmkadmin`, Passwort aus `CMK_PASSWORD`.
## 10. HTTPS einrichten – Let's Encrypt oder selbstsigniert
### 10.1 NGINX Proxy Manager vorbereiten
### 10.1 Das Administratorkonto
> **Die früher üblichen Standardzugangsdaten `admin@example.com` / `changeme`
> gibt es seit Version 2.15 nicht mehr.** Der Container legt das erste Konto
> nur noch an, wenn beim **ersten** Start `INITIAL_ADMIN_EMAIL` und
> `INITIAL_ADMIN_PASSWORD` gesetzt sind – sonst erscheint im Browser ein
> Einrichtungsassistent. Nachgelesen in `backend/setup.js` von v2.15.1 und am
> laufenden Container überprüft.
Deshalb stehen die Werte in der `.env` und werden von `docker-compose.yml`
durchgereicht:
```bash
NPM_ADMIN_EMAIL=admin@example.com
NPM_ADMIN_PASSWORD=ein-ordentliches-kennwort
```
Beides **vor dem ersten Start** setzen. Dann ist das Konto sofort da – und
damit auch die REST-Schnittstelle nutzbar, über die
[Kapitel 10.2](#102-proxy-host-anlegen--ohne-browser) den Proxy-Host anlegt.
Ist der Stack schon gelaufen und das Konto von Hand über den Assistenten
angelegt worden, wirken die Variablen nicht mehr (die Datenbank ist nicht mehr
leer). Dann einfach die selbst vergebenen Zugangsdaten eintragen – das Skript
meldet sich damit an.
### 10.2 Proxy-Host anlegen – ohne Browser
Die Weboberfläche lässt sich im Terminal-Browser nur mühsam bedienen; Formulare
mit Datei-Upload funktionieren dort gar nicht. Da der Proxy Manager ohnehin
lokal läuft, ist die Schnittstelle der verlässlichere Weg:
```bash
# Checkmk unter checkmk.example.com veröffentlichen, mit selbstsigniertem Zertifikat
sudo ./scripts/cmk-manage.sh proxy add --domain checkmk.example.com --cert self
# oder mit Let's Encrypt (Port 80 muss aus dem Internet erreichbar sein)
sudo ./scripts/cmk-manage.sh proxy add --domain checkmk.example.com --cert letsencrypt
# auf einen anderen Zielport statt 5000
sudo ./scripts/cmk-manage.sh proxy add --domain checkmk.example.com --forward-port 8080
```
Das Kommando erledigt in einem Zug: Zertifikat erzeugen (bzw. bei Let's
Encrypt anfordern), in den Proxy Manager hochladen, Proxy-Host anlegen, HTTPS
erzwingen, HTTP/2 und Websockets einschalten und den empfohlenen
`advanced_config`-Abschnitt setzen.
| Kommando | Wirkung |
|---|---|
| `proxy status` | Anmeldung prüfen, Anzahl Hosts und Zertifikate |
| `proxy list` | vorhandene Proxy-Hosts |
| `proxy certs` | vorhandene Zertifikate mit Ablaufdatum |
| `proxy add …` | Proxy-Host anlegen (`--update` ersetzt einen vorhandenen) |
| `proxy del --id N` | Proxy-Host löschen |
Optionen von `proxy add`:
| Option | Vorgabe | Bedeutung |
|---|---|---|
| `--domain FQDN` | `PROXY_DOMAIN` | öffentlicher Name |
| `--forward-host H` | `127.0.0.1` | Weiterleitungsziel |
| `--forward-port P` | `5000` | Zielport – **frei wählbar**, nicht auf Checkmk festgelegt |
| `--scheme http\|https` | `http` | Schema zum Ziel |
| `--cert self\|letsencrypt\|none` | `self` | Zertifikat |
| `--update` | – | vorhandenen Eintrag ersetzen |
| `--advanced TEXT` | Vorgabe unten | eigener nginx-Abschnitt |
| `--no-force-ssl`, `--no-http2`, `--no-websockets`, `--no-block-exploits` | – | Abschalter |
In der Oberfläche liegt derselbe Ablauf unter **proxy → „Proxy-Host anlegen"**
(Name → Zielport → Zertifikat) sowie unter **Einstellungen → NGINX Proxy
Manager → „>> Proxy-Hosts anlegen/verwalten"**.
> Ein selbstsigniertes Zertifikat wird bei wiederholtem Aufruf
> **wiederverwendet** statt jedes Mal neu angelegt – sonst sammeln sich im
> Proxy Manager Dutzende Einträge gleichen Namens an.
### 10.3 Wenn doch die Weboberfläche
1. `http://<server>:81` aufrufen – bzw. den in `NPM_ADMIN_PORT` gesetzten Port
(siehe [Kapitel 12](#12-adminoberfläche-auf-einen-anderen-port-legen));
ist der Port im Netz gesperrt, hilft der Terminal-Browser aus
[Kapitel 11](#11-proxy-manager-lokal-einrichten-terminal-browser)
2. Erstanmeldung: **admin@example.com** / **changeme**
3. Sofort E-Mail-Adresse und Passwort ändern (wird beim ersten Login erzwungen)
2. Anmelden mit `NPM_ADMIN_EMAIL` / `NPM_ADMIN_PASSWORD`
### 10.2 Proxy-Host für Checkmk anlegen
### 10.4 Proxy-Host im Browser anlegen
**Hosts → Proxy Hosts → Add Proxy Host**
@@ -1082,7 +1158,7 @@ proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
```
### 10.3 Variante A – Let's Encrypt (öffentlich erreichbarer Server)
### 10.5 Variante A – Let's Encrypt (öffentlich erreichbarer Server)
Voraussetzungen: der DNS-Name zeigt öffentlich auf diesen Server und **Port 80
ist aus dem Internet erreichbar** (HTTP-01-Challenge).
@@ -1102,7 +1178,7 @@ gesichert.
Bei interner DNS-Zone ohne öffentlichen Zugang: **DNS-Challenge** verwenden
(SSL → *Use a DNS Challenge* → Provider auswählen, API-Token hinterlegen).
### 10.4 Variante B – Selbstsigniertes Zertifikat (interne Umgebung)
### 10.6 Variante B – Selbstsigniertes Zertifikat (interne Umgebung)
Erzeugen:
@@ -1252,7 +1328,7 @@ ausgefüllt), aber das Hochladen eines **selbstsignierten Zertifikats**
(*SSL Certificates → Custom*) funktioniert so nicht zuverlässig.
Für genau diesen Fall führt der Weg über die REST-Schnittstelle des Proxy
Managers. Zertifikat wie in [Kapitel 10.4](#104-variante-b--selbstsigniertes-zertifikat-interne-umgebung)
Managers. Zertifikat wie in [Kapitel 10.6](#106-variante-b--selbstsigniertes-zertifikat-interne-umgebung)
erzeugen, dann:
```bash
@@ -1570,6 +1646,7 @@ Eine Dateiauswahl mit Verzeichnisnavigation ist eingebaut.
| `config list\|get\|set\|edit` | Einstellungen der `.env` anzeigen und ändern |
| `npm-port [PORT]` | Port der Proxy-Manager-Oberfläche setzen/anzeigen |
| `npm-enable [on\|off]` | Proxy Manager ein-/ausschalten (Daten bleiben erhalten) |
| `proxy status\|list\|certs\|add\|del` | Proxy-Hosts über die API anlegen und verwalten |
| `cert …` | selbstsigniertes Zertifikat erzeugen |
| `shell` | Root-Shell im Checkmk-Container |
| `omd …` | beliebiges `omd`-Kommando im Container |
@@ -2077,6 +2154,8 @@ Checkmk-Werksnotizen (Werks/Release Notes) lesen.
| `browser` meldet „braucht ein echtes Terminal" | Aufruf aus Pipe/Skript. Direkt auf der Konsole oder per SSH aufrufen; nur der Bau geht headless mit `--build-only` |
| Menüpunkt bricht mit einer Fehlermeldung in die Shell ab | behoben: fehlende Container, Sites oder Backups werden jetzt als Dialog gemeldet, die Oberfläche bleibt offen |
| `job auto on` meldet fehlende Rechte | `/etc/cron.d/` braucht root: mit `sudo` aufrufen, oder die ausgegebenen Zeilen selbst übernehmen |
| Proxy Manager verlangt beim ersten Aufruf ein neues Konto | seit 2.15 normal. `NPM_ADMIN_EMAIL`/`NPM_ADMIN_PASSWORD` **vor** dem ersten Start setzen; ist das Konto schon angelegt, dessen Daten dort eintragen |
| Im Terminal-Browser erscheint bei Proxy-Hosts ein JSON-Fehler | Die Oberfläche ist dafür zu aufwendig. Proxy-Hosts stattdessen über `cmk-manage.sh proxy add` anlegen ([Kapitel 10.2](#102-proxy-host-anlegen--ohne-browser)) |
| TUI startet nicht | `dialog` installieren: `apt-get install -y dialog` bzw. `dnf install -y dialog` |
| Site startet nicht, `tmp`-Fehler | `./scripts/cmk-manage.sh omd config <site> set TMPFS off`, danach Site starten |
@@ -2096,8 +2175,8 @@ docker exec -it checkmk omd su cmk # bzw. podman exec …
* `CMK_PASSWORD` sofort nach der Installation in der Oberfläche ändern und aus
der `.env` entfernen (wird nur bei der Neuanlage ausgewertet);
`chmod 600 .env` ist gesetzt.
* Standardzugang des Proxy Managers (`admin@example.com` / `changeme`) beim
ersten Login zwingend ändern.
* `NPM_ADMIN_PASSWORD` vor dem ersten Start auf ein eigenes Kennwort setzen –
daraus wird das Administratorkonto des Proxy Managers erzeugt.
* Port **81** (Adminoberfläche) nur aus dem Administrationsnetz erreichbar
machen, Port **5000** gar nicht nach außen öffnen.
* Backups enthalten **alle** Passwörter und Zertifikate der Site – verschlüsselt