Using Ignite-UX GUI to Create a vPar Archive

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 clients to be managed in /etc/exports . Ignite-UX automatically included entries in /etc/exports for the clients 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 Ignite-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 9-12 on our server chess2 :

Figure 9-12. 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 9-13:

Figure 9-13. 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 9-14:

Figure 9-14. 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 a recovery archive of 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.