The intended audience for this material is an HP-UX System Administrator
responsible for managing a large replicated site of technical
workstations. Some characteristics of large replicated sites are 1)
10s to 100s of identical systems in a large network, 2) a network
broken up into application, data, NIS, and maybe even $HOME directory
servers, and 3) multiple target system configurations exist to support different
engineering disciplines (EECAD, MECAD, SWCAD, etc).
Ignite-UX Product Overview:
The Ignite-UX (IUX) design is based on most of the basic mechanisms that it's predecessor, Cold-Install used. The basic goal is to boot a system from an independent device (network, CD-ROM, tape) in a self-contained environment, such that it can configure the file systems on a disk and lay down a fresh copy of the HP-UX operating system.
The process of booting the system to be installed (often referred to as a client, or a target) involves booting an HP-UX kernel which in turn loads into memory a small RAM-disk file system (INSTALLFS). This file system is mounted as the root file system and the kernel continues to boot by running "init" from within the file system. The "init" command turns out to be the first phase of the installation/Ignite-UX application.
Once booted, the Ignite-UX application can either interact with the user via the User Interface (UI) or, in non-interactive mode, contact the install server where it may find a previously specified configuration.
HP-UX Cold Install has always supported a UI, run on the client, that gathered information on how the system should be configured. In the case of a network install, the install server supplied the configuration instead of having the user rely on media. A concept that is new with Ignite-UX is an enhancement to the install server that provides the ability for the server to run a graphical user interface (GUI) while the client is booted, such that the client can be configured and monitored from the server. This model allows multiple clients to be installed from a central server, and for that server to act as a repository for configuration information that can be modified, saved, and reused for later clients.
The Ignite-UX client is booted in such a state that it waits for the
server to instruct it how and when to do the installation. When the
server responds, the two systems will communicate via NFS. The client
will NFS mount the /var/opt/ignite/clients directory of the server and
provide status information that the server can pick up and read. The
server will in turn write a file that contains instructions for the
client. The client will also provide log files and manifest
information that may be printed and analyzed from the server.
Test Network
To assist in the reader's understanding, this paper will reference the following test network layout:
IUX Server IUX Target IUX Target
----- ----- -----
| | | | | |
----- ----- -----
| | |
| | |
-------------------------------------------------
Hostname: interop1 hp_target1 hp_target2
IP address: 15.2.72.150 15.2.75.14 15.2.75.15
This chapter will cover:
WARNING: Ignite-UX is a replacement for the Net-Install product. If your server contains the Net-Install bundle (HPUX-Install product), Ignite-UX will require that the NetInstall bundle be removed (using swremove), or that you touch the file /tmp/okay_to_remove_net_install before loading Ignite-UX, in which case loading Ignite-UX will automatically remove the NetInstall software.
Step 1) Load the Ignite-UX software
You have the option of loading the entire B5724AA_APZ (Ignite-UX) product, or you can load the "Ignite-UX-10-20" product if you plan on only using Ignite-UX to load software for HP-UX 10.20 systems. In our network, the software depot for Ignite-UX was located at hpfclc.fc.hp.com:/release/Ignite-UX:
# swinstall -s hpfclc.fc.hp.com:/release/Ignite-UX B5724AA_APZ
Step 2) In your login scripts add /opt/ignite/bin to your default search path:
# export PATH=${PATH}:/opt/ignite/bin
The majority of the Ignite-UX server configuration is performed by the product installation post-process procedures, but there are a few site-specific configuration steps you will need to perform. These are centered around the specification of available IP addresses and hostnames.
You can note that the Ignite-UX installation has added 2 services to your /etc/inetd.conf file; tftp, and instl_boots.
# /opt/ignite/bin/ignite
Note: You will get a warning screen stating no clients exists. In this situation, this is normal since you really do not have any clients waiting.
If you get the following error message:
ERROR: This machine is not an NFS server (no nfsd running).
The -n option will not be processed.
you did not follow the installation instructions properly. The Ignite-UX server must be an NFS server. Exit Ignite-UX, and make the Ignite-UX server an NFS server before continuing. You can do this by using "sam", or by editing /etc/rc.config.d/nfsconf and setting NFS_SERVER=1 and rebooting. If you do not get the above error, you can note that Ignite-UX has modified your exportfs to include /var/opt/ignite/clients directory:
# exportfs -v
/var/opt/ignite/clients -anon=2
This directory is exported to allow remote "root" users to write to the client's directory. This is required for proper Ignite-UX operations. You may need to export additional directories - for example if you use NFS to transfer your archive, it must be NFS accessible.
Step 2.1) Select "Options->Server Configuration"
This will show the Server Configuration Menu with two tabs; "Server Options", and "Session Options". Under "Server Options" tab, do the following:
Modify (if needed) the Server Options to match the following:
Default Configuration: HP-UX B.10.20 Default
Default Printer: <select a default printer to be
used by IUX>
Client Timeouts: 40 [this is the number of
minutes delay due to
network, or client failures before
the IUX server will inform the
administrator of a problem]
Run client installation UI on: server
[most administration of the install
process to be performed only on the
IUX server]
Step 2.2) Select "Add booting IP Address"
During the install process, the clients need to do a network boot from the Ignite-UX server. In order to do this, the clients need to be given a temporary IP address.
Under "Booting Clients", provide an initial range of available IP addresses. The following example will allow Ignite-UX to perform 20 simultaneous installations. This IP address is only used when booting over the network during the initial transfer of the kernel to the client. You may only need 1 or 2 addresses depending on how many systems do network boots at the same time. (See instl_bootd(1M)). If you need to changes these addresses later, you will need to edit the /etc/opt/ignite/instl_boottab file directly.
15.2.73.1 15.2.73.20
Unless you are familiar with DHCP services, for this exercise, do not modify the DHCP Class ID, or the DHCP Addresses are temporary field. The DHCP service is only used for client configurations which do not have predefined system hostnames, and IP addresses.
Provide a range of available "permanent" IP address. These can only be supplied once here in Ignite-UX. After the initial definition, further modification will need to be perform using SAM "Networking and Communications->Bootable Devices" area. In our network, we used the following IP addresses.
15.2.73.21 15.2.73.40
Step 2.3) Configure Ignite-UX Session Options
Under "Options --> Server Configurations":
Select "Session Options" tab, and for this exercise ensure only these items are selected:
-> Confirm new clients
-> Show the welcome screen for the install server
You may wish to de-select the "Ask for customer information", as this installation information is more geared to HP and HP distribution-partner manufacturing.
There is nothing that needs to be done to the target system to allow it to use Ignite-UX.
If the target system is currently running any version of HP-UX 9.x
or 10.x, the target system can be remotely controlled by the
Ignite-UX server. The Ignite-UX bootsys command can be used to
perform a target system shutdown, and re-set the target
networking parameters after the OS installation.
If the target system is not currently running HP-UX, then a manual network boot will need to be performed on the target. Reboot the target, press <esc> to interrupt the boot process, and then perform the network boot from the Ignite-UX server:
> boot lan.15.2.72.150 install
where the above IP address is the IP address of the Ignite-UX server.
Note that this process and command may be slightly different on your target system, depending on the age of your hardware. You'll need to be familiar with your system boot commands.
This chapter will cover:
In this test scenario, we will create a "golden image", which is a snapshot of a known good installation tar or fpio file which we want to copy to other systems. The system we will copy is referred to as the "golden system", which will then be distributed to the clients. The golden image will be known as the "OS archive". We will explain how an OS archive is created, and placed under Ignite-UX control. We will then add applications and patch bundles specific to that OS archive. Note that Ignite-UX does not require us to create an OS archive to install a new client OS, we have chosen this mechanism because it's quicker to install an image than to go through the swinstall process. The OS archive method can decrease new OS installations to under 30 minutes.
The configuration file structure used by Ignite-UX is well documented
in the instl_adm(4) man page. In the next pages we'll be modifying a
number of config files, but the key one, which is read first to
determine what software is available, is the /var/opt/ignite/index
file. This file will point to additional files which will further
specify options and configurations, but the INDEX file is the "root".
Read the man page for specifics.
Once you have a golden system with the base OS, Ignite-UX has a facility to create an OS archive. Note, it is up to the administrator to define exactly what constitutes a golden system. Some admins will chose to place patches, applications, kernel configurations, etc. on the golden system, others will only place the core OS. In our example, we only placed the core OS. In general, for speed, you will want to place all of your common applications, patches and tools onto the golden system.
Ignite-UX is capable of installing systems from SD depots as well as archives. You may want to use this capability when setting up your "golden system" since you will need to have a system installed somehow before you can get an image. See Appendix A for details.
The make_sys_image command is provided to assist in creating the OS
archive. Refer to the make_sys_image(1m) man page for details. The
command is located under /opt/ignite/data/scripts.
NOTE:
/var/tmp is the default location that
make_sys_image stores the archive image. You can also have it
save the image to a remote server that allows remote access from this
client. Which ever method you choose, you will need to have
sufficient disk space to hold the image. The amount of disk space
will be approximately 1/2 the amount of data contained on your golden
system (assuming about 50% compression ratio provided by gzip).
Step 1.1: Copy /opt/ignite/data/scripts/make_sys_image to /tmp on the
golden system, and make sure it is executable.
WARNING: While make_sys_image is running the system should
not be in use. Device files are removed, and the host and/or
networking information on the system are reset. After the
command is complete these files are put back with the
exception of most *log files.
Step 1.2: On the golden system run /tmp/make_sys_image [options].
NOTE:
By default, this will create a gzip-formatted archive in
/var/tmp with the name "hostname.gz" on the Ignite server (if it can
be determined and the client has access). Also by default, all specific
host information, device files, log files, and network information will
be removed.
OPTIONALLY: If you do not have enough disk space, or you would like for the archive to be created on a remote server, you may use the following options:
# /tmp/make_sys_image -d <directory_to_place_archive> \
-s <ip_address_of_system_to_place_archive>
# /tmp/make_sys_image -d /var/opt/ignite/archives/Rel_B.10.20 \
-s 15.2.72.150
Step 1.3: On the Ignite-UX server, create an archives directory to store the golden image. It is best to keep the naming conventions Rel_B.10.20 (or whatever your release is). This directory will need to be NFS exported if you'll be using NFS to transfer the archive to the target.
# mkdir /var/opt/ignite/archives
# mkdir /var/opt/ignite/archives/Rel_B.10.20
Step 1.4: Move the OS archive to
/var/opt/ignite/archives/Rel_B.10.20/file.gz .
In this first release of Ignite-UX, there are no tools to assist in the creation of configuration files for an OS archive. This is a high priority for the second release. In the interim, an example configuration file is supplied with Ignite-UX, and it's modification is fairly straight forward.
Step 2.1: Use examples/core.cfg to create OS archive's configuration file
Step 2.1.1: Use the example config file to create a new one for the OS archive
# cp /opt/ignite/data/examples/core.cfg \
/var/opt/ignite/data/Rel_B.10.20/core_700_archive_cfg
The /var/opt/ignite/data/Rel_B.10.20/core_700_archive_cfg
filename and path are arbitrary. You can store configuration
files anywhere on the system you chose. Ignite-UX manages the
names and locations via the INDEX file discussed in Step 2.2.
The only restriction on the location of config files and scripts
is that they be accessible via tftp.
Step 2.1.2: Modify the core_700_archive_cfg to set up the OS Archive for NFS transfer
Key Changes are as follows:
nfs_source = "15.2.72.150:/var/opt/ignite/archives/Rel_B.10.20"
(points to directory where the archive lives, must be NFS exported)
description = "HP-UX Core Operating System Archives"
(This will now appear in the Environments section of the Ignite-UX user-interface as a menu choice).
archive_path = "hpfcnjm2.gz"
(This points to the actual archive in combination with the nfs_source line).
# /opt/ignite/lbin/archive_impact -t -g <archive_file>
Below is the complete "sw_sel" stanza. We deleted some of the extra stanzas in the example for simplicity.
init sw_sel "golden image" {
description = "Archive HP-UX 10.20 CDE"
sw_source = "core archive"
sw_category = "HPUXEnvironments"
archive_type = gzip tar
# For NFS, the path to the archive is relative to the mount
# point specified in the sw_source:
archive_path = "hpfcnjm2.gz"
# ftp/remsh sources can use a full path:
# archive_path = "/pub/IUXarchives/B.10.20_700_CDE.gz"
impacts = "/" 23Kb
impacts = "/.dt" 35Kb
impacts = "/TT_DB" 18Kb
impacts = "/etc" 1375Kb
impacts = "/export" 1Kb
impacts = "/opt" 74079Kb
impacts = "/sbin" 13449Kb
impacts = "/stand" 1Kb
impacts = "/tmp" 1Kb
impacts = "/usr" 225459Kb
impacts = "/var" 5736Kb
} = TRUE
Edit the /var/opt/ignite/index file. Here we will install a new "Configuration" to Ignite-UX. In our case we added a new "cfg" stanza as follows:
cfg "HP-UX B.10.20 archive" {
description "some description of this archive..."
"/opt/ignite/data/Rel_B.10.20/config"
"/var/opt/ignite/data/Rel_B.10.20/core_700_archive_cfg"
"/var/opt/ignite/config.local"
}
The line of most interest is the one containing the "core_700_archive_cfg", this is the config file we added in Step 2.1. The "config" and "config.local" are standard boiler-plate configurations.
Note that "/var/opt/ignite/config.local" should be last. The last config file has the highest priority to override values in prior config files.
The file "/opt/ignite/data/Rel_B.10.XX/config" supplies the disk and file-system layout defaults, plus other control information required by Ignite-UX. It must be first in every cfg stanza.
Each "cfg" stanza appears as an available configuration to Ignite-UX. Therefore, the string "HP-UX B.10.20 archive" will now appear as a valid configuration.
Step 2.3: Ensure NFS file system is exported correctly
In the above "sw_source" stanza, we specified the location of the OS archive to be a file on an NFS server. You need to ensure target systems have access to this directory.
Make sure the NFS configuration is correct. Use the "exportfs -v" command to view the current status and ensure the directory containing the archive is correctly exported. Ignite-UX will automatically try to export /var/opt/ignite/clients for its use. In our example /var/opt/ignite/archives/Rel_B.10.20 must also be exported because that is where we placed the OS archive.
Here's our /etc/exports file:
/var/opt/ignite/clients -anon=2
/var/opt/ignite/archives/Rel_B.10.20 -ro
If these are not correct, use SAM to set them up correctly.
Since the Ignite-UX server knows about your new OS archive, you can now use Ignite-UX to load the OS archive onto a target system. To do this, you need to get the target system to inform Ignite-UX that it is ready to install a new OS. There are two methods for doing this.
bootsys command to reboot the
target for which you wish to install the new OS. The
target system can be booted in a mode in which it can be
controlled by the Ignite-UX user interface.
# /opt/ignite/bin/bootsys -w -v <system_name>
This will cause the target system to boot a copy of the Ignite-UX kernel and file system that bootsys copies to the target. An icon representing the system will appear in the Ignite-UX user interface on the server when the system has completed boot. (This may take several minutes.) Only booted clients will appear as icons.
If the server cannot resolve the system_name, you
can specify to bootsys the system_name and IP address
using following syntax:
# /opt/ignite/bin/bootsys -w -v <system_name:ip-address>
> boot lan.15.2.72.150 install
Older S700's that use the RMP (rbootd) protocol instead of BOOTP
require that you use the Ethernet address of
the server, and not specify the "install" keyword:
> boot lan.080009-123456
(Replace the above IP/Ethernet addresses with the correct value for your Ignite-UX server).
In this section, we will use the Ignite-UX user interface to customize an OS install. In Chapter 3, we will discuss how this can be done with no user/administrator interaction.
Run the Ignite-UX user interface by executing the following as root:
# /opt/ignite/bin/ignite
When the target has rebooted (using the bootsys command or manual reboot), and is ready for installation, it will appear as an icon, labeled either as its original hostname (if rebooted using bootsys), or by the hostname supplied by DHCP, or at the console.
Step 4.1: Highlight the icon of the system you wish to install on.
Step 4.2: Select "Actions->Install Client->New Install"
You should now see the "itool" screen with five tabs across the top. (If you see the "System Hardware Inventory" screen simply select OK to bypass this screen).
Step 4.3: In the Basic tab (default):
Under "Configurations:" select "HP-UX B.10.20 archive".
Ensure the Root Disk, Root Swap and other fields are correct for your installation. Note that any disks you select here will be formatted! If you have a disk with existing user information you don't want to modify, add it manually after Ignite-UX has installed the OS.
Step 4.4: In the Software tab:
Because there is only an archive at this point, the screen is blank. We'll add a patch and application depot later.
Step 4.5: In the System tab:
In "Final System Parameters:" select "Set Parameters Now". Fill in the blanks with the correct data.
Also Select the "Set Time Zone", "Network Services" and optionally the "Set Root Password" and fill these in as well.
Step 4.6: In the File System tab:
Verify the correct disk usage. You can also add disks at this point or modify the disk and file system parameters. In our example we will install HP-UX on the disk at address 5 only, and leave the other disks as they were.
WARNING: A newfs will be performed on all selected disks!
Step 4.7: In the Advanced tab:
Nothing will be specified here at this time. Later we'll add post-process scripts to execute.
Step 4.8: When finished entering data, select "Go!"
A configuration dialog will appear. Make sure the data is correct, and select "Go!" again.
Step 4.9: Displaying target installation status
If you double-click on the icon of the target system in the Ignite-UX server GUI during execution, a status screen will be displayed showing the install progress.
A Note on the GUI:
Ignite-UX determines the state of a target by reading the files in the
/var/opt/ignite/clients/<LLA> directory. Seeing an icon
in the GUI does not mean that the target actually exists -- only
that its config and control files exist in the Ignite-UX directories.
We can use this behavior to our advantage to reinstall systems.
This means that if you're reinstalling a system that Ignite-UX has
already installed, you may need to re-execute the bootsys
command (or boot the client off of the Ignite-UX server).
Setting up your Ignite-UX server so that the default configuration is correct for any given system will save you time and allow you to easily automate installations. This chapter discusses setting up the defaults the way you like them, as well as setting up a configuration for a specific target system.
Ignite-UX can install an HP-UX on a target system with no additional
configuration information (the default configuration as specified in the
/var/opt/ignite/index file will be used). You can,
however, select from other configurations listed in the INDEX file on
the bootsys command line.
# bootsys -a -v <target_hostname> [-i configuration] [-f]
The -a option specifies an automatic install. The -f
option forces IUX to disregard prior configuration
info. The -i option can be supplied to select an
alternate configuration. If not set, the default is
used. See bootsys(1M) for details on how to select a
configuration and to force its use. The default is
set in the "server options" menu in the UI, or can be
set manually with the "= TRUE" statement after a "cfg"
stanza in the /var/opt/ignite/index file.
Ignite-UX will contact the target system and extract it's hostname, IP address and default gateway. The default configuration is installed. Post install, Ignite-UX will reset the hostname, IP address and gateway to their original values. (Note: remsh access to the target is required. If not available, bootsys will prompt the user for the root password on the target.)
This is the quickest way to install a system. The
drawback is that you will receive the default config,
which may have incomplete networking information unless you
are using a previously "saved" configuration, or you
specify the defaults in the /var/opt/ignite/config.local
file as shown later.
bootsys command using the -i option.
/var/opt/ignite/config.local file is normally included
in every cfg stanza in the INDEX file. This provides
a convenient location to store default parameters that
are the same for all configurations. Typically this
will be networking, default software selections, kernel
modifications.
It may be easiest to cut and paste information written to
the files /var/opt/ignite/clients/*/config by the user
interface. However there is much more that can be done
here that the GUI does not provide access to. The
instl_adm(4) man page gives all the details.
Below is an example of what a config.local file could look like.
The sw_sel's will depend on what you have defined in
config files on the server.
dns_domain="fc.hp.com"
dns_nameserver[0] = "15.2.72.2"
nis_domain="udl"
wait_for_nis_server=FALSE
root_password="rlW2xSrugUvi2"
timezone="MST7MDT"
ntpdate_server="15.1.48.11"
init sw_sel "Misc_Patches"=TRUE
init sw_sel "B3919DA_AGP"=TRUE
mod_kernel += "maxuprc 100"
mod_kernel += "dbc_max_pct 80"
Always run instl_adm -T after making manual edits to verify
that the syntax is correct.
Appendix C shows how default information may be specified dynamically depending on the target system's configuration.
bootsys (or DHCP/BOOTP) can supply the hostname and IP
address, however the netmask and gateway need to be supplied in the
ram-filesystem (INSTALLFS). This can done by using the
instl_adm(1m) command. The instl_adm command
has options to set netmask, gateway, IUX/tftp server, etc. Or you
can dump the current settings to a file and edit it, then load the
settings back. Just loading Ignite-UX sets some of the parameters.
For example, you may want to set the keyboard language
so that it never prompts you for it when booting
from the console. The file you store using
When Ignite-UX begins an install session, it scans the
directory /var/opt/ignite/clients for a directory
matching the LLA of the target system. As an example,
if the LLA of the target is 0x08000992E346, Ignite-UX looks
in /var/opt/ignite/clients/0x08000992E346 for a file
named "config". Ignite-UX keeps the last configuration installed
to the respective system in this file so
it can perform a repeat install.
If found, the configuration data in this file is used to
overwrite the default values. This file has the highest
precedence over all other config files listed in the INDEX
file.
WARNING: Ignite-UX will write over this file at
the end of the install, so keep an original copy
elsewhere.
The easiest way to create the "config" file is to use
one already built by IUX. If you've previously
installed a system (it's best to use one from a
similar system to your target,) you can find a config
file in the /var/opt/ignite/clients/history/<LLA>
directories. Use this as the basis for your new file.
Copy it to
Typically, you would want to change the networking parameters
to the correct values. For example:
The Ignite-UX user interface does not need to be running.
IUX will install the default configuration (or the
configuration specified with the -i option) and will
include the specific changes provided in the config
file.
The target system should boot into the I/UX
install process and complete the install
automatically. Errors will be reported on the client
screen and in the install.log file.
NOTES:
If you are attempting to install 10.x onto a system running an
HP-UX 9.X version, you may run into the following problem:
bootsys works by copying the Ignite-UX kernel (INSTALL) and
RAM file system (INSTALLFS) to each client and then setting
the system's AUTO file in the LIF area of the root disk to
automatically boot from this kernel at the next system reboot.
For 9.X clients, bootsys requires that the primary boot path
be set to the disk that the system is currently booted from
and that the auto-boot flag be turned on. For 10.X clients,
bootsys will set the primary boot path and auto-boot flag
(using the setboot command) to the disk it is currently booted
from.
To set the "pri path" on 9.X systems (if needed), do the
following:
Perform an attended boot (hit
This chapter will focus on ways to customize the default
configuration, either by adding additional info to the default config
(dynamic parameters) or by adding additional software selections to be
loaded after the archive.
We'll be adding:
In the following example we'll explore adding a bundle which
consists of patches, which would be a typical application.
You must begin with a patch bundle, not just a patch depot.
You can verify the existence of bundles with the following
command:
(You might need to call
The patch bundle will now show up in the software tab of the
UI install screen, but will not be marked for install (It will
be optional).
In the file
The following example will create a software selection called
"My_Kernel_Mods". It will set the following two kernel
parameters: nproc and maxuprc, and these will be force loaded
whenever the "golden image" archive is installed.
In this example, there is a set of parameters we want all
systems to have, "Basic_Kernel_Mods". These are force loaded.
There is also an optional set, "Advanced_Kernel_Mods", which
can be selected in the UI or in a config file at install time.
The contents of the /var/opt/ignite/data/Rel_B.10.20/kernel_cfg file is now:
As a simple example, we may want to set the swap space of all
machines we install using the "golden image" archive to 100 MB.
The "golden image" is defined in the file
/var/opt/ignite/data/Rel_B.10.20/core_700_archive_cfg.
If the primary swap size is not further specified in a config
file new systems will be installed with a default value of
100MB of swap space. If there is a swap value set in the
"config" file in the /var/opt/ignite/clients/<LLA> directory,
it will take precedence.
As a further example, we'll set the final DNS domain name and
IP address of the DNS nameserver of systems installed using
the "golden image".
Any number of tasks may be performed on the target system
after the OS is installed by providing a script to be run on the
target system. This chapter touches on some common examples, but
scripts can easily be written to mount additional disk drives, add
additional software, modify configurations based on system use, etc.
There are a number of points in the install process in which you can
force scripts or commands to be run. Check the instl_adm(4) man page
under the "Command and Script Execution Hooks" section for
specifics. One point to note is that the post_config_script will run
after all software has been loaded and the system has been booted with
it's final kernal, but BEFORE any of the normal /etc/rc startup
scripts have been run. Basic networking is enabled in this
environment.
Step 1: Create a script.
Create a script to perform the desired task. When Ignite-UX
runs this script as a post-configuration, it will be run on the
target system.
Step 2: Add the script to your configuration file.
Ignite-UX post-configuration scripts are defined using the
"post_config_script" variable. For example, you can place the
following line into your core_700_ftp_archive_cfg config file:
The above will define the "install_default_printer" script to
be run as a post installation process on the target system.
Note, the line should stand alone, placed OUTSIDE of any
stanza (i.e. a sw_sel stanza). By default, the script will
always be run on the targets. You can change the behavior
using the ignite user-interface in the "advanced" tab.
If you want to make a script available under all
configurations, you can add it to the /var/opt/ignite/index
file. Add the following to the end of this file:
NOTE:
Scripts are accessed by Ignite-UX via tftp. Make sure the
directory the script resides in is available to tftp by
examining and/or changing the /etc/inetd.conf file.
One task an administrator generally needs to perform
after a new OS installation is setting up printers. Here is one
method you can use to automate this process.
Write a script which performs the HP-UX commands for adding a
printer. Attached below is a script for adding a remote printer
named "printbob", and turning on the lp scheduler. We found that
the easiest method for creating the sequence of commands for the
script was to use SAM. We turned on SAM logging for
"commands-only", performed the tasks desired, and then extracted
those commands from the SAM log file.
Here is our script for adding "printbob" to all systems:
A system that is running 9.x or 10.x can use the
Ignite-UX server across a gateway if the target system is booted
via the
Step 1: To boot HP-UX across a gateway, you need a system on the
local subnet to provide the target with a minimum core
kernel. The helper system must be running
a version of HP-UX 10.x.
Step 2: Install the Ignite-UX minimum core functionality onto
the helper system:
In our environment, Ignite-UX resides in the software
depot "hpfclc:/release/Ignite-UX".
Step 4: Specify temporary IP address for the helper
On the helper, in the
Step 5: Reboot the target system, interrupt the boot sequence
by pressing <esc>, and type the following:
Essentially, the 9.05 helper machine, on the same subnet as the install
target machine(s), hosts the files necessary for network boot of the
target. Once the target has booted, it can run the remainder of the
installation across a gateway. The boot files, in addition to providing
the installation kernel and program, also direct the target to the proper
server machine on the other side of the gateway.
There are two major steps that need to be done: the 9.0X helper machine
has to be modified somewhat to host the 10.X install files, and the boot
files have to be modified on the 10.X install server and copied over to
the 9.0X helper. It is not possible to copy the boot files to the helper
first and modify them under 9.0X.
The ip_addr and system_name do not need to be (but can be) the final
values, just valid temporary values.
You could also set "final" net info (actually cause I-UX to put it
in the rc startup files) by adding additional "final" specifications
for system_name, ip_address, etc. Remember, setting a "final"
system_name will cause set_parms not to run, so all other needed
system info (timezone, routes, etc.) should probably be set along
with system_name.
This applies the changes to the INSTALLFS file.
NOTE: any further changes MUST be done on the server system and
copied over to the helper system. The 9.0X instl_adm command does
have the 10.X functionality.
To perform an installation to a different machine, repeat steps 4,
5, and 6. For a subsequent runs, only the file "INSTALLFS" needs
to be copied over to the boot helper machine in step 6.
At that point, the install should proceed, controlled from the server
by default.
Chapter 2 discusses creating an archive-image of your
golden system. We'll cover the steps for creating the
golden system itself here. In general, the golden system is
simply a system which has been configured with all the
software and customizations which will need to be distributed
to a group of target systems.
Most large HP-UX sites already have the equivalent to a golden
system, which is maintained by the IS certification or QA
department. This system is configured with customer
modifications on top of a base HP-UX system. Critical patches
which all users need are installed onto the OS. Local, common
software that all users use are also layered on the OS, and
the resulting system is tested to ensure proper operation in
the customer's environment.
In some cases, the customer may maintain a disk which is
a golden system. This disk
is copied with
These systems represent a prototype or starting point for all
users. The steps needed for install customizations are
normally captured and are well known. They make good
candidates for a golden image archive using the steps outlined
in Chapter 2. If a golden system exists, the following steps
will not be needed.
Creating a golden system from scratch normally involves the
following steps:
Step 1: IUX setup of HP-UX OS from media
This can be performed without Ignite-UX by using the normal install
from media steps. Alternately, Ignite-UX can install the OS for
you. In this example, we'll use Ignite-UX and a network depot as
the source of our software. We'll first copy an SD depot of
10.20 onto the Ignite-UX server.
On the IUX server, set up the core software to be distributed:
The make_config command will then add this software as a
configuration available for Ignite-UX installations.
Step 1.1: Installing HP-UX onto the target "golden system".
First, boot the target from the Ignite-UX server:
Step 2: Loading critical patches onto the OS
At this point you should have a target system with the basic
10.20 release. If you have patches which you wish to
distribute to all users, install them now. This is normally
done using the standard SD tools.
Step 2.1: As an example, install patch PHSS_8375.
If you've downloaded and unshar'd a patch, you will have a
depot file. For example, after downloading PHSS_8375 and
unsharing it, you be left with files "PHSS_8375.depot" and
"PHSS_8375.text". To install the patch non-interactively,
run the following:
Step 3: Load any optional HP and third-party software you want to make
available to ALL users. Keep in mind that we are creating a
golden system, and anything put on this will be distributed to
all systems installed using the golden image. You'll need to
keep in mind licensing restrictions, as well.
HP software (such as compilers) are normally loaded using SD
from media or a network SD depot. Third-party software
installation varies depending on the vendor.
Step 4: Customize the system. Perform any customizations that you
want to distribute to all users. These might include things
like customized CDE login screens, base /etc/passwd files,
additional phone tools and man pages, or corporate wide
default DNS and NIS setup. It would not include machine,
work group or site specific changes, such as gateways, user
accounts, or machine-specific networking. These will be taken
care of by Ignite-UX later.
Step 5: At this point you should have a good candidate for a golden
image. Use the steps outlined in Chapter 2
to create the
golden image and configure Ignite-UX to use it.
Ignite-UX can use an existing Software Distributor (SD) depot
to distribute additional software. This depot can be managed
separately from Ignite-UX. In this example we'll create a patch depot
containing HP-UX Patches, create a single Patch Bundle of the
contents of the depot, and then add this Bundle to an existing Ignite-UX
configuration. Note that Ignite-UX currently will only work with SD
software configured in bundles.
Obtain the set of patches you want to place and manage in an SD depot.
For example:
HP patches as delivered by the Response Center or the HP Web site
are shar files consisting of a product depot and README file.
In the above output,
If you need to add additional patches to the depot in
the future, simply unshar the patches as described above,
swcopy them into the Patches depot, and rerun the
"make_bundles" command. This will repackage the depot.
If you would like to remove a Patch from the depot,
simply use the
NOTE:
Most software distributed by HP, for example applications on
DART CD-ROMs, are already bundles and will not need (and should not be)
bundled again!
This can make configurations set up by the System Administrator
more general purpose and limit the need for multiple, slightly
differing configurations to handle minor system differences.
These decisions are specified in a C-like language and grammar
unique to IUX. The variables and syntax are documented in the
instl_adm(4) man page.
You could add the following lines to the end of the file
/var/opt/ignite/data/Rel_B.10.20/core_700_archive_cfg or to
/var/opt/ignite/config.local if you would like this to
be the default for all configurations.
This could also be added to the "config" file created for
automatic installs (see Chapter 4). Note that if the
"_hp_pri_swap" parameter is set later in the order of files
searched in the "cfg" definition, this setting will be
overwritten. The order the files are evaluated is documented
in the instl_adm(4) man page. Also be aware that the config
file used for automatic installs is overwritten as part of the
install process. Again, see Chapter 4 for details.
Add the following lines to the end of the file:
To check the syntax of all configuration files that are listed
in the /var/opt/ignite/index file you can use the command:
This example shows one way of accomplishing the task using a
post_config_script. Another way would be to create a software
selection (sw_sel) that would reference the tar archive, and then a
post_config_script (or post_config_cmd) associated with the sw_sel
that would be run only if the selection was picked for loading. Using
a sw_sel would have the advantage of making it appear in the UI as
just another software selection, and would have the sw_impact
statements to ensure sufficient file system space. For more examples,
see the files in /opt/ignite/data/examples.
WARNING:
It is up to the individual administrators to ensure the
Netscape Navigator product is appropriately licensed prior to
its installation.
Step 1) Get Netscape Navigator
Netscape Navigator is typically pulled from one of
the Netscape ftp server sites. The pulled files are gzip
compressed tar images with an encoded name similar to:
Step 2) Special Considerations for Netscape
In order to run Navigator, each user needs the correct
network preferences. Unfortunately, these preferences
cannot be defaulted, and must exist in every users
$HOME/.netscape directory. To get around this limitation,
we have supplied a "run-netscape" script. Instead of
running "netscape", the user can run a link to
"run-netscape" which will install the default preferences
at first invocation.
Step 2) Write an install and customization script
Attached below is a script we used for installing Netscape
in our environment. You will note that the script does
the following:
We named and placed our script under the following:
Step 3) Add the install script to Ignite-UX customization
Add a line similar to the following to one of your config
files (not in a stanza):
For details of adding a post configuration script, see
Chapter 5. This script will need to be accessible using
tftp.
instl_adm -f
# instl_adm defaults:
server="15.2.72.150"
route_gateway[0]="15.2.70.1"
route_destination[0]="default"
netmask[]="255.255.248.0"
# end instl_adm defaults.
kbdlang="PS2_DIN_US_English"
Using the per-target client config file:
Until now, we have discussed specifying default
parameters that all target systems may use.
If you would like to specify a specific configuration
for an individual target system, you may use the
following procedure.
/var/opt/ignite/clients/.
Edit its contents to correspond to your new system.
Here is an example config file:
cfg "HP-UX B.10.20 archive"=TRUE
_hp_cfg_detail_level="ipvs"
#
# Variable assignments
#
init _hp_disk_layout="Whole disk (not LVM) with HFS"
init _hp_pri_swap=68304K
init _hp_root_disk="2/0/1.5.0"
init _hp_sec_swap=0K
init _hp_root_grp_disks=1
init _hp_root_grp_striped="NO"
init _hp_locale="SET_NULL_LOCALE"
init _hp_keyboard="PS2_DIN_US_English"
init _hp_default_final_lan_dev="lan0"
init _hp_boot_dev_path="2/0/1.6.0"
#
# Software Selections
#
init sw_sel "golden image"=TRUE
init sw_sel "English"=TRUE
#
# System/Networking Parameters
#
_hp_custom_sys+={"Current System Parameters", "Original Defaults"}
init _hp_custom_sys="Current System Parameters"
_hp_custom_sys help_text "Final System/Networking Parameters"
(_hp_custom_sys=="Current System Parameters") {
final system_name="hpfcnjm2"
final ip_addr["lan0"]="15.2.75.14"
final netmask["lan0"]="255.255.248.0"
final dns_domain="fc.hp.com"
final dns_nameserver[0]="15.2.72.254"
TIMEZONE="MST7MDT"
is_net_info_temporary=TRUE
} # end "Current System Parameters"
final system_name="system11"
final ip_addr["lan0"]="15.2.75.193"
The values specified should be self explanatory, and
should be edited to the desired new values. It is also
possible to add kernel parameters to this file. This
is covered in Appendix C.
boot_admin commands (at bootup) or with
the lanscan(1M) command. Then create the following
directory (assuming the LLA is 0x08000992E346) and
copy in your config file:
# mkdir /var/opt/ignite/clients/0x08000992E346
# cp config /var/opt/ignite/clients/0x08000992E346/config
# chown bin:bin /var/opt/ignite/clients/0x08000992E346
# chown bin:bin /var/opt/ignite/clients/0x08000992E346/config
# bootsys -a -v <target_hostname> [-i configuration]
/var/opt/ignite/clients/0x08000992E346/install.log
boot_admin> path pri scsi.3.0
boot_admin> auto boot on
This may vary slightly depending on the vintage of the S700.
The help system of the boot-ROM interface should explain
the syntax to use.
Chapter 4: Customization
Adding an SD Bundle to the Archive Environment
Ignite-UX allows you to add patch bundles to your
configuration. These bundles can then be forced to load at
install time, or can be selectable by the user. This allows
the system admin to install the base Operating System very
quickly with an Ignite-UX archive, and still have the flexibility to
install additional software components selectively, based on
machine type or use (for example: server vs client).
# swlist -l bundle -d @ /yourdepot
Appendix B lists the procedure used to create a patch bundle
from an existing depot of individual patches.
swreg -l depot /yourdepot to
register this depot, depending on how it originated.)
/var/opt/ignite/PB
depot, run the following Ignite-UX command to create a config file
that Ignite-UX can use:
# make_config -s /var/opt/ignite/PB -a 700 -c \
/var/opt/ignite/data/Rel_B.10.20/patch_bundle_cfg
This creates the patch_bundle_cfg file which I/UX needs to
manage the install from the depot.
cfg "HP-UX B.10.20 archive" {
description "The ARCHIVE B.10.20 release with patches."
"/opt/ignite/data/Rel_B.10.20/config"
"/var/opt/ignite/data/Rel_B.10.20/core_700_archive_cfg"
"/var/opt/ignite/data/Rel_B.10.20/patch_bundle_cfg"
"/var/opt/ignite/config.local"
}
/var/opt/ignite/data/Rel_B.10.20/patch_bundle_cfg,
(you created this file with the make_config command) in the
sw_sel stanza for the patch bundle, add the following line:
load_with_any = "golden image"
"golden image" is the name used in the sw_sel stanza in
the file /var/opt/ignite/data/Rel_B.10.20/core_700_archive_cfg
for our archive 10.20 UX system. The load_with_any line will
cause this software selection to always be loaded with the
"golden image" archive.
# instl_adm -T
Modifying Kernel Parameters with IUX
Ignite-UX uses the same mechanism for kernel parameters as it does for
selectable software: create a config file which describes the
changes; then make that file visible to Ignite-UX by adding it to a
existing "cfg" in the INDEX file.
HARDWARE_MODEL ~ "9000/7.*" {
sw_sel "My_Kernel_Mods" {
description = "Kernel parameters only"
sw_source = "cmds"
sw_category = "HPUXAdditions"
mod_kernel += "nproc 2000"
mod_kernel += "maxuprc 127"
load_with_any = "golden image"
}
}
cfg "HP-UX B.10.20 archive" {
description "The ARCHIVE B.10.20 release with patches."
"/opt/ignite/data/Rel_B.10.20/config"
"/var/opt/ignite/data/Rel_B.10.20/core_700_archive_cfg"
"/var/opt/ignite/data/Rel_B.10.20/patch_bundle_cfg"
"/var/opt/ignite/data/Rel_B.10.20/kernel_cfg"
"/var/opt/ignite/config.local"
}
These changes will result in "My_Kernel_Mods" being loaded
whenever the "HP-UX B.10.20 archive" is installed. Note that
we've added the line:
load_with_any = "golden image"
An additional example, using multiple, selectable kernel configs
You can have multiple, pre-defined kernel configs available at
install time. This allows clients to be installed with
optional parameters if necessary.
HARDWARE_MODEL ~ "9000/7.*" {
# basic required kernel parameters
sw_sel "Basic_Kernel_Mods" {
description = "Basic Kernel parameters only"
sw_source = "cmds"
sw_category = "HPUXAdditions"
mod_kernel += "nproc (20+12*MAXUSERS)"
mod_kernel += "maxuprc 127"
load_with_any = "golden image"
}
#optional kernel parameters
sw_sel "Advanced_Kernel_Mods" {
description = "Advanced Kernel parameters"
sw_source = "cmds"
sw_category = "HPUXAdditions"
mod_kernel += "maxdsiz 0x0A000000"
mod_kernel += "maxtsiz 0x06000000"
}
} # end of hardware-specific section
Kernel Parameters Tied to Client Hardware
Because we've specified our kernel mods within a
HARDWARE_MODEL stanza, it's possible to set kernel parameters
based on the H/W configuration of the client. As an example,
suppose the first line of the kernel_cfg file is changed to
the following:
HARDWARE_MODEL = "9000/715"
Then the values in this stanza will only be used if the
machine is a Model 715. This allows the system administrator to
tailor the kernels of servers differently from clients, for
example.
Additional Install Parameters
There are a large number of additional parameters which can be
set when we install a system. These are listed in the instl_adm(4)
man page.
init _hp_pri_swap=100MB
final dns_domain = "mydomain.mycompany.com"
final dns_nameserver[0]="1.2.3.4"
Chapter 5: Post Install Scripts
1. Procedure for adding a post-installation script
post_config_script += "/var/opt/ignite/scripts/install_default_printer"
scripts {
"/var/opt/ignite/scripts/install_default_printer"
}
It will then show up in the Advanced tab for all configurations.
2. Managing Network Printers
#!/sbin/sh
# Post process IUX script to add a local default printer
# Performing task "Add Remote Printer": Adding "printbob"
#
/usr/sbin/lpadmin -pprintbob -ormhpfcmgw.fc.hp.com -orptsslj -mrmodel \
-v/dev/null -orc -ocmrcmodel -osmrsmodel
/usr/sbin/lpadmin -dprintbob
/usr/sbin/accept printbob
/usr/bin/enable printbob
# Turn on lp scheduler
#
lpsched -v
Chapter 6: Using Ignite-UX Across Gateways
bootsys command. If the system is booted manually, it
will need a helper system to help it boot across a gateway, and
enabling the target system to perform a "boot lan.<ip_address>
install" to the local boot helper system. This section describes
how to configure the boot helper system.
# swinstall -s hpfclc:/release/Ignite-UX \
Ignite-UX.MinimumRuntime
Step 3: On the helper, run the following command to point the
INSTALLFS at the correct Ignite-UX server:
# /opt/ignite/bin/instl_adm -t <IUX_server_IP>
Verify that INSTALLFS is referencing the correct
Ignite-UX server, and gateway for your subnet:
# /opt/ignite/bin/instl_adm -d
/etc/opt/ignite/instl_boottab file, add the
IP addresses that clients can use to boot. For example:
(The remote subnet needs to have temporary IP addresses
to use during an initial bootup. These are located in
the /etc/opt/ignite/instl_boottab file, and
were provided during our initial IUX server
installation. But, the remote gateway systems cannot
use these, so the boot helper system must supply its
own. Therefore create an
/etc/opt/ignite/instl_boottab file on the
boot helper system containing lines of the following
format. (See /etc/opt/ignite/instl_boottab
on the IUX server for more details):
15.1.53.180
15.1.53.181
15.1.53.182
> boot lan.<helper_IP_address> install
How to Set Up a 9.0X System as a Boot Helper
On the (9.0X) helper:
mkdir -p /opt/ignite/boot
/etc/inetd.conf:
/opt/ignite
to the tftp spec. Don't forget to add \ to the line before it for
continuation.
instl_boots dgram udp wait root /etc/instl_bootd instl_bootd -b /opt/ignite/boot/boot_lif
On the install server (on one side of the gateway):
The effect of the "is_net_info_temporary=false" spec and the ip_addr,
netmask, and system_name specs is to use this information for the
install (thus avoiding DHCP) AND leave it in /tmp/install.vars on the
target system after installation. Set_parms will then run and pick
up this info as defaults. If is_net_info_temporary is set to true,
the network information will be lost.
is_net_info_temporary=false
route_gateway[0]="15.2.48.1"
route_destination[0]="default"
ip_addr="15.2.43.1"
netmask="255.255.248.0"
system_name="a_name"
/opt/ignite/boot/* files to the 9.05 boot helper's
/opt/ignite/boot directory.
To Perform the Install on the Target:
Boot up the target machine to the boot admin menu, and type a line
similar to the following (for example):
boot lan.15.1.50.57 install
where "15.1.50.57" is replaced by the IP address of the HELPER machine.
If there's only 1 install server available on the subnet, then just
typing "boot lan install" should work. The exact string to type is
somewhat machine dependent.
Appendix A: Steps to Create A "Golden System"
dd onto the disks of incoming new systems.
# make_depots -r B.10.20 -a 700 \
-s hpfclc:/release/S700_10.20/B3782EA
# /opt/ignite/bin/make_config -r B.10.20
The make_depots command will copy the release B.10.20 software
at the SD depot pointed to by the "-s" option, (this pathname
will depend on the setup of the SD depot you are accessing)
onto the local Ignite-UX server. (You can also run make_config and
point it to the remote depot directly.)
# bootsys -v -w -f -i "HP-UX B.10.20 Default" <target_hostname>
Use the normal Ignite-UX target install steps as laid out in Chapter 2
Step 4. Select the configuration you've just set up, "HP-UX
B.10.20 Default".
# swinstall -x autoreboot=true -x match_target=true -s \
./PHSS_8375.depot
These instructions can also be found in the file "PHSS_8375.text".
Appendix B: Loading HP-UX Patches with Ignite-UX
PHCO_7891 PHCO_9348 PHKL_9361 PHSS_7726 PHSS_8966
PHSS_9400 PHCO_8353 PHKL_8376 PHKL_9569 PHSS_8667
PHSS_9201
# for i in PH*
do
sh $i
done
swcopy command. First, create the directory to store the
patches:
# mkdir /var/opt/ignite/Patches
# for i in PH*.depot
do
swcopy -s ${PWD}/$i \* @ /var/opt/ignite/Patches
done
# swlist -d @ /var/opt/ignite/Patches
Assuming the above example list of patches, you would see the
following:
# Initializing... # Contacting target "interop1"... # # Target:
interop1:/var/opt/ignite/Patches #
#
# No Bundle(s) on interop1:/var/opt/ignite/Patches
# Product(s):
#
PHCO_7891 B.10.00.00.AA allows mount to turnon hfs-specific opts
PHCO_8353 B.10.00.00.AA cumulative awk(1) patch
PHCO_9348 B.10.00.00.AA cron(1M) and at(1) patch
PHKL_8376 B.10.00.00.AA Fix vmtrace bug.
PHKL_9361 B.10.00.00.AA Fix panic caused by MP race
PHKL_9569 B.10.00.00.AA NFS and VxFS (JFS) cumulative patch
PHSS_7726 B.10.00.00.AA CDE Dtterm August 96 patch
PHSS_8667 B.10.00.00.AA CDE Runtime Nov96 Patch
PHSS_8966 B.10.00.00.AA LIBCL cumulative patch
PHSS_9201 B.10.00.00.AA fix for aC++ dld.sl
PHSS_9400 B.10.00.00.AA ld(1) cumulative patch
swlist states that the depot has "No
Bundles". HP-UX Patches are SD "products", but Ignite-UX can only
manage SD "Bundles".
/opt/ignite/bin/make_bundles command. Run the script and create a
bundle in the Patches depot:
# make_bundles -B -n Misc_Patches -t "HP-UX 10.20 Patches" \
/var/opt/ignite/Patches
# swlist -d @ /var/opt/ignite/Patches
(Output of swlist command assuming the example patches)
# Initializing...
# Contacting target "interop1"...
#
# Target: interop1:/var/opt/ignite/Patches
#
#
# Bundle(s):
#
Misc_Patches HP-UX 10.20 Patches
The default behavior of swlist is to now show only the higher
level software bundles. Individual patches in the bundle can
still be viewed by using swlist options. The following will
show the patch "products" contained in the bundle:
# swlist -l product -d @ /var/opt/ignite/Patches
NOTE:
swremove command. You can either run
swremove and use its friendlier user-interface, or run
swremove in command line mode. The following will remove the
PHKL_8376 patch from the bundle:
# swremove -d Misc_Patches.PHKL_8376 @ /var/opt/ignite/Patches
# make_config -s /var/opt/ignite/Patches -a 700 \
-c /var/opt/ignite/data/Rel_B.10.20/misc_patch_bundle_cfg
cfg "HP-UX B.10.20 archive" {
description "The ARCHIVE B.10.20 release with patches."
"/opt/ignite/data/Rel_B.10.20/config"
"/var/opt/ignite/data/Rel_B.10.20/core_700_archive_cfg"
"/var/opt/ignite/data/Rel_B.10.20/patch_bundle_cfg"
"/var/opt/ignite/data/Rel_B.10.20/misc_patch_bundle_cfg"
"/var/opt/ignite/config.local"
}
load_with_any = "golden image"
We created this file with the make_config command file previously.
Appendix C: Setting Install Parameters Dynamically
Ignite-UX can make intelligent decisions about install
parameters when it runs, based on information it reads from
the target system. Instead of forcing static values for, say,
swap size or kernel parameters, the best values for these can
be determined based on the characteristics of the target
machine.
# default to very minimal swap of 25MB
# unless the disk is larger than 500 MB
# and we have more than 64MB ram
(disk[_hp_root_disk].size > 500MB & memory > 64MB)
{
init _hp_pri_swap=125MB
} else
{
init _hp_pri_swap=25MB
}
/var/opt/ignite/data/Rel_B.10.20/core_700_archive_cfg
# check for H/W model 71x
# and add the Misc_Patches bundle if true
(hardware_model ~ "9000/71*") {
init "Misc_Patches" = true
}
post_config_script += "/var/opt/ignite/scripts/755special"
HARDWARE_MODEL == "9000/755" {
post_config_script += "/var/opt/ignite/scripts/755special"
mod_kernel += "maxuprc 300"
} else {
mod_kernel += "maxuprc 100"
}
instl_adm
command as described in Chapter 3
# For a system with only one disk and small memory, select
# the "small system configuration"
(num_disks == 1 & memory < 64MB )
{
cfg "small system configuration" = true
}
# instl_adm -T
If you want to check the syntax of a file that is not yet
in the INDEX file, you can use the command:
# instl_adm -T -f <file>
Appendix D: Installing NetScape as a Post-Configuration Step
Here is a little more complicated example of using Ignite-UX post
installation scripts to load software on new installs. Netscape is
one of those tools which seems to have a new navigator every 6 months.
Due to the frequency of the changes, this tool may not make sense to
include on the "golden system". Here is an example of adding
Netscape Navigator tool.
netscape-v30-export.hppa1.1-hp-hpux.tar.gz
/usr/local/bin/netscape a link to "run-netscape"
to ensure user defaults will be installed.
/var/opt/ignite/scripts/install_netscape
post_config_script += "/var/opt/ignite/scripts/install_netscape"
Example post install script for Netscape
# !/usr/bin/ksh
#
# Post Ignite-UX installation script used to install Netscape version 3.0.
# This installation assumes HP-UX 10.20 because it depends on gzip
# already loaded on the system.
#
PATH=${PATH}:/usr/sbin:/sbin:/usr/contrib/bin
IUX_SERVER=interop1.fc.hp.com
IUX_ARCHIVE_DIR=/var/opt/ignite/archives/Netscape
NETSCAPE_GZIP=netscape-v30-export.hppa1.1-hp-hpux.tar.gz
NETSCAPE_INSTALL_DIR=/opt/Netscape
NETSCAPE_RUN_DIR=/usr/local
echo "* Loading Netscape"
mkdir ${NETSCAPE_INSTALL_DIR}
cd ${NETSCAPE_INSTALL_DIR}
rcp ${IUX_SERVER}:${IUX_ARCHIVE_DIR}/${NETSCAPE_GZIP} ${NETSCAPE_GZIP}
rcp ${IUX_SERVER}:${IUX_ARCHIVE_DIR}/run-netscape .
rcp ${IUX_SERVER}:${IUX_ARCHIVE_DIR}/default-preferences .
gzip -dc ${NETSCAPE_GZIP} | tar -xvf -
echo "* Finished loading Netscape"
#
# Configure netscape runtime
#
echo "* Configuring Netscape"
chmod 755 ${NETSCAPE_INSTALL_DIR}/run-netscape
ln -s ${NETSCAPE_INSTALL_DIR}/run-netscape ${NETSCAPE_RUN_DIR}/bin/netscape
#
# Install java_30
#
mkdir ${NETSCAPE_RUN_DIR}/lib/netscape
ln -s ${NETSCAPE_INSTALL_DIR}/java_30 ${NETSCAPE_RUN_DIR}/lib/netscape/java_30
#
# Install plugins library
#
mkdir ${NETSCAPE_RUN_DIR}/lib/netscape/plugins
ln -s ${NETSCAPE_INSTALL_DIR}/libnullplugin.so ${NETSCAPE_RUN_DIR}/lib/netscape/plugins/libnullplugin.so
mkdir ${NETSCAPE_RUN_DIR}/lib/netscape/mime.types
mkdir ${NETSCAPE_RUN_DIR}/lib/netscape/mailcap
rm -f ${NETSCAPE_GZIP}
echo "* Finished configuring Netscape"
Example run time script for Netscape
#!/bin/sh
#
# Put this script in /usr/local/bin/netscape
set -e
# Set this to the location of the real Netscape executable
#
REAL_NETSCAPE=/opt/Netscape/netscape
# Set this to the location of the default preferences file.
#
DEF_PREFS=/opt/Netscape/default-preferences
if [ ! -e $HOME/.netscape/preferences ]; then
echo '(installing default Netscape preferences...)'
mkdir $HOME/.netscape
cp -p $DEF_PREFS $HOME/.netscape/preferences
echo '(done)'
fi
# The "-name" option is to avoid confusing the users' X resources.
#
exec $REAL_NETSCAPE -name netscape $*