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 setup consists of the following broad steps, which are described in more detail in the sections that follow:
Most code servers implement a redirected client read-only drive letter for storing product images and response files and a read-write client redirected drive letter 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. You should set the access controls of the SHAREA directory to read-only (RX). The access controls for the SHAREB directory should be set to read-write (RWCXAD) since this is where 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. If you wish, you can create a version or SYSLEVEL directory below each product image. This can help you to manage multiple releases of the same product. If you choose not to have version directories, the directories are created when you XCOPY the product image directories from the Server Pak CD-ROM.
If you want to use our directory structure, you can see it in Figure 41.
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. |
We must copy the images of OS/2 and all the components associated with OS/2 Warp Server for e-business, such as MPTS, TCP/IP, LDAP, and others. The image of the base operating system is located in the directory \OS2IMAGE on the Server Pak CD-ROM. All other products are located in \CID\SERVER. Copy the images to the appropriate directories on your code server. When copying, you can use XCOPY or just drag-and-drop using the drive icons from your Desktop.
In addition to the product images, you will also need a collection of tools that are also delivered on the Server Pak CD-ROM. These utilities provide the LCU code, the REXX libraries, and executable code that enables the creation of client boot diskettes, and some template files to help you 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 server migration (and pristine installation) using LCU CID takes advantage of REXX processing. To make sure that the REXX files are available for use by the server that is being migrated, run the following command:
X:\SHAREA\DLL\GETREXX D:\SHAREA\IMG\OS2IMAGE X:\SHAREA\EXE
The SRVIFS component of the LAN CID Utility (mentioned briefly in 5.3 LAN CID Utility) provides a NetBIOS-based redirector for the target server to get files from the code server during the migration. Unzip the SRVIFS utility to the code server with the following command (one-line):
PKUNZIP2 X:\SHAREA\IMG\MPTS\UTILITY\SRVIFS\SRVIFS.ZIP X:\SHAREA\CID\IMG -D
We must now enable our code server to use the SRVIFS file system that was
just copied in the previous step. This is done with the THINSRV
command. However, THINSRV requires a response file as a parameter.
This response file must be created before running THINSRV. In the
X:\SRVIFS directory, create a default SERVICE.INI file using the information
shown in Figure 42:
;
; SERVICE.INI for WS_CID
;
NAME=WS_CID
GROUPNAME=NO
ADAPTER=0
MAXCLIENTS=10
MAXFILES=500
CLIENTWORKERS=12
PATH=C:\SHAREA\IMG
PERMITWRITE=NO
PERCLIENT=NO
;
; Aliases
;
ALIAS=READONLY,SINGLE,IMG,C:\SHAREA\IMG
ALIAS=READWRITE, SINGLE, LOG, C:\SHAREB\LOG
Figure 42: SERVICE.INI file for THINSRV command
Once this file is created we can run THINSRV to configure SRVIFS on the code server, and update CONFIG.SYS and STARTUP.CMD with the correct parameters by executing the following command (split into several lines to make it easier to read):
X:\SHAREA\IMG\SRVIFS\THINSRV /R:X:\SRVIFS\SERVICE.INI /T:X:\SRVIFS /S:X:\SHAREA\IMG\SRVIFS /TU:X:\ /L1:X:\SRVIFS\CIDSRV.LOG
The results of the THINSRV command are to create the directory specified in the /T parameter and copy the required files, update the CONFIG.SYS PATH and LIBPATH, and update the STARTUP.CMD to automatically start SERVICE.EXE (the NetBIOS mini-server).
Now that we have configured the server portion of SRVIFS, the server that will be migrated must be enabled to do the same thing. The target system's CONFIG.SYS must be modified with the SRVIFS files, and the files on the code server must be accessible by the target system. We have two options:
In the case of a pristine installation, there is no existing operating system on the hard disk to modify, so we would create LCU boot diskettes to connect to the server and start the installation process. See 5.10.1 Create LCU Boot Diskettes for a quick overview of the instructions to do this.
To do this, execute the following command:
X:\SHAREA\IMG\SRVIFS\THINIFS /S:X:\SHAREA\IMG\SRVIFS
The code server administrator must build the response files in order to install the products on the system that will be migrated. These response files will go into the \SHAREB\RSP directory on the code server. There are several ways to create the response files as described below:
We have provided sample response files (in the \RSPFILES directory on the CD-ROM that accompanies this hard copy redbook) 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 system-specific operating system 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