Integrating custom Software

Linux systems offer more consistency in package formats and installation methods than Windows, but the variety of Linux distributions introduces its own complexities. Each distribution tends to use distinct package formats and installation commands. Here’s a quick overview of the main types you’re likely to encounter:

The following sections will detail the key components of an opsi-script script tailored for Windows computers. As an illustration, here is an example of a basic opsi-script script:

An opsi-script script is structured into two main types of sections: primary and secondary sections. Similar to INI files, each section is introduced by its name enclosed in square brackets.

The core activities of software installation are carried out in the secondary sections, which are invoked by the primary sections. Each secondary section is designated for specific topics and follows a unique syntax: the section name starts with the type, followed by a user-defined name.

In the provided example, the primary section [Actions] triggers the secondary section [WinBatch_tightvnc_silent_install]; this section belongs to the WinBatch type. The contents of a WinBatch section are executed using the Windows API. Here, the msiexec tool is employed to install (/i) the 64 bit version of TightVNC silently (using the /quiet option). The /norestart option is included to prevent the computer from rebooting after the installation, which is a specific requirement for TightVNC.

To give you a clearer picture, let’s start with a rundown of the different strategies employed by each method:

To create opsi packages, you will require the following tools:

On Windows, you can launch the opsi-setup-detector from the Start menu, where it is located at opsi.org / opsi-setup-detector. For macOS users, the opsi-setup-detector can be accessed via Programs, while on Linux, it is typically found in the start menus at System Tools. Additionally, on most Linux desktop environments, you have the option to directly enter the full path to the executable file (/opt/opsi-setup-detector/opsisetupdetector) in a quick launcher ([Alt]+[F2]) or terminal window.

Upon the initial launch of the program, a configuration dialog will appear. It’s essential to provide information for the following three entries:

Additionally, you can configure further (optional) settings. For the opsi web service opsiconfd (https://<opsi-server>:4447, see the chapter The opsiconfd Service), you should complete the following fields:

Other optional settings include:

Once the configuration is saved, you will see the start page.

Click on the question mark to display the online help.

A click to this question mark icon will open the general or context sensitive online help pages.

Select the task that fits your needs. The dialog offers tasks for Windows, Linux, and macOS, as well as options that are operating system-independent. There is also a dedicated section for packages designed for multi-platform compatibility.

The following functions are available under Linux:

The following sections describe how to analyze a setup file and create an opsi product from it. To do this, click the Analyze File and Create Opsi Package button on the start page (Figure 6, “opsi-setup-detector Start Page”). Then navigate to the desired .exe or .msi file in the file selection dialog. The opsi-setup-detector starts the analysis immediately.

To open an existing project structure as a project with the opsi-setup-detector, there are two approaches:

The second method provides less comprehensive information, particularly regarding the setup file used by the installer.

Start the application opsi-script-gui:

Upon starting the application, you will be presented with the following window:

Use Select Script to choose the script you’re looking to test. Next, click Start to execute the script on your computer. Alternatively, for a syntax check, select Test_Syntax. This action checks the script for syntax errors but does not run it on your computer (see the section Checking the Script Syntax).

To observe how opsi-script interprets the script, you can use the opsi-logviewer.

If you need to modify the script, you have a couple of options for editing:

Now, you can save the changes and keep the editor open. Simply switch back to the opsi-script window and click on the Start button again; there’s no need to reselect the script. To observe the modifications, refer to the opsi-logviewer. You can refresh the log by choosing Reload from the right-click context menu or by clicking the reload button on the toolbar.

To fine-tune your scripts to perfection, you can repeat these steps as needed:

For the integrated tests, roll out the product on a test client:

To further customize your scripts, you can repeat these steps:

To set up the opsi PackageBuilder, click on the Settings button.

Configure the following on the General tab:

On the Program tab, configure the following settings:

On the opsi Commands tab, adjust the following setting, which deviates from the default configuration:

Save the settings and restart the opsi PackageBuilder. After restarting, the program should switch to online mode.

To edit a package, select the Open Package (F2) button and locate the directory created by the opsi-setup-detector, for instance, w:\develop\newprod2. This action will open the following dialog:

On the Package tab, the metadata of the opsi product is displayed in the left column (refer to section Product Configuration 1 for details). Script files are situated on the right. Next to each script file, you will find this button:

When you click on this button, the script editor specified in the settings will launch, allowing you to modify the script. On Windows, this typically defaults to the oPB-ScriptEditor. This editor comes equipped with features like colored syntax highlighting, optional source code folding (for a more compact view with comments), customizable lexer definition (accessible when launched from the start menu), auto-completion for syntax elements and variables, as well as customizable and reusable code blocks known as snippets.

The editor’s core component is the Scintilla module, which is also used by other renowned text editors like Notepad\++, CodeLite, etc. However, the lexical elements for opsi scripts, such as syntax highlighting and folding, are implemented using AutoIt. This is because Scintilla does not inherently provide specific highlighting for opsi scripts. Since AutoIt is an interpreter language, the ScriptEditor might not be as fast as other editors, particularly when editing very large scripts or with code folding activated.

The settings provide an option to enable or disable these functions when the editor is initiated via oPB. By default, syntax highlighting and folding are turned off when the editor is started from the start menu. However, you can activate them via the View menu if needed.

On the Dependencies tab, the dependencies established with other opsi products are displayed, as detailed in the section Priority and Dependencies.

The Properties tab shows the product properties, including type, value, etc:

At the bottom of the window, you can see the following buttons:

When you activate the Support custom directory checkbox on the Product Configuration 1 tab, the product gets supplemented with an extra directory named custom. This directory is ideal for storing client-specific customizations. Importantly, when you upgrade to a new version of the package, the custom directory remains untouched. The script includes templates for integrating files from this directory into the installation process.

Here’s what gets added to the setup.opsiscript file:

This calls a Files section to copy files from a custom directory to the client. The corresponding section looks like this:

In this example, the contents of the custom directory are transferred to the installation directory, and the custom directory itself is created. It contains the two files OPSI\preinst and OPSI\postinst. These files ensure that the contents of the custom directory remain intact on the depot, even when updates occur.

When you activate the Install from local temp dir checkbox on the Product Configuration 1 tab in opsi-setup-detector, it adjusts the installation process such that the installation files are initially copied to a local, temporary directory, and the installation is carried out from there. This method is particularly beneficial in scenarios where the installation might disrupt the network connection, a common situation with driver installations.

As a result, opsi-setup-detector creates a new boolean property named install_from_local_tmpdir, which defaults to false and has this description: Determines whether the installation files are copied to a local directory.

To accommodate this feature, modifications are made to the setup.opsiscript file as follows:

Now the installation files are temporarily moved to a temporary directory and deleted after the installation if the condition Install_from_local_tmpdir is set to true.

The corresponding sections look like this:

Activating the Handle License Key checkbox on the Product Configuration 1 tab within the opsi-setup-detector adds the necessary property and code for managing license keys.

This action creates an additional property named secretlicense_or_pool. By default, this property is left blank and carries the description license key or opsi licensepool. The inclusion of secret in the property name signifies that the value of this property will be masked in opsi-configed, meaning it won’t be displayed in plain text.

This code is inserted into the setup.opsiscript file:

get_licensekey_byPoolOrKey checks if the value entered in the secretlicense_or_pool property corresponds to the name of a license pool as defined in the opsi extension License Management. If it matches, a license key is retrieved from this specified pool. Otherwise, the content of the property is treated and used directly as the license key.

This code is inserted into the uninstall.opsiscript:

The Product Configuration 1 tab includes a checkbox named Customize Profile. When selected, a section Profileactions is added to the code which facilitates modifications to local user profiles. This feature also extends to Roaming Profiles through a login script.

In the OPSI/control file, the setup.opsiscript is designated not only as a setupScript but also as a userLoginScript.

The following segment is added to the setup.opsiscript file:

The code triggers the execution of a section named ProfileActions. Depending on the context in which it’s invoked, this section is executed for all local profiles or specifically for the profile of the currently logged-in user (see the chapter User Profile Management).

The sections relevant to this process, which serve as templates for modifying user profiles, are structured as follows: