The opsi-package-updater works with different modes, each with its own help module options. You can display help with the --help switch.

# opsi-package-updater --help
usage: opsi-package-updater [-h] [--version] [--config CONFIGFILE]
                            [--verbose | --log-level {0,1,2,3,4,5,6,7,8,9}]
                            [--force-checksum-calculation]
                            [--repo repository_name]
                            [--use-inactive-repository]
                            {install,update,download,list} ...

Updater for local opsi products.

optional arguments:
  -h, --help            show this help message and exit
  --version, -V         show program's version number and exit
  --config CONFIGFILE, -c CONFIGFILE
                        Location of config file
  --verbose, -v         Increase verbosity on console (can be used multiple
                        times)
  --log-level {0,1,2,3,4,5,6,7,8,9}, -l {0,1,2,3,4,5,6,7,8,9}
                        Set the desired loglevel for the console.
  --force-checksum-calculation
                        Force calculation of a checksum (MD5) for every
                        package. Default is to use existing checksums from the
                        .md5-file of a package if possible.
  --repo repository_name
                        Limit the actions the given repository.
  --use-inactive-repository
                        Force the activation of an otherwise disabled
                        repository. The repository must be given through
                        --repo.

Mode:
  {install,update,download,list}
    install             Install all (or a given list of) downloadable packages
                        from configured repositories (ignores excludes)
    update              Update already installed packages from repositories.
    download            Download packages from repositories. This will not
                        install packages.
    list                Listing information

Modes have their own options that can be viewed with MODE -h.

# opsi-package-updater download --help

usage: opsi-package-updater download [-h] [--force]
                                     [productID [productID ...]]

positional arguments:
  productID   Limit downloads to products with the given IDs.

optional arguments:
  -h, --help  show this help message and exit
  --force     Force the download of a product even though it would otherwise
              not be required.

# opsi-package-updater list --help

usage: opsi-package-updater list [-h]
                                 [--repos | --active-repos | --packages | --packages-and-installationstatus | --package-differences | --updatable-packages | --search-package text]

optional arguments:
  -h, --help            show this help message and exit
  --repos               Lists all repositories
  --active-repos        Lists all active repositories
  --packages, --products
                        Lists the repositories and the packages they provide.
  --packages-and-installationstatus, --products-and-installationstatus
                        Lists the repositories with their provided packages
                        and information about the local installation status.
  --package-differences, --product-differences
                        Lists packages where local and remote version are
                        different.
  --updatable-packages, --updatable-products
                        Lists packages that have updates in the remote
                        repositories.
  --search-package text, --search-product text
                        Search for a package with the given name.

There are some common options.

Different modes result in different behavior. The install, update and download modes load packages from a repository, whereas list displays information.

install mode installs new packages. update mode overhauls installed packages to a newer version. Both modes don’t require other parameters.

Example: Installing all available packages on all repositories:

opsi-package-updater install

The modes install and update limit the actions to specific products by using their ID.

Example: Updating the packages for the products firefox and javavm:

opsi-package-updater -vv update firefox javavm

You can specify the package source with --repo id.

Example: Installing ubuntu package from the uib_linux repository:

opsi-package-updater -vv --repo uib_linux install ubuntu
opsi-package-updater install

The download mode allows to download packages without installing them afterwards. The --force switch forces the download of a package, even if this version is already installed on the server. The modes install and update allow to limit the actions to specific products by handing over their ID.

Example: Updating the packages for the products firefox and javavm:

opsi-package-updater -vv update firefox javavm

In combination with the --repo switch the package source can be limited.

Example: Installing the package for ubuntu from the repository uib_linux:

opsi-package-updater -vv --repo uib_linux install ubuntu

The mode download allows to download packages without installing them afterwards. The switch --force forces the download of a package even though this version is already installed on the server.

Through list --active-repos the active repositories are shown. The information consists of name, address and if applicable the description of the repository.

You can display active repositories using list --active-repos.

The information displayed is name, address, and, if available, the repository description.

Through list --products the available products per repository are shown.

To display possible updates use list --updatable-products. This option only considers product already installed. Finally, the update can begin using update.

list --products displays available products list --updatable-products displays available updates.

Installed products are only considered using the aforementioned command. Product update is kicked off via update.

opsi-package-updater list --updatable-packages
opsi-package-updater -v update

Repository configurations are specified in /etc/opsi/package-updater.repos.d/. You will find a commented template with all possible configuration options in file example.repo.template.

There are two kinds of repositories - internet and opsi-server repositories.

Internet Repositories

Example: download.uib.de
You configure this repositories by:

You can configure access through proxy, if required. To use a common proxy for all repositories, specify it at the opsi-package-updater.conf file. This file requires at least opsi-utils 4.1.1.33. All repositories without their own proxy use this configuration.

baseUrl = http://download.uib.de
dirs = opsi4.0/products/localboot
username =
password =
proxy =

opsi-server

A repository has the opsi-server type, if the configured ID points to another opsi-server. You can specify such ID in the repository configuration file, under the item opsiDepotId.

opsiDepotId = mainserver.my.lan

You can set the central config server’on an 'opsi-depot-server. As a result, opsi-package-updater will fetch packages from the /var/lib/opsi/repository directory of such central server.

For each repository you have to configure which actions to run:

Administrators use this option together with notifications, to trigger a notification email. This way, the administrator can install the packages at a convenient time in the future.

In addition, you can send all these clients a Wake-On-LAN signal to install the new software. Furthermore, opsi-product shutdownwanted ensures that clients power off after the installation.

Versions 4.2 interface and info page merged into the new admin page. Point your browser to https://<opsi-server>:4447/admin to access. You must access with opsiadmin group credentials.

The first Blocked Clients tab displays a list of all blocked clients. Clicking the unblock button releases this client. You can unblock clients individually by IP or unblock all clients en masse.

With Delete client sessions you can delete all client sessions.

The user receives feedback in a text box under the input fields. The server’s JSON response is also output.

Figure 5.2. opsiconfd: Blocked Clients

The RPC-Info tab contains a table of the last RPC calls. Click the header bar to sort the table.

Figure 5.3. opsiconfd: RPC list

The RPC-Interface tab contains the former interface page. With the interface you can make API calls. The request and the response is displayed as JSON.

Figure 5.4. opsiconfd: RPC interface

You can use the Redis interface to make redis calls. The response from the server is displayed in JSON.

Figure 5.5. opsiconfd: Redis interface

The tab Grafana redirects the user to the Grafana dashboard of the opsiconfd. There you can find information about the load history of the opsiconfd.

Figure 5.6. opsiconfd info: opsiconfd values from the last 3 hours

Figure 5.7. opsiconfd info: opsiconfd values from the last day

If the Grafana server is running on the same host as the opsiconfd and no user and password have been set with the configuration variable grafana_internal_url, a new Grafana user is created in the database and the variable grafana_internal_url is adjusted (example: http://opsiconfd:passwort@<host>:3000). The creation of the user takes place when starting opsiconfd or calling opsiconfd setup. Grafana can be called via the admin page (https://<opsi-server>:4447/admin). Clicking on the appropriate tab will redirect to https://<opsi-server>:4447/metrics/grafana/dashboard. The endpoint metrics/grafana/dashboard creates and opens the dashboard in Grafana. On redirection the opsidashboard user is created if he does not exist. The opsidashbord user is used for the automatic login in Grafana and gets a random password on each call.

At the command line opsi-admin provides an interface to the opsi API. There’s an interactive mode and a non-interactive mode for batch processing from within scripts.

The opsi-admin --help switch displays a list of available command line options:

$ opsi-admin --help

Usage: opsi-admin [options] [command] [args...]
Options:
  -h, --help           Display this text
  -V, --version        Show version and exit
  -u, --username       Username (default: current user)
  -p, --password       Password (default: prompt for password)
  -a, --address        URL of opsiconfd (default: https://localhost:4447/rpc)
      --opsirc         Path to the opsirc file to use (default: ~/.opsi.org/opsirc)
                       An opsirc file contains login credentials to the web API.
  -d, --direct         Do not use opsiconfd
      --no-depot       Do not use depotserver backend
  -l, --log-level      Set log level (default: 3)
                       0=nothing, 1=essential, 2=critical, 3=error, 4=warning
                       5=notice, 6=info, 7=debug, 8=debug2, 9=confidential
  -f, --log-file       Path to log file
  -i, --interactive    Start in interactive mode
  -c, --colorize       Colorize output
  -S, --simple-output  Simple output (only for scalars, lists)
  -s, --shell-output   Shell output
  -r, --raw-output     Raw output
  --exit-zero          Always exit with exit code 0.

The opsi-admin command interacts by way of the opsi web service or first hand with the data backend. To work via the web service, you must specify username and password together with a URL. The opsi-admin command defaults to the currently logged-in user but allows you to specify a different username with --username.

For security, you want to avoid plain text passwords when using this command in scripts. This prevents unauthorized users from capturing the credential values. Use an opsirc file to secure your credentials or, as an alternative, use the -d option for direct data access.

opsi-admin includes an interactive mode, the -i switch, often used with -c, for colored display, and -d for direct data access. The full combined command becomes opsi-admin -i -c -d, or opsi-admin -idc for short.

Interactive mode uses the Tab key for navigation. The tab key allows you to navigate through the multiple choice options or input text fields. Page up and down scroll through the entire screen.

Options -s and -S generate an output format which scripts can easily parse through.

Besides API-request based method calls, there’s a collection of function ‘tasks’ which combine method calls to perform complex or specific jobs.

Starting on version 4.1.1.30, opsi-admin allows you to save web service connection configuration in a file. This allows you to use the web service without retyping your credentials every time you connect from command line.

By default, opsi-admin searches for credentials at ~/.opsi.org/opsirc but you can specify a different path using the --opsirc switch, allowing you to maintain various configuration files.

An opsirc file has the following contents:

address = https://seeing.the.ramp:4447/rpc
username = tony
password file = ~/.opsi.org/tonys_secret

Everything in an opsirc file is optional. If the file is empty or doesn’t exist, opsi will use the default values.

In the previous example, the ~/.opsi.org/tonys_secret file keeps the password and opsi in turn, reads this information from the specified path location. This file in turn, contains the password.

Although not recommended, you can state the password in plain text in the opsirc file:

address = https://seeing.the.ramp:4447/rpc
username = tony
password = first900

Set a product to setup for all clients which have this product installed. 

opsi-admin -d task setupWhereInstalled "softprod"

List of all clients. 

opsi-admin -d method host_getIdents

Delete client. 

opsi-admin -d method host_delete <clientname>

For example:

opsi-admin -d method host_delete "pxevm.uib.local"

Create client. 

opsi-admin -d method host_createOpsiClient <full qualified clientname>

For example:

opsi-admin -d method host_createOpsiClient "pxevm.uib.local"

Set action request. 

opsi-admin -d method setProductActionRequest <productId> <clientId> <actionRequest>

For example:

opsi-admin -d method setProductActionRequest win7 pxevm.uib.local setup

Attach client description. 

opsi-admin -d method setHostDescription "dpvm02.uib.local" "virtual client"

Listing the IDs of all clients. This uses the option -S so that every client is on its own line. Filtering OpsiClient avoids displaying the server IDs.

You can use this output in other programs or calls.

opsi-admin -dS method host_getIdents '' '{"type": "OpsiClient"}'

Listing products installed on clients. 

opsi-admin -d method productOnClient_getObjects '["productVersion", "packageVersion", "installationStatus"]' '{"installationStatus": "installed"}'

set pcpatch password. 

opsi-admin -d task setPcpatchPassword

Sets the password of the pcpatch user for Unix, samba and opsi.

At the object oriented methods a Object has some properties.

As a example let us have a look at the object Product. A object of the type Product which describes the opsi package javavm may look like this:

"ident": "javavm;1.6.0.20;2"
"id": "javavm"
"description": "Java 1.6"
"changelog": ""
"advice": ""
"userLoginScript": ""
"name": "SunJavaRuntimeEnvironment"
"priority": 0
"packageVersion": "2"
"productVersion": "1.6.0.20"
"windowsSoftwareIds": None
"productClassIds": None
"type": "LocalbootProduct"
"licenseRequired": False
"setupScript": "javavm.ins"
"updateScript": ""
"uninstallScript": "deljvm.ins"
"alwaysScript": ""
"onceScript": ""
"customScript": ""

Every object has a set of operators which can be used to work with this object. Most time these operators are:

The method names are concatenated:

<object name>_<operation>

According to this naming rule, these new methods are easily to difference from the old legacy opsi 3 methods, which almost start with get, set or create.

The getObjects methods have two optional parameters:

The attributes parameter is used query only for some properties of an object. If you are using attributes the returned object has all attribute keys, but only values the attribute you asked for and for all attributes which are used to identify this object. All other attributes have the value none.

For Example you will get by calling the method product_getObjects with attributes:["name"] for the package (Product) javavm:

"onceScript": None,
"ident": "javavm;1.6.0.20;2",
"windowsSoftwareIds": None,
"description": None,
"setupScript": None,
"changelog": None,
"customScript": None,
"advice": None,
"uninstallScript": None,
"userLoginScript": None,
"name": "Sun Java Runtime Environment",
"priority": None,
"packageVersion": "2",
"productVersion": "1.6.0.20",
"updateScript": None,
"productClassIds": None,
"alwaysScript": None,
"type": "LocalbootProduct",
"id": "javavm",
"licenseRequired": None

If you don’t want to ask for attributes but instead you need to use the second parameter filter you have to pass the attribute parameter as [].

The parameter filter is used to define which objects you want to get. For example if you are using the filter {"id":"javavm"} on the method product_getObjects the backend will return the Product object javavm only.

If you are using methods which expect one ore more objects, these objects have to be given as JSON objects or as an array of JSON objects.

The most important objects are:

In addition to the described objects and methods there are some more for special operations.

This design:

This results in improved stability and higher performance.

Example of a OpsiClient:

 method host_getObjects [] {"id":"xpclient.vmnat.local"}
[
          {
          "ident" : "xpclient.vmnat.local",
          "description" : "",
          "created" : "2012-03-22 12:13:52",
          "inventoryNumber" : "",
          "ipAddress" : "172.16.166.101",
          "notes" : "Created by opsi-deploy-client-agent at Wed, 24 Aug 2011 10:24:36",
          "oneTimePassword" : "",
          "lastSeen" : "2012-03-30 16:20:04",
          "hardwareAddress" : "00:0c:29:35:70:a7",
          "opsiHostKey" : "1234567890abcef1234567890abcdef",
          "type" : "OpsiClient",
          "id" : "xpclient.vmnat.local"
          }
]

Most of this data is displayed on the clients tab of the opsi-configed.

Possible types are:

The server type have different and additional data.

Example of a server:

 method host_getObjects [] {"id":"sepiolina.vmnat.local"}
[
          {
          "masterDepotId" : null,
          "ident" : "sepiolina.vmnat.local",
          "networkAddress" : "172.16.166.0/255.255.255.128",
          "description" : "",
          "inventoryNumber" : "",
          "ipAddress" : "172.16.166.1",
          "repositoryRemoteUrl" : "webdavs://sepiolina.vmnat.local:4447/repository",
          "depotLocalUrl" : "file:///var/lib/opsi/depot",
          "isMasterDepot" : true,
          "notes" : "",
          "hardwareAddress" : null,
          "maxBandwidth" : 0,
          "repositoryLocalUrl" : "file:///var/lib/opsi/repository",
          "opsiHostKey" : "1234567890abcef1234567890abcdef",
          "type" : "OpsiConfigserver",
          "id" : "sepiolina.vmnat.local",
          "depotWebdavUrl" : "webdavs://sepiolina:4447/depot",
          "depotRemoteUrl" : "smb://sepiolina/opsi_depot"
          }
]

Most of this data is displayed on the depot configuration of the opsi-configed.

Describes groups and their hierarchical structure. The types HostGroup and ProductGroup exist.

Example of a Group object:

 method group_getObjects
 [
       {
          "ident" : "sub2",
          "description" : "sub2",
          "notes" : "",
          "parentGroupId" : null,
          "type" : "HostGroup",
          "id" : "sub2"
          },
          {
          "ident" : "subsub",
          "description" : "subsub",
          "notes" : "",
          "parentGroupId" : "sub2",
          "type" : "HostGroup",
          "id" : "subsub"
          }
]

Describes the membership of an object in a group. Example of ObjectToGroup objects:

 method objectToGroup_getObjects
[
         {
          "groupType" : "HostGroup",
          "ident" : "HostGroup;sub2;win7.vmnat.local",
          "type" : "ObjectToGroup",
          "groupId" : "sub2",
          "objectId" : "win7.vmnat.local"
          },
          {
          "groupType" : "HostGroup",
          "ident" : "HostGroup;subsub;win7x64.vmnat.local",
          "type" : "ObjectToGroup",
          "groupId" : "subsub",
          "objectId" : "win7x64.vmnat.local"
          },
        {
          "groupType" : "ProductGroup",
          "ident" : "ProductGroup;opsiessentials;opsi-client-agent",
          "type" : "ObjectToGroup",
          "groupId" : "opsiessentials",
          "objectId" : "opsi-client-agent"
          },
          {
          "groupType" : "ProductGroup",
          "ident" : "ProductGroup;opsiessentials;opsi-winst",
          "type" : "ObjectToGroup",
          "groupId" : "opsiessentials",
          "objectId" : "opsi-winst"
          }
]

Describes the meta data of a product which are defined while creating the package.

Example of a product object:

 method product_getObjects [] {"id":"jedit","productVersion":"4.5"}
[
          {
          "onceScript" : "",
          "ident" : "jedit;4.5;3",
          "windowsSoftwareIds" :
                    [

                    ],
          "description" : "jEdit with opsi-winst Syntax-Highlighting",
          "setupScript" : "setup.ins",
          "changelog" : "",
          "customScript" : "",
          "advice" : "",
          "uninstallScript" : "uninstall.ins",
          "userLoginScript" : "",
          "name" : "jEdit programmer's text editor",
          "priority" : 0,
          "packageVersion" : "3",
          "productVersion" : "4.5",
          "updateScript" : "update.ins",
          "productClassIds" :
                    [

                    ],
          "alwaysScript" : "",
          "type" : "LocalbootProduct",
          "id" : "jedit",
          "licenseRequired" : false
          }
]

The attributes productClassIds and windowsSoftwareIds are currently unused.

Describes the properties of a Product' which are defined while creating the package.

Example of a ProductProperty object:

 method productProperty_getObjects [] {"productId":"jedit","productVersion":"4.5"}
[
          {
          "ident" : "jedit;4.5;3;start_server",
          "description" : "Should the jedit server be started at every startup ?",
          "editable" : false,
          "defaultValues" :
                    [
                    false
                    ],
          "multiValue" : false,
          "productVersion" : "4.5",
          "possibleValues" :
                    [
                    false,
                    true
                    ],
          "packageVersion" : "3",
          "type" : "BoolProductProperty",
          "propertyId" : "start_server",
          "productId" : "jedit"
          }
]

Describes:

Example for ProductPropertyState objects:

 method productPropertyState_getObjects [] {"productId":"jedit"}
[
          {
          "ident" : "jedit;start_server;sepiolina.vmnat.local",
          "objectId" : "sepiolina.vmnat.local",
          "values" :
                    [
                    false
                    ],
          "type" : "ProductPropertyState",
          "propertyId" : "start_server",
          "productId" : "jedit"
          },
         {
          "ident" : "jedit;start_server;xpclient.vmnat.local",
          "objectId" : "xpclient.vmnat.local",
          "values" :
                    [
                    true
                    ],
          "type" : "ProductPropertyState",
          "propertyId" : "start_server",
          "productId" : "jedit"
          }

]

Describes the dependencies of a package to another package as it is defined while creating the package.

Example of a ProductDependency object:

method productDependency_getObjects [] {"productId":"jedit","productVersion":"4.5"}
[
          {
          "ident" : "jedit;4.5;3;setup;javavm",
          "productAction" : "setup",
          "requiredPackageVersion" : null,
          "requirementType" : "before",
          "requiredInstallationStatus" : "installed",
          "productVersion" : "4.5",
          "requiredProductId" : "javavm",
          "requiredAction" : null,
          "requiredProductVersion" : null,
          "type" : "ProductDependency",
          "packageVersion" : "3",
          "productId" : "jedit"
          }
]

Describes which packages and versions are installed on which client.

Example of a ProductOnClient object:

 method productOnClient_getObjects [] {"productId":"jedit","clientId":"xpclient.vmnat.local"}
[
          {
          "ident" : "jedit;LocalbootProduct;xpclient.vmnat.local",
          "actionProgress" : "",
          "actionResult" : "successful",
          "clientId" : "xpclient.vmnat.local",
          "modificationTime" : "2012-03-30 15:49:04",
          "actionRequest" : "none",
          "targetConfiguration" : "installed",
          "productVersion" : "4.5",
          "productType" : "LocalbootProduct",
          "lastAction" : "setup",
          "packageVersion" : "3",
          "actionSequence" : -1,
          "type" : "ProductOnClient",
          "installationStatus" : "installed",
          "productId" : "jedit"
          }
]

Describes which product is installed in which version on a given depot..

Example of ProductOnDepot objects:

 method productOnDepot_getObjects [] {"productId":"jedit"}
[
          {
          "ident" : "jedit;LocalbootProduct;4.4.1;2;depotserver.vmnat.local",
          "locked" : false,
          "productVersion" : "4.4.1",
          "productType" : "LocalbootProduct",
          "depotId" : "depotserver.vmnat.local",
          "type" : "ProductOnDepot",
          "packageVersion" : "2",
          "productId" : "jedit"
          },
          {
          "ident" : "jedit;LocalbootProduct;4.5;3;sepiolina.vmnat.local",
          "locked" : false,
          "productVersion" : "4.5",
          "productType" : "LocalbootProduct",
          "depotId" : "sepiolina.vmnat.local",
          "type" : "ProductOnDepot",
          "packageVersion" : "3",
          "productId" : "jedit"
          }
]

Describes the available configurations.

Example of a Config object:

 method config_getObjects [] {"id":"opsiclientd.event_gui_startup.active"}
[
          {
          "ident" : "opsiclientd.event_gui_startup.active",
          "description" : "gui_startup active",
          "defaultValues" :
                    [
                    true
                    ],
          "editable" : false,
          "multiValue" : false,
          "possibleValues" :
                    [
                    false,
                    true
                    ],
          "type" : "BoolConfig",
          "id" : "opsiclientd.event_gui_startup.active"
          }
]

Describes the client specific state of a configuration.

Example of an ConfigState object:

 method configState_getObjects [] {"configId":"opsiclientd.event_gui_startup.active"}
[
          {
          "configId" : "opsiclientd.event_gui_startup.active",
          "ident" : "opsiclientd.event_gui_startup.active;wanclient.vmnat.local",
          "values" :
                    [
                    false
                    ],
          "objectId" : "wanclient.vmnat.local",
          "type" : "ConfigState"
          }
]

Describes the detected hardware types (including the client specific values). The idea is that you can see here the client specific data and in auditHardware only one entry for a network card which is used in all your computers.
Unfortunately in reality this doesn’t work as you might expect.

The attribute state describes if this is current (value = 1) or historic (value = 0) data.

Example of AuditHardwareOnHost objects:

 method auditHardwareOnHost_getObjects [] {"hostId":"xpclient.vmnat.local","hardwareClass":"NETWORK_CONTROLLER","ipAddress":"172.16.166.101"}
[
          {
          "vendorId" : "1022",
          "macAddress" : "00:0C:29:35:70:A7",
          "hardwareClass" : "NETWORK_CONTROLLER",
          "state" : 1,
          "deviceType" : "PCI",
          "subsystemVendorId" : "2000",
          "ipEnabled" : "True",
          "type" : "AuditHardwareOnHost",
          "firstseen" : "2012-03-30 15:48:15",
          "revision" : "10",
          "hostId" : "xpclient.vmnat.local",
          "vendor" : "Advanced Micro Devices (AMD)",
          "description" : "Ethernetadapter der AMD-PCNET-Familie",
          "subsystemDeviceId" : "1022",
          "deviceId" : "2000",
          "autoSense" : null,
          "netConnectionStatus" : "Connected",
          "maxSpeed" : null,
          "name" : "Ethernetadapter der AMD-PCNET-Familie",
          "serialNumber" : null,
          "lastseen" : "2012-03-30 15:48:15",
          "model" : null,
          "ipAddress" : "172.16.166.101",
          "adapterType" : "Ethernet 802.3"
          },
          {
          "vendorId" : "1022",
          "macAddress" : "00:0C:29:35:70:A7",
          "hardwareClass" : "NETWORK_CONTROLLER",
          "state" : 0,
          "deviceType" : "PCI",
          "subsystemVendorId" : "2000",
          "ipEnabled" : "True",
          "type" : "AuditHardwareOnHost",
          "firstseen" : "2012-03-08 14:26:14",
          "revision" : "10",
          "hostId" : "xpclient.vmnat.local",
          "vendor" : "VMware, Inc.",
          "description" : "VMware Accelerated AMD PCNet Adapter",
          "subsystemDeviceId" : "1022",
          "deviceId" : "2000",
          "autoSense" : null,
          "netConnectionStatus" : "Connected",
          "maxSpeed" : null,
          "name" : "VMware Accelerated AMD PCNet Adapter",
          "serialNumber" : null,
          "lastseen" : "2012-03-10 14:47:15",
          "model" : null,
          "ipAddress" : "172.16.166.101",
          "adapterType" : "Ethernet 802.3"
          },
   {
          "vendorId" : "1022",
          "macAddress" : "00:0c:29:35:70:a7",
          "hardwareClass" : "NETWORK_CONTROLLER",
          "state" : 0,
          "deviceType" : null,
          "subsystemVendorId" : "1022",
          "ipEnabled" : null,
          "type" : "AuditHardwareOnHost",
          "firstseen" : "2012-02-29 15:43:21",
          "revision" : "10",
          "hostId" : "xpclient.vmnat.local",
          "vendor" : "Advanced Micro Devices [AMD]",
          "description" : "Ethernet interface",
          "subsystemDeviceId" : "2000",
          "deviceId" : "2000",
          "autoSense" : "",
          "netConnectionStatus" : "yes",
          "maxSpeed" : null,
          "name" : "79c970 [PCnet32 LANCE]",
          "serialNumber" : "00:0c:29:35:70:a7",
          "lastseen" : "2012-03-30 14:58:30",
          "model" : "79c970 [PCnet32 LANCE]",
          "ipAddress" : "172.16.166.101",
          "adapterType" : ""
          }
]

Describes the detected hardware types (independent from client specific values). The idea in this object is to see client specific data and in AuditHardware only the generic. That way, for example, you can see here only one entry for a network card, which is used in all your computers.
Unfortunately in reality this idea doesn’t work as you might expect.

Example of AuditHardware objects:

 method auditHardware_getObjects [] {"hardwareClass":"NETWORK_CONTROLLER","vendorId":"1022"}
[
          {
          "vendorId" : "1022",
          "deviceId" : "2000",
          "maxSpeed" : null,
          "vendor" : "Advanced Micro Devices [AMD]",
          "name" : "79c970 [PCnet32 LANCE]",
          "subsystemDeviceId" : "2000",
          "deviceType" : null,
          "subsystemVendorId" : "1022",
          "autoSense" : "",
          "model" : "79c970 [PCnet32 LANCE]",
          "revision" : "10",
          "type" : "AuditHardware",
          "hardwareClass" : "NETWORK_CONTROLLER",
          "adapterType" : "",
          "description" : "Ethernet interface"
          },
          {
          "vendorId" : "1022",
          "deviceId" : "2000",
          "maxSpeed" : null,
          "vendor" : "VMware, Inc.",
          "name" : "VMware Accelerated AMD PCNet Adapter",
          "subsystemDeviceId" : "1022",
          "deviceType" : "PCI",
          "subsystemVendorId" : "2000",
          "autoSense" : null,
          "model" : null,
          "revision" : "10",
          "type" : "AuditHardware",
          "hardwareClass" : "NETWORK_CONTROLLER",
          "adapterType" : "Ethernet 802.3",
          "description" : "VMware Accelerated AMD PCNet Adapter"
          },
          {
          "vendorId" : "1022",
          "deviceId" : "2000",
          "maxSpeed" : null,
          "vendor" : "Advanced Micro Devices (AMD)",
          "name" : "Ethernetadapter der AMD-PCNET-Familie",
          "subsystemDeviceId" : "1022",
          "deviceType" : "PCI",
          "subsystemVendorId" : "2000",
          "autoSense" : null,
          "model" : null,
          "revision" : "10",
          "type" : "AuditHardware",
          "hardwareClass" : "NETWORK_CONTROLLER",
          "adapterType" : "Ethernet 802.3",
          "description" : "Ethernetadapter der AMD-PCNET-Familie"
          },
  {
          "vendorId" : "1022",
          "deviceId" : "2000",
          "maxSpeed" : null,
          "vendor" : "Advanced Micro Devices (AMD)",
          "name" : "Ethernetadapter der AMD-PCNET-Familie",
          "subsystemDeviceId" : "1022",
          "deviceType" : "PCI",
          "subsystemVendorId" : "2000",
          "autoSense" : null,
          "model" : null,
          "revision" : "10",
          "type" : "AuditHardware",
          "hardwareClass" : "NETWORK_CONTROLLER",
          "adapterType" : "Ethernet 802.3",
          "description" : "Ethernetadapter der AMD-PCNET-Familie"
          },
          {
          "vendorId" : "1022",
          "deviceId" : "2000",
          "maxSpeed" : null,
          "vendor" : "Advanced Micro Devices (AMD)",
          "name" : null,
          "subsystemDeviceId" : "2000",
          "deviceType" : "PCI",
          "subsystemVendorId" : "1022",
          "autoSense" : null,
          "model" : "",
          "revision" : null,
          "type" : "AuditHardware",
          "hardwareClass" : "NETWORK_CONTROLLER",
          "adapterType" : null,
          "description" : "Ethernetadapter der AMD-PCNET-Familie"
          },
(....)
[

Describes the detected software types (including the client specific values). The idea is that you will see here the client specific data and in auditSoftware only one entry for a office software which is used in all your computers.

Example of AuditSoftwareOnClient objects:

 method auditSoftwareOnClient_getObjects  [] {"name":"jEdit 4.5.0","clientId":"xpclient.vmnat.local"}
[
          {
          "ident" : "jEdit 4.5.0;4.5.0;;;x86;xpclient.vmnat.local",
          "licenseKey" : "",
          "name" : "jEdit 4.5.0",
          "uninstallString" : "\\\"C:\\\\Programme\\\\jEdit\\\\unins000.exe\\\"",
          "usageFrequency" : -1,
          "clientId" : "xpclient.vmnat.local",
          "lastUsed" : "0000-00-00 00:00:00",
          "subVersion" : "",
          "language" : "",
          "state" : 1,
          "version" : "4.5.0",
          "lastseen" : "2012-03-30 16:19:55",
          "binaryName" : "",
          "type" : "AuditSoftwareOnClient",
          "firstseen" : "2012-03-30 16:19:55",
          "architecture" : "x86"
          }
]

Describes the detected software types (independent from the client specific values). The idea is that you will see here only one entry for a office software which is used in all your computers.

Example of AuditSoftware objects:

 method auditSoftware_getObjects  [] {"name":"jEdit 4.5.0"}
[
          {
          "windowsDisplayVersion" : "4.5.0",
          "ident" : "jEdit 4.5.0;4.5.0;;;x64",
          "name" : "jEdit 4.5.0",
          "windowsSoftwareId" : "jedit_is1",
          "windowsDisplayName" : "jEdit 4.5.0",
          "installSize" : -1,
          "subVersion" : "",
          "language" : "",
          "version" : "4.5.0",
          "architecture" : "x64",
          "type" : "AuditSoftware"
          },
          {
          "windowsDisplayVersion" : "4.5.0",
          "ident" : "jEdit 4.5.0;4.5.0;;;x86",
          "name" : "jEdit 4.5.0",
          "windowsSoftwareId" : "jedit_is1",
          "windowsDisplayName" : "jEdit 4.5.0",
          "installSize" : -1,
          "subVersion" : "",
          "language" : "",
          "version" : "4.5.0",
          "architecture" : "x86",
          "type" : "AuditSoftware"
          }
]

Describes which license pools are assingned to which AuditSoftware patterns.

Example of AuditSoftwareToLicensePool objects:

 method auditSoftwareToLicensePool_getObjects [] {"licensePoolId":"win7-msdn-prof"}
[
          {
          "ident" : "Windows 7 Professional N;6.1;00376-165;de-DE;x64;win7-msdn-prof",
          "name" : "Windows 7 Professional N",
          "language" : "de-DE",
          "subVersion" : "00376-165",
          "licensePoolId" : "win7-msdn-prof",
          "version" : "6.1",
          "architecture" : "x64",
          "type" : "AuditSoftwareToLicensePool"
          },
          {
          "ident" : "Windows 7 Professional N;6.1;00376-165;de-DE;x86;win7-msdn-prof",
          "name" : "Windows 7 Professional N",
          "language" : "de-DE",
          "subVersion" : "00376-165",
          "licensePoolId" : "win7-msdn-prof",
          "version" : "6.1",
          "architecture" : "x86",
          "type" : "AuditSoftwareToLicensePool"
          }
]

Describes which softwareLicenseId is assingned to which licensePoolId.

Example of a SoftwareLicenseToLicensePool object:

method softwareLicenseToLicensePool_getObjects [] {"licensePoolId":"win7-msdn-prof"}
[
          {
          "licensePoolId" : "win7-msdn-prof",
          "softwareLicenseId" : "uib-msdn-win7-vol",
          "ident" : "uib-msdn-win7-vol;win7-msdn-prof",
          "licenseKey" : "12345-12345-12345-12345-3dbv6",
          "type" : "SoftwareLicenseToLicensePool"
          }
]

Describes the existing software licenses and their meta data.

Example of a softwareLicense object:S

 method softwareLicense_getObjects [] {"id":"uib-msdn-win7-vol"}
[
          {
          "ident" : "uib-msdn-win7-vol;msdn-uib",
          "maxInstallations" : 0,
          "boundToHost" : null,
          "expirationDate" : "0000-00-00 00:00:00",
          "licenseContractId" : "msdn-uib",
          "type" : "VolumeSoftwareLicense",
          "id" : "uib-msdn-win7-vol"
          }
]

Describes the existing licenses contracts and their meta data.

Example of a LicenseContract object:

 method licenseContract_getObjects [] {"id":"msdn-uib"}
[
          {
          "ident" : "msdn-uib",
          "description" : "",
          "conclusionDate" : "2011-04-22 00:00:00",
          "notificationDate" : "0000-00-00 00:00:00",
          "notes" : "",
          "expirationDate" : "0000-00-00 00:00:00",
          "partner" : "Microsoft",
          "type" : "LicenseContract",
          "id" : "msdn-uib"
          }
]

Describes which license is used by which client.

Example of a LicenseOnClient object:

 method licenseOnClient_getObjects  [] {"clientId":"win7client.vmnat.local"}
[
          {
          "softwareLicenseId" : "uib-msdn-win7-vol",
          "ident" : "uib-msdn-win7-vol;win7-msdn-prof;win7client.vmnat.local",
          "licenseKey" : "12345-12345-12345-12345-3dbv6",
          "notes" : "",
          "clientId" : "win7client.vmnat.local",
          "licensePoolId" : "win7-msdn-prof",
          "type" : "LicenseOnClient"
          }
]

Describes the license pool and to which opsi product the license pool is assigned.

Example of a LicensePool object:

 method licensePool_getObjects [] {"id":"win7-msdn-prof"}
[
          {
          "ident" : "win7-msdn-prof",
          "type" : "LicensePool",
          "description" : "MSDN Keys",
          "productIds" :
                    [
                    "win7",
                    "win7-x64"
                    ],
          "id" : "win7-msdn-prof"
          }
]

====== Special methods

Opsi has some special methods. This chapter will introduce some of the more important ones.

====== configState_getClientToDepotserver This is in fact also a storage object, but it’s a little aside of the standard. It tells us to which depot a client is currently assigned.

The syntax is

 method configState_getClientToDepotserver *depotIds *clientIds
*masterOnly *productIds

Example:

method configState_getClientToDepotserver [] "pcbon4.uib.local"
[
          {
          "depotId" : "bonifax.uib.local",
          "alternativeDepotIds" :
                    [

                    ],
          "clientId" : "pcbon4.uib.local"
          }
]

The hostControl methods are used to communicate and control the clients. Since opsi 4.0.3 we strongly recommend to use the hostControlSafe methods. All hostControlSafe or hostControl Methods have as last parameter the hostIds. The hostIds are the list of clients this method should work on. In all hostControlSafe methods this parameter is not optional, if you want to send a method to all clients you have to give a "*". In the older hostControl methods it is allowed to omit this parameter, which means send to all. This has caused some trouble to people which tried this with methods like hostControl_reboot. So with opsi 4.0.3 we broke the backward compatibility and now an empty hostIds is not any more allowed for the hostControl_reboot and hostControl_shutdown methods.

====== Tutorial: Working with groups

The following tutorial will show how to use the opsi interface from the commandline and work with groups of hosts in opsi.

We want to work with group objects and therefore need to work with those functions whose names start with group. Opsi does distinguish between groups of the type ProductGroup and HostGroup. The first is used for product groupings and the last is used for grouping hosts.

Creating a group of hosts is possible through the method group_createHostGroup. The parameters of the method are id, a description, notes and the parentGroupId (ID of the parent group). Only the ID is required - everything else is optional. The ID is also the name of the group.

To create a first group from the commandline we can now issue the following command:

opsi-admin -d method group_createHostGroup rechner_wenselowski "Nikos computer"

To check if our group was created we use group_getObjects.

opsi-admin -d method group_getObjects '' '{"id": "rechner_*", "type": "HostGroup"}'

To create some hierarchy we need to also specify the ID of the parent group.

opsi-admin -d method group_createHostGroup "rechner_wenselowski2" "Undergroup" "" "rechner_wenselowski"

We can use the call to group_getObjects from earlier to see that our group was indeed created.

Opsi has a default group that behaves like a directory service - i.e. OpenLDAP - that means, that a client can only be member of one group. There is a root group with the ID clientdirectory that assumes that exact behavior for any group / client inside. Any client not in a subgroup of clientdirectory will be moved to another special group with the ID NOT_ASSIGNED. Anyone working with that groups is responsible that clients are not member of multiple subgroups of clientdirectory.

Working with the clients is easy now. You probably have noticed that our earlier query to opsi did not show us any signs of clients. That is because the assignment from a client to a group is taken care of another type of object: objectToGroup.

To have a client at hand we will first create one:

opsi-admin -d method host_createOpsiClient "wenselowski-test.uib.local"

This client we now want to add to the group we created previously.

opsi-admin -d method objectToGroup_create "HostGroup" "rechner_wenselowski2" "wenselowski-test.uib.local"

Noticed the HostGroup as the first parameter? That is again our group type. To check if the creation was successful we can execute the following command:

opsi-admin -d method objectToGroup_getObjects '' '{"groupType": "HostGroup", "groupId": "rechner_wenselowski2"}'

If for some reason we want to remove a client we can do this as well. Just execute the following:

opsi-admin -d method objectToGroup_delete "HostGroup" "rechner_wenselowski2" "wenselowski-test.uib.local"

Finally you may want to clean up the groups we created earlier. The following statements will do this for you:

opsi-admin -d method group_delete "rechner_wenselowski"

By far the most important part of opsi is the configuration. True to LSB (Linux Standard Base), the configuration of opsi is located under /etc/opsi.

This directory mainly contains the backend configuration, the webservice configuration and the SSL certificate for the webservice. Furthermore, backend extensions are stored here, the configuration of opsipxeconfd, opsi-package-updater with its repositories and also the modules file, which unlocks your co-financed modules.

The directory /etc/opsi must be backed up in order to achieve a full recovery after an incident.

This part is secured with opsi-backup.

This backup also has another advantage:
If you have changed many configuration options of opsi and the system no longer works properly, it is usually easier and quicker to return to a previous working version than troubleshooting.

The opsi backends are listed in the following chapter. These form the heart of the opsi data storage. All clients, products, configurations, statuses, etc… are stored in the respective data storage.

Opsi offers the following data backends:

If you do not know which backend you are using, you are probably using the file backend. Opsi is also designed to use multiple backends at the same time. Which backends are used for which functions of opsi is configured in /etc/opsi/backendManager/dispatch.conf.

This part is secured with opsi-backup.

The depot files are interesting because they contain the actual files of the software to be distributed. The localboot products as well as the netboot products each have their files stored under /var/lib/opsi/depot. In previous versions of opsi they were located in the directory /opt/pcbin/install.

Depending on how much software is kept on the opsi-server, and how many operating system installations including drivers are stored, this data volume can take on enormous proportions.

There are different approaches to back up these files. The simplest alternative is rsnapshot. However, there are more elegant solutions, such as storing this data in a redundant file system on a SAN, etc.

This part is not backed up by opsi-backup.

The opsi workbench area, which is also used as a Samba-share of the same name (opsi_workbench), contains the state of your own software packaging. By default, the directory is /var/lib/opsi/workbench. If this share is used to store your created packages in different revisions, this directory should also be saved.

The rsnapshot tool is also suitable here.

This part is not backed up by opsi-backup.

The directory /var/lib/opsi/repository is used to store opsi packages. Unlike the opsi workbench, it is not used to create opsi packages, but the opsi packages that are stored there should not be removed, in order to simplify a possible synchronization with other servers or the synchronization using opsi-package-updater.

These files are not absolutely necessary for a complete recovery, but can also be saved with the rsnapshot tool.

This part is not backed up by opsi-backup.

The TFTP directory contains configuration files for booting via PXE. This directory is located under /tftpboot/ on most systems. On SLES this directory is /var/lib/tftpboot/opsi/.

Possibly modified files are e.g. linux/pxelinux.cfg/default.menu or linux/pxelinux.cfg/default.nomenu. These files are created with default values when installing opsi-linux-bootimage. These are not absolutely necessary for disaster recovery.

This part is not backed up by opsi-backup.

A new opsi backup is created with the command opsi-backup create. If this command is given without further parameters, the program creates an archive with all data of the backends and the configuration. The file name is generated automatically. Additional program help is available for the opsi-backup create command, which is output using the --help option.

opsi-backup create
opsi-backup create --help

It is also possible to specify the file name or the target directory of the new backup. To do this, simply add a file name or a target directory to the corresponding command. If a directory is specified, opsi-backup automatically generates a file in this directory. A file name generated by opsi-backup has the form <hostname>_<opsi-version>_<date>_<time> and is well suited for archiving several backups. If a file name is specified, an older backup with the same name will be overwritten by opsi-backup.

opsi-backup create /mnt/backup/opsi_backup.tar.bz2
opsi-backup create /mnt/backup/

In addition, the create command enables the backup to be controlled using the following options:

opsi-backup create --no-configuration --backends=all opsi_backup.tar.bz2

opsi-backup does not have any functionality for archiving backups. The administrator must therefore ensure that created backups are stored securely and versioned. In addition, opsi-backup never automatically deletes older backup versions (unless they are overwritten with create). Since opsi-backup always creates full backups and no incremental backups, the amount of data can quickly grow to a large size. The administrator must thus also ensure that older backups are deleted regularly if necessary.

With the command opsi-backup verify the archive can be checked for internal integrity. This check is not a logical check of the data, it is a pure check if the data stored in the archive is not corrupted. Additional help is available for the opsi-backup verify command, which is shown using the --help option.

Example

opsi-backup verify opsi_backup.tar.bz2
opsi-backup verify --help

With the command opsi-backup list the contents of a backup will be displayed. The listing shows whether configuration data is available, and from which backends data is in the backup.

Example

opsi-backup list opsi_backup.tar.bz2

Restoring an archive is done with the command opsi-backup restore. The backends are (by default) imported based on the current configuration. It is therefore not possible to restore a pure backend backup, if an opsi configuration is not available. The command opsi-backup restore needs a parameter, which is the backup archive from which data is to be restored. Additional help is available for the opsi-backup restore command, which is output using the --help option.

opsi-backup restore accepts the following options:

opsi-backup restore --configuration --backends=all opsi_backup.tar.bz2

If a backup is restored to a server and there is no backup of the depot folder, you can use opsi-package-updater and opsi-package-manager to download and install all packages from the repository again. Any changes made to the depot must then be applied again afterwards.

opsi-package-updater download --force
opsi-package-manager --install /var/lib/opsi/repository/*.opsi

The hardware and software inventory data are by default stored in text files via the opsi file backend. This form of data storage is less suitable for queries and reports. For this, the data can be stored in a SQL database.

Main features of the backend mysql:

Due to the very different nature of the hardware components to be inventoried, the data structure is roughly structured as follows:

The situation is similar for the software inventory. Again, the Software table describes the total software found, while the Software_Config table stores the client-specific configuration.

This results in the following list of tables:

HARDWARE_CONFIG_1394_CONTROLLER
HARDWARE_CONFIG_AUDIO_CONTROLLER
HARDWARE_CONFIG_BASE_BOARD
HARDWARE_CONFIG_BIOS
HARDWARE_CONFIG_CACHE_MEMORY
HARDWARE_CONFIG_COMPUTER_SYSTEM
HARDWARE_CONFIG_DISK_PARTITION
HARDWARE_CONFIG_FLOPPY_CONTROLLER
HARDWARE_CONFIG_FLOPPY_DRIVE
HARDWARE_CONFIG_HARDDISK_DRIVE
HARDWARE_CONFIG_IDE_CONTROLLER
HARDWARE_CONFIG_KEYBOARD
HARDWARE_CONFIG_MEMORY_BANK
HARDWARE_CONFIG_MEMORY_MODULE
HARDWARE_CONFIG_MONITOR
HARDWARE_CONFIG_NETWORK_CONTROLLER
HARDWARE_CONFIG_OPTICAL_DRIVE
HARDWARE_CONFIG_PCI_DEVICE
HARDWARE_CONFIG_PCMCIA_CONTROLLER
HARDWARE_CONFIG_POINTING_DEVICE
HARDWARE_CONFIG_PORT_CONNECTOR
HARDWARE_CONFIG_PRINTER
HARDWARE_CONFIG_PROCESSOR
HARDWARE_CONFIG_SCSI_CONTROLLER
HARDWARE_CONFIG_SYSTEM_SLOT
HARDWARE_CONFIG_TAPE_DRIVE
HARDWARE_CONFIG_USB_CONTROLLER
HARDWARE_CONFIG_VIDEO_CONTROLLER
HARDWARE_DEVICE_1394_CONTROLLER
HARDWARE_DEVICE_AUDIO_CONTROLLER
HARDWARE_DEVICE_BASE_BOARD
HARDWARE_DEVICE_BIOS
HARDWARE_DEVICE_CACHE_MEMORY
HARDWARE_DEVICE_COMPUTER_SYSTEM
HARDWARE_DEVICE_DISK_PARTITION
HARDWARE_DEVICE_FLOPPY_CONTROLLER
HARDWARE_DEVICE_FLOPPY_DRIVE
HARDWARE_DEVICE_HARDDISK_DRIVE
HARDWARE_DEVICE_IDE_CONTROLLER
HARDWARE_DEVICE_KEYBOARD
HARDWARE_DEVICE_MEMORY_BANK
HARDWARE_DEVICE_MEMORY_MODULE
HARDWARE_DEVICE_MONITOR
HARDWARE_DEVICE_NETWORK_CONTROLLER
HARDWARE_DEVICE_OPTICAL_DRIVE
HARDWARE_DEVICE_PCI_DEVICE
HARDWARE_DEVICE_PCMCIA_CONTROLLER
HARDWARE_DEVICE_POINTING_DEVICE
HARDWARE_DEVICE_PORT_CONNECTOR
HARDWARE_DEVICE_PRINTER
HARDWARE_DEVICE_PROCESSOR
HARDWARE_DEVICE_SCSI_CONTROLLER
HARDWARE_DEVICE_SYSTEM_SLOT
HARDWARE_DEVICE_TAPE_DRIVE
HARDWARE_DEVICE_USB_CONTROLLER
HARDWARE_DEVICE_VIDEO_CONTROLLER
HOST
SOFTWARE
SOFTWARE_CONFIG

The assignment of the column names to individual device classes results from the following list (/etc/opsi/hwaudit/locales/en_US):

DEVICE_ID.deviceType = Device type
DEVICE_ID.vendorId = Vendor ID
DEVICE_ID.deviceId = Device ID
DEVICE_ID.subsystemVendorId = Subsystem vendor ID
DEVICE_ID.subsystemDeviceId = Subsystem device ID
DEVICE_ID.revision= Revision
BASIC_INFO.name = Name
BASIC_INFO.description = Description
HARDWARE_DEVICE.vendor = Vendor
HARDWARE_DEVICE.model = Model
HARDWARE_DEVICE.serialNumber = Serial number
COMPUTER_SYSTEM = Computer
COMPUTER_SYSTEM.sku = Stock Keeping Unit
COMPUTER_SYSTEM.systemType = Type
COMPUTER_SYSTEM.totalPhysicalMemory = Physical Memory
COMPUTER_SYSTEM.dellexpresscode = Dell Expresscode
CHASSIS = Chassis
CHASSIS.name = Name
CHASSIS.chassisType = Chassis type
CHASSIS.installDate = Installation date
CHASSIS.serialNumber = Serial number
BASE_BOARD = Base board
BASE_BOARD.product = Product
BIOS = BIOS
BIOS.version = Version
SYSTEM_SLOT = System slot
SYSTEM_SLOT.currentUsage = Current usage
SYSTEM_SLOT.status = Status
SYSTEM_SLOT.maxDataWidth = Maximum data width
PORT_CONNECTOR = Port
PORT_CONNECTOR.connectorType = Attributes
PORT_CONNECTOR.internalDesignator = Internal designator
PORT_CONNECTOR.internalConnectorType = Internal type
PORT_CONNECTOR.externalDesignator = External designator
PORT_CONNECTOR.externalConnectorType = External type
PROCESSOR = Processor
PROCESSOR.architecture = Architecture
PROCESSOR.family = Family
PROCESSOR.currentClockSpeed = Current clock speed
PROCESSOR.maxClockSpeed = Maximum clock speed
PROCESSOR.extClock = External clock
PROCESSOR.processorId = Processor-ID
PROCESSOR.addressWidth = Address width
PROCESSOR.socketDesignation = Socket designation
PROCESSOR.voltage = Voltage
PROCESSOR.NumberOfCores = Number Of Cores
PROCESSOR.NumberOfLogicalCores = Number Of Logical Cores
MEMORY_BANK = Memory bank
MEMORY_BANK.location = Location
MEMORY_BANK.maxCapacity = Maximum capacity
MEMORY_BANK.slots = Number of slots
MEMORY_MODULE = Memory module
MEMORY_MODULE.deviceLocator = Device locator
MEMORY_MODULE.capacity = Capacity
MEMORY_MODULE.formFactor = Form factor
MEMORY_MODULE.speed = Speed
MEMORY_MODULE.memoryType = Memory type
MEMORY_MODULE.dataWidth = Data width
MEMORY_MODULE.tag = Tag
CACHE_MEMORY = Cache memory
CACHE_MEMORY.installedSize = Installed size
CACHE_MEMORY.maxSize = Maximum size
CACHE_MEMORY.location = Location
CACHE_MEMORY.level = Level
PCI_DEVICE = PCI device
PCI_DEVICE.busId = Bus id
NETWORK_CONTROLLER = Network adapter
NETWORK_CONTROLLER.adapterType = Adapter type
NETWORK_CONTROLLER.maxSpeed = Maximum speed
NETWORK_CONTROLLER.macAddress = MAC address
NETWORK_CONTROLLER.netConnectionStatus = Net connection status
NETWORK_CONTROLLER.autoSense = auto-sense
NETWORK_CONTROLLER.ipEnabled = IP protocoll enabled
NETWORK_CONTROLLER.ipAddress = IP address
AUDIO_CONTROLLER = Audio controller
HDAUDIO_DEVICE = HD Audio device
HDAUDIO_DEVICE.address = Addresse
IDE_CONTROLLER = IDE controller
SCSI_CONTROLLER = SCSI controller
FLOPPY_CONTROLLER = Floppy controller
USB_CONTROLLER = USB controller
1394_CONTROLLER = 1394 controller
PCMCIA_CONTROLLER = PCMCIA controller
VIDEO_CONTROLLER = Video controller
VIDEO_CONTROLLER.videoProcessor = Video processor
VIDEO_CONTROLLER.adapterRAM = Adapter RAM
DRIVE.size = Size
FLOPPY_DRIVE = Floppy drive
TAPE_DRIVE = Tape drive
HARDDISK_DRIVE = Harddisk drive
HARDDISK_DRIVE.cylinders = Cylinders
HARDDISK_DRIVE.heads = Heads
HARDDISK_DRIVE.sectors = Sectors
HARDDISK_DRIVE.partitions = Partitions
DISK_PARTITION = Partition
DISK_PARTITION.size = Size
DISK_PARTITION.startingOffset = Starting offset
DISK_PARTITION.index = Index
DISK_PARTITION.filesystem = Filesystem
DISK_PARTITION.freeSpace = Free space
DISK_PARTITION.driveLetter = Drive letter
OPTICAL_DRIVE = Optical drive
OPTICAL_DRIVE.driveLetter = Drive letter
USB_DEVICE = USB device
USB_DEVICE.vendorId = Vendor ID
USB_DEVICE.deviceId = Device ID
USB_DEVICE.usbRelease = USB release
USB_DEVICE.maxPower = Maximum power
USB_DEVICE.interfaceClass = Interface class
USB_DEVICE.interfaceSubClass = Interface sub class
USB_DEVICE.interfaceProtocol = Interface protocol
USB_DEVICE.status = Status
MONITOR = Monitor
MONITOR.screenHeight = Screen height
MONITOR.screenWidth = Screen width
KEYBOARD = Keyboard
KEYBOARD.numberOfFunctionKeys = Number of function keys
POINTING_DEVICE = Pointing Device
POINTING_DEVICE.numberOfButtons = Number of buttons
PRINTER = Printer
PRINTER.horizontalResolution = Horizontal resolution
PRINTER.verticalResolution = Vertical resolution
PRINTER.capabilities = Capabilities
PRINTER.paperSizesSupported = Supported paper sizes
PRINTER.driverName = Driver name
PRINTER.port = Port

Examples queries: List of all hard drives:

SELECT
  *
FROM HARDWARE_DEVICE_HARDDISK_DRIVE AS d
LEFT OUTER JOIN HARDWARE_CONFIG_HARDDISK_DRIVE AS h
ON
  d.hardware_id = h.hardware_id ;

The software inventory uses as primary key the following entries:

In the table Software_config these fields are combined to the field config_id.

Figure 5.8. database schema: software inventory

The mysql backend for configuration data has been available since opsi 4.0.

This module is currently a co-financed opsi extension. This means it is not free to use.
Further details can be found in Section 9.1, “Activation of non-free modules”.

The {mysql backend} has the advantage of a higher performance, especially with large installations.

Here is an overview of the data structure:

Figure 5.9. database schema: configuration data

If the MySQL server is not yet installed, this must first be done by:

apt-get install mysql-server

Then a password must be set for the MySQL-user root user':

mysqladmin --user=root password linux123

The database can now be set up with the command opsi-setup --configure-mysql.

An example session:

Figure 5.10. opsi-setup --configure-mysql: Input dialog

Figure 5.11. opsi-setup --configure-mysql: Output

In the input dialog, all entries can be confirmed with Enter except for the password.

Next you have to specify in /etc/opsi/backendManager/dispatch.conf that the mysql backend should also be used. A detailed description of this configuration can be found in the Backend configuration chapter of the getting-started manual. The file itself contains a number of examples of typical configurations. A configuration for the mysql backend (without internal dhcpd) looks like this:

backend_.*         : mysql, opsipxeconfd
host_.*            : mysql, opsipxeconfd
productOnClient_.* : mysql, opsipxeconfd
configState_.*     : mysql, opsipxeconfd
.*                 : mysql

After completing the configuration, you must execute the following commands to use the now configured and converted backend:

opsi-setup --init-current-config
opsi-setup --set-rights
systemctl restart opsiconfd.service
systemctl restart opsipxeconfd.service

A manual configuration can be done via the backend configuration file. By default this is /etc/opsi/backends/mysql.conf.

Since python-opsi 4.1.1.76 it has been possible to force the creation of new connections after a certain time in order to avoid problems with timeouts. One indication of such timeouts can be the message mysql server has gone away.

You can set a timeout by specifying connectionPoolRecycling after how many seconds a new connection should be created. The default value is -1, which means no forced reconnection. If this value is set, it should generally be lower than the value for connection timeouts configured on the server (wait_timeout).

The existing database must be configured so that external access is possible, i.e. not only connections from localhost are accepted.

Please refer to the manual of your database for the necessary steps.

The IP number and IP name of the clients can be entered here (additional names are aliases, and comments start with the "#" character).

Opsi needs the fully qualified hostname (i.e. including the domain) and this can come from /etc/hosts as well from the DNS.

Example:

192.168.2.106  dplaptop.uib.local  dplaptop  # this opsi-server
192.168.2.153  schleppi.uib.local
192.168.2.178  test_pc1.uib.local # Test-PC PXE-bootprom

The output of:

getent hosts $(hostname -f)

should be similar to:

192.168.1.1 server.domain.tld server

If the result does not look like this (e.g. contains 127.0.0.1 or localhost), you must first correct your /etc/hosts or name resolution.

Two groups must exist here: pcpatch and opsiadmin. All users who are dealing with package management should be member of the group pcpatch. All users who want to use the opsiconfd web service, e.g. via opsi-configed, must be in the opsiadmin group.

Configuration files for the used backends.

Since opsi version 3.2

Here you will find the configuration files for the hardware inventory.

Translations are located in the locales directory.

The mapping between WMI classes (for Windows) or shell programs (for Linux) and the opsi data storage is configured in the file opsihwaudit.conf.

Since opsi version 4.0.2-2

General opsi settings.

Example:

[groups]
fileadmingroup = pcpatch

Background: The classic installation variant with the user: pcpatch with the primary group: pcpatch does not work with Samba 4. Since Samba 4 is subject to the basic restrictions of Active Directory, groups with the same name as users (as is usual in Unix/Linux) are no longer allowed. For this reason, a new configuration file has been introduced: /etc/opsi/opsi.conf, which controls how the group is determined for Samba access to the shares. In the case of Samba 4 installations, the group name pcpatch is now renamed via this file and is now called opsifileadmins. This means that the users which must have access rights to the shares of opsi (opsi-packagers) under Samba 4 cannot become a member of the pcpatch group, but must be a member of the opsifileadmins group.

Since opsi version 3.4

This file is signed by uib gmbh for the activation of non-free features. If this file is changed, it loses its validity. Without this file, only the free features are available.

Since opsi version 4.1

Directory reserved for future usage.

Since opsi 4.1.

Directory for future use.

Since opsi version 3.0

Configuration file for the opsiconfd service in which settings such as ports, interfaces and logging are specified.

Since opsi version 3.0

Configuration file for the opsiconfd service in which the ssl certificate is stored.

Configuration file for the opsipxeconfd service, which is responsible for writing the startup files for the Linux bootimage. Directories, defaults and log levels can be configured here.

Configuration file for the opsi-package-updater. See also Section 5.3.3, “Tool: opsi-package-updater”

This directory is exported (read-only) as the Samba share opsi_depot. In old opsi installations this directory was /opt/pcbin/install. If this directory still exists, a symlink references it to /var/lib/opsi/depot.

This is the default directory where the partition images are stored, that are used with the netboot product opsi-clonezilla.

This is the place where opsi-product-packages are saved, which are loaded by the calls of the opsi-package-updater to the server.

This is also the place where opsi-product-packages are saved, which are installed by the calls of the opsi-package-manager if it is called with the option -d.

This is the location used to create your own packages.

The remaining directories in /var/lib/opsi (config and audit) are directories of the file backend, which is described in the following chapter.

The client-specific opsi-host-keys and also the server key are stored here.

Example:

schleppi.uib.local:fdc2493ace4b372fd39dbba3fcd62182
laptop.uib.local:c397c280fc2d3db81d39b4a4329b5f65
pcbon13.uib.local:61149ef590469f765a1be6cfbacbf491

The passwords encrypted with the server key (e.g. for pcpatch) are stored here.

The files of the file backend of opsi 4 can by default be found in /var/lib/opsi/config/. The following diagram gives an overview of the directory structure:

/var/lib/opsi-|
              |-depot                           opsi_depot share
              |-repository                      opsi package repository used by opsi-package-updater and opsi-package-manager
              |-audit                           inventory files
              !-config/-|                               config share
                        |-clientgroups.ini      client groups
                        |-config.ini            Host Parameters (Global Defaults)
                        |-clients/              <pcname.ini> files
                        |-products/             product control files
                        !-depots                depot description files

        +audit/
                global.<Type> (generic hard-, and software information)
                <FQDN>.<Type> (host specific hard-, and software information)

        clientgroups.ini (contains the hostgroups)

        +clients/
                <FQDN>.ini (client configuration information)
        config.ini (contains the host specific host parameters)

        +depots/
                <FQDN>.ini (Information of the depots)

        +products/
                <ID>_<ProdVer>-<PackVer>.<Type> (Information about the products)

        +templates/
                pcproto.ini (template for new clients)
                <FQDN>.ini (template for specific new clients)

The following chapters explain the structure of the different configuration files of the file backend.

This file contains information about the client groups.

[<GroupId>]
<HostId> = 1 #active
<HostId> = 0 #non-active

Here you will find the default values of the server configuration as shown in opsi-configed in the host parameters tab.

The client-specific configurations are stored in this file. The information is combined with the values from <depot-id>.ini, whereby the settings from <FQDN>.ini take precedence.

These files are structured as follows:

The info section contains all information directly related to the client, for example the description:

[info]
description = <String>
created = <Date> #format: 'YYYY-MM-DD HH:MM:SS'
lastseen = <Date> #format: 'YYYY-MM-DD HH:MM:SS'
inventorynumber = <String>
notes = <String>
hardwareaddress = <MAC> #format: 'hh:hh:hh:hh:hh:hh'
ipaddress = <IP> #format: 'nnn.nnn.nnn.nnn'
onetimepassword = <String>

The following section stores the current status of the products on the client. If there are no entries, not_installed: none is assumed.

[<Type>_product_states] #'LocalbootProduct', or 'NetbootProduct'
<ProductId> = <InstallationStatus>:<ActionRequest>

More detailed information can be found in the sections belonging to the respective products:

[<ProductId>-state]
producttype = <Type> #'LocalbootProduct', or 'NetbootProduct'
actionprogress = <String>
productversion = <ProdVer>
packageversion = <PackVer>
modificationtime = <Date> #format: 'YYYY-MM-DD HH:MM:SS'
lastaction = <ActionRequest>
actionresult = <ActionResult>
targetconfiguration = <InstallationStatus>

This is the location of the file pcproto.ini, which is the standard template for creating new client ini-files and has the same structure. If specific clients should be given different information, you can save a <FQDN>.ini in this directory.

Here you will find the files of the opsi-depot-server, which are also saved with <depot-id>.ini. Among other things, the connection to the depot is stored here.

[depotshare]
remoteurl = smb://<NetBiosName>/<Path>
localurl = file://<Path>

[depotserver]
notes = <String>
network = <IP>
description = <String>
hardwareaddress = <MAC>
ipaddress = <IP>
inventorynumber = <String>

[repository]
remoteurl = webdavs://<FQDN>:<Port>/<Path>
localurl = file://<Path>
maxbandwidth = <Integer> #in Bytes

Here you will also find information on which opsi products, in which version, and with which property defaults are installed on the depot.

The product control files contain the metadata of the products, e.g. name, properties and their default values, dependencies …

The control files correspond to the control files that are created when creating opsi products in the directory <product name>/OPSI/control.

The control files consist of the following sections:

Example:

[Package]
version: 1
depends:

[Product]
type: localboot
id: thunderbird
name: Mozilla Thunderbird
description: Mail client by Mozilla.org
advice:
version: 2.0.0.4
priority: 0
licenseRequired: False
productClasses: Mailclient
setupScript: thunderbird.ins
uninstallScript:
updateScript:
alwaysScript:
onceScript:

[ProductProperty]
name: enigmail
description: Install encryption plug-in for GnuPG
values: on, off
default: off

[ProductDependency]
action: setup
requiredProduct: mshotfix
requiredStatus: installed
requirementType: before

This is the location of the inventory data for hardware (*.hw) and software (*.sw).

Here you can find the log files of the bootimage from the clients. These files are created as <fqdn>.log.

If the bootimage can not connect to the web service, the log file can be found on the client under /tmp/log. In such a case, there are two ways to get the log file from the client:

An example session:

#sfdisk -l
Disk /dev/sda: 30401 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sda1   *      0+  30401-  30402- 244197528+   7  HPFS/NTFS
/dev/sda2          0       -       0          0    0  Empty
/dev/sda3          0       -       0          0    0  Empty
/dev/sda4          0       -       0          0    0  Empty

Disk /dev/sdb: 1017 cylinders, 33 heads, 61 sectors/track
Units = cylinders of 1030656 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sdb1          0+   1016    1017-   1023580    b  W95 FAT32
/dev/sdb2          0       -       0          0    0  Empty
/dev/sdb3          0       -       0          0    0  Empty
/dev/sdb4          0       -       0          0    0  Empty
# mount /dev/sdb1 /mnt
# cp /tmp/log /mnt
#umount /mnt

This is the location of the log files of the opsi-client-agent running on the clients.
This is C:\opsi.org\log\opsiclientd.log on the client.

This is the location of log files of the opsi-winst scripts executed on the clients.
The originals are on the client at C:\opsi.org\log\opsiscript.log

This is the location of log files of opsiconfd itself as well as log files of the clients.
The files are created as <IP address>.log and if configured in /etc/opsi/opsiconfd.conf, symbolic links for these are created as <fqdn>.log.

Log file the opsipxeconfd
which manages the files in the tftp area of the server that are necessary for the PXE boot of the clients.

Log file of opsi-package-manager.

Log file of opsi-package-updater.

The log entries of tftpd can be found in /var/log/syslog.

Log file of opsi-login-blocker

Log file of opsiclientd.
This file is copied to the server at /var/log/opsi/clientconnect/<fqdn>.log when finished.

Log file of opsi-winst.
This file is copied to the server at /var/log/opsi/instlog/<fqdn.log> when finished.

As part of a new installation of an operating system via unattended setup with opsi, the opsi-client-agent is automatically installed.

To uninstall the opsi-client-agent, the action request can be set to uninstall.

For installation afterwards or for repair purposes, see chapter Section 6.1.6, “Subsequent installation of the opsi-client-agents”.

Core component of the opsi-client-agent is the service opsiclientd. This service starts on boot.

It performs the following tasks:

The opsi-login-blocker for NT5 (Win2K/WinXP) is implemented as a GINA (opsigina.dll). This GINA waits until the opsiclientd reports, that all product actions are finished or, if the opsiclientd is not reachable, until the connection timeout to the opsiclientd is reached (normally 120 seconds). Then the complete control is forwarded to the next GINA, which is normally the msgina.dll.

The opsi-login-blocker for NT6 (Vista/Win7/Win10) is implemented as a credential provider filter (OpsiLoginBlocker.dll). This credential provider filter blocks all credential providers until the opsiclientd reports, that all product actions are finished or, if the opsiclientd is not reachable, until the connection timeout to the opsiclientd is reached (normally 120 seconds).

How the opsiclientd works may be configured in many details. To understand these configuration options, it is necessary to understand the processing sequence. Here comes an overview of the work flow of a standard event like the event_gui_startup.

Figure 6.5. simplified work flow of a standard event

The most important parameters have the following relations:

(the section called “opsiclientd infopage”).

The following chapters show how to configure the opsi-client-agent.

To meet the requirements of the various different situations in which the opsi-client-agent will become active, a slightly complex configuration is needed. To reduce the complexity, the configuration file uses something like inheritance.
In the opsiclientd configuration section headers like [event_<config-id>] introduce a new event configuration section. An event configuration may be disabled by setting the section option active = false.

There are different types of event configurations (type).

A small example for a better understanding:
While installing software it may be necessary to reboot the computer. Is there currently a user logged on, you should warn about the pending reboot. This warning should have a timeout and it may make sense to ask the user, if the reboot should be canceled (at the moment).
Is there no user logged on, it makes no sense to ask and wait for an answer. So in this case the reboot should take place immediately.
To handle these different situations, we configure the event_on_demand in the following way:

To limit the functionality of an event to a certain time frame a so called working_window can be configured for all events.

To enable the working_window feature the key working_window has to be added to the configuration of the event. If this key is not present, has no value, or an invalid value it is treated as empty and the event has no time limit.

All events support the working_window feature.
Configuration is done by adding the host parameter working_window to the event of your choice. This can be achived by using the opsi-configed, or via opsi-admin on the opsi-config-server.

The following example shows how to configure a working_window for the event gui_startup using opsi-admin
See the section called “Configuration via web service (Host Parameter)” for how to add host parameter using opsi-configed.

Example 1: Adding an empty working_window for the event event_gui_startup globally. The time restriction has to be configured client specific (see example 3).

opsi-admin -d method config_createUnicode opsiclientd.event_gui_startup.working_window

Example 2: Adding a working_window with a timeframe between 20:00 and 07:00 for the event event_gui_startup globally.

opsi-admin -d method config_createUnicode opsiclientd.event_gui_startup.working_window "gui_startup.working_window" "20:00-07:00"

Example 3: Client specific configuration of the working_window using a timeframe from 07:00 to 19:00 for the event event_gui_startup.

opsi-admin -d method configState_create opsiclientd.event_gui_startup.working_window "client.domain.de" "07:00-19:00"

If the starttime is higher than the endtime the working_window will be valid over the nightly day change (23:59-0:00).
Example during the day (starttime < endtime): working_window=07:00-19:00
Example during the night (starttime > endtime): working_window=20:00-07:00

For the example "working_window=20:00-07:00" the opsiclientd log would look like this:

[5] [<timestamp>] [ event processing gui_startup] Current time 01:02:13.993000 is within the configured working window (20:00-07:00)

The opsiclientd supports the IPv4 and IPv6 protocols when connecting to the opsi service. Normally the protocol is selected automatically when the connection is established. But there is also the possibility to configure the protocol version to be used. For this the option "ip_version" can be used in the section "global" of the opsiclientd.conf. Possible values are "4" (use IPv4), "6" (use IPv6) and "auto" (select protocol automatically, default value).

In the section "global" of the opsiclientd.conf there is the possibility to configure a proxy server. If a proxy is configured, all HTTP and HTTPS connections from opsiclientd will be redirected through this proxy.

# Use a proxy for connecting configservice
# proxy_mode:
#   'system' will try to check the system setting,
#   'static' to use proxyurl from configfile/hostparameter
# proxy_url usage: http://<user>:<password>@<proxy-url>:<proxy-port>
# Example: http://proxyuser:proxypass123@proxy.domain.local:8080
proxy_mode = static
proxy_url =

This proxy settings allows also to use a proxyserver, that require authentication. In that case you must define the credentials as shown in the configuration snippet.

With this new feature it’s possible over the configuration to control the list of products, that will be processed in Events with product groups:

There are (basically) two ways to use this control:

Blacklisting (excluding):

The option exclude_product_group_ids allows to configure a comma separated list of product Groups. The members of these groups will be excluded from the actual Event. Also if action request is set for this products. This products will be ignored in this event, but the action requests will not be changed.

White listing (including):

The option include_product_group_ids allows to also configure a comma separated list of products Groups. The members of this groups are the only products, that will be processed from the actual event if they have set action requests.

You can use these options globally from the default-Event. From that point this settings will be used in every event. You can also set these options in a special event. If you use the option on event_on_demand, you can control which products will not be installed in push installations, although they have an action request. On normal restart of the client, the products will be installed from gui_startup (default event) at startup. CAUTION: For Clients that work in WAN/VPN-mode you must set this options in sync-event and also in the cacheservice-section, because the cache service have no access to the configuration of main sync-event.

On a 64bit Windows the configuration file is c:\program files (x86)\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf.

On a 32bit Windows the configuration file is c:\program files\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf.

The configuration written in this file may be changed by different configuration data, which come via web service after a successful connection to the opsi-server.

A sample opsiclientd.conf:

; = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
; =     configuration file for opsiclientd                              =
; = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =


; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     global settings                                                 -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[global]

# Location of the log file.
log_file = c:\\opsi.org\\log\\opsiclientd.log

# Set the log (verbosity) level
# (0 <= log level <= 9)
# 0: nothing, 1: essential, 2: critical, 3: errors, 4: warnings, 5: notices
# 6: infos, 7: debug messages, 8: more debug messages, 9: passwords
log_level = 4

# Client id.
host_id =

# Opsi host key.
opsi_host_key =

# Verify tls certificates
verify_server_cert = false

# Trust the uib opsi CA
trust_uib_opsi_ca = true

# Install opsi CA into os store
install_opsi_ca_into_os_store = false

# Which ip version to use (4/6/auto)
ip_version = auto

# On every daemon startup the user login gets blocked
# If the gui starts up and no events are being processed the login gets unblocked
# If no gui startup is noticed after <wait_for_gui_timeout> the login gets unblocked
# Set to 0 to wait forever
wait_for_gui_timeout = 120

# Application to run while blocking login
block_login_notifier = %global.base_dir%\\notifier.exe -s notifier\\block_login.ini

# Use a proxy for connecting configservice
# proxy_mode:
#   'system' will try to check the system setting,
#   'static' to use proxyurl from configfile/hostparameter
# proxy_url usage: http://<user>:<password>@<proxy-url>:<proxy-port>
# Example: http://proxyuser:proxypass123@proxy.domain.local:8080
proxy_mode = static
proxy_url =

# Try to Suspend Bitlocker before rebooting the client
suspend_bitlocker_on_reboot = false

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     config service settings                                         -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[config_service]
# Service url.
# http(s)://<opsi config server address>:<port>/rpc
url = https://opsi.uib.local:4447/rpc

# Conection timeout.
connection_timeout = 30

# The time in seconds after which the user can cancel the connection establishment
user_cancelable_after = 30

# If this option is set, the local system time will be synced with time from service
sync_time_from_service = false

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     depot server settings                                           -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[depot_server]

# Depot server id
depot_id =

# Depot url.
# smb://<depot address>/<share name>/<path to products>
url =

# Local depot drive
drive =

# Username that is used for network connection [domain\]<username>
username = pcpatch

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     cache service settings                                          -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[cache_service]
# Maximum product cache size in bytes
product_cache_max_size = 5000000000
# Members of this ProductGroups will be excluded from processing
exclude_product_group_ids =
# Only members of this ProductGroups will be excluded from processing
include_product_group_ids =

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     control server settings                                         -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[control_server]

# The network interfaces to bind to.
# This must be the IP address of an network interface.
# Use 0.0.0.0 to listen to all interfaces
interface = 0.0.0.0

# The port where opsiclientd will listen for HTTPS rpc requests.
port = 4441

# The location of the server certificate.
ssl_server_cert_file = %global.base_dir%\\opsiclientd\\opsiclientd.pem

# The location of the server private key
ssl_server_key_file = %global.base_dir%\\opsiclientd\\opsiclientd.pem

# The location of the static files
static_dir = %global.base_dir%\\opsiclientd\\static_html

# The maximum number of authentication failures before a client ip
# is blocked for an amount of time.
max_authentication_failures = 5

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     notification server settings                                    -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[notification_server]

# The network interfaces to bind to.
# This must be the IP address of an network interface.
# Use 0.0.0.0 to listen to all interfaces
interface = 127.0.0.1

# The first port where opsiclientd will listen for notification clients.
start_port = 44000

# Port for popup notification server
popup_port = 45000

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     opsiclientd notifier settings                                   -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[opsiclientd_notifier]

# Notifier application command
command = %global.base_dir%\\notifier.exe -p %port% -i %id%

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     opsiclientd rpc tool settings                                   -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[opsiclientd_rpc]

# RPC tool command
command = %global.base_dir%\\opsiclientd_rpc.exe "%global.host_id%" "%global.opsi_host_key%" "%control_server.port%"

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     action processor settings                                       -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[action_processor]
# Locations of action processor
local_dir = %global.base_dir%\\opsi-script
remote_dir = opsi-script\\files\\opsi-script
filename = winst32.exe

# Action processor command
command = "%action_processor.local_dir%\\%action_processor.filename%" /opsiservice "%service_url%" /clientid %global.host_id% /username %global.host_id% /password %global.opsi_host_key%

# Load profile / environment of %run_as_user%
create_environment = false

; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; -     events                                                          -
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[event_default]
; === Event configuration
# Type of the event (string)
type = template
# Interval for timer events in seconds (int)
interval = -1
# Maximum number of event repetitions after which the event will be deactivated (int, -1 = forever)
max_repetitions = -1
# Time in seconds to wait before event becomes active (int, 0 to disable delay)
activation_delay = 0
# Time in seconds to wait before an event will be fired (int, 0 to disable delay)
notification_delay = 0
# Event notifier command (string)
event_notifier_command = %opsiclientd_notifier.command% -s notifier\\event.ini
# The desktop on which the event notifier will be shown on (current/default/winlogon)
event_notifier_desktop = current
# Block login while event is been executed (bool)
block_login = false
# Lock workstation on event occurrence (bool)
lock_workstation = false
# Logoff the current logged in user on event occurrence (bool)
logoff_current_user = false
# Get config settings from service (bool)
get_config_from_service = true
# Store config settings in config file (bool)
update_config_file = true
# Transmit log file to opsi service after the event processing has finished (bool)
write_log_to_service = true
# Shutdown machine after action processing has finished (bool)
shutdown = false
# Reboot machine after action processing has finished (bool)
reboot = false
# Members of this ProductGroups will be excluded from processing
exclude_product_group_ids =
# Only members of this ProductGroups will be excluded from processing
include_product_group_ids =

; === Sync/cache settings
# Sync configuration from local config cache to server (bool)
sync_config_to_server = false
# Sync configuration from server to local config cache (bool)
sync_config_from_server = false
# Sync configuration from local config cache to server after action processing (bool)
post_sync_config_to_server = false
# Sync configuration from server to local config cache after action processing (bool)
post_sync_config_from_server = false
# Work on local config cache
use_cached_config = false
# Cache products for which actions should be executed in local depot cache (bool)
cache_products = false
# Maximum transfer rate when caching products in byte/s (int, 0 = no limit)
cache_max_bandwidth = 0
# Dynamically adapt bandwidth to other network traffic (bool)
cache_dynamic_bandwidth = false
# Work on local depot cache
use_cached_products = false

; === Action notification (if product actions should be processed)
# Time in seconds for how long the action notification is shown (int, 0 to disable)
action_warning_time = 0
# Action notifier command (string)
action_notifier_command = %opsiclientd_notifier.command% -s notifier\\action.ini
# The desktop on which the action notifier will be shown on (current/default/winlogon)
action_notifier_desktop = current
# Message shown in the action notifier window (string)
action_message = Starting to process product actions. You are allowed to cancel this event a total of %action_user_cancelable% time(s). The event was already canceled %state.action_processing_cancel_counter% time(s).
# German translation (string)
action_message[de] = Starte die Bearbeitung von Produkt-Aktionen. Sie können diese Aktion insgesamt %action_user_cancelable% mal abbrechen. Die Aktion wurde bereits %state.action_processing_cancel_counter% mal abgebrochen.
# French translation (string)
action_message[fr] = Traitement des actions du produit. Vous êtes autorisé à annuler cet événement un total de %action_user_cancelable% fois. L'événement a été déjà annulée %state.action_processing_cancel_counter% fois.
# Number of times the user is allowed to cancel the execution of actions (int)
action_user_cancelable = 0

; === Action processing
# Should action be processed by action processor (bool)
process_actions = true
# Type of action processing (default/login)
action_type = default
# Update the action processor from server before starting it (bool)
update_action_processor = true
# Command which should be executed before start of action processor
pre_action_processor_command =
# Action processor command (string)
action_processor_command = %action_processor.command%
# The desktop on which the action processor command will be started on (current/default/winlogon)
action_processor_desktop = current
# Action processor timout in seconds (int)
action_processor_timeout = 10800
# Command which should be executed before after action processor has ended
post_action_processor_command =

; === Shutdown notification (if machine should be shut down or rebooted)
# Process shutdown requests from action processor
process_shutdown_requests = true
# Time in seconds for how long the shutdown notification is shown (int, 0 to disable)
shutdown_warning_time = 0
# Shutdown notifier command (string)
shutdown_notifier_command = %opsiclientd_notifier.command% -s notifier\\shutdown.ini
# The desktop on which the action notifier will be shown on (current/default/winlogon)
shutdown_notifier_desktop = current
# Message shown in the shutdown notifier window (string)
shutdown_warning_message = A reboot is required to complete software installation tasks. You are allowed to delay this reboot a total of %shutdown_user_cancelable% time(s). The reboot was already delayed %state.shutdown_cancel_counter% time(s).
# German translation (string)
shutdown_warning_message[de] = Ein Neustart wird benötigt um die Software-Installationen abzuschliessen. Sie können diesen Neustart insgesamt %shutdown_user_cancelable% mal verschieben. Der Neustart wurde bereits %state.shutdown_cancel_counter% mal verschoben.
# French translation (string)
shutdown_warning_message[fr] = Un redémarrage est nécessaire pour terminer l'installation du logiciel. Vous êtes autorisé à retarder le redémarrage un total de %shutdown_user_cancelable% fois. Le redémarrage a été déjà retardé %state.shutdown_cancel_counter% fois.
# Number of times the user is allowed to cancel the shutdown (int)
shutdown_user_cancelable = 0
# Time in seconds after the shutdown notification will be shown again after the user has canceled the shutdown (int)
shutdown_warning_repetition_time = 3600

[event_gui_startup]
super = default
type = gui startup
name = gui_startup
block_login = true

[event_gui_startup{user_logged_in}]
name = gui_startup
shutdown_warning_time = 300
block_login = false

[event_gui_startup{cache_ready}]
use_cached_config = true
use_cached_products = true
action_user_cancelable = 3
action_warning_time = 60

[event_gui_startup{installation_pending}]
name = gui_startup
active = true

[event_on_demand]
super = default
type = custom
name = on_demand

[event_on_demand{user_logged_in}]
name = on_demand
shutdown_warning_time = 300

[event_software_on_demand]
super = default
type = sw on demand

[event_sync]
super = default
type = template
process_actions = false
event_notifier_command =
sync_config_to_server = true
sync_config_from_server = true
cache_products = true
cache_dynamic_bandwidth = true

[event_timer]
super = sync
type = timer
active = false
interval = 3600

[event_net_connection]
super = sync
type = custom
active = false
wql = SELECT * FROM __InstanceModificationEvent WITHIN 2 WHERE TargetInstance ISA 'Win32_NetworkAdapter' AND TargetInstance.NetConnectionStatus = 2

[event_sync_completed]
super = default
type = sync completed
event_notifier_command =
process_actions = false
get_config_from_service = false
write_log_to_service = false

[event_sync_completed{cache_ready_user_logged_in}]
reboot = true
shutdown_user_cancelable = 10
shutdown_warning_time = 300

[event_sync_completed{cache_ready}]
reboot = true

[event_user_login]
super = default
type = user login
action_type = login
active = false
action_message = Starting to process user login actions.
action_message[de] = Beginne mit der Verarbeitung der Benutzer-Anmeldungs-Aktionen.
action_message[fr] = Traitement des actions à la connexion de l'utilisateur.
block_login = false
process_shutdown_requests = false
get_config_from_service = false
update_config_file = false
write_log_to_service = false
update_action_processor = true
event_notifier_command = %opsiclientd_notifier.command% -s notifier\\userlogin.ini
event_notifier_desktop = default
action_processor_command = %action_processor.command% /sessionid %service_session% /allloginscripts /silent
action_processor_desktop = default
action_processor_timeout = 300

[event_on_shutdown]
super = default
type = custom
name = on_shutdown
active = False

[event_on_shutdown{installation_pending}]
name = on_shutdown
active = False

[event_silent_install]
super = default
type = custom
name = silent_install
event_notifier_command =
process_shutdown_requests = false
action_processor_productIds = swaudit,hwaudit
action_processor_command = %action_processor.command% /productlist %action_processor_productIds% /silent
action_processor_desktop = winlogon
action_processor_timeout = 300

[event_timer_silentinstall]
super = silent_install
type = timer
active = false
interval = 21600

[precondition_user_logged_in]
user_logged_in = true

[precondition_cache_ready]
config_cached = true
products_cached = true

[precondition_cache_ready_user_logged_in]
user_logged_in = true
config_cached = true
products_cached = true

[precondition_installation_pending]
installation_pending = true

The opsiclientd configuration can be changed by the host parameter tab at the opsi management interface.

The entries in the host parameter have to be according to the following patterns:

opsiclientd.<name of the section>.<name of the key>

Example:
opsiclientd.event_gui_startup.action_warning_time = 20
set in the configuration file opsiclientd.conf in the section [event_gui_startup] the value of action_warning_time to the value 20.

The following figure shows how to change the serverwide general configure via opsi-configed

Figure 6.6. Setting the server default opsiclientd configuration

Using the context menu you may choose add property to set a new key/value pair.

To delete a server default, please use the opsi-admin tool:

Example:

opsi-admin -d method config_delete "opsiclientd.event_gui_startup.action_warning_time"

It is also possible to manipulate these entries client specific via opsi-configed.

To delete a client specific entry, please use the opsi-admin tool:

Example:

@opsi-admin> method configState_delete "opsiclientd.event_gui_startup.action_warning_time" "myclient.uib.local"

Figure 6.7. client specific opsiclientd configuration via opsi-configed

The opsiclientd logs to:
C:\opsi.org\log\opsiclientd.log.

All log information will be transferred to the opsi-config-server via web service. At the server you find these log infos at /var/log/opsi/clientconnect/<ip-or-name-of-the-client>.log. They are presented in the opsi configed at the tab logfiles / client connect.

Every line at the log has the pattern:
[<log level>] [<time stamp>] [message source] message.