Packages

Roles: Viewer, Packager, Releaser, Administrator

Overview

The Packages area is the start page of oPBWeb. Here you see all packages with their latest version, check in the package details on which depots they are installed, and create new packages. The toolbar offers Workbench …, Promote …, Import, Meta package …, From installer … and New package; From installer … creates a package straight from an installer, see Creating a package from an installer . As a viewer you can see the list and the details; creating, importing and all changing actions require at least the Packager role.

The package list

The table shows the latest version of each package:

A click selects a package and shows its details on the right. A double-click opens it in the Package Editor .

Filtering

• The All, Drafts and Released buttons filter by the status of the latest version. The number next to each shows how many packages match.
• Archive shows the archived packages instead of the active ones (see Archiving a package ). If there are none, “No archived packages.” appears.
• In the “Filter …” field you search by product ID or name.

If no package matches, “No package matches the filter.” appears.

Package details

The right-hand pane shows for the selected package:

• Header: product logo (if any), product ID, version, status, name and the first line of the description.
• Buttons: Open in editor and Source (opens the editor directly in the source view). As a packager, also Build (drafts only) and Install … (only if the latest version has an up-to-date build). If the build is outdated, “changed since build” is shown.
• Key data: Type, Priority, setup and uninstall script, Dependencies, Properties, number of Files and scripts, Format (for example “INI · changelog embedded”) and Origin (“created”, “imported”, “copied from …” or “from the workbench”).
• Distribution: For each depot the Stage (Production, Staging or Test) and the version Installed there, grouped by config server (see Distribution ). As a packager, you take the package from one stage to the next with Promote to another stage … (see Promoting to another stage ). If the product is installed anywhere, you can remove it with Uninstall ….
• Workbench: Which workbench the package lies on, see Workbench .
• Versions: All versions of the package with status and date. A click opens that version in the editor.
• Package (packager and above): Archive, or Restore for archived packages, and Delete package …, see Archiving a package and Deleting a package .

Distribution

The Distribution table groups the depots by config server. The header row of a server tells you on how many of its depots the package is installed (“1 of 3 installed”). Below it, each depot shows its Stage and the version Installed:

• An italic stage is inherited by the depot from its config server.
• If the installed version differs from the latest one, it is marked orange.
• Click the header row of a config server to collapse or expand its depots. oPBWeb remembers this in this browser.
• “Search depots” narrows the depots down by depot ID or config server name; while searching, all groups are expanded.
• The Installed only chip hides all depots the package is not installed on. The number in the chip counts the depots with an installation.

Workbench

The Workbench section shows in which project folders of the workbenches the package lies: Config server, Project folder (with its path if it lies in a group folder, for example develop/firefox) and Version. If the version differs from the latest one in oPBWeb, it is marked orange. If the package is not on any workbench, the section says “Not on any workbench.”

oPBWeb does not read the workbench every time you open a package; it remembers what it saw last. The information is refreshed

• when the Workbench … dialog reads a workbench (see Importing from the workbench ),
• on every export to the workbench ,
• on every sync via Sync or ⟳ in Depots and
• automatically by the worker, hourly by default (configurable under Settings → Worker ).

Ignored folders are left out by every scan; when you ignore a folder, the project folders below it disappear from this section at once.

The “As of:” line below names, per config server, when its workbench was last read completely, or “never read”. If you changed the workbench directly on the server, sync first.

Building, installing and uninstalling are described in Build and Deploy . To take several packages at once from one stage to the next, use Promote … in the toolbar of the package list, see Promoting to another stage .

Creating a new package

Roles: Packager, Releaser, Administrator

1. In the package list, click New package.

   

2. Fill in the fields:

   • Product ID (required): only lowercase letters, digits, period, hyphen and underscore. The first character must be a lowercase letter or a digit, at most 128 characters in total. Example: firefox-esr.
   • Name: display name. If you leave it empty, oPBWeb uses the product ID.
   • Product version (required): version of the software, prefilled from the settings (default 1.0).
   • Package version (required): version of the package, prefilled from the settings (default 1).

3. Click Create. As long as the product ID is invalid, the button stays disabled.

oPBWeb creates the package as a draft and opens it in the package editor. The new package already contains a setup and an uninstall script as templates (CLIENT_DATA/setup.opsiscript, CLIENT_DATA/uninstall.opsiscript) and an empty SERVER_DATA/ folder. Priority, control format and changelog location come from the settings for new packages .

Importing .opsi files

Roles: Packager, Releaser, Administrator

You take over existing packages by importing their .opsi files. Every imported version becomes a draft.

1. Click Import. The “Import packages” dialog opens.

   

2. Drag one or more .opsi files into the “Drop .opsi files here or choose them” area or click Choose files. Other file types and files selected twice are ignored.

3. Optional: Enable Overwrite an existing draft with the same version if an existing version should be replaced.

4. Click Start import.

oPBWeb uploads and imports the files one after the other. Each row shows its state: “ready”, “uploading”, “importing”, “imported” or “failed”. Below the list, the log of all imports runs in one shared field. While the import is running, Close is disabled.

During the import, oPBWeb stores the control data and the changelog in its database. The format of the control file (INI or TOML) and the changelog location are preserved. Old control-*.bak backups of the opsiPackageBuilder are not imported; the job log states how many were skipped.

Importing from the workbench

Roles: Packager, Releaser, Administrator

If package sources are stored as project folders in the workbench of a config server, you can take them over directly – individually, several or all at once.

1. Click Workbench …. The “Import from the workbench” dialog opens.

2. At the top, under Config server, choose the server whose workbench you want to read. The list shows each server with name and stage. oPBWeb remembers your choice in this browser; without an earlier choice, the first server of the Test stage is preset, otherwise the first server. The dialog reads the workbench automatically (“Reading workbench …”), also after each change of server.

3. Check the table. It shows the workbench as a tree: folders without an OPSI folder are groups (bold, ending in /) and can be collapsed and expanded with the arrow in front of them; oPBWeb searches them up to four levels deep. Project folders are listed indented below them with product ID, Version, Format and State:

   State	Meaning
   “new package”	The product ID does not exist in oPBWeb yet.
   “new version”	The package exists, but this version does not yet.
   “draft exists”	The version already exists as a draft.
   “released exists”	The version already exists and is released.
   “archived”	The package is archived and cannot be imported.
   “… · installed”	Added when exactly this version is installed on a depot of the chosen config server (the tooltip names the depots). The import releases it, see Releasing installed versions .

   Project folders with an unreadable control file show the reason in the Format column and have no checkbox. Use the filter field to narrow down the list; it then shows only the matching projects with their full path (for example develop/firefox).

4. Select the checkboxes of the project folders you want to import. The checkbox in the table header selects all, Select all new selects all folders whose version does not exist in oPBWeb yet.

5. Under Existing versions, choose what happens with folders whose version already exists:

   • “skip” (default): The folder is not imported.
   • “overwrite drafts”: An existing draft is replaced. Released versions are skipped.
   • “import as next package version”: oPBWeb creates the version with the next free package version (highest numeric package version of this product version + 1).

6. Click Import selected (n).

The import runs as a single job “Import from workbench (server), projects: n” and processes the folders one after the other. You see the progress as “Importing … 40 %”. If you close the dialog, the job keeps running. If a folder fails, oPBWeb continues with the others.

Afterwards, each row shows its result: “imported as 1.0-2”, “skipped” or “failed” (the tooltip shows the reason). At the bottom there is a summary such as “3 imported, 1 skipped, 0 failed”. The job log under Jobs contains one line per project.

Only the OPSI, CLIENT_DATA and SERVER_DATA folders are imported; other content of the project folders is left alone. Rescan refreshes the list. The import never overwrites released versions.

Releasing installed versions

Normally a version is released only when you install it from oPBWeb. A project folder whose version is already installed on a depot of the chosen config server, however, has already been built and installed there (for example with opsi-makepackage and opsi-package-manager). The import releases such versions right away instead of creating a draft:

• If the project folder contains the matching file <product-id>_<version>.opsi (for example firefox_128.0-1.opsi), oPBWeb takes it as the build of the version. The row then shows “imported as 128.0-1” and “released”. oPBWeb only checks that the file contains this product in this version; it cannot prove that it matches the installed package.
• If the file is missing or unreadable, the Workbench setting decides: the version stays a draft (“stays a draft”, default), or oPBWeb builds it itself and releases it (“built and released”).

Which depots count is determined by the last depot sync of the config server. The repository of a depot plays no role: opsi-package-manager -i stores a package there only with the -d option.

Drafts that were imported before this check existed, or for which the setting has changed since, are caught up with Reconcile with depots (n). The button covers all visible rows marked “draft exists · installed” and starts the job “Reconcile workbench with depots (server), projects: n”. It imports nothing again; it only takes over the .opsi file from the project folder or builds the version as the setting says, and releases it. Afterwards each row shows “released”, “built and released”, “stays a draft” or “skipped” (tooltip with the reason, for example when the version is no longer a draft). The release is recorded in the audit log as version.released with the depots and the origin of the build.

Ignoring folders

If the workbench contains folders whose content oPBWeb should not know about (for example to_review or develop/deprecated with old packages), click Ignore at the right of the folder’s row. This works for group folders and for project folders. The folder stays in the list, greyed out and collapsed with the mark “ignored”; its content disappears from the table and from the Workbench section of the package view.

The list of ignored folders applies per config server and to every scan: in the dialog, scheduled and during the depot sync. Include again takes a folder back; the dialog then reads the workbench again. Both steps are recorded in the audit log .

You can also import individual folders under Depots on the Files tab with Import into oPBWeb, see Depots . If an imported version was later changed directly on the workbench, bring the changes over with Compare with workbench … in the package editor, see Package Editor .

Hand-off from opsi-setup-detector

Roles: Packager, Releaser, Administrator

opsi-setup-detector can start the old opsiPackageBuilder after creating the product files. With the oPBWeb launcher, oPBWeb opens in the browser instead and asks whether you want to import the new workbench folder.

You can set up the launcher by hand (next section) or distribute it as an opsi package via your depots, see Distributing the launcher as an opsi package .

Setting up the launcher by hand

1. Download the launcher for your system: in the “Import from the workbench” dialog via Download launcher for opsi-setup-detector, or directly under /downloads/ of your oPBWeb address. There is one zip file each for Windows, macOS and Linux (amd64 and arm64).

2. Unpack the file. It is called opsipackagebuilder.exe (Windows) or opsipackagebuilder. Do not rename it: opsi-setup-detector only accepts this name.

3. Put it where opsi-setup-detector finds it, or enter its path in the opsi-setup-detector configuration under PathToOpsiPackageBuilder:

   System	Default path
   Windows	C:\Program Files (x86)\opsi PackageBuilderNG\opsipackagebuilder.exe
   macOS	/Applications/opsiPackageBuilder.app/Contents/MacOS/opsipackagebuilder
   Linux	/usr/bin/opsipackagebuilder

4. Store the oPBWeb address once:

   opsipackagebuilder --set-url https://opbweb.example.org
   

   Alternatively, create a file opb-launcher.conf next to the launcher with the line url = https://opbweb.example.org (applies to all users of the computer) or set the environment variable OPBWEB_URL.

5. If opsi-setup-detector works with a mapped drive (for example W:\) instead of a UNC path, also store the config server of this workbench:

   opsipackagebuilder --set-server opsi-test.example.org
   

   Alternatively, add the line server = opsi-test.example.org to opb-launcher.conf or set the environment variable OPBWEB_SERVER.

opsi-setup-detector and oPBWeb must use the same workbench: opsi-setup-detector writes to the workbench share of a config server, and this server must be set up in oPBWeb. The project folder may lie in group folders (\\opsi-test.example.org\opsi_workbench\develop\firefox gives develop/firefox); if the share does not point to the workbench itself, oPBWeb finds the folder by the end of the path. The launcher tells oPBWeb which config server is meant: for a UNC path like \\opsi-test.example.org\opsi_workbench\firefox it is the host name from the path, otherwise the server stored with --set-server.

Distributing the launcher as an opsi package

If the computers running opsi-setup-detector are opsi clients themselves, the easiest way to distribute the launcher is an opsi product. oPBWeb ships the package opb-launcher ready to use: a localboot product for Windows, Linux and macOS (amd64 and arm64) whose product version equals the launcher version.

1. In the “Import from the workbench” dialog, click Create launcher as opsi package … at the bottom.
2. oPBWeb address shows the address you are using oPBWeb at right now. It becomes the default of the property url. Change it if your users reach oPBWeb at a different address.
3. You only need Config server for workbench paths without a host name if opsi-setup-detector works with a mapped drive instead of a UNC path. The value becomes the default of the property server; the host names of your config servers are suggested.
4. Click Create package. If the package exists already, the dialog offers Create new version, Create as … (next free package version) or Overwrite draft, as in the hand-off.
5. The package is created as a draft and opens in the editor. Build it and install it on your depots, see Package editor and Depots . Then set it to setup on the computers running opsi-setup-detector.

The package puts the launcher where opsi-setup-detector looks for the old opsiPackageBuilder (table above) and writes opb-launcher.conf with url and server next to it. On Linux the launcher lives in /opt/opb-launcher/, /usr/bin/opsipackagebuilder is a link to it.

The package has the dependencies uninstall/before on the products opsipackagebuilder and opsipackagebuilder_wlm: if one of them is installed via opsi, it is uninstalled first. If a product is missing on the depot, opsi ignores the dependency.

On uninstall, the package only removes the launcher and its configuration file; folders are only deleted when they are empty.

Using the hand-off

1. In opsi-setup-detector, choose the mode create opsi product files and start the interactive PackageBuilder and create the product.

2. oPBWeb opens in the browser. If you are not signed in, sign in first.

3. The “Hand-off from opsi-setup-detector” dialog reads the workbench folder. If several config servers are set up, Config server is preset to the server the launcher passed on (host name or short name). If oPBWeb does not know this server, a note appears and the last selected server is preset; then choose the matching server. The dialog then asks depending on the situation:

   Situation	Choice
   The package does not exist in oPBWeb yet	Import or Cancel
   The package exists, the version does not	Create new version or Cancel
   The version already exists	Create as … (next free package version, for example 1.0-3 instead of 1.0-2), Overwrite draft (only if the existing version is a draft) or Cancel
   The package is archived	Cancel only; restore the package first

4. After the import, the new version opens in the editor.

The opsi-setup-detector modes build and build + install do not need the launcher: from opsi 4.2.0.311, opsi-setup-detector builds directly via the opsi service. If it still calls the launcher to build, the launcher reports an error, because oPBWeb does not build from the command line.

In these modes, oPBWeb does not learn about the new package. Import it afterwards via Workbench … or in the file manager of the depots with Import into oPBWeb. The periodic workbench scan of the worker does not import; it only remembers which project folders exist.

Creating a meta package

Roles: Packager, Releaser, Administrator

A meta package installs a set of other products. It contains no program itself, only dependencies: each selected product becomes a dependency “setup, installed, before”. The script of the meta package does nothing.

1. Click Meta package …. The “New meta package” dialog opens.

   

2. Fill in the fields on the left:

   • Product ID: prefilled with the prefix from the settings (default meta-). The same rules apply as for a new package.
   • Name, Description: optional.
   • Product version, Package version: prefilled from the settings.

3. Select the products on the right. Use “Filter products …” to narrow down the list. You can choose from all packages in oPBWeb and all products found on the depots; products that exist only on a depot are marked “depot only”.

4. Under Order, use ↑ and ↓ to put the products in the desired installation order. × removes a product from the selection.

5. Click Create. The button is enabled as soon as the product ID is valid and at least one product is selected.

oPBWeb opens the new meta package in the editor. It gets the priority and the setup script name from the settings (default: priority −100, script dummy.opsiscript) and no uninstall script. A meta package cannot contain itself; at most 200 products are possible.

Deleting a version

Roles: Packager, Releaser, Administrator

You delete a single version in the package editor:

1. Open the version in the Package Editor and select the Product section.
2. At the bottom, click Delete this version.
3. Confirm the prompt “Delete version … permanently?”.

Deleting is also possible for released versions and cannot be undone. If the version is installed on a production depot, only a Releaser may delete it (see stage rule ). The built .opsi file of the version is deleted as well. If it is the last version, the whole package disappears from the list. oPBWeb then opens another version of the package or the package list.

Archiving a package

Roles: Packager, Releaser, Administrator

You archive a package that you no longer need but want to keep:

1. Select the package in the package list.
2. In the details, under Package, click Archive.
3. Confirm the prompt “Archive …? The package disappears from the list and becomes read-only, the built .opsi files are deleted.”

An archived package

• only appears under the Archive filter and not in the search,
• is read-only: you can view it in the editor, but you cannot edit or build it, create a new version or delete a version; importing into the package is refused as well,
• no longer has build results and therefore cannot be installed.

If jobs are running or waiting for the package, oPBWeb refuses to archive it. Products installed on the depots are kept; you can still remove them in the details with Uninstall ….

To bring it back, select the package under Archive and click Restore. The versions keep their status. Build the package again before installing it next time.

Deleting a package

Roles: Packager, Releaser, Administrator

You delete a whole package with all its versions in the package list, even if it is archived:

1. Select the package.
2. In the details, under Package, click Delete package ….
3. Type the product ID to confirm and click Delete permanently. The button is only enabled when your input matches exactly.

All versions, their files and build results are deleted. This cannot be undone. If any version of the product is installed on a production depot, only a Releaser may delete the package.