KickStart is a script that drives a Red Hat installation. With KickStart, you answer all of the questions that the Red Hat installation asks, then package up those answers in a way that makes it easy to replicate Red Hat installs. KickStart does not support upgrades, installations other than Red Hat, or configuration files. SGI SystemImager is a disk cloning product. You install one machine with exactly the configuration you desire (for example, you can install Red Hat 6.2, then add the Propack 1.2, then ACE). Then you use SGI SystemImager's Prepare Image task to clone an image of the disk to the server machine. Next, you use the Create Boot Diskette task to create a boot diskette. You insert that disk into a cluster node and boot it. It boots up, contacts the server, and downloads the image onto its hard drive. When the client node is rebooted, it will look exactly like the original machine (minus specifically excluded directories like /tmp, /proc, and so on).
It can install and update patches, files, administrative changes (application, printers, hostname, networks, and so on) on all, selected, or single, nodes in the cluster. You make the changes to the master, then pull the image onto the server with the Prepare Image task. It copies only the changes to the server. Then you run the Synchronize Clients task to push over the new image to the selected clients. Once again, only changes are copied. No reboot is necessary unless you are copying a new kernel or other system files that would require a reboot to occur.
Yes. It uses the rsync program for this. For example, by default, when the client is resynchronized with the image from the server, all new and modified files are copied over, and any files that exist on the client but not in the image are deleted.
SGI SystemImager is not priced separately for individual sale. It is bundled with other products, which have their own pricing. VA SystemImager (the command line interface) is available freely as open source and available for download from the following web site: http://www.systemimager.org/
One advantage to using a separate server is that the server machine can hold multiple images, and might be the only machine that needs a lot of disk space. The server machine also acts as the Dynamic Host Configuration Protocol (DHCP) server. If the master were to act as the DHCP server, the clients, being exact copies of the master, would want to act as the DHCP server as well.
When SystemImager records the golden master's partition information, it also records the type of disk (for example, SCSI or IDE), and expects to find a disk of the same type and with the same name (for example, /dev/sda) on the clients. This means that you must match the types of disks installed on the master and clients.
SystemImager attempts to make the partitions on the clients match the partitions of the master. SystemImager records the partitions on the master in terms of sectors. The clients are partitioned to match. On some systems, partitions should begin only on cylinder boundaries, which do not necessarily correspond to sector boundaries if the geometries of the disks are different. SystemImager forces the partitions to be created exactly the same size as the master's, which works fine on many systems, but not necessarily on all systems. If it does not, you should contact your customer services representative for assistance.
If the master crashes, the performance of the rest of the cluster is unaffected. The server can continue serving out the images as it did before. Only when a new image needs to be created or an existing image needs to be updated would you need to create a new master. Because the master and all of the clients are identical, you can promote a client to a master by renaming the client as the master.
If the server machine crashes, the machines already running in the cluster will be unaffected. However, no synchronizations will be possible. Also, when a client machine reboots, it will be unable to obtain an IP address from the server and will likely fail to restart correctly.
After an image is copied to the server, the next step is to prepare a boot diskette that can boot the clients. The clients need to connect via the network to retrieve the image, and to do this, an IP address is required. The boot diskette that is created is generic -- the same one works for all clients -- and therefore, does not contain a hardcoded IP address. Therefore, the client uses DHCP to contact the server and obtain its name and IP address.
No. While SystemImager does not currently support investigative capabilities such as performing a “diff” with the golden master image, you could accomplish these capabilities with very little effort by issuing a single rsync command from the client (use the -n argument).
Yes. The server can hold as many images as the disk can hold. However, when a client is booted from a diskette, it synchronizes itself with the default image, and there is only one default image at a time. If you want to specify compute nodes and I/O nodes, for example, you would have to set the default image to be the compute nodes image, then boot the compute nodes with the boot diskette, then set the default to be the IP image and boot the I/O images. When resynchronizing via the SGI SystemImager, if you boot over the network, you can specify the image to use.
On the server, rename the file /var/lib/sysadm/sysadmd.conf.example to /var/lib/sysadm/sysadmd.conf.
Edit /var/lib/sysadm/sysadmd.conf, as follows: Uncomment the logFile: and logFile.filter lines. Set logFile: to /tmp/sysadmd-log (or similar).
Restart (or start) SGI SystemImager on the console.
To view log messages from SGI SystemImager on the console machine, do the following:
On the console machine, edit the /usr/bin/simgr file. Replace /usr/jre118/bin/jre with /usr/jre118/bin/jre -DLog.debugLevel=ALL