Deployment Windows clients from a Linux server with Opsi
If an installation fails, Opsi alerts the administrator via the web interface for the package. Additionally, each client generates a detailed log that Opsi stores both centrally on the server and also locally on the client for diagnostics in the case of connection issues.
Optionally, Opsi can pass messages to a Syslog server. When you create a software package, you can also add a custom logfile. In the course of Opsi-controlled Windows installation over the network, logfiles are created on both the server and the client.
In enterprise environments, Opsi supports the use and central configuration of multiplex depot servers for software installation in distributed scenarios. Implementations of this kind seem to be fairly complex, and the manufacturer recommends signing a support agreement before setting up a multiplex depot server.
When Windows boots, the Opsi service calls Winst.exe, which in turn installs the individual packages (Figure 5). An installation-ready Opsi package comprises the executable binaries, some metadata, and an installation script for updating and uninstalling.
Installation control relies on a special, semantically rich scripting language that is documented in a separate installation manual and reference card, along with details of the various installation programs, on the Opsi website . A template supplied with the Opsi distribution is useful for help in getting started, and the wiki , with its collection of sample scripts, helps to explain the concept further.
The scripting language supports all known installation variants (i.e., snapshot, silent, script-based, and simulated keyboard input), which means that the underlying language does not change from program to program. The files have a similar structure to INI files; that is, they are divided into sections.
Opsi distinguishes between a primary section, which controls the basic flow of the script and the run-time behavior of Winst, and multiple secondary sections, which are called by the primary section (for an example, see Listing 1). A secondary section contains instructions, which in turn can reside in external functions or are drawn from external sources, such as programs or included scripts.
Installation Script for TightVNC
01 [Initial] 02 Message=Installing tightvnc 1.2.9 ...... 03 04 [Actions] 05 ; Launch AutoIt as a background process to suppress the window 06 ; that appears when tightvnc is running as a service during the install 07 winbatch_tightvnc_autoit_confirm /LetThemGo 08 ; Start the setup program in silent mode 09 winbatch_tightvnc_silent_install 10 11 [winbatch_tightvnc_autoit_confirm] 12 %SCRIPTPATH%\autoit %SCRIPTPATH%\confirm.aut 13 14 [winbatch_tightvnc_silent_install] 15 %SCRIPTPATH%\tightvnc-1.2.9-setup.exe /silent
Opsi's scripting language includes conditions (if and else), for loops, and string lists to guide the installation, depending on the existence of certain properties. Also, it offers assignable variables, pre-defined functions, and global constants. The constants let you reference system paths, drive letters, operating system versions, environmental variables, and network settings in the script. Opsi automatically discovers the value of global variables at run time.
The code in the secondary section can make various changes to the system, such as copying and deleting files and directories, editing Registry entries, and creating or removing links in the start menu and on the desktop. Also, it is possible to launch external programs via the Windows API, or cmd.exe, and to reboot the target system depending on the file version, operating system, language, free disk space, and other factors.
Administrators can use configurable installation messages and graphics to modify the look of the Opsi service and even modify a system's restart behavior in a script. The Opsi scripting language provides file-patching functions for software configuration and supports INI, hosts, XML, BDE, and Mozilla configuration files, as well as text files.
Custom solutions make sense in some environments; however, you should not underestimate the initial setup effort or the maintenance overhead. Opsi gives you the freedom to decide how much to do yourself and what level of vendor support to rely on. The Opsi alternative also saves you the cost of a Windows server, and you can manage the software on your Windows clients from the stability and security of Linux.
- Windows Packager (WPKG): http://wpkg.org/
- Unattended: http://unattended.sourceforge.net
- Unattended GUI: http://unattended-gui.sourceforge.net
- WPKG wiki: http://wpkg.org/Category:Silent_Installers
- BINL server in Python: http://oss.netfarm.it/guides/pxe.php
- Entry-level article by Microsoft: http://unattended.msfn.org/unattended.xp/view/web/7/
- Prebuilt packages by the Driverpacks project: http://driverpacks.net
- Linux RIS Howto: http://www.promodus.net/linuxris
- Reference for WINNT.SIF: http://unattended.msfn.org/unattended.xp/view/web/19
- Guide to BINL server: http://oss.netfarm.it/guides/ris-linux.pdf
- Opsi: http://www.opsi.org/
- UIB maintenance and support offerings: http://uib.de/en/opsi%20support/index.html
- Opsi community forum: https://forum.opsi.org
- Opsi wiki with ready-to-run scripts: http://www.opsi.org/opsi_wiki/WinstScripts
- Opsi documentation: http://download.uib.de/doku/
Azure CTO says Redmond has already considered the unthinkable.
Lead developer quells rumors that the Debian version is slated for center stage.
MSBuild is now just another GitHub project as Redmond continues its path to the light.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?
.NET Core execution engine is the basis for cross-platform .NET implementations.
The Xnote trojan hides itself on the target system and will launch a variety of attacks on command.