Functional Administration

• Users and Roles
• Audit Log
• Config Servers
• Settings for New Packages
• Depot Management
• System Status

Users and Roles

Role: Administrator

Overview

Under Users and roles, you manage all accounts that can sign in to oPBWeb. Each account has exactly one role, which defines what it may do in the UI. Besides local accounts that you create yourself, there are directory accounts from LDAP whose role is derived from their groups in the directory.

Open the area with the Users and roles icon at the bottom of the activity bar. It has two tabs: Users (with the number of accounts) and Audit log. The audit log is described in the Audit log chapter.

Roles and permissions

There are four roles. They build on each other: each role has all permissions of the roles above it and adds its own.

The UI hides or disables buttons when the role is not sufficient. Every permission is still checked on the server. If a permission is missing, the message “No permission for this action.” appears.

Viewer

• view the package list and package details, open the package editor read-only, view the Source of the control file
• download built .opsi and .md5 files
• read snippets
• follow all jobs with their live log, cancel their own queued jobs
• view depots and download files from them
• see the services table in System status
• set their own Default language, change their own password (local accounts only)

Packager

• create packages: New package, Import, Workbench …, Meta package …
• edit drafts and Build, create a New version, create, upload, rename and delete files in the package
• Archive and Restore packages
• Delete this version, Back to draft and Delete package …, as long as the package or version is not installed on a production depot (see stage rule )
• Compare with workbench …, Export to workbench …, write to /workbench of every config server and Import into oPBWeb
• Sync depots and read the repository
• on test and staging depots: Install …, Uninstall …, Promote … or Promote to another stage …, Unlock products, delete repository files
• maintain their own snippets and snippet categories

Releaser

• all depot actions of the Packager (install, uninstall, promote, unlock, delete from repository) on production depots as well
• delete versions and packages and set versions back to draft, even if they are installed on a production depot

Administrator

• the Users and roles (including Audit log) and Settings areas
• add, change and remove config servers under Depots
• depot settings (Stage, Service URL, Enabled) and Remove for depots
• maintain global snippets
• cancel queued jobs of other users
• the Database, Object storage, Clean up … and Bucket contents sections in System status

The stage rule for depots

What a Packager may do with a package on a depot depends on the depot’s Stage, not only on their role. The table shows who may perform which action on which stage:

For deleting and for Back to draft, it matters where the package is currently installed: if the version (or, when deleting the package, any of its versions) is on a production depot, the Releaser role is required. A Packager then gets a message listing the depots on which the package is installed. This is based on the state of the last depot sync.

Depots inherit the stage of their config server unless you give them their own. New config servers start in the Production stage. So a Packager can install on their depots only after you set the config server or the individual depot to Test or Staging. In the Install … dialog, a locked depot is shown with the hint “requires releaser role”. How to change the stage is described in Depot management .

The user list

The Users tab shows all accounts in a table. The User details pane for the selected account opens to its right.

Below the fields, the user details also show Source, Created and Last sign-in.

Local accounts

Local accounts sign in with a password that oPBWeb stores itself. The first administrator account (admin) is created when the system starts for the first time; you create all further local accounts here.

Creating an account

1. Click New user in the toolbar.

   

2. Enter the User name. Allowed are 2 to 128 characters consisting of letters, digits and . _ @ -.

3. Select the Role. The dialog suggests Viewer, the role with the fewest permissions.

4. Optionally enter Name and Email. The email address appears in changelog entries of this user.

5. Select the Default language (Deutsch or English). The UI starts in this language after every sign-in.

6. In the New password field, set an initial password with at least 10 characters.

7. Click Create.

The new account appears in the list and is selected right away. Pass the initial password to the user through a secure channel; they can then replace it themselves under Change password in the avatar menu.

Editing an account

1. Select the account in the list.
2. In the User details, change Name, Email, Role or Default language.
3. Click Save. “Saved” appears in the toolbar.

Every user can also change their default language themselves in the avatar menu (see Account and language ).

Disabling an account

A disabled account is kept with all its data but can no longer sign in. The sign-in fails with “Account is disabled.”

1. Select the account.
2. Clear the Account is active checkbox.
3. Click Save.

To re-enable it, select the checkbox again and save.

Setting a password

If a user has forgotten their password, set a new one:

1. Select the account and click Set password.
2. Enter the new password twice (at least 10 characters).
3. Confirm the dialog. “Password set” appears in the toolbar.

You do not need the old password for this. Setting a password also lifts an existing lock.

Unlocking an account

After 5 wrong passwords in a row, oPBWeb locks a local account for 15 minutes. During the lock, the sign-in message is “Account locked until HH:MM.”, even if the password is correct. In the list, the account shows as locked.

You do not have to wait for the lock to expire:

1. Select the locked account.
2. Click Unlock. The button only appears for locked accounts.

The user can sign in again immediately. If they have actually forgotten their password, use Set password instead.

Deleting an account

1. Select the account.
2. Click Delete user.
3. Confirm the prompt “Delete user?” with Delete user.

The account is removed permanently. Entries in the Audit log are kept with the user name. You cannot delete your own account; the button is disabled for it.

Protection of the last administrator

oPBWeb prevents a situation where nobody can reach the administration any more. For the last active administrator account:

• You cannot give it a lower role or disable it. The message is “The last active administrator cannot be removed.”
• You cannot delete it: “The last active administrator cannot be deleted.”

So create a second administrator account first before you downgrade or remove the existing one.

Directory accounts (LDAP)

If technical administration has enabled LDAP sign-in, users from the directory (for example Active Directory) can sign in as well. You recognize these accounts by the source Directory (LDAP). The setup is described in LDAP Sign-in .

Directory accounts follow different rules than local accounts:

• Creating: You do not create them yourself. The account is created automatically at the first successful sign-in.
• Role: The role is derived from the user’s LDAP groups at every sign-in. If the user is in several matching groups, the highest role applies. The Role field is locked, and below it you see “The role of directory accounts is derived from their LDAP groups at every sign-in.” To change the role, change the group membership in the directory.
• Name and email: oPBWeb takes these values from the directory at every sign-in. Changes you save here are overwritten at the next sign-in.
• Password: Directory accounts have no password in oPBWeb. Set password is missing, and the user changes their password in the directory. The lock after failed attempts also applies only to local accounts.
• Disabling: Works as for local accounts. A disabled directory account can no longer sign in, even if it is still authorized in the directory.
• Deleting: A deleted directory account is recreated at the next sign-in as long as the user is still in a matching group. To exclude someone permanently, disable the account or remove the user from the groups.

Local accounts always sign in locally, even when LDAP is enabled. This keeps the local administrator admin reachable even if the directory fails.

Audit Log

Role: Administrator

Overview

The audit log records who triggered which important action in oPBWeb and when: sign-ins and changes to accounts, packages, depots and settings. You find it under Users and roles on the Audit log tab. Only administrators can read it.

Entries can be neither changed nor deleted in the UI. Even if you delete a user account, its entries are kept with the user name.

Reading the audit log

The newest entries are at the top. Each row has these columns:

Above the table, you see how many entries are displayed, for example “100 of 2,345 entries”. Entries are loaded 100 at a time. Use Load more below the table to fetch the next 100.

Filtering entries

1. In the Action field, enter the beginning of an action key. user. finds all actions on user accounts, auth.login_failed only the failed sign-ins.
2. In the User name field, enter a user name. The name must be complete and match exactly.
3. Click Filter.

You can combine both fields. To see all entries again, clear the fields and click Filter again.

Recorded actions

For actions that start a job (…_started), the audit log only shows who started the job. Whether it succeeded is shown under Jobs .

What is not recorded

Some actions are deliberately not recorded in the audit log:

• new changelog entries
• saving file contents in the package (script editor)
• creating, moving, renaming and deleting files and folders in the package
• creating, changing and deleting individual snippets and snippet categories
• depot sync
• reading the repository and scanning the workbench
• Fetch from server (CA certificate) and Test connection
• the dry run when cleaning up object storage

Many of these actions still leave a trace: everything that runs as a job appears in the job list with the user who started it and its log.

Config Servers

Role: Administrator

Overview

oPBWeb works with any number of opsi config servers, for example a test, a staging and a production system. Through each config server, oPBWeb reads its depots, installs packages and accesses /repository, /workbench and /depot. Each depot belongs to exactly one config server.

You manage the config servers in the Depots view in the activity bar. As long as no config server is configured, depots, installing and the workbench do not work, and the status bar shows “No config server configured”.

Config servers in the depot list

The list on the left of the Depots view is grouped by config server. Each config server is shown as a bold row, with its depots indented below it. The arrow in front of the name collapses or expands the depots of a server, and the “Search depots” field above searches the list (see Depots ).

There are two buttons at the top of the list:

• + (“New config server”) adds another config server. Only administrators see it.
• ⟳ (“Synchronize all config servers”) syncs the depots of all config servers. The button is available from the Packager role.

Clicking a config server row opens the server’s form on the right. Next to the heading, you see the stage badge and the result of the last check: reachable or not reachable. The header contains the buttons Remove …, Test connection, Sync and Save.

Users without the Administrator role see a card instead of the form, with name, stage, Config server URL, State (reachable or not reachable including the error message) and the validity of the CA certificate. From the Packager role, the card has a Sync button.

The fields

With TLS verification enabled, oPBWeb trusts only the CA certificate you store under TRUSTED CA CERTIFICATE, not the certificate authorities of the operating system. Without a stored CA certificate, an https connection with TLS verification cannot be saved (“A CA certificate is required for the TLS check.”).

What the stage means for permissions and how depots inherit it is described in Depot management .

Adding a config server

1. Open Depots in the activity bar.

2. Click + at the top of the list on the left. The “New config server” form appears on the right.

3. Enter Config server URL, Technical user and Password, and optionally a Name.

4. Select the Stage, for example Test for a test server.

5. Under TRUSTED CA CERTIFICATE, click Fetch from server. oPBWeb loads the server’s CA certificate in a short job; meanwhile the button shows “Loading …”.

6. The CA certificate of the server dialog shows the certificate with its SHA-256 fingerprint. Compare it with the fingerprint on the config server:

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

7. If both match, click Trust. Below the certificate table, “Changed CA certificate – save to apply.” appears.

8. Click Add. The message “Config server saved” confirms this.

Right after adding, oPBWeb runs Test connection for the new server. The test also reads the server’s depots; they then appear in the list below the config server. Cancel discards a new config server before it is saved.

If the URL is already configured, oPBWeb refuses to save: “A config server with this URL is already configured: …”.

Changing a config server

Select the config server in the list, change the fields and click Save. As long as there are unsaved changes, Test connection and Sync are disabled. If you switch to another entry in the list with unsaved changes, oPBWeb asks for confirmation first.

Loading the CA certificate from a file

Instead of fetching the certificate from the server, you can upload it as a file, for example if you copied opsi-ca-cert.pem from the server beforehand:

1. Click Load PEM file … and select a file with the extension .pem, .crt or .cer.
2. “New PEM file loaded, it is checked on save.” appears.
3. Click Save (for a new server, Add). Only now does the server check the file. If it does not contain a valid certificate, the message is “Not a valid PEM certificate: …”.

Remove below the certificate table deletes the stored CA certificate; this, too, only takes effect when you click Save.

Removing a config server

1. Select the config server in the list.
2. Click Remove … in the header.
3. Confirm the prompt “Remove config server name? Its 3 depots disappear from oPBWeb (nothing changes on the opsi server).”

The message “Config server name removed” confirms this. oPBWeb deletes the config server, its depots with their settings and the product lists of these depots. Packages and jobs are kept. Nothing changes on the opsi server itself.

Validity of the CA certificate

The table under TRUSTED CA CERTIFICATE lists every certificate in the stored file with Certificate (subject), Validity and SHA-256 fingerprint. If the file contains no CA certificate, “not a CA certificate” is shown after the subject.

The badge in the Validity column shows the remaining lifetime:

From 60 days before expiry, the status bar additionally shows “name: CA expires in {n} days”, and the opsi server row in System status is set to error.

CA rotation

opsi servers renew their CA themselves. Afterwards, the certificate stored in oPBWeb no longer matches the server’s, and connections with TLS verification fail. oPBWeb detects this during the regular check and reports it in three places:

• in the status bar: “name: new CA certificate” (a link to Depots for administrators)
• in System status in the opsi server row
• in the config server form as a box “The server serves a new CA certificate” above the fields

To accept the new certificate:

1. Open Depots and select the affected config server. The box shows the new certificate with its expiry date and SHA-256 fingerprint.
2. Compare the fingerprint with /etc/opsi/ssl/opsi-ca-cert.pem on the server (command as above).
3. Click Accept new certificate. The message “New CA certificate accepted” confirms this; no further save is needed.

Remaining warnings in the status bar and system status disappear with the next check, after five minutes at the latest. If you do not want to wait, click Test connection.

Testing the connection

Test connection checks the saved settings of the selected config server immediately. The button is disabled as long as there are unsaved changes (“Please save first”).

The test runs as a job and checks, in order:

• whether the stored CA certificate matches the server
• whether signing in with the technical user and password works
• whether the technical user has opsi admin rights
• which opsi version is running and which depots the server reports

If the test succeeds, oPBWeb then syncs the depots of this server. The result appears as “Connection OK” or as an error message. Below the form, you then see, for example, “Last checked 10/15/26, 09:30 · opsi 4.3.x · 3 depots” or the error message of the last check in red.

Syncing

Sync in the config server form reads only the depots of this server, their installed products and the project folders of its workbench again; the job is called “Synchronize depots (name)”. ⟳ at the top of the list syncs all config servers (“Synchronize depots of all config servers”). A sync never touches the depots of another config server. What happens to the depots during a sync is described in Depot management .

Automatic background check

You do not have to run the test by hand regularly. The worker checks all config servers every five minutes (default, configurable under Settings → Worker) in the same way and syncs the depots of every reachable server. You see the result:

• in the dot in front of the server name in the depot list, in the reachable / not reachable badge and in “Last checked …” in the form
• in the opsi server row in System status, with one entry per config server
• as an orange hint in the status bar if the server is missing, the CA was rotated or the CA expires soon

Common errors

Error messages come from the server and follow the interface language. Details that opsiconfd itself returns (for example HTTP errors) are shown unchanged.

Settings for New Packages

Role: Administrator

Overview

Under Settings, you define the values new packages and meta packages start with, and which mail address changelog entries get when the user has no email. The values apply to all users. Only administrators may change them.

The defaults only take effect when a package is created. Existing packages and imported packages (.opsi or workbench) keep their own values, and every Packager can override the defaults in the package editor.

You do not set up the connection to the opsi config servers here but in the Depots view, see Config servers .

Changing settings

1. Open Settings at the bottom of the activity bar.
2. Change the values you want in the New packages, Meta packages or Changelog blocks.
3. Click Save in the toolbar. The message “Settings saved” confirms this.

Revert restores the last saved values. Both buttons are only active if you have changed something. If you leave the page with unsaved changes, oPBWeb asks for confirmation.

New packages

oPBWeb enters these values into every package created via New package.

Meta packages

Meta packages bundle several products. They install their products through dependencies (action setup, order before); the setup script itself does nothing. The values apply to the Meta package … dialog in the package list.

The product version field in the Meta package … dialog is pre-filled with the Product version from the New packages block.

Changelog

If a user has entered an Email in their account, oPBWeb uses that address. So enter a domain here that fits your accounts, or maintain the email addresses in Users and roles . For directory accounts, the address comes from LDAP.

Worker

Changes apply from the next minute; the worker does not need a restart. The interval of the heartbeat (every 30 seconds) cannot be changed: the system status uses it to detect a failed worker.

Every saved change appears in the Audit log as settings.updated with the changed fields.

Depot Management

Role: Administrator

Overview

oPBWeb reads the list of depots from the configured opsi config servers. Each depot belongs to exactly one config server. As an administrator, you define for each depot which Stage it runs in, which Service URL oPBWeb uses to reach it and whether it is used at all (Enabled). The stage determines which role may install on the depot.

You find these settings under Depots. The list on the left is grouped by config server: each config server is shown as a bold row, with its depots indented below it, each with a stage badge and the number of products; for the config server’s own depot, for example, “config server · 120 products”. Additions such as “disabled” or “no longer present” also appear in the second line. How to add and maintain config servers is described in Config servers .

Select a depot on the left, and the Settings block is at the top on the right. All other roles only see the values; the fields are locked for them. The remaining functions of the depot view (installed products, files, repository, comparison) are described in Depots in the User Guide.

Stages: Test, Staging and Production

Every depot has one of three stages. It is shown as a badge in the depot list and in the depot’s header.

This lets Packagers try out new packages on test and staging depots, while only Releasers and Administrators deploy to production depots. In the Install … dialog, a Packager sees production depots with the hint “requires releaser role” and cannot select them. The complete role overview is in Users and roles .

Inherited stage

Every config server has a stage of its own. Its depots take it over as long as you do not set a stage of their own for a depot. You recognize an inherited stage by the italic, lighter badge with the tooltip “inherited from the config server”. If you change the stage of the config server, the stage of all depots that inherit it changes too.

So it is usually enough to set the stage once on the config server: a test server gets Test, and all its depots are test depots. You only need a stage of their own for individual depots that should differ from their config server.

Changing depot settings

1. Open Depots in the activity bar and select the depot on the left.
2. Set the fields in the Settings block:
   • Stage — “as config server (stage)” (the stage is inherited), Production, Staging or Test.
   • Service URL — address of opsiconfd on this depot, used by oPBWeb to upload packages and to access the depot’s files. Leave the field empty to use the default URL: the depot’s host name with the config server’s port, for example https://depot01.example.local:4447. For the config server itself, the default URL is the Config server URL from its form . The default URL is shown as a gray placeholder in the field.
   • Enabled — yes or no. A disabled depot stays in the list but is locked for install, uninstall, unlock and repository deletion. In the Install … dialog, it appears as “disabled”.
3. Click Save. The message “Settings saved” confirms this.

Below the fields, oPBWeb shows what actually applies: URL in use is the address oPBWeb uses to reach the depot; clicking it opens the depot in a new tab. You also see what opsi itself reports, such as the Repository and Depot paths and the URL under Reported by opsi.

How depots get into oPBWeb

oPBWeb syncs the depots with their config server:

• at every automatic check, that is every five minutes (default, configurable under Settings → Worker) for each reachable config server
• right after adding a config server and after Test connection in the config server form
• when a Packager or Administrator clicks Sync in Depots: in the header of a depot or of a config server, this syncs only that one config server (“Synchronize depots (name)”); ⟳ at the top of the list syncs all config servers (“Synchronize depots of all config servers”)

A sync never touches the depots of another config server. A sync via Sync or ⟳ also reads the workbench of the config server (for the “Workbench” information in the package list); the automatic sync does not; instead, the worker reads the workbench at its own interval (see Settings ). During a sync, the following applies:

Removing depots that have disappeared

A depot that the config server no longer reports stays in oPBWeb until you remove it. The detail view then shows “The config server no longer reports this depot. It is kept with its settings until an admin removes it.”

1. Select the depot in the list.
2. Click Remove in the header. The button only exists for depots that are no longer reported.
3. Confirm the prompt “Remove depot depot01.example.local and its settings from oPBWeb? Nothing changes on the opsi server.”

The message “Depot removed” confirms this. You cannot remove depots that the config server still reports; set them to Enabled no instead. If you remove an entire config server, all its depots disappear with it (see Removing a config server ).

Additional administrator permissions

Besides the depot settings, you have some permissions in daily work that other roles lack:

• Cancel other users’ jobs: Under Jobs, you can stop any queued job with Cancel, not just your own. Running jobs cannot be cancelled, not even by administrators. More on this in Jobs .
• Maintain global snippets: Only administrators create snippets with the Visibility “Global (everyone)”, change and delete them, or import snippets into the global area. Everyone else sees global snippets; Packagers can take them over as their own copy with Duplicate. How to use snippets is described in Snippets .

System Status

Role: Administrator

Overview

The System status area shows whether all oPBWeb services are running and gives administrators insight into how the database and object storage are used. Open it with the System status icon at the bottom of the activity bar.

All roles see the services table. Only administrators see the Database, Object storage (with Clean up …) and Bucket contents sections.

Checking services

In the toolbar, a badge summarizes the state: “All services reachable”, “At least one service is not reachable” or “API not reachable”. Next to it, you see “As of HH:MM:SS”. The table refreshes itself every ten seconds; Refresh reloads it immediately.

The texts in the Details column come from the server and follow the interface language.

The Status column shows OK or Error, Duration the response time of the check in milliseconds.

The opsi server row is set to Error as soon as one of the config servers is not reachable, serves a new CA certificate or its CA expires in less than 60 days, even if all others are fine. The entry of the affected server names the reason, for example “Server delivers a new CA certificate, please accept it under Depots”. What to do then is described in Config servers . If it shows “not checked yet”, the worker has not completed a check yet; the result arrives after five minutes at the latest.

Storage usage

The Database and Object storage sections are loaded when you open the page and with Refresh, not every ten seconds.

Database

Above the table, you see the total size, for example “48 MB in 21 tables”. The table lists every database table, largest first:

The sizes come from MariaDB statistics, which are updated with a delay. After larger changes, they are therefore not quite exact for a while.

Object storage

The object storage holds the package files and build results. Above the table, you see “Bucket “packages”: 4.8 GB in 1,523 objects”. The table splits the content into areas:

oPBWeb automatically deletes uploads and downloads older than 24 hours every night.

Below the table, up to three figures are shown:

• Savings through deduplication: “Package files: 12.6 GB across all versions, 4.1 GB actually stored, saved by deduplication 8.5 GB.” The more versions of a package exist, the greater the savings, because unchanged files are not stored twice.
• Unused blobs: “37 blobs are no longer used by any package file.” Such contents remain after versions or files have been deleted. You remove them with Clean up … .
• Missing blobs (red): “2 package files refer to missing blobs.” This should never happen and indicates a damaged or incompletely restored object storage. Contact technical administration.

Browsing the bucket contents

Under Bucket contents, you can browse the object storage like a file tree. The browser is read-only: you can view and download objects, but not change or delete anything.

1. Click a folder to open it. Use the path bar above the table (starting with /) or the “‹ up one level” row to go back.
2. Narrow down the list with the Filter field. ⟳ reloads the folder.
3. To download, click ↓ at the end of the row or double-click the row.

The table shows Name, Size and Modified. In the blobs/ and artifacts/ areas, there is an additional Used by column:

• A link leads to the package version that uses the object; for package files, the file path within the package follows.
• “+n” means that further versions or files use the same object. Hover over the cell to see the list.
• unused means that no package version needs the object any more. It is a candidate for cleanup.

The objects under blobs/ are named after the SHA-256 hash of their content, not after the file name in the package. The Used by column shows which file is behind them.

Cleaning up object storage

When versions or files are deleted, their contents initially remain in the object storage. With Clean up …, you remove package files (blobs/) and build results (artifacts/) that nothing uses any more. Cleanup works in two steps: a dry run determines what would be deleted, and deletion only happens after you confirm.

1. In the Object storage section, click Clean up …. A dry run starts as a job; the button shows “Running …”.
2. If the dry run finds nothing, “Nothing to clean up” or “Nothing to clean up, 5 unused objects are younger than 24 hours” appears next to the button. You are done.
3. Otherwise, the Clean up object storage dialog opens. It shows:
   • the total number and size, for example “The dry run found 37 unused objects (1.2 GB).”
   • number and size per area
   • a list of examples; the full list is in the job log under Jobs
   • how many unused objects are younger than 24 hours and are kept
4. Check the information and click Delete 37 objects. Cancel closes the dialog without deleting anything.
5. The deletion run starts as a second job. Afterwards, the button shows, for example, “37 objects deleted, 1.2 GB freed”.

Several safety rules apply to cleanup:

• 24-hour grace period: Only objects older than 24 hours qualify. This spares freshly uploaded contents that are just being assigned to a version.
• Dry run valid for one hour: Only objects from the confirmed dry run are deleted. If it is older than one hour, oPBWeb refuses to delete (“The dry run is missing or older than one hour. Please check again.”). Start Clean up … again in that case.
• Re-check on deletion: Each object is checked once more immediately before deletion. If it is in use again by then, it is kept.
• Not during imports and builds: As long as an import or build is queued or running, no cleanup starts (“Imports or builds are running. Please start again after they have finished.”). If an import or build begins during deletion, the deletion run stops. Objects already deleted stay deleted; you catch the rest in the next run.

The confirmed deletion run appears in the Audit log as storage.cleanup.