Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
Ignite-UX Administration Guide: for HP-UX 11i > Chapter 12 Customizing Your Installation

Using Configuration Files


Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

Ignite-UX is driven by configuration files that define how clients are installed and configured. A configuration file can be thought of as a set of instructions. Ignite-UX provides a set of default configuration files when you install the product. These default configuration files are used until you change or customize them for use in your environment. By creating your own custom configurations, you can:

  • Save time during installation

  • Ensure standard configurations for similar clients

  • Create configurations specific to operating system version or hardware architecture

  • Automate all manner of tasks that would otherwise require manual intervention

The configuration file is expressed in a human- readable language, which is fully defined in instl_adm(4). The configuration file language is much like other programming languages in that it supports the use of variables and conditional expressions. You can create configuration files directly or by using the Ignite-UX GUI.

Most of the important elements that make up an installed system are described in the configuration files:

  • Identity of the client, presence of network configuration, and kernel modifications (additional drivers or tunable parameter settings)

  • Disk and file system layout

  • Software to be installed

  • User-defined scripts that run at various points in the installation process to further customize the client

Classes of Configuration Files

The configuration files used by Ignite-UX during the installation process logically group similar information into classes by operating system and functionality. Figure 12-1 illustrates the classes of configuration files and their locations.

Figure 12-1 Configuration File Use and Locations

Configuration File Use and Locations

Ignite-UX processes config files in the order shown below. The following description of each class explains how the various installation parameters can be progressively overridden:

  1. Installation control parameters - You can define the behavior of the installation process using parameters stored within the segment of the install file system that is reserved for configuration parameters (the first 8 KB). This configuration file location is special because it is available to Ignite-UX very early in the boot process. Some parameters that control installation must be specified here. You can specify defaults for parameters, such as:

    • IP address of the Ignite-UX server

    • Whether to halt the client when the installation is complete

    • Whether to execute installation of new clients from the Ignite-UX server GUI

    Table 12-1 lists the install kernel and install file system names and supported hardware architecture.

    Table 12-1 Install Kernel and File System Names by Hardware Architecture

    Hardware ArchitectureKernel NameFile System Name


    These install kernels and install file systems are located in the /opt/ignite/boot/Rel_release directory. Install kernels are normally hard linked, such that INSTALLFS, WINSTALLFS, IINSTALLFS, & VINSTALLFS files are one and the same. Ignite-UX uses the INSTALLFS file system as a default unless an alternate is specified using the -F option of the instl_adm command. For more information, see instl_adm(1M).

    Control parameters, such as run_ui, control_from_server, and disable_dhcp, can only be specified in the install file system configuration area and are accessed early in the installation process when this area is available. Boot control parameters are detailed in the Control Parameters section of instl_adm(4).

    You must use instl_adm(1M) to add, change, or delete these boot control and network definitions.

    NOTE: Before upgrading to a new version of Ignite-UX, consider retaining the current control parameters, located in the first 8 KB of your install file system, so that you can reapply them after you have successfully updated your Ignite-UX server.

    Extract the current parameters into a file, with the following command:

    instl_adm -d -F [W|V|I]INSTALLFS > first8k_param_file

    Edit the first8K_param_file to define your control parameters. Check your syntax with the following command:

    instl_adm -T -f first8k_param_file

    If you want to reapply these control parameters to all install file systems on your Ignite-UX, use the following command:

    instl_adm -f first8k_param_file

    If you want these control parameters applied to only one specific install file system, use the -F option. For more information, see instl_adm(1M).

  2. Default disk and file system layout - The capabilities of each operating system release differ somewhat so HP supplies a different set of disk and file system layout configuration defaults for each release. These configuration files are located in:


    Enter uname -r on the command line to determine the release. For example, the file that contains the default disk layout for HP-UX 11.11 would be in:


    as revealed by the uname -r command.

  3. Software description of a single SD depot - Configuration files that describe software available from SD depots can be automatically generated using the make_config tool within Ignite-UX. This tool produces one configuration file per SD depot. Software description configuration files are located in:


  4. Software description of an archive — You can create configuration files to enable access to archives (templates are provided with Ignite-UX in /opt/ignite/data/examples/ to give you a good starting point). Archive software description configuration files are also located in: /var/opt/ignite/data/Rel_release/

  5. Local configuration overrides that apply to all clients - It is often convenient to specify defaults to be applied to every client, in addition to the necessary operating system configuration installed from a particular Ignite-UX server. For example, you might want to specify the same NIS domain for all systems. You must include this type of configuration override information in:


    This file is not overwritten when the operating system is updated.

  6. Client-specific configuration file - This file contains specific directives appropriate for a specific system to override what may have been defined as general defaults for all systems in earlier configuration files. For example, you might want to customize the disk layout beyond what the operating system release defaults allow in:


    The unique customizations appear in the directory dedicated to the client by MAC address, which is linked to a directory containing the client name:


    This file is created when you use the Ignite-UX GUI to specify the client configuration.

  7. Creating and saving custom configuration choices - You can create your own custom configurations using the Ignite-UX GUI, save them for repeated use, and easily select them when installing clients. For example, you might have a large number of users with similar systems who all run Computer Aided Design (CAD) tools. You could build a configuration that defines all necessary parameters and save it in a configuration called CAD System. When you want to install a new system for a CAD user, you can select CAD System from the GUI and you are done (or you could customize it further using CAD System as the template). Saved configurations are located in: /var/opt/ignite/saved_cfgs/

NOTE: Configuration files are often referred to as config files because the word configuration is shortened to create file and directory names. For example, a client’s local configuration file is config.local.

You can build your own configuration files that specify the various installation parameters you are interested in, and then combine them in arbitrary ways into any number of different custom configurations using the /var/opt/ignite/INDEX file. Place these custom configuration files in one of the HP-UX release-specific operating system directories:


The next section describes how to combine multiple configuration files (default or customized) to define a single configuration.

Combining Configuration Files Using INDEX Entries

Grouping configuration files into useful configurations is accomplished in /var/opt/ignite/INDEX. This file contains a list of configurations in separate clauses; each comprising one or more configuration files that define an installation. Each configuration clause begins with cfg and a name by which the configuration is known.

You can view these configuration names using the instl_adm command. When installing a new client from the Ignite-UX GUI, you can view these configurations by clicking the button adjacent to Configurations... on the Basic tab by as shown in Figure 12-2.

Figure 12-2 Configuration Choices Dialog Box

Configuration Choices Dialog Box

A typical /var/opt/ignite/INDEX file might contain clauses similar to the following excerpt:

. . . cfg "HP-UX B.11.23 Default" { description "Default B.11.23 release configuration." "/opt/ignite/data/Rel_B.11.23/config" "/opt/ignite/data/Rel_B.11.23/core_cfg" "/opt/ignite/data/Rel_B.11.23/hw_patches_cfg" "/var/opt/ignite/config.local" } = TRUE . . . cfg "CAD System-11.23" { description "Supplies the CAD System configuration." "/opt/ignite/data/Rel_B.11.23/CAD_config" "/opt/ignite/data/Rel_B.11.23/CAD_core_cfg" "/opt/ignite/data/Rel_B.11.23/hw_patches_cfg" "/opt/ignite/data/Rel_B.11.23/CAD_sw_sels_cfg" "/var/opt/ignite/config.local" } . . .

With this /var/opt/ignite/INDEX file, the Ignite-UX GUI would present two configurations: HP-UX B.11.23 Default and CAD System-11.23. The HP-UX B.11.23 Default configuration is the default because that cfg clause is set to TRUE. After choosing a configuration, you can further customize the configuration using the GUI, or accept the configuration defaults to begin the installation immediately.

The order of the configuration files within a cfg clause is significant; attributes specified in a later configuration file can override the same attributes specified in an earlier configuration file. Two configuration files are used implicitly every time:

  • Any information stored in the first 8 KB of /opt/ignite/boot/Rel_release/[W|V|I]INSTALLFS is implicitly prepended to each configuration list and is the first configuration data processed.

  • The client-specific configuration file /var/opt/ignite/clients/client/config, if it exists, is implicitly added as the last configuration file for each configuration.

A default cfg clause for each release is shipped as part of Ignite-UX. Additional cfg clauses are added when you:

  • Save a named configuration from the GUI with the Save As button.

  • Create a configuration by modifying the /var/opt/ignite/INDEX file directly.

  • Use the manage_index command to automate /var/opt/ignite/INDEX file modifications.

    NOTE: To facilitate client recovery configurations, a CINDEX configuration file, similar to an installation INDEX file, is created. For more information, see Chapter 15: “Recovery Methods” or see manage_index(1M) and make_net_recovery(1M).

Additionally, you can specify how installation software is handled by Ignite-UX using the following three constructs:

  • A sw_source clause specifies an SD depot or an access method to a server containing software depots.

  • The sw_sel clause specifies the software contained in the SD depot or specifies the path to a depot on the server or media. Typically there is one sw_sel definition per software bundle or depot.

  • The sw_category clause is simply a mechanism for grouping sw_sel definitions.

See the clauses in Defining an Installation Depot for example usage of the above constructs. For more information, see instl_adm(1M).

Be sure to pass all user-generated configuration files through the following command to check for syntax errors:

instl_adm -T -f cfg_file

Example Configuration Files

This section shows a few example configuration files to give you an idea of their look and capabilities. For a complete description of Ignite-UX configuration files, see instl_adm(4).

For additional examples of configuration files, see the document, Ignite-UX Custom Configuration Files available on the "Information Library" page of the Ignite-UX Product Website:


Defining Disks

This example shows how a disk might be defined. Here, the disk is located at hardware address 2/0/1.6.0 and does not use Logical Volume Manager (LVM) or Veritas Volume Manager by Symantec (VxVM). The disk contains the root ( / ) file system and a swap area. The swap area takes up 512 MB and the root file system assumes the remainder:

partitioned_disk { physical_volume disk[2/0/1.6.0] fs_partition { usage = HFS size = remaining mount_point = "/" } swap_partition { usage = SWAP mount_point = "primary" size = 512 } }

Combining Disks to Form a Single Volume Group

You can put two disks together to form a single volume group. Two file systems are defined; both are striped across both disks. The following example illustrates this concept:

volume_group "appsvol" { usage=LVM physical_volume disk[2/0/1.5.0] { }
physical_volume disk[2/0/1.4.0] { } logical_volume "apps1" { mount_point = "/apps1" usage = VxFS size=30% free minfree = 5 stripes = 2 } logical_volume "apps2" { mount_point = "/apps2" usage = VxFS size = remaining minfree = 5 stripes = 2 } }

The preceding example uses LVM as the volume manager. However, it is also applicable to VxVM if usage=LVM is changed to usage=VxVM.

The first file system, /apps1, is sized by calculating the amount of space required by the software that is to be installed, and then adding 30 percent for free space. The second file system, /apps2, uses the remaining space on the disks.

NOTE: You can modify the file system volume sizes in the recovery image when the image is installed. By default, Ignite-UX ensures that there is 10 percent free space for each volume and modifies the file system volume size accordingly. If you do not want Ignite-UX to modify the file system volume sizes automatically, add init _hp_ignore_sw_impact=1 to your /var/opt/ignite/recovery/latest/system_cfg file, or to the /var/opt/ignite/clients/client/recovery/latest/system_cfg file.

Defining Networking Parameters

The following example lines define a few of the network parameters that are assigned to the system after it has been installed:

final system_name = "acorn1" final ip_addr["lan0"] = "" final netmask["lan0"] = "" final nis_domain = "nis1" final route_gateway[0] = ""

Defining an Installation Depot

The next example defines a single SD depot from which software can be installed. Two different pieces of software are defined for the SD depot. Each can be selected independently for installation. The impacts lines tell Ignite-UX how much space this software requires in a given directory. This information is used to size the file systems correctly. The sw_category construct enables you to group the software so the GUI can present it in chunks that make sense to you. Because this example references an SD depot, it could have been created by make_config:

sw_source "ee_apps_depot" { description = "Electrical Engineering Application Depot" source_format = SD source_type = "NET" sd_server = "" sd_depot_dir = "/var/opt/ignite/depots/Rel_B.11.11/ee_apps" } sw_category "Applications" { description = "User Applications" } sw_sel "EE CAD Package" { sw_source = "ee_apps_depot" sw_category = "Applications" sd_software_list = "EECad,r=1.2,a=HP-UX_B.11.11" impacts = "/var" 90524Kb impacts = "/sbin" 1248Kb } sw_sel "EE Routing Package" { sw_source = "ee_apps_depot" sw_category = "Applications" sd_software_list = "EERoute,r=2.4,a=HP-UX_B.11.11" impacts = "/usr" 12568Kb impacts = "/var" 26788Kb }

Customizations Based on the Client Hardware

The configuration file syntax provides a large number of system attribute keywords that describe the client. Some examples are:


size of the disk at the specified hw_path


amount of memory present on the client


string returned from uname -m

, lla

MAC address of the client

Using the logical expressions provided by instl_adm(4), you can use system attribute keywords to construct expressions in configuration files so that a particular clause is only included in specific client situations. The basic format of these clauses is:


which translates roughly to "if the expression x is true, then do y."

For example, this clause sets the size of two kernel tunable parameters if the client has more than 4096 MB of memory:

(memory > 4096MB) {     mod_kernel += "nproc (20+100*MAXUSERS)"     mod_kernel += "maxuprc 1000" }

As another example, use this if you want to run a script to do some particular graphics customizations, but you only want to do so when the client has the appropriate hardware:

(graphics[0].planes > 0) {     post_config_script +=         "/var/opt/ignite/scripts/multi_plane_graphics" }

You can also specify multiple conditions. The following example installs a particular piece of previously defined application software if the client is a supported PA-RISC or Itanium-based server or workstation having at least two disks. A message lets you know why it is happening:

( (HARDWARE_MODEL ~ "9000/7.*" | MODEL ~ "ia64 .* workstation .*") & (num_disks >= 2) ) { note += "Installed application software contained in apps1." init sw_sel "apps1" = TRUE

You must use both HARDWARE_MODEL and MODEL because of the differences in the way the uname and model commands work on Itanium-based systems. For example on an Itanium-based client you can use the following commands to find this information:

uname -m

# ia64


# ia64 hp workstation zx2000

Notice that the response from the uname command is truncated so it is not possible to determine if the client is a server or a workstation, whereas on a PA-RISC client, the same command results in the following:

uname -m

# 9000/785


# 9000/785/J6000

Additionally, you can add an else clause so that a choice can be executed automatically. The following example uses a generic variable capability and mathematical expressions to set the primary swap size based on the amount of memory in the client:

(memory > 512Mb) {     init _hp_pri_swap = 512Mb } else {     init _hp_pri_swap = memory * 2 }

The preceding examples represent a few of the numerous ways that system attribute keywords can be used in client configurations and should not be considered an exhaustive list.

Customizations Based on User Selection

One of the ways you can use Ignite-UX to your advantage is to create a customized configuration independent of the client’s hardware setup that can be selected for use repeatedly. For example, you might have some clients that you intend to use as NFS file servers and you would like to be able to quickly install these clients by selecting the same configuration from the GUI.

Let’s assume that you have found NFS file servers to be more efficient if two of their kernel parameters are modified. NFS file servers also require some changes to the /etc/rc.config.d/nfsconf file using the ch_rc command.

One alternative to effecting these changes manually is to define a custom software selection in /var/opt/ignite/config.local with a sw_sel clause, which then becomes a selection on the Software tab when you are configuring a new client installation. For example, the following clauses would automatically configure your NFS file servers:

sw_source "special configs" {     source_format = cmd } sw_sel "NFS Server" {     sw_category = "Machine Uses"     sw_source = "special configs"     mod_kernel += "dbc_min_pct 35"     mod_kernel += "dbc_max_pct 65"     post_config_cmd += "     /usr/sbin/ch_rc -a -p NFS_SERVER=1     /usr/sbin/ch_rc -a -p NFS_CLIENT=1     /usr/sbin/ch_rc -a -p NUM_NFSD=8" }

Figure 12-3 shows the Software tab when the NFS server configuration file is used. As shown, the selected category is Machine Uses as defined in the configuration file using the sw_category clause as in the previous example. This selection causes the kernel modifications and the ch_rc commands to be applied during the installation in addition to the other software categories you select.

Figure 12-3 Software Tab

Software Tab

Using the installation tabs to configure client installations is explained in Chapter 10: “Booting and Installing HP-UX on Clients Using the Server”.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© Hewlett-Packard Development Company, L.P.