5.6.5 Latest
InformationThis section discusses the preparation required to set up a code server. It is provided by way of background information only. If you already are experienced with unattended software distribution, you can skip this section.
The code server set up consists of the following broad steps:
Most code servers use a redirected client read-only drive for storing product images and response files and a read-write client redirected drive for storing installation log files.
Some possible structures are discussed in detail in &CID.&CID.The OS/2 Warp 4 CID Software Distribution Guide, SG24-2010, or OS/2 Insta&CID.llation Techniques: The CID Guide, SG24-4295.
The structure that we have implemented in our environment, from which we provide tested, working examples of LCU syntaxes and response files, is illustrated in 6.8 Description of the Example Domain.
The two top level directories are used to enable coexistence between LCU and NVDM/2. They conform to the NVDM/2 implementation as directories \SHAREA and \SHAREB. The SHAREA directory is read-only. In the SHAREB, read-write directory, we store our client LCU installation command files, log files and response files. Below SHAREA, we have the \SHAREA\IMG directory that contains all product images by name. Below each product image directory is a version or SYSLEVEL directory. This helps us to manage multiple releases of the same product. You might implement it differently, but this works for us.
Although it is possible to keep our LCU installation command files and response files in a read-only area, our implementation provides flexibility in a working, production environment.
Let us explain what we mean by this. When new LCU batch and response files are created by designated CID administrators, they are created dynamically from a front end user written REXX procedure, which provides some degree of automation. In order to have access to support the dynamic creation of such files, read-write access is needed.
| Flexibility in Directory Setup |
|---|
|
There is no right or wrong way to set up your code server directory structure just as long as it is consistent and it works for you. |
The image of the base operating system is located in the directory \OS2IMAGE. All other products are located in \CID\SERVER. Copy the images to the appropriate directories on your code server. If you want to use our directory structure, you can see it in Figure 37.
Once the code server has been installed, the product images must be copied
into the correct directories. All product images can be found on the OS/2 Warp
Server for e-business Server Pak CD-ROM.
Figure 37: CID Directory Structure in Our Examples
In addition to the images, you will also need a collection of tools that are also delivered on the CD ROM. These utilities provide the LCU code, the REXX library, and executable code that enables the creation of client boot diskettes, supports the installation itself, and some template files with which to build your installation routines.
You can find the utilities in \CID\DLL\OS2, \CID\EXE\OS2, \CID\EXE\MPTS, and \CID\LOCINSTU directories on the CD-ROM. If you need further information about any of these utilities, please refer to the README.CID file on the Server Pak CD-ROM.
The following commands will copy the necessary additional files to the right places in the CID tree based on the environment described above. In this set of commands, X: is the drive that your CID directory tree is installed on, and D: is the drive letter assigned to your CD ROM drive.
XCOPY D:\CID\LOCINSTU X:\SHAREA\DLL\ /S /E XCOPY D:\CID\DLL\OS2 X:\SHAREA\DLL\ /S /E XCOPY D:\CID\EXE\MPTS X:\SHAREA\EXE\ /S /E XCOPY D:\CID\EXE\OS2 X:\SHAREA\EXE\ /S /E
The code server administrator must build the response files in order to install the products on the system that must be migrated. There are several ways to do this.
We have provided sample response files that can be tailored to your environment. They represent working examples, but they are specified with our configuration parameters and will need to be modified prior to being used in another environment.
Alternatively, after manually migrating a server to OS/2 Warp Server for e-business, or installing all required components on a pristine system, a set of response files are created, built from the user interaction with the GUI.
Behind the installation shield, the CD-ROM-based installation of OS/2 Warp Server for e-business uses CID techniques. The graphical user interface collects all the necessary configuration information from the user and combines it with template LCU parameters and response files. It then completes a CID installation.
On a server that has been installed with OS/2 Warp Server for e-business, the response files representing the user's selections for each product are placed in the directory \IBMINST\RSP\LOCAL of the boot drive. This is particularly useful if the test machine is installed with the same or similar configuration as other systems that you might want to migrate later on.
The response files, like our supplied, working sample response files, can then be customized to meet your specific needs.
Using the information available to you (the sample response files and README.CID file supplied with the product, this redbook, and access to the CID redbooks The OS/2 Warp 4 CID Software Distribution Guide, SG24-2010&CID. or OS/2 Installation Techniques: The CID Guide, SG24-4295) it is possible to construct your own response files for use in a CID installation.
We feel that this third option has no advantages given, and that options (1) and (2) provide all necessary information.
The CD-ROM contains numerous README files and sample response files that are delivered with the components. For example, on the CD-ROM in the \IBMINST\TABLES directory there are a number of template response files. We believe that a review of all available information will help the administrator decide on the best way of creating the response files.
Feature Installer, or Command Line Interface Feature Installer (CLIFI) was introduced in OS/2 Warp, Version 4. Feature Installer offers a set of installation services available to software developers that frees software developers from writing customized installation code to install their software.
You can find the executable CLIFI.EXE in the \OS2\INSTALL of your boot drive. CLIFI needs two response files for unattended installation:
This is a response file generated with the CLIFI developers toolkit. It contains a detailed description of all files and objects to be installed. The general response file is often very long, sometimes more than 1 MB. It should not be modified by the user.
This is a response file that is created/managed by the CID administrator. It contains the user specific details, such as the selection of components, target paths, and other selections. The settings in the partial response file override the defaults from the generic response file.
Before installing any additional components, &Feature., itself, must be installed. This happens automatically when the base OS/2 operating system is installed. Since &Feature. execution requires a Presentation Manager environment, it cannot be started from a maintenance system, which is command-line only.
You can find out more about CLIFI and the generic response files (the response files that comes with every CLIFI-enabled product) in the redbooks The OS/2 Warp 4 CID Software Distribution Guide, SG24-2010 and The OS/2 Warp 4 CID Rapid Deployment Tools: Migration and Installation Scenarios, SG24-2012.
The following products are installed using Feature Installer:
In this redbook, we discuss Feature Installer only as it directly relates to the installation of the products in this migration scenario.
Some products are still installed by the Software Installer program. They are:
| Software Installer CID Installation Syntax |
|---|
INSTALL.EXE /X /A:I /O:drive /L1:<error_log_file /L2:<history_log_file> /R:<response_file> |
In this redbook, we provide sufficient information (through syntaxes and response files) to enable the installation each of these products. Therefore, there is no need to consider Software Installer any further.
For more detail on Software Installer, including its installation syntax, please refer to the redbook titled Examples of Using Software Installer, GG24-2529.
5.8 Overview of
Installation Steps