A Golden Image is a compressed archive of a current system. It contains all the software and hardware configurations on the existing system. This can be deployed to clients on the network who have similar configurations. The beauty of this model is that we can maintain multiple images based on the types of clients we are supporting. Should one of our clients fail in some way, it may be quicker to re-deploy the client than to try to fix it. I have seen many sites use this idea where the data stored on the client is relatively static and part of the archive, or there is no data on the client at all; it is purely a network client. If you are going to use this model for data servers, you will need to maintain your archives as often as you would maintain your normal backups . I am sure you understand the old adage, "You're only as good as your last backup." This applies to a Golden Image as well. There are many ways to set up a Golden Image, but one of the keys is to ensure that the system from which the image will be taken has been fully configured with as much software, kernel, and patch updates as you see fit. Any changes to such a system, i.e., adding more patches, should trigger a process that updates the Golden Image. Here is a process you could use to create a Golden Image: - Identify a suitable client machine.
- Install the Core OS.
- Install all relevant patches from the Support Plus media.
- Install all additional patches, e.g., using Custom Patch Manager and security_patch_check .
- Install all/any site-specific patches.
- Install any required applications and application patches.
- Perform all necessary customizations including kernel configuration changes.
- Use make_sys_image to create the Golden Image.
- Create an Ignite -UX configuration file that represents the contents of the Golden Image.
- Update the Ignite-UX INDEX file to reflect the new configurations that are now available.
- Test the Golden Image configuration.
This is only one possible solution. One drawback with this approach is that maintaining this archive is a little more time-consuming because everything a client needs is in the archive. The benefit of this solution is that the installation of a client is a simple affair; it is loaded from one source, and once complete, the client can quickly rejoin the network. Obviously, we could take a different approach and have a simple archive that is augmented with additional software loads from different software sources, much like the configuration we saw in the section 13.2.2, "Adding additional software to a Core OS configuration." There are no hard-and-fast rules here; you choose the solution that is best for you. I assume that you have performed steps 13.3.1 through 13.3.7 and are ready to create the Golden Image. 13.3.1 Use make_sys_image to create the Golden Image There are a couple of tasks we need to undertake on the server before we actually run the make_sys_image command on the client: -
If we are going to store the Golden Image directly onto the server, we will need to ensure that the $HOME/.rhosts file allows remote access to the client: root@hpeos004[ignite] cat /.rhosts hpeos003 root root@hpeos004[ignite] -
Create a directory on the server to store the archives: root@hpeos004[ignite] pwd /var/opt/ignite root@hpeos004[ignite] mkdir archives root@hpeos004[ignite] -
Ensure that there is enough disk space on the server to store the archive: root@hpeos004[ignite] bdf /var Filesystem kbytes used avail %used Mounted on /dev/vg00/lvol8 4194304 1309990 2704110 33% /var root@hpeos004[ignite] This is highly dependent on the number of Golden Images you will create. I have over 2GB of space available. This should be enough. -
Add the archive directory to the list of NFS exported directories on the server: root@hpeos004[ignite] vi /etc/exports /var/opt/ignite/clients -anon=2 /var/opt/ignite/archives -anon=2 root@hpeos004[ignite] root@hpeos004[ignite] exportfs -a root@hpeos004[ignite] -
Run make_sys_image on the client. The script make_sys_image comes as part of Ignite-UX. As such, we need to ensure Ignite-UX is installed on our clients before we are able to create a Golden Image. Because it's a script, we can modify it to suit our needs. We might want to modify the files that are reset during the make_sys_image process; these are configuration files such as our network configuration files under /etc and /etc/rc.config.d . We might want to exclude/include some additional files in the archive; make_sys_image does not include log or device files because they are unique to an individual machine. In essence, we may want to customize the make_sys_image script. If we do, it would be a good idea to copy it to some other location because a future installation of Ignite-UX could overwrite any changes we make in the original. When I first looked at this, I was concerned because my client is a trusted system . The make_sys_image script is clever enough to understand trusted systems ; in such a situation, it will not reset the /etc/passwd file to a default /etc/passwd file. If you have similar site-specific configurations, it is worth reviewing make_sys_image and ensuring that the files that are included/excluded from the archive are appropriate. I am going to run make_sys_image such that the archive is stored on the Ignite-UX server ( -s <IPlocal> ) under the directory /var/opt/ignite/archives ( -d <dir> ). I will check that there is enough space on the server to store the archive ( -u ). I will use the default compression, that is a compressed tar ( pax is used as the archive utility, but it writes the archive in tar (alternatively cpio ) format) archive. Because there is a considerable amount of file manipulation during a make_sys_image , I should avoid too much activity on the client while it is running: root@hpeos003[scripts] ./make_sys_image -s 192.168.0.35 -d /var/opt/ignite/ archives -u * Preparing to create a system archive * Testing pax for needed patch * Passed pax tests. WARNING: CLEAN_LEVEL set to 2: (see -l option for make_sys_image(1m)) While this command is running at clean level 2, the system should be as quiet as possible. The host and/or networking information on the system are temporarily set to newconfig values. After the command is complete these files are put back as they were. .................... * NOTE: The following core file(s) was/were found on your system and will be archived in your system image. /var/adm/cmcluster/core /core * The archive is estimated to reach 1362177 kbytes. * Free space on 192.168.0.35:/var/opt/ignite/archives after archive should be about 1341898 kbytes. * Archiving contents of hpeos003 via tar to 192.168.0.35:/var/opt/ignite/archives/hpeos003.gz. * Archiving contents of hpeos003 via tar to 192.168.0.35:/var/opt/ignite/archives/hpeos003.gz. * Creation of system archive complete * Cleanup: Do Not interrupt, restoring files, kernel, and transition links. root@hpeos003[scripts] The next part of this configuration is to try to ensure that I have a configuration file that describes this compressed tar archive. 13.3.2 Create an Ignite-UX configuration file that represents the contents of the Golden Image Unfortunately, we are going to have to get our hands dirty with this part of the configuration. There are no easy ways around this because the archive is in a non-Software Distributor format, so we simply can't use a make_config command. We will have to create a configuration file from scratch; well, not really. Those lovely people at HP have given us some example configuration files that we can use as a template: root@hpeos004[examples] pwd /opt/ignite/data/examples root@hpeos004[examples] ll total 50 -r--r--r-- 1 bin bin 1273 Jan 23 2002 README -r--r--r-- 1 bin bin 8551 Jan 23 2002 core.cfg -r--r--r-- 1 bin bin 7824 Jan 23 2002 core11.cfg dr-xr-xr-x 2 bin bin 1024 Feb 18 2003 networking -r--r--r-- 1 bin bin 4725 Jan 23 2002 noncore.cfg root@hpeos004[examples] In our case, because we have an archive that is essentially a Core operating system, we can use the core11.cfg file as a template. I will copy this to the directory where my other configuration files are stored. Once there, I can edit it to reflect the configuration of the archive: root@hpeos004[examples] cp core11.cfg /var/opt/ignite/data/Rel_B.11.11/archive11.cfg root@hpeos004[examples] root@hpeos004[examples] cd /var/opt/ignite/data/Rel_B.11.11 root@hpeos004[Rel_B.11.11] ll total 102 -rw-rw-r-- 1 root sys 33440 Sep 29 16:18 Core_OS.cfg -rw-rw-r-- 1 root sys 1330 Oct 1 09:46 FooProd.cfg -r--r--r-- 1 root sys 7824 Oct 1 12:36 archive11.cfg root@hpeos004[Rel_B.11.11] Part of the configuration file is the impact statements. Impact statements describe the amount of space required in a given filesystem when installing software. When managing other Ignite-UX configurations, the impact statements are calculated automatically ( make_config calculates the size of each sw_sel software product and simply adds them up). This is not the case when managing a Golden Image; we need to perform this step manually. I can use a command called archive_impact to work out the impact statements for me: root@hpeos004[archives] pwd /var/opt/ignite/archives root@hpeos004[archives] ll total 2055614 -rw-rw-rw- 1 root sys 1052435218 Oct 1 12:44 hpeos003.gz -rw-rw-rw- 1 root sys 30125 Oct 1 12:44 make_sys_image.log root@hpeos004[archives] root@hpeos004[archives] /opt/ignite/lbin/archive_impact -t -g $PWD/hpeos003.gz > /tmp /GOLDEN.impacts root@hpeos004[archives] root@hpeos004[archives] cat /tmp/GOLDEN.impacts impacts = "/" 1896Kb impacts = "/.dt" 70Kb impacts = "/.netscape" 21Kb impacts = "/depots" 67102Kb impacts = "/dev" 14Kb impacts = "/etc" 27310Kb impacts = "/home" 4640Kb impacts = "/ignite" 90Kb impacts = "/mcsg" 200Kb impacts = "/opt" 689746Kb impacts = "/sbin" 36015Kb impacts = "/stand" 1148Kb impacts = "/u01" 926619Kb impacts = "/usr" 774742Kb impacts = "/ux" 5Kb impacts = "/var" 206207Kb root@hpeos004[archives] I will use these impact statements in creating my configuration file. There are a number of example entries in the core11.cfg . You may have to spend some time to get used to the layout of the file. It's not too difficult and requires few changes. I have removed all comments to make it easier to read and underlined the lines I modified or added. I have included the impact statements from the archive_impact command. Here is the resulting configuration file: root@hpeos004[Rel_B.11.11] cat archive11.cfg sw_source "core archive" { description = "HP-UX Core Operating System Archives" load_order = 0 source_format = archive source_type="NET" post_load_script = "/opt/ignite/data/scripts/os_arch_post_l" post_config_script = "/opt/ignite/data/scripts/os_arch_post_c" nfs_source = "192.168.0.35:/var/opt/ignite/archives" } init sw_sel "golden image - 32 bit OS" { description = "English HP-UX 11.11 CDE - 32 Bit OS" sw_source = "core archive" sw_category = "HPUXEnvironments" archive_type = gzip tar archive_path = "Some32-bitArchive.gz" impacts = "/" 1898Kb impacts = "/.dt" 70Kb impacts = "/.netscape" 21Kb impacts = "/.secure" 1Kb impacts = "/depots" 67102Kb impacts = "/dev" 14Kb impacts = "/etc" 27312Kb impacts = "/home" 4640Kb impacts = "/ignite" 90Kb impacts = "/mcsg" 200Kb impacts = "/opt" 689746Kb impacts = "/sbin" 36015Kb impacts = "/stand" 1148Kb impacts = "/tcb" 102Kb impacts = "/u01" 926619Kb impacts = "/usr" 774742Kb impacts = "/ux" 5Kb impacts = "/var" 207120Kb exrequisite += "golden image - 64 bit OS" visible_if = can_run_32bit } = (can_run_32bit) init sw_sel "golden image - 64 bit OS" { description = "English HP-UX 11.11 CDE - 64 Bit OS" sw_source = "core archive" sw_category = "HPUXEnvironments" archive_type = gzip tar archive_path = "hpeos003.gz" exrequisite += "golden image - 32 bit OS" impacts = "/" 1898Kb impacts = "/.dt" 70Kb impacts = "/.netscape" 21Kb impacts = "/.secure" 1Kb impacts = "/depots" 67102Kb impacts = "/dev" 14Kb impacts = "/etc" 27312Kb impacts = "/home" 4640Kb impacts = "/ignite" 90Kb impacts = "/mcsg" 200Kb impacts = "/opt" 689746Kb impacts = "/sbin" 36015Kb impacts = "/stand" 1148Kb impacts = "/tcb" 102Kb impacts = "/u01" 926619Kb impacts = "/usr" 774742Kb impacts = "/ux" 5Kb impacts = "/var" 207120Kb visible_if = can_run_64bit } = (!can_run_32bit) (sw_sel "golden image - 32 bit OS") { _hp_os_bitness = "32" } (sw_sel "golden image - 64 bit OS") { _hp_os_bitness = "64" } sw_source "no select" { source_format = cmd } init sw_sel "English" { description = "English Language Environment" sw_source = "no select" sw_category = "Languages" locale = { "SET_NULL_LOCALE:English", "C:English" } } = TRUE has_ps2 { _hp_keyboard = { "Not_Applicable", "PS2_DIN_US_English", "PS2_DIN_US_English_Euro" } init _hp_keyboard = "PS2_DIN_US_English" } has_usb { _hp_keyboard = { "Not_Applicable", "USB_PS2_DIN_US_English", "USB_PS2_DIN_US_English_Euro" } init _hp_keyboard = "USB_PS2_DIN_US_English" } root@hpeos004[Rel_B.11.11] You may notice that I have included statements relating to the bitness of the operating system and whether clients will be able to see this archive, i.e., if they can support a 64-bit operating system. This is important if you have different types of clients in your network. It may be that you have two archives: one for 32-bit clients and one for 64-bit clients. 13.3.2.1 POST-CONFIGURE AND POST-LOAD SCRIPTS In the configuration file above, I have mentioned two scripts (see Table 13-1): Table 13-1. Post-Load/Post-Configure Scripts Type of Script | Script Name | Post-Configure script | /opt/ignite/data/scripts/os_arch_post_c | Post-Load script | /opt/ignite/data/scripts/os_arch_post_l | The idea behind these scripts is to perform additional functionality once the archive has been installed onto a client. In the case of the Post-Configure script, we hope we don't need to include it at all. Most people will include it for completeness. It comes in useful in the following situations: -
In some cases, the archive creation/extraction tools don't do a complete job, so we account for that here. -
Some SD configure scripts make changes based on the hardware of the machine. Since the machine where the archive is created may have different hardware than the target machine, we need to account for those actions here. -
Defects, which were found too late to fix in the Software Distributor control scripts, are sometimes handled here. With the Post-Load script, it is more likely that you will want to make some modifications to it. The biggest job of the Post-Load script is to merge, remove, or save the configuration files (primarily the networking configuration files) obtained during the extraction of the archive and the networking configuration obtained during the final part of the installation process. Here are some changes I made to the Post-Load script for my configuration: Default behavior: root@hpeos004[scripts] pwd /opt/ignite/data/scripts root@hpeos004[scripts] vi os_arch_post_l #save_file /etc/hosts #merge_file /etc/hosts rm -f /etc/resolv.conf #save_file /etc/resolv.conf #merge_file /etc/resolv.conf #save_file /etc/rc.config.d/namesvrs #merge_file /etc/rc.config.d/namesvrs ... #save_file /etc/fstab ... # save_file /etc/nsswitch.conf Changed to: ... #save_file /etc/hosts merge_file /etc/hosts #rm -f /etc/resolv.conf save_file /etc/resolv.conf #merge_file /etc/resolv.conf save_file /etc/rc.config.d/namesvrs #merge_file /etc/rc.config.d/namesvrs ... save_file /etc/fstab ... save_file /etc/nsswitch.conf ... NOTE : If you are going to make any changes to these files, you should store them in a separate location because a new/reinstallation of Ignite-UX will overwrite any changes you have made. 13.3.3 Update the Ignite-UX INDEX file to reflect the new configurations that are now available I can now update the Ignite-UX INDEX file to reflect my new Golden Image archive. There is one potential issue here. Previously, I have used the default disk/volume configuration file /opt/ignite/data/Rel.B.11.11/config file. One good aspect of this configuration file is that it has built-in logic to work out the size of volumes such as primary swap whose size can depend on the amount of memory a client has installed. If I wanted to truly emulate the client system, I would have to create a configuration file by hand or by using the save_config command on the client machine: root@hpeos003[scripts] save_config -f /tmp/save_config.out vg00 root@hpeos003[scripts] I would need to edit the resulting file ( /tmp/save_config.out ) to remove the network and hardware specific entries for this client. Here is the resulting configuration for my client: root@hpeos003[] more /tmp/save_config.out cfg "HP-UX System Recovery"=TRUE _hp_saved_detail_level="vfph" # # Variable assignments # init _hp_root_disk="0/0/1/1.15.0" init _hp_root_grp_disks=1 init _hp_root_grp_striped="NO" init _hp_pri_swap=2097152KB _hp_locale visible_if false _hp_cfg_detail_level visible_if false _hp_pri_swap visible_if false _hp_min_swap visible_if false _hp_disk_layout visible_if false _hp_default_cur_lan_dev visible_if false _hp_default_final_lan_dev visible_if false _hp_keyboard visible_if false _hp_root_disk visible_if false _hp_boot_dev_path visible_if false _hp_saved_detail_level visible_if false _hp_root_grp_disks visible_if false _hp_root_grp_striped visible_if false init _hp_disk_layout="HP-UX save_config layout" # # Disk and Filesystems # _hp_disk_layout+={"HP-UX save_config layout"} (_hp_disk_layout=="HP-UX save_config layout") { # Disk/Filesystem Layout: volume_group "vg00" { max_physical_extents=4350 max_logical_vols=255 max_physical_vols=16 physical_extent_size=8 minor_number=0x00 usage=LVM physical_volume disk[_hp_root_disk] { } # end pv_options logical_volume "lvol1" { usage=HFS size=114688KB mount_point="/stand" minfree=10 file_length=LONG blksize=8192 fragsize=1024 ncpg=16 nbpi=6334 rotational_delay=0 largefiles=FALSE bad_block_relocate=false contiguous_allocation=true stripes=0 stripe_size=0KB minor_number=0x01 disk[_hp_root_disk] } # end logical_volume logical_volume "lvol2" { usage=SWAP_DUMP size=2097152KB bad_block_relocate=false contiguous_allocation=true stripes=0 stripe_size=0KB minor_number=0x02 disk[_hp_root_disk] } # end logical_volume logical_volume "lvol3" { usage=VxFS size=1335296KB blksize=1024 mount_point="/" largefiles=FALSE bad_block_relocate=false contiguous_allocation=true stripes=0 stripe_size=0KB minor_number=0x03 disk[_hp_root_disk] } # end logical_volume logical_volume "lvol4" { usage=VxFS size=65536KB blksize=1024 mount_point="/tmp" largefiles=FALSE bad_block_relocate=true contiguous_allocation=false stripes=0 stripe_size=0KB minor_number=0x04 disk[_hp_root_disk] } # end logical_volume logical_volume "lvol5" { usage=VxFS size=24576KB blksize=1024 mount_point="/home" largefiles=FALSE bad_block_relocate=true contiguous_allocation=false stripes=0 stripe_size=0KB minor_number=0x05 disk[_hp_root_disk] } # end logical_volume logical_volume "lvol6" { usage=VxFS size=851968KB blksize=1024 mount_point="/opt" largefiles=FALSE bad_block_relocate=true contiguous_allocation=false stripes=0 stripe_size=0KB minor_number=0x06 disk[_hp_root_disk] } # end logical_volume logical_volume "lvol7" { usage=VxFS size=1122304KB blksize=1024 mount_point="/usr" largefiles=FALSE bad_block_relocate=true contiguous_allocation=false stripes=0 stripe_size=0KB minor_number=0x07 disk[_hp_root_disk] } # end logical_volume logical_volume "lvol8" { usage=VxFS size=614400KB blksize=1024 mount_point="/var" largefiles=FALSE contiguous_allocation=false stripes=0 stripe_size=0KB minor_number=0x07 disk[_hp_root_disk] } # end logical_volume } # end volume_group "vg00" } # end "HP-UX save_config layout" release="B.11.11" timezone="GMT0BST" root@hpeos003[] NOTE : You need to ensure that any hardware paths mentioned in this file are relevant for your Golden Image clients. I copied this to my Ignite-UX server to use as part of my Golden Image configuration. root@hpeos003[] rcp /tmp/save_config.out hpeos004:/var/opt/ignite/data/ Rel_B.11.11/archive_disk.cfg root@hpeos003[] I am now ready to add a new configuration to my Ignite-UX INDEX file. Here is my complete INDEX file: root@hpeos004[ignite] pwd /var/opt/ignite root@hpeos004[ignite] root@hpeos004[ignite] vi 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" } cfg "Golden Image" { description "HP-UX B.11.11 Golden Image" "/var/opt/ignite/data/Rel_B.11.11/archive11.cfg" "/var/opt/ignite/data/Rel_B.11.11/archive_disk.cfg" "/var/opt/ignite/config.local" } root@hpeos004[ignite] I will check this complete configuration for syntax errors: root@hpeos004[ignite] 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 * Checking file: /var/opt/ignite/data/Rel_B.11.11/archive11.cfg * Checking file: /var/opt/ignite/data/Rel_B.11.11/archive_disk.cfg root@hpeos004[ignite] root@hpeos004[ignite] manage_index -l HP-UX B.11.11 Default HP-UX B.11.11 FooProd Golden Image root@hpeos004[ignite] The only consideration I have is the content of the first 8KB of the INSTALLFS file. Previously, I set up a root password in this file. To ensure that I don't use that password for my Golden Image, which is a trusted system and has a root password already established, I will build some logic into my INSTALLFS file: root@hpeos004[] instl_adm -d > /tmp/instl.out root@hpeos004[] vi /tmp/instl.out # 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 !( cfg "Golden Image" ) { 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.out root@hpeos004[] This logic means that the installation will not set up a root password. This is okay because we are extracting from the archive the trusted systems database. I am now ready to test the Golden Image. 13.3.4 Test the Golden Image configuration I could now attempt to install a client using the Golden Image. In my case, I will attempt to reinstall the system that acted as the Golden System. First, I will reset some attribute to test that it was the Golden Image that was actually installed: root@hpeos003[] /usr/lbin/tsconvert -r Restoring /etc/passwd... /etc/passwd restored. Deleting at and crontab audit ID files... At and crontab audit ID files deleted. root@hpeos003[] root@hpeos003[] bdf /dev/vg00/lvol3 1335296 1056096 261777 80% / /dev/vg00/lvol1 111637 53265 47208 53% /stand /dev/vg00/lvol8 614400 338839 258352 57% /var /dev/vg00/lvol7 1122304 773682 326888 70% /usr /dev/vg00/lvol4 65536 30153 33235 48% /tmp /dev/vg00/lvol6 851968 686803 154858 82% /opt /dev/vg00/lvol5 24576 5765 17678 25% /home root@hpeos003[] root@hpeos003[] lvextend -L 200 /dev/vg00/lvol5 Logical volume "/dev/vg00/lvol5" has been successfully extended. Volume Group configuration for /dev/vg00 has been saved in /etc/lvmconf/vg00.conf root@hpeos003[] fsadm -F vxfs -b 200M /home vxfs fsadm: /dev/vg00/rlvol5 is currently 24576 sectors - size will be increased root@hpeos003[] bdf Filesystem kbytes used avail %used Mounted on /dev/vg00/lvol3 1335296 1056368 261522 80% / /dev/vg00/lvol1 111637 53265 47208 53% /stand /dev/vg00/lvol8 614400 338839 258352 57% /var /dev/vg00/lvol7 1122304 773682 326888 70% /usr /dev/vg00/lvol4 65536 30153 33235 48% /tmp /dev/vg00/lvol6 851968 686803 154858 82% /opt /dev/vg00/lvol5 204800 5813 186593 3% /home root@hpeos003[] I will now reinstall this system, and I expect it to return to its former configuration once the installation is complete. I will use bootsys to boot the client and use the Golden Image archive: root@hpeos004[] bootsys -i "Golden Image" -f hpeos003 Rebooting hpeos003 now. root@hpeos004[] As you can see in Figure 13-3, I have picked up the Golden Image configuration from the Ignite-UX server. Figure 13-3. Installing a Golden Image. Once the installation is complete, I will test to ensure that we are a trusted system again, and that the /home filesystem has been configured correctly. root@hpeos003[] cat /tcb/files/auth/r/root root:u_name=root:u_id#0:\ :u_pwd=9ea83MEzCNwmI:\ :u_bootauth:u_auditid#0:\ :u_auditflag#1:\ :u_succhg#1065026597:u_pswduser=root:u_suclog#1065026597:u_suctty=consol e:\ :u_lock@:chkent: root@hpeos003[] root@hpeos003[] bdf Filesystem kbytes used avail %used Mounted on /dev/vg00/lvol3 1335296 1056853 261063 80% / /dev/vg00/lvol1 111637 27030 73443 27% /stand /dev/vg00/lvol8 614400 206161 382782 35% /var /dev/vg00/lvol7 1122304 774080 326483 70% /usr /dev/vg00/lvol4 65536 1184 60400 2% /tmp /dev/vg00/lvol6 851968 685277 156289 81% /opt /dev/vg00/lvol5 24576 5765 17678 25% /home root@hpeos003[] root@hpeos003[] 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 root@hpeos003[] This all looks great. I would say that we have had success with our Golden Image. The last configuration we look at is in some ways similar to a Golden Image, except it is unique to an individual node; it is known as a Recovery Archive. |