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