Golden Plated Image
Last month we created the "Golden Image" host. In this episode we'llcreate the archive file from that </b>golden image host.
This archive file is what actually gets expanded onto the disk(s) of hosts that willhave software loaded using Ignite/UX. Before we look at the commands involved, there aresome details to discuss about what should go into the image.
IMAGE IS EVERYTHING
Previously, we said to load everything you want on a host, then perform anyconfigurations you want propagated to all target hosts that will use this image. In moredetail, this can be as simple as throwing some locally used programs into /usr/local/bin,but there is generally much more to it than that.
To begin with, when installing the operating system manually, most of us just selectand load everything, since it is so much trouble to de-select unused components only tofind out that you've saved just 15MB in load size. Well, in the case of the golden imagehost, this time will not have to be spent again and will save that 15MB from beingtransferred over the network every time you ignite a host. It also might mean that certainpatches don't have to be loaded because they are only needed by a certain language, orbundle.
You should also be sure that the filesystem is setup as you want it, including LVMlayout and sizes. This information can be propagated to other hosts at ignition time. Youcan also override, or dynamically configure this layout, while still using the samearchive image.
As for configuring the host, you will have control over which files go into the archiveand which will be "cleared" of host specific information. For example, if allhosts in your network need to be NFS servers, you should configure the golden image hostthat way. If you want certain menus and actions in CDE, configure it. You should burn arather serious amount of brain time deciding what goes into the golden image.
Of course you can always test the image, then go back and edit the golden image hostand make another archive file. Creating the archive file usually ends up not harming theimage host, although it could corrupt the OS. But, so far this has not happened to me.
If there are applications that you want loaded on all hosts using this image, load themon the image host. One issue though, is to be aware of client specific files. Someapplications create files that contain some identity of the host on which they're loaded.You'll need to fix that after the load with a script. Luckily, Ignite/UX allows us toinsert scripts to be run at various times.
SEPARATE ROOTS
Another option is to make separate image files for applications. You can do this bymaking a "root image tree," then installing the application to that directory asthe target. You would then make an archive from the root image directory.
The command that creates an archive file is make_sys_image. Actually a shell script, itlives in /opt/ignite/data/scripts. This is a good design, because very few people will beusing it without some editing.
You're supposed to edit this script before use, so make a copy of it, then startreading. Typically, the copy is moved into a root level directory on the image host.
When building the archive, this script will remove client identity and host specificconfigurations from many files. You might not agree with which files this should happento, thus the need for editing. For example, if you use NIS in your network, you might wantthe /etc/passwd and /etc/group files to be copied into the archive as is (with the + linestill in the files).
The script also contains a list of files that are not included in the image, such asNFS automounter files resolv.conf and exports. If you use the same files on all hosts,comment out the lines that exclude those files.
You can also add directories or files that are not to be included in the image, such astemporary directories you use to take notes, or copy the script to, or even applicationsloaded that you don't want propagated. This means that the image host does not really needto be dedicated to the purpose, but it makes it cleaner to start with a nice, crispy, newsoftware load.
It's possible that the script will cause some harm to the host. This is due to the factthat it copies many files around and does quite a bit of file editing. Because of this,you really should try to get everything right the first time.
To help, the first time you run make_sys_image you should do it with the -xv options,or preview mode. It will point out any problems and document what will happen when run forreal.
READY, SET, GNUZIP
When you're ready, creating the actual archive file is easy, because most of the workwas in configuring the host and editing the script. You need to make a couple of choicesas to the type of archive. This is controlled with options. The default is a pax GNUzipfile, which is what most people use.
If you want a tar file, use -m. To use compress instead of gzip, use -c. Note that someolder versions of Ignite/UX needed patches before the pax archives would work.
If you're short on disk space or don't want to move a 200MB file later, use the -soption to specify on which host to save the archive file. Most people create it directlyinto the proper version directory under /var/opt/ignite/archives. A version directory isnamed in the manner of Rel_ followed by the output of uname -r. This is the recommendedlocation.
The -n option allows you to name the archive file. By default it will be named the sameas the image hostname, with an appropriate extension (.gz). If you use this option, besure to include the extension in the supplied argument.
The next step towards a total hands-off software load is to build some Igniteconfiguration files that tell Ignite how to use the archive. We'll look into theseconfiguration files in the next column of the series.
You can save yourself lots of time building the config files by letting Ignite do someof the work. The command save_config, when run on a host, builds a configuration file thatdescribes the disk and filesystyem layout on the host. It also saves some networkinformation.
What I'm getting at, is that you should run this command on the image host to save acopy of the layout used, because it might be exactly what you want on other hosts, or itcan be a good starting point.
HOSTING UNIFORMITY
Some administrators are lucky because they're in a uniform environment. This means allhosts in the network are to be configured similarly, so they can use the same operatingsystem load and even the same application loads, if any. If you're in a data-less clientsituation this is probably true -- especially so if you're using application servers, orhave all applications NFS mounted. Other networks have different requirements about whatsoftware is loaded on each machine or have several configurations.
You might need to configure another disk or image host so that you can create archiveswith different information in them or different applications. Remember that you can usemultiple archive files, so if only the application set is different, you might considerhaving one OS archive and a few application archives. Which one is loaded can bedetermined at ignition time.
Many configuration issues can be controlled by the Ignite config files, so before yougo building lots of archives, wait until we dive into writing configuration files.
--Fred's looking for an agent to help improve his image!