Automated Installation of Large-Scale Linux Networks
With files shared among a large number of workstations, it becomes imperative that machines have their clocks synchronized so that file time stamps are globally comparable. Time synchronization helps in maintaining logs, updating and distributing updates, etc. We simply set up all the machines to match their time to that of a reference server at every startup by utilizing the rdate utility. To enable this on the client side, we simply added the following line to the rc.local file:
On the server side, the default time service had to be enabled in the /etc/inetd.conf. This was done by locating and removing the # sign from the beginning of the following line and restarting inetd:
#time stream tcp nowait root internalFancy time-servers such as NTPD or TIMED could also have been used, but rdate works well for an undergraduate laboratory without causing headaches due to cryptic configuration issues.
Many volunteers helped with the installation. Once the installations were complete, security reasons demanded that we change the root password on every machine. This meant that either Linuxconf Web access was used for all the machines, or the system administrators had to manually change the password on each workstation. We wrote a script, change_password_on_all.pl (see Resources), to achieve this password change from a single server. The script requires that all workstations be configured to allow remote shell root access from the server using the rsh utility. This provision was configured during the post-install steps. It should be noted, however, that although this is not a very secure method of exchanging crucial information, it worked fine in our controlled laboratory environment. In addition, if caution is exercised by running the script only when the LAN is not being used, this method can prove to be very useful.
Now we move on to a discussion of how we automated the LAN startup and shutdown by controlling it from a single machine. To understand this we have to take a closer look at AMD's Magic Packet technology. Many network cards now come equipped with the Wake-on-LAN feature. This means that when the machine is switched off (i.e., the ATX casing has power but is not in the “on” state), it provides a small amount of power to the Wake-on-LAN enabled network card through a three-wire header connecting the motherboard and the card. Hence, the card is actually alive and able to keep watch on the LAN for a special packet, called the Magic Packet (see Resources). On receiving such a packet, the network card generates a pulse that can be used to switch on the machine. The Magic Packet is, in fact, a stream of 0xFF characters followed by the MAC address of the NIC, repeated a specific number of times. The probability of such a packet occurring coincidentally during normal operation is very rare. Hence, the reception of such a packet can be safely assumed to indicate that it is indeed meant for the target machine.
We wrote a Perl program named switch (see Listing 8) that switches one or all machines on the LAN either on or off. It generates a Magic Packet and broadcasts it over the network. The target machine, on receiving this packet, switches on. To switch a machine off, a straightforward remote shell invocation of halt or shutdown -h suffices. To make things more manageable, we made the script parse /etc/switch.conf for information regarding which host on the LAN has what MAC address. It should be obvious that the MAC addresses are required only for switching on and not off, as the shutdown invoked through the remote shell requires only target IP addresses.
A small drawback is that, although the switch-on is possible whether the target machine runs Linux or not, the switch off is possible only if the target machine properly boots into Linux. This method does not provide for switching the system off if the target machine fails to boot properly. It should, however, be noted that if a machine does fail to boot properly, it would require manual attention for fixing it anyway.
In our laboratory, we had Intel 440BX2 motherboards with D-link network cards that support the Wake-on-LAN feature. The motherboard requires that the feature be switched on from the BIOS. There is a large range of other component brands that support this feature as well. Chances are that if you have purchased your hardware in the last year, you already have these features.
Free DevOps eBooks, Videos, and more!
Regardless of where you are in your DevOps process, Linux Journal can help!
We offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, and advice & help from the expert sources like:
- Linux Journal
- Nmap—Not Just for Evil!
- Resurrecting the Armadillo
- High-Availability Storage with HA-LVM
- March 2015 Issue of Linux Journal: System Administration
- Real-Time Rogue Wireless Access Point Detection with the Raspberry Pi
- DNSMasq, the Pint-Sized Super Dæmon!
- Localhost DNS Cache
- Days Between Dates: the Counting
- The Usability of GNOME
- Linux for Astronomers