Docs/SysAdmin/Server/TerminalServer
From Mandriva Community Wiki
A guide for using the terminal-server package.
Contents |
Terminal-server is a subsytem of Mandriva Linux that is perhaps less than well publicized. If you are familiar with LTSP, it is very similar, except that it uses the server's root filesytem, rather than having a parallel, client filesystem under a different directory (like /opt). The main benefit to this type of arrangement is that the client software base will automatically be updated along with the server, rather than needing to redo an LTSP type arrangement to agree with the server software base. The negative side may be in sharing the root fileystem with a number of other machines. although in a controlled environment this shouldn't be much worse than having user accounts on the server.
[edit] The Components
Several components are required for terminal server to work. First of all, a dhcpd service must be run to assign IPs to the client machines, in conjunction with a tftp server to serve up the boot images. (a combination of kernel and initrd). These services could potentially run on a different box than the terminal-server, but for the sake of this discussion, we'll assume the server machine is providing the services. Finally, nfs must be running on the server machine to share the root filesystem (read-only), as well as the user's home directory and selected other mount points to enable hardware configuration on the client. Terminal-server uses clusternfs, which is a speciallized implementation of nfs that allows unique files to be shared to the client machines, in parallel with the original file on the server, through a special naming convention:
- Server: foo.cfg
- Any Client: foo.cfg$$CLIENT$$
- Specific Client: foo.cfg$$IP=1.2.3.4$$
If one of the special files above exists on the server, the client will see/use that file, rather than the original foo.cfg. This allows things like /etc/modules.conf to be tuned for the needs of each client machine without affecting the server's configuration. This naming convention can also be used for directories.
Installation of the terminal-server meta-package via urpmi will install all the necessary server components. There is a gui configuration tool, drakTermServ that is part of the drakxtools package, that will assist in configuring the server and client machines.
On the client side, etherboot is used to boot the client machine, search for the server and it's boot image and bring the machine up as a diskless client. This can be done via floppy, a ROM image on the network card, using LILO, or several other means. Clients can be either "fat" or "thin". Fat clients run applications locally, using the client machine's RAM/CPU. Thin clients connect to the server machine's X server and login/run applications on the server machine. For older machines with low RAM, slow CPUs, a thin client configuration will be preferred.
[edit] Dhcpd Server
The dhcpd server configuration is similar to a normal configuration, with some special additions to support etherboot, which is the piece that runs on the client machine. It's perhaps easiest to show a common set of configuration files:
/etc/dhcpd.conf:
#dhcpd.conf - generated by drakTermServ
ddns-update-style none;
# Long leases (48 hours)
default-lease-time 172800;
max-lease-time 172800;
# Include Etherboot definitions and defaults
include "/etc/dhcpd.conf.etherboot.include";
# Include Etherboot default kernel version
include "/etc/dhcpd.conf.etherboot.kernel";
# Network-specific section
subnet 192.168.192.0 netmask 255.255.255.0 {
option routers 192.168.192.11;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.192.255;
option domain-name-servers 127.0.0.1, 192.168.192.45, 63.97.221.64;
}
# Include client machine configurations
include "/etc/dhcpd.conf.etherboot.clients";
You will notice several "include" lines. The first one is a rather large file provided by the etherboot package, which defines a number of etherboot specific variables, and also includes another file: /etc/dhcpd.conf.etherboot-pcimap.include. This file is generated when creating net boot images for a given kernel. It maps device ids to kernel modules so that etherboot knows what kernel boot image to ask for. This file is rather large also, but here is a snippet of it's contents:
# Generated from /etc/mknbi-set.conf
if option etherboot.nic-dev-id = 01:12:60:38:73 { option etherboot.kmod "prism2_pci"; }
if option etherboot.nic-dev-id = 01:16:38:11:00 { option etherboot.kmod "prism2_plx"; }
The second include line defines a default kernel version for clients that don't specify a particular boot image:
option bootfile-name = pick-first-value ( concat ( "boot-",
config-option etherboot.kmod, ".2.4.25-2mdk", ".nbi" ), concat
( "boot-", config-option etherboot.kmod, ".nbi") ,"boot.nbi" );
In this example, etherboot will boot either a specific image called for in the client's dhcpd configuration or use the pcimap and the kernel version ".2.4.25-2mdk" to ask for the correct image.
Finally, we have the client configuration file:
host peanut {
hardware ethernet 00:03:B3:02:2A:3A;
fixed-address 192.168.192.44;
#type fat;
filename "boot-pegasus.2.4.25-2mdk.nbi";
#hdw_config true;
}
host moe {
hardware ethernet 00:60:08:95:78:58;
fixed-address 192.168.192.1;
#type fat;
if substring (option vendor-class-identifier, 0, 9) = "PXEClient"
{
filename "3c59x.zimg.pxe";
}
else if substring (option vendor-class-identifier, 0, 9) = "Etherboot"
{
filename "boot-3c59x.2.4.25-2mdk.nbi";
}
#hdw_config false;
}
This file is optional, and could just be an empty file if you want to let etherboot load the appropriate image. Alternately, you can fine tune the setting on a per-client basis. Let's look at the above entries.
For "peanut", we're going to use the boot image boot-pegasus.2.4.25-2mdk.nbi. The machine is being assigned the 192.168.192.44 IP address. client type is defined as "fat", and local hardware config is "true". (These last two are used by the drakTermServ configuration tool. They are comments as far as the dhcpd server is concerned.
For "moe", we've added the option to be able to boot with a PXE image. Some NICs can netboot using PXE. When creating the client configuration, if drakTermServ finds a PXE image that mathces the NIC in /var/lib/tftpboot, the client stanza will be created as is illustrated for "moe" above.
If the client type is defined as "thin", then a special /etc/inittab is created for the client:
/etc/inittab$$IP=192.168.192.2$$
The inittab defines the client to start at runlevel 5, and to use the server's X server, as seen in the last 2 lines of the above file:
# Connect to X server x:5:respawn:/usr/X11R6/bin/X -ac -query 192.168.192.33
[edit] Tftp Server
The dhcpd server passes off requests for the boot image to the tftp server. Images reside in /var/lib/tftpboot, and the server is controlled by xinetd. The configuration file is pretty simple, and drakTermServ takes care of enabling the server:
A typical tftp configuration file (/etc/xinetd.d/tftp) looks like:
service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /var/lib/tftpboot
}
The changes here from the default installation are changing the disable flag to 'no'.
[edit] Clusternfs Server
We've already covered how clusternfs differs from the standard nfs server by using specially suffixed files visible to the clients instead of the server files. The server runs in much the same manner as the stock nfs server. There are 2 daemons, rpc.nfsd and rpc.mountd. They respect entries in /hosts/allow, which drakTermServ takes care of, but if you are manually configuring the server, you need to be aware of this. Here is a typical /etc/hosts.allow:
rpc.nfds: 192.168.192. rpc.mountd: 192.168.192.
The remaining bit is defining the directories to share. This is done is /etc/exports:
#/etc/exports - generated by drakTermServ / 192.168.192.0/255.255.255.0(ro,root_squash) /home 192.168.192.0/255.255.255.0(rw,root_squash) /etc/sysconfig/mouse$$IP=192.168.192.2$$ 192.168.192.2(rw,no_root_squash) /etc/modules.conf$$IP=192.168.192.2$$ 192.168.192.2(rw,no_root_squash) /etc/modules$$IP=192.168.192.2$$ 192.168.192.2(rw,no_root_squash) /etc/X11/XF86Config$$IP=192.168.192.2$$ 192.168.192.2(rw,no_root_squash) /etc/X11/XF86Config-4$$IP=192.168.192.2$$ 192.168.192.2(rw,no_root_squash) /etc/sysconfig/mouse$$IP=192.168.192.44$$ 192.168.192.44(rw,no_root_squash) /etc/modules.conf$$IP=192.168.192.44$$ 192.168.192.44(rw,no_root_squash) /etc/modules$$IP=192.168.192.44$$ 192.168.192.44(rw,no_root_squash) /etc/X11/XF86Config$$IP=192.168.192.44$$ 192.168.192.44(rw,no_root_squash) /etc/X11/XF86Config-4$$IP=192.168.192.44$$ 192.168.192.44(rw,no_root_squash)
The most basic configuration will have only the first 2 lines. The additional lines illustrated above allow one to do hardware configuration for the X server, mouse, and sound on the client machine. Once these items are done, the mount points can be removed. Any changes to the file require you to restart the clusternfs daemon for them to take effect (service clusternfs restart).
[edit] Etherboot
Etherboot enables booting machines over a network. The etherboot image enables the network interface and then searches for a dhcpd server, downloading the net boot image and passing control to the kernel/initrd in that image. It can be initiated from a floppy disk, a ROM on the NIC itself, a PXE image, a DOS .com file, or a lilo entry. rpm -qi etherboot gives specific examples of how to create these various images.
[edit] Client Boot Process
Client machines boot much the same as a normal machine, once etherboot has done it's magic to initiate the process:
Etherboot -> Net boot image -> mount server:/ -> start init
What happens once init starts is dependant on how things are configured on the server side and what special files may be enabled for the client. Normally one would offer the graphical environment, although it's also possible to run the clients with just a console interface at run level 3. (In fact the client will fall back to a console login if X should fail).
Fat Client: The display manager (xdm, gdm, kdm) runs on the client machine, the user logs in and their preferred desktop environment runs. Their home dir is mounted r/w via nfs and they can create/modify files in their home dir, with all software running on the client machine.
Thin Client: X attaches to the display manager running on the server machine. Before the user logs in, init scripts run on the client hardware. Once the user logs in, another X session starts on the server, displaying on the client's monitor. Applications run on the server machine, just as if the user was logged on at the physical server.
[edit] Local Hardware
For fat clients, local hardware access is pretty straightforward. By enabling "local hardware config" in drakTermServ, the special mount points are created to configure X, mouse, sound for the client machine. CDROM and floppy access point to local hardware via the special mountpoints /mnt/cdrom$$CLIENT$$ and /mnt/floppy$$CLIENT$$. /etc/fstab$$CLIENT$$ points to these mount points as well as providing several tmpfs mount points for log files and other transient files that may need to be created on the client:
# /etc/fstab for diskless boot clients # Save this file as /etc/fstab$$CLIENT$$ # $Id: [[TerminalServer]].txt,v 1.8 2006/03/19 08:43:23 dvgeversxs4all.nl Exp apache $ #10.0.0.8:/ / nfs soft,ro,rsize=8192,wsize=8192 0 0 none /proc proc defaults 0 0 none /tmp tmpfs defaults 0 0 none /lib/dev-state tmpfs nosuid 0 0 none /var/lib/gdm tmpfs defaults 0 0 none /var/lib/gnome/desktop tmpfs nodev,nosuid 0 0 none /var/lib/kdm tmpfs defaults 0 0 none /var/lib/xdm tmpfs defaults 0 0 none /var/log tmpfs defaults 0 0 none /var/run tmpfs defaults 0 0 none /var/tmp tmpfs defaults 0 0 none /var/lock/subsys tmpfs defaults 0 0 none /root tmpfs defaults 0 0 none /dev/shm tmpfs defaults 0 0 none /dev/pts devpts mode=0620 0 0 # basic cdrom/floppy mount points - client will be using # /mnt/cdrom$$CLIENT$$, /mnt/floppy$$CLIENT$$ # multiple clients should probably have unique mount points # such as /mnt/cdrom/$$IP=client-ip-address$$ none /mnt/cdrom supermount fs=iso9660,dev=/dev/cdrom,--,codepage=850,iocharset=iso8859-1,ro,nosuid,umask=0,nodev,exec 0 0 none /mnt/floppy supermount fs=vfat,dev=/dev/fd0,--,codepage=850,iocharset=iso8859-1,nosuid,umask=0,unhide,nodev 0 0
For thin clients, there is a package in contrib called terminal-server-localdevices, which enables local hardware access on the client machine.
[edit] Troubleshooting
Problems can come in a number of variations. Since a number of pieces of software all need to work in conjunction with each other, it's important to try and isolate the problem and not get overwhelmed with the interactions.
- Client Boot:
- Does the etherboot image correctly find the NIC?
- Does the client machine get an IP from the dhcpd server?
- Does the client machine get the nbi image from the tftp server?
- Does the client machine successfully mount / via nfs from the server?
If all these succeed, then normally the boot will continue. Any errors should be able to be examined in the client's /var/log. If any of the above fails beyond the first step, you need to look at the server logs. If step 1 fails, you'll need to carefully review what can be seen on the client console.
- Login Problems:
- Does the user attempting to login have an entry in /etc/shadow$$CLIENT$$?
- Client X fails to start:
- The display manager and X should have logs in /var/log/ on either the server (thin client) or client (fat client).
- Client Hardware Configuration:
- Does the root user have an entry in /etc/shadow$$CLIENT$$
- Are the mount points in item 2 exported in /etc/exports?
- Do the special mount points for the client exist?
/etc/sysconfig/mouse$$IP=192.168.192.2$$ 192.168.192.2(rw,no_root_squash)
/etc/modules.conf$$IP=192.168.192.2$$ 192.168.192.2(rw,no_root_squash)
/etc/modules$$IP=192.168.192.2$$ 192.168.192.2(rw,no_root_squash)
/etc/X11/XF86Config$$IP=192.168.192.2$$ 192.168.192.2(rw,no_root_squash)
/etc/X11/XF86Config-4$$IP=192.168.192.2$$ 192.168.192.2(rw,no_root_squash)
[edit] Other Resources
Another user's notes on implementation (Dirk van der Walt): http://peoples.mandriva.com/~sbenedict/terminal-server/term1.sxw
Another user's notes from Bugzilla: The default setup did not work with my dell latitude laptop as a client, because the 3com boot ROM does not support the boot image format. I had to get the utility imggen from www.ltsp.org, which mangles the image so that it can boot.
