Buy One, Get One Free
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:
drop source routed frames
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/rarptabThe 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
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.
Special Reports: DevOps
Have projects in development that need help? Have a great development operation in place that can ALWAYS be better? Regardless of where you are in your DevOps process, Linux Journal can help!
With deep focus on Collaborative Development, Continuous Testing and Release & Deployment, we offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, advice & help from the experts, plus a host of other books, videos, podcasts and more. All free with a quick, one-time registration. Start browsing now...
- Dealing with Boundary Issues
- Vagrant Simplified
- SUSE – “Will not diverge from its Open Source roots!”
- System Status as SMS Text Messages
- Libreboot on an X60, Part I: the Setup
- Bluetooth Hacks
- October 2015 Issue of Linux Journal: Raspberry Pi
- Disney's Linux Light Bulbs (Not a "Luxo Jr." Reboot)
- New Products
- Linux and the Internet of Things