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

default disk from the set of available disks. However, if the system has hundreds or thousands of disks, you

might be extremely unhappy with this approach. It could be vital for you to be able to control things like

root disk selection.

Depending on the end user policies, it might be possible to set up default config rules that manage these

issues to a certain extent. For example, if the end user policy is to place OS content on local storage and

use FibreChannel for application storage, Ignite-UX inventory blocking of FibreChannel could be used to

ensure that FC LUNs are not selected for OS installation.

You should consider how to could create custom config content for clients that would fit with the CMS

software approach for deployment control. This is important so you can get correct client-specific Ignite-UX

configuration details not supported in your CMS user interface.

The CMS solution should consider software maintenance needs as supported by Ignite-UX. An Ignite-LUX

server is unable to support HP-UX depot installation since the Software Deport (SD) agent (swagent) can

only run on HP-UX servers. However, installations often rely on depots of patches and additional HP-UX

software. Ignite-UX does have the ability for an installation to use an archive from a Linux server and

software from depots provided from HP-UX servers.

Note: Support for the installation of Software Distributor (SD) depots via NFS from a Linux Ignite-LUX server

might be supported in a future release. That approach does not require the swagent agent to run on the

Linux server.

The focus of this section is installation and recovery using config files and archives that have previously

been set up on the Ignite-UX server. CMS integrators should consider how that set up will be done. Manual

set up of the Ignite-UX server might be acceptable. However, there might be considerable value in

providing a means for controlling golden image creation and client recovery image creation.

The Ignite-LUX ignite CLI uses best practices for client management and provides machine-readable

output in XML format. The ignite, ignite-version, ignite-client, and ignite-config

manpages should be consulted. Using the Ignite-LUX CLI will simplify compatibility with future Ignite-LUX

releases since the data format is extensible.

The Ignite-LUX ignite command has limitations and differences from the HP-UX Ignite-UX ignite

command. The Ignite-LUX ignite command does not manage bootp configuration. Normally, CMS

software manages client boot from a variety of operating systems and Ignite-LUX boot configuration would

cause conflicts. Also, the Ignite-LUX ignite command does not include config file content parsing, so there

is no check for syntax errors. Due to the approach used to implement Ignite-LUX, parsing is not likely to be

developed anytime soon.

Care should be taken to avoid sensitivity to the format and details of file content accessed outside

recommended commands. For example, it might make sense for a CMS to provide the ability to show

install.log details, but it would be a bad idea to parse these log file details rather than use ignite

client status XML data.

Listing Configuration Clauses

A CMS will need to list the OS configurations available for installation. For Ignite-UX, these are represented

in config file content. Ignite-UX can only install configuration clauses for the same HP-UX release as the