In this chapter, we start the discussion on installing software from the premise that we all know the basics of installing, removing, and updating software using basic Software Distributor commands like swinstall, swremove, and the various associated logfiles like swagentd.log. We start by looking at Software Distributor as a tool for installing software across the network. This should not be new to us; most administrators should be perfectly aware of pulling software across the network using swinstall. The problem with this is that you need to log in to each server in turn and issue a swinstall command. We look at using Software Distributor to push software across the network. From a central software depot, we issue a single swinstall command to push software to a collection of machines on our network. From there, we discuss using Ignite-UX to push an entire operating system image onto a client. That operating system image can either be a fresh installation of it can be an image of our ideal server—a so-called Golden Image, containing all of the customizations an ideal server would require to exist in a complex network infrastructure.
The installation media we have is used not only for installing the operating system but also to help us repair it after a disaster or major corruption. Although reinstalling a system using a Golden Image is relatively quick, it means a loss of some data stored in the operating system disks. We can try to affect a recovery of the operating system using the Recovery Shell available on the Install media. We can affect some complex recovery procedures that would normally render a system unusable. We look at scenarios where booting the system in maintenance mode boot fails and how we can attempt to recover the system using the Recovery Shell. As always with troubleshooting, there comes a time when a good administrator will say, “enough is enough.” With good backup and recovery procedures, no machine should be out of action for too long.
We look at the steps necessary to set up Software Distributor to push software across the network. I assume that you have already set up a software depot containing software, patches, or a combination of both; we looked at those issues in Chapter 12. The process of pushing software to a remote host is known in Software Distributor documentation as Remote Operations. This capability became available as of HP-UX 11i. In general, all Software Distributor features that apply to local operations also apply to Remote Operations. The limitations of Remote Operations include the following:
You cannot use Remote Operations to directly push an entire HP-UX operating system update to remote systems.
Remote operations do not apply to the following SD-UX commands:
install-sdswpackageswmodify
I am going to perform Remote Operations from the same machine that hosts the depots containing software products. This need not be the case: You could initiate a swinstall from one node that pushes software from a depot on some remote server onto distant Remote Operations clients. Setting up Remote Operations is relatively simple and can be summarized as follows:
Set up a software/patches depot on a central server (we will call this server our depot server).
Make a special
Service Control Managerdepot available on the depot server.Set up Remote Operations Agent software on each client machine.
On the depot server, set up Remote Operations GUI (optional).
Push software to remote clients.
Let's look at each of these steps in a little more detail.
Setting up software and associated patches can take some time and some considerable disk space. In Chapter 12, we looked at the pros and cons of setting up a depot that contained not only software but any associated patches as well. The default behavior for Software Distributor is to install any associated patches available in the same depot as the base software; Software Distributor utilizes the option autoselect_dependencies=true. This can make installing up-to-date software somewhat easier and more efficient. In this example, I have a number of depots available to me; I have spent some considerable time setting up these depots:
root@hpeos004[] swlist -l depot
# Initializing...
# Target "hpeos004" has the following depot(s):
/software/11i-PA/FooProd
/software/11i-PA/patches
/software/11i-PA/core
/software/11i-PA/IPv6
/software/11i-PA/SG11.14
root@hpeos004[]
To demonstrate Remote Operations, I utilize the IPv6 depot that contains IPv6 software including additional IPv6-enabled utilities:
root@hpeos004[] swlist -d @ /software/11i-PA/IPv6
# Initializing...
# Contacting target "hpeos004"...
#
# Target: hpeos004:/software/11i-PA/IPv6
#
#
# Bundle(s):
#
DHCPv6 B.11.11.01 DHCPv6 web release
IPv6NCF11i B.11.11.0109.5D IPv6 11i product bundle
IPv6Patches B.11.11 Patches to enable IPv6 functionality in standard OS software
Sendmail-811 B.11.11.01.005 Sendmail-8.11.1 special release upgrade
WU-FTP-261 B.11.11.01.003 WU-FTPD-2.6.1 special release upgrade
root@hpeos004[]
My aim is to install these products and related patches onto a number of nodes in my network. I need to ensure that these clients allow the depot server access to their system in order to allow an install to take place from a remote location.
Service Control Manager (SCM) is a software product made available in HP-UX 11i. SCM includes lot of the functionality of SAM. One major difference with SCM is that it is simple to include other nodes in a network into the SCM framework whereby management of these nodes can be controlled centrally. To make management of multiple nodes even easier, SCM allows for a central server to associate UNIX users with particular roles. These roles, e.g., the role of Operator, can be given access to specific tasks with the SCM framework. Part of that framework allows for tasks to be executed on remote machines. In this way, an Operator can perform specific tasks on multiple nodes from one central location: the SCM central server. Part of the SCM product is a Software Distributor depot. The depot can be installed on remote clients that allow Software Distributor to perform a push of software components over the network. We make this depot available to clients simply by registering the depot on the depot server:
root@hpeos004[] swreg -l depot @ /var/opt/mx/depot11
======= 09/29/03 12:19:44 BST BEGIN swreg SESSION (non-interactive)
* Session started for user "root@hpeos004".
* Beginning Selection
* Targets: /var/opt/mx/depot11
* Selection succeeded.
======= 09/29/03 12:19:44 BST END swreg SESSION (non-interactive)
root@hpeos004[]
There is a depot for HP-UX 11.X clients as well as for HP-UX 10.X clients. There are two software filesets in this depot:
root@hpeos004[] swlist -l fileset -s /var/opt/mx/depot11
# Initializing...
# Contacting target "hpeos004"...
#
# Target: hpeos004:/var/opt/mx/depot11
#
# AgentConfig ServiceControl Agent Config
AgentConfig.SCR-CONFIG agent configuration for SCR
AgentConfig.SD-CONFIG Managed Node Agent Configuration for SD
root@hpeos004[]
We need only the AgentConfig.SD-CONFIG fileset to enable Remote Operations for Software Distributor. You can install the other fileset if you wish; it will enable Remote Operations for a utility known as System Configuration Repository. By installing the AgentConfig.SD-CONFIG software in this depot, we are actually modifying the Software Distributor ACLs in order for client machines to allow the depot server to install software onto those clients remotely.
We will install the software on all client machines, from the SCM depot located on the depot server. The software is actually a single file called /usr/lbin/sw/setaccess. This script is run as part of the post-installation phase. This script actually manipulates the Software Distributor ACLs on the client machine. Here are the default ACL entries for one of our clients:
root@hpeos003[] swacl -l global_product_template
#
# swacl Global Template for Product Access Control Lists
#
# For host: hpeos003
#
# Date: Mon Sep 29 12:44:31 2003
#
# Object Ownership: User= root
# Group=sys
# Realm=hpeos003
#
# default_realm=hpeos003
object_owner:crwit
any_other:-r---
root@hpeos003[]
We will install the AgentConfig.SD-CONFIG fileset on this node:
root@hpeos003[]swinstall -s hpeos004:/var/opt/mx/depot11 AgentConfig.SD-CONFIG
======= 09/29/03 12:51:41 BST BEGIN swinstall SESSION
(non-interactive) (jobid=hpeos003-0043)
* Session started for user "root@hpeos003".
* Beginning Selection
* Target connection succeeded for "hpeos003:/".
* Source connection succeeded for
"hpeos004:/var/opt/mx/depot11".
* Source: hpeos004:/var/opt/mx/depot11
* Targets: hpeos003:/
* Software selections:
AgentConfig.SD-CONFIG,a=HP-UX_B.11.00_32/64,v=HP
* Selection succeeded.
* Beginning Analysis and Execution
* Session selections have been saved in the file
"/.sw/sessions/swinstall.last".
* The analysis phase succeeded for "hpeos003:/".
* The execution phase succeeded for "hpeos003:/".
* Analysis and Execution succeeded.
NOTE: More information may be found in the agent logfile using the
command "swjob -a log hpeos003-0043 @ hpeos003:/".
======= 09/29/03 12:51:53 BST END swinstall SESSION (non-interactive)
(jobid=hpeos003-0043)
root@hpeos003[]
Let's see what has happened to my Software Distributor ACL entries:
root@hpeos003[] swacl -l global_product_template
#
# swacl Global Template for Product Access Control Lists
#
# For host: hpeos003
#
# Date: Mon Sep 29 12:53:37 2003
#
# Object Ownership: User= root
# Group=sys
# Realm=hpeos003
#
# default_realm=hpeos003
object_owner:crwit
user:root@hpeos004:crwit
any_other:-r---
root@hpeos003[]
As you can see, my depot server now has full access to this machine in order to install and manage Software Distributor objects.
Some people would say that, technically, you don't need to install the AgentConfig.SD-CONFIG fileset to enable remote operations. If you know what you are doing, you could simply manipulate the Software Distributor ACLs by hand. Please be very careful if you adopt this mindset.
Software Distributor Access Control Lists (ACLs) offer a greater degree of selectivity than do permission bits. An ACL extends the concept of the HP-UX file system's permission bits by letting you specify different access rights to several individuals and groups instead of just one of each.
The ACLs manipulated during the swinstall process are those protecting the source host (the host ACL), the host's template ACLs used in subsequent operations to produce ACLs for products (the global_product_template), and depot/root containers (the global_soc_template). When you copy these ACLs, users on the source host are immediately granted the same permissions on the destination host as they have locally on the source host. In addition, an entry for the superuser at the source host was added. This lets the root user on the depot server perform software distribution tasks on the remote system without having to reconfigure ACLs.
If you need to change security, the following tasks can be performed (i.e., to understand and modify the default setup):
Listing user access
Allowing user to manage products in a depot
Allowing user to manage roots
Restricting read access to a depot
Adding target hosts
Restricting access to a depot temporarily
Closing the SD-UX network
Above, we can see that the depot server (hpeos004) has been included in the product's (global_product_template) ACL. Similar output would be achieved if we specified a level of global_soc_template or host.
If the AgentConfig.SD-CONFIG fileset is not available or it's installation failed in some way, we would have to ensure that the ACLs were set up accordingly. In this case, the following commands would have to be run on the client node hpeos003:
Allow access to the host/root:
# swacl -l host -M user:root@hpeos004:a # swacl -l root -M user:root@hpeos004:a
Ensure access to future products and depots:
# swacl -l global_product_template -M user:root@hpeos004:a
# swacl -l global_soc_template -M user:root@hpeos004:a
We may have to manage the default ACLs on the depot server itself, e.g., to enable access to existing depots and products in those depots:
# swacl -l depot -M user:root@hpeos004:a @ /software/11i-PA/IPv6 # swacl -l product_template -M user:root@hpeos004:a @ /software/11i-PA/IPv6
You need to be careful if you change the hostname of an existing depot server. There is a concept called a default realm, which is defined as follows:
“An ACL defines a default realm for an object. The realm is currently defined as the name of the host system on which the object resides. When using swacl to view an ACL, the default realm is printed as a comment in the header.”
If we were to change the hostname of our server, this header stating the default realm would be wrong. In such a situation, you will need to edit the files in the directory /var/adm/sw/security:
root@hpeos004[security] pwd /var/adm/sw/security root@hpeos004[security] grep -i realm * _ACL:# default_realm=hpeos004 _OWNER:# default_realm=hpeos004 _PROD_DFLT_ACL:# default_realm=hpeos004 _SOC_DFLT_ACL:# default_realm=hpeos004 root@hpeos004[security]
For more information on Software Distributor's ACLs, refer to document B2355-90699: Software Distributor Administration Guide for HP-UX 11i available at http://docs.hp.com.
The Software Distributor commands swinstall, swcopy, and swremove have enhanced GUI interfaces relating to Remote Operations. To provide access to these enhanced GUI interfaces, we simply perform the following command on our depot server:
root@hpeos004[security] touch /var/adm/sw/.sdkey root@hpeos004[security] ll /var/adm/sw/.sdkey -rw-rw-r-- 1 root sys 0 Sep 29 13:51 /var/adm/sw/.sdkey root@hpeos004[security]
This step is not required when you use Software Distributor from within Service Control Manager.
I have performed the necessary steps to set up three machines as Remote Operations clients: hpeos001, hpeos002, and hpeos003. I can now use a single swinstall command to install all the product/patches from my IPv6 depot onto all of these Remote Operations clients:
root@hpeos004[] swinstall -x patch_match_target=true -x autoreboot=true -s / software/11i-PA/IPv6 * @ hpeos001 hpeos002 hpeos003 ======= 09/29/03 14:13:34 BST BEGIN swinstall SESSION (non-interactive) (jobid=hpeos004-0193) * Session started for user "root@hpeos004". * Beginning Selection * Target connection succeeded for "hpeos001:/". * Source connection succeeded for "hpeos004:/software/11i-PA/IPv6". NOTE: The software "IPV6AA" was successfully marked, but it depends on the following software items which could not be found in the source. However, these items may already be in the target. This will be checked during the Analysis Phase: PHNE_25644.NET2-KRN,fa=HP-UX_B.11.11_32 | PHNE_25644.NET2-KRN,fa=HP-UX_B.11.11_64 PHNE_25644.CORE2-KRN,fa=HP-UX_B.11.11_32 | PHNE_25644.CORE2-KRN,fa=HP-UX_B.11.11_64 ERROR: Could not apply the software selection "PHKL_25233" because there are no product variations that are compatible with the destination host(s). ... NOTE: More information may be found in the agent logfile using the command "swjob -a log hpeos004-0194 @ <host>:<path>". ======= 09/29/03 14:16:07 BST END swinstall SESSION (non-interactive) (jobid=hpeos004-0193) root@hpeos004[]
As with any swinstall process, we need to monitor any ERRORS and correct them if they will stop an individual installation on a specific node. Once complete, we need to check the swagent.log file on all the client nodes to ensure that each installation was successful. We need to check that the software itself was installed and in good working order. Just because we issued a single swinstall command does not mean that we have less of a job to check up on all the affected client nodes.
root@hpeos003[] swlist -l product |grep -i -e dhcp -e send -e wu -e ipv6
DHCPV6 B.11.11.01 DHCPv6 Web release
IPV6AA A.01.01.5D IPv6 11i product
PHSS_24261 1.0 HP DCE/9000 1.8 DCE Client IPv6 patch
SMAIL-811 B.11.11.01.005 sendmail(1m) 811 special release upgrade
WUFTP-26 B.11.11.01.003 wu-ftpd 2.6.1 special release upgrade
root@hpeos003[]
In this instance, it looks like the IPv6 software was loaded successfully, as was a selection of the patches from the depot server.
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.
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
tftpandinstl_bootdservices in/etc/inetd.conf.Set up
/etc/exportsto give NFS access to the/var/opt/ignite/clientsdirectory.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.
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.
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.
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.
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[]
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.cfg # 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.
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.
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.
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.
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.
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).
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).
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.
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.
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]
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.
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.
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.
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_imageto 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.
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/.rhostsfile 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_imageon 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 <IP|local>) 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.
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.
In the configuration file above, I have mentioned two scripts (see Table 13-1):
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.
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.
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.
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.
A Recovery Archive is similar in some ways to a Golden Image. The major difference is that a Recovery Archive is unique to an individual machine. When used to perform an installation, it will recover that system to exactly the way it was configured when the Recovery Archive was created with no user intervention. As such, it can be viewed as a customized Ignite-UX installation device.
A Recovery Archive can be used to clone systems, in a similar way to a Golden Image, but user interaction will be required at the beginning of the installation to stop the Recovery Archive from using the hostname/IP address configuration of the node that created the Recovery Archive.
There are three options in creating a Recovery Archive. The commands are similar but subtly different:
make_recovery: Not many options to it; not highly configurable and as such not used as much these days.
make_tape_recovery: Used to create a Recovery Archive to a local tape device.
make_net_recovery: Used to create a Recovery Archive that is stored on an Ignite-UX server located on the network.
In essence, these commands are a simple interface into the make_sys_image command. We see this in the output to commands later. We look at make_net_recovery. The other commands are either similar or are not as complicated; as such, you should find them easy to navigate.
When creating a Recovery Archive, the clients will store configuration files on the Ignite-UX server under the directory /var/opt/ignite/clients while the actually Recovery Archive itself will be stored (by default) under the directory /var/opt/ignite/recovery/archives/<client>. In my experience, the Ignite/UX server and the server storing the Recovery Archive (the Archive Server) are usually the same machine, although technically they don't have to be. Both these directories need to be NFS exported to the client. In many cases, I have seen the /var/opt/ignite/recovery directory exported to everyone. While this is easier to set up, it has security implications. Ideally, we would export individual client directories to individual clients. We just need to make sure that when we create individual client directories, they are owned by user and group bin:bin:
root@hpeos004[archives] pwd /var/opt/ignite/recovery/archives root@hpeos004[archives] mkdir hpeos003 root@hpeos004[archives] chown bin:bin hpeos003 root@hpeos004[archives] ll total 0 drwxrwxr-x 2 bin bin 96 Oct 1 17:41 hpeos003 root@hpeos004[archives] root@hpeos004[archives] cat /etc/exports /var/opt/ignite/recovery/archives/hpeos003 -anon=2,access=hpeos003 /var/opt/ignite/clients -anon=2 /var/opt/ignite/archives -anon=2 root@hpeos004[archives] root@hpeos004[archives] exportfs -a root@hpeos004[archives]
Again, we need to ensure that there is adequate disk space under /var to accommodate an entire tar archive of vg00 for all the clients on the network.
It is a good idea that the clients are using the most up-to-date versions of the Recovery Commands loaded on our Ignite-UX server. To assist in this, we have some commands that we can run to create a depot of the necessary Recovery Commands required on the clients. We do this on our Ignite-UX server:
root@hpeos004[] swlist -l depot
# Initializing...
# Target "hpeos004" has the following depot(s):
/software/11i-PA/FooProd
/software/11i-PA/patches
/software/11i-PA/core
/software/11i-PA/IPv6
/software/11i-PA/SG11.14
/var/opt/mx/depot11
root@hpeos004[]
This tells me that we haven't created the depot for the Recovery Commands. If we were to initiate a Network Recovery Archive from the Ignite-UX GUI running on the Ignite-UX server, it would automatically create the depot for me. Here is the command to create it by hand:
root@hpeos004[] /opt/ignite/lbin/pkg_rec_depot
* Generating the product specification file.
======= 10/01/03 18:03:49 BST BEGIN swreg SESSION (non-interactive)
* Session started for user "root@hpeos004".
* Beginning Selection
* Targets: hpeos004
* Objects: /var/opt/ignite/depots/recovery_cmds
* Selection succeeded.
======= 10/01/03 18:03:49 BST END swreg SESSION (non-interactive)
* Creating depot: /var/opt/ignite/depots/recovery_cmds
======= 10/01/03 18:03:50 BST BEGIN swpackage SESSION
* Session started for user "root@hpeos004".
* Source: hpeos004:/var/tmp/rec_psf.5769
* Target: hpeos004:/var/opt/ignite/depots/recovery_cmds
* Software selections:
*
* Beginning Selection Phase.
* Reading the Product Specification File (PSF)
"/var/tmp/rec_psf.5769".
* Reading the product "Ignite-UX" at line 5.
* Reading the fileset "BOOT-KERNEL" at line 16.
* Reading the fileset "BOOT-SERVICES" at line 46.
* Reading the fileset "FILE-SRV-11-11" at line 70.
* Reading the fileset "IGNITE" at line 93.
* Reading the fileset "IGNT-ENG-A-MAN" at line 248.
* Reading the fileset "MGMT-TOOLS" at line 309.
* Reading the fileset "OBAM-RUN" at line 391.
* Reading the fileset "RECOVERY" at line 426.
NOTE: Creating new target depot
"/var/opt/ignite/depots/recovery_cmds".
* Selection Phase succeeded.
* Beginning Analysis Phase.
* Analysis Phase succeeded.
* Beginning Package Phase.
NOTE: You have specified the "package_in_place" option. The
software you have selected will be packaged with references to
the actual source files. No source files will be copied into
the target depot "/var/opt/ignite/depots/recovery_cmds".
* Packaging the product "Ignite-UX".
* Packaging the fileset "Ignite-UX.BOOT-KERNEL".
* Packaging the fileset "Ignite-UX.BOOT-SERVICES".
* Packaging the fileset "Ignite-UX.FILE-SRV-11-11".
* Packaging the fileset "Ignite-UX.IGNITE".
* Packaging the fileset "Ignite-UX.IGNT-ENG-A-MAN".
* Packaging the fileset "Ignite-UX.MGMT-TOOLS".
* Packaging the fileset "Ignite-UX.OBAM-RUN".
* Packaging the fileset "Ignite-UX.RECOVERY".
* Package Phase succeeded.
NOTE: You must register the new depot
"/var/opt/ignite/depots/recovery_cmds" to make it generally
available as a source for swinstall and swcopy tasks. To
register it, execute the command
swreg -l depot /var/opt/ignite/depots/recovery_cmds
======= 10/01/03 18:03:51 BST END swpackage SESSION
* Registering depot: /var/opt/ignite/depots/recovery_cmds
======= 10/01/03 18:03:51 BST BEGIN swreg SESSION (non-interactive)
* Session started for user "root@hpeos004".
* Beginning Selection
* Targets: hpeos004
* Objects: /var/opt/ignite/depots/recovery_cmds
* Selection succeeded.
======= 10/01/03 18:03:51 BST END swreg SESSION (non-interactive)
* Creating IUX Recovery bundles.
======= 10/01/03 18:03:53 BST BEGIN swpackage SESSION
* Session started for user "root@hpeos004".
* Source: hpeos004:/var/tmp/psf.5792
* Target: hpeos004:/var/opt/ignite/depots/recovery_cmds
* Software selections:
*
* Beginning Selection Phase.
* Reading the Product Specification File (PSF)
"/var/tmp/psf.5792".
* Reading the bundle "Ignite-UX-11-11" at line 11.
WARNING: Converting software from a source with layout_version 1.0 into
a target with layout_version 0.8 since the layout_version
option is set to 0.8.
Note by converting 1.0 software to layout_version 0.8, you
will lose any new 1.0 attributes which can corrupt the
software if it depends on 1.0 attributes.
* Selection Phase succeeded.
* Beginning Analysis Phase.
* Analysis Phase succeeded.
* Beginning Package Phase.
* Packaging the bundle
"Ignite-UX-11-11,r=B.3.6.82,a=HP-UX_B.11.11_32/64".
* Package Phase succeeded.
======= 10/01/03 18:03:53 BST END swpackage SESSION
======= 10/01/03 18:03:54 BST BEGIN swpackage SESSION
* Session started for user "root@hpeos004".
* Source: hpeos004:/var/tmp/psf.5814
* Target: hpeos004:/var/opt/ignite/depots/recovery_cmds
* Software selections:
*
* Beginning Selection Phase.
* Reading the Product Specification File (PSF)
"/var/tmp/psf.5814".
* Reading the bundle "IUX-Recovery" at line 11.
WARNING: Converting software from a source with layout_version 1.0 into
a target with layout_version 0.8 since the layout_version
option is set to 0.8.
Note by converting 1.0 software to layout_version 0.8, you
will lose any new 1.0 attributes which can corrupt the
software if it depends on 1.0 attributes.
* Selection Phase succeeded.
* Beginning Analysis Phase.
* Analysis Phase succeeded.
* Beginning Package Phase.
* Packaging the bundle
"IUX-Recovery,r=B.3.6.82,a=HP-UX_B.11.11_32/64".
* Package Phase succeeded.
======= 10/01/03 18:03:54 BST END swpackage SESSION
root@hpeos004[]
We can now use this depot to install the Recovery Commands onto all the clients in the network. We could use this script periodically on all the clients to automatically update the Recovery Commands if the server has a newer version than the client:
root@hpeos003[] ll /usr/local/bin/check_rec_cmds.sh -rwx------ 1 root sys 181 Oct 1 18:09 /usr/local/bin/check_rec_cmds.sh root@hpeos003[] cat /usr/local/bin/check_rec_cmds.sh #!/sbin/sh IUXServer=hpeos004 /opt/ignite/lbin/check_version -s ${IUXServer} if [ $? != 0 ] then swinstall -s ${IUXServer}:/var/opt/ignite/depots/recovery_cmds IUX-Recovery fi root@hpeos003[]
Once we have the updated Recovery Commands, we can proceed with using make_net_recovery.
When we run make_net_recovery, we can simply run it with a command line such as:
# make_net_recovery –s <IgniteServer>
This will archive a list of files contained in /opt/ignite/recovery/mnr_essentials (and /var/opt/ignite/recovery/mnr_essentials if we have set it up). The mnr_essentials file does not contain lots of files. As the name suggests, it would just be enough for you to boot your client and perform some basic recovery, e.g., recover all your vg00 files from a backup tape. Most of the time, administrators will want their Recovery Archive to be a complete archive or vg00 and possibly other volume groups (although if your other volume groups are on separate disks and backed up regularly, having them as part of a Recovery Archive might be overkill) I am going to use the –A option to make_net_recovery, which will include all the disk and volume groups that house the files mentioned in the mnr_essentials file(s). In most instances, this is a convenient way to have vg00 backed up in its entirety.
root@hpeos003[] make_net_recovery -A -s hpeos004
* Creating NFS mount directories for configuration files.
======= 10/01/03 18:27:52 BST Started make_net_recovery. (Wed Oct 01 18:27:52
BST 2003)
@(#) Ignite-UX Revision B.3.6.82
@(#) net_recovery (opt) $Revision: 10.567 $
* Testing pax for needed patch
* Passed pax tests.
* Checking Versions of Recovery Tools
* Creating System Configuration.
* /opt/ignite/bin/save_config -f /var/opt/ignite/recovery/client_mnt/0x0
0306E5C3FF8/recovery/2003-10-01,18:27/system_cfg vg00
NOTE: File: /var/opt/ignite/recovery/client_mnt/0x00306E5C3FF8/recovery/2003
-10-01,18:27/system_cfg is not world-readable, this may cause clients to
fail to read it during an installation.
* 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.
NOTE: File: /var/opt/ignite/recovery/client_mnt/0x00306E5C3FF8/recovery/2003
-10-01,18:27/control_cfg is not world-readable, this may cause clients
to fail to read it during an installation.
* Creating Archive File List
* Creating Archive Configuration
* /opt/ignite/bin/make_arch_config -c /var/opt/ignite/recovery/client_mn
t/0x00306E5C3FF8/recovery/2003-10-01,18:27/archive_cfg -g /var/opt/ign
ite/recovery/client_mnt/0x00306E5C3FF8/recovery/2003-10-01,18:27/flist
-n 2003-10-01,18:27 -r 64 -d Recovery Archive -L
/var/opt/ignite/recovery/arch_mnt -l
hpeos004:/var/opt/ignite/recovery/archives/hpeos003 -i 1
NOTE: File: /var/opt/ignite/recovery/client_mnt/0x00306E5C3FF8/recovery/2003
-10-01,18:27/archive_cfg is not world-readable, this may cause clients
to fail to read it during an installation.
* 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 2003-10-01,18:27 -m
t -w /var/opt/ignite/recovery/client_mnt/0x00306E5C3FF8/recovery/2003-
10-01,18:27/recovery.log -u -R -g /var/opt/ignite/recovery/client_mnt/
0x00306E5C3FF8/recovery/2003-10-01,18:27/flist -a 2929740
* Preparing to create a system archive
* The archive is estimated to reach 1464870 kbytes.
* Free space on /var/opt/ignite/recovery/arch_mnt
after archive should be about 1324738 kbytes.
* Archiving contents of hpeos003 via tar to
/var/opt/ignite/recovery/arch_mnt/2003-10-01,18:27.
* Creation of system archive complete
NOTE: Could not read the /etc/resolv.conf file.
* Creating CINDEX Configuration File
* /opt/ignite/bin/manage_index -q -c 2003-10-01,18:27 Recovery Archive
-i /var/opt/ignite/recovery/client_mnt/0x00306E5C3FF8/CINDEX -u
Recovery Archive
======= 10/01/03 18:44:04 BST make_net_recovery completed successfully!
root@hpeos003[]
I can include other files, directories, and volume groups by using options such as –x include=file|dir and –x inc_entire=dsk|vg. The archive will be created on the Ignite/Archive Server under a subdirectory named after the MAC address of my LAN card (the LAN card used can be modified using the –l <MAC> option). The configuration files generated are stored under a directory whose name reflects the time the last archive was created:
root@hpeos004[recovery] ll total 4 drwxr-xr-x 2 bin bin 1024 Oct 1 18:44 2003-10-01,18:27 -rw------- 1 bin sys 290 Oct 1 18:44 client_status lrwx------ 1 bin bin 16 Oct 1 18:28 latest -> 2003-10-01,18:27 root@hpeos004[recovery] ll 2003-10-01,18:27/ total 9110 -rw------- 1 bin sys 3375 Oct 1 18:28 archive_cfg -rw------- 1 bin sys 17 Oct 1 18:28 archive_content -rw------- 1 bin sys 289 Oct 1 18:28 control_cfg -rw------- 1 bin sys 4637951 Oct 1 18:28 flist -rw------- 1 bin sys 8341 Oct 1 18:44 manifest -rw------- 1 bin sys 3467 Oct 1 18:44 recovery.log -rw------- 1 bin sys 5796 Oct 1 18:28 system_cfg root@hpeos004[recovery]
Interestingly, make_net_recovery has created an Ignite-UX INDEX file for this client:
root@hpeos004[hpeos003] pwd /var/opt/ignite/clients/hpeos003 root@hpeos004[hpeos003] cat CINDEX # CINDEX # 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 "2003-10-01,18:27 Recovery Archive" { description "Recovery Archive" "recovery/2003-10-01,18:27/system_cfg" "recovery/2003-10-01,18:27/control_cfg" "recovery/2003-10-01,18:27/archive_cfg" }=TRUE root@hpeos004[hpeos003]
Every time a new archive is created, a new entry in this file will be created and the new archive is made the default choice. By default, make_net_recovery will maintain the last two archives per client; we can modify this with the –n <num of archives> option to make_net_recovery. We can view these configurations with manage_index command as long as we specify the location of the CINDEX file:
root@hpeos004[hpeos003] manage_index –l -i /var/opt/ignite/clients/hpeos003/CINDEX
2003-10-01,18:27 Recovery Archive
root@hpeos004[hpeos003]
An interesting addition to this would be to include the mirroring of your root disk after the installation was complete. Although we may install the disk mirroring software, it would take additional work to ensure that the functionality was added to the client once the archive was installed. Here, I have added an entry to the CINDEX file for this client:
root@hpeos004[hpeos003] vi CINDEX
# CINDEX
# 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 "2003-10-01,18:27 Recovery Archive" {
description "Recovery Archive"
"recovery/2003-10-01,18:27/system_cfg"
"recovery/2003-10-01,18:27/control_cfg"
"recovery/2003-10-01,18:27/archive_cfg"
"recovery/2003-10-01,18:27/config.local"
}=TRUE
root@hpeos004[hpeos003]
I need to create the config.local file. This script will make use of the post_config_cmd variable, which is one way of performing additional tasks after the installation has completed. Here's my interpretation of this for my client hpeos003:
root@hpeos004[hpeos003] vi recovery/ 2003-10-01,18:27/config.local
#########################################################
######## Begin user changes to add disk mirroring. ########
post_config_cmd +="
# Recreate a mirror of the boot disk.
# Make sure the disk is removed from the group by using
# vgreduce. Alternatively you could edit the vg00
# definition to remove the references to this disk.
vgreduce /dev/vg00 /dev/dsk/c3t15d0
# Make the disk contain a boot area.
pvcreate -f -B /dev/rdsk/c3t15d0
# Add the mirrored disk back to the group.
vgextend /dev/vg00 /dev/dsk/c3t15d0
# Copy the boot area to the disk.
mkboot /dev/rdsk/c3t15d0
# Turn off the quorum requirement on both disks
mkboot -a "hpux -lq" /dev/rdsk/c3t15d0
mkboot -a "hpux -lq" /dev/rdsk/c1t15d0
# Allocate the mirrors. Mirrors must be allocated for all
# logical volumes that were previously mirrored. This
# example illustrates primary swap and root. You should
# add others as needed. If /stand is in a separate volume, you
# should do an lvextend for it first.
for x in 1 2 3 4 5 6 7 8
do
lvextend -m 1 /dev/vg00/lvol${x} /dev/dsk/c3t15d0
done
# Update the BDRA and the LABEL file.
lvlnboot -vR
"
######## End user changes to add disk mirroring. ########
#########################################################
root@hpeos004[hpeos003]
This script would need tuning for your own clients. I can check the syntax of this file with the instl_adm command.
root@hpeos004[hpeos003] instl_adm -T -f recovery/2003-10-01,18:27/config.local
root@hpeos004[hpeos003]
I could include such a script for all my Recovery Archives, if appropriate.
At this point, I am now a little concerned that we still have some options in the INSTALLFS file that could affect a Recovery Archive. In particular, I am concerned with setting the root password even on a Recovery Archive. At this point, I would be looking at taking that option out of the INSTALLFS file and placing it in specific configuration files where it is appropriate.
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 !( 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 -d > /tmp/instl_adm.out root@hpeos004[] root@hpeos004[] vi /tmp/instl_adm.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 timezone="GMT0BST" is_net_info_temporary=false _hp_keyboard="PS2_DIN_US_English" root@hpeos004[] root@hpeos004[] instl_adm -f /tmp/instl_adm.out root@hpeos004[]
Consequently, we can use these configuration clauses in a bootsys command if we want to install a client from this archive:
root@hpeos004[hpeos003] bootsys -f -a -i "2003-10-01,18:27 Recovery Archive" hpeos003 Rebooting hpeos003 now. root@hpeos004[hpeos003]
When the installation is complete, all the logical volumes in vg00 should be mirrored:
root@hpeos003[] lvlnboot -v
Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Group:
/dev/dsk/c1t15d0 (0/0/1/1.15.0) -- Boot Disk
/dev/dsk/c3t15d0 (0/0/2/1.15.0) -- Boot Disk
Boot: lvol1 on: /dev/dsk/c1t15d0
/dev/dsk/c3t15d0
Root: lvol3 on: /dev/dsk/c1t15d0
/dev/dsk/c3t15d0
Swap: lvol2 on: /dev/dsk/c1t15d0
/dev/dsk/c3t15d0
Dump: lvol2 on: /dev/dsk/c1t15d0, 0
root@hpeos003[]
This looks like it has been successful. I could perform a number of additional steps to check that the mirroring of all volumes in vg00 was completed successfully. You have to take my word for it that it worked perfectly well.
We have looked at a number of configuration possibilities with Ignite-UX. Please do not think that we have covered every possibility. There is significantly more that you can accomplish if you want to really customize a configuration for individual clients on your network. We hinted at some of the logic you can include in your configuration files. This logic is where we could spend countless time in tuning specific configurations for specific clients with specific hardware configurations. Have a look at man 4 instl_adm if you want to take this further, as well as some excellent documentation under /opt/ignite/share/doc. Obviously, you can download the online manual B2355-90767: Ignite-UX Administration Guide from http://docs.hp.com. Have fun!