Test Environment

Audience: Technical administration, anyone who wants to try oPBWeb

Overview

The test environment starts oPBWeb together with two simulated opsi servers (opsiconfd mocks). With them you try the editor and the whole workflow, from the import from the workbench through building to promoting from Test to Production, without a real opsi server.

The mocks run with the oPBWeb backend image, their code comes from tools/opsi-mock/opsi_mock.py. Both are part of the repository clone and of the stack ZIP . The short version of this guide is next to them as START-TEST-ENVIRONMENT_en.md.

Requirements

• Docker with the Compose plugin and openssl, see Requirements . Access to an opsi server is not needed.
• The oPBWeb files, a clone or the stack ZIP, see Installation .

Set up and start

1. Change into the directory with the files and run the setup:

   ./setup-opbweb.sh
   

   The defaults suit a test, Enter accepts them. At the images question choose r (registry) or, in a clone, l (build locally). In the stack ZIP the setup selects the registry images from versions.env. At the end the setup shows the password of the first administrator admin; it is also in secrets/admin_password.txt.

2. Start the stack with the mocks:

   ./start.sh --test            # images from the registry
   ./start.sh --test --build    # in a clone with locally built images
   

   --test adds docker-compose.test.yml. On the first start the API registers the two mocks as config servers, as long as no opsi server is configured yet (variable OPSI_MOCK_SERVERS in the overlay). The technical user is opsiadm with the password mock, TLS verification is off.

3. Open https://localhost/ (or the port from the setup) and sign in as admin. Without your own certificate the setup created a self-signed one; confirm the browser warning.

4. Open Depots. opsi-prod (Production) and opsi-test (Test) are listed on the left. Click opsi-test, then Test connection; oPBWeb reads the depots of the server. Do the same for opsi-prod. Without this step the depots arrive with the next opsi check, after 5 minutes at the latest.

Trying the workflow

1. In Packages, click Workbench … and choose the config server opsi-test. The workbench of the mock contains the project mock-demo and the folder kein-paket (not a valid project, to see the error message). Select mock-demo and click Import selected (1), see Packages .
2. Open mock-demo with Open in editor, change something, for example in CLIENT_DATA/setup.opsiscript in the script editor , and save.
3. Click Build, then Install …. Select the two depots of opsi-test (stage Test) and click Install. The version is released afterwards, see Build and Deploy .
4. In Packages, click Promote …, set From Test to Production and click Promote (1). oPBWeb installs the same build on the depots of opsi-prod, see Promoting to another stage .
5. Under Depots you see the installed products, the files and the repository of each depot, under Jobs the logs of all steps.

What the mocks can do

• Reproduced: sign-in, workbench, repository and depot via WebDAV, install and uninstall (the uploaded package is read and its .md5 checked), installed products per depot, four sample clients (client1.mock to client4.mock) for “Request setup on all clients that have the product installed”. The product hwaudit is locked on the depots except the config server, to try Unlock.
• State in memory: restarting the mocks (or the stack) resets them, with a fresh workbench and without the installed packages. The oPBWeb database keeps packages, versions and users; the next sync brings the depot states up to date.
• No substitute for a real server: permissions, admin-networks, certificates and the behaviour of remote depots only show on a real opsi server.

Stop, continue, remove