Voraussetzungen

Zielgruppe: Technische Administration

Überblick

Dieses Kapitel listet alles, was vor der Installation bereitstehen muss: ein Docker-Host, freie Ports, eine Netzwerkverbindung zum opsi-Configserver und ein technischer opsi-Benutzer. Prüfe die Punkte der Reihe nach, bevor du mit der Installation beginnst.

Host

oPBWeb läuft auf jedem Linux-Host mit Docker. Du kannst den Stack direkt auf dem opsi-Configserver betreiben oder auf einem eigenen Host, der den Configserver per HTTPS erreicht.

• Betriebssystem: Linux mit aktuellem Docker Engine.
• Docker Compose: das Compose-Plugin (Version 2, Aufruf docker compose). Das alte eigenständige docker-compose (Version 1) reicht nicht, weil die Compose-Datei Funktionen wie Datei-Secrets und service_completed_successfully nutzt.
• Bash und OpenSSL: Die Skripte setup-opbweb.sh, start.sh, stop.sh und scripts/init-secrets.sh sind Bash-Skripte, die Secrets werden mit openssl erzeugt.
• Git: zum Holen der Quellen.
• Speicherplatz: Der Objektspeicher wächst mit den Paketdateien. Plane genug Platz für die Docker-Volumes ein (Datenbank, Objektspeicher). Feste Mindestwerte für CPU, Arbeitsspeicher oder Plattenplatz gibt es nicht; die Container laufen ohne Ressourcenlimits.

Ports

Nach außen öffnet der Stack nur den Frontend-Container. Alle anderen Dienste kommunizieren in internen Docker-Netzen.

Die Oberfläche läuft nur per HTTPS; der HTTP-Port leitet dorthin weiter. Läuft auf dem Host bereits ein Webserver (zum Beispiel auf dem Configserver), wähle andere Ports.

Netzwerk zum opsi-Configserver

Der Worker-Container spricht direkt mit opsiconfd auf dem Configserver:

• HTTPS auf Port 4447 für JSON-RPC.
• WebDAV über denselben Port für die Freigaben /repository, /workbench und /depot.

Die Verbindung geht vom Worker aus über das Docker-Netz opsi-net. Firewalls zwischen Docker-Host und Configserver müssen Port 4447 zulassen.

opsi-seitige Voraussetzungen

oPBWeb ist für opsi 4.3 ausgelegt. Auf dem Configserver brauchst du:

• Technischer Benutzer mit opsi-Admin-Rechten: Der Worker meldet sich mit diesem Benutzer an (Vorgabe in der Oberfläche: opsiadm). Ohne Admin-Rechte schlägt der Verbindungstest mit „… hat keine opsi-Admin-Rechte“ fehl; außerdem verlangen /repository und /workbench Admin-Rechte.
• admin-networks in opsiconfd: Ist diese Einstellung gesetzt, muss das Docker-Netz des Workers darin enthalten sein. Sonst lehnt opsiconfd die Admin-Aufrufe mit HTTP 403 ab. Das Subnetz ermittelst du nach dem ersten Start mit docker network inspect opbweb_opsi-net (Eintrag Subnet).
• FQDN des Configservers: Trage den Configserver später mit seinem vollständigen Hostnamen ein, nicht mit der IP-Adresse. Das Serverzertifikat von opsiconfd lautet auf den Namen; mit einer IP-Adresse scheitert die TLS-Prüfung. Der Name muss aus dem Worker-Container auflösbar sein.

Zertifikate

• TLS-Zertifikat für die Weboberfläche (empfohlen): Für HTTPS brauchst du ein Zertifikat mit vollständiger Kette (fullchain.pem) und den passenden privaten Schlüssel (key.pem) für den Hostnamen, unter dem die Benutzer oPBWeb aufrufen. Leg die beiden Dateien vor dem Setup neben setup-opbweb.sh. Ohne eigenes Zertifikat erzeugt das Setup ein self-signed Zertifikat; dann warnt der Browser.
• CA des opsi-Servers: Sie wird bei der Ersteinrichtung direkt vom Configserver geholt. Halte für den Abgleich des Fingerabdrucks einen Shell-Zugang zum Configserver bereit.
• LDAPS-CA (optional): Für die Anmeldung per LDAP mit eigener CA legst du die CA-Datei als ldap-ca.pem neben das Skript oder unter certs/ldap/ ab, siehe LDAP-Anmeldung .

Images und Internetzugang

Die eigenen Images von oPBWeb (Backend, Frontend, garage-init) kannst du auf zwei Wegen bereitstellen:

• Lokal bauen mit ./start.sh --build. Dafür braucht der Host Zugriff auf:
  • Docker Hub für die Basis-Images (Python, Node.js, nginx, Alpine),
  • GitHub für python-opsi und die Hugo-Module des Handbuchs,
  • PyPI für die Python-Pakete,
  • npm-Registry für die Frontend-Abhängigkeiten,
  • den Go-Modul-Proxy proxy.golang.org für das Handbuch-Theme.
• Fertig aus einer Registry ziehen, zum Beispiel aus der Registry der GitLab-CI des Projekts oder einem internen Mirror. Dann braucht der Host nur Zugriff auf diese Registry; ein Konto (docker login) nur, wenn sie eine Anmeldung verlangt. Die Registry des Projekts ist öffentlich. Internetzugang zum Bauen braucht nur der Rechner, auf dem die Images gebaut werden.

Die Fremd-Images für MariaDB, Redis und Garage kommen in beiden Fällen von Docker Hub, sofern du keinen Mirror verwendest. Welchen Weg du nimmst, legst du bei der Installation mit setup-opbweb.sh fest.

Im laufenden Betrieb braucht der Stack keinen Internetzugang.

Versionen

Dieses Handbuch beschreibt folgenden Stand:

Technische Basis:

Die installierten Versionen von Frontend und Backend siehst du jederzeit in der Statusleiste unten in der Oberfläche.