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.

+ 183 hidden pages