Installation

• Voraussetzungen
• Installation
• Ersteinrichtung
• Testumgebung

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.

Installation

Zielgruppe: Technische Administration

Überblick

Die Installation besteht aus wenigen Schritten: Quellen holen, ./setup-opbweb.sh ausführen (es schreibt die Konfigurationsdatei .env und erzeugt die Secrets), optional ein TLS-Zertifikat ablegen und den Stack starten. Die Images baust du dabei entweder lokal mit ./start.sh --build oder ziehst sie fertig aus einer Registry. Danach prüfst du, ob alle Dienste laufen, und machst mit der Ersteinrichtung in der Oberfläche weiter.

Alle Befehle führst du im Projektverzeichnis auf dem Docker-Host aus. Prüfe vorher die Voraussetzungen .

1. Quellen holen

Klone das oPBWeb-Repository (opsiPackageBuilder-web) auf den Docker-Host und wechsle in das Verzeichnis:

git clone https://gitlab.open-mind.space/pages/opsiPackageBuilder-web.git
cd opsiPackageBuilder-web

Ohne Git und ohne Quellen geht es mit dem Stack-ZIP aus dem Release oPBWeb Stack (oPBWeb-Stack-<Nr>.zip, siehe Build und Auslieferung ): entpacken und in den Ordner oPBWeb-Stack wechseln. Die Images kommen dann immer aus der Registry, die Versionen gibt die beiliegende versions.env vor.

Alle Pfade in diesem Kapitel (.env, secrets/, certs/) beziehen sich auf dieses Verzeichnis.

2. Einrichtung mit setup-opbweb.sh

Starte das Setup-Skript:

./setup-opbweb.sh

Das Skript prüft zuerst, ob docker, das Plugin docker compose und openssl vorhanden sind. Dann fragt es die wichtigsten Einstellungen ab. Bei jeder Frage steht die Vorgabe in eckigen Klammern; mit Enter übernimmst du sie.

Die Vorgabe für das Registry-Präfix ist die Registry der GitLab-CI des Projekts. Ein anderes Präfix, etwa für einen internen Mirror, gibst du bei der Frage ein oder setzt es vorher als Umgebungsvariable OPBWEB_REGISTRY. Die LDAP-Einstellungen erklärt das Kapitel LDAP-Anmeldung .

Nach einer Zusammenfassung fragt das Skript „Fortfahren und Dateien schreiben?“. Bestätigst du, dann

1. schreibt es die .env,
2. erzeugt es über scripts/init-secrets.sh alle fehlenden Secrets (siehe 3. Secrets ) und schreibt das eingegebene LDAP-Passwort nach secrets/ldap_bind_password.txt,
3. legt es die Verzeichnisse certs/ und certs/ldap/ an, übernimmt mitgebrachte Zertifikate dorthin oder erzeugt ein self-signed Zertifikat,
4. bietet es bei Registry-Images an, die Images gleich zu ziehen („Images jetzt ziehen?“),
5. zeigt es die nächsten Schritte an.

Fehlen Dateien, die das Skript für deine Antworten erwartet, warnt es, etwa wenn die angegebene LDAP-CA-Datei nicht in certs/ldap/ liegt oder das Zertifikat in weniger als 30 Tagen abläuft.

Werte, nach denen das Skript nicht fragt (Zeitlimits, Kompression, Token-Laufzeiten, Kontosperre, DEBUG), setzt es auf ihre Standardwerte. Du kannst sie danach direkt in der .env ändern; ein späterer Lauf des Skripts übernimmt sie. Alle Variablen beschreibt das Kapitel Konfiguration .

Optionen von setup-opbweb.sh

--updateonly brauchst du vor allem beim Aktualisieren .

Ohne .env bricht start.sh mit der Meldung „.env fehlt – bitte ./setup-opbweb.sh ausführen (im Entwickler-Checkout: ./setup-opbweb.sh –dev).“ ab.

Alternative: .env von Hand anlegen

Statt des Skripts kannst du die Vorlage kopieren und selbst anpassen:

cp .env.example .env

.env.example enthält alle Variablen; auskommentierte Zeilen zeigen den Standardwert. Für eine erste Installation reichen die Vorgaben meist aus. Diese Variablen solltest du prüfen:

Die Secrets erzeugt in diesem Fall start.sh beim ersten Start. Das Passwort des LDAP-Dienstkontos trägst du selbst in secrets/ldap_bind_password.txt ein, siehe LDAP-Anmeldung .

Zugangsdaten gehören nicht in die .env, sondern in das Verzeichnis secrets/. Alle Variablen beschreibt das Kapitel Konfiguration .

3. Secrets

Das Skript scripts/init-secrets.sh legt alle fehlenden Secrets im Verzeichnis secrets/ an. Vorhandene Dateien überschreibt es nie. setup-opbweb.sh ruft es auf, start.sh führt es bei jedem Start ohnehin aus. Du kannst es auch selbst aufrufen:

./scripts/init-secrets.sh

Das Skript erzeugt diese Dateien:

Zusätzlich legt das Skript das leere Verzeichnis certs/ldap/ an.

Das Verzeichnis secrets/ bekommt die Rechte 750, die Dateien 444. Docker reicht die Secret-Dateien mit den Rechten des Hosts in die Container durch. Dort laufen die Prozesse unter anderen Benutzern (MariaDB, Redis, die Anwendung als appuser mit UID 1000); mit 600 könnten sie die Dateien auf einem Linux-Host nicht lesen. Andere Benutzer des Hosts halten die Rechte des Verzeichnisses fern.

Beim ersten Lauf zeigt das Skript das Passwort des ersten Administrators genau einmal an:

  >>> Erstes Admin-Konto: Benutzer 'admin', Passwort: <Passwort>
  >>> (steht auch in secrets/admin_password.txt; bitte nach der ersten Anmeldung ändern)

Notiere dir das Passwort oder lies es später aus secrets/admin_password.txt.

4. TLS-Zertifikat

oPBWeb läuft immer mit HTTPS. Port FRONTEND_HTTP_PORT leitet nur auf HTTPS weiter, COOKIE_SECURE setzt das Setup auf true. Für das Zertifikat gibt es drei Wege, das Setup wählt selbst:

fullchain.pem enthält das Serverzertifikat mit allen Zwischenzertifikaten, key.pem den privaten Schlüssel ohne Passwort. Liegt nur eine der beiden Dateien vor oder passen sie nicht zusammen, bricht das Setup mit einer Meldung ab.

Die CA des LDAP-Servers legst du genauso als ldap-ca.pem neben das Skript; das Setup verschiebt sie nach certs/ldap/ und schlägt sie bei den LDAP-Fragen als CA-Datei vor, siehe LDAP-Anmeldung .

Ein eigenes Zertifikat später einspielen oder erneuern: fullchain.pem und key.pem neben das Skript legen, ./setup-opbweb.sh --updateonly ausführen und das Frontend neu starten (docker restart opbweb-frontend).

5. Images bereitstellen und Stack starten

oPBWeb hat drei eigene Images: Backend (für api und worker), Frontend und garage-init. Welchen Weg du nimmst, hast du im Setup festgelegt.

Images lokal bauen

Starte den Stack und baue dabei die Images:

./start.sh --build

Der erste Build dauert einige Minuten, weil alle Abhängigkeiten heruntergeladen werden. Der Host braucht dafür Internetzugang, siehe Voraussetzungen .

Images aus einer Registry

Die GitLab-CI baut die Images und legt sie mit Versionsnummer und als latest in der Registry des Projekts ab (<Registry>/backend, …/frontend, …/garage-init, siehe Build und Auslieferung ). setup-opbweb.sh trägt die vollständigen Namen als BACKEND_IMAGE, FRONTEND_IMAGE und GARAGE_INIT_IMAGE in die .env ein. Hole die Images (falls du das nicht schon im Setup erledigt hast) und starte ohne --build. Die Registry des Projekts ist öffentlich; nur bei einer eigenen Registry, die eine Anmeldung verlangt, meldest du dich vorher mit docker login <Registry-Host> an:

docker compose pull
./start.sh

Gebaut wird auf diesem Host dann nichts; Internetzugang zum Bauen braucht nur der Rechner, der die Images baut.

start.sh

start.sh prüft, ob .env vorhanden ist, ruft scripts/init-secrets.sh auf, startet die Container im Hintergrund und zeigt anschließend ihren Status an.

Die Optionen lassen sich kombinieren, zum Beispiel ./start.sh --build --logs.

Was beim ersten Start passiert

Die Dienste starten in fester Reihenfolge, jeder wartet auf seine Abhängigkeiten:

1. db, redis und garage starten und melden sich über ihre Healthchecks als bereit.
2. garage-init richtet den Objektspeicher ein: Layout, Zugangsschlüssel opbweb und Bucket packages. Danach beendet sich der Container. Das passiert bei jedem Start erneut und ändert an vorhandenen Daten nichts.
3. api wartet bis zu 60 Sekunden auf die Datenbank, spielt die Datenbankmigrationen ein und legt das erste Administrator-Konto an, solange noch kein Benutzer existiert. Im Log steht dann „Initial admin ‘admin’ created“.
4. worker startet und meldet sich regelmäßig per Heartbeat.
5. frontend wählt je nach Zertifikat HTTPS oder HTTP und meldet „TLS-Zertifikat gefunden – HTTPS auf Port 443“ bzw. „Kein TLS-Zertifikat – HTTP auf Port 80“. Die Portangabe bezieht sich auf den Container; nach außen gelten die Ports aus der .env.

Alle Dienste starten mit restart: unless-stopped und laufen nach einem Neustart des Hosts automatisch wieder an.

6. Installation prüfen

Prüfe zuerst den Status der Container:

docker compose ps

Die Dienste opbweb-frontend, opbweb-api, opbweb-worker, opbweb-db, opbweb-redis und opbweb-garage müssen laufen. opbweb-garage-init ist normalerweise bereits beendet (Exit-Code 0); docker compose ps -a zeigt auch beendete Container. Bei Problemen helfen die Logs, zum Beispiel:

docker logs opbweb-api
docker logs opbweb-worker

Öffne anschließend oPBWeb im Browser unter https://<host>/ (bzw. http://<host>/ ohne Zertifikat, bei abweichenden Ports mit Portangabe). Nach der Anmeldung zeigt die Seite Systemstatus den Zustand von Datenbank, Redis, Objektspeicher, Worker und opsi-Server. Solange noch kein Configserver eingerichtet ist, meldet die Zeile opsi-Server einen Fehler – das ist vor der Ersteinrichtung normal. Mehr dazu unter Systemstatus .

Ohne Anmeldung kannst du die API prüfen:

curl -k https://<host>/api/health

Die Antwort enthält "status":"ok" und die Backend-Version.

Stack stoppen

./stop.sh

Das Skript fährt alle Container herunter und entfernt sie. Die Docker-Volumes mit Datenbank und Objektspeicher bleiben erhalten; beim nächsten ./start.sh ist alles wieder da.

Wie geht es weiter?

• Ersteinrichtung – Configserver (in der Ansicht Depots), Depot-Stufen und Benutzer in der Oberfläche einrichten.
• Konfiguration – alle Variablen, Secrets und Zeitlimits.
• LDAP-Anmeldung – Anmeldung über das Verzeichnis.
• Betrieb und Aktualisierung – Logs, Updates, Migrationen.
• Sicherung und Wiederherstellung – was du sichern musst.

Ersteinrichtung

Rolle: Administrator

Überblick

Nach der Installation ist oPBWeb erreichbar, kennt aber noch keinen opsi-Server und hat nur ein Konto: den ersten Administrator. In der Ersteinrichtung meldest du dich mit diesem Konto an, änderst sein Passwort, verbindest oPBWeb mit einem oder mehreren opsi-Configservern, legst die Stufen der Depots fest und richtest die ersten Benutzer ein.

Du brauchst dafür das Admin-Passwort aus secrets/admin_password.txt, die Zugangsdaten des technischen opsi-Benutzers und einen Shell-Zugang zum Configserver, um den Fingerabdruck des CA-Zertifikats zu prüfen.

1. Als Administrator anmelden

1. Öffne oPBWeb im Browser, zum Beispiel https://opbweb.example.local/.

   

2. Trage bei Benutzername admin ein (bzw. den Wert von ADMIN_USERNAME aus der .env).

3. Trage bei Passwort das Passwort aus secrets/admin_password.txt ein.

4. Klicke auf Anmelden.

Nach der Anmeldung siehst du die Paketliste. Unten in der Statusleiste erscheint der orange Hinweis „Kein Configserver eingerichtet“, bis du den ersten Configserver eingerichtet hast.

2. Admin-Passwort ändern

Das erzeugte Passwort steht im Klartext in secrets/admin_password.txt. Ändere es deshalb direkt nach der ersten Anmeldung:

1. Klicke oben rechts auf deinen Avatar (die Initialen).
2. Wähle Passwort ändern.
3. Trage das Aktuelle Passwort ein, dann zweimal das neue Passwort in Neues Passwort und Neues Passwort wiederholen. Das Passwort muss mindestens 10 Zeichen lang sein.
4. Klicke auf Speichern.

Die Datei secrets/admin_password.txt wird dabei nicht geändert. Sie wird nur ausgewertet, solange noch kein Benutzer existiert, also beim allerersten Start.

3. Configserver einrichten

oPBWeb kann mit mehreren opsi-Configservern arbeiten, zum Beispiel einem Test- und einem Produktivsystem. Du legst sie in der Ansicht Depots an; das Passwort wird verschlüsselt in der Datenbank gespeichert und nur vom Worker entschlüsselt. Für jeden weiteren Configserver wiederholst du die folgenden Schritte.

1. Klicke in der Aktivitätsleiste links auf Depots.

2. Klicke im Kopf der linken Liste auf + („Neuer Configserver“).

3. Trage folgende Werte ein:

   • Name – eine Bezeichnung, zum Beispiel Configserver. Lässt du das Feld leer, wird der Hostname aus der URL verwendet.
   • URL des Configservers – vollständiger Hostname mit Port 4447, zum Beispiel https://opsi.example.local:4447. Verwende den FQDN, nicht die IP-Adresse: Das Zertifikat von opsiconfd lautet auf den Namen.
   • Technischer Benutzer – der opsi-Benutzer mit Admin-Rechten (Vorgabe opsiadm).
   • Passwort – das Passwort dieses Benutzers.
   • Stufe – Produktion (Vorgabe), Staging oder Test. Für einen Testserver wählst du Test; alle Depots des Servers übernehmen diese Stufe (siehe Schritt 4 ).

4. Lass TLS-Zertifikat des Servers prüfen (empfohlen) eingeschaltet.

5. Klicke unter VERTRAUTES CA-ZERTIFIKAT auf Vom Server holen. oPBWeb lädt das CA-Zertifikat des Configservers und zeigt es im Dialog CA-Zertifikat des Servers mit seinem SHA-256-Fingerabdruck an.

6. Ermittle auf dem Configserver den Fingerabdruck der opsi-CA:

   openssl x509 -in /etc/opsi/ssl/opsi-ca-cert.pem -noout -fingerprint -sha256
   

7. Vergleiche beide Fingerabdrücke. Stimmen sie überein, klicke auf Vertrauen. Weichen sie ab, brich ab und kläre, mit welchem Server du tatsächlich verbunden bist.

8. Klicke auf Hinzufügen. Die Meldung „Configserver gespeichert“ bestätigt das.

   

Direkt nach dem Hinzufügen startet oPBWeb Verbindung testen für den neuen Server. Der Test prüft Anmeldung, Admin-Rechte und opsi-Version und liest die Depots des Configservers; sie erscheinen danach in der Liste unter dem Server. War er erfolgreich, wird der Punkt vor dem Servernamen grün und das Abzeichen im Formular zeigt „erreichbar“. Später kannst du den Test im Formular des Servers mit Verbindung testen jederzeit wiederholen.

Unter dem CA-Zertifikat siehst du danach eine Zeile wie „Zuletzt geprüft … · opsi 4.3 … · 2 Depots“.

Schlägt der Test fehl, prüfe die häufigsten Ursachen:

Weitere Ursachen beschreibt das Kapitel Fehlersuche . Alle Funktionen des Formulars, auch das Entfernen eines Configservers und den Wechsel des CA-Zertifikats bei einer Rotation, erklärt das Kapitel Configserver .

4. Depot-Stufen festlegen

Mit dem erfolgreichen Verbindungstest liest oPBWeb die Depots vom Configserver. Danach gleicht der Worker die Depots aller Configserver alle 5 Minuten automatisch ab; unter Depots kannst du mit Abgleichen (ein Configserver) oder ⟳ (alle Configserver) auch selbst einen Abgleich anstoßen.

Jedes Depot hat eine Stufe: Test, Staging oder Produktion. Packager dürfen auf Test- und Staging-Depots installieren, auf produktive Depots nur Releaser. Ein Depot erbt die Stufe seines Configservers; das erkennst du am kursiven Abzeichen. Hast du die Stufe beim Configserver schon passend gewählt, ist hier nichts mehr zu tun.

Sollen einzelne Depots von der Stufe ihres Configservers abweichen, zum Beispiel ein Test-Depot an einem produktiven Configserver, stellst du die Stufe am Depot selbst um:

1. Klicke in der Aktivitätsleiste auf Depots.

2. Wähle links das Depot aus.

3. Wähle im Bereich Einstellungen bei Stufe den gewünschten Wert, zum Beispiel Test. Mit „wie Configserver (…)“ erbt das Depot wieder die Stufe seines Servers.

   

4. Klicke auf Speichern. Die Meldung „Einstellungen gespeichert“ bestätigt die Änderung, und das Depot trägt in der Liste das Abzeichen Test.

5. Wiederhole die Schritte für alle weiteren abweichenden Depots.

Die weiteren Depot-Einstellungen (Dienst-URL, Aktiv) beschreibt das Kapitel Depot-Verwaltung .

5. Erste Benutzer anlegen

Lege für alle, die mit oPBWeb arbeiten, eigene Konten an, statt das Admin-Konto zu teilen:

1. Klicke in der Aktivitätsleiste auf Benutzer und Rollen.
2. Klicke auf Neuer Benutzer.
3. Fülle Benutzername, Rolle, Name, E-Mail, Standardsprache und Neues Passwort aus und klicke auf Anlegen.

Welche Rolle was darf und wie du Konten später bearbeitest, sperrst oder löschst, steht im Kapitel Benutzer und Rollen .

6. Optional: Anmeldung über LDAP

Zusätzlich zu lokalen Konten können sich Benutzer mit ihrem Verzeichniskonto (LDAP oder Active Directory) anmelden. Die Rolle ergibt sich dann bei jeder Anmeldung aus der Gruppenmitgliedschaft. Die Einrichtung erfolgt über die .env und ist Aufgabe der technischen Administration, siehe LDAP-Anmeldung .

Ergebnis

Nach der Ersteinrichtung:

• ist das Admin-Passwort geändert,
• sind die Configserver eingerichtet und „erreichbar“, die Statusleiste zeigt keinen opsi-Hinweis mehr,
• sind die Depots bekannt und haben die richtige Stufe (Test, Staging oder Produktion),
• können sich die ersten Benutzer anmelden.

Wie die Arbeit in oPBWeb dann aussieht, zeigt das Kapitel Erste Schritte .

Testumgebung

Zielgruppe: Technische Administration, alle, die oPBWeb ausprobieren wollen

Überblick

Die Testumgebung startet oPBWeb zusammen mit zwei nachgebauten opsi-Servern (opsiconfd-Mocks). Damit probierst du den Editor und den ganzen Ablauf aus, vom Import aus der Workbench über das Bauen bis zur Übernahme von Test nach Produktion, ohne einen echten opsi-Server.

Die Mocks laufen mit dem Backend-Image von oPBWeb, ihr Code kommt aus tools/opsi-mock/opsi_mock.py. Beides liegt im Klon des Repositorys und im Stack-ZIP . Die Kurzfassung dieser Anleitung steht als START-TEST-ENVIRONMENT_de.md daneben.

Voraussetzungen

• Docker mit dem Compose-Plugin und openssl, siehe Voraussetzungen . Ein Zugang zu einem opsi-Server ist nicht nötig.
• Die Dateien von oPBWeb, ein Klon oder das Stack-ZIP, siehe Installation .

Einrichten und starten

1. Wechsle in das Verzeichnis mit den Dateien und führe das Setup aus:

   ./setup-opbweb.sh
   

   Die Vorgaben passen für einen Test, Enter übernimmt sie. Bei der Frage nach den Images wählst du r (Registry) oder im Klon l (lokal bauen). Im Stack-ZIP stellt das Setup die Registry-Images aus versions.env ein. Am Ende zeigt das Setup das Passwort des ersten Administrators admin; es steht auch in secrets/admin_password.txt.

2. Starte den Stack mit den Mocks:

   ./start.sh --test            # Images aus der Registry
   ./start.sh --test --build    # im Klon mit lokal gebauten Images
   

   --test nimmt docker-compose.test.yml hinzu. Beim ersten Start legt die API die beiden Mocks als Configserver an, solange noch kein opsi-Server eingerichtet ist (Variable OPSI_MOCK_SERVERS im Overlay). Technischer Benutzer ist opsiadm mit dem Passwort mock, die TLS-Prüfung ist aus.

3. Öffne https://localhost/ (bzw. den Port aus dem Setup) und melde dich als admin an. Ohne eigenes Zertifikat hat das Setup ein self-signed erzeugt; bestätige die Warnung des Browsers.

4. Öffne Depots. Links stehen opsi-prod (Produktion) und opsi-test (Test). Klick auf opsi-test und dann auf Verbindung testen; oPBWeb liest die Depots des Servers ein. Mach dasselbe für opsi-prod. Ohne diesen Schritt kommen die Depots mit der nächsten opsi-Prüfung, spätestens nach 5 Minuten.

Ablauf ausprobieren

1. Klick in Pakete auf Workbench … und wähl den Configserver opsi-test. Die Workbench des Mocks enthält das Projekt mock-demo und den Ordner kein-paket (kein gültiges Projekt, zum Ausprobieren der Fehlermeldung). Wähl mock-demo aus und klick auf Ausgewählte importieren (1), siehe Pakete .
2. Öffne mock-demo mit Im Editor öffnen, ändere etwas, zum Beispiel in CLIENT_DATA/setup.opsiscript im Scripteditor , und speichere.
3. Klick auf Bauen und danach auf Installieren …. Wähl die beiden Depots von opsi-test (Stufe Test) und klick auf Installieren. Die Version ist danach freigegeben, siehe Bauen und Verteilen .
4. Klick in Pakete auf Übernehmen …, stell Von Test nach Produktion ein und klick auf Übernehmen (1). oPBWeb installiert denselben Build auf den Depots von opsi-prod, siehe Auf andere Stufe übernehmen .
5. Unter Depots siehst du je Depot die installierten Produkte, die Dateien und das Repository, unter Jobs die Protokolle aller Schritte.

Was die Mocks können

• Nachgebildet: Anmeldung, Workbench, Repository und Depot per WebDAV, Installieren und Deinstallieren (das hochgeladene Paket wird gelesen und die .md5 geprüft), installierte Produkte je Depot, vier Beispiel-Clients (client1.mock bis client4.mock) für „Setup auf allen Clients anfordern, auf denen das Produkt installiert ist“. Das Produkt hwaudit ist auf den Depots außer dem Configserver gesperrt, zum Ausprobieren von Entsperren.
• Zustand im Speicher: Ein Neustart der Mocks (oder des Stacks) setzt sie zurück, mit frischer Workbench und ohne die installierten Pakete. Die Datenbank von oPBWeb behält Pakete, Versionen und Benutzer; die Depotstände gleicht der nächste Abgleich an.
• Kein Ersatz für einen echten Server: Rechte, admin-networks, Zertifikate und das Verhalten entfernter Depots zeigt nur ein echter opsi-Server.

Beenden, weiterarbeiten, entfernen