Ignite-LUX: Management and Integration of Ignite-UX Software on a Server Running Linux

20
Client-Specific File: manifest
The manifest file is intended to be a human-readable report of how the client system was installed. CMS
software should not parse this file since Ignite-UX software might make changes in the future.
Client-Specific File: server.instr
The server.instr file is used to control client operation when a client is booted into Ignite-UX control
from the server. CMS software may write strings into this file. The Ignite-UX client periodically polls this file
to get server instructions.
The following control strings may be used:
start_install (initiate install or recovery)
reboot_client (interrupt install and reboot the system)
recovery_shell (interrupt install or recovery and launch diagnostic shell)
halt_client (interrupt install or recovery and shutdown system)
Client Installation and Recovery Control Operations
There are a number of operations that are typically necessary for a CMS to control HP-UX installation. This
section provides some best practices for implementing integration for these operations.
One of the high-level design considerations is the exact sequence of client and server operations controlled
by the CMS software. There are two ways to approach the client/server boot and control synchronization
problem:
1. Live client system inventory data are used with server controlled installation. This may be done via
the following sequence of operations:
a. The client system is booted manually or by CMS control, and the Ignite-UX install
environment is started. A client system inventory is done and reported to the server. The
client waits for server-controlled installation.
b. CMS software uses the client inventory data to create an Ignite-UX config file that will
perform needed selections and provide other configuration details.
c. CMS software allows the client system to proceed with installation using the supplied
config.
2. Previously collected inventory data are used to control non-interactive installation. This may be done
as follows:
a. CMS software already has any needed client system inventory data via some process. That
process may be unrelated to Ignite-UX or may be the result of a previous use of Ignite-UX.
b. CMS software uses the client inventory data to create an Ignite-UX config file that will
perform needed selections and provide other configuration details.
c. The client system is booted manually or by CMS control and the Ignite-UX install
environment is started. Upon boot, the client immediately initiates installation using the
config content previously created by the CMS software.
Either approach may be used; they may even be intermixed on the same Ignite-UX server. Care is required
if independently collected client inventory data are used so values match Ignite-UX config values.
You will have to consider the configuration complexity of HP-UX client systems and what that means to CMS
software. An important question is how the end user will control config settings. For example, HP-UX
systems often have complex configurations that include many disks. Ignite-UX is able to install by choosing a