13.2 Installing a Complete Operating System Using Ignite -UX Ignite-UX has been around for a number of years now. With HP-UX 11.0, we saw the product being shipped as a standard part of the operating system. Our installation media is in Ignite-UX format. Some people regard Ignite-UX as an extension to Software Distributor. I can understand why this misconception is prevalent . The only real relationship between Ignite-UX and Software Distributor is that Ignite-UX can understand and interpret Software Distributor software depots. One of the main differences is that Software Distributor only knows how to interpret Software Distributor depots, while Ignite-UX can understand other software formats, e.g., tar and gzip to name a few. As a result, Ignite-UX could be used to distribute not only HP-UX operating system software but also third-party software in a non-SD format. There are various configurations we will look at: -
Set up an Ignite-UX server to utilize a Core OS depot. -
Add additional products and/or patches into a Core OS depot. -
Set up a Golden Image to ignite future clients with. 13.2.1 Set up an Ignite-UX server to utilize an existing Core OS depot Here, we look at the steps necessary to set up an Ignite-UX server in order to allow for the installation of a complete operating system. Initially, we look at using a Software Distributor depot that is an swcopy of the Core OS Install and Recovery Media. Ignite-UX can be managed via the intuitive GUI /opt/ignite/bin/ignite . There is a command called /opt/ignite/lbin/setup_server that can help you in setting up some of the one-time configuration changes (see man setup_server for details). We look at the individual tasks in the setup procedure and perform them by hand: -
Install the Ignite-UX software. -
Set up temporary IP addresses for boot clients. -
Set up tftp and instl_bootd services in /etc/inetd.conf . -
Set up /etc/exports to give NFS access to the /var/opt/ignite/clients directory. -
Set up Ignite-UX parameters to be used during the installation of the operating system. -
Set up a DHCP server (optional). Because these tasks don't take long, I will perform them now. 13.2.1.1 INSTALL THE IGNITE-UX SOFTWARE Ignite-UX is part of the Basic Operating Environment for HP-UX 11i. As such, it should already be installed:
root@hpeos004[] swlist -a is_reboot Ignite-UX # Initializing... # Contacting target "hpeos004"... # # Target: hpeos004:/ # # Ignite-UX Ignite-UX.BOOT-KERNEL false Ignite-UX.BOOT-SERVICES false Ignite-UX.FILE-SRV-11-11 false Ignite-UX.IGNITE false Ignite-UX.IGNT-ENG-A-MAN false Ignite-UX.MGMT-TOOLS false Ignite-UX.OBAM-RUN false Ignite-UX.RECOVERY false root@hpeos004[]
As you can see, even if it isn't installed, it doesn't require a reboot when you do install it. 13.2.1.2 SET UP TEMPORARY IP ADDRESSES FOR BOOT CLIENTS Clients wishing to perform an installation of the OS will be assigned a temporary IP address when they boot from the Ignite-UX server over the network. You need to assign enough temporary IP addresses for the maximum number of clients who will boot simultaneously over the network. The file that needs to be edited in order to set up temporary IP addresses for boot clients is the file /etc/opt/ignite/instl_boottab :
root@hpeos004[] vi /etc/opt/ignite/instl_boottab # # /etc/opt/ignite/instl_boottab: Used by /opt/ignite/lbin/instl_bootd(1M) # # This file contains a list of IP addresses to be reserved for booting # clients during an the HP-UX install process. These addresses are # used only during the boot period and not at any other time, thus # they are temporary. # # A list of (one or more) IP addresses should be entered below, one # per line, beginning in the first column. The IP addresses will be # cycled through for each consecutive client that boots. If many # clients are booting at the same time, it may be necessary for you to # enter several addresses to keep the server from denying any client # access. # # When instl_bootd allocates an IP address to a client, it will # change the line to include the clients network hardware address and # the date/time that it booted (fields 2 and 3). This data is for use # by instl_bootd when determining which address to use next time. # # File Syntax: # # - Comments can be included as appropriate. They are denoted # by the '#' character and end-of-line. They can appear at the # end of an IP address line, or on a line by themselves. Blank # lines are also allowed. # # Non-comment lines can contain 1 or 4 fields. Fields are separated # by the ":" (colon) character. Each field is described as follows: # # Field 1: Must start in the first column, and contain an IP # address in "dot" notation. This field is not optional. # # Field 2: Can be empty, or can specify the LAN hardware address # of the system that last used the entry, or (depending # on field 4), the only system that is allowed to use it. # This field is updated automatically by instl_bootd. # # Field 3: Can be empty, or can specify the date/time of the last # time that the IP address was used. This field is also # updated by instl_bootd. It should be left empty when # adding new entries. # # Field 4: Can be empty, or the keyword "reserve" can be # specified to prevent an IP from being allocated to # any client not matching the hardware address value in # field 2. If field 2 is empty ("::"), then when the # entry is issued to a client, that entry/IP-Address # will become reserved for that system and will not be # allocated to any other systems. # # Example: (lines are intentionally commented out) # 15.1.54.125 # IP address usable by any client # 15.1.54.126:080009123456:19960116132331 # Entry usable by all (used already) # 15.1.54.127:::reserve # Reserve this entry once used. # 15.1.54.138:080009123457::reserve # Reserve an IP-Addr for specific host # 192.168.0.45::: 192.168.0.46::: 192.168.0.47::: 192.168.0.48::: 192.168.0.49::: 192.168.0.75::: 192.168.0.76::: 192.168.0.77::: 192.168.0.78::: 192.168.0.79::: root@hpeos004[]
This file does exist by default, but does not contain any valid entries. The comments describe the necessary fields. As you can see, I have set up five IP address for both subnets that my server is connected to (it is important to remember to include all subnet addresses that a client can boot from). We should ensure that these IP addresses are not disallowed by the file /var/adm/inetd.sec . The file /etc/opt/ignite/inst_boottab is used by the instl_bootd process that we set up next. 13.2.1.3 SET UP TFTP AND INSTL_BOOTD SERVICE IN /ETC/INETD.CONF. We need to ensure that the following lines are included in the file /etc/inetd.conf :
root@hpeos004[] vi /etc/inetd.conf ... # Before uncommenting the "tftp" entry below, please make sure # that you have a "tftp" user in /etc/passwd. If you don't # have one, please consult the tftpd(1M) manual entry for # information about setting up this service. tftp dgram udp wait root /usr/lbin/tftpd tftpd\ /opt/ignite\ /var/opt/ignite ... instl_boots dgram udp wait root /opt/ignite/lbin/instl_bootd instl_bootd ... root@hpeos004[] inetd -c root@hpeos004[] root@hpeos004[] pwget -n tftp tftp:*:510:1:Trivial FTP user:/home/tftpdir:/usr/bin/false root@hpeos004[]
I have included the comment lines relating to tftp to remind you about the need for a tftp user in the file /etc/passwd . Most administrators I know will use either the Ignite-UX GUI or SAM to set up these services. 13.2.1.4 SET UP /ETC/EXPORTS TO GIVE NFS ACCESS TO THE /VAR/OPT/IGNITE/CLIENTS DIRECTORY The Ignite-UX mini-kernel is NFS-enabled in order to access configuration information stored on the Ignite-UX server. Client information is stored under individual subdirectories in /var/opt/ignite/clients . We need to ensure that this directory is part of our NFS exported files/directories. We need to ensure that the anonymous user is equivalenced to the bin user. Here's the line from my /etc/exports file:
root@hpeos004[] vi /etc/exports /var/opt/ignite/clients -anon=2 root@hpeos004[] root@hpeos004[] exportfs -a root@hpeos004[] showmount -e export list for hpeos004: /var/opt/ignite/clients (everyone) root@hpeos004[]
13.2.1.5 SET UP IGNITE-UX PARAMETERS TO BE USED DURING THE INSTALLATION OF THE OPERATING SYSTEM When a client boots over the network, one of the files it downloads from the server is the file /opt/ignite/data/INSTALLFS . The first 8KB of this file contains default parameters that control the installation of software. This 8KB area is managed by the command instl_adm :
root@hpeos004[] instl_adm -d # instl_adm defaults: # NOTE: Manual additions between the lines containing "instl_adm defaults" # and "end instl_adm defaults" will not be preserved. server="192.168.0.35" netmask[]="0xffffffe0" route_gateway[0]="" route_destination[0]="default" sd_server="192.168.0.35" # end instl_adm defaults. root@hpeos004[]
We can add to and/or modify these parameters. The first time we run through an installation, we are asked many questions relating to, for example, the IP configuration for this client machine. These parameters will be stored in a file on the server called /var/opt/ignite/clients/0x[LLA]/config . This file will be used in future installations from that client. We can influence some of those parameters at this time via the instl_adm command:
root@hpeos004[] instl_adm -d > /tmp/instl.cfg root@hpeos004[] root@hpeos004[] vi /tmp/instl.cf g # instl_adm defaults: # NOTE: Manual additions between the lines containing "instl_adm defaults" # and "end instl_adm defaults" will not be preserved. server="192.168.0.35" netmask[]="0xffffffe0" route_gateway[0]="" route_destination[0]="default" sd_server="192.168.0.35" # end instl_adm defaults. run_ui=false control_from_server=true disable_dhcp=true root_password="sv.epmVgln4pU,.." timezone="GMT0BST" is_net_info_temporary=false _hp_keyboard="PS2_DIN_US_English" root@hpeos004[] root@hpeos004[] instl_adm -f /tmp/instl.cfg root@hpeos004[] root@hpeos004[] instl_adm -d # instl_adm defaults: # NOTE: Manual additions between the lines containing "instl_adm defaults" # and "end instl_adm defaults" will not be preserved. server="192.168.0.35" netmask[]="0xffffffe0" route_gateway[0]="" route_destination[0]="default" sd_server="192.168.0.35" # end instl_adm defaults. run_ui=false control_from_server=true disable_dhcp=true root_password="sv.epmVgln4pU,.." timezone="GMT0BST" is_net_info_temporary=false _hp_keyboard="PS2_DIN_US_English" root@hpeos004[]
As you can see, some of these parameters are true/false expressions while others take string values. What I am trying to do here is to anticipate some of the inane questions you always get asked during these installations. This file, as well as the file under /var/opt/ignite/clients/0x[LLA]/config , is appended to the configurations listed in the Ignite-UX INDEX file we see later. 13.2.1.6 SET UP A DHCP SERVER (OPTIONAL) If we want the entire IP configuration for our boot clients to be handled by a DHCP server, we can set up the DHCP server at this time if we wish. We cover setting up a DHCP server in Chapter 15, Basic IP Configuration. Because our boot clients will be real HP-UX servers, we will not be using a DHCP server in this instance. We can now look at the additional steps to setting up an Ignite-UX server. We repeat some of the tasks whenever we add or modify software to our Ignite-UX configuration. Here are the steps we perform: - Set up a software depot(s).
- Create an Ignite-UX configuration file that represents the contents of the software depot(s).
- Update the Ignite-UX INDEX file to reflect the new configurations that are now available.
- Ensure that the Ignite-UX server recognizes all clients.
Let's look at each step in turn . 13.2.1.7 SET UP SOFTWARE DEPOT(S) We discussed setting up software depots that contain software and/or patches in Chapter 12, HP-UX Patches. I assume that you have spent the necessary resources in setting up your software depot(s). The only problem is we need to ensure that Ignite-UX has an appropriate understanding of what those software depot(s) are and what software is contained within them. That is our next step. 13.2.1.8 CREATE AN IGNITE-UX CONFIGURATION FILE THAT REPRESENTS THE CONTENTS OF THE SOFTWARE DEPOT(S) In order for Ignite-UX to be able to interpret the software loaded in a Software Distributor depot, we must use an Ignite-UX command called make_config . This will analyze the content of a software depot and make an appropriate configuration file that represents its contents. We need to tell make_config whether to analyze software for a server (800), a workstation (700), or both. We also need to specify the name of the configuration file to use. Ignite-UX comes with some appropriately named directories for this task.
root@hpeos004[] ll /var/opt/ignite/data total 0 drwxr-xr-x 2 bin bin 96 Feb 18 2003 Rel_B.11.11 root@hpeos004[]
You don't need to use these directories if you don't want to, but it seems such a waste. I will create a configuration file called Core_OS.cfg and store it in the directory listed above. The last piece of information that make_config needs is the location of the software depot. The command can take some time to run, depending on the content of the depot. Here's the output from my system:
root@hpeos004[] make_config -a both -c /var/opt/ignite/data/Rel_B.11.11/ Core_OS.cfg -s /software/11i-PA/core NOTE: make_config can sometimes take a long time to complete. Please be patient! root@hpeos004[] root@hpeos004[] more /var/opt/ignite/data/Rel_B.11.11/Core_OS.cfg ... ###################################################### ## Operating Environments ##################################################### sw_sel "HPUX11i-OE-MC" { description = "HP-UX Mission Critical Operating Environment Component" sw_source = "core" sw_category = "OpEnvironments" sd_software_list = "HPUX11i-OE-MC,r=B.11.11.0209,a=HP-UX_B.11.11_32/64,v=HP" (_hp_os_bitness == "32") { impacts = "/usr" 26445Kb impacts = "/sbin" 61Kb impacts = "/opt" 450725Kb impacts = "/etc" 10319Kb impacts = "/var" 28910Kb impacts = "/" 6Kb } (_hp_os_bitness == "64") { impacts = "/usr" 26445Kb impacts = "/sbin" 61Kb impacts = "/opt" 450750Kb impacts = "/etc" 10319Kb impacts = "/var" 28910Kb impacts = "/" 6Kb } } ...
The configuration file is quite detailed. I have highlighted some interesting areas of the file above, for example, the impact this software will have on certain filesystems. Whenever we add additional software to a depot, we need to ensure that the configuration file reflects these changes with relevant impact statements . 13.2.1.9 UPDATE THE IGNITE-UX INDEX FILE TO REFLECT THE NEW CONFIGURATIONS THAT ARE NOW AVAILABLE The heart of the Ignite-UX configuration is the file /var/opt/ignite/INDEX . This file contains a list of valid configurations, each of which is made up of one of more configuration files. The list of available configurations is presented in the user interface when we are installing a client. The command manage_index needs to know the name of the configuration file to reference as well as the name of the operating system release. By default, Ignite-UX knows about the current OS release:
root@hpeos004[] manage_index -l HP-UX B.11.11 Default root@hpeos004[]
Now look at the INDEX file that comes with Ignite-UX:
root@hpeos004[] more /var/opt/ignite/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" }
The configuration file / opt/ignite/data/Rel_B.11.11/config details the default disk and filesystem layouts. If we wanted to create a config file for an existing machine, we could use the save_config command. If we were to create our own configuration, we would probably include this configuration file (and /opt/ignite/data/Rel_B.11.11/hw_patches_cfg , which details the behavior of installing any available patches) along with our own configuration files, e.g., to add additional software after the Core OS is installed. We see this later. We add the configuration file created by make_config into the description of our B.11.11 release:
root@hpeos004[] manage_index -a -f /var/opt/ignite/data/Rel_B.11.11/Core_OS.cfg r "B.11.11" root@hpeos004[] root@hpeos004[] more /var/opt/ignite/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/data/Rel_B.11.11/Core_OS.cfg" "/var/opt/ignite/config.local" } root@hpeos004[]
We can see our configuration file listed alongside the other configuration files. This is a simple configuration, but it is enough to demonstrate the basic requirements for an Ignite-UX server. The last step we need to perform is to ensure that the Ignite-UX server recognizes the client as a valid Ignite-UX client. 13.2.1.10 ENSURE THAT THE IGNITE-UX SERVER RECOGNIZES ALL CLIENTS This part of the process is where we boot a client from the server over the network. This process will register the client with the Ignite-UX server, creating a series of subdirectories on the server to hold the client's configuration. An alternative to rebooting the client is to have the client run the command /opt/ignite/bin/add_new_client s <Ignite server> . In order to run this command, the client must have the fileset Ignite-UX.MGMT-TOOLS already installed (in reality, if the client is an HP-UX 11.X machine, Ignite-UX is loaded by default anyway). We will use the server command /opt/ignite/bin/bootsys (requires remsh capability; otherwise , we are asked for the root password for the client), which will boot the client and (possibly) start the installation depending on the options used. The option a will automatically start the installation with no user interaction, utilizing the parameters in the configuration files. The w option causes the client to boot and wait for user input from the server. If we specify neither a nor w , the client will boot depending on the options specified in the INSTALLFS file (remember, we set the control_from_server and run_ui options earlier). The bootsys command copies the Ignite-UX kernel ( INSTALL ) and the Ignite-UX filesystem ( INSTALLFS ) to the client and then modifies the client AUTO file to boot from the Ignite-UX kernel on the next reboot. Once booted, the Ignite-UX kernel will read any options specified in the INSTALLFS 8KB header that can affect whether the installation starts automatically or needs further user input. Let's have a look at bootsys in action:
root@hpeos004[] bootsys hpeos003 Rebooting hpeos003 now. root@hpeos004[]
And on the client itself: To discontinue, press any key within 10 seconds. 10 seconds expired. Proceeding... Trying Primary Boot Path ------------------------ Booting... Boot IO Dependent Code (IODC) revision 1 HARD Booted. ISL Revision A.00.43 Apr 12, 2000 ISL booting hpux (;0)/stand/WINSTALL Boot : disk(0/0/1/1.15.0.0.0.0.0;0)/stand/WINSTALL 9777152 + 1687552 + 2602664 start 0x2012e8 alloc_pdc_pages: Relocating PDC from 0xf0f0000000 to 0x3fb01000. Ignite-UX Waiting for installation instructions from server: 192.168.0.35 Icon Name Shown in GUI: hpeos003 Active System Name/IP: hpeos003/192.168.0.33 You may now complete the installation using the "ignite" graphical interface on the Ignite-UX server (See ignite(1M)). If you are not already running "/opt/ignite/bin/ignite" on the server, do so now. No further action is required at this console. [ Perform Installation from this Console ] [ View Active Network Parameters ] [ Change Icon Name Shown in GUI ] Are you sure you want to switch to run the UI locally?[n] As you can see, I can proceed with the installation from the server. On the server, I can now see the client from within the Ignite-UX GUI. By right-clicking on the client, I can start a New Install (Figure 13-1). Figure 13-1. Ignite-UX GUI after client discovery. 
Once we select a New (or Repeat ) Install , we will be presented with the Ignite-UX itool interface where we can select the options for that individual client (Figure 13-2). Figure 13-2. Ignite-UX itool interface. 
An interesting feature here is that we can modify our installation choices via navigating the screens, choosing to add additional software components , add filesystems, add disks to vg00 , and so on. Before pressing the " Go! " button, we can save this configuration by using the " Save As " button. We will give the configuration a name, e.g., Custom_Config :
root@hpeos004[saved_cfgs] pwd /var/opt/ignite/saved_cfgs root@hpeos004[saved_cfgs] ll total 10 -rw-rw-r-- 1 bin bin 4797 Sep 30 17:23 Custom_Config root@hpeos004[saved_cfgs]
This selection can be used for other clients in the future in addition to the default configuration file = /opt/ignite/data/Rel_B.11.11/config . In this case, I have added additional filesystem options (I could have modified existing filesystem options and/or included additional software components as well) that will be added to the filesystem choices listed in the default configuration.
root@hpeos004[saved_cfgs] pwd /var/opt/ignite/saved_cfgs root@hpeos004[saved_cfgs] more Custom_Config ... logical_volume { mount_point="/data" usage=VxFS size=311296K } # end logical_volume ... root@hpeos004[saved_cfgs]
Another alternative for this client is that once installed, we can subsequently use bootsys a hpeos003 to start the installation automatically and use the previous settings for this client. 13.2.2 Adding additional software to a Core OS configuration As well as loading Core operating system software, we want to commonly load additional software to a client. To achieve this, we need to add additional configuration lines to the Ignite-UX index file. In fact, we may want to generate a new release to signify that this is the Core OS + Applications. In this way, we can select which release to install for each client. To add additional software to a Core OS installation, we would perform the following steps: - Set up software depot(s).
- Create an Ignite-UX configuration file that represents the contents of the software depot(s).
- Update the Ignite-UX INDEX file to reflect the new configurations that are now available.
- Use the new configuration to install a client.
This looks similar to setting up a Core OS configuration. And it is; all we need to ensure is that we have included all the necessary configuration files to reflect our Core OS + Applications installation. Let's look at each step in turn. 13.2.2.1 SET UP SOFTWARE DEPOT(S) I am assuming that you have spent the necessary resources to set up your software depots. As we saw with setting up a Core OS configuration, we had to create a configuration file that allowed Ignite-UX to interpret what software was housed in the depot. In this instance, we may have an additional step to undertake. We may have to create bundle specifications for our application software depot(s). Ignite-UX expects software to be in a bundle; if not, it will not be able to analyze and create a proper configuration file for it:
root@hpeos004[] make_config -a both -c /var/opt/ignite/data/Rel_B.11.11/FooProd -s /software/11i-PA/FooProd NOTE: make_config can sometimes take a long time to complete. Please be patient! WARNING: No bundles were processed for the "/software/11i-PA/FooProd" depot. No config file will be generated for this depot. This may be because the depot does not contain any bundles. To find out, run "swlist -d -l bundle @ /software/11i-PA/FooProd". If there are no bundles in the depot, run the make_bundles command before re-running make_config. SUMMARY: 0 config files were created correctly. 1 config file could not be created due to errors.
We can use the make_bundles command to create a bundle specification for our applications:
root@hpeos004[] make_bundles /software/11i-PA/FooProd Generating list of unbundled filesets... Generating swpackage PSF... ======= 09/30/03 18:11:13 BST BEGIN swpackage SESSION * Session started for user "root@hpeos004". * Source: hpeos004:/var/tmp/psf.3544 * Target: hpeos004:/software/11i-PA/FooProd * Software selections: * * Beginning Selection Phase. * Reading the Product Specification File (PSF) "/var/tmp/psf.3544". * Reading the bundle "b_FooProd" at line 11. * Reading the bundle "b_PHCO_3000" at line 18. * Reading the bundle "b_PHCO_4000" at line 25. * Selection Phase succeeded. * Beginning Analysis Phase. * Analysis Phase succeeded. * Beginning Package Phase. * Packaging the bundle "b_FooProd,r=1.0,a=HP-UX_B.11.00_32/64". * Packaging the bundle "b_PHCO_3000,r=1.0,a=HP-UX_B.11.00_32/64". * Packaging the bundle "b_PHCO_4000,r=1.0,a=HP-UX_B.11.00_32/64". * Package Phase succeeded. ======= 09/30/03 18:11:13 BST END swpackage SESSION root@hpeos004[] swlist -l bundle -d @ /software/11i-PA/FooProd # Initializing... # Contacting target "hpeos004"... # # Target: hpeos004:/software/11i-PA/FooProd # b_FooProd 1.0 (FooProd) This is an example 11.X product. b_PHCO_3000 1.0 (PHCO_3000) Foo Cumulative Patch b_PHCO_4000 1.0 (PHCO_4000) Foo Cumulative Patch root@hpeos004[ignite]
Now we can make a configuration file for my applications. 13.2.2.2 CREATE AN IGNITE-U UX CONFIGURATION FILE THAT REPRESENTS THE CONTENTS OF THE SOFTWARE DEPOT(S) We have seen this process before, so it should be of little surprise to us here. We are going to use the make_config command to create a configuration file that represents our application depot:
root@hpeos004[] make_config a both -c /var/opt/ignite/data/Rel_B.11.11/ FooProd.cfg s /software/11i-PA/FooProd NOTE: make_config can sometimes take a long time to complete. Please be patient! root@hpeos004[]
You might want to manually edit this configuration file to ensure that it is automatically selected as part of the installation process. Here, you can see that I have included a line in the configuration file to ensure that specific Software Distributor command line options are used; these are especially useful if the additional software we are loading includes patches (see sd_command_line statement). I have also used a load_order statement to ensure that this is one of the last pieces of software that is loaded, a load_order=6 being the last software to be installed (I have not used 6 in case I add more patches at a later date). As you can also see toward the bottom of the file, I have ensured that the FooProd product is selected for installation, by default:
root@hpeos004[Rel_B.11.11] pwd /var/opt/ignite/data/Rel_B.11.11 root@hpeos004[Rel_B.11.11] vi FooProd.cfg ######################################################### ## Software Sources ######################################################### sw_source "/software/11i-PA/FooProd" { source_type = "NET" sd_server = "192.168.0.35" sd_depot_dir = "/software/11i-PA/FooProd" sd_command_line="-x autoselect_dependencies=true -x autoselect_patches=true -x patch_match_target=true -x autoreboot=true" source_format = SD load_order = 5 } ###################################################### ## Other Software ##################################################### sw_sel "b_PHCO_4000" { description = "(PHCO_4000) Foo Cumulative Patch" sw_source = "/software/11i-PA/FooProd" sw_category = "Uncategorized" sd_software_list = "b_PHCO_4000,r=1.0,a=HP-UX_B.11.00_32/64" impacts = "/usr" 4Kb } sw_sel "b_PHCO_3000" { description = "(PHCO_3000) Foo Cumulative Patch" sw_source = "/software/11i-PA/FooProd" sw_category = "Uncategorized" sd_software_list = "b_PHCO_3000,r=1.0,a=HP-UX_B.11.00_32/64" impacts = "/usr" 3Kb } sw_sel "b_FooProd" { description = "(FooProd) This is an example 11.X product." sw_source = "/software/11i-PA/FooProd" sw_category = "Uncategorized" sd_software_list = "b_FooProd,r=1.0,a=HP-UX_B.11.00_32/64" impacts = "/usr" 6Kb } =TRUE root@hpeos004[Rel_B.11.11]
NOTE : I can include this software by other methods than those used above; for example, I could use the load_with_any= statement in the sw_sel section. I can now add this configuration to my Ignite-UX INDEX file. 13.2.2.3 UPDATE THE IGNITE-UX INDEX FILE TO REFLECT THE NEW CONFIGURATIONS THAT ARE NOW AVAILABLE If you look at my INDEX file, I have cut and pasted the Default configuration and given it a new name. Notice that the Default configuration has been marked as the default choice: =TRUE . Also notice that I have included my Custom_Config.cfg file to include the creation of my additional filesystem:
root@hpeos004[] cat /var/opt/ignite/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/data/Rel_B.11.11/Core_OS.cfg" "/var/opt/ignite/config.local" }=TRUE cfg "HP-UX B.11.11 FooProd" { description "HP-UX B.11.11 plus FooProd applications" "/opt/ignite/data/Rel_B.11.11/config" "/opt/ignite/data/Rel_B.11.11/hw_patches_cfg" "/var/opt/ignite/data/Rel_B.11.11/Core_OS.cfg" "/var/opt/ignite/config.local" "/var/opt/ignite/saved_cfgs/Custom_Config" } root@hpeos004[]
I can now use the manage_index command to add the newly created FooPrd.cfg file to this configuration:
root@hpeos004[] manage_index -a -f /var/opt/ignite/data/Rel_B.11.11/FooProd.c fg -c "HP-UX B.11.11 FooProd" root@hpeos004[] cat /var/opt/ignite/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/data/Rel_B.11.11/Core_OS.cfg" "/var/opt/ignite/config.local" }=TRUE cfg "HP-UX B.11.11 FooProd" { description "HP-UX B.11.11 plus FooProd applications" "/opt/ignite/data/Rel_B.11.11/config" "/opt/ignite/data/Rel_B.11.11/hw_patches_cfg" "/var/opt/ignite/data/Rel_B.11.11/Core_OS.cfg" "/var/opt/ignite/config.local" "/var/opt/ignite/saved_cfgs/Custom_Config" "/var/opt/ignite/data/Rel_B.11.11/FooProd.cfg" } root@hpeos004[]
I should test this new configuration just to ensure that it is syntactically correct:
root@hpeos004[] instl_adm -T * Checking file: /opt/ignite/data/Rel_B.11.11/config * Checking file: /opt/ignite/data/Rel_B.11.11/hw_patches_cfg * Checking file: /var/opt/ignite/data/Rel_B.11.11/Core_OS.cfg * Checking file: /var/opt/ignite/config.local * Checking file: /var/opt/ignite/saved_cfgs/Custom_Config * Checking file: /var/opt/ignite/data/Rel_B.11.11/FooProd.cfg root@hpeos004[]
This is now ready to be used by a client. 13.2.2.4 USE THE NEW CONFIGURATION TO INSTALL A CLIENT I am going to use the new configuration to install a client. I will use the bootsys command to override the previous configuration setting and to install this configuration automatically:
root@hpeos004[] bootsys -f -a -i "HP-UX B.11.11 FooProd" hpeos003 Rebooting hpeos003 now. root@hpeos004[]
Here are some features of the new installation we set up in our configuration files; to start with, the root password immediately expires ( root_password=sv.epmVgln4pU,.. in INSTALLFS ):
Start CDE login server .............................................. OK The system is ready. GenericSysName [HP Release B.11.11] (see /etc/issue) Console Login: root Password: Your password has expired. Choose a new one Changing password for root New password:
Our /data filesystem has been created (see Custom_Config.cfg ):
# bdf Filesystem kbytes used avail %used Mounted on /dev/vg00/lvol3 204800 78180 118737 40% / /dev/vg00/lvol1 303125 27478 245334 10% /stand /dev/vg00/lvol9 2613248 149876 2310439 6% /var /dev/vg00/lvol8 1089536 784768 285745 73% /usr /dev/vg00/lvol5 204800 1242 190903 1% /tmp /dev/vg00/lvol7 950272 703978 230948 75% /opt /dev/vg00/lvol6 24576 1109 22008 5% /home /dev/vg00/lvol4 311296 1181 290740 0% /data #
And the software FooProd has automatically been installed (including patches for the product as well).
# swlist -l patch FooProd # Initializing... # Contacting target "hpeos003"... # # Target: hpeos003:/ # # FooProd 1.0 This is an example 11.X product. # FooProd.FOO-HELP 1.0 On-line Help for Foo # FooProd.FOO-MIN 1.0 Minimal stuff for Foo 32-bit PHCO_3000.FOO-MIN 1.0 Minimal stuff for Foo applied PHCO_4000.FOO-MIN 1.0 Minimal stuff for Foo applied #
An alternative to having Core OS depots and additional software components loaded onto each client is to take a snapshot of an existing client: This is known as a Golden Image . This will include all current software and hardware settings. This image can then be used to install an entire network of similarly configured machines. | 