Buy One, Get One Free

Configuring Linux as a dual-purpose user environment.
Server Base System Installation

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.

Network Preparation/Configuration

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:

  • TCP/IP networking

  • drop source routed frames

  • reverse ARP

  • allow large windows

  • network device support

  • token-ring driver support

  • IBM tropic chipset-based adapter support

The Slackware network initialization script, /etc/rc.d/rc.inet1, was edited to set up the token-ring interface (tr0). This was done by replacing the default network interface argument Ethernet, eth0, supplied to the ifconfig command with tr0.

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_Address

The rarptab script was invoked at system boot from /etc/rc.local, using the command

sh -c /etc/rarptab
The server's /etc/exports file was modified to give client PCs access to the following directories:
  • /adm: shared files moved from /etc

  • /home: user home directories

  • /root: superuser's home directory

  • /shlib: loadable libraries

  • /usr: system tools and user directories

  • /var/X11R6: XFree86 shared libraries

  • /var/openwin: Sun Window system shared libraries

Client PCs were given read-write access to /home and /root directories. Access to all other directories was restricted to read-only. Entries added to /etc/exports had the following format:
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
Client Base System Installation

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.

Client System Files Configuration

Listing 1.

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:

  • /tftpboot/lin2/var/openwin

  • /tftpboot/lin2/shlib

  • /tftpboot/lin2/man

  • /tftpboot/lin2/info

lin2's /etc/exports file was then edited to allow lin2 to export the CD-ROM that would later be placed on that machine. The following lines were added to lin2's /etc/exports:
/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.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState