Editor's Note: In Part I of this article, Kevin explained how he ended up spending his summer in Nicaragua and why Linux is finding an audience there. Here, he discusses some of the technical aspects of his work.

As for what I've actually been doing down here, the most significant project to date is getting diskless clients to run with our current install, SuSE 9.0. Diskless clients are important to us because it gives us a clear advantage over Windows when marketing to local businesses and schools. Instead of trying to roll it myself, I decided I might as well utilize the years of work that have been put into the LTSP project and chose the LTSP 4.0 release for this project.

The first part of understanding diskless clients is knowing how they boot. Because they have no hard drive, they have to access booting information over the network. The LTSP documentation covers the booting process in detail, but here's a summation:

That's the basic idea of how this process works. The LTSP documentation goes into much more detail towards the end of the list, but for our purposes, this level of detail is sufficient. We now can configure each of the pieces in order; the machine will get closer and closer to functional as we go along.

The first thing to do, as far as I'm concerned, is make sure the network card in your client is capable of booting from the network. This is accomplished in two main ways, either by PXE (Preboot eXecution Environment) or by etherboot. Because the network cards on my clients already were PXE-capable, I went that route. If your network card does not support booting off of the network, ROMs are available for purchase that enable your card to do so in most cases. Often, though, it's cheaper simply to buy a new network card. I recommend Realtek 8139 cards, as I've always had good experience with them. In my experience, however, any modern network card has a bootable ROM.

Also, it is imperative that you understand that all of this configuration is done on the server--not on the client. The client has no hard drive, so it can't store settings. The client will be more successful continually as you go along configuring the server.

Once you've established this setup is possible with your current equipment, the next step is to configure the dhcpd daemon. First, you need to make sure that dhcpd is installed on your system. It's usually installed with the Server group of packages or something akin to that. You can find out for sure if it's installed by typing whereis dhcpd on the command line. On my SuSE 9.0 system, it's installed as /usr/sbin/dhcpd.

You also want to make sure the daemon starts every time you boot. The way this is accomplished on every system is different, so I'll leave you to your distro's documentation. In SuSE 9.0, it is accomplished by utilizing the DHCP configuration module of YaST, under Network Services. Instead of talking about how to get all the correct values in the config file with YaST, I find it easier simply to edit the file by hand. If you're using SuSE, you must be careful not to re-run the DHCP module, as doing so overwrites your changes.

Here is the dhcpd.conf I currently have:

/etc/dhcpd.conf
ddns-update-style ad-hoc;
allow booting;
allow bootp;

subnet 198.186.207.0 netmask 255.255.255.0 {
    range dynamic-bootp 198.186.207.128 198.186.207.254;
    default-lease-time 21600;
    max-lease-time 43200;
}
group{
    next-server 198.186.207.124;
    filename    "pxelinux.0";
    option root-path "/opt/ltsp/i386/";

    host cieba {
        hardware ethernet 00:E0:4C:84:3E:58;
        fixed-address 198.186.207.127;
        option host-name "cieba";
    }

    host chilamate {
        hardware ethernet 00:E0:4C:84:9A:67;
        fixed-address 198.186.207.123;
        option host-name "chilamate";
    }
}

If you wanted to allow the clients to have dynamic IPs--it doesn't really matter, as they're merely thin clients--you should set up the file like this:

ddns-update-style ad-hoc;
allow booting;
allow bootp;

subnet 198.186.207.0 netmask 255.255.255.0 {
    range dynamic-bootp 198.186.207.128 198.186.207.254;
    default-lease-time 21600;
    max-lease-time 43200;
}

next-server 198.186.207.124;
filename    "pxelinux.0";
option root-path "/opt/ltsp/i386/";

Make sure the IPs your network uses are what you put in the range and fixed address areas, if you're using them. I wish I could give more direction in this area, but it really depends on your network setup. On most home networks, this is 192.168.1.1??.

The most important parts of this file are the next-server, filename and option root-path values. The Linux kernel as a whole is too large to be loaded directly by PXE on the network card. So, to accomplish this, we use a boot loader called PXE Linux. It's included with LTSP. This is the pxelinux.0 file that's referenced under the filename marker. The root path is standard for an LTSP implementation.

As for the clients, the hardware Ethernet option is the MAC address of the network card. This can be found using /sbin/ifconfig. I've elected to give the hosts static IPs, but this isn't mandatory.

Once you have your dhcpd.conf file edited appropriately for your network, it's time to restart the dhcpd daemon to apply the changes. On SuSE, rc<name of service> restart restarts any system-wide service, so go to a command line as root and issue the command rcdhcpd restart. On Red Hat-like systems, this is accomplished with service dhcpd restart. Once the daemon's restarted, start your client on network boot, configured in the BIOS, and see how far it gets.

You most likely will get a TFTP error of some kind. Your client has grabbed an IP address--static or dynamic, depending on your dhcpd.conf file--and should tell you what it is. Verify that everything fits your network. If you go back and revisit the boot sequence, you can see that it's time to configure TFTP on the server.

In SuSE, this step is dead easy. Open YaST -> Network Services -> TFTP Server. Select Activate and leave the default directory of /tftpboot. Don't worry if it doesn't exist, YaST will create it for you. Click Finish, and you have TFTP configured. If you navigate to the root (/) directory, you should see the appearance of /tftpboot. If you're using a different distro, you may have to install a TFTP server package, configure it and get it going, I can't really help you here. Consult forums and mailing lists, and good luck.

If you restart your client now, you should get a TFTP: File not found error error. This is because the pxelinux.0 file it's looking for (from dhcpd.conf) is not there. We're using LTSP 4.0, but the LSTP 3.0 initrd kits work fine. These are files that contain the necessary components to boot an LTSP system. Download this tarball, and you'll find a file called pxelinux.0; move it to the /tftpboot directory. Now, we must configure the PXE Linux boot loader, which is done on the server.

In the /tftpboot directory, make a subdirectory called pxelinux.cfg. The boot loader searches this directory for a config file named after the MAC address of the network card in multiple ways. I found that I didn't need separate files for the clients, so I used only one file, called default. This file is much like a LILO config file. Place the following lines in the file, using your favorite text editor:

/tftpboot/pxelinux.cfg/default
prompt=0
label linux
        kernel <kernel image>
        append init=/linuxrc rw root=/dev/ram0 initrd=<initrd image>

where <kernel image> is the name of the kernel image and <initrd image> is the name of the initrd image included in the initrd kit. The kernel should be named bzimage something and the initrd image is initrd something.gz. Please don't use the LPP (Linux progress patch) kernel until you're sure everything works correctly; it has lpp in its name. This process displays a nice progress bar, which is wonderful--unless something goes wrong. In that case, it's far more useful to have the kernel messages.

Next, you need to place the kernel and init images in the /tftpboot directory. Do not place them in a subdirectory, simply in the /tftpboot directory. If you boot up your client now, you should see it try to mount the root filesystem and fail. That's because it doesn't exist yet; it comes from installing LTSP on the server.

The LTSP team has done a fantastic job of making this step as painless as possible. The install process is described on the LTSP site; it installs LTSP to /opt/ltsp/i386.

Go through the installer again, but this time select the X package instead of the base package.

Make sure the LTSP install path (the default is /opt/ltsp/i386) is exported by way of NFS, or your client will not be able to mount the root filesystem. This means you need to configure NFS if you haven't already done so. Again, this step is dead easy on a SuSE system; all you have to do is utilize the appropriate module is YaST.

The client now should boot up to a grey screen with an X mouse cursor; alternatively, you may get a login screen. If you got the login, you're done. Otherwise, you're almost there. Whether you get a login is dependent on whether the login manager on the server is set up to accept remote connections. f you didn't get a login screen, then most likely your login manager is not configured to accept remote logins. On SuSE, go to YaST, System, /etc/sysconfig Files Editor, find Desktop -> Display Manager -> DISPLAY_MANAGER_REMOTE_ACCESS and set it to Yes. Your client now should boot up into a fully functional desktop, as if you were sitting at the server.

If you aren't using SuSE or if YaST leaves you in the cold, the configuration file for KDM is located at /etc/opt/kde3/share/config/kdm on a standard directory structure. If you use Red Hat or another non-standard distro, then I can't help you. Check your documentation. Once your login manager accepts remote connections, you should have a fully functional thin client.

If you want to limit access to certain parts of the KDE desktop--if, for instance, you're setting up an Internet café, then you should use Kiosk mode. A Kiosk mode editor is available for SuSE 9.1 or KDE 3.2.2, which greatly simplifies your life. Otherwise, you can create a user and then edit the configuration files by hand. The KDE team has a HowTo on this subject on its site.