Automated Installation of Large-Scale Linux Networks
One question that remained was where and how to place the ks.cfg file so that the target system was able to receive it even after it had undergone a DHCP/TFTP boot. An analysis of the installation procedure revealed that the tmp directory within the initial ramdisk is one of the locations that the Kickstart system looks for a configuration file.
The procedure of copying each ks.cfg to the appropriate location and then adding a kernel to initrd to make an encapsulated chunk of code was all performed by a script called superkick. A look at this script (see Listing 5) will show the steps involved in setting up the network bootable image.
We wrote another script, doitfor, to automatically customize the ks.cfg file and a post-install file for every workstation. It is shown in Listing 6. The major task that this script performed was inserting a specific host name and IP address within each ks.cfg using the streplace utility. This script takes as input the host name and IP address and generates a boot image to be uploaded using DHCP/TFTP boot.
To get the installation running, we needed to set up either a DHCPD server or a BOOTP server. The problem with the BOOTP method is that a list of network card MAC addresses has to be provided to issue IP addresses to the target machines. With a large number of installations, this would be quite a tedious job, so we opted for DHCPD. There is a long list of DHCPD options but we needed only the most basic ones, namely the default name-server address, starting IP and domain names.
Now the tricky issue here was that if we booted a machine an IP address would be issued to it. As long as it stayed on, the IP address would not be reused and any subsequent machine that was switched on would be automatically granted the next IP address by the DHCP d&\#230;mon. If the first machine was turned off, then its IP address became free. Since DHCP has the liberty to assign any unused IP addresses, there is a good chance that the same IP address would be given to another new machine. If an installation were then run, this new machine would end up with the same host name and IP address as the one that was turned off. Simply put, they would have the same network settings and would not work properly.
To solve this problem, we changed the first IP address that the DHCPD was allowed to offer. This was done by reconfiguring the /etc/dhcpd.conf file (see Listing 7) and restarting the DHCPD. The doitfor script includes the code to carry out this task every time a boot image for a new target is created. Once an IP address had been allotted, DHCPD could be switched to the next IP address and the next installation started without complications.
Once the DHCPD had been configured to offer the desired IP address for a target, we could proceed in two ways. The first was to burn the ROM image into an EPROM and plug the EPROM in to the network card. This obviously requires an EPROM programmer. The second and simpler way was to use the command
cat floppyload.bin <yourcard.rom> >>/dev/fd0
to create a bootable floppy disk carrying the ROM image and thus get the installation running. Some initial installations were carried out with the floppy method. Later, the availability of an EPROM writer allowed us to employ the EPROM technique, which worked fine and was good for experience and experimenting.
Note that completing more than two or three installations at a time overloads the network and brings down the efficiency. With two machines installing concurrently, we were able to achieve complete installations in an average time of fifteen minutes. The exact details of our installation procedure now follow.
First, we ran the shell script, doitfor, on the server to specify which machine we would be installing next. The floppy drive or the EPROM was plugged in to the target system and the system booted. The boot image was automatically retrieved, and the installation process started. While this process continued, we moved on to the next machine by running the doitfor script with new arguments corresponding to the next target. Booting the next machine would result in two installations running simultaneously. As soon as the installation on the first machine completed, we could start at the third one, and so on. The only hassle was plugging in the ROM/floppy and booting. Nevertheless, it was much faster than the standard method of using the floppy and manual settings.
If, on booting, the MAC address of the detected network card is reported as FF:FF:FF:FF:FF:FF, it is an indication that the network card is not initialized properly. There are two ways to overcome this. One is to switch off the Plug and Play OS feature of the motherboard during initial setup, forcing the BIOS to configure the network card. Note that switching this feature off is required only during the installation bootup; it can be switched on later, if required. The second method is to enable the -DCONFIG_PCI_DIRECT option in the configuration file of the etherboot as discussed earlier.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Sony Settles in Linux Battle
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Libarchive Security Flaw Discovered
- Profiles and RC Files
- Maru OS Brings Debian to Your Phone
- Understanding Ceph and Its Place in the Market
- Snappy Moves to New Platforms
- The Giant Zero, Part 0.x
- Git 2.9 Released
- Astronomy for KDE
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide