| In this section we'll create a bootable recovery archive for a Virtual Partition using the Ignite-UX GUI. In addition, we'll take a look at some of what is taking place in the background such as: - Disk space consumed by a bootable recovery archive on the server. - Server files created and modified to support creating the client archives (/etc/exports, others.) - Command issued by server on client to produce the archive. - In the next section we'll restore a client by booting from the archive created on the server (note that the relocatable kernel is different from a standard kernel.)
Using Ignite-UX GUI to Create a vPar Archive After the Ignite-UX tool is loaded on the server there is some initial client setup that is required and managed through the Ignite-UX Graphical User Interface (GUI). There are also some modifications made to the server. One of these changes is to make entries for the cleints to be managed in /etc/ exports. Ignite-UX automatically included entries in /etc/exports for the cleints that were set up. The following /etc/exports listing shows an entry for two clients on the server chess2: root@chess2 > cat /etc/exports /var/opt/ignite/clients -anon=2 /var/opt/ignite/recovery/archives/actappd1 -anon=2,access=actappd1 /var/opt/ignite/recovery/archives/ecvpard2 -anon=2,access=ecvpard2 root@chess2 > The three entries include the general clients directory used by the Ingite-UX server, and archives directories for the two clients that were setup on the Ignite-UX server, called actappd1 and ecvpard2. These two hosts are Virtual Partitions running on the same server. chess2, the Ignite-UX server, is a different server than that on which the two vPars are running. In addition to /etc/exports updates that were automatically made when specifying clients, you may want to manually create entries in /.rhosts on both the server and client so that you won't have to respond with the client password on the server when you initiate creating the bootable recovery archive. The server is running a program remotely on the client, and in order to do so without issuing a password, the /.rhosts file must have the appropriate entries. Keep in mind, though, that including entries in /.rhosts reduces the overall security level of your system. Once this has been completed you can initiate the process of creating the bootable recovery archive as shown in Figure 10-1 on our server chess2: Figure 10-1. Specifying Client for Which Bootable Recovery Archive Will Be Produced  The two clients shown in the Ignite-UX GUI were those for which we saw entries in /etc/exports. Keep in mind that the two systems shown in the Ignite-UX GUI are two Virtual Partitions running on the same server. There are several Actions from which we can choose once a client has been selected, as shown in Figure 10-2: Figure 10-2. Actions Menu after Client Has Been Selected  With actappd1 selected we'll choose Create Network Recovery Archive from the Actions menu. Making this menu selection brings up a window that contains a series of defaults for creating the archive, as shown in Figure 10-3: Figure 10-3. Defaults for Creating a Bootable Recovery Archive  After we progress through these basic screens, Ignite-UX begins the process of creating the archive.  | The server issued the make_net_recovery command on the client in order to create the archive. The following is the output of ps -ef for only this command on the client (actappd1) for which the archive is being produced: |
root@actappd1 > ps -ef | grep make /opt/ignite/bin/make_net_recovery -i -b -P s -l 0x00306E0981D4 root@actappd1 > This command is now running in the background on our client, which is a Virtual Partition, and writing an archive across the network to the server. This process takes about three hours on our client and produces a file over 600 MBytes in size. | | If you're interested in the many options to make_net_recovery, you can view the online man page for the command. In this example the i is for interactive, b for background, -P for partial, s for server, and -l for lanic id of the client. You could issue this command from the client as well as from the server. Some system administrators prefer to manage the creation of the archives centrally from the server and others prefer to create cron entries on the clients and initiate this process from the client. Both the setup and syntax of the make_net_recovery command appear in its man page (at the time of this writing, make_net_recovery is the latest command.) |
There are many files created as a result of initiating the creation of the recovery archive for the client. The following listing shows some of the more interesting directories and files. The man page for make_net_recovery provides an explanation for all of the important directories and files created for clients. Let's take a look at some of the more interesting ones on the Ignite-UX server used in our example in this chapter. The following is a long listing of the /var/opt/ignite/clients directory on the server: root@chess2[/var/opt/ignite/clients] > ll total 4 drwxrwxrwx 3 bin bin 1024 Jul 20 12:23 0x001083F7C4FC drwxr-xr-x 3 bin bin 1024 Jul 19 17:54 0x00306E0981D4 drwxr-xr-x 2 root sys 96 Jul 19 14:13 161.228.212.121 lrwxr-xr-x 1 bin bin 14 Jul 27 14:01 actappd1 -> 0x00306E0981D4 lrwxr-xr-x 1 bin bin 14 Jul 20 09:53 ecvpard2 -> 0x001083F7C4FC lrwxrwxrwx 1 root sys 14 May 25 15:53 sample -> 0x999999999999 Notice that there are entries for both of our clients in this directory. There is a link that allows you to specify the client name rather than the ID of the LAN card because the client name is much easier to remember and type. Next, let's change to the directory of the client for which we are creating our archive and perform a long listing: root@chess2[/var/opt/ignite/clients] > cd actappd1 root@chess2[/var/opt/ignite/clients/actappd1] > ll total 18 -rw-r--r-- 1 bin bin 987 Jul 24 18:33 CINDEX -rw-r--r-- 1 bin bin 9 Jul 19 15:15 client_name -rw-r--r-- 1 bin bin 28 Jul 19 15:15 client_status -rw-r--r-- 1 bin bin 300 Jul 19 15:15 config.sys -rw-r--r-- 1 bin bin 336 Jul 19 15:15 host.info -rw-r--r-- 1 bin bin 940 Jul 19 15:15 hw.info -rw-r--r-- 1 bin bin 231 Jul 19 15:15 install.log -rw-r--r-- 1 bin bin 0 Jul 19 15:20 lockfile drwxr-xr-x 3 bin bin 1024 Jul 27 14:01 recovery -rw-r--r-- 1 bin bin 585 Jul 27 13:39 server.state There is a lot of client-related information in this directory. The recovery directory has the most interesting files related to our client, so let's change to that directory and perform a long listing: root@chess2[/var/opt/ignite/clients/actappd1] > cd recovery root@chess2[/var/opt/ignite/clients/actappd1/recovery] > ll total 8 drwxr-xr-x 2 bin bin 1024 Jul 27 14:05 2001-07-27,13:55 -rw-r--r-- 1 bin bin 252 Jul 27 14:03 archive_content -rw-r--r-- 1 bin bin 247 Jul 27 14:05 client_status -rw-r--r-- 1 bin bin 411 Jul 27 14:03 defaults lrwxr-xr-x 1 bin bin 16 Jul 27 14:01 latest -> 2001-07-27,13:55 | | The archive_content file has in it the files and directories to be included or excluded. client_status is used to communicate with the client to provide the status of the make_net_recovery command. A status window is shown in the GUI after the creation of the archive is initiated. latest is a link to the directory that has in it the newest recovery files. If we change to this directory and perform a long listing, we see the files in the following listing: |
root@chess2[/var/opt/ignite/clients/actappd1/recovery] > cd 2001-07-27,13:55 @chess2[/var/opt/ignite/clients/actappd1/recovery/2001-07-27,13:55] > ll total 3704 -rw-r--r-- 1 bin bin 3089 Jul 27 14:05 archive_cfg -rw-r--r-- 1 bin bin 252 Jul 27 14:03 archive_content -rw-r--r-- 1 bin bin 269 Jul 27 14:03 control_cfg -rw-r--r-- 1 bin bin 1880616 Jul 27 14:05 flist -rw-r--r-- 1 bin bin 2510 Jul 27 14:05 recovery.log -rw-r--r-- 1 root sys 5588 Jul 27 13:58 system_cfg The recovery.log file contains information about the archive we are currently creating. The following output contains the contents of the file: ======= 07/27/01 13:55:54 EDT Started /opt/ignite/bin/make_net_recovery. (Fri Jul 27 13:55:54 EDT 2001) @(#) Ignite-UX Revision B.3.4.115 @(#) net_recovery (opt) $Revision: 10.543 $ * User interface starting. NOTE: Detected entries in the defaults file at /var/opt/ignite/recovery/client_mnt/0x00306E0981D4/recovery/defaults. * User interface completed successfully. NOTE: Detected entries in the defaults file at /var/opt/ignite/recovery/client_mnt/0x00306E0981D4/recovery/defaults. * Checking Versions of Recovery Tools * Creating System Configuration. * /opt/ignite/bin/save_config -f /var/opt/ignite/recovery/client_mnt/0x0 0306E0981D4/recovery/2001-07-27,13:55/system_cfg vg00 * Backing Up Volume Group /dev/vg00 * /usr/sbin/vgcfgbackup /dev/vg00 Volume Group configuration for /dev/vg00 has been saved in /etc/lvmconf/vg00.conf * Creating Map Files for Volume Group /dev/vg00 * /usr/sbin/vgexport -p -m /etc/lvmconf/vg00.mapfile /dev/vg00 vgexport: Volume group "/dev/vg00" is still active. * Creating Control Configuration. * Creating Archive File List * Creating Archive Configuration * /opt/ignite/bin/make_arch_config -c /var/opt/ignite/recovery/client_mn t/0x00306E0981D4/recovery/2001-07-27,13:55/archive_cfg -g /var/opt/ign ite/recovery/client_mnt/0x00306E0981D4/recovery/2001-07-27,13:55/flist -n 2001-07-27,13:55 -r 64 -d Recovery\ Archive -L /var/opt/ignite/recovery/arch_mnt -l chess2:/var/opt/ignite/recovery/archives/actappd1 -i 1 * Saving the information about archive to /var/opt/ignite/recovery/previews * Creating The Networking Archive * /opt/ignite/data/scripts/make_sys_image -d /var/opt/ignite/recovery/arch_mnt -t n -s local -n 2001-07-27,13:55 -m t-w/var/opt/ignite/recovery/client_mnt/0x00306E0981D4/recovery/2001- 07-27,13:55/recovery.log -u -R -g /var/opt/ignite/recovery/client_mnt/ 0x00306E0981D4/recovery/2001-07-27,13:55/flist -a 905500 * Preparing to create a system archive * The archive is estimated to reach 452750 kbytes. * Free space on /var/opt/ignite/recovery/arch_mnt after archive should be about 4066 kbytes. * Archiving contents of actappd1 via tar to /var/opt/ignite/recovery/arch_mnt/2001-07-27,13:55. @chess2[/var/opt/ignite/clients/actappd1/recovery/2001-07-27,13:55] > ll total 3704 -rw-r--r-- 1 bin bin 3089 Jul 27 14:05 archive_cfg -rw-r--r-- 1 bin bin 252 Jul 27 14:03 archive_content -rw-r--r-- 1 bin bin 269 Jul 27 14:03 control_cfg -rw-r--r-- 1 bin bin 1880616 Jul 27 14:05 flist -rw-r--r-- 1 bin bin 2510 Jul 27 14:05 recovery.log -rw-r--r-- 1 root sys 5588 Jul 27 13:58 system_cfg There are many useful files produced for each client; however, the one in which we are most interested is the recovery archive. The following listing shows three archives that have been produced for our client. root@chess2[/var/opt/ignite/recovery/archives/actappd1] > ls -l total 1432116 -rw------- 1 bin bin 623288688 Jul 24 18:33 2001-07-24,13:08 -rw------- 1 bin bin 36152098 Jul 25 16:08 2001-07-25,15:42 -rw------- 1 bin bin 73728000 Jul 27 14:42 2001-07-27,13:55 root@chess2[/var/opt/ignite/recovery/archives/actappd1] > The first is a complete archive created at an earlier date, the second is a partial archive that was not complete because it was aborted, and the third is the archive we were creating at the time this listing was produced. This shows that our Virtual Partition consumed over 600 MBytes of disk space for the complete archive. You'll want to consider the number of clients for which you wish to store bootable recovery archives on your server and plan your volume space accordingly. For the archive we are currently producing, there have been about 73 MBytes of what will be an over 600 MByte recovery archive present, and we have been running make_net_recovery on the client for about 20 minutes. | | After our archive has been fully created we can progress to booting it as a test. I usually create an archive as soon as a Virtual Partition has been produced and test it before I perform a lot of customization on the vPar. This will give you peace of mind that you know the process of booting from the recovery archive. |
Virtual Partition Recovery  | Now that we've created the bootable recovery archive for our Virtual Partition, we can restore our vPar using it. You can restore one vPar from another using the vparboot command. This means that while one vPar is running, you can restore another vPar on the same system using the following vparboot command: |
vparboot -p vp_name -I ignite_kernel This is different from the vparboot form used in Chapter 2 when we booted a vPar using a kernel that was located on the same system as opposed to an Ignite-UX server. That form of the vparboot is as follows: vparboot -p vp_name [-b kernel_path] [-o boot_opts] [-B boot_addr] In examples in early chapters we simply specified the name of the Virtual Partition we wanted to boot, such as vparboot -p cable1. With this form of vparboot we specify a boot kernel on the local system with the -b option. The man page for vparboot and the other vPar commands are found in Appendix A. You would normally boot a recovery archive from the PDC prompt, that is, your system is down and you are recovering it. Since we have multiple vPars on our system, we can recover one vPar on a system from a running vPar on the same system using vparboot. We'll issue the following vparboot command from our running vPar in order to restore vPar actappd1 from an Ignite-UX server at the command line: # vparboot -p actappd1 -I 161.228.212.110,/opt/ignite/boot/WINSTALL The IP address of our Ignite-UX server is specified. The WINSTALL file used in this vparboot command is different from that used for normal HP-UX recovery (without vPars.) A relocatable kernel is required for vPars, so the WINSTALL used in the vparboot command is one that is required for vPars. This WINSTALL is supplied with vPars. | | The ability to recover a Virtual Partition from a running vPar using vparboot means that fewer users are affected. The users in the running vPar are unaffected by the recovery taking place, on another vPar. After the recovery of the root volume group (vg00) takes place you can restore the balance of information on your vPar from the latest backup. Be sure to create the bootable recovery archive often so that your entire root volume group can be recovered with the latest data. |
Virtual Partition Installation with Ignite-UX This section contains a step-by-step procedure to set up an Ignite-UX server to install vPars. This procedure was supplied by HP lab engineer Geff Blaha. Since you'll be installing many instances of HP-UX 11i and vPars software in a vPars environment, this procedure may save you a lot of time. In examples in early chapters, we simply specified the name of the Virtual Partition we wanted to boot, such as vparboot -p cable1. With this form of vparboot we specify a boot kernel on the local system with the -b option. The man pages for vparboot and the other vPar commands are found in Appendix A. Ignite-UX and vPars Cookbook | | Use the vparboot command from a Virtual Partition to install HP-UX and vPar software to a target vPar. An Ignite-UX server is used as the source depot for this installation process. |
 | The following is an overall vPars installation process (assuming that a new server is being installed) |
- Install the server and peripherals - Install any required patches for vPars (i.e., Gold Quality Pack, etc.) - Install HP-UX 11i (stand-alone.) - Install vPars software. - Plan for desired vPars. - Create vPars using the vparcreate command: this creates the vPars database /stand/vpdb. - Shut down HP-UX and place the server into BCH (Boot Console Handler) mode. - Boot from the HP-UX/vPars disk and stop (interact) at the ISL prompt. - Load and run the vPars monitor. - Boot the first vPar (previously installed) with the vparload command. - Use the vparboot command to install HP-UX and vPars software to all remaining vPars. Use the Ctrl A command to switch the virtual console between vPars and the monitor. An Ignite-UX server is used as the source depot for the vparboot installation process. If an Ignite-UX server does not already exist for use with this process, install and configure one, preferably on another system, starting with steps 1 through 3 below. If an Ignite-UX server does exist, or is older than revision B.3.4.115, it will need to be updated. If your Ignite-UX server is already at revision B.3.4.115, continue with step 4 below.
-
Obtain Ignite-UX software. Sources include CDROM, software.hp.com, and SD-UX depot files. Note: the revision of Ignite-UX supported for the first release of vPars is B.3.4.115: # what /opt/ignite/bin/ignite /opt/ignite/bin/ignite: ignite user interface $Revision: 10.643 $ Ignite-UX Revision B.3.4.115 install/h $Revision: 10.102 $ This revision can be found on the September 2001 application distribution. Although previous versions of Ignite-UX may work, they are not supported for use with vPars, and may have problems with the relocatable WINSTALL file, which was built using libraries based on the B.3.4.115 revision of Ignite-UX. -
Install or update Ignite-UX software. Use swinstall to install Ignite-UX. -
Update PATH. Add the following search path to your login script(s): export PATH=${PATH}:/opt/ignite/bin If an Ignite-UX server already exists (revision B.3.4.115), add HP-UX 11i server OEs and vPars software to the Ignite-UX server (Note, there are various methods to install and configure software on the Ignite-UX server; described below is one method): -
Set up software within Ignite-UX to be installed on target vPars: -
- Create HP-UX 11i OE depots from September 2001 media (example using CDROM device c0t3d0): # make_depots -r B.11.11 -s /dev/dsk/c0t3d0 -
- Create a vPars application depot so that it will appear within the Software tab of itool during installation (using a tar-format depot file, and another example using an Ignite-UX server): # make_depots -r B.11.11 -a 800 -s /tmp/vpar_IC9.tar or # make_depots -r B.11.11 -a 800 -s flatcat.cup.hp.com:/opt/VPAR/ic9/depot Note: the above assumes that vPars source was available as a tar (depot) file or another Ignite-UX depot on the flatcat computer. A CDROM source will also work. The above example commands will create and copy vPars within the "apps_800" depot. -
- Create an Ignite-UX config file for the above depots (11i OEs and vPars): # make_config -r B.11.11 The above command creates the /var/opt/ignite/data/Rel_B.11.11/ apps_800_cfg configuration file. -
- Manage the Ignite-UX index file for applications: # manage_index -a -f /var/opt/ignite/data/Rel_B.11.11/ apps_800_cfg -
- Create HP-UX 11i OE depots from September 2001 media: Once the above steps are completed, copy the relocatable WINSTALL file for use with vPars to the Ignite-UX boot directory: # cd /opt/ignite/boot # cp WINSTALL WINSTALL_NoReloc # cp <source_path>/WINSTALL . (may also need to perform a chmod and chown.) Note that the <source_path> above means any source where WINSTALL exists. Using the WINSTALL bundled within Ignite-UX will not work (presently) for vPars, as it is not relocatable. The following is to verify that the correct WINSTALL is being used: # /usr/ccs/bin/elfdump -r /opt/ignite/boot/WINSTALL|fgrep -i relocation If no output is supplied from the above command then WINSTALL is not relocatable.
-
Start the Ignite-UX server manager: # /opt/ignite/bin/ignite -
Complete the Ignite-UX server configuration Select: Options -> Server Configuration... -
- Select the Server Options tab -
- Default Configuration: HP-UX B.11.11 Default. -
- Client timeouts: 40 -
- Run client installation UI on: server Select: Options -> Server Configurations... -> Session Options -
- Verify that only these options are set: -
- Confirm new clients -
- Show the welcome screen for the install server
-
- Ensure that the option Halt the client after installation is not selected.
| | Once the Ignite-UX server is installed and configured to install HP-UX OEs and vPars, proceed to use vparboot to install all remaining vPars as needed. |
More information on Ignite-UX is available in the Ignite-UX Administration Guide. ____________________________________________________ As I mentioned at the beginning of this chapter, you'll probably have more instances of HP-UX 11i to manage when you use vPars. Intalling these vPars from an Ignite-UX server will save you a lot of time and ensure that you have a consistent base of software for your installation. | 
