The Linux Diskless Workstation HOWTO <author> Sumeet Madhukar Moghe <url url="mailto:sumeet@ascentsolutionsonline.com" name="sumeet@ascentsolutionsonline.com"> <date> v1.0.2, May 2003 <abstract> This HOWTO is a simplified guide to the creation of secure diskless terminals, using Linux as the underlying operating system. This article assumes no knowledge whatsoever of electronic technology, such as burning ROM chips, and hence concentrates on software aspects alone. This therefore aims to be a quick reference for an inexperienced system administrator who wants to get a cheap yet high-performance network running in no time. </abstract> <toc>  <sect>Before we begin <sect1>Why this document? The content of this document may well beg the above question, in light of the fact that several other HOWTOs and manuals exist on the concerned subject. I, however, believe that those documents either assume an in-depth working knowledge of electronic technology or UNIX system administration or are very cursory in nature. This document attempts to overcome those limitations and cater to less experienced system administrators who have just begun playing with their Linux boxes. In later versions of this document, I also intend to include detailed cost metrics and first-hand statistics on the performance of diskless workstations. It is an honest attempt to provide in a simplistic form "everything of something" than "something of everything" !! <sect1>For whom is this document This document is intended for the following audience:- <itemize> <item> Students with a basic knowledge of networking and exploring the virtues of Linux, <item> System Administrators, <item> Entrepreneurs wishing to reduce network/hardware/maintainence costs, and <item> Colleges and educational institutions that wish to provide secure terminals for students in their computer labs </itemize> While this document can be perused and its contents executed with little preliminary knowledge of Linux system administration, it would be of help if the readers had a working knowlege of the following: <itemize> <item> TCP/IP and networking with Linux <item> Dynamic Host Configuration protocol (DHCP) <item> Network File System (NFS) and Trivial File Transfer Protocol (TFTP) <item> The working of the X Windows System </itemize> Since the following HOWTO is based on a Red Hat 9 system, I guess <url url="http://www.Red Hat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/"> would be a great starting point for the above information. <sect1> Current versions of this document The latest tarball of this document can be found <url url="http://www.geocities.com/smm_cipher/Diskless-Workstation/Diskless-Terminals-HOWTO.tar.gz" name="here">. The LinuxDoc SGML source for the document can be found <url url="http://www.geocities.com/smm_cipher/Diskless-Workstation/Diskless-Terminals-HOWTO.sgml.gz" name="here"> You can read this document online <url url="http://www.geocities.com/smm_cipher/Diskless-Workstation/Diskless-Terminals-HOWTO.html" name="here"> <sect2> Other formats <url url="http://www.geocities.com/smm_cipher/Diskless-Workstation/Diskless-Terminals-HOWTO.txt.gz" name="Plain text"> <url url="http://www.geocities.com/smm_cipher/Diskless-Workstation/Diskless-Terminals-HOWTO.info.gz" name="Info pages"> <url url="http://www.geocities.com/smm_cipher/Diskless-Workstation/Diskless-Terminals-HOWTO.rtf.gz" name="Rich text Format (RTF)"> <url url="http://www.geocities.com/smm_cipher/Diskless-Workstation/Diskless-Terminals-HOWTO.tex.gz" name="LaTex"> <url url="http://www.geocities.com/smm_cipher/Diskless-Workstation/Diskless-Terminals-HOWTO.dvi.gz" name="Device Independent (DVI)"> <url url="http://www.geocities.com/smm_cipher/Diskless-Workstation/Diskless-Terminals-HOWTO.pdf.gz" name="Portable Document Format (PDF)"> <url url="http://www.geocities.com/smm_cipher/Diskless-Workstation/Diskless-Terminals-HOWTO.ps.gz" name="Postscript"> <sect1> About the author I am Sumeet Madhukar Moghe; a die-hard FLOSS evangelist. I live by the day as a student of the arts (sic!) and by night as a hacker. My association with Linux dates back to 1998 and it has been a love story ever since. My home on the web can be found at <url url="http://smith-morgan.mirrorz.com">. <sect1> Whom to contact for help Before sending out an SOS signal to me (<url url="mailto:sumeet@ascentsolutionsonline.com" name="sumeet@ascentsolutionsonline.com">) be sure that your problem, with respect to this document, has not been already solved elsewhere. Search the web; <url url="http://www.google.com" name="Google"> is a good starting point. Join a Linux User Group somewhere in the vicinity and post your problems there for a solution. Read <url url="http://www.catb.org/~esr/faqs/smart-questions.html" name="this page"> to get a good idea on how to ask smart questions on Usenet. The best way to learn however, is to <bf>RTFM = Read The Fine Manual</bf>. I hope this document will be useful to you. Happy hacking!! <sect>Introduction If you or your organisation has been working with computers for some time now, then it is pretty much assumed that over the years, you have retired many a computer, and now have a warehouse full of those supposedly useless machines. Did you know that those discarded boxes could be put to better use? Or that each of those boxes could be made to run a modern operating systems at nearly no cost, whatsoever? Surprise, surprise!! Linux can breathe life into that pathetic 486 of yours! And what's more: it could run at a decent clip compared to a Pentium III! The idea is as simple as it gets. Take a simple bare-bones PC with some memory, a cheap display card and a decent network card, and turn it into a workstation for office work or surfing the net, or for scientific computing. In educational organisations you could use it as a terminal for students to perform their practicals. Interested?? Read on... <sect1>A historical perspective Way back in the late 1970s and 1980s, memory and hard disk space were insanely expensive, and there arose a need to find ways and means to make workstations more affordable. However, as displays became more and more sophisticated and preliminary GUI applications replacing their legacy character-based counterparts, this task seemed more and more daunting. In those days of UNIX, universities and large corporations found a method to do this. They used the X Window System and gave birth to a new breed to displays - X Terminals. These systems had no local storage and very little memory. All they were meant to do was to run an X display for their own purposes in order to support applications running on the server itself. As workstations became more powerful, the need arose to run applications using the processing power of the workstation alone. Storage, however, continued to be expensive and hence servers continued to handle the storage for the networks. Soon these terminals, were the "in thing", finding favor with corporates and small organizations, alike. Management of such networks was simple with a centralized server being all that needed to be configured and maintained. A single point failure in the network was easy to rectify, and terminals that failed could easily be swapped with working systems. But as processing power increased to deal with computing demand, networks could not cope with the immense traffic generated by simulataneous read-write operations from various hosts. With secondary storage becoming cheaper, diskless systems were soon things of the past and the benefits of centralized computing were lost. However with the recent increase in network bandwidth, diskless systems have seen a sort of a revival and have found usage in many a computing applications, such as public reservation systems, information kiosks, set-top boxes, etc. Diskless nodes are once again being considered as a tremendous cost-saving exercise and centralized computing is seeing a renaissance. <sect1> Look Ma...No disk!! A truly diskless system can eliminate the following storage devices: <itemize> <item> Hard Disk <item> CD-ROM Drive <item> Floppy Drive </itemize> With a diskless setup, even the need for a monitor can be elimnated. The above setup, however, would need the expertise of burning the boot images on to a ROM chip, which (as indicated earlier), would be beyond the scope of this article. We shall therefore look at other options involving a single, removable storage device. <sect1> The pros and cons of going diskless <sect2> The Advantages Diskless systems have many advantages to offer: <enum> <item><bf>Diskless sytems offer a very low-cost solution.</bf> <itemize> <item>The RAM on the central server is shared by many clients. A single copy of a program is kept in memory and used by multiple clients. For example, in an internet cafe, despite the fact that various users on the network use a web browser, only one copy of the web browser is kept in memory, thereby eliminating wasted memory. Thus, by pooling memory on the server, memory costs can be reduced tremendously. <item>There is no need for a UPS or airconditioned environment for the diskless clients. Providing the server alone, with a UPS, serves the purpose. <item> The cost of the workstations, with typically low requirements, is minimal. </itemize> <item><bf>With no local storage, diskless systems can be made very secure </bf> These are ideal machines for students to experiment with. There is no local filesystem to corrupt if the machine crashes. Files on the server can be easily controlled or replaced. Diskless workstations are also safe from viruses, which function by copying themselves to the hard disk. The risk is limited to the central server. <item><bf>Administration of a group of diskless systems is simpler.</bf> As discussed earlier, because administration is centralised, workstations can be added and removed with great ease. Backups need to be maintained only at the server end, and all configuration can be performed centrally. This is particularly useful when the network is spread over a campus or over several offices in a company. <item><bf>Diskless computers offer high-speed performance.</bf> With the elimination of program loading time, diskless computers tend to work very fast. Once someone has loaded a memory hog like Star Office/Open Office into memory, the program loads in a flash for subsequent users. </enum> <sect2>The Disadvantages With the advent of modern 100 MBit and 1 Gigabit ethernet cards, network bandwidth is no longer a consideration for the performance of diskless systems. However, with distributed computing having played a significant role in the proliferation of desktop PCs, the totally server-based solution represents a single point of failure. However, when compared to the central dependency that many modern systems have on various specialised, central servers, the diskless scenario doesn't look much worse. The bottom line is: Take care of your server!! <sect> The Technology under the hood To build a diskless network, it is important to understand how such a system works. This section deals with the basics of how such a system functions. <sect1>How does it work ? Each time it boots up, the diskless system follows these steps: <enum> <item>The BIOS, configured to boot from either a floppy or a network card's BOOT ROM, reads the boot information from the specified device. <item> The media then does the following <itemize> <item> Broadcasts its MAC address on the network, searching for a DHCP server. <item> Receives an IP address from the DHCP server and configures the NIC accordingly. <item> Fetches a predefined kernel image from the server using TFTP (Trivial File Transfer Protocol). <item> Loads this kernel image into the RAM. </itemize> <item> Once the kernel image is loaded into the RAM, the root file system is fetched via NFS. <item> Depending on the methodology adopted, system initialization scripts are run and the system is made ready for use. </enum> <sect1>Methods of achieving diskless systems Diskless systems can be achieved in 3 ways:- <enum> <item><ref id="ltsp_" name="LTSP"> The Linux Terminal Server Project. <item>Network Booting with <ref id="etherboot_" name="Etherboot"> <item><ref id="cd_" name="CD Based distributions"> </enum> <sect> LTSP - The Linux Terminal Server Project <label id="ltsp_">The LTSP provides a simple way to utilize low-cost workstations as either graphical or character based terminals on a GNU/Linux server. Using the LTSP, you can take very low-end PCs, remove the hard drives and CD-ROMs, and add floppies or bootable network cards. Many network cards have bootrom sockets just waiting for a bootrom to be inserted. During the boot phase, the diskless workstation obtains its IP info and a kernel from the server, then mounts the root filesystem from the server via NFS. A workstation using the LTSP can be configured in the following ways: <enum> <item> <bf>Graphical Workstation</bf> The workstation uses the X-Window System to access applications on the Linux Terminal Server <item> <bf>Character-Based Telnet Session</bf> Multiple telnet sessions are invoked by the client to the telnet server. Users can switch between telnet sessions by pressing Alt+F1 through Alt+F9. However, telnet being an extremely insecure service, the use of this mode is strongly discouraged. <item> <bf>Shell Prompt</bf> This basically drops the user in a minimalistic bash prompt. This mode is basically a diagonistic or troubleshooting mode that helps debug problems with X or NFS. </enum> Depending on the size of the server and the applications being run, a number of clients can be served by a single Linux server. The LTSP official documentation tells us: "It's not unusual to have 40 workstations, all running Netscape and StarOffice from a Dual PIII 650 with 1GB of ram. We know this works. In fact, the load average is rarely above 1.0!" <sect1> Configuring the Linux Terminal Server Let us now look at how to configure LTSP on a Red Hat 9 server. Perform all the underlined steps as <bf>root</bf> <sect2>Packages required The packages required for LTSP are available at <url url="http://www.ltsp.org" name="ltsp.org">. To start, you will need the following packages: <enum> <item>ltspcore-x.x.x.i386.rpm <item>ltsp_kernel-x.x.x.i386.rpm <item>ltsp_x_core-x.x.x.i386.rpm <item>ltsp_x_fonts-x.x.x.i386.rpm </enum> Where x.x.x is the version of the package set downloaded. <sect2>Installing the packages Install the packages as follows: <code> [root@quaker install_scripts]#rpm -ivh ltspcore-x.x.x.i386.rpm [root@quaker install_scripts]#rpm -ivh ltsp_kernel-x.x.x.i386.rpm [root@quaker install_scripts]#rpm -ivh ltsp_x_core-x.x.x.i386.rpm [root@quaker install_scripts]#rpm -ivh ltsp_x_fonts-x.x.x.i386.rpm </code> <sect2>Running the distro-specific install script Once the packages are installed, change to the directory <tt>/opt/ltsp/install_scripts/</tt> and run the script <tt>redhat.sh</tt> <code> [root@quaker install_scripts]# cd /opt/ltsp/install_scripts/ [root@quaker install_scripts]# sh redhat.sh Take a look in /tmp/ltsp.install.log for a complete log of the installation. You now need to change to the /opt/ltsp/templates directory and run the ltsp_initialize script to complete the installation </code> <sect2> Initializing the Services Now change to the directory <tt>/opt/ltsp/templates</tt> and run the script <tt>ltsp_initialize</tt>. Follow the steps as indicated below. <code> [root@quaker install_scripts]# cd /opt/ltsp/templates/ [root@quaker templates]# ./ltsp_initialize The Linux Terminal Server Project (http://www.LTSP.org) About to update important system files. If you would like to stop and review the changes that are about to be made, you can cancel now and look at the replacement files that are about to be installed. Press <ENTER> to go on, or 'C' to cancel</code> <bf><ENTER></bf> <code> The Linux Terminal Server Project (http://www.LTSP.org) The following files will be created/modified: /etc/X11/xdm/Xaccess The config file to allow remote xdm log [Y] /etc/X11/xdm/Xservers Config file for xdm to launch local Xse [Y] /etc/X11/xdm/Xsetup_workstation Sets the logo of your login window [Y] /etc/dhcpd.conf.example Example config file for dhcp [Y] /etc/exports The config file for nfs [Y] /etc/X11/gdm/gdm.conf The config file for gdm [Y] /etc/X11/gdm/Init/Default The gdm startup script [Y] /etc/hosts.allow Configuration file for tcp wrappers [Y] /etc/inetd.conf Config file for inetd [Y] /etc/inittab Config file for init [Y] /etc/kde/kdm/kdmrc The config file for kdm [Y] /etc/X11/xdm/ltsp.gif The background logo for your login [Y] /etc/rc.d/rc5.d/S60nfs Startup links for nfs [Y] /etc/rc.d/rc5.d/S13portmap Startup links for portmapper [Y] /etc/rc.d/init.d/syslog Startup script for syslogd [Y] /etc/xinetd.d/tftp Enable the tftp daemon [Y] /etc/X11/xdm/xdm-config The main config file for xdm/kdm [Y] Ready to apply the changes? ( R-Review, A-Apply, C-Cancel )</code> <bf>A<ENTER></bf> <code> The Linux Terminal Server Project (http://www.LTSP.org) Doing the update Xaccess.tmpl Saving old /etc/X11/xdm/Xaccess as /etc/X11/xdm/Xaccess.2 Xservers.tmpl Saving old /etc/X11/xdm/Xservers as /etc/X11/xdm/Xservers.2 Xsetup_workstation.tmpl Saving old /etc/X11/xdm/Xsetup_workstation as /etc/X11/xdm/Xsetup_workstation.1 dhcpd.tmpl Saving old /etc/dhcpd.conf.example as /etc/dhcpd.conf.example.1 Creating new dhcpd.leases file Saving old /etc/exports as /etc/exports.2 gdm.conf.tmpl Saving old /etc/X11/gdm/gdm.conf as /etc/X11/gdm/gdm.conf.2 gdm_Init_Default.tmpl Saving old /etc/X11/gdm/Init/Default as /etc/X11/gdm/Init/:0 hosts.allow.tmpl Saving old /etc/hosts.allow as /etc/hosts.allow.2 inetd.tmpl Saving old /etc/inetd.conf as /etc/inetd.conf.1 inittab.tmpl Saving old /etc/inittab as /etc/inittab.2 kdmrc.tmpl Saving old /etc/kde/kdm/kdmrc as /etc/kde/kdm/kdmrc.2 ltsplogo.tmpl Saving old /etc/X11/xdm/ltsp.gif as /etc/X11/xdm/ltsp.gif.1 nfs.tmpl Saving old /etc/rc.d/init.d/syslog as /etc/rc.d/init.d/syslog.2 tftpd.tmpl xdm-config.tmpl Saving old /etc/X11/xdm/xdm-config as /etc/X11/xdm/xdm-config.2 </code> <sect2> Configuring the DHCP daemon Bingo!! That sure does take care of a lot of stuff! Now all we need to do is perform some minor changes to a few configuration files. The first file I usually modify is <tt>/etc/dhcpd.conf</tt>. In this example, I assume a server with IP address <tt>192.168.100.13</tt> and a diskless workstation which will be assigned the IP address <tt>192.168.100.14</tt> and hostname <tt>ws001</tt>. This workstation's ethernet card has a MAC address <tt>00:0B:2B:0B:6B:2E</tt>. The netmask is <tt>255.255.255.0</tt> and the domain name is <tt>gamingheaven.com</tt>. In order to do this, open the file <tt>/etc/dhcpd.conf</tt> and make it read as follows (rather, change it to suit your setup ;)). This is a recommended minimum configuration: <code> ddns-update-style ad-hoc; default-lease-time 21600; max-lease-time 21600; option subnet-mask 255.255.255.0; option broadcast-address 192.168.100.255; option root-path "192.168.100.13:/opt/ltsp/i386"; #The above line specifies where to fetch the root file system from shared-network WORKSTATIONS { subnet 192.168.100.0 netmask 255.255.255.0 { } } group { use-host-decl-names on; option log-servers 192.168.100.13; #configuring the first host host ws001 { hardware ethernet 00:0B:2B:0B:6B:2E; fixed-address 192.168.100.14; filename "/lts/vmlinuz-2.4.9-ltsp-5"; #We need to copy the above file to the tftpboot directory. } } </code> <sect2> Configuring hostname mapping <label id="hostname_">Computers usually love communicating with numbers. Human beings on the other hand prefer names because we find them easier to remember. This is where the file <tt>/etc/hosts</tt> or DNS comes into play. Theoritically, IP address to hostname mapping should not be required. In an LTSP environment, however, we can't do without it because NFS throws permission errors when the workstation tries to mount the root file system over the network. We just need to add a single line to <tt>/etc/hosts</tt> describing the workstation, so that surely won't be too painful! In my case the line would look like this: <code> ws001.gamingheaven.com ws001 192.168.100.14 </code> <sect3> Workstation-specific configurations We now need to edit the global LTSP configuration file <tt>/opt/ltsp/i386/lts.conf</tt> and perform the following steps. Again, this is a recommended minimum configuration. <enum> <item> In the default section edit the line containing SERVER and change it to read SERVER = <your server ip> In my case, it reads: <code> SERVER = 192.168.100.13 </code> <item> In the section [ws001] (which you should change to the hostname you set in <tt>/etc/dhcpd.conf</tt>), you can play with the following options: <itemize> <item> RUNLEVEL: Set this to 3 for a <bf>Shell Prompt</bf>, 4 for <bf>Character based Telnet Session</bf> and 5 for a <bf>Graphical Workstation</bf> <item> XSERVER: Set this if you want to force a specific X-Server module to be loaded for your workstation For example: <code> XSERVER = vesa #This forcibly loads the generic vesa driver module for you X-Server </code> <item> X_MODE_0 through X_MODE_2: Up to 3 Modelines or resolutions can be configured for the workstation. This entry can take two different types of values: a resolution or a complete modeline. For example, if you have a really old monitor, you could use the following modelines. (Use Ctrl+Alt+KP+ to cycle between the resolutions in the same order as you list them here.) <code> X_MODE_0 = 640x480 31.5 640 664 704 832 480 489 492 520 +hsync +vsync X_MODE_1 = 800x600 40 800 840 968 1056 600 601 605 628 +hsync +vsync X_MODE_2 = 1024x768 44.9 1024 1048 1208 1264 768 776 784 817 interlace </code> <item> USE_XFS: Set this to Y if you wish to use the X Font server. <item> MODULE_xx: (where xx is a number starting from O1) Set this to the name of a module you wish to load for your workstation. For example, I use the following line to initialize a Yamaha soundcard on one of my workstations: <code> MODULE_01 = opl3.o </code> <item> To setup printers attached to the workstation, use the parameters PRINTER_0_DEVICE and PRINTER_0_TYPE. Set the former to the device identity of the printer and the the latter to "S" for serial printers and "P" for parallel port printers. To add other printers use PRINTER_1_DEVICE and PRINTER_1_TYPE and so on. You can add up to 3 printers. For example: <code> PRINTER_0_DEVICE = /dev/lp0 PRINTER_0_TYPE = P </code> </itemize> There are a number of other such parameters to play with, but discussing them all would be beyond the scope of this document. </enum> <sect2> Setting the Default Display Manager The <tt>ltsp_initialize</tt> script does a great job handling all the scripts, but makes a the mistake of setting XDM as the display manager for the clients. I personally enjoy the insane eye-candy of GDM. To use GDM, open the file <tt>/etc/inittab</tt>, scroll down to the line that reads <tt>x:5:respawn:/usr/X11R6/bin/xdm -nodaemon</tt> and change it to: <code> x:5:respawn:/usr/bin/gdm -nodaemon </code> Well, that's it for the server configuration. Switch to runlevel 5. <code> [root@quaker etc] init 5 </code> Whoa!! Your LTS is up and running. We still need to work a little to get our workstation up. <sect1> Building the bootdisk for the workstations. <label id="bootdisk_">Making the floppy is usually as simple as downloading the boot image from Marty Connor's<url url="http://www.rom-o-matic.net">. Marty has done an execellent job with the site: it generates boot images on the fly when you enter your network card chip model. The default configuration usually doesnt need changing. For my Realtek 8139 cards (rt8139), I got the following boot image: <code>eb-5.0.8-rtl8139.lzdsk </code> To create the bootdisk, change to the directory containing the downloaded boot image and run the following command: <code> [sumeet@quaker sumeet]$ dd if=eb-5.0.8-rtl8139.lzdsk of=/dev/fd0 </code> You could also use Etherboot to locally build boot images for various NICs. Etherboot is a package for creating ROM images that can download code over an Ethernet network, to be executed on an x86 computer. It can be downloaded freely from <url url="http://etherboot.sourceforge.net/distribution.html">. Creating boot images with Etherboot involves the following steps: <enum> <item>Untar and unzip the sources from the etherboot package <item>Dive into the "src" directory at the location where you untarred the package. <item>Insert a floppy into the floppy drive and run the following command: <tt>make bin32/<network-card-name.fd0></tt> For example, with my RTL 8139 cards I need to execute the following steps <code> [sumeet@quaker sumeet]$ tar -zxvf etherboot-5.0.8.tar.gz [sumeet@quaker sumeet]$ cd etherboot-5.0.8/src/ [sumeet@quaker src]$ make bin32/rtl8139.fd0 </code> </enum> Now that your disk is ready, configure the BIOS of your diskless workstations to boot from the floppy and boot them up using this disk. You should get the GDM login window, with an LTSP.org background. Login and enjoy!! <sect1> Shutting down the diskless system Shutting down a diskless node couldn't be easier. Just press the power switch and walk away. That's it!! Now isn't that easy? <sect> Network Booting with Etherboot <label id="etherboot_"> This is a slightly more complicated method of getting diskless systems to work. However, once configured, it allows greater flexibility than LTSP. It allows users access to six terminals in addition to the standard X session. Etherboot works on the same principle as LTSP, but it uses BOOTP (Boot Protocol) instead of DHCP. A server running BOOTP will receive the request for an IP address and return the IP address the client system is to use. Since the BOOTP request is broadcast -- that is, addressed to all computers on the network -- the client doesnt need to know the address of the server. Note: BOOTP is not a standard part of the Red Hat 9 distribution; you must download it from <url url="http://www.rpmfind.net">. <sect1>Configuring BOOTP Configuring BOOTP is extremely simple compared to DHCP. You just need to remember the following commonly used fields and flags: <table> <tabular ca="cc"> bf | Boot File@ dn | Domain Name@ ds | Domain Name Server address List@ ha | Host Hardware Address@ ip | Host's IP Address@ hn | Send client's hostname to client@ ht | Hardware Type @ sa | TFTP server address@ rp | Root Path to mount as root@ tc | Table Continuation@ </tabular> </table> Based on this, my <tt>/etc/bootptab</tt> file looks like this: <code> .def:ht=ethernet:hn=y ws001:ha=000B2B0B6B2E:ip=192.168.100.14:tc=linux linux:bf=/tftpboot/linux.diskless </code> Setup BOOTP to start up automatically in runlevel 5 <code> [root@quaker root]#chkconfig --level 5 bootp on </code> <sect1> Configuring TFTP Edit the file <tt>/etc/xinetd.d/tftp</tt>. Change the line that reads: <tt>disable = yes</tt> to read: <tt>disable = no</tt> and the line that reads <tt>server_args = -s /tftpboot</tt> to read: <tt>server_args = /tftpboot</tt> Finally, setup TFTP to start automatically in runlevel 5 <code> [root@quaker root]#chkconfig --level 5 tftp on </code> <sect1> Building and configuring the kernel image for the Diskless Systems We now need to build the kernel image that will be loaded into the RAM of the diskless system. <sect2>Configuring the kernel Dive into the kernel sources directory and run <tt>make menuconfig</tt> Then do the following: <enum> <item> Enable the option [General Setup-->Networking Support]. <item> Enable the option [File systems-->Network File Systems-->NFS file system support] and [File systems-->Network File Systems-->NFS file system support-->Root over NFS]. <item> Enable the options [Networking Options-->IP: kernel level autoconfiguration] and [Networking Options-->BOOTP support]. <item> Build your network card drivers into the kernel instead of selecting them as modules: [Network Device Support-->Select your card driver] </enum> <sect2> Building the Kernel It takes just one command to build the kernel: <code> [root@quaker linux2.4]# make dep clean bzImage </code> This leaves a your new kernel image at <tt>/usr/src/linux2.4/arch/i386/boot/bzImage</tt>. Move this to the <tt>/tftpboot</tt> directory. <code> [root@quaker linux2.4]# mv i386/boot/bzImage /tftpboot/kernel.diskless </code> <sect2>Making the kernel network bootable We now need to explicitly make sure that the kernel is meant to boot from the network rather than a hard disk. To ensure this, we run the following set of commands: <code> [root@quaker linux2.4]# cd /tftpboot [root@quaker tftpboot]# mknod /dev/nfs c 0 255 [root@quaker tftpboot]# rdev kernel.diskless /dev/nfs </code> <sect2>Creating a Tagged Image The last step that remains is to create the tagged image. A kernel image intended for a diskless client needs a special header which tells the network bootloader where the bytes go in the memory and at what address to start the program. This image is called the tagged image. Creating a tagged image is simple; all we need is the <tt>mknbi-linux</tt> tool from <tt>the etherboot</tt> package: <code> [root@quaker tftpboot]# mknbi-linux kernel.diskless > linux.diskless </code> <sect1> Configuring NFS A diskless system configured with IP address 192.168.100.14 attempts to mount the root filesystem from the location /tftpboot/192.168.100.14. We therefore add the following workstation-specific lines to <tt>/etc/exports</tt> <code> /tftpboot/192.168.100.14 ws001(rw,no_root_squash) /usr (ro) /opt (ro) </code> As you can see above, we export the directory <tt>/tftpboot/192.168.100.14</tt> with read+write options and allowing root access to the workstation ws001 (<ref id="hostname_" name="Hostname Mapping"> needs to be configured here). The /usr and /opt directories are made available in order to allow workstations to access installed programs. Finally, make the exported file systems available and setup NFS to start up automatically in runlevel 5: <code> [root@quaker root]# exportfs -a [root@quaker root]# chkconfig --level 5 nfs on </code> <sect1> Initializing the root filesystem A minimal root filesystem for the client should contain the following directories in their entirety: /etc - Configuration files /var - Log files /lib - Libraries used at boot time /dev - device files A simple script, <tt>buildroot</tt> automates the process of creating the root filesystem with the minimum of fuss. The script is as follows <code> #!/bin/bash if [ $# != 1 ] then echo Usage: $0 client-IP-address-or-name exit 1 fi cd / umask 022 mkdir -p /tftpboot/$1 for d in home mnt proc tmp usr opt do mkdir /tftpboot/$1/$d done chmod 1777 /tftpboot/$1/tmp touch /tftpboot/$1/fastboot chattr +i /tftpboot/$1/fastboot cp -a bin lib sbin dev etc root var /tftpboot/$1 cat << EOF Now, in /tftpboot/$1/etc, edit sysconfig/network sysconfig/network-scripts/ifcfg-eth0 fstab hosts modules.conf and configure rc.d/rc3.d EOF </code> Move the script to <tt>/usr/bin</tt>. The script can be invoked from the command line, like this: <code> [root@quaker tftpboot] buildroot 192.168.100.14 </code> <sect2> Setting up NFS mounts Now it's time to set up the filesystems exported from NFS. We do this in order that the client should mount them. The file <tt>/etc/exports</tt> should be set up as shown below: <code> 192.168.100.13:/tftpboot/192.168.100.14 / nfs rw 0 0 192.168.100.13:/usr /usr nfs ro 0 0 192.168.100.13:/opt /opt nfs ro 0 0 proc /proc proc defaults 0 0 devpts /dev/pts devpts defaults 0 0 </code> <sect2> Setting up the network scripts Set the values of HOSTNAME and IPADDR in the files <tt>/tftpboot/192.168.100.14/etc/sysconfig/network</tt> and <tt>/tftpboot/192.168.100.14/etc/sysconfig/network-scripts/ifcfg-eth0</tt> respectively. Finally, delete unwanted scripts in <tt>/tftpboot/192.168.100.14/etc/rc.d/rc3.d/</tt>. <sect1> Setting up the display manager Setting up GDM as the display manager usually involves 2 simple steps: <enum> <item>Open the <tt>/etc/X11/gdm/gdm.conf</tt> file and scroll down to the section [xdmcp]. Add this line: <code> Enable = true </code> <item>Open the file <tt>/etc/inittab</tt> and replace this line: <code> x:5:respawn:/etc/X11/prefdm -nodaemon </code> with this one: <code> x:5:respawn:/usr/bin/gdm -nodaemon </code> to force GDM as the display manager. </enum> All that needs to be done now is to switch to runlevel 5: <code> [root@quaker root]# init 5 </code> <sect1> Building the bootable disk for the client <ref id="bootdisk_" name="Building the bootdisk for the diskless client"> is the same as described for the <ref id="ltsp_" name="LTSP configuration">. Just pop in the disk and boot up your clients. <sect1> Running X on the client To run X on the diskless node, execute the following command: <code> $ X -query 192.168.100.13 </code> This should give you a GDM login window. Login and enjoy your remote X session. You can also switch between X and the 6 consoles from Ctrl+Alt+F1 through F6. <sect> CD Based Distributions - Rapid Upgrade diskless systems <label id="cd_">CD-based distributions and Live! Linux CD-ROMs are fast becoming popular ways to implement diskless nodes. These distributions use a compressed file system and boot off a CD-ROM. Note that they require over 128 MB of RAM for satisfactory performance, and they eliminate the possibility of workstation users having any storage facilities. They also depend on a pre-configured DHCP server if they are to have any kind of network capability. Also, for internet access, the additional task of configuring a proxy server is introduced. Despite these inherent limitations, CD-based distros are popular for the singular reason that they offer a painless software upgrade scheme: to get a completely new operating system, the user just trashes the old CD and starts booting from the new one. A few extremely popular CD based distros are listed below: <itemize> <item><url url="http://www.knopper.net" name="Knoppix"> <item><url url="http://www.slackware.org" name="Slackware Live!"> <item><url url="http://www.lnx-bbc.org" name="Linux Bootable Business Card"> <item><url url="http://lab.dyne.org/DyneBolic" name="DyneBolic Linux"> <item><url url="http://www.demolinux.org" name="Demo Linux"> </itemize> <sect> Online References <itemize> <item>Official LTSP Documentation<url url="http://www.ltsp.org/documentation/ltsp-3.0-4-en.html"> <item> Documentation index of the Etherboot project <url url="http://etherboot.sourceforge.net/doc/html/documentation.html"> <item>Building a self-contained auto-configuring Linux system on an iso9660 filesystem<url url="http://www.knopper.net/knoppix/knoppix-als2000-paper-html/"> <item>The LDP Diskless Nodes HOWTO <url url="http://www.tldp.org/HOWTO/Diskless-HOWTO.html"> </itemize> <sect>Copyright Notice Copyright © 2003 by Sumeet Madhukar Moghe. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0.8 or later. (The latest version is presently available at <url url="http://www.opencontent.org/openpub">.) Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. <bf>NO WARRANTY.</bf> Open Publication works are licensed and provided "as is" without warranty of any kind, express or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose or a warranty of non-infringement. </article>