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

If you are running the opsi-configed on a Linux based machine, so make sure that your Java is the Sun Java Version. The often installed OpenJDK or other versions may lead to subtil errors. So you have to install the Sun Java and configure it as the default Java:

update-alternatives –config java

The command

java -version

should lead to the following output:

java version "1.6....
Java(TM) SE Runtime Environment ...

Most times the opsi-configed will be called as applet in the browser via: https://<servername>:4447/configed

The opsi-configed as application is also part of the opsi product opsi-adminutils and may then be started via 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 you in the correct directory, it also can be started with java -jar configed.jar.

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

P:\install\opsi-adminutils>java -jar configed.jar --help
starting configed
default charset is windows-1252
server charset is configured as UTF-8

configed [OPTIONS]...

Options:
     -l, --locale    Set locale (format: <language>_<country>)
     -h, --host      Configuration server to connect to
     -u, --user      Username for authentication
     -p, --password  Password for authentication
     -d, --logdirectory Directory for the log files
         --help      Show this text

Figure 5. 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.

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 views of the opsi-configed, use the buttons in the upper right corner.

Figure 6. opsi-configed: Buttons for (from left to right): Client configuration, Server configuration, License management

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.

Figure 8. 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 9. 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.

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

• 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 11. 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 12. 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.

With the icon Set client group or Grouping / set client group saved groups can be loaded.

Figure 13. opsi-configed: mask: group setting

With the function Set client group you can build client groups by certain criteria (e.g.: all clients which have the product firefox with the installation status installed).

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). This tree view feature is part of a co-funding project and runs only with a valid activation file. A activation costs 500 €. For evaluation please contact info@uib.de. The tree view control has base node ALL with all groups and clients beyond..

Basic concepts

The tree view control has base node ALL with all groups and clients beyond. Ther is a other node Groups which is the bas group for all other self defined groups.

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

There is a additional group REPORTED_FAILURES which contains all clients, which have a action result failed.

Every known client is alwas in the group ALL. Add itionally a client may be in one or more other groups. You may build up different group trees which represent different order critiras like administrative structure, hardware or typical software inventory.

If you select a client, all groups where the selected client belog to get colored marked icons.

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 15. opsi-configed: Using the context menu to create a new subgroup

You will be asked for the new groups name.

Figure 16. 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 17. 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 18. 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 19. opsi-configed: opsi message display dialog

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 20. 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 analogously used in the commands are %ipaddress% and %inventorynumber%.

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 add a requested password or vary the command as needed.

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 21. 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 22. 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.

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 23. 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 24. opsi-configed: product configuration mask

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 25. 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 26. 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 27. 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 28. 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 29. opsi-configed: Hardware informations for the selected client

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

Figure 30. 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.

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

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

There are many configuration options for the opsi server and the opsi clients that may be set or changed via the tab Host parameters. Theryby, 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 “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.

Figure 32. 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 33. opsi-configed: Tab Depot configuration

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 34. 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

Usage: opsi-admin [options] [command] [args...]
Options:
  -h, --help           Display this text
  -V, --version        Display this text
  -u, --username       Username (default: current user)
  -p, --password       Password (default: prompt for password)
  -a, --address        URL of opsiconfd (default: https://localhost:4447/rpc)
  -d, --direct         Do not use opsiconfd
      --no-depot       Do not use depotserver backend
  -l, --loglevel       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

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 35. opsiconfd info: opsiconfd values from the last hour

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

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 6.5, “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 38. opsiclientd blocklogin notifier

Figure 39. opsiclientd event notifier

Figure 40. opsiclientd action notifier

Figure 41. 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 42. simplified work flow of a standard event

The most important parameters have the following relations:

(the section called “opsiclientd infopage”).

Figure 43. 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 46. 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 47. 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 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.

# has to be written #

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 51. 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 52. 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 53. 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. /opt/pcbin/install/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 /opt/pcbin/install or /var/lib/opsi/depot.

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

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

The main features are:

From the opsi-configed a separate window is used for the license management.
It is available by the button "licenses" from the main window of the opsi-configed, provided that the license management module is acivated for the current opsi configuration (see the entry for "license management" from the main menu /Help/Modules).
If the license management is disabled, a note will be displayed.

Figure 58. 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 funded.

For every type of license a license pool has to be defined. 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 license management window of the opsi-configed is dedicated to the management of license pools.

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

In the upper part of the license pools window is a table of available license pools.

The input field description can be edited.

Some more editing functions are available from the context menu. 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 umlauts. When saving the new entry, any capitals will be converted to lower case.

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

The upper part contains the table of available license pools. The context menu provides several functions for managing license pools, especially to insert a new license pool. When editing, the green check mark changes to red and the cancel option is enabled. By clicking the red check mark the changes can be saved, or cancelled by clicking the cancel option (also available from the context menu).

The standard case of license management is an opsi-product installing software, which is subject to a license (e.g. the Acrobat Writer) from a single license pool.

More complicated is the situation with an opsi-product is installing software, which requires licenses from several license pools, like an opsi-product "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).

As it is with all tables of the license management module, clicking on the column header will sort the table content by the column content. 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 62. 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 63. 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.

For transferring the product files, two different protocols are used:

In case of using CIFS/SMB, a connection to the depotRemoteUrl will be established as configured with the properties of the opsi-depot. In case of using HTTP(S)/WEBDAV(S), the depotWebdavUrl is connected, which as well is to be configured with the properties of the opsi-depot.

Which protocol is to be used, can be configured client specific by the host parameter clientconfig.depot.protocol. Available values to be set as clientconfig.depot.protocol are cifs and webdav.

The synchronization process is based on the file <product-id>.files, which is located in the base directory of each opsi-product on the opsi-depot. This file contains information about the files, directories ans symbolic links used by an opsi-product. Each line of that file contains such information. Different types of information are separated by a blank.
The first character of a line defines the type of the following entry. Available values are:

Separated by a blank follows the relative path, which is single quoted.
The next entry gives the sizes of the file (which is 0 for directories and symbolic links).
The final entry in case of a file is the MD5-sum of the file, in case of a symbolic link it is the target referred to by the symbolic link.

Example excerpt of a .files file:

d 'utils' 0
f 'utils/patch_config_file.py' 2506 d3007628addf6d9f688eb4c2e219dc18
l 'utils/link_to_patch_config_file.py' 0 '/utils/patch_config_file.py'

The .files file is generated automatically when installing opsi-product-packages (after running the postinst-Script).

The synchronization of a local copy of an opsi-product processes as follows:

The synchronization results in an exact local copy of the opsi-product from the opsi-depot.

When the opsi-product has completed successfully,

The opsi-product caching is configured in the section [cache_service] of the opsiclientd.conf.

Further configurations can be done event specific.
Within an event configuration section [event_<event-config-id>] the following options are available:

The local client-cache-backend is based on SQLite and mainly consists of a local working copy, a snapshot an a modification tracker, which records all changes of the local working copy.
The base directory of the config cache can be configured and defaults to %SystemDrive%\opsi.org\cache\config. The snapshot reflects the configuration status on the opsi-config-server at the time of the last synchronization.
At the start of the processing, the local working copy is a copy of the snapshot, but will be modified during processing.

The synchronization of the local changes of the client-cache-backend with the config backend of the opsi-config-server is processed as follows:

The config backend replication of the opsi-config-server to the client-cache-backend is processed as follows:

A successful replication from server to client results in:

The configuration of the config caching is mainly done event specific:
Within an event configuration section [event_<event-config-id>], the following options are available:

The caching of opsi-products can be done via the protocols HTTPS/WEBDAVS or CIFS/SMB.

When using webdav, access to the opsi-depot is performed by the opsiconfd.

By using cifs, access to the opsi-depot is done via SAMBA.

An instruction for configuring the protocols is to be found in the chapter the section called “Communication Protocol for accessing an opsi-depot”.

Figure 66. processing of an installation with WAN extension as displayed in the opsiclientd infopage

To activate the verifying of SSL certificates, in the opsiclientd.conf within the section [global], the option verify_server_cert is to be set to true. This, during connection to an opsiconfd, results in verifying the opsi-server by using the SSL certificate. The server certificates will be stored in the directory %SystemDrive%\opsi.org\opsiclientd\server-certs. The name of the certificate is combined from the server address (IP or name) and the extension .pem. If at connection time no stored certificate is to be found, no checking will be done.

The most comfortable way to create and manage product-groups is using the opsi-configed. There you have to change to the tab product configuration.

The product-group menu is above the product list.

Figure 73. product-group menue

With the drop down menu you can choose a product-group to edit it. If you have chosen a group, the corresponding products will be highlighted.
With a second icon, filter can be activated or deactivated. When a filter was activated, only the products of the activated product-group are seen.
Product-groups can be edited after activating the icon with the yellow packets (show editor / hide editor) next to the icon with the filter. In this view, a new group and it’s description can be added. Save the editing by activating the red check icon.
If some more products should be added to a group, select them and press the red check icon. (Press the <ctrl> button and select the products).

The module can be configured, as mentioned above, with the config-variables described in the following table:

There are two ways to use these configuration objects. For the whole system or for each client. The following 2 chapters will explain both ways.

Configuration for the whole system

The configuration here is the default system wide for every client. The configuration can be edited in the opsi-configed. Push the Button Server Configuration and change to the tab Host Parameter

Figure 74. part of the module server configuration in the opsi configuration editor

Another possibility is to change the server-configuration with the following command:

opsi-setup --edit-config-defaults

Figure 75. edit-config-defaults with opsi-setup

Tip

Administration is also possible with the opsi-python-API or with opsi-admin

Configuration for a single client

The configuration for a single client - or client specific configuration - is useful if, for example, only some of the clients should have access to the Software-on-Demand extension. Or if you want to make several product groups available to some clients.

The configuration of the client specific host parameters can be edited in different ways:

The most comfortable way to edit the configuration is via opsi-configed. Choose one or several clients (even all clients of a client group if you want to) and then navigate to the tab "Host parameters".

Figure 76. edit hostparameter in the configuration editor

This editing overrides the system wide defaults.

There are two ways for the users to start the software-installation:

If the user chooses "with the next system start", the product state will be set to "setup." If the choice is "immediately", the opsiclientd creates an event software on demand. This event can be configured in the file opsiclientd.conf as any other event.

The look of the software-on-demand module can be customized to the companies corporate identity. Therefore the file opsiclientd.css has to be customized. It lies under:
c:\program files\opsi.org\opsi-client-agent\opsiclientd\static_html

It can be edited and then reloaded. The changes have to be copied to the server to remain with new opsi-client-agent installations. Copy the CSS-file and perhaps a file with the companies logo to the server directory:
/opt/pcbin/install/opsi-client-agent/files/opsi/dist/opsiclientd/static_html

To avoid errors, we recommend to set rights after changing the configuration.

opsi-setup --set-rights /opt/pcbin/install/opsi-client-agent

Inventory data at the file backend is stored in structured text files by default. This type of storage is not very useful if you wish to form free queries on these data. In order to allow free queries and reports a mysql based backend for the inventory data has been introduced.

The main characteristics of this backend are: * only for inventory data free (for other data it is part of a co funding project until now) * optional (not the default backend) * a very fine granulated data structure with an additional table to make queries easier. * a history function which tracks changes in the inventory.

Regarding the very different structure of the components in the inventory the resulting data structure is complex.

The table hosts comprises all known hosts. For every device type we use two tables: The HARDWARE_DEVICE_ .table describes the model without individual aspects like the serial number. The HARDWARE_CONFIG table stores these individual and configuration data.

These both tables are connected via the field hardware_id. This is the resulting 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

Which field name in the database is corresponding to which reported and localized name in the opsi management interface is defined in a configuration file. Example (/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.systemType = Type
COMPUTER_SYSTEM.totalPhysicalMemory = Physical Memory
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
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 for queries: Listing of all hard drives:

SELECT * FROM HARDWARE_DEVICE_HARDDISK_DRIVE D
LEFT OUTER JOIN HARDWARE_CONFIG_HARDDISK_DRIVE H ON D.hardware_id=H.hardware_id ;

The software inventory uses as primary keys the following entries:

At the table Software_config these primary keys are integrated to one key: config_id.

Figure 81. data base schema: software inventory

The mysql backend for configuration data is available since opsi 4.0 and is published as co funding project.

The mysql backend has a high performance which is important for large installations.

Here a data structure overview:

Figure 82. data base schema: configuration data

First, the mysql-server has to be installed (if not done yet):

apt-get install mysql-server

In the next step the administrative password for the mysql-server has to been set:

mysqladmin --user=root password linux123

The command

opsi-setup --configure-mysql

will now initialize the mysql backend.

A example session:

Figure 83. Dialog: opsi-setup --configure-mysql

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

At all questions (beside the password) you may accept the defaults by pressing ENTER.

As next step you have to configure how (for which methods) opsi should use which backend. Therefore please edit the file /etc/opsi/backendManager/dispatch.conf .

A detailed description for this configuration you will find at the getting started manual. The configuration file also contains a lot of examples of typical configurations.

A configuration for the use of the mysql backend (without internal dhcpd) looks like that:

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

Finally you have to activate the changed configuration with the following commands:

opsi-setup --init-current-config
opsi-setup --set-rights
/etc/init.d/opsiconfd restart
/etc/init.d/opsipxeconfd restart

# has to be written #

The hosts file stores all IP addresses and IP names known to the network. The IP addresses and names of all clients have to be entered here. There might be aliases (additional names) and comments (starting with #).

opsi needs full qualified host name (including the domain name) and this might come from the /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

With the following command you may test the name is resolved:

getent hosts $(hostname -f)

The result should be similar to:

192.168.1.1 server.domain.tld server

If the result isn’t like that and contains for example 127.0.0.1 or localhost you should correct your /etc/hosts or your DNS before you continue with the installation.

The required opsi groups are pcpatch and opsidamin. All users who are administrating opsi packets need to be member of the pcpatch group. Membership of the group opsiadmin allows users to connect to the opsi web service (for instance using the opsi-configed).