|
|
|
|
|
|
|
|
Configuring Linux as a dual-purpose user environment.
by R. Scott Gray, Luke Pargiter and Phil Pfeiffer
In an era of decreasing budgets and increasing costs, it is sometimes impossible to follow standard wisdom and use distinct computer systems to achieve different goals. The East Tennessee State University (ETSU) Department of Computer and Information Sciences confronted this problem in spring 1997, when course requirements suggested the need for two computer laboratories:
Pargiter's strategy for supporting a dual-purpose laboratory partitioned the available computers into one trusted PC and a set of client PCs. The trusted PC, known as the kernel server PC, acted as a secure file server for the network as a whole. The client PCs were set aside for user development. Users were directed to use only client PCs, and to boot these PCs according to how they intended to use the systems:
Configuring the six-station network posed two key challenges. The first one stemmed from the need to use surplus PCs with Micro Channel Architecture (MCA) buses--a type of bus the standard Linux 2.0 kernel does not support. The MCA problem was solved by using Chris Beauregard's MCA kernel patch from the Micro Channel Linux home page.
A second configuration-related challenge arose from the need to conserve disk space on the kernel server PC. Configuring the kernel server PC as a trusted server would help ensure the integrity of the kernel server's file system in the face of random kernel changes applied to satellite PCs. The server, however, would then be required to host one copy of the Linux operating system for every networked PC, leaving little room for user home directories.
The Linux kernel ``disk bloat'' problem was solved by observing that most of the files in the Linux distribution could be stored once on the server and shared among multiple PCs. This set of shared kernel files included system-independent files like /etc/passwd, which remain constant across the configuration, and satellite-independent files like /etc/exports that need to be configured only twice: once for the kernel server and once for all client PCs.
Since Linux distributions are not ordinarily partitioned into system-dependent and system-independent files, system-dependent configuration files were moved to a new directory, /adm. Most of the relocated files were originally stored in /etc. For each file moved to /adm, a corresponding soft link pointing to that file was created in each client's /etc directory. Trial and error was used to determine whether a configuration file could be moved to /adm.
The principal goal of the mass storage device configuration was to provide adequate disk space for system executables and files, while reserving the greater portion of disk space for user files. Initially, three mass storage devices were found on the kernel server: a CD-ROM, a 320MB hard drive and a 545MB hard drive.
The 320MB hard drive was configured as the default boot drive /dev/sda. This drive was partitioned into a 50MB swap partition, /dev/sda1, and a second partition, /dev/sda2, for the server's root file system. The first 80MB of the 545MB hard drive, /dev/sdb1, were reserved to house the client's operating system images, /tftpboot/Client_IP_Address, and the directory containing shared operating systems file, /tfpboot/adm. The remainder of the drive, /dev/sdb2, was set aside for the server's /usr/local directory. In retrospect, it would have been better to have partitioned /dev/sda into three logical disks, reserving the third partition for temporary files such as those found in the /var directory since the demand for temporary file space changes in response to a system's tasks.
The CD-ROM drive was included in the server's initial hardware configuration to simplify and speed up the Linux installation. One of the last configuration steps was to replace the CD-ROM with a 320MB hard drive. This third hard drive, /dev/sdc, was initialized with one partition, /dev/sdc1, intended for user home directories, /home. The CD-ROM was then placed on a client system, lin2, and exported to allow other clients and the server to utilize the device.
The MCA Slackware 3.1 installation boot floppy was used to initiate the server's installation. Basic Slackware 3.1 installation instructions were followed. The standard Linux 2.0 kernel series does not provide support for the MCA bus architecture; therefore, the kernel image residing on the MCA Slackware 3.1 installation floppy was installed on the new system. Upon completion of the Linux installation, the system was booted and the MCA Linux kernel patch applied to the kernel source code. The modified kernel source was then configured, compiled and installed. Finally, the server was rebooted to load the new kernel image.
The basic network setup was configured during the Slackware 3.1 installation as with any standard Linux system. At the time, the Linux 2.0 kernel series did not support token-ring adapters. However, token-ring adapter support was provided via the MCA kernel patch. During the kernel configuration process, the following networking support and network device support options were selected:
A non-standard shell script, rarptab, was created and placed in the /etc directory. This script initialized the RARP (reverse address resolution protocol) table with mappings from 48-bit MAC (mandatory access control) addresses to IP addresses. The script compensated for the Slackware RARP's failure to respond to clients named in standard Linux initialization scripts. The rarptab script consists of a single command for each client of the form
rarp -a Client_IP_Address Client_MAC_AddressThe rarptab script was invoked at system boot from /etc/rc.local, using the command
sh -c /etc/rarptabThe server's /etc/exports file was modified to give client PCs access to the following directories:
Shared Directory Client Hostname \ (rw, no_root_squash) Shared (ro, no_root_squash)The no_root_squash option specified above is important for diskless operation. This option allows a client's SETUID programs to gain access to root-only accessible system files.
The tftp entry in the file /etc/inetd.conf was uncommented and the following line inserted in the file ``/etc/services'':
tftp 68/tcp #TFTP server
A directory, /tftpboot/Client_IP_Address, was created on the server to house the files for a single client system. A soft link, lin2, pointing to the Client_IP_Address directory, was created in /tftpboot for convenience. The /tftpboot/adm directory was then created to hold cross-system configuration files. Slackware's installation routine setup was invoked, and /tftpboot/lin2 specified when prompted for an installation target. Only packages from Section A (base Linux) and Section N (networking) were selected. During the configuration of the client's system files, redundant packages from Sections A and N were removed with ease. The setup routine option for installing the Linux kernel was refused, since kernels, by design, are loaded from specially prepared boot floppies. The setup option to run LILO was also refused.
The file /etc/fstab is used to determine which file systems are to be mounted at system boot. Remote clients on the LBLC share the common fstab file shown in Listing 1.
Sharable system files residing in /tftpboot/lin2/etc were removed, and soft links made to their counterparts in the /tftpboot/adm directory. The file /tftpboot/lin2/rc.inet1 was edited to ensure initialization of the token-ring interface (tr0). All file system integrity checks were then removed from /tftpboot/lin/2etc/rc.d/rc.S. The server must ensure file system integrity, since the fsck utility cannot be used by the client PCs to check file system integrity at system boot; at the time such a check would occur, the file systems have already been mounted.
Selected directories in which the contents were to reside only on the server (NFS mounted) were removed from /tftpboot/Client_IP_Address, using the following commands:
rm -rf /tftpboot/linwin2/var/X11R6/* rm -rf /tftpboot/linwin2/user/* rm -rf /tftpboot/linwin2/root/*As discussed earlier, only a limited Linux installation was placed in /tftpboot/lin2; therefore, the following directories were created to serve as mount points to allow lin2 to import these directories from the server:
/cdrom lin1(rw,no_root_squash) /cdrom lin3(rw,no_root_squash) /cdrom lin4(rw,no_root_squash) /cdrom lin5(rw,no_root_squash)The chmod -R +r /tftpboot/lin2 command was used to make all files in the lin2 directory tree readable by tftp, a protocol that, essentially, can access only world-readable files. The configuration for lin2 was then used to configure lin3 through lin5. A duplicate of the lin2 configuration was created for each of the remaining clients with the commands:
mkdir /tftpboot/Client_IP_Address ln -s /tftpboot/Client_IP_Address\ /tftpboot/"lin3 through lin5" cp -Rpd /tftpboot/lin2\ /tftpboot/"lin3 through lin5"A few of the system configuration files were then modified to make these files specific to their target hosts. The most notable changes involved modifications to /tftpboot/Client_IP_Address/etc/rc.d/rc.inet1. Specifically, two lines in the rc.inet1 file were modified to reflect the remote system's IP address and gateway:
IPADDR="Client_IP_Address" GATEWAY="Client_IP_Address"Additionally, the file /tftpboot/Client_IP_Hostname/etc/HOSTNAME was modified to reflect each remote system's correct host name. Finally, the file /etc/exports was modified such that the /cdrom directory was no longer exported.
A two-step procedure was used to generate remote bootstrap floppy disks for client machines. First, the kernel source residing on the server was recompiled to include ``root file system on NFS (Network File System)'' support. Once compilation was complete, the newly created kernel image was moved from /usr/src/linux/arch/i386/boot/zImage to /tftpboot/adm/client_boot_image_remote. A new disk was labeled and inserted in the server's floppy drive. A dummy device, /dev/boot22, was created with the mknod utility. The dd utility was used to copy client_boot_image_remote to the floppy disk. The rdev utility was then used to set the root device for the kernel residing on the floppy image to the dummy device /dev/boot22. The following sequence of commands was used to create the remote bootstrap floppy disk:
mknod /dev/boot255 c 0 255 dd if=/adm/client_boot_image_remote/zImage of=/dev/fd0 rdev /dev/fd0 /dev/boot255Finally, this procedure was captured in a shell script and used to create additional remote bootstrap floppy disks.
All client systems included a hard disk configured to provide a single 50MB swap partition, /dev/sda1. This would allow experimental users to partition the remainder of the drive to suit their needs when installing Linux on their systems. Because the only CD-ROM resides on lin2, any installation of Linux to a client system other than lin2 has to be done via NFS. To make such an installation possible, modifications to the MCA Slackware 3.1 boot floppy were necessary. The boot floppy was mounted under the /mnt directory using the command
mount -t minix /dev/fd0 /mntThe file /mnt/etc/networks was updated, changing LOCALNET to IP address 151.141.99.0. The MCA Slackware 3.1 boot floppy assumes that if a network installation is being conducted, the network is of type Ethernet. Therefore, it was necessary to edit the file /mnt/usr/lib/set/INSNFS, changing all occurrences of eth0 to tr0. As with the remote bootstrap floppy, a script was written to automate the above operations.
The declining cost of disk drives, together with concerns about system security, have made diskless workstation operation and remote protocols like RARP less attractive. ``Relatively inexpensive'', however, is still not quite ``free''. We described a strategy for implementing a Linux-based laboratory that, in effect, uses diskless operation to support regular as well as standard users, at no additional cost.
ETSU's Linux-based computer lab has not been fully integrated into the ETSU curriculum, due primarily to unforeseen delays including equipment outages caused by a thunderstorm. The lab, however, is operational. Two students used the lab in spring 1998 to develop a serial line driver for a senior-level operating systems course. Currently, plans are being made to use the laboratory as a tool for teaching graduate operating systems and undergraduate networking courses in the coming academic year.
Scott Gray (sgray@eolian.com) is the Senior System Designer for Eolian Inc. (www.eolian.com), where he is currently working on Internet caching proxy server development. Scott is also completing a master's thesis at East Tennessee State University on disk caching and adaptive block rearrangement. He and his cat, Sheba, regularly commute between their home in Church Hill, Tennessee and Eolian's office in Fairfax, Virginia.
Luke Pargiter is currently the Network Operations Supervisor at Pilot Corporation, a $2 billion privately owned petroleum retailer and travel center operator. He was formerly the Systems Manager for the Dept. of Computer and Information Sciences at East Tennessee State University. In his spare time, he reads, plays golf and guitar, and takes long walks with his wife, Rose. Luke can be reached via e-mail at pargitel@pilotcorp.com.
Phil Pfeiffer, assistant professor of computer and information science, currently teaches at East Tennessee State University (www.etsu-cs.edu). Phil, who earned his Ph.D. in computer science from UW-Madison in 1991, is currently working on his cave diving certifications. He has also done systems programming for PPG Industries (1977-1984) and taught computer science at East Stroudsburg University (1991-1996).