ReleaseEngineering/OPSI

From MozillaWiki
Jump to navigation Jump to search

Definitions

  • OPSI Server - Serves opsi packages, instructs clients on which packages to install, remove, etc. This is a Linux machine (debian currently).
  • OPSI Client - Runs on win32 machines. Runs right before the login prompt at boot and audits the system to make sure the packages are in the proper state. This is when new installations happen.
  • OPSI Package - Contains to-be-installed files as well as installation instructions. Sources for these package are to be kept in version control. Packages themselves are kept on the OPSI Server.
  • OPSI Config Editor - This is a Java app that is used to manage what is installed on which machines. It lets you schedule installations of packages, and see what is currently installed. (Other things too, but not all packages support them.) You can download it here.
    • If you are on OS X and can't start OPSI.jar, launch 'Java Preferences' and change Java 6 64-bit to be the top of the list of runtimes for applications

Install OPSI on a client

Enable File and Print Sharing

  • Enable File & Print Sharing
    • Control Panel -> Network Connections -> Local Area Connection -> Properties
    • Enable "Client for Microsoft Networks" and "File and Print Sharing", click Close.
  • Open firewall (only to opsi server)
    • Control Panel -> Windows Firewall -> Exceptions
    • Enable "File and Print Sharing", click "Edit"
    • For each entry:
      • Click "Change Scope"
      • Select "Custom List"
      • Enter the IP address of the OPSI server. (For staging: 10.2.71.216, for production: 10.2.71.64).

OPSI Prep and Install

We need to flip a few options in Windows to enable certain packages to install without prompting.

  • Do not prompt for unsigned drivers (needed for at least the windows mobile sdk)
    • Control Panel -> System -> Hardware -> Driver Signing, choose "Ignore".
  • Security Settings
    • Start Menu -> Run -> \\$ipOfOpsiServer (staging: \\10.2.71.216, production: 10.2.71.64)
    • Use 'pcpatch' and the root password when prompted.
    • Right click 'opt_pcbin' and select 'Mount as Network Drive'
    • Browse to z:\install\preloginloader
    • Double click 'opsi-prep.vbs'
    • Double click 'service-setup.cmd', hit a key when prompted
    • When prompted for a username and password use 'root' and the appropriate password.

Once OPSI is finished installing it will forcibly reboot the system. In a few minutes it should come back up and the client should be listed in the OPSI GUI.

Autoit

We require Autoit to deploy many packages. To install it, do the following:

  • Checkout the installer:
cvs -d:ext:cltbld@cvs.mozilla.org:/mofo co ref-platforms/win32/autoit-v3-setup.exe
  • (as Administrator), run the installer, accept the defaults

Installing a package on a client

  • Open up the OPSI Config Editor
  • Select a client or clients, click on "Product Configuration"
  • Change the action to "setup" for anything you want to install.
  • The package(s) will be installed at the next reboot.

Note: The state table under "Product Configuration" does not seem to work right. No matter what happens during the install of a package (whether it works or not) it will be considered "installed" afterwards.

Creating a package

Parts of the package

An OPSI package is built from a directory with a specific layout and set of files. These are kept in version control and should be reviewed before check in. The important files in the package are as follows:

  • OPSI/control - This contains the metadata for a package: name, version number, path to install script, etc.
  • CLIENT_DATA/packagename.ins - This is the meat of a package. All of the installation work and setup should be done here. It is written in a language called wInst which is fairly well documented.

Less commonly used files:

  • OPSI/preinst - Executes before the installation script (shell)
  • OPSI/postinst - Executes after the installation script (shell)

Any installers or files a package depends on should be placed in the CLIENT_DATA/ directory, too. That entire directory is downloaded to the client before the installation script executes. Files in it can be referenced from within the installation script.

Bootstrapping a new package

To get the basic files/directories needed to start a new package you should do the following: 

hg clone http://hg.mozilla.org/build/opsi-package-sources
cd opsi-package-sources
rsync -av newproduct-template/ myproduct/

Next:

  • Edit OPSI/control with the product details.
  • Put package files in CLIENT_DATA/.
  • Create an installation script.

Installation script basics

This document doesn't cover wInst syntax in detail, please refer to the wInst manual for that.

Installing an MSI

This is by far the easiest type of package to install. Almost all MSIs have a silent mode which you can invoke. For example, here is the installation script for Visual Studio 2005: 

[Initial]
Message=installing Visual Studio 2005 ...
StayOnTop=false
[Aktionen]
  Winbatch_product_silent_install
[Winbatch_product_silent_install]
msiexec.exe /i %SCRIPTPATH%\vs_setup.msi TRANSFORM=%SCRIPTPATH%\Setup\vs.ini /passive /l* c:\visualstudioinstall.log

Installing a package without a silent install

A lot of packages don't offer silent install options. To work around this, we depend on a tool called Autoit. Autoit is a tool which automates mouse clicks and keyboard strokes. Here's how to create a package that uses Autoit:

  • Use the Autoit "Script Writer" to record the necessary clicks and strokes to install your package. Try to keep unnecessary mouse movement to a minimum while recording to avoid bloating the script.
  • Test the script to make sure it works.
  • Put the script and the package in the CLIENT_DATA/ directory.
  • Create the OPSI installation script and call Autoit from it. For example, here's the installation script for MozillaBuild 1.3:
Initial]
Message=MozillaBuild 1.3 Installation
StayOnTop=false

[Aktionen]
Winbatch_install_mozillabuild

[Winbatch_install_mozillabuild]
autoit3.exe %SCRIPTPATH%\mozillabuild.au3 %SCRIPTPATH%\MozillaBuildSetup-1.3.exe

Updating registry keys

The wInst language provides a nice built-in way to update registry keys as part of an installation. Rather than (or in addition to) calling out to an installer you can write registry keys in the installer. For example, here's how to update the system PATH to append "d:\mozilla-build\python25\scripts": 

[Initial]
Message=Installing new registry keys
StayOnTop=false

[Aktionen]
Registry_AddPath

[Registry_AddPath]
openkey [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment]
supp "Path"; "d:\mozilla-build\python25\scripts"


Testing the package on staging

On staging you want to test out the package first to make sure it installs correctly before it goes into production. To create a .opsi package and inform OPSI about it, do the following: (For staging): 

# as root on the opsi server
cd ~cltbld/opsi-package-sources
su -c './regenerate-package dir-with-your-package'

If there are any issues and you need to regenerate the package you can simply drop in the new code and run the above again.

Installing the package file on production

Please note that you should NOT install packages onto the production OPSI server unless they have been properly reviewed and checked in. That means your package should be landed in opsi-package-sources (hg), and you should land any binaries in opsi-binaries as cltbld@staging-puppet (CVS).

(For production): 

# as cltbld on the opsi server
# update binaries
cd ~cltbld/opsi-binaries
cvs up -Pd

# update the package source clone
cd ~cltbld/opsi-package-sources
hg pull && hg up
./sync-binaries

# Recreate and install the package
su -c './regenerate-package package-name'

Your package should now show up in the OPSI Config Editor. Make sure to set staging slaves to install/update the package as well as production ones.

Documentation/Links

Retrieved from "https://wiki.allizom.org/index.php?title=ReleaseEngineering/OPSI&oldid=250723"