Author: Jerald Sheets
All the desktop users are Unix-savvy, and already had reason to have elevated privileges on our production systems (DBAs, applications administrators, etc.), so allowing users root access to their own machines was not an issue.
Since processing power on the part of the server isn’t paramount, I utilized a small Pentium II machine that used to be a documentation server. It had a 20GB hard drive and half a gig of RAM installed, which was more than enough for our purposes. I installed Red Hat 9.0 using the Server Installation, allowing the install routine to auto-partition the disk, and selected the services I might use. It was unnecessary to install any desktop niceties, as this machine would eventually be shelved and headless.
Once the installation of Red Hat was complete, I remounted CD 1 and copied the contents to my target. To make client configuration easier I chose /linux as the directory off docroot (on Red Hat Systems, Apache’s docroot is /var/www/html). I wanted to keep things just as they are on the CD to handle any unforeseen pitfalls, so I copied the contents, maintaining their on-CD permissions:
mount /dev/cdrom /mnt/cdrom
mkdir /var/www/html/linux
cp -rp /mnt/cdrom/* /var/www/html/linux/
I copied contents of the remaining two CDs to the directory as well.
You need to serve files to your client machine across the network. You can use the Apache Web server or you can share the codebase through FTP and NFS. Kickstart/Network Installations are aware of these other services and can easily adapt to whatever service you prefer. We are on a 100M network, and this particular group of machines is on the same switch, so performance wasn’t an issue. For our purposes, HTTP worked as well as any of the aforementioned services, was easy to set up, and was quick to deploy.
Red Hat uses the System V booting facility, and has provided a nifty set of utilities to enable and start the necessary services. Since we installed the Web server in our initial steps, we just need to enable the Web server and start it at boot time. As root, we ran the command:
/sbin/chkconfig --level 2345 httpd on
This tells the System V bootscript facility to enable Apache for runlevels 2, 3, 4, and 5 and start automatically. (Although it is not necessary to enable all those runlevels, I’ve made it a habit to do so unless I’m trying to tie down a service to a particular runlevel for a particular purpose.) Since we’re already booted there’s no reason to reboot, so we simply turn the Web server service on:
/sbin/service httpd start
You may see a gripe from Apache that there isn’t a hostname it can associate/lookup for your workstation, and that it’s using your loopback address as “Servername.” This is normal, and you can safely ignore the error. Now you’re ready to create boot images and install your system.
Creating boot media
You need to create boot diskettes or a CD to use to to boot client systems, configure their network interfaces, and select installation packages. There is a boot.iso image in the images directory. From the README:
This file is an ISO image that can be used to boot the Red Hat Linux installation program. It is a handy way to start network-based installations without having to use multiple diskettes. To use boot.iso, your computer must be able to boot from its CD-ROM drive, and its BIOS settings must be configured to do so. You must then burn boot.iso onto a recordable/rewriteable CD-ROM.
If having a boot CD instead of a floppy is an attractive option for you, burn the ISO as described above and skip the rest of this section, picking up the installation procedure at “Starting the network installation.”
The Red Hat CD comes with two directories that are essential to creating the diskettes you need. To view the essential directories in question, cd to /var/www/html/linux. The directory dosutils contains utilities that are necessary to create the diskettes from a Windows system. From a Linux machine you can use the dd utility. The directory images contains the disk images you need (based on your configuration) to load a minimum set of drivers and configuration information to access the network, and consequently your kickstart server.
The diskette images end with a .img suffix and are nearly self-explanatory in their filenames:
bootdisk.img – Primary boot disk image necessary for all install types
drvblock.img – Supplemental block device drivers
drvnet.img – Supplemental (and incidentally *necessary*) network drivers
pcmciadd.img – PCMCIA device drivers (network cards, etc.)
Generally speaking, if you are installing to a desktop system, bootdisk.img and drvnet.img should be sufficient, while a laptop install would most likely be best served utilizing bootdisk.img and pcmciadd.img.
Once you have selected the pertinent images, you are ready to create your diskettes. If you are on a Windows system you will want to copy the file rawrite.exe and the disk images you’ve chosen to your Windows machine from the CD. Once they are on your Windows machine, run rawrite.exe:
C:> rawrite.exe Enter disk image source file name: bootdisk.img Enter target diskette drive: a: Please insert a formatted diskette into drive A: and press --Enter-- : [ENTER]
Your session should look like the above for your bootdisk.img. Repeat the process for your disk image, using drvnet.img or pcmciadd.img as the file name. Label each diskette when you’re done.
If you are already on a linux desktop, you can use the dd utility to write the image you specify to the diskette:
dd if=bootdisk.img of=/dev/fd0
Starting the network installation
To begin the network installation, place the bootdisk.img diskette or boot CD into the proper drive and boot your system. (You need to make sure your system BIOS is set to boot from the drive of your choice.) You’ll get a standard Red Hat welcome screen and a Boot: prompt. At the prompt, request the askmethod boot type by typing:
Boot: linux askmethod [ENTER]
If you used diskettes, the system will boot to a point and request the additional driver disk. After you supply it you will be presented with the standard installation screens for a Red Hat Linux installation. When installing from the network, the text mode installer is all that is available, but you can still install the same configurations the GUI install affords you.
At this point, you (or your users) can proceed through the installation as one would normally proceed. Configure disk space, RAID, LVM, etc. Select software, configure time zone and system settings, and let the installation run. When it’s done the system will request a reboot. Remove your installation media from the disk drive and let the system reboot. You now have a working Red Hat Linux 9.0 system.
Providing continuing updates and services
As a service to my users, I keep an eye on the Red Hat errata, CERT advisories, and security announcements around the ‘net. I set up a directory parallel to $DOCROOT/linux called $DOCROOT/updates, in which I make directories to hold officially released Red Hat updates ($DOCROOT/updates/linux) and updates to resolve any security issues that may come along ($DOCROOT/updates/security). I also created an area with important (or desired) applications in $DOCROOT/apps. This way I can deploy common applications and be reasonably sure the entire team will be on the same release levels of software.
Since we are a hospital, we are held to a high standard of security and compliance by government regulation, and I need to be able to assure our security department we are in compliance. The easiest way to do this was to provide an intrusion detection facility and to teach the users to run the Lokkit program to lock down any services they don’t need. For the intrusion detection product I chose the tried-and-true portsentry. I had my users install the package, then delivered a portsentry.conf file that provided strong security with maximum notification so users would be notified in the event of a compromise attempt.
Finally, I send out a bi-weekly email with a “tip of the day” for Red Hat that helps the users get more acquainted with their systems as time goes on.
Future plans
I am currently building a kickstart file to clone my systems across the enterprise. The kickstart configuration deploys LVM and a custom set of packages and network configurations, and allows me to rapidly build servers and easily deploy a customized server where one didn’t exist. The kickstart facility utilizes a powerful configuration set, and is capable of duplicating most every configuration choice you can select during a standard hands-on installation.
Jerald Sheets is a senior Unix systems administrator for Our Lady of the Lake Regional Medical Center in Baton Rouge, Louisiana, where he is team lead for open source initiatives, Lawson Systems Administration, and DNS.
