5.7. Too Many Computers on Which to Install Linux
As a Linux geek, you have to be ready in case the people you're working with want to install Linux on a substantial number of computers. And it would be supremely annoying to be up all night running installation programs on each individual computer. There are four sensible steps that you should take before installing Linux on a large number of computers:
Different Linux distributions include tools that can help. Red Hat has Kickstart. SUSE has AutoYaST. Debian uses the Fully Automatic Installation (FAI) tools. While some of these tools can work with bootable network cards, you may not be lucky enough to have them in your environment.
With these tools, you can automate the installation of Linux on other computers. If you have 100 identically configured computers and a DHCP server on a network, you can set up a single installation process that works automatically for those computers. Test your favorite Linux on one computer, configure it to your needs, and replicate this process on other computers. Yes, you could use disk mirror tools as well, but that requires you to physically move the disks, etc. If there is a hardware defect on one of the 100 systems, you may not know it until you get a user complaint.
As a Linux geek, you may already be familiar with Progeny Linux (http://www.progeny.com). Ian Murdock (one of Debian's founders) created Progeny to bring Linux, and primarily Debian Linux, to more people. Progeny uses open source tools; they're in the process of porting Red Hat's Anaconda and Kickstart tools. Thus, in this section, we'll limit our solution to the basic procedures for Kickstart and AutoYaST.
Kickstart is still a work in progress for Progeny Debian as of this writing. Progeny has announced that Kickstart will be a part of its next release. It is consistent with Progeny's decision to adapt Anaconda as the primary installation program. Hopefully Kickstart for Debian will be ready by the time you read this book, possibly for the Debian-based enterprise distribution. (Ubuntu already uses Kickstart.) Alternatively, you might consider SystemImager (http://www.systemimager.org) or the aforementioned FAI (http://www.informatik.uni-koeln.de/fai/).
5.7.1. Configuring Kickstart
Kickstart is a straightforward tool. If your test computer is perfect and does not need tweaking, you can almost take your original Red Hat (or Debian) configuration Kickstart file, add it to a boot disk, and install away on the computers of your choice. When you install a Red Hat distribution on a computer, it includes the current configuration in /root/anaconda-ks.cfg . We'll take a brief look at my version of this file, with things you may need to modify for your situation. Here are the first few commands:
install nfs --server=server.example.com --dir=/mnt/fedora lang en_US.UTF-8 langsupport --default=en_US.UTF-8 en_US.UTF-8 keyboard us
The second command, which specifies a network installation, is critical. NFS has the advantage over FTP and HTTP; besides being most efficient, you can copy the Red Hat installation CDs to the directory that you're sharing over the network as .iso files. Alternatively, if you use cdrom on this line, you'll need installation CDs for each computer.
xconfig --card "Intel 810" --videoram 16384 --hsync 31.5-37.9 --vsync 50-70 --resolution 800x600 --depth 24 --startxonboot --defaultdesktop gnome network --device eth0 --bootproto dhcp --hostname Fedora3 rootpw --iscrypted $1$2l6AeSZr$54N4e4kuMQFYiZnuxDdxw0
The xconfig command appears on two lines in this book because it's long. It specifies an automatic boot into the GUI by setting the id variable in /etc/inittab to runlevel 5. The network command could be annoying; it sets up Fedora3 as the hostname of every computer. You could leave out the --hostname Fedora3 option if your DHCP server assigns hostnames. The rootpw command can carry an encrypted password, which you can copy from /etc/shadow, assuming you've configured the shadow password suite on your computer. For more information on how you can use the shadow password suite, see the "Too Many Tasks, Too Few Qualified Administrators" annoyance in Chapter 10.
firewall --disabled authconfig --enableshadow --enablemd5 timezone America/Los_Angeles bootloader --location=mbr --append="rhgb quiet"
Most administrators disable a firewall on a computer within a LAN. In any case, a computer that serves as a firewall should get special attention and not be configured using Kickstart. The authconfig command enables the shadow password suite, with MD5 encryption. The computers on your network are probably all in the same time zone. Unless you have another bootloader, the MBR is the best place for it. Red Hat now appends the rhgb quiet command to the kernel; regular users might be confused by standard kernel messages. This configuration is for systems with SCSI disks; the sda name below is the standard name for the first SCSI drive.
#clearpart --linux --drives=sda #part /boot --fstype "ext3" --size=100 --ondisk=sda #part pv.8 --size=0 --grow --ondisk=sda #volgroup VolGroup00 pv.8 #logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=5024 #logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=256 --grow --maxsize=512
You can't use this file to automate installation until you activate the preceding commands. This particular set of commands configures a standard ext3 partition for the /boot directory, with logical volumes and given sizes for the root directory (/) and swap partitions.
%packages @ office ... @ graphical-internet kernel e2fsprogs grub lvm2
The package selection list is straightforward; I've abbreviated it to save space. In the preceding lines, I see the Office and Graphical Internet package groups, which are defined in Red Hat's comps.xml file. Red Hat organizes its RPM packages in groups in a file named comps.xml, in the first installation CD's /Package/base subdirectory, where Package is Fedora or RedHat. As the file's name suggests, it's in XML format. During the installation process, Red Hat's Anaconda installer presents these package groups to the administrator so you can choose which you want to install.
For example, here is an excerpt from comps.xml for Red Hat Enterprise Linux 3. A number of intermediate XML comments and commands have been omitted for brevity. As you can see, Red Hat's Office group includes several packages over and above openoffice.org:
<group> <id>office</id> <name>Office/Productivity</name> ...... <grouplist> <groupreq>base-x</groupreq> </grouplist> <packagelist> <packagereq type="default">openoffice.org</packagereq> <packagereq type="default">xpdf</packagereq> <packagereq type="default">ggv</packagereq> <packagereq type="default">mrproject</packagereq> <packagereq type="optional">kdepim</packagereq> <packagereq type="optional">kdegraphics</packagereq> <packagereq type="default">tetex-xdvi</packagereq> </packagelist> </group>
We also see the kernel, e2fsprogs, grub, and lvm2 packages listed separately because they are not a default part of any Red Hat package group.
If you've added software while testing your Linux system, you'll need to add that information to this list. Red Hat also provides a GUI configuration tool for ks.cfg: system-config-kickstart or redhat-config-kickstart.
Once you've configured the Kickstart file with desired settings, save it to ks.cfg. Next, you'll want to copy this file to a shared directory. You can use the same shared directory that the installation files are in.
Now you can test the result on a new computer, with the following steps:
Similar options are possible from ks.cfg files on a floppy disk or embedded on the CD.
Note the %post tag at the bottom of the Kickstart configuration file. You can add commands to further configure servers. For example, you might use it to copy key configuration files, such as for Samba servers.
5.7.2. SUSE AutoYaST
SUSE also has a tool for automated installations called AutoYaST. It's available through YaST2, SUSE's Yet another Setup Tool. You can start it from the command line with the /sbin/yast2 autoyast command, or by selecting "autoinstallation" from the miscellaneous options in the graphical YAST tool. Unless you're familiar with SUSE's XML tags, I recommend that you use AutoYaST to configure the autoinstallation file.
If you don't see the AutoYaST module, you probably need to install the associated RPMs: yast2-trans-autoinst, yast2-config-autoinst, and yast2-module-autoinst.
As with Kickstart on Red Hat, you can configure a reference profile based on the local computer. To do so, open YaST. Navigate to the Misc menu, where you can start the Autoinstallation tool. Then click Tools Create Reference Profile. It opens the Create a Reference Control File menu shown in Figure 5-3. Select the services that you need, and the appropriate settings will be copied to the Reference Control File.
Figure 5-3. Creating a SUSE Autoinstallation file
Once created, you can modify the Reference Control File or save it via the File menu.
22.214.171.124. Setting up AutoYaST installation media
To set up your AutoYaST installation media, you'll need to make sure that you copy all of the CDs to the installation server. To make sure the client sees the server as a single installation source, run the following Perl command, where inst is the directory with the SUSE installation files:
perl -pi -e 's/InstPath: \t\d+/InstPath: \t01/' /inst/suse/setup/descr/common.pkd
Now you can share the /inst directory. NFS is usually best for this purpose. Then, to configure a network installation, copy the autoyast.xml file to the boot media. To make sure the client looks at the installation server, configure an info file. You can include this information within the <init> tags, with an <info_file> tag:
<init> <info_file> install: nfs://192.168.0.1/inst/suse netdevice: eth0 server: 192.168.0.1 serverdir: /inst/suse autoyast: 192.168.0.1/inst/autoinst.xml </info_file> </init>
Then when you boot the SUSE installation program, enter the following command, where autoyast.xml is on the shared NFS directory from server.example.com: