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
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.
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:
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
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). |
|
| |
|
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:
/opt/ignite/data/Rel_release/config
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:
/opt/ignite/data/Rel_B.11.11/config
as revealed by the uname -r command.
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:
/var/opt/ignite/data/Rel_release/*
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/
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:
/var/opt/ignite/config.local
This file is not overwritten when the operating
system is updated.
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:
/opt/ignite/data/Rel_release/config
The unique customizations appear in the directory
dedicated to the client by MAC address, which is linked to a directory
containing the client name:
/var/opt/ignite/clients/client/config
This file is created when you use the Ignite-UX
GUI to specify the client configuration.
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:
/var/opt/ignite/data/Rel_release/*
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.
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.
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:
http://www.docs.hp.com/en/IUX/infolib.html
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"] = "10.99.45.123"
final netmask["lan0"] = "255.255.255.0"
final nis_domain = "nis1"
final route_gateway[0] = "10.99.45.1" |
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 = "10.23.45.6"
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:
- disk[hw_path].size
size of the disk at the
specified hw_path
- memory
amount of memory present
on the client
- hardware_model
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:
(x){y}
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
model
# 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
model
# 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.
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
