Creating a Package from an Installer
Roles: Packager, Releaser, Administrator
Overview
The assistant From installer … in the package list does in oPBWeb what the opsi-setup-detector otherwise does on your computer: it analyses an installer, suggests the product id, version, install and uninstall command, and creates a complete package from the script templates of the opsi-setup-detector. The package ends up as a draft in oPBWeb, with the installer already in CLIENT_DATA/files1.
You need neither the opsi-setup-detector nor a workbench share on your computer. If you prefer working with the opsi-setup-detector, keep using the hand-off through the launcher ; both ways lead to the same result, a draft in oPBWeb.
Analysis and creation run as jobs in the worker. You follow the progress in the assistant and under Jobs (“Analyse installer: …”, “Create package from installer: …”).
The assistant at a glance
Click From installer … in the toolbar of the package list. The dialog “New package from installer” guides you through four steps:
| Step | What you do |
|---|---|
| Source | Choose the kind of package, target OS and template channel; upload the installer or name it in the workbench |
| Analysis | Check and correct the result of the analysis |
| Product | Set product id, versions, description, options, properties, dependencies, changelog and product image |
| Create | Check the summary, create the package, open it in the editor |
Back goes back one step; clicking a completed step at the top jumps straight to it. The template kinds without an installer skip the Analysis step.
The first time you open the assistant, a one-time hint “Note on the feature set” appears first: the assistant does less than the original opsi-setup-detector; the differences are listed under Limitations . The same hint also appears before your first Analyse installer in the package editor, unless you have already confirmed it. After Got it, oPBWeb remembers this in your user account, so the hint does not come back, not even in another browser. Under My account you can turn it on again with Show again .
Step 1: Source
- Under Kind of package, choose what to create (table below). A short hint for the chosen kind appears below the field.
- Choose the Target OS (Windows, Linux or macOS). The field is only active for the kinds that target a single operating system.
- Choose the Template channel. It is preset with the channel from the settings
:
- Training (verbose comments): scripts with many explanations, good for learning.
- Default: the templates the opsi-setup-detector normally uses.
- Structured: scripts split up more into separate files.
- Own (custom): your own templates. Whatever is missing there, the generator takes from Default, see Templates .
- For each installer, say where it comes from:
- Upload: drop the file onto the field “Drop the installer here or choose it” or click Choose file ….
- From the workbench: under Path relative to the workbench, enter the path starting with the project folder, for example
firefox/CLIENT_DATA/files1/setup.exe. If several config servers are set up, choose the Config server above. With Copy the whole folder, oPBWeb copies every file of the installer’s folder (with sub folders) intofiles1(orfiles2,files3) when creating the package, e.g. for installers with additional files.
- For an
.msifile you can add an MST file (optional): when uploading in a second field, for the workbench by its name only (it has to be in the same folder). The install command then getsTRANSFORMS=…. - Change the two analysis options if needed (preset from the settings):
- Use silent instead of unattended parameters: the installer runs without any window instead of showing its progress.
- Uninstall MSI wrappers through msiexec when the MSI data is known: for installers with an embedded MSI, the package uninstalls with
msiexec /xand the ProductCode.
- Click Analyse. For the template kinds the button reads Next.
If something is missing, the dialog says so below the fields, for example “Installer: file or workbench path missing.”
Kinds of package
| Kind of package | Installers | Result |
|---|---|---|
| Single installer | one | package for one operating system; the target OS follows the installer |
| 32 and 64 bit installers | two (Windows) | package with both installers and the property install_architecture (32 only, 64 only, system specific, both) |
| Several operating systems | one each for Windows, Linux, macOS, each optional, at least one | package with scripts for all three operating systems; an OS without installer gets the template scripts only |
| Template only | none | only the scripts from the templates; you add the install commands in the editor afterwards |
| Template for several operating systems | none | scripts for Windows, Linux and macOS without installer |
| Installation in the user context | one (Windows) | the installer runs in a session of the user opsisetupuser; the scripts are in localsetup |
| Template for installation in the user context | none | scripts for an installation in the user context without installer |
| winget | none | product the client installs through winget; instead of a file you enter the winget id (for example Mozilla.Firefox) and the Source (default winget) |
Step 2: Analysis
oPBWeb uploads the installers and starts an analysis job for each. A badge next to the file name shows the state: “uploading”, “analysing” with a percentage, “analysed ✓” or “failed”. Log holds the job log. Next becomes active once all analyses are finished.
For each installer the dialog shows:
- Type: the detected installer type, for example “Inno Setup” or “Nullsoft Install System”. If the rules matched several types, “Also detected: …” appears below. If oPBWeb detects the type wrongly or not at all, choose it here; this starts a new analysis with that type (“type chosen by hand”). detect automatically switches back.
- Hint of the detector: the opsi-setup-detector’s explanation for this installer type, often with a link to the vendor’s documentation.
- Matches: the detection patterns found in the file.
- Result of Detect-It-Easy: only if Detect-It-Easy is installed in the worker (see Limits ).
- Notes of the analysis, for example “Installer type not detected. Please choose the type by hand.”
- The fields the generator uses: Product id, Product name, Product version, Install directory, Architecture, Main program (for the desktop icon), Install command, Uninstall command, Uninstall program, Uninstall through msiexec, Required space, for MSI MSI ProductCode and MSI UpgradeCode, and Check “installed?” (opsi-script lines that check whether the software is already installed).
You can change every field; the generator takes your values. Analyse again repeats the analysis, for example after switching Use silent instead of unattended parameters.
What the analysis finds per installer type
Like the opsi-setup-detector, oPBWeb detects the type by text patterns in the file. The basis is the installer table of the opsi-setup-detector with about 30 types; it also provides the silent and unattended parameters, the uninstall program and the function that evaluates exit codes. Depending on the type, oPBWeb then reads more details:
| Installer | What is read in addition |
|---|---|
Windows programs in general (.exe) | version resource: product name and file version, architecture of the installer |
MSI (.msi) | ProductName, ProductVersion, ProductCode, UpgradeCode and the install directory from the MSI database; uninstall through msiexec /x |
| Inno Setup | from the setup header: name and version of the application, default install directory, 32/64 bit, location of the uninstall program |
| InstallShield with MSI, Advanced Installer, WiX bundles | the embedded MSI, if 7-Zip can extract it; then as for MSI |
| InstallAware | name of the uninstall program from the matches |
| MSIX / APPX (bundles too) | name, version, architecture and description from the manifest; uninstall and check through PowerShell. The option Uninstall before installation is preselected (“For MSIX/APPX the detector recommends …”) |
Debian packages (.deb) | package name, version, description, vendor, license, architecture, homepage, required space |
RPM packages (.rpm) | the same details from the RPM header |
macOS (.dmg, .pkg, .app, .zip with target macOS) | name and version from the file name; a ZIP has to contain an .app, .dmg or .pkg |
| other detected types (NSIS, classic InstallShield, Wise, Bitrock …) | parameters and uninstall program from the installer table, name and version from the version resource or the file name |
Limits of the analysis
- Inno Setup: the tool innoextract reads the setup header. New Inno versions that innoextract does not know yet give “The Inno Setup header could not be read (innoextract).” Install directory and uninstall program are default assumptions then; check them.
- MSI in wrapper installers: the opsi-setup-detector runs such installers on Windows to extract the MSI. oPBWeb runs no installers; it tries 7-Zip instead. If 7-Zip finds no MSI (“7-Zip found no embedded MSI …”), the MSI data is missing and the package uninstalls with the installer’s uninstall program. If there are several MSI files inside, oPBWeb analyses the first one and lists all of them.
- Detect-It-Easy: for unknown files the opsi-setup-detector asks Detect-It-Easy for a second opinion. It is not part of the oPBWeb image; without it, detection relies on the patterns. How to add it is described in Configuration .
- Windows only: what the opsi-setup-detector finds out by running the installer on a Windows computer, oPBWeb cannot determine. So check install directory, uninstall program and the check “installed?” especially for unknown types.
The analysis is a suggestion. Test every generated package on a test client before you bring it to production depots.
Step 3: Product
Product id, name, product version and description are preset from the analysis; package version, priority, control format and Changelog from the settings for new packages . The fields follow the same rules as in New package. Below the fields oPBWeb shows whether the product id or the version already exists, for example “firefox already exists in oPBWeb; the version will be added.”
Options
The options switch on additional building blocks of the templates:
| Option | Effect |
|---|---|
| License required | sets License required in the control |
| Desktop icon (property desktopicon) | property desktopicon and script parts that create or remove a shortcut to the Main program |
| License key property (SecretLicense_or_Pool) | property secretlicense_or_pool for a license key or an opsi license pool, plus the script parts that fetch and free the license |
| Install from a local directory | property install_from_local_tmpdir: the client copies the installation files locally first and installs from there |
| Custom directory | folder CLIENT_DATA/custom/ for your own files, which the script copies along |
| Profile customization | folder CLIENT_DATA/profile_files/ and script parts that customize user profiles |
| Uninstall before installation | property uninstall_before_install: removes an existing installation before the setup |
Desktop icon and license key property are preselected if an administrator set this in the settings.
Properties and standard properties
Properties lists the preset properties from the settings. You can change and delete them and add more with Add property (Name, Type, Default, Possible values comma-separated, Description, Free). Every name may occur only once.
The generator adds the properties belonging to the chosen options and the kind of package itself. You do not have to create them:
| Property | When |
|---|---|
desktopicon | option desktop icon |
secretlicense_or_pool | option license key property |
install_from_local_tmpdir | option install from a local directory |
install_architecture | kind 32 and 64 bit installers |
uninstall_before_install | option uninstall before installation, and installation in the user context |
copy_files_locally, debug, execution_method, install_at_safe_mode_boot | installation in the user context |
Dependencies, changelog and product image
- Dependencies: with Add dependency you enter per row the product under Required product, an action or a state of that product under Requires, and
before,afteror “any” under Order. The dependencies apply to the actionsetup; you can change them later in the package editor . - Changelog entry: text of the first changelog entry. Leaving it empty gives the generator’s default text.
- Product image (PNG): Choose PNG … uploads your own image. Without one, the package gets the default image of the operating system from the templates.
Step 4: Create
The last step summarises kind, template channel, product id, version, installers and the number of properties, and checks whether the package already exists. Depending on the situation it offers:
| Situation | Choice |
|---|---|
| The package does not exist in oPBWeb yet | Create package |
| The package exists, the version does not | Create new version |
| The version already exists | Create as … (next free package version, for example 1.0-3 instead of 1.0-2) and, if the existing version is a draft, Overwrite draft |
| The version exists, is released and the package version cannot be incremented | none; change the version in the step Product |
| The package is archived | none; restore the package first, see Archiving a package |
After the click the dialog shows the progress (“Creating the package … 40 %”) and the job log. The job generates the product files from the templates, copies the installers into CLIENT_DATA/files1 (or files2, files3) and stores everything as a new draft version. It then reports “firefox 128.0-1 was created as a draft.” Click Open in editor to check, build and test the package.
In the package details, Origin shows “opsi-setup-detector”.
Warnings of the job appear below the success message:
- “Template … is missing, the building block is skipped”: the file exists neither in the chosen channel, nor in Default, nor in
default/generic, for example because an administrator deleted it. - “Placeholders left in the generated files: …”: a template contains a placeholder the generator has no value for. Find it in the editor and replace it by hand.
Analysing an installer in a package
If an installer is already in a package, analyse it in the package editor with Analyse installer in the context menu of the file tree, see Package files . The result is display only there; it does not change the package. If you have not yet confirmed the “Note on the feature set”, it appears before the first analysis; the limitations apply here as well.
Limitations compared to the opsi-setup-detector
The assistant takes over the analysis and package generation of the opsi-setup-detector, but it runs in the worker container under Linux, not on a Windows machine. This and the scope of the port lead to the following differences:
| Area | opsi-setup-detector | oPBWeb |
|---|---|---|
| MSI in wrapper installers | extracts the MSI on Windows by running the installer: InstallShield with MSI (extractMSI.cmd), Advanced Installer (/extract), WiX bundles (dark.exe) | does not run installers and only tries 7-Zip. If that fails, MSI ProductCode, product name and installation directory stay unknown (“7-Zip found no embedded MSI …”). This has not yet been tested with real InstallShield, Advanced Installer and WiX installers. |
| Detect-It-Easy | asks it for a second opinion on unknown files | not in the image, can only be added (DIEC_PATH, see Configuration
). Without Detect-It-Easy, installers that only Detect-It-Easy recognizes (such as Squirrel or Microsoft .NET installers) stay “unknown”, and you choose the type manually. |
| Inno Setup | reads the setup with innounp or innounp-2 | reads the setup header with innoextract (fork by crazy-max, knows Inno Setup up to 7.1). Newer Inno versions get default assumptions (“The Inno Setup header could not be read …”). |
| Installer source | local file or local folder | upload or a file in a project folder of the workbench. Large installers have to be uploaded first. Copy the whole folder is only available for the workbench. An .app bundle is a folder and cannot be uploaded; zip it. |
| Project file | saves opsi-project.osd and reopens it, can pre-fill a product from an existing control file | no project file, no pre-filling from a control file. What remains is the created package; you make changes afterwards in the Package Editor . |
| Command line | batch mode with --filename, --nogui, --targetOS, --productID, --mode, --template-channel | only the assistant in the interface |
| Metadata for background installation | tab “Product Configuration 3”: processes and directories to check are editable | opsi-meta-data.toml from the analysis only (setting Write metadata (CLIENT_DATA/opsi-meta-data.toml)): empty process list, only the installation directory is checked. Whether the opsi service accepts the file in this form has not been verified. |
| Build and install | mode “build and install” in one go | the assistant ends with a draft. You build and install afterwards in the editor. |
| Types winget and installation in the user context | winget templates are referenced but missing from the detector’s repository | oPBWeb’s own winget templates. Neither winget nor with-user packages from oPBWeb have been tested on a Windows client yet. |
| Template channel Own (custom) | no templates in the repository | empty as well; fill it in the Templates view or by ZIP import . |
When the opsi-setup-detector is the better choice
Use the opsi-setup-detector on Windows if
- a wrapper installer only releases its MSI when it runs and you need the MSI data,
- the installer is exotic and only Detect-It-Easy recognizes it (and it has not been added to your oPBWeb),
- an Inno Setup installer is so new that oPBWeb cannot read its header,
- the files are local and you do not want to upload them or put them on the workbench first, or an
.appbundle exists as a folder, - you work with project files or in batch mode,
- you need a winget package or a package with installation in the user context, as long as these types have not been verified on a client in oPBWeb.
The result of the opsi-setup-detector still ends up in oPBWeb: through the launcher, oPBWeb takes over the created project folder from the workbench, see Hand-off from opsi-setup-detector .