opsi Version 4.0.3 Release Notes

With this feature pack release the official support for Python 2.4 is discontinued. This regards the Python 2.4 distributions: Redhat 5 and Centos 5. The repositories concerned will be closed at the end of March 2013. The final packet versions will be available from the archive of download.uib.de. For opsi installations concerned we recommend to upgrade to the new distribution versions, which still are supported.

The following Linux distribution versions are not supported anymore because of insufficient maintenance by the distributor:

These repositories will be closed at the end of March 2013. For installations based on these distribution versions we strongly recommend an upgrade of the operating system. But before doing so, please check whether your chosen version to upgrade to is supported by opsi.

Usually the client installation of opsi software packets is started when booting the client. So the user has to wait for the installation to finish, before the user logon is granted. So it might be useful to do most of the software installation when the client is going to shut down.

The opsi module for installation on shutdown is providing that feature. Selected clients can be configured to do installation on shutdown.

The opsi module Installation on Shutdown can be used for clients with Windows XP or above. The required components are part of the opsi packet opsi-client-agent. Currently this module is a cofunding project. So it requires a special modules file to unlock this feature. For further details on cofunding projects see Section 12.1.1, “Activating licensed extension modules” and the weblink opsi cofunding projects.

The packet opsi-client-agent must be version 4.0.2.3-2 or above with an opsiclientd version 4.0.75 or above.

Some technical restrictions and constraints are the following cases:

The required components for Installation on Shutdown are part of the current opsi-client-agent packet. For unlocking it, a valid modules file must be purchased and copied to the server.

Then Installation on Shutdown can be configured for suitable clients (see Section 5.2, “Preconditions for Installation on Shutdown”) by setting the opsi-client-agent product property on_shutdown_install=on and setting opsi-client-agent=setup.

This is it. All the rest of the configuration is done by the opsi-client-agent packet during setup.

The Installation on Shutdown is done in addition to the Installation at Startup. Usually this is the best way to ensure that the clients always have the current security updates installed, even if the client was off for a long time (when the user was on holiday for instance). If required, the standard Installation on Startup can be disabled, see Section 5.4.5, “Special Configuration of Installation on Shutdown”. Installations in progress are continued anyway, which is triggered by the precondition installation_pending.

The Windows system during system shutdown does not distinguish shutdown from reboot. The Installation on Shutdown is started in both cases and it is not possible, to distinguish them during the installation process. Also it is not possible to transform a system shutdown into a reboot (or vice versa). So in case of a system shutdown, any further installations are continued at the next system startup.

The following explanations are for understanding the technical design and the interactions of the components in case of special configurations or error states. Usually all of the required configurations are done by the opsi-client-agent packet.

echo Start opsi product installation ...
cd "%ProgramFiles%\opsi.org\opsi-client-agent"
opsiclientd_shutdown_starter.exe on_shutdown

echo Start opsi product installation ...
cd "%ProgramFiles(x86)%\opsi.org\opsi-client-agent"
opsiclientd_shutdown_starter.exe on_shutdown

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Shutdown\0]
"GPO-ID"="LocalGPO"
"SOM-ID"="Local"
"FileSysPath"="C:\\WINDOWS\\System32\\GroupPolicy\\Machine"
"DisplayName"="opsi shutdown install policy"
"GPOName"="opsi shutdown install policy"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Shutdown\0\0]
"Script"="C:\\Programme\\opsi.org\\opsi-client-agent\\on_shutdown\\doinstall32.cmd"
"Parameters"=""
"ExecTime"=hex(b):00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System\Scripts\Shutdown\0]
"GPO-ID"="LocalGPO"
"SOM-ID"="Local"
"FileSysPath"="C:\\WINDOWS\\System32\\GroupPolicy\\Machine"
"DisplayName"="opsi shutdown install policy"
"GPOName"="opsi shutdown install policy"

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System\Scripts\Shutdown\0\0]
"Script"="C:\\Programme\\opsi.org\\opsi-client-agent\\on_shutdown\\doinstall32.cmd"
"Parameters"=""
"ExecTime"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system]
"MaxGPOScriptWait"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Shutdown\0]
"GPO-ID"="LocalGPO"
"SOM-ID"="Local"
"FileSysPath"="C:\\WINDOWS\\System32\\GroupPolicy\\Machine"
"DisplayName"="opsi shutdown install policy"
"GPOName"="opsi shutdown install policy"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Shutdown\0\0]
"Script"="C:\\Programme\\opsi.org\\opsi-client-agent\\on_shutdown\\doinstall32.cmd"
"Parameters"=""
"ExecTime"=hex(b):00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Shutdown\0]
"GPO-ID"="LocalGPO"
"SOM-ID"="Local"
"FileSysPath"="C:\\Windows\\System32\\GroupPolicy\\Machine"
"DisplayName"="opsi shutdown install policy"
"GPOName"="opsi shutdown install policy"
"PSScriptOrder"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Shutdown\0\0]
"Script"="C:\\Program Files (x86)\\opsi.org\\opsi-client-agent\\on_shutdown\\doinstall64.cmd"
"Parameters"=""
"IsPowershell"=dword:00000000
"ExecTime"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system]
"MaxGPOScriptWait"=dword:00000000

[event_gui_startup]
active = True

[event_gui_startup{installation_pending}]
active = True

[event_on_shutdown]
active = False

[event_on_shutdown{installation_pending}]
active = False

[precondition_installation_pending]
installation_pending = true

[event_gui_startup]
active = True

[event_gui_startup{installation_pending}]
active = True

[event_on_shutdown]
active = True

[event_on_shutdown{installation_pending}]
active = False

[precondition_installation_pending]
installation_pending = true

[event_on_shutdown]
active = True.

opsi-admin -d method config_createBool opsiclientd.event_gui_startup.active "gui_startup active" true

opsi-admin -d method configState_create opsiclientd.event_gui_startup.active myclient.domain.de false

doinstall32.cmd started
The current date is: .Tue 02/012/2013
Enter the new date: (mm-dd-yy) Backend connected.
modules: passed first checkpoint.
Modules file signature verified (customer: my company)
Check completed.
Event fired
Task completed.

For using this feature, opsi version 4.0.3. or above is required. Basically the opsi-client-agent version 4.0.3.1 or above is required.

The SilentInstall method offers the ability to install a pre-defined list of products on a client, without the user having to interrupt his work. Unlike the installation by the onDemand-Event (push Installation), the SilentInstall method does not display anything on the user desktop.

All displays are suppressed and are not to be seen on any desktop. Of course this feature bears some risk. In case of a problem, e.g. a syntax error of the opsi-winst script, there is no way to interact with the installation process, for no dialog windows are shown. So this would result in the opsi-winst and so the Event processing not coming to an end, and so no more events will be executed. To avoid this "Worst case scenario", the maximum installation time is limited by a timeout configuration. This timeout value might have to be adapted in case of an extended installation. For further information, see the configuration chapter.

Another very important ability of this feature is the predefined list of products to be installed silently. Contact to the service is established, but different from the usual procedure, the ActionRequests given by the service are ignored. The list of software to be installed is defined by an opsi-client-agent configuration. The "setup" action will be executed for all the products on this list and they do not have to be set to setup. As usual after processing the setup script, also the update script will be executed, if there is one. No product dependencies will be resolved. So either no products containing product dependencies should be installed by the SilentInstall feature, or all the products from the dependency list must be added to the SilentInstall product list. As usual the installation process is completed by sending the installation status and installation logfiles to the service. In summary it is recommended to use the SilentInstall only for products, that meet the following requirements:

Within the default configuration swaudit and hwaudit are installed by this method. The inventory products of opsi meet all the requirements above and so are applicable for this method. With the default configuration the opsi hard- and software inventory are generated on demand, without the need to set the setup action request with the opsi-configed. With this method the inventory information can be generated in real-time operation. Also applicable would be any configuration products, that perform automatic repairs or restore client patches.

This event will not be triggered automatically like other events. So there are two ways to perform this event.

The first way is to trigger the event from the opsi webservice, like e.g.:

opsi-admin -d method hostControl_fireEvent silent_install client.domain.local

So this command is scriptable and can be used within scripts that can be combined with an at-job to plan the execution of the event.

As an alternative the event can be triggered by a timer event after a certain amount of time. The default configuration for this event is 6 hours. This value presumes, that a work station usually is in use for 8 hours. So the event would be executed once a day after six hours of uptime. For mor information on configuring and activating this event see the following configuration chapter.

This chapter is about the default configuration of this feature. The default opsiclientd.conf has got a SilentInstall event. This listing just shows the important options:

Standard Event SilentInstall:

[event_silent_install]
process_shutdown_requests = false
action_processor_productIds = swaudit,hwaudit
action_processor_command = %action_processor.command% /productlist %action_processor_productIds% /silent
action_processor_desktop = winlogon
action_processor_timeout = 300

The second event is the Timer Event, which triggers the event after a certain amount of time:

Default Timer Event for SilentInstall

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

Also the SilentInstall event could be triggered by another system event detected by an WMI request. Therefore a wql option can be specified. How to specify a wql option is to be seen in the event_net_connection section. If the wql option is used, the event should be set to active = false as default, so it can be activated later on when requested.

To trigger the event by a timer, usually it only needs to set a host parameter. Therefore at first a default configuration has to be created. In this case it is sufficient to activate the Timer Event.

To create the standard option the following host parameter are to be created by the opsi-admin. Also this configuration could be created by the opsi-configed:

opsi-admin -d method config_createBool opsiclientd.event_timer_silentinstall.active "event_timer_silentinstall active" false

So at first this event is disabled for all the clients. Then the event can be enabled for single clients:

opsi-admin -d method configState_create opsiclientd.event_timer_silentinstall.active silentclient.domain.de true

To define the products to be installed, the following entry must be set. If for instance instead of swaudit and hwaudit the product firefox shall be installed, the entries should be created as described above:

opsi-admin -d method config_createUnicode opsiclientd.event_silent_install.action_processor_productIds "event_silent_install productIds" "swaudit,hwaudit"

With this option as the default for all clients the product list for the Silent Install Event is set to swaudit and hwaudit. To change the product list for a single client into firefox execute the following command:

opsi-admin -d method configState_create opsiclientd.event_silent_install.action_processor_productIds client.domain.de "firefox"

As you can see, the product list can be different for each client.

Since version 3.6 the opsi-winst GUI can be customized. The elements for customizing are to be found in the winstskin subdirectory of the opsi-winst directory. The configuration file for customization is skin.ini.

Since version 4.11.3.5 the opsi-winst searches the skin directory in the following order (first directory with a skin.ini to be found wins):

With the Command SetSkinDirectory the SkinDirectory to be used can be defined in the script. If the path specified is empty or not valid, the default path will be used.

Example:

SetSkinDirectory "%ScriptPath%\testskin"
sleepseconds 1
SetSkinDirectory ""

SetSkinDirectory "%ScriptPath%\testskin"
sleepseconds 1
SetSkinDirectory ""

(…)

Example:

message "SetConfidential"
SetConfidential "forbidden"
comment "This is a forbidden string"
comment "shown in the should be in the log file: This is a ***(confidential)*** string"

Log:

message SetConfidential
comment: This is a ***(secret)*** string
comment: should be in the log file: This is a ***(confidential)*** string

opsi-winst scripts do not have a special type of variables for numbers. But there are some functions to help calculating with numbers.

Example:

set $ConstTest$ = "0"
set $CompValue$ = calculate("-1+1")
if ($ConstTest$ = $CompValue$)
        comment "passed"
else
        set $TestResult$ = "not o.k."
        LogWarning "failed"
endif
set $ConstTest$ = "1"
set $CompValue$ = calculate("0+1")
if ($ConstTest$ = $CompValue$)
        comment "passed"
else
        set $TestResult$ = "not o.k."
        LogWarning "failed"
endif
set $ConstTest$ = "-1"
set $CompValue$ = calculate("0-1")
if ($ConstTest$ = $CompValue$)
        comment "passed"
else
        set $TestResult$ = "not o.k."
        LogWarning "failed"
endif
set $string1$ = "5"
set $string2$ = "5"
set $ConstTest$ = "25"
set $CompValue$ = calculate($string1$+"*"+$string2$)
if ($ConstTest$ = $CompValue$)
        comment "passed"
else
        set $TestResult$ = "not o.k."
        LogWarning "failed"
endif
set $string1$ = "5"
set $string2$ = "5"
set $ConstTest$ = "1"
set $CompValue$ = calculate($string1$+"/"+$string2$)
if ($ConstTest$ = $CompValue$)
        comment "passed"
else
        set $TestResult$ = "not o.k."
        LogWarning "failed"
endif
set $string1$ = "5"
set $string2$ = "0"
set $ConstTest$ = ""
comment " expecting devision by zero error and empty string result"
set $CompValue$ = calculate($string1$+"/"+$string2$)
if ($ConstTest$ = $CompValue$)
        comment "passed"
else
        set $TestResult$ = "not o.k."
        LogWarning "failed"
endif
set $string1$ = "9"
set $string2$ = "10"
set $ConstTest$ = "1"
comment "result 0.9 is rounded to 1 "
set $CompValue$ = calculate($string1$+"/"+$string2$)
if ($ConstTest$ = $CompValue$)
        comment "passed"
else
        set $TestResult$ = "not o.k."
        LogWarning "failed"
endif
set $string1$ = "10"
set $string2$ = "9"
set $ConstTest$ = "1"
comment "result 1.1111 is rounded to 1 "
set $CompValue$ = calculate($string1$+"/"+$string2$)
if ($ConstTest$ = $CompValue$)
        comment "passed"
else
        set $TestResult$ = "not o.k."
        LogWarning "failed"
endif
set $string1$ = "5"
set $string2$ = "5"
set $ConstTest$ = "55"
comment " rule * before +"
set $CompValue$ = calculate($string1$+"+"+$string2$+"*10")
if ($ConstTest$ = $CompValue$)
        comment "passed"
else
        set $TestResult$ = "not o.k."
        LogWarning "failed"
endif
set $string1$ = "5"
set $string2$ = "5"
set $ConstTest$ = "100"
comment "brackets before  rule * before + "
set $CompValue$ = calculate("("+$string1$+"+"+$string2$+")*10")
if ($ConstTest$ = $CompValue$)
        comment "passed"
else
        set $TestResult$ = "not o.k."
        LogWarning "failed"
endif
set $string1$ = "5"
set $string2$ = "ten"
set $ConstTest$ = ""
comment "invalid char error"
set $CompValue$ = calculate($string1$+"*"+$string2$)
if ($ConstTest$ = $CompValue$)
        comment "passed"
else
        set $TestResult$ = "not o.k."
        LogWarning "failed"
endif
set $string1$ = "5"
set $string2$ = ""
set $ConstTest$ = "25"
comment "5* is interpreted as 5*5"
set $CompValue$ = calculate($string1$+"*")
if ($ConstTest$ = $CompValue$)
        comment "passed"
else
        set $TestResult$ = "not o.k."
        LogWarning "failed"
endif
set $string1$ = "5"
set $string2$ = ""
set $ConstTest$ = "10"
comment "5+ is interpreted as 5+5"
set $CompValue$ = calculate($string1$+"+")
if ($ConstTest$ = $CompValue$)
        comment "passed"
else
        set $TestResult$ = "not o.k."
        LogWarning "failed"
endif
set $string1$ = "nothing"
set $string2$ = "foo"
set $ConstTest$ = ""
comment "invalid char error"
set $CompValue$ = calculate($string1$+"*"+$string2$)
if ($ConstTest$ = $CompValue$)
        comment "passed"
else
        set $TestResult$ = "not o.k."
        LogWarning "failed"
endif
set $string1$ = "5"
set $string2$ = "foo"
set $ConstTest$ = ""
comment "invalid char error"
set $CompValue$ = calculate($string1$+"/"+$string2$)
if ($ConstTest$ = $CompValue$)
        comment "passed"
else
        set $TestResult$ = "not o.k."
        LogWarning "failed"
endif

For more examples refer to the product opsi-winst-test at the section $Flag_calculate$ = "on"

(…)

In a LinkFolder section at first must be defined, in which virtual system folder the subsequent instructions are meant to operate. This expression defines the base folder:
set_basefolder <virtual system folder>

Virtual system folders to be used are:

desktop, sendto, startmenu, startup, programs, desktopdirectory, common_startmenu, common_programs, common_startup, common_desktopdirectory

These folders are virtual, for it depends on the operating system (and version), what the resulting physical directory name is.

In the context of standard machine installations, only the virtual system folders starting with common_ are relevant.

The system folders desktop, sendto, startmenu, startup, programs, desktopdirectory can only be used in the context of a logged on user respectively in a userLoginScript in the context of the opsi extension user Profile Management.

For a better overview the host parameters now are devided into functional groups. The groups are displayed on the left side as a tree. The parameters and values of the selected group are displayed on the right side.

Figure 11.1. opsi-configed: Tab host parameter (server and client configuration)

The level of log entries to be shown can be selected by a slider, so it is easier to find errors. The slider can also be moved using the mouse wheel.

Logs referring to an event can be selected.

Figure 11.2. opsi-configed: Tab Logfiles

Some chapters of the Release Notes are also part of the opsi-manual and refer to other chapters of the opsi-manual. The chapters referred to are: