The actual VNC server binary, Xvnc, is usually started by a Perl script called vncserver. The vncserver script provides a more flexible mechanism for passing arguments to the server, displays status information once the server has started and detached, and also builds in the ability to use a startup script to identify the window manager and any X applications the VNC server should start. The VNC server’s startup script is the file ~/.vnc/xstartup. If this directory and the startup file do not exist the first time you start a VNC server, the directory is created and the startup script is cloned from the default X Window System startup file (/etc/X11/xinit/xinitrc). On Red Hat and Fedora Core systems, the default ~/.vnc/xstartup script simply executes the command script /etc/X11/xinit/xintrc:

	#!/bin/sh
	# Red Hat Linux VNC session startup script
	exec /etc/X11/xinit/xinitrc

This enables VNC on Red Hat and Fedora Core systems to follow the same somewhat convoluted chain of X Window startup files that are normally used: ~/.Xclients, ~/.Xclients-$HOSTNAME$DISPLAY, ~/.Xclients-default, and /etc/X11/xinit/Xclients. Xclient files can start various desktop environments and window managers by using environment variable settings, and they finally fall through to execing the twm window manager (http://www.plig.org/xwinman/vtwm.html).

On SUSE systems, the ~/.vnc/xstartup script is a little more straightforward:

	#!/bin/sh
	xrdb $HOME/.Xresources
	xsetroot -solid grey
	xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
	twm &

This startup script loads the X Window System resource settings specified in the file $HOME/.Xresources, sets the background to solid grey, starts an xterm with the specified parameters, and then starts the twm window manager. Later in this hack, in the section “Customizing Your VNC Server’s X Window System Environment,” I’ll discuss how to customize this script to start the X Window System environment and applications of your choice. For now, it’s simply useful to understand how the VNC server determines what X Window System applications to run.

To start a VNC server you execute the vncserver script, which starts the Xvnc server and the X Window System window manager or desktop and applications defined in your ~/.vnc/xstartup script. The first time you start a VNC server on your system, you will be prompted to set and confirm a password for read/write access to the VNC server. You will also be prompted as to whether you want to set a view-only password for the VNC server. As the name suggests, a view-only password will enable you to see but not interact with the remote desktop displayed in the vncviewer window. The first time you run the vncserver script, you’ll see something like the following:

	$ vncserver
	You will require a password to access your desktops.
	Password:
	Verify:
	Would you like to enter a view-only password (y/n)? n
	New 'X' desktop is 64bit:1
	Starting applications specified in /home/wvh/.vnc/xstartup
	Logfile is /home/wvh/.vnc/64bit:1.log

You’ll notice that I didn’t bother to set a view-only password: I’ve never found this to be all that useful. You can change your VNC password at any time using the vncpasswd command. Like most password-changing utilities, it first prompts you for your old VNC password, then for the new one, and finally asks for confirmation of the new VNC password.

Once you’ve set a password and, optionally, a view-only password, the vncserver script will display a message like the following whenever a server is successfully started:

	New 'X' desktop is home.vonhagen.org:1
	Starting applications specified in /home/wvh/.vnc/xstartup
	Logfile is /home/wvh/.vnc/home.vonhagen.org:1.log

Once you’ve started a VNC server, you can connect to it from any remote system by executing the command vncviewer host:display, where host is the host on which the VNC server is running and display is the number of the X Window System display on which the VNC server is running. Figure 2-1 shows a connection to a remote SUSE system using the default xstartup script shown in the previous section. As you can see, the default VNC server setup is a bit austere, even if you are a window manager bigot or connoisseur of simplicity.

Most VNC server configurations automatically start the twm window manager in the VNC server environment by default. However, the VNC server’s use of a startup script makes it easy to start any window manager, desktop environment, and X Window System applications that you’d prefer to use in the VNC environment.

Figure 2-1. The default VNC desktop

For low-bandwidth conditions, the twm window manager may still be the best choice: due to its comparatively minimal feature set, it is relatively lightweight. In higher-bandwidth network environments, however, you may want to use a window manager or desktop environment that you are more comfortable with. You can easily do this by commenting out the twm entry in your xstartup file and adding the commands that you want to use to start another window manager or a desktop environment such as GNOME or KDE. For example, Figure 2-2 shows a connection to a remote SUSE system when the default xstartup script has been modified to start KDE on that desktop, as in the following:

	#!/bin/sh
	xrdb $HOME/.Xresources
	# xsetroot -solid grey
	xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
	# twm &
	/opt/kde3/bin/startkde &

Figure 2-2. A VNC desktop using KDE

Like any process, a VNC server will always terminate when you shut down or reboot the machine on which it’s running. (No kidding!) However, this isn’t the cleanest shutdown mechanism, because it will leave useless PID files in your ~/.vnc directory and will leave some temporary and socket files in various locations in your system’s /tmp directory. A much cleaner way to shut down a running VNC server process is to use the vncserver script’s -kill option:

	$ vncserver -kill :number

Besides cleanly terminating VNC servers when you’re planning to shut down or reboot your systems, you may also want to manually terminate a VNC server if you have modified its startup file and want to restart the VNC server with the new window manager, desktop, or X Window System applications.

You can optimize VNC performance at two different levels, either by minimizing X Window System updates that have to be communicated between the VNC client and server, or by optimizing how VNC sends that information between the client and the server.

Minimizing the amount of graphical X Window System traffic sent between the VNC client and server is largely a matter of reducing updates to a minimum while still retaining a usable X Window System session. Regardless of the window manager or desktop environment that you’re using in VNC, here are some general tips for improving performance by minimizing graphical updates:

Optimizing the way in which the VNC client and server exchange update information is the other possible way to improve VNC’s performance. VNC clients and servers attempt to communicate using encoded update instructions to minimize network traffic. All graphical updates between the VNC viewer and server are communicated as rectangles of pixels to be updated. The supported encoding mechanisms differ based on whether you’re using the VNC server/viewer from RealVNC or TightVNC. The TightVNC viewer enables you to specify a custom sequence of encoding mechanisms to try in order by using the -encoding option. This option must be followed by a series of supported encodings enclosed within double quotation marks. The RealVNC viewer enables you to specify a single preferred encoding mechanism using the -PreferredEncoding option, which must be followed by the name of the encoding mechanism you want to try first. In either case, the encoding mechanism will default to sending all information in an unencoded fashion (known as raw encoding) if no supported encoding mechanism can be negotiated with the server.

The following list shows the encoding mechanisms supported by the RealVNC and TightVNC packages. Different encoding mechanisms will improve performance in different situations, depending upon conditions such as whether the VNC client and server are running on the same system, the load on your network, and so on. You may want to refer to this section later to experiment with customizing VNC server/viewer communications, depending on your network environment and whether you are actually seeing performance problems. The supported encoding mechanisms are:

Table 2-1 shows the sequence in which a TightVNC viewer tries these different encoding mechanisms when communicating with a remote or local VNC server.

To enable web access to your VNC server(s), you must install the Java class and JAR files, and a few additional files for the HTTP VNC server on the system where you’ll be running it. These files are installed as part of both the RealVNC and TightVNC server packages, but they can also be obtained from the RealVNC and TightVNC web sites (http://www.realvnc.com and http://www.tightvnc.com, respectively) if they aren’t installed on your system for some reason. Where they are installed and how you let the VNC server know about them depends on the version of the VNC server and the associated vncserver script that you’re running.

If you’re running TightVNC, the location where these files are found is specified in the variable $vncClasses in the vncserver script.

You must also make sure that the following line is not commented out of the vncserver script:

	$cmd .= " -httpd $vncClasses";

If you’re running a RealVNC server, the location(s) where these files can be found is specified in the variable $vncJavaFiles in the vncserver script:

	$vncJavaFiles = (((-d "/usr/share/vnc/classes") && "/usr/share/vnc/classes")
	||
			((-d "/usr/local/vnc/classes") && "/usr/local/vnc/classes"));

You must also make sure that the following line is not commented out of the vncserver script:

	$cmd .= " -httpd $vncJavaFiles" if ($vncJavaFiles);

Once you’ve configured the startup script for the Java and other files used by the VNC server, you should restart any VNC server(s) that you’re currently running to ensure that they pick up the files used by the VNC server’s mini-HTTPD daemon.

In addition to the standard secure shell functionality that most people use SSH for, SSH also enables you to forward traffic from a specific port on a remote machine to a specific port on your local machine. Doing this requires that a VNC server is already running on the remote machine, and that you establish a standard SSH connection to the remote machine but supply the –L (local) option and an appropriate argument when you execute the ssh command.

The syntax for forwarding ports when using a standard SSH connection is the following:

	$ ssh -L local-port:local-host:remote-port remote-host

As discussed in “Access Systems Remotely with VNC” [Hack #10] , standard VNC traffic with a given host takes place over port 590x, where x is the X Window System display that a specific VNC server is using. For example, to use SSH to forward VNC traffic from the VNC server running on the X Window System display:1 of the host nld.vonhagen.org to the same port on your local system, home.vonhagen.org, you would execute the following command:

	$ ssh -L 5901:home.vonhagen.org:5901 nld.vonhagen.org

Once this tunnel is created, point your vncviewer at home.vonhagen.org:1 to establish a connection. When you supply the VNC password for the VNC server running on nld.vonhagen.org, a standard VNC window will display on your system—but the connection is secure. You can now type passwords, write love letters, or surf for a new job without anyone being able to sniff out what you’re doing.

Even after forwarding a remote VNC port, the VNC server is still running on its original port on the remote host. Anyone who knows the VNC password to the remote system will still be able to connect to the VNC server normally, without the encryption you’ve set up through your locally forwarded tunnel.

When forwarding ports in SSH, you can refer to your local machine using either its public hostname, which uses its standard IP address, or its loopback name, which maps the remote port to your host’s loopback address. Each approach has its advantages.

Using the loopback address is best for security, because it requires that you be directly connected to your machine in order to access the remote VNC server through your loopback address. No one else can access the VNC server without being connected to your machine, since a loopback address (127.0.0.1) is specific to each host.

On the other hand, you may want to specify your host’s public hostname if you want to be able to access the forwarded VNC from other hosts, or if you want to use a single system as an aggregator for connections to multiple VNC servers. The latter can be useful in enterprise environments where you want encrypted VNC connections but don’t want to set up each one individually on whatever computer you’re currently using. Using a specific system as a VNC aggregator provides the convenience of being able to access multiple VNC servers through a single host while still using the security provided by VNC’s encryption, as shown in Figure 2-4.

Using the standard ssh command and the -L option requires that you actually establish an SSH connection to a remote machine, tying up whatever terminal session you’re using to set up the port forwarding. To start up SSH port forwarding in the background, you can use the ssh command’s -f (fork) and -N (no command) options, as in the following example:

	$ ssh -f -N -L 5901:localhost:5901 nld.vonhagen.org

In this example, unless you’ve used SSH keys to set up passwordless SSH with the host nld.vonhagen.org, you’ll still be prompted for your remote password. Once you enter it, SSH will set up the specified port forwarding and then return control to the local shell, rather than starting up a remote shell and connecting you to it. To terminate SSH port forwarding started in this fashion, you will have to locate and terminate the process using the Linux ps and kill commands or equivalents.

Figure 2-4. Multiple hosts using a single VNC aggregator

Slow connections, such as those via modems and heavily loaded networks, can make using remote graphical applications painful. In these cases, you can optimize the bandwidth required for communicating with your remote VNC server by taking advantage of SSH compression. The ssh command provides a -C (compression) option that uses the same compression algorithms used by gzip to reduce the amount of data that you have to transfer back and forth over whatever wire you’re using. To add compression to your SSH tunnel, just add the -C option to your existing ssh command line. For example, the command in the previous section would become the following to invoke compression:

	$ ssh -C -L 5901:home.vonhagen.org:5901 nld.vonhagen.org

This command compresses all data exchanged between home.vonhagen.org and nld.vonhagen.org over the SSH tunnel.

Compression reduces the amount of data that needs to be exchanged over the tunnel, but it adds some processing overhead on both the client and the server in order to compress and decompress the data being exchanged over the tunnel. Compression may not be a good idea on slow or heavily loaded systems, but it’s almost always a good idea over dialup connections. When using actual network connections, since both system and network load are transient, the only surefire way to gauge the possible benefits of compression is to experiment with using it.

As explained in detail in “Access Systems Remotely with VNC” [Hack #10] , VNC supports a number of different ways to encode graphical update information when exchanging data between a VNC server and viewer. VNC viewers try to negotiate different encoding mechanisms depending on whether they believe that the VNC server is running locally or on a remote machine. Local connections always try to use raw encoding before trying any compressed encoding options. Raw encoding is extremely fast if the VNC server and viewer are running on the same machine, since local bandwidth is effectively infinite, but it’s inefficient when communicating between a remote server and a local viewer.

When using SSH tunneling to redirect a remote VNC server to a local port, you’ll want to override the default encoding settings to make communication between the VNC server and client more efficient, since the server is remote. If you’re using the RealVNC vncviewer, specify the -PreferredEncoding hextile option on the vncviewer command line. If you’re using TightVNC’s vncviewer, you should specify -encodings "copyrect tight hextile" to take advantage of TightVNC’s optimized encoding.

The modern Linux Internet daemon xinetd (like its predecessor inetd, which may still be used somewhere) initiates the daemons associated with various servers in response to incoming requests on different ports, as defined in the file /etc/services. Throughout the rest of this hack, I’ll refer to xinetd and inetd together as x/inetd, using their specific names whenever necessary to differentiate between them.

The x/inetd daemon is often referred to as a “super server,” because its job is to manage other server processes. Using x/inetd lowers the load on your systems, because the daemons for these services don’t have to be running all the time—x/inetd starts them as needed when an incoming request is detected. Using x/inetd also heightens security on your systems by providing what are commonly known as TCP wrappers—a central mechanism for enabling or denying TCP access to a number of services through entries in the files /etc/hosts.allow and /etc/hosts.deny, respectively.

The first step in integrating VNC with x/inetd is to create an appropriate entry for VNC in the text file /etc/services. On new systems that I set up, I decided that automatic VNC sessions would start on port 5908—choosing a value higher than 5900 will prevent collisions when a user manually starts a VNC session on the server using a lower port number. An appropriate /etc/services entry for automatically starting VNC in response to incoming requests on port 5908 is the following:

	vnc		5908/tcp		# Xvnc

Once you’ve created this entry in /etc/services, you must next define what happens in response to an incoming request on this port.

If you’re using xinetd, you must create the file /etc/xinetd.d/vnc, which contains various settings for how xinetd should respond to incoming requests, which application it should start, and so on. Here’s a sample /etc/xinetd.d/vnc file:

	# default: on
	# description: The vnc server provides remote desktop connections
	#
	service vnc
	{
		disable			 = no
		socket_type		 = stream
		protocol		 = tcp
		wait			 = no 
		user			 = nobody
		server			 = /usr/bin/Xvnc
		server_args		 = :8 -inetd -once -query localhost -depth 24 
				-geometry 1280x1024 -securitytypes=none
	}

The server_args entry should be on a single line, but I’ve broken it into two in this example for readability. The arguments that you specify to the Xvnc server are highly dependent on the version and source of the Xvnc server that you’re running. The arguments shown in the previous example mean the following:

Depending on the version of Xvnc that’s installed on your system, you may need other or additional options:

If you’re still using inetd, the equivalent of the /etc/xinetd.d/vnc file is a single entry in the file /etc/inetd.conf. Here’s an example entry that matches the previous xinetd example:

	vnc stream tcp nowait nobody /usr/sbin/tcpd /usr/bin/Xvnc :8 -inetd 
		-once -query localhost -depth 24 -geometry 1280x1024 
		-securitytypes=none

As with the server_args entry in the xinetd example, this should all appear on a single line in your /etc/inetd.conf file—I’ve only broken it across multiple lines here for readability. The same caveats about possible alternate/extra arguments apply to an /etc/inetd.conf entry.

XDMCP is a network protocol used for initiating login sessions on X Window System display devices. Originally developed in 1989, XDMCP is primarily associated with X terminals [Hack #14] ), but it can be used with any X Window System device—such as, in this case, the X server started by Xvnc.

Most systems that come up in graphics mode use an X Window System display manager to provide a graphical login and subsequently start the window manager or desktop environment of your choice. Graphics mode is usually runlevel 5 for most Linux systems, or any of runlevels 2 through 5 if you’re a Debian or Ubuntu fan. By default, the X display manager manages the X Window System device associated with the console, but it is optionally responsible for responding to XDMCP requests and initiating the appropriate X Window System login sessions on new X Window System devices. XDMCP support is a configuration option for all X display managers, but it is usually disabled by default since most display managers only need to support X login sessions on their consoles.

How you activate XDMCP support depends on which display manager you’re using, which is usually determined by the default desktop system used on your Linux system. GNOME uses a display manager called gdm, usually found in /usr/bin/gdm (which calls /usr/bin/gdm-binary) or in /opt/gnome/bin/gdm on KDE-based systems such as SUSE. KDE uses one called kdm, usually found in /opt/kde3/bin/kdm. The classic X Window display manager, often used on systems where neither GNOME nor KDE is installed, is xdm, and it is usually found in /usr/X11R6/bin/xdm. If you are running Red Hat Linux, you can check the script /etc/X11/prefdm to see how your system selects its default display manager and which one it is. You can also figure out which display manager your system is actually running by looking for the string dm in a system process listing, as in the following example:

	$ ps -ef | grep dm
	root	5137	 1	 0	May25 ?		  00:00:00 /opt/kde3/bin/kdm
	root	5167  5137  65	May25 ?		 3-01:52:35 /usr/X11R6/bin/X 
		-br vt7 -auth /var/lib/xdm/authdir/authfiles/A:0-K7ItZv
	wvh		29664 24116	 0	13:42 pts/11 00:00:00 grep -i dm

In this case, the system is running kdm as its display manager, so you’ll have to correctly configure kdm to support XDMCP. Needless to say, each of these X Window System display managers has its own configuration file, in which you must enable XDMCP so that when Xvnc queries the localhost, the local display manager will initiate an X login session.

If the system on which you are configuring Xvnc runs gdm, the GNOME desktop provides a convenient application called gdmsetup for configuring gdm. Start gdmsetup as root or by using sudo, select the XDMCP tab, and select Enable XDMCP to activate XDMCP support in gdm the next time you restart the X Window System. Figure 2-5 shows this tab selected in gdmsetup, with XDMCP enabled.

Figure 2-5. XDMCP activation in gdmsetup

You can also manually modify the gdm configuration file as an alternative to running gdmsetup. On many Linux systems, this configuration file is /etc/X11/gdm/gdm.conf.

If the system on which you are configuring Xvnc runs kdm, you can either use the administrative utilities provided by your system or manually modify the kdm and system configuration files that control its behavior. For example, on SUSE systems, you can use the YaST administrative modules from the Control Center (Control Center → YaST2 modules → Network Devices → Remote Administration) to activate remote access to the display manager. Figure 2-6 shows this panel in the Control Center.

If you’d prefer to tweak the configuration files yourself, you can modify the primary kdm configuration file (/opt/kde3/share/config/kdm/kdmrc) with a text editor, changing the Enable entry in the [xdmcp] section to true and making sure that the Port=177 entry is not commented out. You will also have to modify the file /etc/sysconfig/displaymanager, setting the DISPLAYMANAGER_REMOTE_ACCESS variable to yes. You can then run /sbin/SuSEconfig to cause SUSE to perform the correct internal updates.

Figure 2-6. XDCMP configuration in SUSE’s YaST utility

Once you have modified your display manager to support XDMCP, you will need to restart the display manager with the correct settings. The easiest way to ensure a complete restart is to reboot your system, but if you are running critical services on that system, you can also use the telinit or init commands to take your system to a nongraphical runlevel (telinit number-of-runlevel or init number-of-runlevel) and then return to a graphical runlevel, such as runlevel 2 for Debian-based distributions or runlevel 3 for most others. You can then use telinit to return to runlevel 5. Some flavors of Linux provide scripts (such as SUSE’s rcxdm restart command) that will automatically terminate the X Window System and restart the display manager for you without switching runlevels.

Once you’ve set up your system to initiate Xvnc in response to incoming requests and have configured your display manager to respond to XDMCP requests, go to another system and start your favorite VNC viewer application, pointing to a port that you specified in /etc/xinet.d/vnc. After a few moments, you should see something like Figure 2-7. Congratulations—initiating VNC sessions to your host(s) is now easier than ever before, and you no longer have to start VNC manually on those systems like an electronic catcher’s mitt to service incoming VNC requests!

Figure 2-7. A successful Xvnc connection using XDMCP

If you’re lucky, you’re already looking at Figure 2-7 and thinking “problems— what problems?” However, if your vncviewer simply hangs or terminates with information-packed messages such as “vncviewer: ConnectToTcpAddr: connect: Connection refused” or “Unable to connect to VNC server,” don’t despair. These problems are easily resolved.

If your vncviewer connection to the remote machine simply hangs—i.e., you press Return and nothing happens—chances are that the ports associated with your VNC setup are being firewalled on the remote machine, the local machine, or somewhere in between. Check to make sure that whatever ports you put in /etc/services on the remote system are actually available and that a process is listening on the XDMCP port. An easy way to do this is by executing the netstat -an command and filtering its output for port 177, the port used by XDMCP, as in the following example:

	$ netstat -an | grep 177
	udp			  0		 0 :::177				:::*

If you do not see any output from this command, make sure you have correctly configured XDMCP support in your display manager and that the Xvnc entries in /etc/xinetd.d/vnc are not disabled. Worst-case, you can reboot your system to make sure everything starts up correctly.

If you still can’t establish a VNC connection to your system, make sure no firewall rules are blocking any of the ports used by XDMCP or Xvnc. An easy (but completely insecure) way to do this is to temporarily terminate your firewalls or punt all your active rules using a command such as iptables -F. First try this on the system that you are trying to connect to; then, if you still can’t connect, try it on the system you are trying to connect from. If you can connect successfully after disabling the firewall, review your system’s firewall configuration and relax the appropriate rules to enable remote VNC connections. Remember to reactivate your firewalls after reconfiguring them—you don’t want the entire seventh-grade class of PS150 in Seoul to be able to try getting graphical logins on your machine!

In case the notion of systems booting and getting all their software over a network is new to you, this section provides an overview of the boot process for an LTSP client system. Being able to visualize how LTSP clients and servers interact will minimize configuration problems and will also be useful if you need to diagnose performance or connectivity problems in the future.

LTSP client and servers interact in the following way when you boot an LTSP client:

Once you log in, you are logged in on the LTSP server system. The client system is running only the X Window System software necessary to manage network connections, run an X Window System server, and so on.

You can download the LTSP administrative and configuration utilities as a tarball with an installer (http://www.ltsp.org/ltsp-utils-0.11.tgz) or as an RPM (http://www.ltsp.org/ltsp-utils-0.11-0.noarch.rpm). You can also download the latest LTSP software by following the download link from its Sourceforge project site at http://sourceforge.net/projects/lts/.

As part of the initial configuration process, the LTSP administration utility downloads additional packages that the LTSP server(s) and clients require. These additional packages provide the kernel, X Window System utilities, and other components of the root filesystem used when LTSP clients boot from the server in order to start their X sessions. During the LTSP configuration process, you can either download these additional packages over the network or load them from a local CD-ROM or directory that provides them. To save time during the installation process and simplify installation in general, you should download an ISO image of a CD-ROM that contains all of these packages from http://ltsp.mirrors.tds.net/pub/ltsp/isos/ltsp-4.1-1.iso.

If you’ve downloaded a tarball of the LTSP utilities, unpack it and execute the install.sh script to install the utilities on the system that you want to be your LTSP server. If you’ve downloaded the RPM, simply install it with your favorite RPM invocation. Mine is:

	# rpm -Uvvh ltsp-utils-0.11-0.noarch.rpm

If you’ve download the ISO of the packages required by the LTSP server, burn it to a CD-ROM and mount the CD-ROM (or mount the ISO using a loopback device if you’re in a hurry or don’t have a CD burner handy). Now the real fun begins!

To actually install the packages that an LTSP server needs and create your default LTSP configuration file, su to root (use su - to provide a pristine root environment) and execute the ltspadmin command. This command provides a terminal-oriented interface that enables you to install the packages and configure the system services required by required by an LTSP server. Figure 2-8 shows the ltspadmin utility’s initial screen in an xterm.

Figure 2-8. The initial screen of the ltspadmin utility

The first step in configuring an LTSP server is to configure the installer itself. Use the arrow keys to select the “Configure the installer options” menu option. The installer prompts you for the location from which to retrieve the packages required by the installer, providing a network source by default. If you’ve installed them locally, supply the pathname to the directory containing the packages in the form of a URL that begins with file://, followed by the full pathname. (This means that your URL must begin with three slashes: two for the protocol specification and one for the beginning of the path to the directory containing the packages. For example, if you burned a CD-ROM and mounted it as /mnt/cdrom, your URL would be file:///mnt/cdrom.)

Next, you’ll be prompted for the directory in which you want to install these packages on your server. You’ll need to have about 350 MB free on the partition where this directory is located in order to do a complete install of all the LTSP software.

Finally, identify any HTTP or FTP proxies you want to use (or specify none), and then enter y to accept the values that you’ve entered. The screen shown in Figure 2-8 will be displayed again.

The next step is to select the Install/Update LTSP Packages option, which displays the screen shown in Figure 2-9.

Figure 2-9. The ltspadmin utility’s Select Packages screen

Press A to select all the packages listed, and press Q to exit this screen and begin installing those packages. You’ll have to answer y to an “are you really, really sure” prompt, and then package installation to the specified directory will begin.

Once all the packages are installed, press Enter and select the Configure LTSP option. This starts the ltspcfg utility and begins LTSP configuration. ltspcfg first checks and summarizes the status of all the services that LTSP requires on your server. Press Enter to continue, and you’ll see two options: S to summarize the status of required services of your LTSP server, and C to actually configure them. Figure 2-10 shows the summary screen.

Figure 2-10. The ltspcfg utility’s Summary screen

Selecting C displays the screen shown in Figure 2-11, which lists the various aspects of the LTSP server that have to be configured for the terminal server.

Figure 2-11. The ltspcfg utility’s Configuration screen

An LTSP server must provide or have access to the following services in order to function correctly:

We’re all sysadmins here, so rather than walking through each step and listing each keypress, I’ll just highlight the services that you have to activate and the types of values that you need to enter:

	option routers				192.168.6.32;
	option domain-name-servers	192.168.6.32;
	option domain-name			"vonhagen.org";
	option root-path			"192.168.6.32:/opt2/ltsp-4.1/i386";
	subnet 192.168.6.0 netmask 255.255.255.0 {
		use-host-decl-names   on;
		option log-servers	  192.168.6.32;
		range 192.168.6.100 192.168.6.120;
		filename			  "/lts/vmlinuz-2.4.26-ltsp-2";
	}

“Quick and Easy DHCP Setup” [Hack #20] has more detailed information about setting up DHCP and all the entries in the /etc/dhcpd.conf file.

At this point, you should reboot your LTSP server and verify that all the mandatory services have started automatically (DHCP, portmapper, NFS, and an X display manager) and that other mandatory services such as TFTP are enabled. Almost there!

Once the LTSP server is configured, the next step is to figure out how you want to boot your clients. There are a variety of ways of booting LTSP clients:

Of these, the most common and easiest to start with is booting from floppy. You simply write the customized Etherboot image to a floppy and then ensure that the client system is configured to boot from its floppy disk drive first. The client boots the image on the floppy, which initializes your client’s network interface, then sends out a DHCP request and uses the boot-file and root-path images to download the kernel and boot using the specified root filesystem.

Creating an Etherboot image customized for your client’s network card would be completely outside the scope of this hack if it weren’t for the amazing ROM-O-Matic web site (http://www.rom-o-matic.net)—simply identify your network card, and the web site will generate a boot image for you and download it to your system. It doesn’t get much easier than that!

To create the right ROM image, you need to know the exact PCI ID of your network card. If you’re not sure which card you have, the easiest thing to do is to boot your client using a rescue disk [Hack #90] or other bootable CD (the Knoppix Live CD included with Knoppix Hacks, also from O’Reilly, is a personal favorite). After logging in, you can run the lspci command to identify your Ethernet card and then run the lspci -n command to display the PCI identifiers (two four-digit, colon-separated numbers) for your card. You can then match these against the versions of your card listed on the ROM-O-Matic site, click Get ROM, and save the ROM image to your system. You can then write it to a floppy disk using a command like the following (as root):

	# cat ROM-filename > /dev/fd0

You’re now seconds away from turning an old PC into a useful X terminal.

Before booting your LTSP client, make sure that all the services required by the LTSP server are running on the server, and that the client is configured to boot from its floppy disk first.

Drumroll, please! Insert the floppy disk in the client’s floppy drive and power on the system. After the generic POST messages, you should see a message about loading the ROM image, followed by some Ethernet configuration information and the message “(N)etwork Boot or (Q)uit.” Press N, and your system will download and boot the Linux kernel from your LTSP server. After the standard Linux boot messages, you will see a screen that displays the login dialog shown in Figure 2-12.

Figure 2-12. An LTSP client’s GDM login dialog

Congratulations—your doorstop is now a useful X terminal!

Once you have an LTSP server configured and set up, the only thing you have to do to create additional client systems is to generate ROM images for the appropriate Ethernet cards, put each on a floppy, and boot the new client with an appropriate boot floppy. This is especially easy if you tend to buy your PCs in batches or from a single vendor—chances are that many of them will have the same Ethernet cards and can use the same boot floppies.

Because rdesktop is a graphical application, you must execute it from a Linux system that is running the X Window System. This hack discusses options that are found only in more recent versions of rdesktop, which was at Version 1.4.0 when this book was written. Though it’s found on many Linux distributions, you can always get the latest and greatest version of rdesktop from the sites listed at the end of this hack.

The most minimal command line that you can use to connect to a system running Windows Terminal Services is rdesktop host, where host is the name or IP address of the system running Windows Terminal Services. Once connected, a window displaying the standard Windows login screen appears on your Linux desktop, as shown in Figure 2-13.

Figure 2-13. The Windows Terminal Services login screen in rdesktop

After you log in and specify the domain that you want to log into (if necessary), your rdesktop window will display the standard Windows desktop, as shown in Figure 2-14.

Like most programs, rdesktop provides a number of options that can simplify access to Windows Terminal Services. Though they’re all on the manpage, I’ll go through my favorites here:

Figure 2-14. A successful Windows Terminal Services login in rdesktop

If the system running Windows Terminal Services is running Microsoft Windows XP, Windows Server 2003, or any newer version of Windows, one especially cool option not listed in the previous section is the -r option, which lets you directly map resources on your Linux system to your Windows Terminal Services connection. This is useful when you want to map a local print queue to a virtual printer in your Windows Terminal session or access a local drive in your Terminal session (using -r printer :local-queue-name and -r disk:share-name=/device/path, respectively). For example, to attach PRN1 to a local print queue named Silentwriter, you would add -r printer:Silentwriter to your command-line options when executing the rdesktop command. Figure 2-15 shows how your local print queue shows up in a generic Windows print dialog.

To map your local CD-ROM drive to a share called cdrom, you could add -r disk:cdrom=/dev/cdrom to the rdesktop command line. If you still use floppies, you could map your local floppy drive to a share called floppy by adding -r disk:floppy=/dev/fd0 to your rdesktop command line. The name that you specify as the share must be eight characters or less.

Figure 2-15. A print queue mapped by rdesktop

The FreeNX server consists of two packages: the nx package, which consists of binaries and libraries compiled from the open source packages from NoMachine; and the freenx package, which is a set of client scripts that invoke the NX binaries in the right ways. Depending on the Linux distribution that your server is running, you can obtain these packages from different locations:

If you’re using a distribution that isn’t listed in the previous section, or you have a policy of installing nothing on your server without having the source code, you can build the GPL version of the NoMachine NX server from scratch in several ways: retrieve the source code from http://www.nomachine.com/download/snapshot/nxsources using wget -r and then follow the instructions at http://fedoranews.org/contributors/rick_stout/freenx/freenx.txt, or download the source RPM from one of the distributions listed above (SUSE’s SRPM for the open source NX server is at ftp://ftp.suse.com/pub/suse/i386/supplementary/X/NX/NX-1.4.0-12.1.nosrc.rpm), install it using rpm or extract its contents into a tarball using alien, and then follow the instructions in the nx.spec file to see how to build it yourself. I prefer the latter approach, since the source includes any mandatory patches to build the official RPMs for SUSE, which is my desktop/server distribution of choice.

As good open source citizens, NoMachine provides a document about building the open source portions of the NX products in the Documentation center at http://www.nomachine.com/documentation/pdf/building-components.pdf.

If you manually downloaded RPMs, install them in the standard fashion, as in the following example (from a Red Hat 9 system):

	# rpm -Uvvh nx-1.4.0-4.1.rh9.at.i386.rpm
	# rpm -Uvvh freenx-0.3.1-0.1.rh9.at.noarch.rpm

Next, use the nxsetup application to do the initial configuration of your NX server by specifying the --install option, as shown below:

	# /usr/bin/nxsetup --install
	Setting up /etc/nxserver …done
	Setting up /var/lib/nxserver/db …done
	Setting up /var/log/nxserver.log …done
	Setting up known_hosts and authorized_keys2 …done
	Setting up permissions …done
	Ok, nxserver is ready.
	PAM authentication enabled:
		All users will be able to login with their normal passwords.
		PAM authentication will be done through SSH.
		Please ensure that SSHD on localhost accepts password authentication.
		You can change this behaviour in the file.
	Have Fun!

This step creates the nx user in the server’s /etc/passwd file and sets up the files, directories, and keys used by FreeNX.

Next, add any users that you want to be able to use the NX server to its user database and set their passwords, as in the following example:

	# nxserver --adduser wvh
	NX> 100 NXSERVER - Version 1.4.0-03 OS (GPL)
	NX> 1000 NXNODE - Version 1.4.0-03 OS (GPL)
	NX> 716 Public key added to /home/wvh/.ssh/authorized_keys2
	NX> 1001 Bye.
	NX> 999 Bye
	# nxserver --passwd wvh
	NX> 100 NXSERVER - Version 1.4.0-03 OS (GPL)
	New password:
	Password changed.
	NX> 999 Bye

Now you’re ready to install and configure the NX client on any systems from which you want to access the FreeNX server.

NoMachine’s free NX clients for various Linux distributions, various flavors of Microsoft Windows, Apple’s Mac OS X, and even Sun’s Solaris are available from http://www.nomachine.com/download.php. The name of the NoMachine client binary is, surprisingly enough, nxclient. Though a free NX client for the KDE environment (called knx) is actively under development, the NoMachine NX clients are nicely done, work fine, and are free. You’ll have to put up with seeing NoMachine’s logo each time you start one up, but that’s a small price to pay—and it’s a cool logo!

If you’ve downloaded the RPM for the NoMachine NX client, you can install it using a standard RPM invocation such as:

	# rpm –Uvvh rh9-nxclient-1.4.0-91.i386.rpm

Note that the version of the file that you’ve downloaded, and therefore its name, may have changed by the time you read this.

After downloading and installing the client on a desktop system, you’ll need to copy the FreeNX server’s key to your client installation. This key is located in the file /var/lib/nxserver/home/.ssh/client.id_dsa.key on a Linux FreeNX server, and it should be copied to the file /usr/NX/share/client.id_dsa.key on any Linux system where you’ve installed the NoMachine client. You must also make this file readable by mere mortals, so chmod it to 644. Windows client users should copy this file to the directory C:Program FilesNX Client for Windowsshare.

NX client and server applications are installed in /usr/bin, which is probably already in your path, so no path munging is required to start an NX client. NoMachine’s NX client enables you to create configuration files that specify parameters with which the nxclient application can be invoked. To create a configuration file, execute the following command:

	$ nxclient --wizard

A friendly but content-free dialog displays. Click Next, and the dialog shown in Figure 2-16 displays. Enter a logical name for the connection in the Session text box, and specify the hostname or IP address of the NX server in the Host text box. You can then modify the slider settings to specify the type of network/Internet connection you’re using, so that the NX client will select appropriate compression and optimization settings for your connection speed.

Figure 2-16. The initial NX Client configuration dialog

When you click Next, the dialog shown in Figure 2-17 displays. For standard X connections to a remote Linux or Unix server, leave the system type set to Unix, and click the KDE drop-down to select the type of desktop that you’d like the NX server to start for you. Next, click the Available Area drop-down and select the size of the remote desktop that you’d like to create. I tend to select 1024 x 768 because that’s always smaller than the size of my desktop machine’s monitor. Using the default Available Area setting is a better choice if you’re using the NX client on a laptop that may or may not be connected to an external monitor.

Figure 2-17. Specifying NX Client protocols and size

This dialog also enables you to provide an additional level of security by enabling SSL encryption. This encrypts all traffic between the client and the server, including your initial password exchange.

When you click Next, a final dialog displays that enables you to create a desktop shortcut or open the Advanced Configuration dialog, shown in Figure 2-18. The tabs in this dialog enable you to further optimize connections between your client and the FreeNX server, customize the paths to various files on your system, and so on.

Once you’ve created a configuration, the standard NX Client dialog displays. Enter your password for the NX server, and the fun begins. The NX client authenticates to the remote NX server, negotiates connection parameters, and then displays a window in which a remote desktop session starts. You also get to see the NoMachine logo for a few seconds, which reminds you who should be thanked for this way-cool technology! Figure 2-19 shows a remote Linux desktop connection to a Red Hat 9 system running the GNOME desktop

Figure 2-18. The optional NX Client Advanced configuration dialog

To terminate your NX client session, simply close the window as you would any other application. Like VNC connections, NX client connections can be suspended rather than simply terminated, so you’ll see a dialog that asks if you want to suspend the session, terminate the session, or cancel the termination request. If you select Suspend, your existing connection to the remote NX server will be renewed the next time you start NX Client with the current configuration.

The previous hack explained how to obtain and install NoMachine’s excellent NX client. To create a configuration for accessing VNC through your NX client, click the Unix drop-down shown in Figure 2-17, and select VNC. The dialog shown in Figure 2-20 will display.

Figure 2-20. VNC configuration in NX Client

In this dialog, specify the hostname or IP address of the system on which your VNC server is running, and the port on which it is running. By default, the port will be 5900 plus the number of the display that the VNC server is using. For example, if the VNC server was running on display:1 on the remote system, you would enter 5901 as the port number.

Next, specify the password for the remote VNC server, and check the “Remember my password” checkbox if you want to make this a permanent part of your configuration. Click OK to close this dialog, proceed with your standard NX client configuration and save your NX/VNC configuration.

When you start nxclient with that configuration, you’ll see a screen like the one shown in Figure 2-21—congratulations, you’re securely connected!

Figure 2-21. A remote VNC session in NX Client

“Secure VNC Connections with FreeNX” [Hack #17] explained how to obtain and install NoMachine’s excellent NX client. To create a configuration for accessing a Windows Terminal server through your NX client, click the Unix drop-down shown in previously in Figure 2-17, and select RDP. The dialog shown in Figure 2-22 will display.

In this dialog, specify the hostname or IP address of your Windows Terminal server, whether you want to use existing credentials to auto-login or see the standard Windows login screen, and whether you want to run a specific application or the standard Windows desktop.

Click OK to close this dialog, proceed with your standard NX client configuration, and save your NX/Windows Terminal configuration. When you start nxclient with that configuration, you’ll see a screen like the one shown in Figure 2-23. Congratulations—you’re securely connected!

Installation of Webmin couldn’t be easier. If you’re running an RPM-based distribution such as SUSE or Fedora Core, simply grab the latest version from the Webmin home page at http://www.webmin.com. Install Webmin with the following command, where version-number is the version that you downloaded:

	# rpm –install Webmin-version-number.rpm

If you’re using a non-RPM-based distribution such as Debian or Slackware, you can install from source. Simply download the latest tarball from http://www.webmin.com and unpack it to your system as usual. Navigate into the newly created Webmin directory, and execute the following command as root:

	# ./setup.sh /usr/local/Webmin

This will start the setup process for Webmin. The script will ask you for a number of options. For most of these questions, the default answers should suffice. However, there are a few answers that should be changed for security reasons. For instance, it is widely known that the default port for Webmin is 10000, so when the script asks you what port to run it on, pick something original—just make sure that you pick something above port 1024, because port numbers lower than that are typically reserved for system services. I typically use port 5555. Changing the default port helps protect against automated tools probing Webmin and discovering your Webmin login by checking its default port.

Also, choose a default username other than admin and definitely specify a password. If you don’t, the password will be left blank and anyone who wants to log in will be able to do so. You should also make sure that you choose to use SSL for encryption. The setup script will only ask you this if you have the SSL libraries for Perl installed, so make sure they’re loaded before you begin. Without them, all the information transmitted back and forth between you and Webmin will be transmitted in clear text, including passwords and other valuable system information.

The final question the script will ask you is if you want Webmin running at boot time. This is largely a matter of personal preference. I tend to say no and simply SSH in and start Webmin whenever I need it, which allows it to stay off the radar when it’s not in use; however, your mileage may vary and you should use your own judgment here. If you’ll be using it in a trusted environment or don’t mind the limited risk of leaving it on all the time, answer yes, and the script will configure Webmin to start automatically.

That’s it! You now have a fully functional Webmin interface running on your server. You can access it by logging into https://localhost:5555, where 5555 is the port you specified during the setup. If you installed via rpm, the default port of 10000 was used. Log in with the username and password you specified earlier—you should see something similar to Figure 2-24—and have a look around.

Figure 2-24. The default Webmin interface in a web browser

As you can see, the Webmin interface has several sections, including System, Networking, Servers, Hardware, and Cluster. Each of these tabs contains options related to its title. If you’d like to change the IP address of your server, for instance, select Networking, then Interfaces. Click on the name of the interface you want to change, and enter your new IP address. You can add new users, manage your logfiles, configure DNS and Apache, and perform a whole host of other administrative functions with the same ease we’ve just demonstrated.

The Servers tab is another area where Webmin shines, and this is where the true capabilities of Webmin can be seen. Under the Servers tab, you can see the full list of applications that Webmin supports by default. We’ve already mentioned quite a few, but let’s take a moment to explore Webmin’s capabilities. Clicking the Apache icon will show you many of the options that are available to you. For this example, let’s suppose we want to add a virtual host to Apache. Normally, this would require manually editing httpd.conf, followed by a restart of the Apache service. With Webmin, we can do all this with a few simple clicks. The bottom of the configure page for Apache has the options for creating a virtual server—all you have to do is fill in the blanks and click Create Now. Everything will be done for you, including restarting Apache to pick up the new virtual server from the configuration file, without ever having to fire up emacs or vi.

As you can see, Webmin provides numerous options and capabilities. Webmin even makes it easy for developers to write their own modules to use with it, allowing its capabilities to be expanded and extended by the community. Webmin can be a lifesaver when you need to install or work with complicated tools such as Sendmail or DNS in a hurry. It also simplifies managing clustered or high-availability servers. No matter how you look at it, there’s no denying the usefulness of such a versatile administration tool.

—Brian Warshawsky