We Have Ignition ...

• 03/04/1999

Last month, we did an overview of configuration files. This month I'll run through somedetails and examples.

COLLECTING A SYNTAX

First, a quick look at the syntax used. Because HP ships so many examples, we'll leavethe details to the man page (man 4 instl_adm). Numbers can be typed out, or you can usesuffixes. For example, 1024 and 1KB mean the same thing. The MB suffix is real handy forworking with disks. The common math operators * / + - are supported.

Variables are assigned with the = symbol. Use += to add a string to what's already in avariable. This is valid for complex string type variables that are handy for making a listof scripts to be executed.

Use # for a comment line and group statements with {}. The common symbols for logicalcomparisons and grouping are in the examples below. One deviation from typical programminglanguages, however, is that & means logical and instead of &&.

The syntax used for branching if statements omits the if. For instance:

(num_disks < 2)
{cfg "small_sys" = true}
else {cfg "eng_sys" = true}

This example uses the system attribute keyword num_disks. It returns how many disks areinstalled on the system being ignited that determines which named configuration to use (ifonly one disk, select the small_sys configuration).

There are many such keywords and variables used to customize the installation to thetarget hardware. You can test for memory size to determine swap space or graphicscontroller type to determine which applications are loaded. You can test for just aboutanything concerning the target hardware.

CONFIGURATION CREATION

Let's take a look at a set of files. First, the INDEX file. By adding the followinglines, we've created our own configuration named ex1:

cfg "ex1" {
"/opt/ignite/data/Rel_B.10.20/config"
"/var/opt/ignite/data/Rel_B.10.20/ex_cfg"
"/var/opt/ignite/config.ex"
"/var/opt/ignite/config.local"
} = TRUE

Note that the first and last lines in the list of config files in this configurationare standard. The middle two are pathnames that I created. You must create all three fileswhose path begins with /var.

The =TRUE makes this the default configuration, as long as this is the lastconfiguration read that has =TRUE after it. There should be only one, unless it ispreceded by a conditional, as in the example above.

As mentioned in the last column, the config.local file is used for assigning commonsettings. Here are some examples of what might go in this file:

timezone="CST6CDT"
SD_SERVER="pookie"
root_password="7di3yDVWP55k6"
dns_domain="famece.com"
dns_nameserver[0]="172.16.3.4"
nis_server="172.16.3.6"
nis_domain="famece.com"
is_net_info_temporary=FALSE
disable_dhcp=TRUE
wait_for_nis_server=FALSE
run_setparms=FALSE

APPLYING THE BASICS

Take note that these are basic network configurations to be applied to all installationtargets. You can also do some site-wide system configurations in this file, such as kerneltuning parameters:

mod_kernel+="page_text_to_local 1"

This file is also a good place for Ignite server settings:

_hp_cfg_detail_level="ipvs"
env_vars+="INST_ALLOW_WARNINGS=1"
Note that you can use the keyword true, or 1, to signify true.

The next two, ex_cfg and config.ex, could be combined in one file, but in this examplewe'll separate the part that describes the archive file from the part that configures thefile systems and swap. To show it can be done, they are in different directories, and thenames, though following convention, do not exactly match the configuration name (ex vs.ex1).

Creating ex_cfg is actually simple. It's done by copying a template file from/opt/ignite/data/examples, reading the comments and filling in the details. This is thefile that describes the software source and any scripts you want to assign (removed inthis example) that complete the installation:

sw_source "ex Core Archive" {
source_format = archive
source_type ="NET"
....
final_script = "/opt/ex/bin/ex_Final"
nfs_source =
"172.16.3.4:/var/opt/ignite/archives/Rel_B.10.20"
}

In this example, we are describing an archive load that we want to access via NFS fromthe server. There are some standard scripts HP supplies that should be left in this file.Here they are omitted, but it does show an example of a final script to be executed afterthe load.

This file also has the very important software selection section. That section israther large, but this is a short version:

HARDWARE_MODEL~
"9000/7.*" {
init sw_sel "ex Golden Image" {
sw_source = "ex Core Archive"
archive_type = gzip tar
archive_path = "ex_002.gz"
impacts = "/" 18Kb
impacts = "/etc" 1847Kb
...
}} = TRUE

Here we told Ignite what type of archive (Gnuzipped tar file) and the name of the file.The software source section above told Ignite the directory it would be in. In the impactssection we must list out the size of all the upper level directories, so that Ignite canmake sure that everything fits in the logical volume setup chosen.

SUDDEN IMPACT

You can also let Ignite decide how to setup the disk so it will fit based on thisinformation. You can get the impact information by running the archive_impact commandagainst the image file. You can then adjust it if needed, say if some scripts will becopying, or if you are installing more software or data into the directories in thearchive image.

In this example, we also made this sw_sel statement true only if we were installing toa HP 9000 workstation (Model 700). We might have another section for a HP 9000 server witha different image file or scripts.

The last of the files listed in the INDEX file for this configuration is config.ex.This is where we saved the LVM sections created by the save_config command, run againstthe host containing the OS used to build that archive. That is why I said to save thatdata!

The file might have more that one filesystem layout for different disk configurations.You could choose which one to use with a dynamic statement such as:

(disk[_hp_root_disk].size >= 4000MB )
{ init _hp_disk_layout="Big disk"
init _hp_pri_swap=800MB}
else
{ init _hp_disk_layout="Small disk"
init _hp_pri_swap=200MB}

This example demonstrates the size of the root disk to decide which LVM layout and howmuch swap space to use. The section of this file that's not showing is the two disk layoutdeclarations, since that can be easily created from the save_config command. Or, you cancopy an example and edit it.

There are some settings used by the target before the actual installation begins thatmust be sent to the client in the INSTALLFS file. You poke these settings into INSTALLFSwith the instl_adm command.

TAKE A POKE AT INSTALLFS

One way to do this is to put the data into a file and use the -f option. For example,use instl_adm -f <name of this file> to load the information into INSTALLFS.

server="172.16.3.2"
route_destination[0]="default"
netmask[]="255.255.255.0"
kbdlang="PS2_DIN_US_English"
run_ui=false
control_from_server=false

Now the target will know how to get to the Ignite server and its address. We also setthe keyboard type, so that it does not stop and ask. The last two lines make sure that thesession will be hands-off, so long as a configuration matches this machine, or if we haveset a default configuration.

The target will either use its former IP address (if we use bootsys to invoke thesession) or get it from DHCP. Note that if we had set disable_dhcp=true in this file, wewould have had to set the IP address manually, or in the per-client files. If disable_dhcpis set in any other file it means don't use it during normal boots.

--At this point, we can perform hands-off software loads. That means Ican go home now.