In principle, you can use any mainstream Linux distribution as a login server for thin clients. Distributions that are geared toward desktop use, such as Mandrake and Xandros, can provide lots of eye candy and be very friendly to users, but these features may generate more in the way of video (and hence network) activity than you’d like, because they might use lots of animation and demand large or color-intensive displays. Thus, you might prefer starting with a distribution that provides less fluff, such as Debian, Gentoo, or Slackware, and build it up to the point that you want and no further. This can help you control network and server load.

For the most part, you can configure a Linux login server for thin clients just as you’d configure any other desktop system. Appendix B describes some of the issues involved in such a configuration. When planning this configuration, remember that the video display involves a network access, so features such as animated icons will consume network bandwidth. Because thin clients may be running on small or low-bit-depth displays, you may also need to test your applications on such systems, and perhaps adjust their default configurations.

Fortunately, very little needs to be done to XDMCP and VNC configurations to support thin clients. The configurations described in Chapter 11 should work fine with X terminals and thin clients that support VNC.

For XDMCP, though, one feature you may want to be sure you support is indirect accesses. Some X terminal thin clients can’t present a list of available servers by themselves; they need the help of an XDMCP server that’s configured to provide this list. This can be accomplished on the XDM and KDM servers by editing the Xaccess file to include an appropriate line:

* CHOOSER BROADCAST

You can also specify a pattern of hostnames for the asterisk (*), which lets only specified computers receive the server list. In GDM, the equivalent configuration can be found in the gdm.conf file, which is usually in /etc/X11/gdm:

HonorIndirect=true

This line should appear in the [xdmcp] section of the file. In either case, you must then configure your thin client to make an indirect query of the XDMCP server that supports indirect lookups.

Of course, all this is necessary only if you want your users to be able to use more than one computer from their thin clients. If each thin client should connect to precisely one system, you can configure it to make a direct connection to the remote system and be done with it.

If you’re running VNC on the Linux system to enable remote logins via thin clients, chances are you’ll want to link VNC to an XDMCP server. This configuration enables users to type their usernames and passwords when logging in, rather than logging in via a text-mode protocol, running a VNC server, and then connecting to a specified port. Linking VNC to XDMCP is described in Chapter 11, so consult it for details.

Thin clients are generally much simpler to configure if you use DHCP to help configure them, particularly if you want the thin client to download its OS from a TFTP server. DHCP configuration is described in more detail in Chapter 15, so if you’re not already familiar with DHCP configuration, consult that chapter.

In addition to the common options described in Chapter 15, you may want to add more options for the benefit of thin clients:

Consider Example 12-1, which shows a short but typical configuration for enabling network booting. Many of these options are described in Chapter 15, so consult it for details. This listing points to an XDMCP server and a TFTP server in the opening lines. It also creates a group with options for PXE-bootable hosts, including an additional pointer to the TFTP server and a reference to the file that’s to be delivered to the clients. (To use EtherBoot rather than PXE, change the filename to point to an appropriate .nbi file.) Two specific clients are defined in this group; you can create other groups with other options. This might be handy if your thin clients have different needs, in terms of features such as default resolutions or even the OSs they run. You can mix Linux-based PXES clients with dedicated X terminals, for instance, by creating separate groups for each set of systems and identifying individual clients by their hardware Ethernet addresses.

allow booting;
allow bootp;

# Standard configuration directives...
option domain-name "example.com";
option domain-name-servers ns1.example.com, ns2.example.com;
option routers 172.24.21.1;
#option resource-location-servers server.your.domain;
#option font-servers server.your.domain;
option x-display-manager xdmcp.example.com;
option tftp-server-name "tftp.example.com";

max-lease-time 120;
default-lease-time 120;

subnet 172.24.21.0 netmask 255.255.255.0 {
}

# Options for PXE-bootable hosts
group {
    next-server tftp.example.com;
    server-name "dhcp.example.com";
    filename "/pxes/pxelinux.0";
    get-lease-hostnames true;
    use-host-decl-names on;

    host thin1 {
        hardware ethernet 00:0C:76:96:A3:73;
        fixed-address 172.24.21.101;
    }

    host thin2 {
        hardware ethernet 00:80:C6:F9:3B:BA;
        fixed-address 172.24.21.102;
    }
}

Configuring your DHCP server to deliver information to clients is only part of the job. To do any good, clients must be able to download Linux files from a server. The TFTP protocol was designed for this task; it’s a very simple file transfer protocol that’s useful for clients with minimal software, such as systems that haven’t yet fully booted.

Most Linux distributions ship with a TFTP server, typically in a package called tftp. This server is usually launched through a super server such as inetd or xinetd. A typical xinetd configuration, stored in /etc/xinetd.d/tftp, looks like this:

service tftp
{
  socket_type  = dgram
  protocol     = udp
  wait         = yes
  user         = root
  server       = /usr/sbin/in.tftpd
  server_args  = -s /tftpboot
  disable      = no
}

This configuration is fairly typical of xinetd-launched servers that use UDP. If your distribution uses xinetd, chances are it ships with such a configuration file, but it may be disabled by default; you must change disable = yes to disable = no.

This example also passes an argument to the TFTP server: -s /tftpboot. This option tells the TFTP server to use the chroot( ) system call, which “locks” the running program in the specified directory, making the server treat that directory as if it were the root directory for the system. This is a useful security feature, and it has implications for file access and naming; all files served by the TFTP server must reside in the specified directory tree, and references to files omit the name of the chroot directory. For instance, the file /tftpboot/pxes/pxelinux.0 is referred to as /pxes/pxelinux.0 in client configurations. Because boot clients receive their filenames from a DHCP server, this means you must use these truncated filenames in DHCP server configurations.