Ignite-UX Frequently Asked Questions

disks and volume groups.
===============================================================================
11.5
Q: How can I use make_net_recovery if I need to be able to recover from a tape?
A: There are two ways you can recover from a tape with
make_net_recovery. The following method that you choose depends on
your needs:
- The first method is useful when you want to create a totally
self-contained recovery tape. The tape will be bootable and
contain everything needed to recover your client, including the
archive of your client. During recovery, no access to an Ignite-UX
server is needed.
- The second method is useful when you do not have the ability to
boot the client using the network, but are still able to access the
Ignite-UX server using the network for your archive and
configuration data. This could happen if your client does not
support network boot or if is is not on the same subnet as the
Ignite-UX server. In these cases, use make_boot_tape to create a
bootable tape with just enough information to boot and connect with
the Ignite-UX server. The configuration files and archive are then
retrieved from the Ignite-UX server. For more information, refer
to make_boot_tape(1M).
===============================================================================
11.6
Q: Which files does Ignite-UX change during an installation from a
make_net_recovery configuration?
A: During a client recovery, Ignite-UX strives to restore the client
back to the way it was. However, Ignite-UX is a general purpose
installation tool and as such it has the capabilities of modifying
many client configuration files.
When you run make_net_recovery, client configuration information is
gathered and saved in configuration files that are used later when
the client is recovered. During the client recovery you are allowed
to make changes to this information, then Ignite-UX makes the
appropriate changes to the client configuration. If you do not make
any changes, then Ignite-UX simply reapplies the last installation
information and makes no changes to the client's configuration.
Most of the client configuration files that Ignite-UX modifies are
listed in the script: /opt/ignite/data/scripts/os_arch_post_l.
The os_arch_post_l script checks for the client recovery case by
checking the $RECOVERY_MODE variable. When this variable is true,
the os_arch_post_l script causes some configuration files to be
protected from modification by using the /save_file/ function. The
os_arch_post_l script uses the merge_file function on files into
which Ignite-UX knows how to intelligently merge information.
The files operated on by merge_file, as well as those that have a
commented out "save_file" line are those that are likely to be
modified by Ignite-UX. Comments in this file explain any exceptions.
Because the list of files modified by Ignite-UX may change from
release-to-release, it is best to look at the os_arch_post_l script
on the client to see which files are saved as-is and which are merged
with information from the Ignite-UX configuration files.
===============================================================================
11.7
Q: How can I keep archives from being deleted by make_net_recovery when
new archives and configurations are created by subsequent invocations
of make_net_recovery?
A: You may want to prevent known good archives from being deleted from
your client. The make_net_recovery tool provides the -n option,
which allows you to specify the number of archives to save. To
preserve disk space, the oldest archives are removed as new archives
are created. The number of archives that are removed is based on the
number of archives you specified to be saved using the
make_net_recovery -n. One way to ensure that known good archives are
saved is to specify the number of archives to save to be greater than
the maximum number of archives you plan to store on the client at any
given time. This method has the potential to use a great deal of
disk space.