Pull files out of a Ignite-UX recovery archive

Perhaps you have a regular backup utilizing make_net_recovery, and want to get some files out of it. How is this done? The standard way to utilize a Ignite-UX backup is to restore the machine completely, using Ignite-UX.

However, if just one file – or a series of files – is desired, log into the Ignite server. Change to the directory /var/opt/ignite/recovery/archives and then into the directory matching the host you want to restore files to. The files in these directories are gzipped archives of the sort that you specified when you did the make_net_recovery (tar files by default). The file names are of the format YYYY-MM-DD,HH:MM.

Use your favorite tools to extract the files from the desired archive. For example, the following will extract the /stand directory (where HP-UX keeps its kernels):

gunzip -c 2009-01-24,07:05 | tar xvf - stand

The actual configuration of the archive process is kept in a different directory in /var/opt/ignite/clients followed by the host name. Most of these files should not be changed, as it would be easy to mangle the backup (or restore) process by making a bad change to one of these files.

Updating Ignite-UX on HP-UX

Every major UNIX operating system has its own method of automated installs; HP-UX uses Ignite-UX. However, “updating” Ignite-UX is a misnomer and not recommended.

The recommended method is to remove Ignite-UX first. Find the names, then remove the installed software:

# swlist -l product | grep -i ignite
Ignite-UX C.7.7.93 HP-UX System Installation Services
# swremove Ignite-UX

After removing the software (which does not remove the installed repositories), then install the updated version with swinstall.

After the software is installed, it must be configured, if it isn’t already:

# /opt/ignite/bin/make_config -s /var/opt/ignite/depots/Rel_B.11.31/core_media -c /var/opt/ignite/data/Rel_B.11.31/core_media_cfg
# /opt/ignite/bin/manage_index -a -f /var/opt/ignite/data/Rel_B.11.31/core_media_cfg -c "B.11.31 From OE Media"
# /opt/ignite/bin/manage_index -n "HP-UX B.11.31 Default" -c "B.11.31 From OE Media"

You could make this configuration the default:

# /opt/ignite/bin/manage_index -e -c "B.11.31 From OE Media"

Or you could list configurations:

# /opt/ignite/bin/manage_index -l

See manage_index(1m) for more information on manipulating Ignite-UX configurations.

Automation: Live and Breathe It!

Automation should be second nature to a system administrator. I have a maxim that I try to live by: “If I can tell someone how to do it, I can tell a computer how to do it.” I put this into practice by automating everything I can.

Why is this so important? If you craft every machine by hand, then you wind up with a number of problems (or possible problems):

• Each machine is independently configured, and each machine is different. No two machines will be alike – which means instead of one machine replicated one hundred times, you’ll have one hundred different machines.
• Problems that exist on a machine may or may not exist on another – and may or may not get fixed when found. If machine alpha has a problem, how do you know that machine beta or machine charlie don’t have the same problem? How do you know the problem is fixed on all machines? You don’t.
• How do you know all required software is present? You don’t. It might be present on machine alpha, but not machine delta.
• How do you know all software is up to date and at the same revision? You don’t. If machine alpha and machine delta both have a particular software, maybe it is the same one and maybe not.
• How do you know if you’ve configured two machines in the same way? Maybe you missed a particular configuration requirement – which will only show up later as a problem or service outage.
• If you have to recover any given machine, how do you know it will be recovered to the same configuration? Often, the configuration may or may not be backed up – so then it has to be recreated. Are the same packages installed? The same set of software? The same patches?

To avoid these problems and more, automation should be a part of every system wherever possible. Automate the configuration – setup – reconfiguration – backups – and so forth. Don’t miss anything – and if you did, add the automation as soon as you know about it.

Things like Perl, TCL, Lua, and Ruby are all good for this.

Other tools that help tremendously in this area are automatic installation tools: Red Hat Kickstart (as well as Spacewalk), Solaris Jumpstart, HP’s Ignite-UX, and OpenSUSE Autoyast. These systems can, if configured properly, automatically install a machine unattended.

When combined with a tool like cfengine or puppet, these automatic installations can be nearly complete – from turning the system on for the very first time to full operation without operator intervention. This automated install not only improves reliability, but can free up hours of your time.