HP Ignite-UX User's Guide

Ignite-UX Custom Configuration Files

Table of Contents

Abstract ..............................................................................................................................................6

Introduction .........................................................................................................................................6

Typographic Conventions......................................................................................................................7

HP-UX 11i release names and release identifiers......................................................................................8

Configuration files and INDEX files .......................................................................................................9

The INDEX file ................................................................................................................................9

The CINDEX file ............................................................................................................................10

The per-client configuration file.........................................................................................................10

The global config.local file........................................................................................................11

The recovery config.local file.....................................................................................................11

Order of precedence of configuration files.........................................................................................11

Testing the order of precedence........................................................................................................12

What is in a configuration (cfg) clause? ...........................................................................................13

The make_net_recovery configuration files ...................................................................................14

The make_tape_recovery configuration files .................................................................................14

Files created by make_config .......................................................................................................15

Using the manage_index command ...................................................................................................15

A variety of uses.............................................................................................................................15

Adding a configuration file to a clause or "release"............................................................................16

Adding scripts to the INDEX file .......................................................................................................17

Removing cfg clauses from an INDEX file........................................................................................18

Setting the default cfg clause in an INDEX file .................................................................................19

Listing the names of cfg clauses in an INDEX file .............................................................................20

Listing the name of the default cfg clause in an INDEX file ................................................................21

Renaming a cfg clause in an INDEX file .........................................................................................21

Creating a new cfg clause from an existing clause ...........................................................................22

Removing a configuration file from a cfg clause ...............................................................................22

Removing a script from an INDEX file ...............................................................................................23

List the names of all configuration files in a cfg clause ......................................................................24

Display the description of a cfg clause............................................................................................25

Using the make_bundles command ...................................................................................................25

Why do you need to use make_bundles? .......................................................................................25

Choosing which form of make_bundles to use.................................................................................25

The make_bundles first form .....................................................................................................26

The make_bundles second form................................................................................................31

The make_bundles third form....................................................................................................33

Using the instl_dbg command .........................................................................................................35

Introduction....................................................................................................................................35

Requirements..................................................................................................................................35

Using the itool command .............................................................................................................35

Combining instl_dbg and itool.................................................................................................36

Running instl_dbg ......................................................................................................................36

Other instl_dbg options ..............................................................................................................41

The hw.info and host.info files .................................................................................................41

Creating both files ..........................................................................................................................41

Miscellaneous configuration tips...........................................................................................................43

Analyzing the HP-UX default B.11.11 cfg clause .................................................................................43

The release-specific configuration file ................................................................................................44

Analyzing the HP-UX default B.11.31 cfg clause .................................................................................64

The release-specific configuration file ................................................................................................65

Special variables................................................................................................................................85

_hp_locale.................................................................................................................................85

_hp_cfg_detail_level .............................................................................................................86

_hp_pri_swap.............................................................................................................................87

_hp_min_swap.............................................................................................................................87

_hp_disk_layout.......................................................................................................................88

_hp_default_cur_lan_dev .......................................................................................................90

_hp_default_final_lan_dev ...................................................................................................90

_hp_keyboard.............................................................................................................................91

_hp_root_disk...........................................................................................................................92

_hp_boot_dev_path...................................................................................................................92

_hp_primary_path.....................................................................................................................93

_hp_primary_partition_size .................................................................................................93

_hp_efi_partition_size .........................................................................................................93

_hp_service_partition_size .................................................................................................94

_hp_root_grp_disks.................................................................................................................94

_hp_root_grp_striped .............................................................................................................94

_hp_addnl_fs_free_pct ...........................................................................................................95

_hp_ignore_sw_impact .............................................................................................................95

_hp_custom_sys.........................................................................................................................97

_hp_lanadmin_args...................................................................................................................98

_hp_nfs_mount_opts.................................................................................................................99

_hp_nfs_mount_retries ...........................................................................................................99

_hp_tftp_cmds.........................................................................................................................100

_hp_hide_other_disks ...........................................................................................................100

_hp_saved_detail_level .......................................................................................................100

_hp_os_bitness.......................................................................................................................101

_hp_force_autoboot...............................................................................................................101

_hp_ikernel_os_release .......................................................................................................102

_hp_current_client_release ...............................................................................................102

_HP_CLONING.............................................................................................................................102

_hp_console_verbosity .........................................................................................................103

_hp_patch_save_files ...........................................................................................................103

_hp_umask.................................................................................................................................104

_hp_ht_enable.........................................................................................................................104

_hp_debug_level.....................................................................................................................105

Configuration for software to be installed ............................................................................................105

Application software depots...........................................................................................................105

Core operating system depot configuration......................................................................................110

Impacts statements ........................................................................................................................116

Overstated SD impacts ..................................................................................................................118

Categories and other Ignite-UX software attributes ............................................................................118

Defining a custom software configuration ........................................................................................120

Looking at a network recovery sw_source and sw_sel ..............................................................120

Using a sw_sel to run commands instead of installing software ....................................................122

Using a sw_sel to apply kernel parameters ................................................................................123

Forcing software (sw_sel) clauses to be installed.........................................................................127

Automating dependencies in software .........................................................................................127

Installing patches ..........................................................................................................................129

Configuration for volume and disk groups ...........................................................................................129

Overview.....................................................................................................................................130

Configuration examples ....................................................................................................................131

Example One (custom disk layout) ..................................................................................................131

Example Two (selection of disk layout based on hardware)................................................................136

Example Three (be careful what you ask for, you just might get it) ......................................................138

Example Four (installation file system configuration) ..........................................................................139

Part A (custom configuration in installation file system)...................................................................139

Part B (Installation file system custom network config).....................................................................140

Example Five (handling user input)..................................................................................................140

Part A (restricting the values that a variable can take using an enum) ..............................................141

Part B (looking at the same thing when we don’t have an enum).....................................................142

Example Six (handling command line arguments) .............................................................................142

Example Seven (regular expression matching)..................................................................................143

Configuration parameters in the installation file system .........................................................................148

Networking..................................................................................................................................148

Problems that can be solved with _hp_lanadmin_args..................................................................150

Control........................................................................................................................................151

Environment variables ...................................................................................................................152

Managing configurations with unifdef.............................................................................................153

Coping with auto_adm and boot changes in HP-UX B.11.23 ...............................................................155

Looking at auto_adm...................................................................................................................156

ISL and CONF format data ............................................................................................................156

CONF data..............................................................................................................................156

ISL data ...................................................................................................................................158

Usage examples...........................................................................................................................158

Creating new files .....................................................................................................................158

Adding new menu entries to a file...............................................................................................159

Using an "append" file..............................................................................................................160

Updating a menu entry in a file ..................................................................................................160

Deleting a menu entry from a file ................................................................................................161

Changing the default menu choice ..............................................................................................162

Changing the timeout ................................................................................................................162

Updating the prompt message ....................................................................................................163

Into and out of an LIF file............................................................................................................163

Installation configurations using Software Distributor depots ..................................................................163

Getting started .............................................................................................................................164

Creating the core operating system depot........................................................................................164

Operating Environments containing multiple CDs or DVDs .................................................................166

Other methods for creating the Core OS depot ................................................................................167

Using the Ignite-UX GUI .............................................................................................................167

The pitfalls of using multiple media..............................................................................................173

Creating the configuration file to describe the depot .........................................................................173

Creating a minimalist cfg clause for installation ..............................................................................175

Comments on the SD based cfg clause ..........................................................................................176

Extending the generic SD cfg clause with applications.....................................................................176

Creating the application depot ...................................................................................................176

Creating a configuration for the application depot........................................................................176

An example problem.................................................................................................................177

Follow on consequences ............................................................................................................178

Resolving applications that are not in SD format ...............................................................................179

Package an application in SD format ..........................................................................................179

Define an application in a non-SD format.....................................................................................180

Using noncore.cfg to define applications ....................................................................................183

SD and archive bitness comparison ................................................................................................186

Adding the non-SD application configuration file to the INDEX file .................................................187

Installing patches from a depot.......................................................................................................187

Setting up the depot ..................................................................................................................187

Packaging the patches into a bundle ...........................................................................................187

Generating a configuration ........................................................................................................188

Customizing configuration .............................................................................................................189

Installing with SD wrap-up .............................................................................................................191

Performance considerations for SD-UX based installs ............................................................................191

Tuning SD-UX for concurrent access ................................................................................................192

Issues to consider related to the HP-UX revision ................................................................................192

Issues Independent of HP-UX revision ..............................................................................................193

Memory and the buffer cache.....................................................................................................193

Network Bandwidth ..................................................................................................................194

Installation configurations using golden images....................................................................................195

Golden image configuration file explanation....................................................................................195

Instances that may require modifying os_arch_post_l..................................................................201

Creating a golden image...............................................................................................................202

Final words about golden image installations...................................................................................202

Understanding what is_net_info_temporary does........................................................................203

Understanding how VxFS file system versions are set ............................................................................204

How do I…......................................................................................................................................205

How do I remove the warning message that occurs when compiling a kernel on PA-RISC systems?.........205

How do I recognize if a disk exists or not from within a configuration file? ..........................................206

How do I create the CD equivalent of a tape created by make_boot_tape? .....................................207

How do I enable the X server and CDE during a golden image install? ...............................................211

Summary.........................................................................................................................................212

For more information ........................................................................................................................212

Abstract

Ignite-UX for HP-UX addresses the need for system administrators to perform operating system installations, deployment, and recovery, often on a large scale. It provides the means for creating and reusing standard operating system configurations. Additionally, Ignite-UX delivers the ability to archive operating system configurations, and to use these archives to replicate systems, with the added benefit of speeding up the process. Ignite-UX also permits various customizations, and is capable of both interactive and unattended operating modes.

Introduction

The Ignite-UX Administration Guide explains how to use the Ignite-UX product. However, it does not cover in detail the configuration files used by Ignite-UX (and custom configuration files that you can write).

This document supplements the Ignite-UX Administration Guide to help make creating and writing custom configuration files easier. It is assumed readers understand how to install a system using Ignite-UX. The information in this document addresses managing, writing, and modifying configuration files.

In developing this document, Ignite-UX versions from B.5.1.x to C.7.1.x were used.

Note:

Care was taken to prevent unintended line wraps from occurring in the

s in this document; however, due to formatting limitations, some

example might exist. This may affect the usefulness of examples if you use them without verifying the syntax using instl_adm with the –T option.

Typographic Conventions

The following typographical conventions are used throughout this document.

audit(5)

An HP-UX manpage. "audit" is the name and "5" is the section in the HP-UX Reference. On the Web and on the Instant Information media, it may be a hot link to the manpage itself. From the HP-UX command line, enter "man audit" or "man 5 audit" to view the manpage. For more information, refer to man(1).

Book Title

The title of a book. On the Web and on the Instant Information media, it may be a hot link to the book itself.

Emphasis

Text that is emphasized.

Emphasis

Text that is strongly emphasized.

ComputerOut

Text displayed by the computer.

Command

A command name or qualified command phrase.

Computer

Computer font indicates literal items displayed by the computer. For example:

file not found

Filename

Text that shows a filename and/or filepath.

UserInput

Commands and other text that you type.

Variable

The name of a variable that you may replace in a command or function or information in a display that represents several possible values.

[ ]

The contents are optional in formats and command descriptions.

{ }

The contents are required in formats and command descriptions. If the contents are in a list separated by |, you must choose one of the items

. . .

The preceding element may be repeated an arbitrary number of times.

Separates items in a list of choices.

<MAC>

When used as part of a file name, this placeholder variable refers to the Media Access Control (MAC) address of the Ignite-UX client system under /var/opt/ignite/clients. This may also be referred to as Link-Level Address (LLA).

<DATE-TIME>

This indicates a directory created by Ignite-UX that has a fixed format containing the date and time it was created, for example "2004-01-12,15:23".

HP-UX 11i release names and release identifiers

Each HP-UX 11i release has an associated release name and release identifier.

Table 1 shows the releases available for HP-UX 11i.

able 1

Release Name Release Identifier Supported Processor Architecture

HP-UX 11i v1 B.11.11 PA-RISC

HP-UX 11i v2 B.11.23 Intel® Itanium

PA-RISC1

HP-UX 11i v3 B.11.31 Intel® Itanium

PA-RISC

The uname(1) command with the -r option returns the release identifier.

You can also determine the update release date and the Operating Environment by entering the following:

# swlist | grep HPUX11i

The resulting output lists the current release identifier, update release date, and Operating Environment. For example:

HPUX11i-OE-MC B.11.23.0606 HP-UX Mission Critical Operating Environment Component

The preceding revision string represents the following:

B.11.23 = HP-UX 11i v2

0606 = June 2006 Update Release (in the format YYMM)

1 HP9000 systems are supported on HP-UX 11i v2 starting with the September 2004 release.

Configuration files and INDEX files

This section discusses the contents of configuration files and INDEX files to help you understand the purpose of the files, not to document what is occurring in the files.

The INDEX file

The file /var/opt/ignite/INDEX is used during cold-installs. The following example only has one cfg clause; usually there are more. Each cfg clause defines a series of configuration files, along with a description, that together form a cohesive configuration that is used to install a system.

$ pwd /var/opt/ignite $ cat INDEX # /var/opt/ignite/INDEX # This file is used to define the Ignite-UX configurations # and to define which config files are associated with each # configuration. See the ignite(5), instl_adm(4), and # manage_index(1M) man pages for details. # # NOTE: The manage_index command is used to maintain this file. # Comments, logic expressions and formatting changes are not # preserved by manage_index. # # WARNING: User comments (lines beginning with '#' ), and any user # formatting in the body of this file are _not_ preserved # when the version of Ignite-UX is updated. # cfg "HP-UX B.11.11 Default" { description "This selection supplies the default system configuration that HP supplies for the B.11.11 release." "/opt/ignite/data/Rel_B.11.11/config" "/opt/ignite/data/Rel_B.11.11/hw_patches_cfg" "/var/opt/ignite/config.local" }

If the cfg clause in the INDEX file were to be the default cfg clause (in a non-interactive installation this would cause the cfg clause to be selected for installation by default) it would look like the following:

cfg "HP-UX B.11.11 Default" { description "This selection supplies the default system configuration that HP supplies for the B.11.11 release." "/opt/ignite/data/Rel_B.11.11/config" "/opt/ignite/data/Rel_B.11.11/hw_patches_cfg" "/var/opt/ignite/config.local" }=TRUE

Of course, the INDEX file is never to be edited manually; instead, the manage_index command should be used to maintain this file. The actual command needed to set a cfg clause to be the default clause is as follows:

# manage_index -e -c "HP-UX B.11.11 Default"

The manage_index command operates on the /var/opt/ignite/INDEX file by default, so the INDEX file does not need to be specified on the command line.

The CINDEX file

The CINDEX file is very different from the INDEX file. The CINDEX file is created and managed by the make_net_recovery command. The format of the CINDEX file is the same as the INDEX file. For example:

# cat /var/opt/ignite/clients/<MAC>/CINDEX # This file is used to define the Ignite-UX configurations # and to define which config files are associated with each # configuration. See the ignite(5), instl_adm(4), and # manage_index(1M) man pages for details. # # NOTE: The manage_index command is used to maintain this file. # Comments, logic expressions and formatting changes are not # preserved by manage_index. # # WARNING: User comments (lines beginning with '#' ), and any user # formatting in the body of this file are _not_ preserved # when the version of Ignite-UX is updated. # cfg "2003-10-08,12:41 Recovery Archive" { description "Recovery Archive" "recovery/2003-10-08,12:41/system_cfg" "recovery/2003-10-08,12:41/control_cfg" "recovery/2003-10-08,12:41/archive_cfg" } cfg "2003-10-08,12:45 Recovery Archive" { description "Recovery Archive" "recovery/2003-10-08,12:45/system_cfg" "recovery/2003-10-08,12:45/control_cfg" "recovery/2003-10-08,12:45/archive_cfg" }=TRUE

This file contains the cfg clauses needed to recover a system from a network recovery archive. The make_net_recovery command automatically manages the CINDEX file so older information is removed recovered.

and the latest recovery archive is set as the default archive that is

The per-client configuration file

The configuration file that can exist in a per-client directory (var/opt/ignite/clients/<MAC>) overrides all other files that an Ignite-UX client may use. Any configuration values set in this file override all other files with one exception that is discussed elsewhere (see "Order of precedence of conf

iguration files" for more information). During the installation proc

the configuration information that was used, which facilitates repeated installations of the same system. If this file exists, it typically selects a cfg clause from the CINDEX or INDEX files. For example:

# cat config cfg "2003-10-08,12:45 Recovery Archive"=TRUE _hp_cfg_detail_level="ipvs" # # Variable assignments

For more information, refer to make_net_recovery(1M) and review the description of the –n option.

ess, Ignite-UX saves to this file

# init _hp_root_disk="8/16/5.6.0" init _hp_root_grp_disks=1 init _hp_root_grp_striped="NO" ...

In this case, a recovery archive has been selected. (This also indicates that a recovery archive may have been recovered onto this system at some time in the past.)

The global config.local file

The file /var/opt/ignite/config.local is included by default into all new cfg clauses in the /var/opt/ignite/INDEX file. For this reason, configuration data stored in this file is used on all new installations.

The recovery config.local file

For make_net_recovery, if the file /var/opt/ignite/clients/<MAC>/recovery/config.local exists on the Ignite-UX server, the contents are automatically included into the configuration used by the client during a network recovery.

For make_tape_recovery, if the file /var/opt/ignite/recovery/config.local exists, the contents are automatically included into the configuration used by the client even though it is not explicitly referenced. The content of this file is placed into the LIF on the tape.

Note:

If you use the –s option with make_tape_recovery, the same file used by make_net_recovery is used instead of /var/opt/ignite/recovery/config.local, as previously described.

config.local

Order of precedence of configuration files

Configuration files have an order of precedence when a client is reading configurations from an Ignite-UX server. The precedence is as follows:

1. The per-client configuration file (/var/opt/ignite/clients/<MAC>/config) —

Any variable set in the per-client config file takes precedence over any variable set anywhere else. Using the per-client config file in the preceding example, the cfg clause 2003-10-

08,12:45 Recovery Archive in the CINDEX file is selected no matter what the INDEX or CINDEX have set to TRUE. (This, of course, you can change this using the Ignite-UX Graphical

User Interface (GUI).)

2. The per-client CINDEX file (/var/opt/ignite/clients/<MAC>/CINDEX) —

This file contains recovery archive configurations. Any cfg clause set to TRUE in this file automatically selects that cfg clause if there is no per-client config file.

3. The global INDEX file (/var/opt/ignite/INDEX)—

This is the last file to have precedence. The default clause from the INDEX file is the one that is set to TRUE. (None of the cfg clauses in the INDEX file has been set to TRUE.)

Configu

ration also has an order of precedence when you are booting a system. The precedence is

as follows:

1. The first 8 KB of the installation file system has the highest precedence since it is the first

configuration read by Ignite-UX.

2. During media installations, if there is a LIF file called CUSTOM on any device, this file is loaded

and parsed after the configuration from the installation file system has been processed. Parsing the configuration after loading all other configurations means that it has the highest order of precedence (when booting from a CD or tape)

Testing the order of precedence

It is possible to test the order of precedence using the instl_dbg command:

# pwd /var/opt/ignite/clients/<MAC> # cat CINDEX ... cfg "2003-10-08,12:41 Recovery Archive" { description "Recovery Archive" "recovery/2003-10-08,12:41/system_cfg" "recovery/2003-10-08,12:41/control_cfg" "recovery/2003-10-08,12:41/archive_cfg" } cfg "2003-10-08,12:45 Recovery Archive" { description "Recovery Archive" "recovery/2003-10-08,12:45/system_cfg" "recovery/2003-10-08,12:45/control_cfg" "recovery/2003-10-08,12:45/archive_cfg" }=TRUE # manage_index -e -c "2003-10-08,12:41 Recovery Archive" \ > -i /var/opt/ignite/clients/box1/CINDEX # cat CINDEX ... cfg "2003-10-08,12:41 Recovery Archive" { description "Recovery Archive" "recovery/2003-10-08,12:41/system_cfg" "recovery/2003-10-08,12:41/control_cfg" "recovery/2003-10-08,12:41/archive_cfg" }=TRUE cfg "2003-10-08,12:45 Recovery Archive" { description "Recovery Archive" "recovery/2003-10-08,12:45/system_cfg" "recovery/2003-10-08,12:45/control_cfg" "recovery/2003-10-08,12:45/archive_cfg" }

So far, the CINDEX for this client has been changed so that the older recovery archive is the default archive. This is needed in order to show how precedence works. In the config file, the following cfg clause is selected:

# cat config cfg "2003-10-08,12:45 Recovery Archive"=TRUE _hp_cfg_detail_level="ipvs" ...

This feature is being considered for obsolescence. This part of the installation process is very time consuming for systems

with a very large number of disks.

You can now use the instl_dbg command to print out the fully parsed configuration (The –D option points it to a per-client directory containing the files it needs. The –f option designates where to write the parsed configuration). This will occur with and without the config file being present in the per-client directory:

# instl_dbg -D . -f /tmp/client.with.config # mv config config.save # instl_dbg -D . -f /tmp/client.with.no.config

With the per-client config file present, the cfg clause 2003-10-08,12:45 Recovery Archive is selected:

# head /tmp/client.with.config cfg "2003-10-08,12:45 Recovery Archive"=TRUE server="10.0.0.3" is_net_info_temporary=FALSE init _hp_keyboard="PS2_DIN_US_English" system_name="host" ip_addr[]="10.0.0.1" netmask[]="0xffffff00" route_gateway[0]="10.0.0.2" route_destination[0]="default" _hp_cfg_detail_level="ibnpvcdsrlLtfh" ...

Without the per-client config file present, the cfg clause is selected by the CINDEX file (200310-08,12:41 Recovery Archive) instead:

# head /tmp/client.with.no.config cfg "2003-10-08,12:41 Recovery Archive"=TRUE server="10.0.0.3" is_net_info_temporary=FALSE init _hp_keyboard="PS2_DIN_US_English" system_name="host" ip_addr[]="10.0.0.1" netmask[]="0xffffff00" route_gateway[0]="10.0.0.2" route_destination[0]="default" _hp_cfg_detail_level="ibnpvcdsrlLtfh" ...

The instl_dbg command is covered in more detail in a later section.

What is in a configuration (cfg) clause?

The question now is, what is in a cfg clause? The following example shows a cfg clause taken from the /var/opt/ignite/INDEX file:

The cfg clause needs the following information:

1. A name (for example, HP-UX B.11.11 Default)

2. A description (see the description keyword)

3. A list of one or more configuration files referenced by this cfg clause

4. One or more configuration files that define software that may be installed

When a cfg clause is selected (it has been set to TRUE and nothing of higher precedence changes this), its configuration files are processed in order and evaluated. This turns the set of configuration files into something that a client can use to install itself.

The make_net_recovery configuration files

A make_net_recovery session always creates the same configuration files, and you can see what they are by looking at a cfg clause in a CINDEX file:

cfg "2003-10-08,12:45 Recovery Archive" {

description "Recovery Archive" "recovery/2003-10-08,12:45/system_cfg" "recovery/2003-10-08,12:45/control_cfg" "recovery/2003-10-08,12:45/archive_cfg" }

The three configuration files are as follows:

1. system_cfg –-

This file is produced by the save_config command. It contains the file system layout, networking information, and hardware instance numbers for the system.

2. control_cfg –

This file contains definitions of Ignite-UX variables and the commands needed to import volume groups back into the final system.

3. archive_cfg –

This file contains the software definition of the archive that is used for recovery (including impacts keywords, etc.).

The CINDEX file provides a higher level of precedence than the INDEX file, so any cfg clause selected in the CINDEX file is used in preference to anything in the INDEX file in a non-interactive installation for a system. In an interactive installation, the recovery archive is automatically selected for installation so you can manually select another configuration for installation on the Basic tab in the Ignite-UX GUI.

The make_tape_recovery configuration files

The make_tape_recovery command still creates the same three configuration files that

make_net_recovery does. For example:

# pwd

This cfg clause is a default clause set up by Ignite-UX. This clause, as shown, does not have any configuration files that

define software to be installed. Therefore, it is incomplete and cannot be used to install a system.

/var/opt/ignite/recovery/2004-01-12,15:23 # ll *cfg

-rw-r--r-- 1 root sys 3032 Jan 12 15:24 archive_cfg

-rw-r--r-- 1 root sys 963 Jan 12 15:24 control_cfg

-rw-r--r-- 1 root sys 7223 Jan 12 15:24 system_cfg

The main diff

erence is that the three configuration files end up in a single LIF file on the tape when the recovery tape is created. The order of precedence here is unimportant since the tape is the only device used and all of the configuration files are concatenated together into one LIF file (CONFIG).

Files created by make_config

The make_config command is used to create configuration files that provide enough information to allow the installation of software bundles from Software Distributor (SD) depots. The make_config command is covered in a later section.

Using the manage_index command

A variety of uses

The manage_index command has many different options. This section describes every form the command can take, as well as its uses.

You should never manually maintain INDEX files. Instead, you should always use manage_index to maintain them. The manage_index command does not maintain any formatting or comments that may have been added to index files by an Ignite-UX administrator.

The following are all the forms defined in manage_index(1M):

manage_index -a -f config_filename [-c cfg_clause_name| -r release] [-p] [-v] [-i

manage_index -a -s script

manage_index -d -c [-i

manage_index -e -c cfg

manage_index -l -c [-i index_filename]

manage_index -l -o [-v] [-i index

manage_index -m [-i

manage_index -n [-i

manage_index -t -f [-p] [-v] [-i

index_filename]

_file_name [-p] [-v] [-i index_filename]

cfg_clause_name | -r release [-p] [-v]

_clause_name [-p] [-v] [-i index_filename]

cfg_clause_name | -r release ] [-o] [-v]

_filename]

old_clause_name -c new_clause_name [-p] [-v]

existing_clause_name -c new_clause_name [-p] [-v]

config_file_name [-c cfg_clause_name| -r release] index_filename]

manage_index -t -s script

manage_index -w -c cfg

manage_index -x -c cfg

Note:

The examples presented are for illustration purposes only; they show the intended purpose index files, and scripts.

of the command and use fictional configuration files,

_file_name [-p] [-v] [-i index_filename]

_clause_name [-v] [-i index_filename]

Although the –p (preview, make no changes) and –v (verbose) options are available to most or all forms of manage_index, they are not discussed with any of the examples.

Adding a configuration file to a clause or "release"

When you need to add a configuration file to a clause or release you need to use the –a option. The –i option must be given a fully qualified path if it is used (it cannot be relative).

manage_index -a -f config_filename [-c cfg_clause_name| -r release]

[-p] [-v] [-i

Neither the –c nor –r options are required. If you use the –c option, you can explicitly name the configuration clause to which to add the configuration file. If you use the –r option to give an HP-UX release identifier (for example, B.11.23), the configuration file will be added to each configuration clause that satisfies one of the following conditions:

index_filename]

 One of the configuration files in a cfg clause defines the release keyword with a value that

matches the release identifier given with the –r option.

 One of the configuration files in a cfg clause starts with the path

/var/opt/ignite/data/Rel_, and the value of the release identifier immediately after it matches the release identifier given with the –r option.

 One of the configuration files in a cfg clause starts with the path /opt/ignite/data/Rel_,

and the value of the release identifier immediately after it matches the release identifier given with the –r option.

Without the –c or –r option, the value of the release identifier is determined in the same way that clauses are matched with the –r option. The following, in order, is performed to try to determine the release identifier that will be used:

 The configuration file defines the release keyword, and the value of the release keyword provides

the value for the release identifier.

 The configuration file starts with the path /var/opt/ignite/data/Rel_, and the value of the

release identifier from this path provides the value for the release identifier.

 The configuration file starts with the path /opt/ignite/data/Rel_, and the value of the

release identifier from this path provides the value for the release identifier.

Once a relea command behaves as though it was given that release identifier with the –r option.

se identifier has been determined for the configuration file, the manage_index

In the following example, if you subsequently tried to add a configuration file based upon a release, it would not work because none of the configuration files contains an operating system release in their path names. However, you can add a file based upon a release if you first add the expected information in the path.

$ cat INDEX cfg "testing" { description "testing clause" } $ touch config_a config_b $ print "release=B.11.11" > config_c $ manage_index -a -f /var/tmp/config_c -c "testing" \ > -i /var/tmp/INDEX $ cat INDEX ... cfg "testing" { description "testing clause" "/var/tmp/config_c" }

The following example adds the configuration file /opt/ignite/data/Rel_B.11.11/config to the cfg clause that then enables you to add the configuration file /var/tmp/config_a.

manage_index -a -f /opt/ignite/data/Rel_B.11.11/config -c "testing" \ > -i /var/tmp/INDEX $ manage_index -a -f /var/tmp/config_a -r B.11.11 \ > -i /var/tmp/INDEX $ cat INDEX ... cfg "testing" { description "testing clause" "/var/tmp/config_c" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" }

Adding scripts to the INDEX file

As part of the syntax for configuration index files, there is a keyword called scripts, which enables you to define user-selectable scripts that can be run during installation and recovery:

manage_index -a -s script

The manage_index command with the –a and –s options allows you to add scripts into an INDEX file. For example:

$ manage_index -a -s /var/tmp/script_a \ > -i /var/tmp/INDEX $ cat INDEX …

This information is applicable to all forms of the manage_index command that need to search for or match release identifiers.

_file_name [-p] [-v] [-i index_filename]

scripts { "/var/tmp/script_a" }

On the Advanced tab in the Ignite-UX GUI, the sample script appears so it can be selected and run by a user. The scripts clause in the INDEX file is global in scope; scripts defined here are available for selection with any cfg clause in the INDEX file. You should be careful not to define scripts that make assumptions about the release they will be run on or are not portable across all HP-UX releases.

Removing cfg clauses from an INDEX file

The –d option is used to remove cfg clauses from an INDEX file using manage_index:

manage_index -d -c cfg_clause_name | -r release [-p] [-v] [-i index_filename]

The following example removes the cfg clause "testing two" from the INDEX file completely:

You can see that the cfg clause "testing two" has been removed from the INDEX file:

$ cat INDEX... cfg "testing" { description "testing clause" "/var/tmp/config_c" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a"

The –r option operates on all cfg clauses applicable to a release identifier. If you reference cfg clauses by release, you need to be careful. In the following example, both cfg clauses have a release identifier that matches B.11.11, so both are removed from the INDEX file.

$ cat INDEX.save ... cfg "testing" { description "testing clause" "/var/tmp/config_c" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" }

cfg "testing two" { description "testing clause" "/var/tmp/config_c" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" } $ manage_index -d -r B.11.11 -i /var/tmp/test/INDEX $ cat INDEX ...

Setting the default cfg clause in an INDEX file

Using the following command, you can easily set which of the cfg clauses in an INDEX file is the default cfg clause:

manage_index -e -c cfg

The following example changes the default cfg clause between two different cfg clauses:

$ cat INDEX ... cfg "testing" { description "testing clause" "/var/tmp/config_c" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" } cfg "testing two" { description "testing clause" "/var/tmp/config_c" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" } $ manage_index -e -c "testing" -i /var/tmp/INDEX $ cat INDEX ... cfg "testing" { description "testing clause" "/var/tmp/config_c" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" }=TRUE cfg "testing two" { description "testing clause" "/var/tmp/config_c" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" } $ manage_index -e -c "testing two" -i /var/tmp/INDEX $ cat INDEX ... cfg "testing" { description "testing clause" "/var/tmp/config_c" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" } cfg "testing two" { description "testing clause" "/var/tmp/config_c"

_clause_name [-p] [-v] [-i index_filename]

"/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" }=TRUE

Listing the names of cfg clauses in an INDEX file

The following syntax for the manage_index command lists the names of all of the cfg clauses in an

INDEX file:

manage_index -l -c cfg_clause_name | -r release ] [-o] [-v] [-i index_filename]

For example:

Being able to list the cfg clauses also makes it easier to script Ignite-UX tasks. An example of this could be a sanity-checking script that ensures all of the configuration files referenced from within cfg clauses exist and are readable.

Such a script might look like:

#!/usr/bin/sh /opt/ignite/bin/manage_index -l | while read CFG do { eval /opt/ignite/bin/manage_index -w -c \"${CFG}\" | while read FILE do if [[ ! -f $FILE ]] then print -u2 "Error: file $FILE does not exist" fi if [[ ! -r $FILE ]] then print -u2 "Error: file $FILE is not readable" fi done } done

Note that this script is a trivial example. The instl_adm command with the –T option would perform these tasks as well as sanity-check the

syntax within the configuration files.

Listing the name of the default cfg clause in an INDEX file

This form of the manage_index command enables you to see which cfg clause is the current default cfg clause:

manage_index -l -o [-v] [-i index

For example:

_filename]

Renaming a cfg clause in an INDEX file

The following form of manage_index enables you to rename a cfg clause. (This may be useful when you need to swap two clauses.)

manage_index -m old_clause_name -c new_clause_name [-p] [-v] [-i index_filename]

The following example swaps two cfg clauses:

$ manage_index -l -i /var/tmp/INDEX testing testing two $ manage_index -m "testing two" -c "t two" -i /var/tmp/INDEX $ manage_index -l -i /var/tmp/INDEX testing t two $ manage_index -m "testing" -c "testing two" -i /var/tmp/INDEX $ manage_index -l -i /var/tmp/INDEX testing two t two $ manage_index -m "t two" -c "testing" -i /var/tmp/INDEX $ manage_index -l -i /var/tmp/INDEX testing two testing

Creating a new cfg clause from an existing clause

Using the following form of manage_index, you can easily to create a new cfg clause from an existing clause:

manage_index -n existing_clause_name -c new_clause_name [-p] [-v] [-i index_filename]

For example:

$ manage_index -n "testing" -c "old testing two" -i /var/tmp/INDEX $ manage_index -l -i /var/tmp/INDEX testing two testing old testing two

Removing a configuration file from a cfg clause

Earlier you learned how to add a configuration file to a clause. Now you can do the opposite, which is to remove configuration files from cfg clauses:

manage_index -t -f config_file_name [-c cfg_clause_name| -r release] [-p] [-v] [-i

In the following example, a configuration file is removed from a cfg clause and then, a file is removed from all of the cfg clauses for one release:

$ cat INDEX ... cfg "testing two" { description "testing clause" "/var/tmp/config_c" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" } cfg "testing" { description "testing clause" "/var/tmp/config_c" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" }=TRUE cfg "old testing two" { description "testing clause" "/var/tmp/config_c" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" } $ manage_index -t -f "/opt/ignite/data/Rel_B.11.11/config" -c "testing" \ > -i /var/tmp/INDEX $ cat INDEX ... cfg "testing two" { description "testing clause" "/var/tmp/config_c" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" }

index_filename]

cfg "testing" { description "testing clause" "/var/tmp/config_c" "/var/tmp/config_a" }=TRUE cfg "old testing two" { description "testing clause" "/var/tmp/config_c" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" }

In the previous example, you removed a specific configuration file from the cfg clause “testing”. The following example removes config_c from all B.11.11 clauses:

$ manage_index -t -f /var/tmp/config_c -r B.11.11 \ > -i /var/tmp/INDEX $ cat INDEX ... cfg "testing two" { description "testing clause" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" } cfg "testing" { description "testing clause" "/var/tmp/config_c" "/var/tmp/config_a" }=TRUE cfg "old testing two" { description "testing clause" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" }

The cfg clause "testing" is not modified in this example. Earlier in the section Adding a configuration file to a clause or "release" on page 6, we discussed how manage_index associates a release identifier with a cfg c

lause. The configuration files associated with the cfg clause

“testing” no longer meets any of the conditions that allows manage_index to determine a release identifier. Since no release identifier could be determined, the configuration file /var/tmp/config_c was not removed from the cfg clause.

Important:

A cfg clause must have a release keyword in one files associated with it.

of the configuration

Removing a script from an INDEX file

Earlier you learned how to add a script into the configuration so that it appears on the Advanced tab in the Ignite-UX GUI. You use the following form of the command to remove the script:

manage_index -t -s script

The following example adds a script and then removes it:

_file_name [-p] [-v] [-i index_filename]

$ manage_index -a -s /var/tmp/script_a -i /var/tmp/INDEX $ cat INDEX ... cfg "testing two" { description "testing clause" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" } cfg "testing" { description "testing clause" "/var/tmp/config_c" "/var/tmp/config_a" }=TRUE cfg "old testing two" { description "testing clause" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" } scripts { "/var/tmp/script_a" } $ manage_index -t -s /var/tmp/script_a -c "testing" \ > -i /var/tmp/INDEX $ cat INDEX cfg "testing two" { description "testing clause" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a" } cfg "testing" { description "testing clause" "/var/tmp/config_c" "/var/tmp/config_a" }=TRUE cfg "old testing two" { description "testing clause" "/opt/ignite/data/Rel_B.11.11/config" "/var/tmp/config_a"

}

Files (or in this case a script) must exist before they can be removed (or added) with

manage_index. This applies to configuration files as well as scripts.

$ manage_index -a -s /var/tmp/script_a -i /var/tmp/INDEX ERROR: Cannot read script file: /var/tmp/script_a ERROR: No read access to file specified by -f

List the names of all configuration files in a cfg clause

The following command enables you to list all the configuration files named in a cfg clause:

manage_index -w -c cfg_clause_name [-v] [-i index_filename]

For example:

$ manage_index -w -c "testing" -i /var/tmp/INDEX /var/tmp/config_c /var/tmp/config_a

In conjunction with the earlier form of manage_index used to list out the names of cfg clauses in an INDEX file, the preceding command can be used to ensure that all of the configuration files referenced in an INDEX file are present and, as far as can be determined, correct.

Display the description of a cfg clause

This last form of manage_index is used to display the description of the cfg clause:

manage_index -x -c cfg

_clause_name [-v] [-i index_filename]

For example:

$ manage_index -x -c "testing" -i /var/tmp/INDEX testing clause

Using the make_bundles command

Why do you need to use make_bundles?

The make_bundles command is necessary when using Ignite-UX because commands like make_config only work with software that is contained within a bundle. Therefore, if you create a configuration file for a depot and it contains software that is packaged only as an SD product, it is not listed in a configuration file created by make_config.

Choosing which form of make_bundles to use

The make_bundles command has the following three forms:

/opt/ignite/bin/make_bundles {-b|-B} [-i] [-n name] [-t title] [-c

category] [-o psf] [-r revision] depot_path

/opt/ignite/bin/make_bundles [-b] [-p|-f] [-i] [-c category] [-o psf]

depot_path

/opt/ignite/bin/make_bundles {-p|-f|-B} [-i] [-c category] [-o psf] [-l

The make_bundles command is primarily controlled by the –B or –b options. causes make_bundles to operate on all product filesets The –B option causes all product filesets in the depot (or those given on the command line) to be operated on regardless of whether they are currently in a bundle or not. The different forms of the make_bundles command, which are covered in this section, create either one or many bundles. Each form has advantages over the other forms depending on what you want to achieve.

In some forms of make_bundles, the use of –b or –B is optional. However, in the most useful forms of the make_bundles command, you

will almost always use one or the other option.

You cannot have a standalone fileset because it must be contained within a product.

If you perform a swlist operation on a depot, the default output shows all bundles in the depot followed by all products not contained

within a bundle. The–b option operates only on products not contained within a bundle.

file| product/fileset...] depot_path

that are not contained within a bundle.9

The –b option

You ca

n use the –b option when you want to operate on all of the unbundled product filesets in a

depot and the –B if you want to operate on all product filesets within a depot. You can use the –p and –f options to modify what the –b option does (although you cannot use

them with the –B option). The –p option creates one bundle for every product in the depot, making –B unnecessary. When used with the –b option, the command only processes products that are not already contained within a bundle. The –f option has a similar function to –p but it operates at the fileset level; that is, when you use –f it causes a bundle to be created for all filesets in the depot (except when –b is used as well; then only filesets in products not already contained with a bundle are processed).

The form of make_bundles that you use depends upon what you want to do with it. The following sections demonstrate what can be done with three forms of the command.

The make_bundles first form

The first form of make_bundles uses –b or –B and not –p or –f, so you can operate either on all unbundled product filesets or on all product filesets. This form, however, can only create one bundle wrapper.

/opt/ignite/bin/make_bundles {-b|-B} [-i] [-n name] [-t title] [-c

category] [-o psf] [-r revision] depot_path

With the addition of the –i option, you can set the is_reference SD bundle attribute to TRUE. When set to TRUE, the is_reference causes the bundle wrapper to be installed whenever a product or fileset within a bundle is installed. When set to FALSE, the bundle wrapper is installed only when selected. HP-UX patch bundles always have the is_reference set to TRUE because they can then be installed with either patch_match_target or autoselect_patches set to TRUE. In contrast, if is_reference is set to FALSE, the bundle wrapper for the the HP-UX patch bundle would not be installed with the patches since SD selects patches to be installed, not bundles (leaving the patches unbundled after installation). This allows the bundle wrapper to be automatically installed when patches have been automatically selected for installation by SD. (This can happen if there are software bundles in the same depot as the patches that are installed, and the patches are for filesets in the bundles.)

Important:

You should always use the –i option when defining bundles that contain patches so t the bundle is installed.

hat the bundle definition is installed when any patch from

With the –n option, you can give the bundle a name, which must be 16 characters or fewer. With the –t option, you can give a longer descriptive title for the bundle, which must be 256 characters or fewer and can only contain one line. With the –c option you can assign a category to the bundle; the default, if not given, is to make the bundle uncategorized. See the section "Categories and other Ignite-UX software attribu

With the –o option, make_bundles writes ou

tes" on page 118 for more information on software categories.

t a Product Specification File (PSF) instead of

modifying the target depot. This option is useful if you need to make customizations to the PSF before applying the changes to the depot. The PSF contains the swpackage command required to

pac

kage the bundle in the depot. The example swpackage command contains the path given to

PSF “as is”. You may need to change the path to the PSF file in the example if you change your current working directory or move the PSF file.

With the –r option, you can specify a revision for a bundle. This allows you to create bundle wrappers with revision numbers, enabling you to better manage changes to software.

The examples in this section operate on the following depot:

# swlist -d @ /var/opt/ignite/depots/Rel_B.11.23/patches # Initializing... # Contacting target "test"... # # Target: test:/var/opt/ignite/depots/Rel_B.11.23/patches #

# # No Bundle(s) on test:/var/opt/ignite/depots/Rel_B.11.23/patches # Product(s): #

PHCO_31622 1.0 Cumulative changes to frecover(1M) PHCO_31634 1.0 Cumulative changes to pax(1) PHCO_33431 1.0 tar(1) catalogs ; directory timestamp PHCO_36056 1.0 find(1) cumulative patch

Because there are no existing bundles, using the –b option or the –B options achieves the same result.

The following example bundles all the patches:

# make_bundles -b -i -n "PB_Sept_2007" \ > -t "backup commands patches for Sept 2007" \ > -r 1.0 /var/opt/ignite/depots/Rel_B.11.23/patches Generating list of unbundled filesets...

======= 08/30/07 16:25:12 EST BEGIN swpackage SESSION

* Session started for user "root@test".

* Source: test:/var/tmp/psf.28120 * Target: test:/var/opt/ignite/depots/Rel_B.11.23/patches * Software selections: *

* Beginning Selection Phase. * Reading the Product Specification File (PSF) "/var/tmp/psf.28120". * Reading the bundle "PB_Sept_2007" at line 11.

* Selection Phase succeeded.

* Beginning Analysis Phase. * Analysis Phase succeeded.

* Beginning Package Phase.

* Packaging the bundle

"PB_Sept_2007,r=1.0,a=HP-UX_B.11.23_IA/PA,v=HP". * Package Phase succeeded.

======= 08/30/07 16:25:13 EST END swpackage SESSION With swlist, you can verify that all of the patches are now contained within the bundle:

# swlist -d @ /var/opt/ignite/depots/Rel_B.11.23/patches # Initializing... # Contacting target "test"... # # Target: test:/var/opt/ignite/depots/Rel_B.11.23/patches #

# # Bundle(s): #

PB_Sept_2007 1.0 backup commands patches for Sept 2007

To continue the example, assume you missed a patch from the bundle that you created and you still need to add it in. In this case, you need to use the –B option in a similar command to what was used to create the bundle initially. Therefore, after you copy in the latest ls patch PHCO_33976, you have the following in the depot:

# swlist -d @ /var/opt/ignite/depots/Rel_B.11.23/patches # Initializing... # Contacting target "test"... # # Target: test:/var/opt/ignite/depots/Rel_B.11.23/patches #

# # Bundle(s): #

PB_Sept_2007 1.0 backup commands patches for Sept 2007 # # Product(s) not contained in a Bundle: #

PHCO_33976 1.0 ls(1) cumulative patch

You can then run make_bundles again10 but this time we can’t use the –b option because we want all of the patches in the depot to be placed into the bundle. To do that we need to use the –B option instead, as –b only operates on product filesets not currently in a bundle.

make_bundles -B -i -n "PB_Sept_2007" \ > -t "backup commands patches for Sept 2007" \ > -r 1.1 /var/opt/ignite/depots/Rel_B.11.23/patches

======= 08/30/07 16:40:40 EST BEGIN swpackage SESSION

* Session started for user "root@test".

The reason for specifying -r 1.1 is to identify a collection of patches by a unique bundle specification composed of the bundle name and revision. Revision 1.0 of the bundle PB_July_2004 does not include PHCO_30150; revision 1.1 does include PHCO_30150. If the option -r 1.0 were specified, the original bundle would be replaced.

* Source: test:/var/tmp/psf.28291 * Target: test:/var/opt/ignite/depots/Rel_B.11.23/patches * Software selections: *

* Beginning Selection Phase. * Reading the Product Specification File (PSF) "/var/tmp/psf.28291". * Reading the bundle "PB_Sept_2007" at line 11.

* Selection Phase succeeded.

* Beginning Analysis Phase. * Analysis Phase succeeded.

* Beginning Package Phase.

* Packaging the bundle "PB_Sept_2007,r=1.1,a=HP-UX_B.11.23_IA/PA,v=HP". * Package Phase succeeded. ======= 08/30/07 16:40:41 EST END swpackage SESSION

Now the depot lists two revisions of the bundle:

# swlist -d @ /var/opt/ignite/depots/Rel_B.11.23/patches # Initializing... # Contacting target "test"... # # Target: test:/var/opt/ignite/depots/Rel_B.11.23/patches #

# # Bundle(s): #

PB_Sept_2007 1.0 backup commands patches for Sept 2007 PB_Sept_2007 1.1 backup commands patches for Sept 2007

By looking at the filesets for revision 1.1 or PB_Sept_2007,you can also verify that the new bundle was created with the correct contents:

swlist -d -l fileset PB_Sept_2007,r=1.1 @ /var/opt/ignite/depots/Rel_B.11.23/patches # Initializing... # Contacting target "test"... # # Target: test:/var/opt/ignite/depots/Rel_B.11.23/patches #

# PB_Sept_2007 1.1 backup commands patches for Sept 2007 # PB_Sept_2007.PHCO_31622 1.0 Cumulative changes to frecover(1M) PB_Sept_2007.PHCO_31622.SYS-ADMIN 1.0 OS-Core.SYSADMIN ... PB_Sept_2007.PHCO_31634.UX2-CORE 1.0 OS-Core.UX2-CORE PB_Sept_2007.PHCO_31634.UX2-CORE 1.0 OS-Core.UX2-CORE

In the precedi

ng example, note that most of the output is not shown. If you wanted the ls patch

PHCO_33976 to have its own wrapper bundle, you could have instead used –b and changed the bundle name, revision, and so forth and created a new bundle to hold the patch.

The following example demonstrates what happens when you use the –o option to create a PSF. It also shows how you can then use the PSF with swpackage to implement the changes yourself. Before creating the PSF however we need to remove the existing bundle wrappers since they will prevent the PSF from being created with the –b option:

# swmodify -u -d PB_Sept_2007,r=\* @ /var/opt/ignite/depots/Rel_B.11.23/patches

Now we can create the PSF file.

# make_bundles -b -i -n "PB_Sept_2007" \

> -t "backup commands patches for Sept 2007" \ > -o ./PB-Sept_2007.psf -r 1.0 \ > /var/opt/ignite/depots/Rel_B.11.23/patches Generating list of unbundled filesets... # ll ./PB-Sept_2007.psf

-rw-r--r-- 1 root sys 1011 Aug 30 16:53 ./PB-Sept_2007.psf

The PSF contains all of the information needed to create the bundle and the swpackage command needed to create the bundle.

# cat PB-Sept_2007.psf ################################################################# # swpackage product specification file generated by make_bundles # on Thu Aug 30 16:53:26 EST 2007. For depot: /var/opt/ignite/depots/Rel_B.11.2 3/patches # # To run swpackage to apply the bundle definitions to the # depot, use the command: # # swpackage -s ./PB-Sept_2007.psf -xlayout_version=1.0 xreinstall_files=true

-d /var/opt/ignite/depots/Rel_B.11.23/patches # ################################################################# bundle tag PB_Sept_2007 title backup commands patches for Sept 2007 os_name HP-UX is_reference true revision 1.0 architecture HP-UX_B.11.23_IA/PA vendor_tag "HP" contents PHCO_31622,r=1.0,a=HP-UX_B.11.23_IA/PA,v=HP,fr=1.0 contents PHCO_31634,r=1.0,a=HP-UX_B.11.23_IA/PA,v=HP,fr=1.0 contents PHCO_33431,r=1.0,a=HP-UX_B.11.23_IA/PA,v=HP,fr=1.0 contents PHCO_33976,r=1.0,a=HP-UX_B.11.23_IA/PA,v=HP,fr=1.0 contents PHCO_36056,r=1.0,a=HP-UX_B.11.23_IA/PA,v=HP,fr=1.0 end

You can then package the bundle manually:

Getting the make_bundles command to produce a PSF also means that the file can be kept in a source management system so changes can be tracked and monitored. Because the PSF can be checked out, the same configuration can be validated and recreated at will.

# swpackage -s ./PB-Sept_2007.psf -xlayout_version=1.0 \ > -xreinstall_files=true -d /var/opt/ignite/depots/Rel_B.11.23/patches

======= 08/30/07 16:55:31 EST BEGIN swpackage SESSION

* Session started for user "root@test ".

* Source: test:./PB-Sept_2007.psf * Target: test:/var/opt/ignite/depots/Rel_B.11.23/patches * Software selections: *

* Beginning Selection Phase. * Reading the Product Specification File (PSF) "./PB-Sept_2007.psf". * Reading the bundle "PB_Sept_2007" at line 11.

* Selection Phase succeeded.

* Beginning Analysis Phase. * Analysis Phase succeeded.

* Beginning Package Phase.

* Packaging the bundle "PB_Sept_2007,r=1.0,a=HP-UX_B.11.23_IA/PA,v=HP". * Package Phase succeeded.

======= 08/30/07 16:55:31 EST END swpackage SESSION

This new revision 1.0 bundle is the same as the previous 1.1 bundle since we did not remove the ls patch from the depot.

Running make_bundles with the –B option to repackage the bundle has the same effect:

# make_bundles -B -i -n "PB_ Sept_2007" \ > -t "backup commands patches for Sept 2007" \ > -r 1.0 /var/opt/ignite/depots/Rel_B.11.23/patches

The make_bundles second form

The second form of make_bundles uses the –b option. The –b option causes make_bundles to operate on all products and filesets that are not contained within a bundle.

/opt/ignite/bin/make_bundles [-b] [-p|-f] [-i] [-c depot_path

category] [-o psf]

The –p and –f options specify that multiple bundles are to be created.

 If –p is specified and –b is not, a bundle is created for each product in the depot.  If both –p and –b are specified, a bundle is created for every product in the depot which does

not already belong to a bundle.

 If –f is specified and –b is not, a bundle is created for each fileset in the depot.  If both –f and –b are specified, a bundle is created for each fileset in the depot which does not

already belong to a bundle.

The –i, -c, a

llowing examples show what happens when you use the –p and –f options with the

The fo

nd –o options are discussed in the "The make_bundles first form" section.

make_bundles command. These examples do not have a depot with any bundles, so the–b option has no effect.

The first example uses the –p option to show bundles being produced at the product level:

======= 08/31/07 14:24:04 EST BEGIN swpackage SESSION

* Session started for user "root@test ".

* Source: test:/var/tmp/psf.29896 * Target: test:/var/opt/ignite/depots/Rel_B.11.23/patches * Software selections: *

* Beginning Selection Phase. * Reading the Product Specification File (PSF) "/var/tmp/psf.29896". * Reading the bundle "b_PHCO_31622" at line 11. * Reading the bundle "b_PHCO_31634" at line 20. * Reading the bundle "b_PHCO_33431" at line 29. * Reading the bundle "b_PHCO_33976" at line 38. * Reading the bundle "b_PHCO_36056" at line 47.

* Selection Phase succeeded.

* Beginning Analysis Phase. * Analysis Phase succeeded.

* Beginning Package Phase.

* Packaging the bundle "b_PHCO_31622,r=1.0,a=HP-UX_B.11.23_IA/PA,v=HP". * Packaging the bundle "b_PHCO_31634,r=1.0,a=HP-UX_B.11.23_IA/PA,v=HP". * Packaging the bundle "b_PHCO_33431,r=1.0,a=HP-UX_B.11.23_IA/PA,v=HP". * Packaging the bundle "b_PHCO_33976,r=1.0,a=HP-UX_B.11.23_IA/PA,v=HP". * Packaging the bundle "b_PHCO_36056,r=1.0,a=HP-UX_B.11.23_IA/PA,v=HP". * Package Phase succeeded.

======= 08/31/07 14:24:05 EST END swpackage SESSION

The preceding example covers packaging of all the patches in the depot that are not already part of the bundle. The command would have to be modified to replace –b with –B to package every

patch

into a bundle.

Next, the same command is used but with the –f option instead of –p. Since the –b option only operates on unbundled filesets, the previously existing bundle wrappers were removed before the command was run. All of the bundle names are produced at the fileset level:

Actually every product would be placed into an individual bundle if the –B option was used instead of –b, that is it would not just apply to

patches.

# make_bundles -b -f -i /var/opt/ignite/depots/Rel_B.11.23/patches Generating list of unbundled filesets... Generating swpackage PSF...

======= 08/31/07 14:30:41 EST BEGIN swpackage SESSION

* Session started for user "root@test ".

* Source: test:/var/tmp/psf.29995 * Target: test:/var/opt/ignite/depots/Rel_B.11.23/patches * Software selections: *

* Beginning Selection Phase. * Reading the Product Specification File (PSF) "/var/tmp/psf.29995". * Reading the bundle "b_PHCO_31622_SYS" at line 11. * Reading the bundle "b1_PHCO_31622_SY" at line 20. ... * Reading the bundle "b1_PHCO_36056_CM" at line 299. * Reading the bundle "b_PHCO_36056_CMI" at line 308.

* Selection Phase succeeded.

* Beginning Analysis Phase. * Analysis Phase succeeded.

* Beginning Package Phase.

* Packaging the bundle "b10_PHCO_33431_U,r=1.0,a=HP-UX_B.11.23_IA/PA,v=HP". * Packaging the bundle "b11_PHCO_33431_U,r=1.0,a=HP-UX_B.11.23_IA/PA,v=HP". ... * Packaging the bundle "b_PHCO_36056_CMD,r=1.0,a=HP-UX_B.11.23_IA,v=HP". * Packaging the bundle "b_PHCO_36056_CMI,r=1.0,a=HP-UX_B.11.23_IA/PA,v=HP". * Package Phase succeeded.

======= 08/31/07 14:30:44 EST END swpackage SESSION

Note:

The preceding example merely demonstrates ho patches need to be installed fully at the product level, not at the fileset level. You should not package and attempt to install patches in this way.

w the –f option works -

The make_bundles third form

The third form of make_bundles uses –p, -f, or –B (all optional) with either a list of products and filesets or a list contained in a file given with the –l option to process. This form of make_bundles gives you improved control over exactly what is packaged into a bundle regardless of what fileset in which it may already be bundled.

/opt/ignite/bin/make_bundles {-p|-f|-B } [-i] [-c category] [-o psf]

file| product/fileset...] depot_path

[-l

Note:

With this form of the command you cannot give the bundles you are creating a na the –o option to create a PSF that can be used for subsequent packaging.

me. The most useful form of this command involves giving

In this example, you create some of the same bundles that were created in previous examples. However, this time you use an explicit list of products to include (or patches in this case):

# make_bundles -B -i -o ./PB_Sept_2007_1.0.psf -r 1.0 PHCO_31622 \ > PHCO_31634 PHCO_33431 PHCO_36056 \ > /var/opt/ignite/depots/Rel_B.11.23/patches # ll ./PB_Sept_2007_1.0.psf

-rw-r--r-- 1 root sys 951 Aug 31 16:46 ./PB_Sept_2007_1.0.psf

Next, you create another PSF but this time with the extra pax patch PHCO_33967:

# make_bundles -B -i -o ./PB_Sept_2007_1.1.psf -r 1.1 PHCO_31622 \ > PHCO_31634 PHCO_33431 PHCO_36056 PHCO_33976 \ > /var/opt/ignite/depots/Rel_B.11.23/patches # ll ./PB_Sept_2007_1.1.psf

-rw-r--r-- 1 root sys 1015 Aug 31 16:47 ./PB_Sept_2007_1.1.psf

You can now apply the commands stored in these two PSF files against the depot. When you do, you end up with the same results as with the make_bundles first form:

# swlist -d @ /var/opt/ignite/depots/Rel_B.11.23/patches # Initializing... # Contacting target "test"... # # Target: test:/var/opt/ignite/depots/Rel_B.11.23/patches #

# # Bundle(s): #

patches 1.1 /var/opt/ignite/depots/Rel_B.11.23/patches patches 1.0 /var/opt/ignite/depots/Rel_B.11.23/patches

With the third form, you cannot specify an explicit name. You must edit the PSF to change the name of the bundle.

Tip:

If you use change control it is better to generate a PSF and place it under cha temporary PSF and apply the changes to the depot. By placing the PSF in your change process, you know exactly how a bundle wrapper in a depot was created and what was in it. This allows you to, at some later time, recreate bundles exactly as they were before.

nge control than to use make_bundles to generate a

Using the instl_dbg command

Introduction

The instl_dbg command is often overlooked but offers valuable functionality in testing the effect of a change in a configuration file. This section introduces some of the useful functionality of instl_dbg and how it can be combined with the itool command to rapidly prototype and test configuration changes.

Requirements

The instl_dbg command requires some information that can only be created during an installation session either by adding a new client to an Ignite-UX server, by running make_net_recovery, or by running make_tape_recovery with the –s option. The files that are most needed are hw.info

/opt/ignite/bin/instl_dbg -D client_directory [-f file] [-v] [-a {l|r}] [-cdls|-A] [-V var[=value]] [-S swsel[=TRUE|=FALSE]] [-U use_model[=TRUE|=FALSE]] [-?]

The one command-line option required by instl_dbg is the –D option. This would usually point to a per-client directory on an Ignite-UX server. It must contain all of the information that instl_dbg needs to run. If you add a new client to an Ignite-UX server, the information you need is created automatically. However, this does not help when you have a new client that has never had an operating system installed.

, host.info, and config.sys.

Using the itool command

The itool command provides the Wizard and Advanced interfaces during recovery and installation. It is not well known that the itool command can be run from the command line on an Ignite-UX server to manipulate the configuration for a client. The itool command accepts the following options

# itool -? itool: illegal option -- ? usage itool [ arguments ]

-d <directory path>

-i <client name>

-m 'demo', 'push', 'pull', 'quick', or 'wiz'

-w show welcome screen in push mode (The default is -m pull)

The only method you really need to worry about when using itool is as follows:

# itool –d <client dir> -m pull

As of Ignite-UX C.7.0 the io.info file is also required.

HP does not recommend the use of itool outside of its normal use (running on a client system during installation or recovery or via the Ignite user interface).ignite(1)). This information is presented here so itool can be run in conjunction with instl_dbg for rapid prototyping of configurations.

This r

uns the itool user interface as though it were running on the client system.

You must run

itool as root.

Important:

Do not change time-related information in the Ignite-UX GUI unless the

you are on is considered non-production; altering the time

system information changes the system clock.

Configuration changes are saved into the configuration file in the per-client directory. When exiting itool, there is no need for concern with respect to the list of options it presents; no

action should be taken for any of them. The different options set a different return code from itool. The return code is how itool communicates the next action to the program that calls it when it is running during a normal installation or recovery.

Combining instl_dbg and itool

If a configuration file (a file named config) exists in the client directory, its configuration information is used (for example, which cfg clause) instead of the default. This is the reason the itool program was discussed in the previous section.

When you use itool to change configurations and then run instl_dbg to see what is happening in the configurations, it makes it possible to test configurations and changes without having to boot a system and attempt to install the system.

Running instl_dbg in this way enables you to see the configuration the way Ignite-UX parses it on that client.

Running instl_dbg

You can use instl_dbg to test some aspects of your configuration; for instance, with the –c option you can perform system configuration sanity checks. In the following example, it is assumed that you have changed working directories to a per-client directory on an Ignite-UX server (/var/opt/ignite/clients/<MAC>).

# instl_dbg -D . -c

======= System Configuration Checks ====== WARNING: The disk at: 0/8/0/0.2.0 (SEAGATE_ST39173WC) appears to contain a file system and boot area. Continuing the installation will destroy any existing data on this disk.

The –c option allows you to see configuration check messages that would normally only be seen during an installation or recovery session. This allows you to preview what you will see during an installation or recovery session.

When an installation is controlled from the server, itool is actually run on the server. However, it is run with the –m push option since configuration changes are pushed to the client system.

With the –d option, you ca

n get instl_dbg to print out the expected size of the volumes it creates

and what the impacts are for each file system. The expected output of percent (%) used is also shown with the file system type. If the disk does not contain enough space, the amount shy (KB) column indicates the additional space needed.

# instl_dbg -D . -d ======= Disk and Volume allocation ====== Mount Size Usage Disk / impact amount Directory (Mb) Group (MB / %) shy (KB)

---------------------------------------------------------------------/stand 300 HFS vg00 21 7% 0 (swap_dump) 1280 SWAP_DUMP vg00 0 0% 0 / 200 VxFS vg00 92 46% 0 /tmp 200 VxFS vg00 0 0% 0 /home 20 VxFS vg00 0 0% 0 /opt 976 VxFS vg00 723 74% 0 /usr 1296 VxFS vg00 1035 79% 0 /var 1780 VxFS vg00 229 12% 0

---------------------------------------------------------------------Size unallocated from group: vg00: 2624Mb * Expected physical allocation of volumes on disks: * 0/8/0/0.2.0 (/dev/dsk/c0t2d0) (vg00) * 3997 - 311197 KB /stand * 311197 - 1621917 KB primary * 1621917 - 1826717 KB / * 1826717 - 2031517 KB /tmp * 2031517 - 2051997 KB /home * 2051997 - 3051421 KB /opt * 3051421 - 4378525 KB /usr * 4378525 - 6201245 KB /var * 2686976 KB unallocated

The –l option to instl_dbg performs some lint type checks on the configuration. Variables that are not assigned with the init keyword appear as follows:

# instl_dbg -D . -l ... ******* Variables assigned without init keyword ******* * _my_variable

Note:

Every variable used in an Ignite-UX configuration initialized using the init keyword. If you do not want the variable to be changed, use the visible_if keyword to prevent it from being displayed by the Ignite-UX GUI. (See instl_adm(1M) for more information about the init and visible_if keywords.)

# instl_dbg -D . -l

======= Lint-type Checks =======

******* Variables assigned without init keyword ******* All variables assigned with the init keyword.

file should be

With the –s option, the value of all varia

bles, sw_sel objects, and usage models are shown.

The information is quite detailed. From the information for sw_sel objects, you can tell if sw_sel has been selected, if it has been selected because of a dependency, or if it has been unselected because of an exrequisite.

The variable information provides the name of the variable, the value that it holds, the type of variable, and whether the variable is visible (based on the setting of visible_if). If the variable has an "effects" relationship, the name of the variable it has a relationship with is shown, and if the variable has a list of potential values, the list of values is shown.

For use models, the name is shown and whether it is selectable, selected, or visible.

# instl_dbg -D . -s

======= Software Selection Attributes: ====== sw_sel name: "100BaseT-01" description: "HP-PB 100BaseT;Supptd HW=A3495A;SW=J2759BA" selected: 0 dep_selected: 0 ex_unselected: 0 is_defined: 1

sw_sel name: "100BaseT-00" description: "" selected: 0 dep_selected: 0 ex_unselected: 0 is_defined: 1 ... sw_sel name: "perl" description: "Perl Programming Language" selected: 0 dep_selected: 1 ex_unselected: 0 is_defined: 1

======= Variable Attributes: ====== Variable name: "_hp_boot_dev_path" value: "0/8/0/0.2.0" type: string visible: 0

Variable name: "_hp_default_cur_lan_dev" value: "lan5" type: string visible: 0 ... Variable name: "_hp_disk_layout" value: "Logical Volume Manager (LVM) with VxFS" type: string visible: 0 val_list[0]: "Whole disk (not LVM) with HFS" val_list[1]: "Logical Volume Manager (LVM) with HFS" val_list[2]: "Logical Volume Manager (LVM) with VxFS" val_list[3]: "VERITAS Volume Manager (VxVM) with VxFS" Effects var: _hp_pri_swap Effects var: _hp_group_name

Variable name: "_hp_root_disk" value: "0/8/0/0.2.0"

type: string visible: 0 Effects var: _hp_pri_swap Effects var: _hp_min_swap Effects var: _hp_disk_layout Effects var: _hp_root_grp_disks ... ======= Use-Model Attributes: ====== Use model name: "Create /export volume" selected: 0 selectable: 1 visible: 1

Use model name: "Create separate volumes (/usr, /var, ...)" selected: 1 selectable: 1 visible: 1

Using the –f option, the instl_dbg command also provides a completely parsed version of the configuration. This output builds on top of the configuration files parsed on the system. In this case, the configuration was modified using the Ignite-UX GUI before running instl_dbg:

# instl_dbg -D . -f ./parsed.output # cat parsed.output cfg "HP-UX B.11.11 Default"=TRUE server="10.0.0.60" is_net_info_temporary=FALSE init _hp_keyboard="Not_Applicable" system_name="spectre" netmask["lan0"]="255.255.255.0" ip_addr[]="10.0.0.162" netmask[]="255.255.255.0" route_gateway[0]="10.0.0.1" route_destination[0]="default" _hp_cfg_detail_level="ibnpvcdsrlLtfh" # # Variable assignments # init _hp_boot_dev_path="0/8/0/0.2.0" init _hp_default_cur_lan_dev="lan5" init _hp_primary_path="0/8/0/0.2.0" init _hp_current_client_release="B.11.11" init _hp_HFS_blksize=65536 init _hp_HFS_fragsize=8192 init _hp_VxFS_blksize=8192 init _hp_FS_stripe_size=64K init _hp_disk_layout="Logical Volume Manager (LVM) with VxFS" ... init _hp_os_bitness="64" init _hp_patch_save_files="YES" init _hp_custom_sys="Current System Parameters" init _hp_locale="SET_NULL_LOCALE" init "Create /export volume"=FALSE init "Create separate volumes (/usr, /var, ...)"=TRUE sd_command_line=" -x os_release=B.11.11 -x os_name=HP-UX:64 " # # Software Selections # init sw_sel "100BaseT-01"=FALSE init sw_sel "ATM-00"=FALSE init sw_sel "ATM-01"=FALSE init sw_sel "B5725AA"=TRUE

... init sw_sel "b_PHSS_28764"=FALSE init sw_sel "b_PartitionManag"=FALSE # sw_sel "perl" will be loaded due to other software. (cfg "HP-UX B.11.11 Default") { ... sw_source "core" { description="HP-UX coreSoftware" source_type="NET" source_format=SD sd_server="10.0.0.60" sd_depot_dir="/var/opt/ignite/depots/Rel_B.11.11/core" sd_command_line=" -xpatch_filter=*.* -xpatch_save_files=true " sd_use_ui=FALSE load_order=0 } sw_source "Kernel Configuration" { source_format=CMD load_order=11 } sw_source "site commands" { source_format=CMD load_order=10 } } RUN_UI=TRUE RUN_SD=TRUE SD_USE_UI=FALSE CONTROL_FROM_SERVER=FALSE HALT_WHEN_DONE=FALSE USE_EXPERT_UI=TRUE CLEAN_ALL_DISKS=FALSE HIDE_BOOT_DISK=FALSE ERROR_IF_BAD_SW=FALSE RECOVERY_MODE=FALSE DISABLE_DHCP=TRUE ALLOW_DISK_REMAP=FALSE release="B.11.11" # # System/Networking Parameters # _hp_custom_sys+={"Current System Parameters"} init _hp_custom_sys="Current System Parameters" _hp_custom_sys visible_if TRUE _hp_custom_sys help_text "System/Networking Info" (_hp_custom_sys=="Current System Parameters") { final system_name="testa" final ip_addr["lan5"]="10.0.0.162" final netmask["lan5"]="255.255.255.0" final ip_addr[]="10.0.0.47" final netmask[]="255.255.255.0" final route_gateway[0]="10.0.0.1" final route_destination[0]="default" TIMEZONE="EST-10EDT" ROOT_PASSWORD="/aIc61gXgbz2A" is_net_info_temporary=FALSE run_setparms=FALSE } # end "Current System Parameters"

# # Disk and File systems #

_hp_disk_layout+={"Modified LVM Layout"} init _hp_disk_layout="Modified LVM Layout" (_hp_disk_layout=="Modified LVM Layout") { # Disk/File system Layout: volume_group "vg00" { usage=LVM physical_volume disk[_hp_root_disk] { } # end pv_options max_physical_extents=2500 logical_volume { mount_point="/stand" disk[_hp_root_disk] usage=HFS size=307200K FILE_LENGTH=LONG FRAGSIZE=8192 BLKSIZE=65536 bad_block_relocate=FALSE contiguous_allocation=TRUE } # end logical_volume ... logical_volume { mount_point="/var" usage=VxFS size=73728K | remaining | 1822720K BLKSIZE=8192 largefiles=TRUE } # end logical_volume } # end volume_group "vg00" } # end "Modified LVM Layout"

Other instl_dbg options

The –vvv option (very verbose) lists all the selections and values of all variables. You can select use models (for example, "Logical Volume Manager (LVM) with VxFS") and set values for variables to test the impact that a change has on the configuration.

Refer to instl_dbg(1M) for more information on other options available.

The hw.info and host.info files

Both the hw.info and host.info files can be created in either of two ways:  When you add a new client to the Ignite-UX server for recovery, the add_new_client script

creates these two files (indirectly).

 When a new client boots from the Ignite-UX server and creates a directory for itself, information

about the client hardware is written to the hw.info file.

As of Ignite-UX version C.7.0, the io.info file is also created. This is used by Ignite-UX instead of the hw.info file.

Creating both files

You can easily create both host.info and hw.info16 files on a system by using the same method as the add_new_client script. The following example, run on the client system as root, places the host.info and hw.info files in the current working directory:

As of Ignite-UX version C.7.0, you will require the io.info file.

# export INST_CLIENT_DIR=./ # export PATH=$PATH:/opt/ignite/lbin # rescan_hw_host * Scanning system for IO devices... * Querying disk device: 0/0/1/1.15.0 ... * Querying disk device: 0/0/2/1.15.0 ... # ll total 4

-rw-r--r-- 1 root sys 214 Apr 27 15:31 host.info

-rw-r--r-- 1 root sys 688 Apr 27 15:31 hw.info # cat host.info MEMORY=1310720K HARDWARE_MODEL="9000/800" MODEL="9000/800/A400-6X" can_run_32bit=TRUE can_run_64bit=TRUE is_numa=FALSE is_ia64=FALSE is_hppa=TRUE _hp_boot_dev_path="0/0/1/1.15.0" _hp_boot_dev_path visible_if FALSE # cat hw.info cdrom: 0/0/1/0.1.0 2 sdisk 188 31 1000 HP_DVD-ROM_304 0 /dev/rdsk/c0t1d0 /dev/dsk/c0t1d0 -1 -1 0 1 0 disk: 0/0/1/1.15.0 0 sdisk 188 31 1f000 SEAGATE_ST336704LC 35566480 /dev/rdsk/c1t15d0 /dev/dsk/c1t15d0 -1 -1 5 1 10 disk: 0/0/2/1.15.0 1 sdisk 188 31 3f000 SEAGATE_ST336704LC 35566480 /dev/rdsk/c3t15d0 /dev/dsk/c3t15d0 -1 -1 4 1 10 lan: 0/0/0/0 0 lan0 btlan 000F201D7D1F HP_PCI_10/100Base-TX_core0 ext_bus: 0/0/1/0 0 c720 n/a SCSI_C896_Ultra_Wide_Single-Ended ext_bus: 0/0/1/1 1 c720 n/a SCSI_C896_Ultra_Wide_Single-Ended ext_bus: 0/0/2/0 2 c720 n/a SCSI_C87x_Fast_Wide_Single-Ended ext_bus: 0/0/2/1 3 c720 n/a SCSI_C87x_Ultra_Wide_Single-Ended processor: 160 0 processor n/a Processor

Note:

The lines are not folded in the actual hw.info file as they appear in the preceding e

xample.

You can test configuration changes with instl_dbg by copying an existing per-client directory to a new directory. However, it is not a good idea to copy the directory to another directory under /var/opt/ignite/clients in case the <MAC> directory you choose to copy it to conflicts with a potential future client; instead, copy it somewhere else.

You can either copy the hw.info and host.info files from the client system or freely change the existing hw.info and host.info files for testing. For example, the disk size is the field after the description, but before the raw device file name (both disk devices are set to 35566480 in the preceding example).

If you had to test a configuration with 72 GB disks, you could manually change those sizes. While you might consider doing this for testing purposes, you should never change the hw.info or host.info files in a per-client directory on the Ignite-UX server that is used by a "real" client system, as doing so may cause many potentially fatal problems. You should not attempt to

manually cha manual changes are likely to leave the file unusable.

nge the io.info file, this file is considerably more complex than the hw.info file and

Miscellaneous configuration tips

 In Ignite-UX configuration files, TRUE and FALSE should be stated only in upper- or lower-case

and never in mixed case. Ignite-UX does not understand TRUE or FALSE when they are in mixed case. This applies to other keywords as well.

 Be careful when deciding to use the = or += operators. The += operator enables you to add to

something, while the = operator removes any current value for a variable and replaces it with the new value being assigned. See the "_hp_disk_layout" section on page 88 for information abou

t how = and += can be used to replace existing disk layouts or add more layout choices.

The error keyword is a good example of the need to use += at times. If you use =, you remove any previous error messages that may have been encountered. If you use +=, all of the error messages, both previous and new, can be shown to the user.

 When you are using the Ignite-UX GUI to add new logical volumes, you might want to consider

choosing the logical volume that is most similar to what you want to create and use that as a starting point. Change the attributes and instead of selecting Modify, then select Add to create your new logical volume.

 When setting a network configuration, review instl_adm(4) to verify whether the modifier

final (placed before a keyword, such as dns_domain) is required to retain the configuration

when the system is installed. If it is required and you do not provide this modifier, the configuration is only kept for the duration of the installation and is discarded at the final system reboot.

 If you do not want to preserve instance numbers when cloning a system, you should remove all of

the hw_instance_num lines from the system_cfg file. Unlike network recovery archives, you cannot remove hw_instance_num lines from a recovery tape after creation. Instead, if you use a recovery tape for cloning and do not want to preserve instance numbers, you must preview using make_tape_recovery with the -p option, edit the associated configuration file (/var/opt/ignite/recovery/latest/system_cfg), and then resume creation of the recovery tape using make_tape_recovery with the -r option. For a network recovery archive, you would find the system_cfg file in the following location: /var/opt/ignite/clients/<MAC>/recovery/<DATE-TIME>/system_cfg

 If you need to create swap spaces larger than 32GB with HP-UX 11i v2 or later releases of HP-

UX, you should be running Ignite-UX version C.7.0 or later - previous versions of Ignite-UX do not allow you to do this.

Analyzing the HP-UX default B.11.11 cfg clause

The following is from a default /var/opt/ignite/INDEX showing the configuration files referenced by the HP-UX B.11.11 cfg clause:

cfg "HP-UX B.11.11 Default" { description "This selection supplies the default system configuration that HP supplies for the B.11.11 release." "/opt/ignite/data/Rel_B.11.11/config"

"/opt/ignite/data/Rel_B.11.11/hw_patches_cfg" "/var/opt/ignite/config.local" }

This section describes these configuration files and explains what is happening and why certain things have been done in certain ways.

The release-specific configuration file

The config file defines all of the file system and volume management configurations for the release (and a few other things).

########################################################################## # config: # # (c) Copyright Hewlett-Packard Company 1994 # # This file contains the default system definitions used during a # cold-install of HP-UX. This file should not be modified. If # modifications are needed, the file "config.local" should be modified # instead. # See the instl_adm(4) man page for details. # # Changes to this file will not be preserved if the fileset is re-installed. # # If you are editing this file via the advanced options during a # cold-install, then notice that the "config.local" contents are appended # to the end of this file. # # @(#) config $Revision: 10.82 $

The release keyword is probably the single-most important keyword in an Ignite-UX configuration file. This keyword must be set or else any installation of HP-UX is likely to fail or not work properly. Ignite-UX has no idea what version of HP-UX it is installing unless it is set.

As of Ignite-UX C.6.0.x, the release keyword is checked against the value of the

_hp_ikernel_os_release variable (the client creates the value of this variable in the host.info file). If the HP-UX release in the release keyword is not supported by the kernel

version given in _hp_ikernel_os_release the installation is not allowed to proceed and the following error appears:

ERROR: The version of HP-UX you have chosen to install on the system (B.11.23) is not supported by the version of the Ignite-UX install kernel that the system booted (B.11.11). You will need to reboot the target system from an install kernel matching the desired release from the menu at the console. If using the bootsys command, use the '-R' option to specify the install kernel version.

Table 2 shows the different HP-UX releases, beginning with Ignite-UX C.7.3.x, which can be installed with the different versions of an installation kernel

Table 2

This assumes that you have installed the necessary filesets to support those HP-UX releases.

HP-UX Release18 PA-RISC Itanium®-based

B.11.11 B.11.11 N/A

B.11.23 B.11.23 B.11.23

B.11.31 B.11.31 B.11.31

Ther

efore, if you boot the B.11.11 installation kernel you can install HP-UX B.11.11 but you cannot install B.11.23. The reverse applies - if you boot the B.11.23 PA-RISC installation kernel, you cannot install B.11.11 with it.

When you create custom configuration files and do not plan to include the default configuration files you must set this variable.

release="B.11.11"

#######################################################################

Some time ago, changes were made to Ignite-UX to increase the block and fragment sizes for VxFS and HFS file systems. This can lead to differences between systems installed in the last few years and much older systems that had smaller default block and fragment sizes (for example, the file system attributes are different so the block and fragment sizes from older systems are probably smaller).

The use of <variable> visible_if false ensures that the variables do not appear in the Additional dialog box from the Basic tab.

init _hp_HFS_blksize = 65536 # HFS block size. init _hp_HFS_fragsize = 8192 # HFS frag size. init _hp_VxFS_blksize = 8192 # VxFS block size. init _hp_FS_stripe_size = 64Kb # File system stripe size.

_hp_HFS_blksize visible_if false _hp_HFS_fragsize visible_if false _hp_VxFS_blksize visible_if false _hp_FS_stripe_size visible_if false #######################################################################

The following example shows the start of a definition for the _hp_disk_layout variable, which is set to one of four possible values.

Around the _hp_disk_layout is a test for is_hppa (is PA-RISC). This only exists in this file since the file is generated from one common source file using unifdef (refer to unifdef(1) for more information) for all HP-UX releases. Obviously, this test is not actually needed for HP-UX B.11.11 since it is only supported on PA-RISC systems. The entire release-specific configuration files are based on one original file and they are processed with unifdef to produce the release-specific configuration file.

You actually get to see the value of the variable _hp_disk_layout when you use the Ignite-UX GUI. The values currently assigned to _hp_disk_layout are shown on the File System: list on

HP-UX release of the install kernel

the Basic tab. The form us

ed in the next example to initialize a list of possible values allows the

Ignite-UX GUI to modify the list later. Further in the configuration file, when giving _hp_disk_layout a final value you only assign its

value using init. When using the form "init _hp_disk_layout="…" the Ignite-UX GUI is still allowed to modify the value. If you instead define "_hp_disk_layout="…"" without the init, the Ignite-UX GUI cannot change this value. If the Ignite-UX GUI were not able to change the value of _hp_disk_layout, no changes made in the Ignite-UX GUI to file system attributes are applied to the system

This is because the Ignite-UX GUI must change the value of _hp_disk_layout to "Modified LVM Layout", "Modified VxVM Layout", or "Modified Whole-Disk Layout" when changes have been made. If the Ignite-UX GUI is not allowed to change the variable, you cannot keep any file system customizations. This concept becomes very important when creating custom configuration files.

# For PA architecture only is_hppa { _hp_disk_layout = { "Whole disk (not LVM) with HFS", "Logical Volume Manager (LVM) with HFS", "Logical Volume Manager (LVM) with VxFS", "VERITAS Volume Manager (VxVM) with VxFS" } }

You can now set the variable _hp_disk_root to the value of _hp_primary_path, assuming that the device that _hp_primary_path points to exists and _hp_root_disk does not already have a value. You can use an Extended Regular Expression (ERE) set to any value

to see if _hp_root_disk is

# # Set the default root disk to the current primary path. The # _hp_primary_path will be "" if it was set to a non-existent dev. # also don't reset the _hp_root_disk if it was initialized in # a different config file and non-null (see 15654FSDdt). Use # the ~ operator instead of == to detect if _hp_root_disk is not # yet set (See FSDdt22058). # (_hp_primary_path != "" & !(_hp_root_disk ~ ".*")) { init _hp_root_disk=_hp_primary_path }

The itool command Ignite-UX GUI accepts changes to file system attributes and does not caution you, but no file system

attribute changes made in the Ignite-UX GUI are applied to the system.

For more information regarding ERE, refer to regexp(5).

The ERE ".*" means zero or more of any character so it matches a zero length string.

The next section of the configurat

ion file presents a critical concept that it is important to understand – the idea of the effects relationship. An effects relationship creates a relationship between two variables so that when one variable changes the other variable is re-evaluated – even if its final value is not based upon that variable.

In the next example, you can see that the value of _hp_pri_swap has been set to the size of the root disk and to the value of _hp_disk_layout (after that primary swap is initialized to a value more useful for swap).

This forces Ignite-UX to reevaluate the value of _hp_pri_swap whenever the size of the root disk changes (a smaller disk might force Ignite-UX to define a smaller swap space) or when the disk layout changes.

# # The next two statements are used only to establish an effects # relationship between the _hp_pri_swap variable and _hp_root_disk & # _hp_disk_layout variables. The value is overwritten below. # This makes the UI change the swap anytime either of these two # values change. init _hp_pri_swap = disk[_hp_root_disk].size init _hp_pri_swap = _hp_disk_layout

# default (recommended) swap size is 2 X memory # Round up to the nearest 64MB so that we don't get a warning # about it being adjusted in the UI. Really this just needs # to be rounded to be a multiple of the physical-extent-size, but # that can vary depending on the size of disk (4,8,16,32,64...) # 64MB should work on the majority of the disks available. init _hp_pri_swap = (((MEMORY * 2) + 65535KB)/64MB)*64MB

Now you have other calculations for swap for different sized disks. The following example limits the size of swap for small disks. If you use init when setting both _hp_pri_swap and _hp_sec_swap, then the configuration only uses methods for setting the variables that allows the Ignite-UX GUI to modify them.

# Put an upper bounds of 1024Mb to the default swap size for disks # less than 5Gb. And 4Gb swap for other disks _hp_pri_swap > 1024Mb { disk[_hp_root_disk].size < 5120Mb { init _hp_pri_swap = 1024Mb } else { _hp_pri_swap > 4096Mb { init _hp_pri_swap = 4096Mb } } }

# Use a 128Mb as the default minimum amount of swap configured on any # system. The real swap space will be reduced down to _hp_min_swap if # there is not enough file system space. (_hp_pri_swap < 128Mb) { init _hp_pri_swap = 128Mb }

# Initialize the swap range minimum to what the default is _hp_min_swap = _hp_pri_swap

# If the system is limited on resources, then reduce the minimum so # that the OS has a better chance of fitting. The swap size will # still be set to the recommended value if there is enough disk space. (_hp_min_swap > 512Mb & disk[_hp_root_disk].size < 3000Mb)

{ _hp_min_swap = 512Mb } (_hp_min_swap > 192Mb & disk[_hp_root_disk].size < 1800Mb) { _hp_min_swap = 192Mb } (_hp_min_swap > 96Mb & disk[_hp_root_disk].size < 700Mb) { _hp_min_swap = 96Mb } (_hp_min_swap > 68Mb & disk[_hp_root_disk].size < 600Mb) { _hp_min_swap = 68Mb }

Now _hp_sec_swap has been initialized with a set of values that can be chosen from; however, they are not a fixed set of values. The variable _hp_sec_swap can be set using the Additional button because of the way the variable was defined (<variable>={ value1, value2, … }). The variable _hp_sec_swap has its value set from a selection list or by typing it into the corresponding field directly. This can happen because _hp_sec_swap was not defined as an "enum"; if it had been defined as an enum only a value from the list of values it contains could be used.

Although, in this configuration, hp_pri_swap cannot be modified using the Additional button. This value appears directly in the Ignite-UX GUI on the Basic tab using the Root Swap (MB) button and it allows you to select from a list of possible values. The list of values shown in the selection list for _hp_pri_swap comes from the list defined in the configuration. If you create a custom disk configuration file, you should supply a value or a list of values for _hp_pri_swap (or somehow otherwise calculate a default value for it).

_hp_pri_swap = { 128Mb, 256Mb, 512Mb, 1024Mb, 1536Mb, 2048Mb, 3072Mb, 4096Mb, 8192Mb, 12288Mb, 16384Mb }

_hp_sec_swap ={ 0Mb, 128Mb, 256Mb, 512Mb, 1024Mb, 1536Mb, 2048Mb, 3072Mb, 4096Mb, 8192Mb, 12288Mb, 16384Mb } init _hp_sec_swap = 0Mb _hp_sec_swap help_text "Secondary Swap space (KB)"

The next example gives _hp_disk_layout a value of disk [_hp_root_disk].model. If the value of that expression ever changes, it causes the value of _hp_disk_layout to be reevaluated.

Doing this makes good sense in the context of this configuration file because if you change the root disk, you may need to re-evaluate what the disk configuration is. Tests later on may override some defaults for _hp_disk_layout in the following example:

Note:

The models being tested on are not likely ever to run HP-UX B.11.11. This is old data b

# This next statement is used only to establish an effects relationship # between the _hp_disk_layout variable and _hp_root_disk. The value is # overwritten below. init _hp_disk_layout = disk[_hp_root_disk].model

eing carried along into later releases.

The following section defines some limitations on non-LVM configuations due to firmware limitations in older HP9000 systems - it is somewhat unlikely any of these systems are running HP-UX 11.11 (some of them supported HP-UX revisions as early as 7.x).

# # Define the defaults based on the system architecture 700 vs 800 # is_hppa { HARDWARE_MODEL ~ "9000/7.*" { init _hp_disk_layout = "Logical Volume Manager (LVM) with VxFS" } else { # For a certain class of S800's, non-LVM takes >30 minutes to boot due # to sequential access firmware. So make the default LVM on them no # matter what size of disk it is. disk[_hp_root_disk].size >= 600Mb | HARDWARE_MODEL ~ "9000/825.*" | HARDWARE_MODEL ~ "9000/834.*" | HARDWARE_MODEL ~ "9000/835.*" | HARDWARE_MODEL ~ "9000/635.*" | HARDWARE_MODEL ~ "9000/845.*" | HARDWARE_MODEL ~ "9000/645.*" | HARDWARE_MODEL ~ "9000/822.*" | HARDWARE_MODEL ~ "9000/832.*" | HARDWARE_MODEL ~ "9000/842.*" | HARDWARE_MODEL ~ "9000/852.*" { init _hp_disk_layout = "Logical Volume Manager (LVM) with VxFS" } else { init _hp_disk_layout = "Whole disk (not LVM) with HFS" } } # # For disks over 2Gb+300k the default must be LVM. # Set the default here, and sanity_checks will ensure it. # disk[_hp_root_disk].size > 2097452K { init _hp_disk_layout = "Logical Volume Manager (LVM) with VxFS" } } else { init _hp_disk_layout = "VERITAS Volume Manager (VxVM) with VxFS" }

The enumeration _hp_root_grp_striped in the following example is a perfect example of how to ask a yes/no or Boolean question using the Additional button on the Basic tab in the Ignite-UX GUI. The first step is to define the variable as an enum, then give it two values, an initial value (with the init keyword so the user is allowed to change it using the Ignite-UX GUI), and some help text.

Without defining _hp_root_grp_striped as an enum, the user would be able to select YES or NO on the Additional button or also enter any value. In this case, it does not matter because the configuration only ever tests on the value YES (later) to decide on an action, but if you could enter a lower-case "yes" the tests would fail; hence the enumeration type is used.

# # Boolean describing whether or not the root disk group # will be striped # enum _hp_root_grp_striped _hp_root_grp_striped = { "YES", "NO" } init _hp_root_grp_striped = "NO" _hp_root_grp_striped help_text "Stripe root VG disks?"

The expr true / false expressions that are used to control how things are done

ession in the next example is defining a use model. Use models are not variables; they are

. Like variables, use

models can be viewed using the Additional button of the Basic tab in the Ignite-UX GUI. When you are in the Additional dialog box, use models look visibly different from variables. Later in the configuration file, is the impact statement that this use model would have when it is set to true.

INIT23 "Create /export volume" = false

Now you have another effects relationship, this time between a new variable _hp_root_grp_disks and _hp_root_disk. The variable _hp_root_grp_disks is meant to be an integer so when doing the effects relationship you add zero (0) to disk[_hp_root_disk].size to ensure that the final value is an integer. Since variables are not explicitly typed, you want to imply an integer type.

The variable _hp_root_grp_disks is also an enum; it can take one of the values from 1 up to the value of variable num_disks,

# # Number of disks in the root volume group # The fist line below is just to define an "effects" relationship # between the root disk and _hp_root_grp_disks which dependent # upon each other in the logic to follow. # init _hp_root_grp_disks = (disk[_hp_root_disk].size+0) # +0 convert to int enum _hp_root_grp_disks _hp_root_grp_disks = { 1..num_disks } init _hp_root_grp_disks = 1 _hp_root_grp_disks help_text "# of disks in root VG"

and it has a default initial value of 1.

In the next example, you test on the size of the root disk and the number of disks attached to the system. If the size of the root disk is <600MB and there are only two disks, the second disk is automatically included into the root volume group (by setting _hp_root_grp_disks to be 2).

When the root disk is <600MB, the default value for _hp_disk_layout is "Whole disk (not LVM) with HFS". If there are only two disks in the system, the second disk is included and the default for

_hp_disk_layout is changed to "Logical Volume Manager (LVM) with VxFS".

# If there are only two disks and the "_hp_root_disk" disk is small, default to # LVM configuration with both disks in root volume group. disk[_hp_root_disk].size < 600Mb & num_disks == 2 { init _hp_disk_layout = "Logical Volume Manager (LVM) with VxFS" init _hp_root_grp_disks = 2 }

Unfortunately, variables cannot have effects relationships with use models or software selections.

The "init" keyword is case insensitive, so it can appear is init or INIT. It cannot appear in mixed case such as

"Init". If you do this, Ignite-UX will not recognize it as a keyword.

A built-in variable that is a count of the number of disks discovered on the system. Refer, refer to instl_adm(4).

Next is another u

se model defined called "Create separate volumes (/usr, /var, ...)". It is used

later for _hp_disk_layouts other than "Whole disk (not LVM) with HFS" only. By default, this is

TRUE (and the Ignite-UX GUI does show separate volumes for /usr, /var, … by default).

INIT "Create separate volumes (/usr, /var, ...)" = TRUE

The first disk configuration "Whole disk (not LVM) with HFS" is protected by a test of the variable _hp_disk_config to see if it is equal to "Whole disk (not LVM) with HFS".

After that, the partitioned_disk keyword starts the definition of a whole disk layout for a system. The partitioned_disk disk definition must contain the following:

 A physical_volume definition  An fs_partition definition  A swap_partition definition

If you have no fs_partition definition that at least defines the root file system, the following error appears after pressing Go! in the Ignite-UX GUI:

ERROR: There is no root volume (mount point = /) defined in the configuration.

If you have no swap_partition defined, you see the following error after selecting Go! in the Ignite-UX GUI:

ERROR: There is no swap volume defined in the root volume group (or on the root disk).

For the physical volume statement, you need only supply the name of the disk that is used as the root disk (the disk[] keyword takes a hardware path or index number and returns the name of the disk). This discussion here assumes that you are defining the boot disk as a whole disk

However, if you were writing custom configurations you probably would not worry about whole disk layouts on any system running B.11.11 (you need a 2GB or less disk drive to do this on PARISC because of potential firmware limitations and HP-UX B.11.11 recommends at least a 4GB root disk).

_hp_disk_layout == "Whole disk (not LVM) with HFS" { partitioned_disk { physical_volume disk[_hp_root_disk]

The file system partition on a partitioned disk must be HFS. It follows from the fact that the PA-RISC boot loader can only read from some types of HFS file system (large files-enabled HFS file systems cannot be booted from on PA-RISC systems). Therefore, the usage statement is set to be HFS. You set the block size and the fragment size

to the HFS defaults defined earlier.

You can have multiple whole disks defined in a configuration. Each whole disk is defined by different

partitioned_disk definitions and has a different mount_point.

These concepts are only meaningful in a HFS file system. The block size is the largest block of data a file can have allocated to it (files that can occupy a full free block will do so and the smallest amount of space that can be allocated by a file is the fragment size. In extent-based file systems these concepts are usually meaningless. For example, the smallest allocation unit is 1KB no matter what the fragment size is set to for the file system.

Now si

ze is set to the remaining, which takes whatever space is left over once "other" things (in

this case swap at the end of the disk) have been allocated., The mount point naturally is "/" (since it is the root file system). Lastly, if this is a very small disk change minfree to be 5% (you are installing B.11.11 and there is no way you can fit B.11.11 onto a 300MB disk anyway).

fs_partition { usage = HFS blksize = _hp_HFS_blksize fragsize = _hp_HFS_fragsize size = remaining mount_point = "/" disk[_hp_root_disk].size < 300Mb { # For really small disks, tune down minfree # in order to gain some disk space. minfree = 5 } }

Now you have our primary (and presumably only) swap partition definition, you can see that it is swap from the usage. The interesting thing is the size specification. This sets the size to be at least _hp_min_swap but also includes any remaining space up to _hp_pri_swap in size. The swap space in this case attempts to get all of the space that it can (up to _hp_pri_swap) but does not go lower than _hp_min_swap while ensuring that the file system partition gets enough to meet its impacts

statements requirements.

swap_partition { usage = SWAP mount_point = "primary" size = _hp_min_swap | remaining | _hp_pri_swap } } }

Now you have all the volume manager layouts. You may have noticed at the beginning of this section that LVM and VxVM both use the same ways of defining volume definitions; only the usage statement at the volume group level determines if an LVM volume group or VxVM disk group will be created (see below).

_hp_disk_layout == "VERITAS Volume Manager (VxVM) with VxFS" | _hp_disk_layout == "Logical Volume Manager (LVM) with HFS" | _hp_disk_layout == "Logical Volume Manager (LVM) with VxFS" {

Here you are defining the variable _hp_group_name. However, you must first make sure that it is not visible on the Additional button (since you do not want anyone to be able to change it). If the value of _hp_disk_layout is set to be VxVM ("VERITAS Volume Manager (VxVM) with VxFS") you set _hp_group_name to be rootdg; otherwise it is LVM you are using and vg00 is the name you are going to use

Impact statements and software are discussed later.

VxVM 3.5 and earlier requires the root volume group be named rootdg. This is enforced by Ignite-UX.

The _hp_gro

up_name does not actually do anything except hold the initial name of the volume

group or disk group that this configuration is defining. If this variable could be changed using the Additional button, it would not do anything since it is only a temporary variable to hold the

name

_hp_group_name visible_if FALSE

(_hp_disk_layout == "VERITAS Volume Manager (VxVM) with VxFS") { _hp_group_name = "rootdg" } else { _hp_group_name = "vg00" }

The temporary variable is necessary to give the volume group a name. You do this by assigning the name to a temporary variable and then starting your volume group definition with that name.

A volume group definition must have the following things in it:

 volume group attributes  one or more physical_volume definitions (including "group"

definitions that also include

more physical volume definitions)

 one or more (usually more) logical_volume definitions.

volume_group _hp_group_name {

The physical_volume definition places the first disks (whose number is determined by _hp_root_grp_disks) returned by the disk[] construct into the root volume group

. When

Ignite-UX encounters the first volume group that uses *=<index> it attempts to return the preset root disk as the first disk. This causes things to look as though the disk in _hp_root_disk (initialized from _hp_primary_path) was always placed into the list of physical volumes put into the root volume group and disk group.

physical_volume disk[*=_hp_root_grp_disks]

Next is a test to choose the volume manager. Currently the only choice that enables VxVM is "VERITAS Volume Manager (VxVM) with VxFS". All of the other choices use LVM.

(_hp_disk_layout == "VERITAS Volume Manager (VxVM) with VxFS") { usage = VxVM } else { usage = LVM }

All the volume group attributes such as max_physical_extents are optional and only affect LVM volume groups. If you do not give them, they take on the defaults of the vgcreate command.

To change the name of a volume group you use the Ignite-UX GUI to select the File system tab then the Additional Tasks button, and click Group Parameters. From the Group Parameters dialog box, select the name of the group to change from the selection list, change the group name, press modify, and then click Ok.

Defining physical volume groups is discussed later when discussing custom configuration.

This is evaluated once. After that, changes made via the Ignite-UX GUI affect which physical volumes is used in the root volume group.

# In order to accommodate adding 9GB disks now or in the # future, set the default max_physical_extents large # enough to handle it (based on 4Mb extent size). # Note that this will be increased by IUX automatically # for disks larger than 9GB. max_physical_extents = 2500

Very large disks are the most common disks on new systems with ≥140GB disks considered large, 36/72GB disks average, and 18GB disks small. These tests adjust the physical extent size for the LVM volume group being defined and ensures that the complete disk can be used with the disks. It is only based upon the size of the root disk, not the size of every disk that might be included. This might influence the amount of usable space in the volume group. Additionally, Ignite-UX examines all the disks being used and selects the LVM parameters that work for that entire disk group. The setting of physical extent size here is just a first approximation; Ignite-UX can change these values at a later stage.

In a custom configuration, it might be better to scale both max_physical_extents and

physical_extent_size based upon the disk size.

# # For very large disks, the root group VGRA meta-data area # will outgrow its bounds and trigger an IUX sanity check # error. So for root disks large enough, set the physical # extent size. Note that this only handles the root disk, but # any disk in the root VG could trigger the error... # (disk[_hp_root_disk].size > 21504MB) # >21GB { physical_extent_size=8 } (disk[_hp_root_disk].size > 44032MB) # >43GB { physical_extent_size=16 } (disk[_hp_root_disk].size > 84992MB) # >83GB { physical_extent_size=32 } (disk[_hp_root_disk].size > 179200MB) # >175GB { physical_extent_size=64 }

Next are the definitions of the logical volumes in the configuration. The first one is, of course, the root file system (note the mount_point definition). Depending on the value of the disk layout, the file system type is either HFS or VxFS.

Further, you have a test for a use model "Create separate volumes (/usr, , ...)". If there are separate file systems, then the default size for the root file system is 140MB if the root disk is less than 8192MB, or 200MB if it is greater than or equal to 8192MB.

If you are not

expected to create separate logical volumes for file systems like /usr and /var then

the sizes are the remaining space up to 1200MB if the size of the disk is less than 8192MB or the remaining space up to 1200MB plus the size of _hp_pri_swap

The root file system cannot have bad block relocation on and must be contiguous; therefore

contiguous_allocation is set to true, and bad_block_relocation is set to false.

logical_volume { mount_point = "/" _hp_disk_layout == "Logical Volume Manager (LVM) with HFS" { usage = HFS blksize = _hp_HFS_blksize fragsize = _hp_HFS_fragsize } else { usage = VxFS blksize = _hp_VxFS_blksize } "Create separate volumes (/usr, /var, ...)" { disk[_hp_root_disk].size < 8192Mb { size = 140Mb } else { size = 200Mb } } else { disk[_hp_root_disk].size < 8192Mb { size = remaining | 1200Mb } else { size = remaining | 1200Mb + _hp_pri_swap } } contiguous_allocation = true bad_block_relocate = false }

Next, you define primary swap by setting the usage to be swap and dump. The mount_point is set to "primary". The vgdisk[0] value enables you to specify that this logical volume be placed onto the first disk in the root volume group. Refer to instl_adm(4) for more information on the vgdisk keyword.

Next are the usual settings for primary swap of contiguous allocation and disabled bad block relocation. The size must be at least _hp_min_swap and up to _hp_pri_swap depending on the size of the disk.

logical_volume { usage = SWAP_DUMP mount_point = "primary" # Map it to the root disk to ensure it is considered primary # without this the secondary swap gets sorted first and considered # primary. vgdisk[0] contiguous_allocation = true bad_block_relocate = false size = _hp_min_swap | remaining | _hp_pri_swap }

HP-UX B.11.11 may not actually fit into the amount of space defined here; the impacts statements for software defined may also force the sizes of file systems to be adjusted.

You looked at _hp_sec_swap earlier in the configuration file to see how it was defined. The only place you can give it a value is by using the Additional button on the Basic tab in the Ignite-UX GUI. You can manually define secondary swap using the File system tab, but you must manually select the disk to avoid it being on the same disk as primary swap. The configuration enables you to have secondary swap/dump. You only have to care about its size, not placement.

So if the variable _hp_sec_swap is >0MB, swap/dump space is created. If there is more than one disk in the root volume group, this swap/dump space is created on the second disk. If you provide equal sized primary and secondary swap, it creates an interleaved swap setup.

Also, you set the options required for this swap space to also be used as a dump space (contiguous allocation and bad block relocation off), and lastly you set the size to be _hp_sec_swap. Secondary swap, if not used for dump, does not require contiguous allocation and bad_block relocation to be _relocate set to true.

_hp_sec_swap > 0Mb { logical_volume { usage = SWAP_DUMP mount_point = "secondary" (num_vgdisks > 1) { # This maps the secondary swap space to # the second disk when one is defined. vgdisk[1] } contiguous_allocation = true # allows use as dump bad_block_relocate = false # allows use as dump size = _hp_sec_swap } }

Next /stand is defined. Of course, it must be HFS since the HP9000 secondary load cannot read a VxFS file system. Only HP Integrity servers (starting with HP-UX B.11.23) can have a VxFS file system in /stand. The block and fragment sizes are initialized from constants defined earlier. If you have a disk less than 2050MB, /stand defaults to 84MB. A disk greater than or equal to 2050MB but less than 3075MB is 112MB in size; otherwise you get a 300MB /stand file system by default.

logical_volume { mount_point = "/stand" # /stand must be HFS! usage = HFS blksize = _hp_HFS_blksize fragsize = _hp_HFS_fragsize # The /stand volume needs to be able to hold at least 5 kernels, # for various debugging reasons. The typical 11i kernel is # about 18Mb. The debug IA kernel is 42Mb. The smallest /stand # area needs to be at least twice the largest possible kernel. # Unless a user tries to put on more than the "normal" amount of # software on a system with a large root disk, the default /stand # directory will be 300Mb. To see the use of the size option, # see the man page for "instl_adm". disk[_hp_root_disk].size < 3075Mb { disk[_hp_root_disk].size < 2050Mb { # Most 2G drives are actually bigger than exactly 2G size = 84Mb

} else { size = 112Mb } } else { size = 300Mb } contiguous_allocation = true bad_block_relocate = false }

300MB is the default for large disk configurations because additional Dynamically Loadable Kernel Modules (DLKMs) require more space in /stand.

Now at this stage you might be wondering why you had to make sure that you set up those logical volumes with certain values for contiguous allocation and bad block relocation. Table 3 contains a brief summary

of the reasons.

Table 3

Name Contiguous

Allocation

Primary swap

Dump space

Secondary swap

/stand TRUE FALSE

TRUE FALSE

N/A N/A

Bad Block

Relocation33

The root file system must be usable before the volume manager is active to enable this. It cannot allow the volume manager to relocate blocks and it must be contiguous on a disk.

Primary swap is activated before the volume manager is active, so it requires the same options as the root file system.

A dump is written when no volume manager is active; because of this, it must be contiguous, and cannot have bad blocks relocated by the volume manager.

Secondary swap has no requirements unless it is also a dump space; in which case, it has the dump space requirements.

The /stand volume is read by the boot loader. The boot loader knows nothing about volume managers and currently only understands HFS and cannot have bad block relocation enabled.

Note:

On HP-UX B.11.11, it is assumed that all IODC (I/O Dependent Code)

irmware can perform operations with up to 4GB offsets35 . For some

in f I/O c

ontrollers this limits the maximum offset for dump. Newer systems have block-based I/O implemented in IODC. This allows the offset of an I/O operation to be given in blocks not bytes. This change dramatically increases the amount allowed for offset of dump spaces on most new I/O interfaces. Itanium®-based systems do not have a 4GB

Reason

file systems, so the file system must be contiguous

This is bad block relocation performed by a volume manager not automatic relocation performed by the disk drives.

Itanium®-based systems may have /stand as a VxFS file system. The HFS restriction is applicable only to PA-RISC

systems.

Various combinations of 2GB and 4GB offsets (depending on the I/O interface) were allowed in older releases of Ignite-

UX (before B.3.0 and in all of the A.x.x versions).

offset limit for dump since they all support block-based dump. In these cases the size is limited to the size of the disk itself.

If the option to create separate volumes is true (the default), then the following very long block of definitions is examined:

"Create separate volumes (/usr, /var, ...)" {

Next is a definition for /usr. The file system has large files enabled, and if the disk layout is "Logical Volume Manager (LVM) with HFS" then a HFS file system is created with the default block and fragment sizes set up earlier. Otherwise, it is a VxFS file system with the default VxFS block size (note that the fragment size is irrelevant

for VxFS).

logical_volume { mount_point = "/usr" largefiles = true _hp_disk_layout == "Logical Volume Manager (LVM) with HFS" { usage = HFS blksize = _hp_HFS_blksize fragsize = _hp_HFS_fragsize } else { usage = VxFS blksize = _hp_VxFS_blksize }

Now if the size of the root disk is less than 1800MB, the size of the volume is at least 332MB, after all other volumes have had their sizes allocated. The size of /usr can be increased to have up to 20% free space

(if available). The impact of disk space requirements for software being installed

that affects /usr may force the size to be higher.

disk[_hp_root_disk].size < 1800Mb { size = 332Mb | remaining | 20% free } else {

If the root disk size is >3072 MB, the size of /usr is 500MB. Once all other volumes have had their space allocated, the size can be increased to ensure that there is 20% free space (noting the issues discussed previously can impact the size requirements). If the root disk size is between 1800MB and 3072MB, then the minimum size is 400MB.

disk[_hp_root_disk].size > 3072MB {

size = 500Mb | remaining | 20% free } else { size = 400Mb | remaining | 20% free } }

VxFS is an extent-based file system and allocates available space to a file. Fragments can be as low as 1KB but are

typically larger. There is no way to control fragment size in a VxFS file system.

This amount does not include the amount of space that can be added by the _hp_addnl_fs_free_pct configuration

item.

If the con

figuration item _hp_root_grp_striped is set to "YES" then you set up striping. The "stripes = *" set the number of stripes equal to the number of disks in the volume group. The stripe size _hp_FS_stripe_size was set up earlier as 64KB.

_ hp_root_grp_striped == "YES" { stripes = * stripe_size = _hp_FS_stripe_size } }

The definition of /opt is very similar to the definition of /usr. For this volume and the others defined by setting "Create separate volumes (/usr, /var, ...)" to true, you only look at the differences rather than the similarities.

The only difference between /usr and /opt is the size definition: rather than giving a percentage free, there is a specific size requirement for free space. For example, in the first size definition, when the size of the root disk is <1800MB, /opt is a minimum of 100MB. After all space has been allocated, you take from the remaining up to an extra 100MB and place it into /opt

logical_volume { mount_point = "/opt" largefiles = true _hp_disk_layout == "Logical Volume Manager (LVM) with HFS" { usage = HFS blksize = _hp_HFS_blksize fragsize = _hp_HFS_fragsize } else { usage = VxFS blksize = _hp_VxFS_blksize } disk[_hp_root_disk].size < 1800Mb { size = 100Mb | remaining | 100Mb free } else { disk[_hp_root_disk].size > 3072MB { size = 100Mb | remaining | 252Mb free } else { size = 100Mb | remaining | 152Mb free } } _hp_root_grp_striped == "YES" { stripes = * stripe_size = _hp_FS_stripe_size } }

If the size of the root disk is greater than or equal to 8192MB, the final size can be 500MB plus the size of _hp_pri_swap. The value is based on primary swap being dump and some space is required in /var/adm/crash to save crash dumps. This assumption is invalid if you define a separate volume for /var/adm/crash using the Ignite-UX GUI.

Again, the impact of software being installed can increase the size of this volume, and the _hp_addnl_fs_free_pct

configuration item can increase the final size of the volume (if free space is still left unallocated).

The size requirement is up to 500MB + _hp_pri_swap. Depending on free disk space, there may not be enough to

increase the size of a file system this large. During an interactive installation, the size of /var can be manually tuned down to a more appropriate value.

logical_volume { mount_point = "/var" largefiles = true _hp_disk_layout == "Logical Volume Manager (LVM) with HFS" { # /var needs lots of inodes due to SD's IPD nbpi = 2048 usage = HFS blksize = _hp_HFS_blksize fragsize = _hp_HFS_fragsize } else { usage = VxFS blksize = _hp_VxFS_blksize } disk[_hp_root_disk].size < 8192Mb { size = 72Mb | remaining | 500Mb } else { size = 72Mb | remaining | 500Mb + _hp_pri_swap } _hp_root_grp_striped == "YES" { stripes = * stripe_size = _hp_FS_stripe_size } }

The definition of /tmp is a simpler case than the other volumes. In this case, the size is a fixed value. It is unlikely that any impacts caused by installing software would affect /tmp.

logical_volume { mount_point = "/tmp" largefiles = true _hp_disk_layout == "Logical Volume Manager (LVM) with HFS" { nbpi = 2048 usage = HFS blksize = _hp_HFS_blksize fragsize = _hp_HFS_fragsize } else { usage = VxFS blksize = _hp_VxFS_blksize } disk[_hp_root_disk].size < 8192Mb { size = 64Mb } else { size = 200Mb } _hp_root_grp_striped == "YES" { stripes = * stripe_size = _hp_FS_stripe_size } } } # "Create separate volumes (/usr, /var, ...)"

Although it is rare to see an /export volume created, you can enable it by using the Additional button on the Basic tab in the Ignite-UX GUI.

"Create /export volume" { logical_volume { mount_point = "/export" largefiles = true _hp_disk_layout == "Logical Volume Manager (LVM) with HFS" {

usage = HFS blksize = _hp_HFS_blksize fragsize = _hp_HFS_fragsize } else { usage = VxFS blksize = _hp_VxFS_blksize } size = remaining | 100Mb _hp_root_grp_striped == "YES" { stripes = * stripe_size = _hp_FS_stripe_size } } }

The /home volume always gets defined and has a rather small size with no minimum, going up to 20MB.

logical_volume { mount_point = "/home" largefiles = true _hp_disk_layout == "Logical Volume Manager (LVM) with HFS" { usage = HFS blksize = _hp_HFS_blksize fragsize = _hp_HFS_fragsize } else { usage = VxFS blksize = _hp_VxFS_blksize } size = remaining | 20Mb _hp_root_grp_striped == "YES" { stripes = * stripe_size = _hp_FS_stripe_size } } } # root group } # Volume Manager disk layout.

The following special variables are used by Ignite-UX to control aspects of the installation or recovery. The "Special variables" section describes all of the special variables in detail.

# Set the variables that are recognized by the UI as invisible # so that they don't show on the "Additional" screen: _hp_locale visible_if false _hp_cfg_detail_level visible_if false _hp_pri_swap visible_if false _hp_min_swap visible_if false _hp_disk_layout visible_if false _hp_default_cur_lan_dev visible_if false _hp_default_final_lan_dev visible_if false _hp_keyboard visible_if false _hp_root_disk visible_if false _hp_boot_dev_path visible_if false

If _hp_disk_layout is one of the volume manager values then you allow some things to become visible in the Additional button from the Basic tab in the Ignite-UX GUI. Some of these control some of the configuration that you have already looked at. They are only applicable if you are using a volume manager, so the else construct makes sure that none of them can be seen on the Additional button.

_hp_disk_layout == "VERITAS Volume Manager (VxVM) with VxFS" | _hp_disk_layout == "Logical Volume Manager (LVM) with HFS" | _hp_disk_layout == "Logical Volume Manager (LVM) with VxFS" { "Create /export volume" visible_if true "Create separate volumes (/usr, /var, ...)" visible_if true _hp_sec_swap visible_if true _hp_root_grp_striped visible_if (_hp_root_grp_disks > 1) _hp_root_grp_disks visible_if true } else { "Create /export volume" visible_if false "Create separate volumes (/usr, /var, ...)" visible_if false _hp_sec_swap visible_if false _hp_root_grp_striped visible_if false _hp_root_grp_disks visible_if false }

The following sw_sel definition adds some impacts and enables the addition of the impacts to the file systems to take into account file system usage caused by the installation. When the visible_if variable is set to false the sw_sel definition does not appear in the Ignite-UX GUI; this variable is preset to true so the impacts always affect the installation.

# # In order to more accurately specify the software impact to # specific volumes that normally do not have files loaded # directly, but get created by scripts, we specify some # typical sizes here so the disk space is accounted for. # init sw_sel "impact by scripts" { sw_source = "core" visible_if = false impacts = "/var" 60Mb impacts = "/stand" 20Mb } = TRUE

The following configuration statements add a selection to the Additional button that enables the user to control the use of autoboot. Ignite-UX normally runs no matter what the autoboot flag is set to (refer to setboot(1M)). It forces it on if it was off, then later turns it back off for the final reboot when the system would normally come back. This configuration enables the user to manually boot the system when autoboot is disabled.

Ignite-UX normally forces the system to perform the first reboot automatically when rebooting from the installation kernel to the newly created or recovered kernel. This reboot is forced no matter what the autoboot flag is set to (refer to setboot(1M)). Ignite-UX forces it on if it was off; prior to the final reboot Ignite-UX returns the autoboot flag to off. If _hp_force_autoboot is set to NO and the system’s autoboot flag is not set to on, the system does not perform a reboot.

Important:

If you disable autoboot and then install a system, the system never

utes a final reboot without manual intervention. HP does not

exec

support booting into any other mode than the default multi-user run level at this point. The installation or recovery session has not yet completed and some steps must still be performed by Ignite-UX. Booting into anything other than the default run level does not allow the installation or recovery to complete. This is the intended behavior of Ignite-UX and not a flaw. In general (except when investigating Ignite-UX issues on advice from HP Support), you should never change the value of the _hp_force_autoboot variable.

# # Variable to give user control over the use of setboot. When the variable # is YES, autoboot is set before the first reboot and restored after the # first reboot. When the variable is NO, autoboot is never changed. # enum _hp_force_autoboot _hp_force_autoboot = { "YES", "NO" } init _hp_force_autoboot = "YES" _hp_force_autoboot help_text "Force Ignite-UX autoboot?"

The following example enables you to set, using the Additional button, whether the final system uses DHCP to obtain an IP address and hostname once it is installed or recovered. Ignite-UX uses DHCP to get initial networking information (you must disable DHCP [disable_dhcp=true] in the installation file system to stop a system booting over the network from using DHCP to obtain an IP address and hostname).

# # Variable to give user control over DHCP. # If YES, then DHCP is turned off on the system. # enum _disable_dhcp _disable_dhcp = { "YES", "NO" } init _disable_dhcp = "NO" _disable_dhcp help_text "Disable DHCP?" _disable_dhcp == "YES" { DISABLE_DHCP=TRUE }

In the next example, you can configure the value of _hp_addnl_fs_free_pct. The variable is defined as a list of values that can be selected from the Additional button. If an enum had been placed before the _hp_addnl_fs_free_pct you would only be able to select a value from 0 to

10. Instead, you can select a value from 0 to 10 or enter another value when changing the variable using the Additional button.

# # JAGae82704 fix. Variable to give user control over the amount of # free space left over in a logical volume. It defaults to 10. The # range provided if you click on the button is from 0-10, but a larger # value can be entered directly in the field if desired. # _hp_addnl_fs_free_pct = { 0,1,2,3,4,5,6,7,8,9,10 } init _hp_addnl_fs_free_pct = 10 _hp_addnl_fs_free_pct help_text "Additional free space %"

The last part of configuration accomplishes several things:

1. Sets the os_release attribute for the swinstall command line.

2. Makes sure that _hp_os_bitness is set and set correctly (it should be set by the configuration

file that defines the core operating system depot or archive sw_sel clause).

3. Makes sure that the system can run the bitness of HP-UX.

4. Sets the operating system Name attribute for the swinstall command line.

################################################################# # Ensure that the swinstall command line used contains the correct pose_as # attributes for the type of system being installed. # sd_command_line += " -x os_release=" +

(_hp_os_bitness == "64") { (!can_run_64bit) { ERROR += "This system model: \"" +${model}+ "\" is not supported for running 64bit HP-UX, you must select the 32bit selection" } sd_command_line += " -x os_name=HP-UX:64 " } else { (_hp_os_bitness == "32") { (!can_run_32bit) { ERROR += "This system model: \"" +${model}+ "\" is not supported for running 32bit HP-UX, you must select the 64bit selection" } sd_command_line += " -x os_name=HP-UX:32 " } else { ERROR += "The _hp_os_bitness variable is not set to \"32\" or \"64\". This variable must be set in the config file that supplies the core archive or depot. If using an archive, make sure you start with the core11.cfg example config file. When using a depot, make_config will set this automatically." } } _hp_os_bitness visible_if false

${release}

You should exercise care when setting the value of sd_command_line in any other configuration file because the os_name and os_release variables are required to install software correctly during an initial installation. Using = rather than += to add an option to sd_command_line removes any current settings from sd_command_line.

Analyzing the HP-UX default B.11.31 cfg clause

The following is from a default /var/opt/ignite/INDEX showing the configuration files referenced by the default HP-UX B.11.31 cfg clause:

Concatenates two strings together using the + operator. For more information, refer to instl_adm(4).

cfg "HP-UX B.11.31 Default" { description "This selection supplies the default system configuration that HP supplies for the B.11.31 release." "/opt/ignite/data/Rel_B.11.31/config" "/opt/ignite/data/Rel_B.11.31/hw_patches_cfg" "/var/opt/ignite/config.local" }

Of course, by itself, this can’t be used to install a system as it doesn’t have a configuration file referencing any software to be installed.

This section describes the per release configuration file

/opt/ignite/data/Rel_B.11.31/config

and explains what is happening and why certain things have been done in certain ways.

Please note the following text from the Ignite-UX C.7.0 release notes:

- Default file system sizes, primary swap size and other default system configuration settings have been changed in HP-UX 11i v3 as compared to prior HP-UX releases. This was important to better adjust to Operating Environment software and computer system hardware. Futher tuning of these configuration defaults may be done in a future Ignite-UX release. As before, it may be necessary or appropriate to create custom configurations specific for your systems. Such custom configurations or recovery configurations will not be affected by future default configuration tuning.

The configuration presented in this section may not match that provided with Ignite-UX revisions greater than C.7.0, please be careful if you rely on the information provided here and ensure it is consistent with the release of Ignite-UX you are using.

The release-specific configuration file

The config file defines all of the file system and volume management configurations for the release (and a few other things). This description is based on the release-specific config file from Ignite-UX version C.7.0.

########################################################################## # config: # # This file contains the default system definitions used during a # cold-install of HP-UX. This file should not be modified. If # modifications are needed, the file "config.local" should be modified # instead. # See the instl_adm(4) man page for details. # # Changes to this file will not be preserved if the fileset is re-installed. # # If you are editing this file via the advanced options during a # cold-install, then notice that the "config.local" contents are appended # to the end of this file. # # @(#) config $Revision: 10.11 $

The release k

eyword is probably the single-most important keyword in an Ignite-UX configuration file. This keyword must be set or else any installation of HP-UX is likely to fail or not work properly. Ignite-UX has no idea what version of HP-UX it is installing unless it is set.

As of Ignite-UX C.6.0.x, the release keyword is checked against the value of the

_hp_ikernel_os_release variable (the client creates the value of this variable in the host.info file). If the HP-UX release in the release keyword is not supported by the kernel

version given in _hp_ikernel_os_release, the installation is not allowed to proceed and the following error appears:

ERROR: The version of HP-UX you have chosen to install on the system (B.11.31) is not supported by the version of the Ignite-UX install kernel that the system booted (B.11.23). You will need to reboot the target system from an install kernel matching the desired release from the menu at the console. If using the bootsys command, use the '-R' option to specify the install kernel version.

Therefore, if you boot the B.11.31 installation kernel, you can’t install HP-UX B.11.11 or B.11.23, you can only install HP-UX B.11.31.

When you create custom configuration files and do not plan to include the default configuration files you must set this variable.

release="B.11.31"

In this section we have some HP-UX 11i v3 restrictions that Ignite-UX enforces via configuration.

HP-UX 11i v3 does not support any HP9000 workstations, so the first test checks to see if the system being installed is a PA-RISC system, and then checks to see if the hardware model starts with 9000/7 followed by one or more of any character. If this is true, an error will eventually be shown to the user saying “HP-UX B.11.31 does not support 9000/7xx workstation systems”.

The second thing that is enforced relates to memory. HP-UX 11i v3 requires a minimum of 1GB of memory in order to be installed. If the system contains less than 950MB of memory, you will eventually see an error saying “HP-UX B.11.31 requires at least 1GB of system

memory” and you will not be allowed to continue the install.

####################################################################### # Release supported configuration checking for unsupported configs # that are easy to recognize. # is_hppa { HARDWARE_MODEL ~ "9000/7.*" { error += "HP-UX " + ${release} + " does not support 9000/7xx workstation systems." } }

( memory < 950MB ) { error += "HP-UX " + ${release} + " requires at least 1GB of system memory." }

Sometime ago, changes were made to Ignite-UX to increase the block and fragment sizes for VxFS and HFS file systems. This can lead to differences between systems installed in the last few years

and mu

ch older systems that had smaller default block and fragment sizes. (For example, the file system attributes are different so the block and fragment sizes from older systems are probably smaller.)

The use of <variable> visible_if false ensures that the variables do not appear in the Additional dialog box from the Basic tab.

####################################################################### init _hp_HFS_blksize = 65536 # HFS block size. init _hp_HFS_fragsize = 8192 # HFS frag size. init _hp_VxFS_blksize = 8192 # VxFS block size. init _hp_FS_stripe_size = 64Kb # File system stripe size.

This section defining the EFI and HPSP partitions for HP Integrity servers is the same as it was for HP-UX B.11.23.

The test around the section ensures that partition sizes are only defined for HP Integrity systems. The variable _hp_efi_partition_size is given a set of values it can have. Note that it is not defined as an enum, so although there is a list of values to choose from, you can still set the size of the EFI partition directly if you want a very specific size. The _hp_efi_partition variable is then given an initial (default) size, and then given some help text to make it easier to understand what is does on via the additional screen.

Note that on the additional screen sizes appear in KB not MB, so although the size is defined in MB you will see the size in KB when in itool.

For the service partition size we have some configuration that looks almost identical to the EFI partition size we’ve already discussed.

####################################################################### # Set the boot disk's EFI boot partition and HP Service Partition (HPSP) # sizes. The EFI boot partition may actually hold the HP-UX kernel at # some point in the future. The HPSP hold off-line diagnostics and dump # information related to machine state (clearly not a full memory dump). # A zero size (no HPSP) should probably be kept as an option. # is_ia64 { _hp_efi_partition_size = { 500Mb, 1000Mb, 2000Mb, 4000Mb } init _hp_efi_partition_size = 500Mb _hp_efi_partition_size help_text "EFI Boot Partition (KB)" _hp_service_partition_size = { 0Mb, 400Mb, 1000Mb, 2000Mb, 4000Mb }

init _hp_service_partition_size = 400Mb _hp_service_partition_size help_text "HP Service Partition (KB)" } else { _hp_efi_partition_size visible_if false _hp_service_partition_size visible_if false }

The following shows the start of a definition for the _hp_disk_layout variable, which is set to one of several possible values depending on if this is a HP9000 or HP Integrity system.

Around the _hp_disk_layout is a test for is_ia64 and is_hppa (is HP Integrity or PARISC/HP9000 system). Disk layouts specific to those different types of systems are defined. The reason for converting some of the string for backwards compatibility is that older custom configuration files may refer to the names previously used for a disk layout. This would break those older configuration files, so the new names that appear in itool for the disk layouts are mapped to the older names for compatibility with older configuration files.

You actually get to see the value of the variable _hp_disk_layout when you use the Ignite-UX GUI. The values currently assigned to _hp_disk_layout are shown on the File System: list on the Basic tab. The form used in the next example to initialize a list of possible values allows the Ignite-UX GUI to modify the list later.

Further in the configuration file, when giving _hp_disk_layout a final value, you only assign its value using init. When using the form "init _hp_disk_layout="…", the Ignite-UX GUI is still allowed to modify the value. If you instead define "_hp_disk_layout="…"" without the init, the Ignite-UX GUI cannot change this value. If the Ignite-UX GUI were not able to change the value of _hp_disk_layout, no changes made in the Ignite-UX GUI to file system attributes are applied to the system

This is because the Ignite-UX GUI must change the value of _hp_disk_layout to "Modified LVM Layout", "Modified VxVM Layout", or "Modified Whole-Disk Layout" when changes have been made on the File System tab in the Ignite-UX GUI. If the Ignite-UX GUI is not allowed to change the variable, you cannot keep any file system customizations. This concept becomes very important when creating custom configuration files.

####################################################################### # Any _hp_disk_layout variable setting besides those below will disable # the default disk layout described in this file. This can be # done if a custom disk layout is defined elsewhere. # is_ia64 { _hp_disk_layout = { "VERITAS Volume Manager (VxVM) with VxFS", "Whole disk with VxFS", "Logical Volume Manager (LVM) with VxFS" } }

# For PA architecture only is_hppa { _hp_disk_layout = { "Whole disk (not LVM) with HFS",

The itool command Ignite-UX GUI accepts changes to file system attributes and does not caution you, but no file system

attribute changes made in the Ignite-UX GUI are applied to the system.

"Logical Volume Manager (LVM) with HFS", "Logical Volume Manager (LVM) with VxFS", "VERITAS Volume Manager (VxVM) with VxFS" } }

# convert strings for backwards compatibility (_hp_disk_layout == "Whole disk (not LVM) with VxFS") { _hp_disk_layout = "Whole disk with VxFS" }

(_hp_disk_layout == "VxVM with VxFS") { _hp_disk_layout = "VERITAS Volume Manager (VxVM) with VxFS" }

Here the variable _hp_disk_root is set to the value of _hp_primary_path, assuming that the device _hp_primary_path points to exists and _hp_root_disk does not already have a value. An Extended Regular Expression (ERE)

value

####################################################################### # Set the default root disk to the current primary path. # The _hp_primary_path will be "" if it was set to a # non-existent dev. Do not change the root disk variable # if it's already set. The '~' operator is used instead # of '==' to deal with the variable not yet being defined. # (_hp_primary_path != "" & !(_hp_root_disk ~ ".*")) { init _hp_root_disk = _hp_primary_path }

is used to see if _hp_root_disk is set to any

The definition of swap has changed significantly in this release-specific configuration file in order to deal better with two issues – large memory configurations and large disk luns. Systems containing very large memory configurations and very large disk luns (or JBODs) should be commonplace with HP-UX B.11.31, so the definition of primary swap takes both of these factors into consideration.

####################################################################### # Default (recommended) swap size for very small memory systems is # two times memory. Swap size needs to be reduced if available disk # space is limited. As system memory space increases it may or may # not be necessary to increase swap size. Some systems may run using # only system memory and little additional swap space. For some system # application loads additional swap space may be needed. By default # little additional swap space is added for large memory systems. # # Note that the swap size should be a multiple of 64MB to avoid a UI # adjustment warning.

For more information regarding EREs, refer to regexp(5).

The ERE ".*" means zero or more of any character so it matches a zero length string.

Altho

ugh we cover effects relationships in other places, it is worthwhile revisiting it again. Normally, once a value is worked out for a variable it is not reevaluated again. Effects relationships set relationships between values, so when one changes the other is forced to be reevaluated. The effects relationships below cause _hp_pri_swap to be reevaluated whenever the size of the root disk changes, or when the disk layout is changed.

# The next two statements are used only to establish an effects # relationship between the _hp_pri_swap variable and _hp_root_disk & # _hp_disk_layout variables. The value is overwritten below. # This makes the UI change the swap anytime either of these two # values change. init _hp_pri_swap = disk[_hp_root_disk].size init _hp_pri_swap = _hp_disk_layout

Now we have a sanity check based on the size of the root disk. If it is less than 9GB, and primary swap is more than 1GB, and it is the only disk in the root volume or disk group, an error will be given that will force you to change the size of primary swap to be 1GB or less. Note that lgnite-UX won’t set primary swap to more than 1GB under these circumstances - this sanity check is here to prevent it from being set manually.

# Recognize swap size being set too large for the root volume config. ( disk[_hp_root_disk].size < 9000MB & _hp_pri_swap > 1GB & _hp_root_grp_disks == 1 ) { error+="Primary swap size is too large for root disk. Reduce primary swap size to 1GB, add disks to root volume / disk group, or use a larger disk." }

Here we set the size of primary swap. Primary swap is sized this way because on lower memory configurations you are more likely to allocate or use device swap, so more swap is required compared to the size of memory. Ignite limits the size of primary swap to 8GB.

# Start with 2x or cap on swap based on memory size ( memory < 4GB ) { init _hp_pri_swap = (((memory * 2) + 65535KB)/64MB)*64MB } ( memory >= 4GB ) { init _hp_pri_swap = 8GB }

In this section we adjust the size of primary swap for a small root disk. If you only have one disk in the root volume or disk group, and it is less than 9GB in size, primary swap will be set to 1GB. The second part of the configuration checks if the size of the root disk is between 9G and 18GB. Then, if the size of memory is greater than or equal to 4GB, primary swap will be set to 4GB. Otherwise it will be set to 2GB.

# Adjust swap size to deal with small disks. ( disk[_hp_root_disk].size < 9000MB & _hp_root_grp_disks == 1 ) { init _hp_pri_swap = 1GB } ( disk[_hp_root_disk].size >= 9000MB & disk[_hp_root_disk].size < 18000MB ) { ( memory >= 4GB ) { init _hp_pri_swap = 4GB } else { init _hp_pri_swap = 2GB

} }

Here we set up an effects relationship between _hp_min_swap and _hp_pri_swap. That is followed by some final adjustments to the size of primary swap based on the size of the root disk and the amount of memory in the system. Depending on the size of the root disk and the amount of memory in then system, Ignite-UX will attempt to place a sensible lower bound (_hp_min_swap) on the size of primary swap.

# The next statement is used only to establish an effects relationship # between the _hp_pri_swap variable and _hp_min_swap variable. The # value is overwritten below. This ensure that changes will be handled # correctly. Depending how _hp_min_swap is calculated it may not change # due to UI changes. init _hp_min_swap = _hp_pri_swap

# Adjust swap size to deal with a lot of system memory ( memory < 16GB) { _hp_min_swap = 1GB } ( memory >= 16GB & memory < 64GB) { _hp_min_swap = 2GB } ( memory >= 64GB) { _hp_min_swap = 4GB }

Now _hp_sec_swap and _hp_pri_swap are initialized with a set of values that can be chosen from; however, they are not a fixed set of values. The variable _hp_sec_swap can be set using the Additional button because of the way the variable was defined (<variable>={ value1, value2, … }). The variable _hp_sec_swap has its value set from a selection list or by typing it into the corresponding field directly. This can happen because _hp_sec_swap was not defined as an "enum"; if it had been defined as an enum only a value from the list of values it contains could be used.

Although, in this configuration, hp_pri_swap cannot be modified using the Additional button. This value appears directly in the Ignite-UX GUI on the Basic tab using the Root Swap (MB) button, and it allows you to select from a list of possible values. The list of values shown in the selection list for _hp_pri_swap comes from the list defined in the configuration. If you create a custom disk configuration file, you should supply a value or a list of values for _hp_pri_swap (or somehow otherwise calculate a default value for it).

Note that large values can be used for primary and secondary swap. From Ignite-UX version C.7.0 onwards, HP-UX 11i v2 and later releases of HP-UX are no longer limited to 32GB swap spaces.

# Note that 0 (zero) is not a valid size for primary swap _hp_pri_swap = { 1GB, 2GB, 4GB, 8GB, 16GB, 24GB, 32GB, 48GB, 64GB, 98GB, 128GB, 192GB, 256GB }

_hp_sec_swap = { 0GB, 1GB, 2GB, 4GB, 8GB, 16GB, 24GB, 32GB, 48GB, 64GB, 98GB, 128GB, 192GB, 256GB }

init _hp_sec_swap = 0Mb

_hp_sec_swap help_text "Secondary Swap space (KB)"

From here we are going to be looking at the disk layouts. Some parts of the disk layout have changed significantly for HP-UX 11i v3.

####################################################################### # Determine disk layout for volumes and file systems. #

You should have noticed by now that for HP-UX 11i v3, all of the tests related to legacy HP9000 systems have been removed. None of these systems can run HP-UX 11i v3 (they couldn’t run HP-UX HP-UX 11i v2 either) so all of the tests are gone.

The next example gives _hp_disk_layout a value of disk [_hp_root_disk].model. If the value of that expression changes, it causes the value of _hp_disk_layout to be re-evaluated.

Doing this makes good sense in the context of this configuration file, because if you change the root disk, you may need to re-evaluate what the disk configuration is. After that, we set the default disk layout to be LVM with VxFS.

# Default disk layout init _hp_disk_layout = "Logical Volume Manager (LVM) with VxFS"

Without defining _hp_root_grp_striped as an enum, the user would be able to select YES or NO on the Additional button, or also enter any value. In this case, it does not matter because the configuration only tests on the value YES (later) to decide on an action. If you could enter a lowercase "yes", the tests would fail; hence the enumeration type is used.

# Boolean describing whether or not the root disk group # will be striped # enum _hp_root_grp_striped _hp_root_grp_striped = { "YES", "NO" } init _hp_root_grp_striped = "NO" _hp_root_grp_striped help_text "Stripe root VG disks?"

The expression in the next example defines a use model. Use models are not variables; they are true / false expressions that are used to control how things are done

. Like variables, use

models can be viewed using the Additional button of the Basic tab in the Ignite-UX GUI. In the

Unfortunately, variables cannot have effects relationships with use models or software selections.

Additional d

ialog box, use models look visibly different from variables. Later in the configuration

file is the impact statement this use model would have when it is set to true.

INIT "Create /export volume" = false

Now you have another effects relationship, this time between a new variable _hp_root_grp_disks and _hp_root_disk. The variable _hp_root_grp_disks is meant to be an integer, so when doing the effects relationship you add zero (0) to disk[_hp_root_disk].size to ensure that the final value is an integer. Since variables are not explicitly typed, you want to imply an integer type.

The variable _hp_root_grp_disks is also an enum; it can take one of the values from 1 up to the value of variable num_disks,

and it has a default initial value of 1.

That is followed by the usage model "Create separate volumes (/usr, /var, ...)". This is used to decide if there will be only one large root file system or if separate file systems will be created (it would be unusual to set this to FALSE).

# Number of disks in the root volume group # The fist line below is just to define an "effects" relationship # between the root disk and _hp_root_grp_disks which dependent # upon each other in the logic to follow. # init _hp_root_grp_disks = (disk[_hp_root_disk].size+0) # +0 convert to int enum _hp_root_grp_disks _hp_root_grp_disks = { 1..num_disks } init _hp_root_grp_disks = 1 _hp_root_grp_disks help_text "# of disks in root VG"