The opsi-configed requires Java 1.7 and a running opsiconfd on the server.

Most times the opsi-configed will be called from the opsi server page with address

https://<servername>:4447

or directly as applet via:

https://<servername>:4447/configed

The opsi-configed can be as well installed as a local application. There the complex security administration of browser based java can be omitted. An opsi-configed opsi package can be found at download.uib.de. The installation produces an entry in the windows start menue.

At the server the opsi-configed is installed as part of the opsi-server installation. It may be started using the menue entry or with the command /usr/bin/opsi-configed.

If the file configed.jar is placed in the current directory, the program can just be started by java -jar configed.jar.

The help option java -jar configed.jar --help shows the available command line options.

java -jar configed.jar --help

configed [OPTIONS]

Options:
     -l, --locale  LOC  Set locale LOC (format: <language>_<country>)
     -h, --host  HOST    Configuration server to connect to
     -u, --user  USER   Username for authentication
     -p, --password  PWD Password for authentication
     -d, --logdirectory DIR Directory for the log files
     -c, --client CLIENT Start with selected client CLIENT
     -g, --group GROUP Start with activated group GROUP
     -t, --tab X Start with selected tab X
     -qs, --querysavedsearch SAVEDSEARCH_NAME Give names of clients on commandline which are produced by this search
      -r, --refreshminutes MIN   Refresh client connect data every MIN (0 = never)
         --help    Show this text
         --gzip  [/y/n] Activate gzip transmission of data from opsi server (default yes)
         --sqlgetrows  Get data by method getRawData where implemented
         --version  Tell configed version
         --loglevel L   Set logging level to L

logging directory not yet set
regularly exiting app with code 0

Figure 4. opsi-configed: login mask

At login time the opsi-configed tries to connect the opsi server via https. The login is done with the given parameters opsi server[:Port] (default port 4447 – opsiconfd) and the User/Password of the opsi-config-server account. For a successful login the provided user has to be a member of the unix-group opsiadmin.

The gzip compression in HTTP protocol reduces the amount of data to be transferred at the expense of an extended processing time, this is due to the fact that the data must be compressed and decompressed. It has been determined that the reaction times tend to be shorter without compression in the local network, as the effects normally surpass the prolonged processing time. For transmissions over the WAN, it tends to be the opposite. Normally little difference is noticed in WAN connections, but usually necessary, and that is why the Gzip option is enabled by default.

The feature to check which clients are reachable runs in the background and shows the results in the client table. It can be enabled from the login screen mask or via command line parameter. The default refresh interval is 0 min (= deactivated).

You may copy the selected entries from nearly every section of the opsi-configed to the clipboard using the standard key combinations (Strg-Insert, Strg-C). This may be used to transfer interesting data to other programs. For the most tables you may also use Drag & Drop to copy the data to programs like Excel.

To switch between the different usage modes of the opsi-configed, use the buttons in the upper right corner. Since version 4.0.4, there six buttons.

Figure 5. opsi-configed: Usage modes

The first three buttons allow to change the editing target of the main window: client configuration, server configuration. On the other hand, each of the buttons "group actions", "product actions" and "licence management" starts a special window for managing the specific objects or actions.

All opsi-depotservers integrated with your server are listed in the upper left corner of the opsi-configed. By default the depot on your opsi-config-server is selected and the clients belonging to this opsi-depot are shown.

You can select multiple Depots at the same time and edit their clients together. However, only if the selected depots are synchronized with each other. Trying to edit clients from asynchronous depots together will be rejected with an appropriate warning and the corresponding error message.

As of version 4.0.5, there is no need to carry out a complete data-reload when changing to a different depot-server, that means, when you select a depot its data is loaded immediately. In addition, there are the following buttons:

Figure 6. opsi-configed: depot selection

After a successful login the main window pops up and shows the tab Client selection. This tab shows a list of known clients from the selected opsi-depot resp. the clients which are selected using the treeview control on the left side of the opsi-configed.

Since version 4.0.4, the opsi-configed saves on the local machine, for the current user, the current depotserver and group selection. If the opsi-configed is restarted, work may continue at the point where it had been.

Observe that group selection is preserved when changing depot selection. In order to see all clients in the other depot the group selection has to be changed appropriately.

Figure 7. opsi-configed: client selection mask

You may select a line of the list not only by manual scrolling and selecting but also by a String search. This requires that you enter a String into the search field at the top of the list In der Liste kann eine Zeile auch über die Suche nach einem Stringwert ausgewählt werden.

How the search works is determined by the selected elements in two drop down lists:

Via field selection you decides if

Concerning the method of search you have to choose if a hit is defined

The enter key leads to the next search hit. More selection functions based on String search are shown in the context menu of the search field.

Figure 8. opsi-configed: Search function in the client selection list

The clients list

The clients list has per default the columns client name, description, on, IP address and last seen.

• client name is the full qualified hostname which is the client name including the domain name
• description is a free selectable description which you can edit in the right top part of the window
• On shows after clicking the button Check wich clients are connected the result of this query. This feature runs in the background and shows the results in the client table. It can be enabled from the login screen mask or via command line parameter. The default refresh interval is 0 min (= deactivated).

Figure 9. opsi-configed: Button Check which clients are connected

Figure 10. opsi-configed: Client reachable

Figure 11. opsi-configed: Client unreachable

• IP address shows the IP number to which the opsi server resolves the client name.
• last seen shows the date and a time of the last client connect to the opsiconfd web service

Some columns are deactivated by default:

• session infos (data as retrieved from the operating system running on the specific client)
• Inventory No (displaying some optionally entered data)
• created (date and time of client creation)
• opsi mac address (hardware address of the client as used by opsi)

You may activate these columns using the context menu. The configuration which columns are activated may be changed using the entry configed.host_displayfields in the server configuration.

Figure 12. opsi-configed: change the default for visible columns in the clients list

Adding the column session infos enables the button "request session infos from all clients" in the button panel.

Figure 13. opsi-configed: Button Sessioninfo

When this button is clicked the opsiconfd tries to connect to all clients and to retrieve data of the active user sessions. From the result, the account names are shown in the column session infos. Instead of using the button you may start the request only for the selected clients via the context menu or the main menu entry OpsiClient. By this, waiting for the network timeouts is avoided.

Since the search function for the client list works (if not configured otherwise) on all displayed columns you may now find out which is the client belonging to a logged in user (with known account name).

To sort the clients by a certain column click on the top header of that column.

Selecting clients

You can select one or multiple clients to work with. The client view can be restricted to the selected clients by clicking the funnel icon or from the menu by Grouping / Show only selected clients.

A selected client group can be saved with the icon Save grouping or from the menu by Grouping / save group with a free selectable name.

You can use the mouse to add the selected clients to an existing group (by dragging them to an existing group which is displayed in the tree view).

In the client selection dialog (as called via menu Selection / Define search) clients can be selected using a variety of criteria based on their configurations.

Figure 14. opsi-configed: Auswahldialog

E.g., it is possible to search for opsi installed products as well as software as found by the opsi software audit. You may as well search for PCs satisfying certain hardware conditions. Criteria may be combined by logical and or or operations and may be negated. Search strings can be given as fixed strings combined with asterisks * as wildcard symbols.

Search definitions can be saved and then again used via the menu item Selection/Use saved search definition.

Figure 15. opsi-configed: Saved Search

It is also possible to run a saved search from the command line when the opsi-configed editor is started. By including the flag "-qs" and the name of the saved search, the configuration editor will start with the saved search results. If the name is omitted, then a list of available searches will be displayed.

To detect failed installations, the menu item Selection offers Failures with product and Failures occurred (today, since yesterday, …), since version 4.0.5 .
Choose the first setting to get a list of all products. If you select a single product, all clients will be shown, where the installation of this product failed.
When choosing for instance Failures occured - today, all the clients will be marked, where an product installation failed today.

Figure 16. opsi-configed: Failed Actions

Since opsi 4.0 it is possible to manage groups and clients using a tree view control on the left side of the opsi-configed. A second enhancement is the possibility of hierarchical groups (groups in groups).

Basic concepts

The tree view control has three base nodes "groups", "directory" and "client list". Every known client is alwas in the group client list.

Additionally a client may be in one or more groups. You may build up different group trees which may represent different ways to organize them, according to your own criteria. Like administrative structure, hardware or typical software inventory.
If a client needs to be in one or more groups use the base node groups. For clients that need to be exclusively in one group, use the directory node.

If you select a client, all groups where the client belongs will get colored marked icons.

Figure 17. opsi-configed: Treeview with clients and groups

How to …

By a click one a node (or a group) all clients beyond this node will be shown in the Clients tab, but none of these clients is selected for processing.

By a click one a client, this client will be shown in the Clients tab and selected for processing. You may also use this way to change the selected client while you are in a other tab like product configuration without coming back to the clients tab.

You may use Ctrl-click and Shift-click to select multiple clients. This tree view control show the groups which are created according the chapter

You may also create groups by using the context menu above ALL or any existing group.

Figure 18. opsi-configed: Using the context menu to create a new subgroup

You will be asked for the new groups name.

Figure 19. opsi-configed: Dialog: Group name

A group can be populated with clients using Drag&Drop by

• copying clients from the Clients tab to the group in the tree view (left mouse button)
• copying clients from the tree view control below the node ALL to group in the tree view (left mouse button)
• moving clients from a group in the tree view control to a other group in the tree view (left mouse button)
• copying clients from a group in the tree view control to a other group in the tree view (Ctrl-left mouse button)

Using the menu OpsiClient or the context menu in the Clients tab you may choose from a lot of client specific operations

Figure 20. opsi-configed: : context menu Clients Tab

Sending messages (Show popup message)

Choosing the menu entry Show popup message you will get a small edit window where you can type in your message.

Figure 21. opsi-configed: opsi message edit mask

By clicking on the red tick you will send the message to the selected clients.

At the selected clients a message window will appear.

Figure 22. opsi-configed: opsi message display dialog

On WAN clients there are occasional problems with package cache synchronization. The function resets the cache.

Call external remote control tools for selected clients

The option Remote Control Software call in the client context menu as well as the client main menu (since opsi-configed version 4.0.1.11) is very powerful. It can be used to use any command that the operating system offers, parametrized e.g. by the client name.

As an example there are configurations automatically generated which can be used to send a ping to the selected client: one ping command that works in Windows environment and one command that requires a Linux X environment. Please observe: opsi-configed calls obviously the command in its environment, i.e., we need the Linux command when the opsi-configed is running in Linux.

Figure 23. opsi-configed: Choice of Remote Control call

The selection window has three parts. The upper part lists the names of the existing commands. It follows a line, which shows the selected command and offers the chance to edit it (if this is allowed). Additionally, the line contains the buttons to execute or abandon the action. The third text area of the window captures any messages that are returned by the operating system when calling the command.

These calls offer a quasi infinite range of opportunities. For example, a command can be configured to open a Remote Desktop connection to the selected client (if it allows such connections). On a Windows system, such a command is

cmd.exe /c start mstsc /v:%host%

In a Linux environment the following command can be used:

rdesktop -a 16 %host%

In these examples serves %host% as a variable, which opsi-configed automatically replaces by the value for the selected host. Other variables that can be analogously used in the commands are:

• %ipaddress%
• %hardwareaddress%
• %opsihostkey%
• %inventorynumber%
• %depotid%
• %configserverid%

If the command is marked by the additional server configuration entry editable as true, then the command line allows ad hoc editing. For example, you may supply a requested password or vary the command as needed.

Caution

If there is some command declared as editable then in fact any program addressed at the client computer can be called by changing the editable command.

If more than one client is selected the command will be executed in a own thread for each client.

The list of remote control commands is editable via server configuration entries (cf. the section called “Host parameters at client and server configuration”).

To define a command example, at minimum an entry configed.remote_control.example (or configed.remote_control.example.command) must be generated. The value of property has to be the command (in which the variables %host%, %ipaddress% etc. can be used). Additionally, an entry configed.remote_control.example.description can be defined. The value of this entry will be shown as tooltip (if not existing, the command itself will serve as tooltip content). Furthermore, a Boolean entry configed.remote_control.example.editable can be added. If its value is set to false the command cannot be edited in the selection window.

Figure 24. opsi-configed: Editing of remote control commands in the server properties editor

Delete, create, rename and move clients

You may delete the selected clients from the opsi-server.

If you choose to create a client, an input mask opens. There you enter or confirm the required data – client name without domain specification, domain name, depot server name. You may add a textual description for this client and notes on this client.

Figure 25. opsi-configed: creating a client

The mask also contains fields for an optional declaration of the IP-number and the ethernet (MAC) address of a client. If the backend is activated for the configuration of a local dhcp-server (which is not the default setting), this information will be used to make the new client known to the dhcp-server. Otherwise the MAC address will be saved in the backend and the IP-number will be discarded.

When creating clients you can directly for the new client specify to which group it should belong, as well as which netboot product should be directly set on setup. In addition, you can activate directly the Install by shutdown, UEFI Boot and the (standard) WAN configuration from the beggining. These settings can easily be made in the Hosts-List. These configurations are only available since the version 4.0.5.8.1 .

Since opsi 4.0.4 it is possible to disable the options for creation and deletion of an opsi client. This is used if the client creation should be managed by a different service, eg. the UCS service.

For the configuration of these options, a host parameter (config) is provided. It is named configed.host_actions_disabled and offers the list values

• add client
• remove client

(multiple selection allowed). The default is the empty selection meaning that no option is disabled.

The default setting can be changed so that adding and removing clients from the opsi-configed is disabled:

opsi-admin -d method config_createUnicode "configed.host_actions_disabled" "Disable host actions" ["add client","remove client"] ["add client","remove client"] false true

You may rename a selected client, you will be asked for the new name.

Moving a client to a different depot-server. If clicked the following windows appears with a list of existing depot-servers

Figure 26. opsi-configed: change the depot of a client

Switching to the tab Product configuration you get a list of available software packets with its installation status and action status for the selected clients.

Figure 27. opsi-configed: product configuration mask

Since opsi 4.0.4 a search function is added.

ith the search function products can be searched by product names and (if desired) in combination with special values in the fields of the product table (like searching the client table). Therefore a search string can be entered. The search starts immediately and the first matching line is marked . If there is no match to be found (or characters are removed from the search string), the first line of the table is marked.

The context menu offers some more options.

Figure 28. opsi-configed: Product search with context menu

To get a better overview, activating the filter function reduces the product view to the selected products only. The selections stays active until the filter is disabled by clicking the filter button again.

If there is a different status for the selected clients this will be marked grey (undefined). The list of the selected clients is shown at right on top.

You can also sort the product list by clicking at the column header.

This are the columns:

There are two more columns which can be activated via the context menu:

Choose a software product to get more product information in the right part of the window like:

A property table is a two-column table. In each row, the first column contains a property name, the second column displays the assigned property value(s).

It may be configured that a tool tip is displayed showing some information on the meaning of the property and the default value.

Figure 29. opsi-configed: property table with tooltip

If you click at a value a window pops up: the list editor for this property. It shows a value resp. a list of preconfigured values with the current value as selected.

Figure 30. opsi-configed: list editor, selection list

Clicking a new value changes the selection.

If the property value list is editable (new values may be added to the existing list resp. existing values changed) the window comes up with an edit field for the new or modified values.

Figure 31. opsi-configed: list editor, edit field

The most comfortable way to get a new value that is a variant of an existing one is double clicking the existing value in the list. This copies it into the edit field where it can be modified.

As soon as the edit field contains a new value – not yet occuring in the value list – the plus button is activated by which the new value can be added to the list of values.

If multiple values are allowed – as it should be e.g. for the property additional drivers – a value may be added to the set of selected values by Strg-Click . The very same action removes the value from the set. The minus button (since opsi-configed version 4.0.2) clears the selection completely.

When the list has been edited the green check mark turns to red as usual in the opsi-configed. Clicking it takes the new selection as new property value (and finishes editing). Clicking the blue cancel button stops editing and resets the original value.

The products on tab Netboot products are mainly used to install the client OS (operating system) and are listed and configured like the products on tab Product configuration.

If for the selected client(s) a netboot product is set to setup, the correspondent bootimage will be loaded and executed at the next client reboot.

Figure 32. opsi-configed: mask to start the bootimage

This is usually done to initiate an OS installation or any other bootimage task (like a memory test etc.)

With this tab you get the last detected hardware information for this client (only available if a single client is selected).

Figure 33. opsi-configed: Hardware information for the selected client

Automatic driver upload

The two offered byAudit driver paths are composed of the manufacturer and the product or the model, which are respectively read from the computer and the mainboard. By clicking the right button to upload a driver, a new window will be displayed to add more settings.

Figure 34. opsi-configed: Hardware information - driver upload

If you open the opsi-configed on a Linux system, it is not directly possible to carry out a driver upload because the connection is carried out via a Share. This needs to be made manually. However, the methods or directory structures are an essential aspect of the drivers integration for linux users as well as for windows users.

Without further settings, the driver upload of a Windows computer, works only if the connection to the Share is enabled.

Among other things, information must be given in a new window, like to which Windows product should the driver be prepared, which drivers are to be uploaded and with which method or the directory in which the driver integration takes place. The target directory is accordingly changed with the selection of another method. The previously selected byAudit driver path can be found again by default in the selected method byAudit, that specifically integrates the selected driver for the type of machine.

Following methods and directories are possible:

• standard: For the drivers which are found in ./drivers/drivers/, the driver will be matched to the corresponding hardware using the PCI IDs (i.e. USB- or HD_Audio-ID) in the description file, and then integrated into the Windows setup as needed. It may be the case that the drivers found by opsi in this location do not necessarily work with your hardware. For the drivers which are found in ./drivers/drivers/, the driver will be matched to the corresponding hardware using the PCI IDs (i.e. USB- or HD_Audio-ID) in the description file, and then integrated into the Windows setup as needed. This is the fallback directory for all clients.
• preferred: In the case that you have to support special hardware, and you can find the additional drivers from the manufacturers, then use the following procedure to include them in the installation. Place the additional drivers in their own directory under: ./drivers/drivers/preferred (the naming and depth of the directory structure is not important). Drivers that are found in the directory ./drivers/drivers/preferred will be integrated into the Windows setup, assuming that opsi finds a suitable match to the drive hardware based off of the PCI IDs (i.e. USB or HD_Audo-ID) in the description file. Problems can occur when the same PCI ID of the drivers is found in preferred. In this case, a direct mapping of the drivers to the devices is needed.
• excluded: It could be that manufacturers include different drivers for different operating systems (i.e. Vista vs. Win7) or different configurations (ie. SATA vs. SATA RAID). The create_driver_links.py cannot make this distinction. If you think the wrong driver has been installed, then move the driver to the drivers/exclude directory and then call create_driver_links.py again. Drivers in the directory drivers/exclude are not used during the integration.
• additional: When installing additional drivers based on the PCI-IDs or USB-IDs, they should be installed under the directory ./drivers/drivers/additional (where name and depth of the directory structure is not important). You can map one or more drivers to a client using the Product-Property additional_drivers and a list of driver directories under ./drivers/drivers/additional. The directories specified by additional_drivers are searched recursively until all drivers are found. This method can be used to make a specific directory based on the client type (i.e. dell-optiplex-815).
• byAudit: The previously described mechanisms that directly map drivers to devices is automated since the 4.0.2 Release 2 of opsi. Opsi will search the directory ./drivers/drivers/additional/byAudit for a director name that matches the field Vendor that was given in the Hardware Inventory. This Vendor directory will be search for a Model directory that corresponds to what is seen in Hardware Inventory. If this directory is found, then it will be manually assigned to the product property additional_drivers. The directory name byAudit is case sensitive. The directory names for Vendor and Model are not case sensitive (Dell and dELL are treated the same way).

Some manufacturers use model names that are very adverse to this method, since some special characters such as / are not allowed to be used in file or directory names. An example for a model name could be: "5000/6000/7000". A directory with this name is not allowed because of the special characters. Since the third Service Release from opsi 4.0.3 the following special characters: < > ? " : | \ / * were replaced internally with an underscore "_" character. With this change can the above example be replaced with: "5000_6000_7000" the directory will automatically be shown, even though the directory structure information in the hardware inventory are not visually the same.

Important

After the driver upload please execute create_driver_links in the opsi-depot-server.

With this tab you get the last known software information for this client (only available if a single client is selected).

Figure 35. opsi-configed: Software information for the selected client

The client specific log files are stored on the server and visible with the opsi-configed via the Tab log files.

The level up to which the log lines are seen can be chosen by a slider (wheel mouse enabled), so that errors can be easily found.

It’s also possible to search in the log file (to continue the search press F3 or n).

Figure 36. opsi-configed: Display of the log file in the opsi-configed

To change the default values of the products for one or more opsi-depots, there is a tab, called Product default-properties. This is only available if you select Properties of depots (which is the second button at the top right hand side).
In the main table, all products are listed with the product version as well as the package version.

If a product is selected, at the top of the right side (as is customary for the client product configuration) general information about the product packets is shown. Below is the list of all depots, that have installed the selected product. The table below with the property keys and values is also known from the client product configuration.

Figure 37. opsi-configed: product default properties

You can select a single depot or multiple depots to change the default values (which are also called the depot values) of the product. As the default, all available depots are preselected. With the usual shortcuts (Ctrl-a, Ctrl-Click or Shift-Klick) multiple or all clients can be selected.
If the property value is shown greyed (see Figure 37, “opsi-configed: product default properties” - “gui_language”), the values for that property differ on the selected depots. On the right side of the depots are three buttons:

There are many configuration options for the opsi server and the opsi clients that may be set or changed via the tab Host parameters. Server defaults are set in the mode server configuration, client specific values in the mode client configuration plus manual selection of the Host parameters tab (see also the section called “opsi-configed modes Client configuration / server configuration / license management”).

On principle, these configuration entries (config objects of the opsi-server) are conceived as lists of values. Therefore they are edited via the list editor tool (cf. the section called “Property tables with list editor windows”).

Depending on the specific definition of a configuration object

New configuration entries of types unicode (extendible) and boolean (fixed) may be created via the context menu. It offers also the option to remove existing entries.

The relationship of server and client entries is complicated.

Starting with opsi-configed version 4.0.3, the configurations objects are categorized in some (predefined) groups. The groups are listed in a tree-like manner on the left part of the panel. The entry name/value pairs belonging to the selected group are shown in the right part of the panel. Wheel mouse scrolling is enabled as well on the left as on the right side.

Figure 38. opsi-configed: Tab Host parameters (Server- and Client configuration)

In the mode Properties of depots you will see the tab Depots. There is a drop down menu to select the depot. After selecting the depot you may change the properties of the opsi-depot.

see also:

Figure 39. opsi-configed: Tab Depot configuration

The button "group actions" in the main button bar (cf. the section called “opsi-configed modes Client configuration / server configuration / license management”) opens a window for group related functions.

At the moment, it provides only one function which is relevant for the opsi-localimage module.

Figure 40. opsi-configed: Group actions (for opsi-local-image)

The button "product actions" in the main button bar (cf. the section called “opsi-configed modes Client configuration / server configuration / license management”) opens a window for functions related to products resp. packages.

Currently it offers two options:

Figure 41. opsi-configed: packet and product actions

Repositories are the sources which will be used by the opsi-product-update to fetch new opsi packages

There are two kinds of repostories:

Internet Repositories

Example: download.uib.de
This are repositories which are configured by:

You may also configure a proxy here.

opsi-server

This is (using a opsi-depot-server) the central opsi-config-server will be used to fetch the opsi-packages.

The central configuration item is here:

This in most cases on a a opsi-depot-server the central opsi-config-server. So on any call of the opsi-product-updater the opsi-product-packages wil be fechted from the opsi-config-server. This can be done for example by a cronjob.

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

In addition it is possible to send all these clients a Wake-On-LAN signal to install the new software to the clients. Using the opsi-product shutdownwanted you can make shure that the clients will be powered off after the installation.

opsi V3 introduced an opsi owned python library which provides an API for opsi configuration. The opsiconfd provides this API as a web service, whereas opsi-admin is the command line interface for this API.

Calling https://<opsi-server>:4447/interface in your browser gives you agraphical interface to the opsi web service. You have to login as a member of the unix group opsiadmin.

Figure 42. opsi config interface: Access to the web service via browser

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

The help option opsi-admin --help shows a list of available command line options:

# opsi-admin --help

Verwendung: opsi-admin [options] [command] [args...]
Optionen:
  -h, --help           Diesen Hilfetext anzeigen
  -V, --version        Versionsnummer ausgeben und beenden
  -u, --username       Benutzername (standard: momentaner Benutzer)
  -p, --password       Passwort (standard: Passwort interaktiv abfragen)
  -a, --address        URL des opsiconfd (standard: https://localhost:4447/rpc)
  -d, --direct         opsiconfd umgehen
      --no-depot       Depotserver-Backend nicht verwenden
  -l, --loglevel       Log-Level (standard: 3)
                       0=nichts, 1=essenziell, 2=kritisch, 3=Fehler, 4=Warnungen
                       5=Hinweise, 6=Informationen, 7=debug, 8=debug2, 9=vertraulich
  -f, --log-file       Pfad zur Log-Datei
  -i, --interactive    Im interaktiven Modus starten
  -c, --colorize       Farbige Ausgabe
  -S, --simple-output  Einfache Ausgabe (nur für Skalare und Listen)
  -s, --shell-output   Shell-Ausgabe
  -r, --raw-output     Rohdaten-Ausgabe

opsi-admin can use the opsi web service or directly operate on the data backend. To work with the web service you have to provide the URL and also an username and password. Due to security reasons you probably wouldn’t like to do this from within a script. In that case you’d prefer direct access to the data base using the -d option: opsi-admin -d.

In interactive mode (start with opsi-admin -d or opsi-admin -d -i -c or short opsi-admin -dic) you get input support with the TAB-key. After some input, with the TAB-button you get a list or details of the data type of the next expected input.

The option -s or -S generates an output format which can be easily parsed by scripts.

There are some methods which are directly based on API-requests, and there are some tasks, which are a collection of function calls to do a more complex special job.

Using the web address https://<opsi-server>:4447/info you will get a graphical chart of opsiconfd load and cpu/memory usage in the last hour/day/month/year. This information is completed by tabulary information to the actual tasks and sessions.

Figure 43. opsiconfd info: opsiconfd values from the last hour

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

In opsi 4 the data structure of all backends and the web service methods are completely new designed.

The new design is object / database oriented. 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 product 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 ćan be used to work with this obect. 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 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 like to not ask for attributes but want to use the second parameter filter you have to give as attribute parameter [].

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 you will get only the object(s) which describe the product javavm.

If you are using methods which expecting one ore more objects, these objects have to be given as JSON objects or as 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:

According to these facts we get a increased stability and performance.

In case of automatic OS-Installation with opsi (not image based), the opsi-client-agent will be installed automatically.

You may set the action request uninstall to uninstall the opsi-client-agent.

For a subsequent installation on an existing Windows system or for repair purposes see the getting started manual. Section 7.6, “Subsequent installation of the opsi-client-agents”.

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

The opsiclientd has the following tasks:

The opsiclientd notifier implements the interaction with the user. It displays status messages and may give the possibility to interact with the process.

There are different situations where the opsiclientd notifier will become active in different ways:

Figure 46. opsiclientd blocklogin notifier

Figure 47. opsiclientd event notifier

Figure 48. opsiclientd action notifier

Figure 49. opsiclientd shutdown notifier

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) 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 50. simplified work flow of a standard event

The most important parameters have the following relations:

(the section called “opsiclientd infopage”).

Figure 51. Complete work flow of an event

The opsiclientd logs to:
c:\tmp\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.

There are the following log levels:

# 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

Example:

(...)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'sync_completed{cache_ready}' added to event generator 'sync_completed'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'gui_startup' added to event generator 'gui_startup'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'gui_startup{cache_ready}' added to event generator 'gui_startup'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'on_demand' added to event generator 'on_demand'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'sync_completed{cache_ready_user_logged_in}' added to event generator 'sync_completed'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'gui_startup{user_logged_in}' added to event generator 'gui_startup'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'sync_completed' added to event generator 'sync_completed'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'software_on_demand' added to event generator 'software_on_demand'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Event config 'on_demand{user_logged_in}' added to event generator 'on_demand'   (Events.pyo|1107)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] Updating config file: 'C:\Program Files (x86)\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf'   (Config.pyo|287)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] No need to write config file 'C:\Program Files (x86)\opsi.org\opsi-client-agent\opsiclientd\opsiclientd.conf', config file is up to date   (Config.pyo|318)
[5] [Mar 22 10:17:46] [ event processing gui_startup  ] No product action requests set   (EventProcessing.pyo|591)
[5] [Mar 22 10:17:49] [ event processing gui_startup  ] Writing log to service   (EventProcessing.pyo|247)
[6] [Mar 22 10:17:49] [ opsiclientd                   ] shutdownRequested: 0   (Windows.pyo|340)
[6] [Mar 22 10:17:49] [ opsiclientd                   ] rebootRequested: 0   (Windows.pyo|326)
[5] [Mar 22 10:17:49] [ opsiclientd                   ] Block login now set to 'False'   (Opsiclientd.pyo|111)
[6] [Mar 22 10:17:49] [ opsiclientd                   ] Terminating block login notifier app (pid 1620)   (Opsiclientd.pyo|148)
[6] [Mar 22 10:17:49] [ event processing gui_startup  ] Stopping notification server   (EventProcessing.pyo|225)
[6] [Mar 22 10:17:51] [ control server                ] client connection lost   (Message.pyo|464)
[6] [Mar 22 10:17:52] [ event processing gui_startup  ] Notification server stopped   (Message.pyo|651)
[5] [Mar 22 10:17:52] [ event processing gui_startup  ] ============= EventProcessingThread for event 'gui_startup' ended =============   (EventProcessing.pyo|1172)
[5] [Mar 22 10:17:52] [ opsiclientd                   ] Done processing event '<ocdlib.Events.GUIStartupEvent object at 0x023CE330>'   (Opsiclientd.pyo|405)
[5] [Mar 22 10:19:41] [ opsiclientd                   ] Session 'HSzMB1wtOiBS6vHl7mh3ro5r6s3TanFu' from ip '127.0.0.1', application 'opsi jsonrpc module version 4.0.1' expired after 120 seconds   (Session.pyo|184)
[6] [Mar 22 10:19:41] [ opsiclientd                   ] Session timer <_Timer(Thread-20, started daemon 2636)> canceled   (Session.pyo|120)
[5] [Mar 22 10:19:41] [ opsiclientd                   ] Session 'HSzMB1wtOiBS6vHl7mh3ro5r6s3TanFu' from ip '127.0.0.1', application 'opsi jsonrpc module version 4.0.1' deleted   (Session.pyo|207)
[6] [Mar 22 10:27:55] [ control pipe                  ] Creating pipe \\.\pipe\opsiclientd   (ControlPipe.pyo|253)
[5] [Mar 22 10:27:55] [ event generator wait_for_gui  ] -----> Executing: getBlockLogin()   (JsonRpc.pyo|123)
[5] [Mar 22 10:27:55] [ opsiclientd                   ] rpc getBlockLogin: blockLogin is 'False'   (ControlPipe.pyo|428)
[6] [Mar 22 10:27:55] [ event generator wait_for_gui  ] Got result   (JsonRpc.pyo|131)
'

The opsi-login-blocker logging to the log file: c:\tmp\opsi_loginblocker.log.

According to the fact that there are a lot of subcomponents of the opsiclientd which work and log at the same time, the log file of the opsiclientd becomes complex.

In order to make it easier to understand how the different subcomponents work together, the opsiclientd has an own info page which visualizes the running tasks on a timeline.
You may view this info page at the browser calling the url:
https://<address-of-the-client>:4441/info.html

Figure 54. Info page of the opsiclientd after push installation with activated product caching

The opsiclientd has its own web service interface which can be used to transmit commands to the opsiclientd. The possible commands can be divided in the following categories:

This can be done on the command line using the tool opsi-admin by calling one of the hostControl_* methods. Calling one of these methods takes the parameter *hostid which:

If a client isn’t reachable (e.g. powerd off) you will get a message.

opsi-admin -d method hostControl_showPopup message *hostid

opsi-admin -d method hostControl_showPopup "This is my message" "myclient.uib.local"

opsi-admin -d method hostControl_fireEvent event *hostIds

opsi-admin -d method hostControl_fireEvent "on_demand" "myclient.uib.local"

Additional maintenance tasks (shutdown, reboot,…..)

Using the control server port you may remote control the opsiclientd. In order to do this you have to authenticate yourself at the web service. This could be done either with the local administrator account (with a not empty password) or with the opsi-host-Id (FQDN, client name and DNS Domain name) as user name and the opsi-hostkey as password.

Using the opsi-configed you may choose the menu opsiClient or the context menu in the Clients Tab.

Figure 55. Web service of the opsiclientd

At the command line you also can initiate a client:

shutdown:

opsi-admin -d method hostControl_shutdown *hostIds

reboot:

opsi-admin -d method hostControl_reboot *hostIds

The files to be configured for opsi-winst are to be found in the directory /var/lib/opsi/depot/opsi-client-agent/files/opsi/opsi-winst/winstskin:

In the directory /var/lib/opsi/depot/opsi-client-agent/files/opsi/dist/notifier are the files to configure the look of the notifiers. Each notifier has an image and a configuration file:

(available since opsi-client-agent version 4.0.2.3)

The custom directory can be used to protect your configuration changes during opsi-client-agent updates: (/var/lib/opsi/depot/opsi-client-agent/files/opsi/custom). During server updates of opsi-client-agent the whole custom directory will be saved and restored after the update, so that your custom changes will persist.

The opsi-login-blocker is implemented as the Gina opsigina.dll. Gina means Graphical Identification and Authentication and is the official Microsoft hook to manipulate the login process.

If you already have a special Gina-DLL installed, which is different from the original Microsoft msgina.dll (e.g. Novell nwgina.dll), you should not install the opsi-login-blocker without consulting uib or https://forum.opsi.org. It is possible to chain different gina.dll’s, but therefore the installation has to be customized. Proper chaining of Gina DLLs is a quite critical task and might result in a locked up computer if done improperly.

Whether the opsi-login-blocker is installed or not is configured by the switch LoginBlockerStart=on/off in section [opsi-client-agent-install] of the client configuration.

The opsi-login-blocker at Vista is implemented as a credential provider filter. It blocks all credential providers until the release by the opsiclientd or timeout.

In order to install the opsi-client-agent from a prepared (sysprep) masterimage, the opsi-client-agent has to be (re)installed while the clone awakes and get a new personality.

To do this use the following steps:

If you like you may pack the temporary directory to a self extracting exe with final program start using a tool like filzip.

The opsi-client-agent packet contains the installation and update mechanism of the opsi-client-agent.

The opsi-winst packet is a special case. It includes the actual opsi-winst winst32.exe, which is updated by the opsi-client-agent packet itself. The opsi-client-agent checks the server for there is a different version of the winst32.exe and then copies the new opsi-winst (all it’s files) to the client. This automatic update do no more work for Windows 2000 since opsi 4.

he product javavm installs the required Java 1.6 runtime environment (required for opsi-configed) on the clients.

The product opsi-adminutils offers some utilities and a local installation of the opsi-configed.

Java based editor with syntax highlighting for opsi-winst scripts

The products hwaudit and swaudit provide the hardware and software inventories. The hardware data are acquired using WMI and written to the hardware inventory via opsi web service. The data for the software inventory are taken from the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall) and passed to the inventory server via opsi web service.

Template for you own opsi scripts.

You may extract this template with:

`opsi-package-manager -x opsi-template_<version>.opsi`

it is also possible to rename it at the same time:

`opsi-package-manager -x opsi-template_<version>.opsi --new-product-id myprod`

Package for customizing the GUI and Explorer settings (not only) for XP.

Using this algorithm, the product installation sequence at first will be calculated by the product priorities. In a second step it will be resorted to met the product dependencies. This algorithm may push products with low priority before products with higher priority to met the needs of product dependencies. But therefore you will not see installation problems as result of not resolved product dependencies.

The base philosophy of this algorithm is, that in practice there are three needed priority classes:

Product dependicies will only resolved inside of priority class. This guarantees that products with a high priority will be installed very early. But is in your reponsibility that there are non product dependencies which go cross priority class borders.

Product priorities and dependencies belong to the meta data of a product. You will be asked for these meta data creating a new product using the command opsi-newprod.

These meta data will be stored in the product control file and may be edited there. After changing the control file you have create and install the package again.

For more details see at getting started manual in the chapter creating a opsi-package.

Using CD-Boot: * The client boots the boot image from the opsi-client-bootcd. *The boot image starts and asks for confirmation to proceed with the re-installation. This is the only interactive question. After confirming this, the installation proceeds without any further request for interaction. * The boot image partitions and formats the hard disk. * The boot image copies the required installation files and configuration information from the opsi-server to the client and initiates a reboot. * After the reboot the client installs the OS according to the provided configuration information without any interaction. * Next the opsi-client-agent is installed as the opsi installer for automated software distribution. * The automated software distribution then installs all the software packages as defined in the client’s configuration.

The client PC has to be equipped with a bootable network controller. Most recent network controllers provide this functionality (PXE boot), also recent network controllers which are integrated on the PC’s main board. The PXE software, which is stored in the bootprom of the network controller, controls the boot process via network according to the BIOS boot device sequence. Usually the boot sequence has to be set in the BIOS, network-boot has to be the first boot device. If there is no possibility to use PXE you may boot from the opsi-client-bootcd.

The opsi installation package for the OS to be installed needs to be provided on the depot server. In the following we assume Windows XP to be the OS to install.

The PXE firmware gets activated at startup of the PC. Part of the PXE implementation is a DHCP client.

Figure 59. Step 1 during PXE-Boot

At first the PC only knows its hardware Ethernet address (MAC), consisting of six two-digit HEX characters.

The firmware initiates a DHCPDISCOVER broadcast: “I need an IP address, who is my DHCP-Server?“

The DHCP-Server offers an address (DHCPOFFER).

DHCPREQUEST is the response of the client to the server if the IP address is accepted. (This is not an obsolete step as there could be more than one server in the network.)

The server sends a DHCPACK to acknowledge the request. The information is sent to the client again.

You can watch this process on the display, for the PXE-BOOTPROM displays some firmware information and its CLIENT MAC ADDR. The rotating pipe-symbol is displayed during the request. When an offer was made it is replaced by an \ and you get the transmitted information (CLIENT IP, MASK, DHCP IP, GATEWAY IP). A short while later you should get a response like this: My IP ADDRESS SEEMS TO BE …….

This process makes the PC a regular, fully configured member of the network. The next step is to load the boot file (boot image) given in the configuration information.

The boot image is loaded via trivial file transfer protocol (tftp). The displayed message is „LOADING“. tftp is a rather old and simple protocol to transfer files without authentication. In fact, all data available via tftp is available to everyone in the network. Therefore the tftp access is limited to one directory, which is usually /tftpboot. This directory is specified in inetd (internet daemon, /etc/inetd.conf), which will start the tftp daemon tftpd if requested. The start command as noted in inetd.conf is something like
tftpd -p -u tftp -s /tftpboot

The PXE boot-process is multi-stage:

Stage 1 is to load and start the file submitted as part of the address discovery process (usually /tftpboot/linux/pxelinux.0).

The program pxelinux.0 then looks for configuration and boot information in /tftpboot/linux/pxelinux.cfg. It first looks for a PC specific file with a name based on the hardware ethernet address (MAC) of the network controller with a leading 01. The filename for the controller with the hardware ethernet address 00:0C:29:11:6B:D2 would be 01-00-0c-29-11-6b-d2. If the file is not found, pxelinux.0 will start to shorten the filename (starting at the end) to obtain a match. If this process ends without result, the file default will be loaded. This file only contains the instruction to boot from the local hard disk. In this case the PC won’t install anything and will just start the current OS from hard disk.

Figure 60. Step 2 PXE-Boot

To initiate the re-installation of a certain PC, a loadable file is prepared for the program pxelinux.0. In order to do so, the opsipxeconfd creates a PC custom file in /tftpboot/linux/pxelinux.cfg. Part of this file is the command to load the installation boot image. Also this file contains the client key to decrypt the pcpatch password. This file is created as a named pipe and therefore disappears after being read once. More details about this in the chapter on security of file shares.

Based on the information the pxelinux.0 got from the named pipe, the actual bootimage is loaded from the opsi depot server via tftp. The bootimage is based on a linux kernel (/tftpboot/linux/install) within an appropriate initrd file system (/tftpboot/linux/miniroot.gz) and has a size of approximately 65 MB.

Similar to the tftp boot via PXE-bootprom, the installation boot image can be booted from the opsi bootcd.

This might be recommended under the following conditions:

According to different situations, several information has to be provided for the CD boot image by interactive input. The most simple case is to provide no further information. Eventually the clients hostname can be passed by hn=<hostname>. Using the option ASK_CONF=1 several parameters can be queried. Pressing F1 at the CD prompt shows the syntax.

Please read the chapter Create a new client using the opsi-client-bootcd at the opsi-getting-started manual.

The bootimage again performs a dhcp request and configures the network interface according to the perceived information. Afterwards the configuration data for the client will be loaded via opsi web service.

Figure 61. PXE-Boot loaded with bootimage preparing hard disk for operating system installation

It also holds the information on how to partition the hard disk, what file system to use and which operating system to install. Also it provides the encrypted password to connect the file share.

These information will be combined with some information taken from the dhcp response and then be passed to the installation script for further processing.

Then the password for the user pcpatch will be decrypted with the transferred key to mount the installation share and then call the installation script from the mounted share to start the installation of the operating system. What specific operations the script performs depends on the operating system which is to be installed. Below the steps of a Windows XP installation will be described.

Prepare the disc: On the hard disk the bootimage creates a new partition (of size 6 GB), formats it and installs a bootable ntloader kernel.

Copy the installation file: The files required for OS installation and the setup files for the opsi-client-agent (which is the opsi software distribution pack) will be copied from the server file share (e.g. /var/lib/opsi/depot/winxppro/i386) to the local hard disk.

Maintain the configuration informations: Some of the configuration and control files contain replacement characters, which will be patched before starting the actual installation. With a specified script (patcha-script) the placeholders will be replaced with parameters taken from the information packet, which is built from configuration files and the dhcp-response. For example the file unattend.txt, which is the control file for unattended OS Installation, will be patched with specific information like host IP, client IP, client name, workgroup, default gateway etc..

Prepare Reboot: Bootrecords will be installed which will start the Windows setup program at the next reboot. The patched unattend.txt is passed to the setup as the control file for unattended installation.

Reboot: During the previous boot, the named pipe (which is indicating a request for installation) has been removed by reading it once. So the next PXE boot will load the default netboot response, which executes the command hdboot. The local boot loader will be started and the setup for operating system installation starts.

These steps are controlled by an OS specific python script.

The OS installation is based on the Microsoft unattended setup. Part of this is the standard hardware detection. In addition to the possibilities given during an installation from non-OEM or slipstreamed installation media, drivers and patches (i.e. service packs) can be installed during the initial installation, making the separate installation of drivers obsolete.

One feature of the unattended installation is the possibility to initiate additional installations after the main installation is finished. This mechanism is used to install the opsi-client-agent, which implements the automatized software distribution system. An entry in the registry marks the machine as being still in the reinstallation-mode.

The final reboot leads to starting the opsi-client-agent service for software distribution prior to the first user login. Based on the value of the aforementioned registry key the opsi-client-agent switches into reinstallation-mode. Therefore, regarding the configuration status of each software packet, each packet which is marked as action status ”setup” or installation status ”installed” within the configuration of that client will be installed. After all the designated client software has been installed, the reinstallation process is finished and the internal status is switched back from reinstallation-mode to standard-mode. In standard-mode only software packages that are marked as action status ”setup” will be installed.

As mentioned above the information collected from dhcp and opsi-webservice will be used to patch some configuration files as e.g. unattend.txt. The program used for patching is the script /user/local/bin/patcha.

This script replaces patterns like @flagname() in a file with values taken as flagname=value from a control file (default input is /proc/cmdline). In the files that have to be patched, the search and replace pattern must start with @, might have an optional after the flagname and must have one or more trailing .

So by calling patcha <filename> the file <filename> will be patched with information taken from /proc/cmdline.

Calling patcha without any parameters will show all the flagname=value entries from /proc/cmdline.

A different input file (another_cmdline) can be passed to patcha: patcha -f another_cmdline
Without any other parameter patcha will show the information taken from another_cmdline. This input file must have cmdline’syntax, which means to be entries like '<flagname>=<value> separated by space.

patcha -f another_cmdline patchfile
This will patch patchfile with substitutions taken from another_cmdline.

Usage: patcha [-h|-v] [-f <params file>] <patch file>

Fill placeholders in file <patch file>
Options:
-v Show version information and exit
-h Show this help
-f <params file> File containig key value pairs
If option not given key value pairs from kernel cmdline are used

patcha patcht nur einen Tag pro Zeile.

Caveat: patch a patches only the first pattern of each line.

Each pattern will be expanded (or reduced) to the length of the value to be replaced with and then replaced. Trailing chars will not be affected.

Examples:

With the input file try.in

cat try.in
tag1=hallohallohallo1 tag2=t2

and the file patch.me to be patched:

cat patch.me
<#@tag1##########################>
<#@tag2##########################>
<#@tag1#>
<#@tag2#>
<#@tag1*##########################>
<#@tag2*##########################>
<#@tag1*#>
<#@tag2*#>
<#@tag1#><#@tag1#####>
<#@tag2*#######><#@tag1#>

the result will be:

./patcha -f try.in patch.me
cat patch.me
<hallohallohallo1>
<t2>
<hallohallohallo1>
<t2>
<hallohallohallo1>
<t2>
<hallohallohallo1>
<t2>
<hallohallohallo1><#@tag1#####>
<t2><#@tag1#>

The information about the Structure of the unattended installation products you will find in the opsi-getting-started manual.

The information about the Simplified driver integration with symlinks you will find in the opsi-getting-started manual.

At the first contact to a opsi-server, the client will accept the given SSL certificate and store it at C:\opsi.org\opsiclientd\server-certs.
On any subsequent contact, the client creates a random string and uses the public key of the stored certificate to encrypt this string (and the own access parameters). These encrypted data will be sent to the server.
The server uses the private key of its own SSL certificate to decrypt the data and sends the decrypted random string back to the client.
Now the client checks if the correct string was sent back. If not, the communication to the server will be aborted.

You can prevent this way that somebody directs your clients to a wrong server, e.g. by manipulating the DNS. If you setup a new server, you may migrate the SSL certificate from the old to the new server without problems. And you must not deploy any certification authority (CA).

The disadvantage of this method is, that a man-in-the-middle attack is still possible.

This security method checks the communication between client and opsi-config-server.

Using the opsi WAN extension and as clientconfig.depot.protocol webdav, also the communication to the opsi-depot-server is checked.

the section called “Communication Protocol for accessing an opsi-depot”

To activate this check, set at the opsiclientd.conf in the section [global] the option:

verify_server_cert = true

Run the following command at your opsi-config-server to to create this configuration entry for all clients:

opsi-admin -d method config_createBool opsiclientd.global.verify_server_cert "verify_server_cert" false

Now you can activate this using the opsi-configed at the Server configuration or at the Host parameter of seleted clients by chaning the value from false to true.

This variant works just like SSL certificates are checked in your browser.
The given SSL certificate will be accepted, if it is issued for the exact FQDN (commonName) of the server (or if the DNS verifies that this is the FQDN matching the IP address of the server) and the certificate is issued and signed by the uib gmbh.

Is one of these conditions not true, the communication to the server will be aborted.

This method is more secure than the first one. But you will have to buy the certificates from uib gmbh. For prizes and conditions have a look at the prize list of uib gmbh:
http://uib.de/en/opsi_support/index.html

Any profits from selling these certificates will be invested in the maintenance of the opsi security.

To activate this security method, set at the opsiclientd.conf in the section [global] the option:

verify_server_cert_by_ca = true

Run the following command at your opsi-config-server to to create this configuration entry for all clients:

opsi-admin -d method config_createBool opsiclientd.global.verify_server_cert_by_ca "verify_server_cert_by_ca" false

Now you can activate this using the opsi-configed at the Server configuration or at the Host parameter of seleted clients by chaning the value from false to true.

The most important part of opsi is the configuration. You will find it at /etc/opsi.

This part will be backed up by opsi-backup.

The data about the managed clients and the products might be stored in different backends. The most important backends are:

Different backends may be used for different purposes at the same time. So you should have a look at the /etc/opsi/backendManager/dispatch.conf to see which backends you are using.

This part will be backed up by opsi-backup.

At the opsi depot share you will find the installation files of the software to be installed on the clients by opsi. The directories which contain these files (Local boot products and netboot products) are located at /var/lib/opsi/depot.

Older versions of opsi used the directory /opt/pcbin/install for this. If it still is present it may be symlinked against the new location.

Depending on how many operating systems, drivers, software and so on is located here, this part will have a huge extent.

This part will not be backed up by opsi-backup.

So if you like to backup this part, you may use rsnapshot or other backup utilities.

The opsi work bench is the location which is used to create own packages. It is usally located at /home/opsiproducts and exported as the samba share opsi_workbench. Because this directory holds your own work, it should be backed up.

This part will not be backed up by opsi-backup.

So if you like to backup this part, you may use rsnapshot or other backup utilities.

The directory /var/lib/opsi/repository is used to store opsi packages, which are downloaded by the opsi-product-updater or which are installed by the opsi-package-manager when using the -d option.

This part will not be backed up by opsi-backup.

So if you like to backup this part, you may use rsnapshot or other backup utilities.

To create a backup call opsi-backup create.
This command (without any additional options) will create a backup of all configuration data and all used backends. The backup file will be stored at the current directory with an automatically generated name.
To get information about the possible options of create call
opsi-backup create --help

opsi-backup create
opsi-backup create --help
usage: opsi-backup create [-h] [--flush-logs]
                          [--backends {file,mysql,dhcp,auto,all}]
                          [--no-configuration] [-c [{gz,bz2,none}]]
                          [destination]

positional arguments:
  destination           Destination of the generated output file. (optional)

optional arguments:
  -h, --help            show this help message and exit
  --flush-logs          Causes mysql to flush table logs to disk before the
                        backup. (recommended)
  --backends {file,mysql,dhcp,auto,all}
                        Select a backend to backup or 'all' for all backends.
                        Can be given multiple times. (Default: auto)
  --no-configuration    Backup opsi configuration.
  -c [{gz,bz2,none}], --compression [{gz,bz2,none}]
                        Sets the compression format for the archive (Default:
                        bz2)

You may give the target directory or the full path to the backup file as option to opsi-backup create. If the given option is a filename, the backup will be created in this file - existing files will be overwritten. If the given option is a directory, the backup file will be crated in this directory with a generated filename using the pattern: <hostname>_<opsi-version>_<date>_<time>

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

Other create options are:

opsi-backup create --backends=file --backends=mysql
opsi-backup create --backends=all

opsi-backup create --no-configuration

opsi-backup create -c bz2

opsi-backup create --backends=mysql --flush-log

Example

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

opsi-backup has no features to archive the created backup files. So you have to do it by yourself (e.g. using a file backup tool).
If you call opsi-backup with a target directory as option, please keep in mind that every call creates a new full backup file and no older files will be deleted.

The command opsi-backup verify is used to test the internal integrity of the created backup file. Special help for the opsi-backup verify command is available by the command option --help.

Example

opsi-backup verify opsi_backup.tar.bz2
opsi-backup verify --help
usage: opsi-backup verify [-h] file [file ...]

required arguments:
  file        The backup archive to verify.

optional arguments:
  -h, --help  shows this help message and then exits

To restore data from a backup file, use the command opsi-backup restore.

You have to give the path to the backup file as parameter.

The command opsi-backup restore --help gives information about the options for the command restore.

opsi-backup restore --help
usage: opsi-backup restore [-h] [--backends {file,mysql,dhcp,auto,all}]
                           [--configuration] [-f]
                           file

required arguments:
  file                  The backup archive to restore data from.

optional arguments:
  -h, --help            show this help message and exit
  --backends {file,mysql,dhcp,auto,all}
                        Select a backend to restore or 'all' for all backends.
                        Can be given multiple times.
  --configuration       Restore opsi configuration.
  -f, --force           Ignore sanity checks and try to apply anyway. Use
                        with caution! (Default: false)

opsi-backup restore has the following options:

opsi-backup restore --backends=file --backends=mysql opsi_backup.tar.bz2
opsi-backup restore --backends=all opsi_backup.tar.bz2

opsi-backup restore --configuration opsi_backup.tar.bz2

opsi-backup restore -f opsi_backup.tar.bz2

Example

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

Here we show (as an example for similar operations) the additional dialogs you will get in the savedisk expert mode.

Figure 70. Choose the tools (default value recommended)

Figure 71. miscellaneous: unset -c here to suppress interactive questions for automation.

Figure 72. compression method before opsi 4.0.5, which is bootimages ⇐ 20130207 (opsi-clonezilla_2.01-3), select here -z1. With opsi 4.0.5 and above not required anymore.

Figure 73. Check filesystem (den default skip nutzen)

Figure 74. Check the saved image (den default yes nutzen)

Figure 75. Action after cloning (use the default -p true, the reboot is triggered by the opsi bootimage).

The opsi license management module is designed for managing the software licenses for proprietary software installed on opsi clients.

The main features are:

A separate window in the opsi-configed management GUI is used for the license management.
It is available by pressing the button "licenses" at the top right corner of the opsi-configed management GUI. If the license management module is disabled, # then a note will be displayed.(see the entry for "license management" in the main menu under /Help/Modules).

Figure 93. opsi-configed: Menu bar with the button "licenses" (rightmost)

The opsi license management module is a co-financed opsi extension module, which is available to the participants of the cofunding project, who have payed a certain amount of the development costs. The module will be available to the community when all the development costs have been recuperated.

A license pool has to be defined for every type of license. The license pools represent the use cases of licenses, and provide the license keys for installing the licensed software on the clients. The license pool is the central element of the opsi license management. Therefore, the first tab of the opsi-configed license management window is the management license pools tab.

Figure 94. License management: tab "License pools" from the license management window

At the top of the license pools window is a table of available license pools.

The input field description can be edited.

More editing functions are available from the context menu (right mouse button). The most important is: creating a {New license-pool}.

When inserting a new line into the table, a (unique) licensePoolId must be entered, e.g. softprod_pool. Please do not use special characters. When saving the new entry, any capitals will be converted to lower case.

The new licensePoolId cannot be changed after it is saved, because it is used as the master key.

The table at the top of the window contains the available license pools. The context menu provides several functions for managing license pools, especially to insert a {New license-pool}. After any changes to the data in the window, the green check checkmark changes to red and the cancel option is enabled. The changes can be saved by clicking the red checkmark, or changes can be cancelled by clicking the cancel option (also available from the context menu).

The standard method to manage licenses is to include the license, from a single license pool, when installing the software (i.e. using the opsi-product installation software to install Acrobat Writer).

A more complicated situation might occur while installing software that requires licenses from several license pools (i.e. "Designer tools" which installs Adobe Photoshop as well as Acrobat Writer).

In this case, the opsi-product requests licenses from several license pools. At the same time, there might be other opsi-products requesting licenses from the same license pools (e.g. the Acrobat Writer license pool). So the relation between opsi-products and license pools can be ambiguous. This can be avoided by using unambiguous policies when building opsi-products.

The second part of the license pool tab manages the relationship between license pools and productIds (from opsi-products).

All tables in the license management module can have their columns sorted by clicking on the column header. Clicking again inverts the order (ascending or descending).

Sorting can be used to display the connections between opsi-products and license pools. Sorting by opsi-product displays all license pools connected to a certain opsi-product, whereas sorting by license pool shows which opsi-products are connected to a license pool.

The context menu provides an option for inserting a new relationship between opsi-product and license pool. An empty row is inserted on top of the table. Clicking into the field licensePoolId or productId displays a dropdown with the available options.

The third section of the license pools tab displays the Windows software IDs connected to the currently selected license pool (in the first section of the tab).

A Windows software ID is an unique key identifying a software packet as detected by opsi software audit. These software IDs are also used by the opsi software inventory module to identify which software is actually installed on the client.

The assignment of software IDs to the current license pool can be changed by setting or removing the selection (ctrl-click or shift-click). From the context menu the display can be toggled between showing all available software IDs detected by the software audit or just showing the software IDs connected to the current license pool.

Displaying the relationship between Software IDs and license pools is useful for comparing the number of actual software installations (detected by the software audit) with the number of legal installations available from the license pool (tab "Statistics", see below).

Licensing means the actual deployment of a permission to use a software by installing the software on a client. This might (but doesn’t have to) include the use of a special license key (license key).

The software license is the permission to install and use a software as defined by the license contract. Within the opsi database a software license is identified by a softwareLicenseId.

There are several types of software licenses (volume license, OEM license, time limited license etc.) which are the different license models. A software license is based on a license contract (license contract), which is defining and documenting the juristic aspects of the license.

A license option defines the option to use a software license for a selected license pool. Within opsi the license option is defined by a combination of softwareLicenseId and licensePoolId. This includes the actual licenseKey (if required).

Finally the license usage documents the use of a license by assigning the license option to a client. This is the legal and implemented licensing of a software defined by the combination of softwareLicenseId, licensePoolId, the unique client name hostId and (if required) the licenseKey.

After selecting the license pool for the new license option, the next step is to register the license contract the license is based on. The section "Select or enter license contract" (from tab "New license") defaults to a standard contract with ID default. The default setting can be used if the license contract is implied by purchasing the software or the contract is documented some other way. Otherwise the contract can be selected from the table or a new contract can be registered from the context menu. The license contract dataset comes with data fields for partner, conclusion date, notification date and expiration date. The entry field notes can hold some additional notes like the location where the contract document is kept. The unique contract ID (licenseContractId) is for identifiying the license contract in the license management database. When entering a new license contract, a new unique ID is constructed based on the current date and time stamp. This ID can be changed before saving the new data set. When saving the data, the opsi service checks whether the ID is unique. In case it is not, a new ID is generated and cannot be changed any more.

The third part of the Tab "New license" is named "Configure license" and is for registering the license model and license data.

Several types of license models are available:

Each Option is represented by a button. Clicking a button, the form is filled with data for that type of license model.

The license model Standard license means, that this license is valid for a single installation on an arbitrary client. So the license key (if any) is valid for a single installation only.

A Volume license is valid for a certain number n of installations. In this case the optional license key is used for that number of installations. Setting n = 0 means, that the number of installations is unlimited within the same network (campus license).

In case of an OEM license, the license is valid for a dedicated client only. Clients that come with a vendor pre installed operating system often have this type of license for the pre installed OS and software packets.

The Concurrent license means that a certain number of licenses is available for a variable set of clients. Within opsi this situation is handled like an unlimited Volume license. The number of actual installations in use has to be managed by some external license server.

After clicking a button, the automatic generated data include a generated unique ID (derived from date and time stamp). This ID can be changed as desired.

It depends on the type of license model, which of the other fields can or cannot be changed.

The field "Expiration date" defines the expiration date of the license in a technical sense. (This column of the license is for future use).

The "Send" button sends the data to the opsi service to save them permanently to the opsi data base (if they are consistent and no errors occur).

While proceeding this, data records will be generated for the new software license based on the selected software contract and the new license option assigned to that.

The list of available license options at the bottom of the window will be refreshed with the new license option selected. If necessary, the license key can be changed then.

Downgrade option means, that instead of the software purchased, also the preceding version can be installed. For instance installing Windows XP based on a Windows Vista license. In this case, the license key also can be used for an installation, which it wasn’t meant for in the first place.

In the opsi license model this case can be configured like this:

From the tab "New license" the Vista license is to be registered as usual, resulting in a new license option, which is displayed in the list of license options at the bottom of the window. This new license option is based on a new software license identified by softwareLicenseId.

Figure 97. License management: copying the license-ID to the license options from the context menu

This softwareLicenseId is needed for the further configuration steps. You can keep it in mind or copy it with drag&drop. You can as well look for the ID in the "Available license options" list of the "Edit licenses" tab. The context menu supports copying the ID.

The important step now is to connect this softwareLicenseId to an additional license pool.

Therefore a new record has to be registered from the "Available license options" table of the "Edit licenses" tab. The fields of the new record have to be filled with the softwareLicenseId and the ID of the additional license pool (in this case the pool for Windows XP licenses). For installing Windows XP based on this license, an applicable Windows XP license key already in use by another client has to be added.

After saving the new record, there are two different license options based on the same software license! The opsi service counts the use of either of them as an installation deducting from the maximum installation count. So in case of a downgrade license (with maxInstallations = 1), the opsi service delivers a license key for a Vista installation or for a XP installation, but not for both of them.

The opsi service call for requesting a license option and retrieving the license key for doing the installation (as transmitted by a Winst script) is

getAndAssignSoftwareLicenseKey

The parameters to be passed are the client hostID (hostID of the client where the software is to be installed) and the ID of the license pool the license is requested from. Instead of the licensePoolId also an opsi-product ID or a Windows Software ID can be passed, if they are connected to a license pool within the opsi license management.

The use of a license option can be released by calling:

deleteSoftwareLicenseUsage

Again the parameters to be passed are the hostID and alternatively the licensePoolId, productID or Windows Software ID. Calling this service releases the license option and returns it to the pool of available license options.

For the complete documentation of opsi service calls see below.

The opsi-winst provides the client related calls as opsi-winst commands.

A opsi-winst script can make a call to the function DemandLicenseKey to get a license key for installing. The parameters to be passed are:

DemandLicenseKey (poolId [, productId [, windowsSoftwareId]])

The return value is the license key (can be empty) as a string:

set $mykey$ = DemandLicenseKey ("pool_office2007")

The returned license key can be used by other script command for installing the software.

For releasing a license option and license key (as to be used in a opsi-winst deinstallation script) the command FreeLicense is available with the following syntax:

FreeLicense (poolId [, productId [, windowsSoftwareId]])

The boolean function

opsiLicenseManagementEnabled

can be used to check whether the opsi license management is enabled and can be used for scripting:

if opsiLicenseManagementEnabled
        set $mykey$ = DemandLicenseKey ("pool_office2007")
else
        set $mykey$ = IniVar("productkey")

The service calls can be invoked from the command line tool opsi-admin.

Parameters marked with * are optional.

method createLicenseContract(*licenseContractId, *partner, *conclusionDate, *notificationDate, *expirationDate, *notes)

This method registers a new license contract record with the ID licenseContractId. If no licenseContractId is passed, it will be generated automatically. Using the licenseContractId of an existing contract, this contract can be edited.

The parameters partner (co-contractor) and notes are strings and can be filled with any information desired. The parameters conclusionDate (date of conclusion of the contract), notificationDate (date for a reminder) and expirationDate (expiration date of the contract) are passed in the format YYYY-MM-DD (e.g. 2009-05-18).

The method returns the licenseContractId of the contract.

        set $mykey$ = DemandLicenseKey ("pool_office2007")
else
        set $mykey$ = IniVar("productkey")

With the string returning functions

getLastServiceErrorClass

and

getLastServiceErrorMessage

error states can be detected and handled, e.g. if there is no license available:

if getLastServiceErrorClass = "None"
        comment "no error"
endif

Within the opsi config editor, the licenses registered by the opsi service are listed on the tab "Licenses usage":

Figure 98. License management: tab "Licenses usage" from the license management window

From this tab, licenses also can be managed manually. This can be useful, if a licensed software is not integrated into the opsi deployment, but installed manually on just a few clients.

These are the functions for manual license management in detail:

If a software packet is reinstalled, the call to the opsi-winst function DemandLicenseKey will return the same license option and license key as had been used before.

In case this is not favoured, the former license option has to be released by calling the opsi-winst command FreeLicense, or by calling the opsi service call deleteSoftwareLicenseUsage or deleting the license use manually.

So, if not explicitly deleted, the license usages are preserved when reinstalling a client.

For releasing the licenses, they can be deleted from the tab "Licenses usage" or can be deleted by the service call

deleteAllSoftwareLicenseUsages

passing the client host name to delete the license uses from.

If a downgrade option has been configured (see the section called “Example downgrade option”), this appears in the overview and statistics like this:

A single downgrade license results in a license option for at least two different license pools, but only one of them can be requested for an installation. So using a downgrade license option decreases the number of available license options (remaining_opsi) in each of the license pools concerned by that downgrade option by 1. So this looks like a single installation reduces the number of available license options by 2, which, in this case, actually is the fact.