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:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user