Chapter 2. Remote GUI Connectivity

Hacks 10–19: Introduction

Networks are the backbone of most computing today. Even small businesses depend on internal networks of desktop computers and servers to deliver services such as email, file and directory sharing, access to internal and external web servers, and so on. For the system administrator, this means that you typically need to connect to different types of systems during the course of a day to perform different types of administrative tasks.

If your network is composed solely of Linux systems, you can use standard command-line tools such as ssh or telnet to connect to remote systems and get most of your work done, but let’s face it—it’s a graphical world nowadays. There are lots of great administrative tools out there that make it easier to do complex tasks that could easily be derailed by a typo in a long command line. And if you also administer Microsoft Windows or Mac OS X systems, you’ll need access to graphical tools that run on those systems, too.

This chapter primarily consists of hacks that make it easy to establish graphical connections to remote machines from a desktop system, enabling people to run graphical packages that are installed on those remote systems without leaving their chairs. It also provides a hack that tells you how to use Webmin, a centralized, web-based system administration utility that enables you to access multiple server resources from a single system and browser.

The hacks in this chapter aren’t just for system administrators: they’re for anyone who needs to use graphical interfaces on multiple machines. Even if yours is a Linux shop, chances are that your users will occasionally need access to Windows machines to update project plans, requirements documents, spreadsheets, and so on. You could give everyone a Windows system “just in case,” but that isn’t reasonable or cost-effective. Instead, why not just allow users to connect to a remote Windows system or Windows Terminal server on those rare occasions when Windows software is actually necessary? Similarly, if people need to check their personal email while they’re at work, you could configure their mail clients to support additional mail profiles, leave the mail on the server, enter personal passwords, and so on. Many businesses don’t mind this sort of thing, but people may (and should) object to having copies of personal mail and authentication information on machines that aren’t theirs. Using hacks such as “Access Systems Remotely with VNC” [Hack #10] and “Secure VNC Connections with FreeNX” [Hack #17] , people can remotely access their home systems and check mail there. No local copies of personal mail, no local passwords…no problem.

Access Systems Remotely with VNC

Virtual Network Computing is the next best thing to being there—and it’s cross-platform, too.

Command-line-oriented utilities (such as ssh and telnet) for accessing remote systems are fine for many things, but they don’t help much when you need to run graphical utilities on a remote system. You can play around with the standard X Window System DISPLAY environment variable to output programs to different displays, or you can take advantage of cooler, newer technologies such as VNC to display the entire desktop of a remote system in a window on the system on which you’re currently working. This hack explains how to use VNC to do just that. VNC is a cross-platform thin client technology originally developed by Olivetti Research Labs in Cambridge, England, who were later acquired by AT&T. A VNC server runs on a desktop or server system and exports an X Window System desktop that can be accessed by a VNC client running on another system. VNC servers are typically password-protected and maintain their state across accesses from different clients. This makes VNC an optimal environment for accessing a graphical console and running graphical administrative and monitoring applications remotely.

Any host system can run multiple VNC servers, each of which exports a separate desktop environment and therefore maintains separate state. Similarly, multiple clients can connect to and interact with the same VNC server, providing an excellent environment for training, since many users can view the same desktop.

VNC follows the traditional client/server model rather than the X Window System client/server model. A VNC server is actually an X Window System process that exports an X desktop from the system on which it is running, using a virtual framebuffer to maintain state information about the graphical applications running within that server. VNC uses its own Remote Frame Buffer (RFB) protocol to export graphical changes and handle mouse and keyboard events. Though VNC exports a graphical environment, the RFB protocol is highly optimized, minimizing the amount of screen update information that must be passed between client and server.

VNC is released under the General Public License (GPL), and many of the original VNC developers now work for a company called RealVNC (http://www.realvnc.com), which distributes and supports a commercial VNC implementation. Another extremely popular VNC distribution is TightVNC (http://www.tightvnc.com ), a small, even more highly optimized VNC client and server. TightVNC makes better use of network bandwidth, utilizing JPEG compression for the display and differentiating between local cursor movement and cursor movement that needs to be communicated back to the VNC server. TightVNC also features automatic SSH tunneling for security purposes, though any VNC session can be run through an SSH tunnel [Hack #12] . This hack focuses on using TightVNC, although RealVNC is also an excellent choice. Most Linux distributions install one of these VNC implementations as part of their default client/server installations, but you can always obtain the latest version from the appropriate web site.

Understanding the VNC Server Startup Process

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.

Starting Your VNC Server

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.

Warning

When you start a VNC server on a system console or as a privileged user, make sure you have set a VNC password that follows the most stringent rules for password security. Anyone who breaks your password will have instant virtual access to one of your desktops and all applications it contains. This would be paradise for a script-kiddy who might not otherwise know his way around a Linux box.

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

Tip

VNC servers export their virtual displays via ports starting at 5900 plus the number of the display being exported. For example, a VNC server running on the X Window System display:1 will use port 5901, a VNC server running on the X Window System display:2 will use port 5902, and so on. If your system does kernel packet filtering or your network uses a firewall, you must make sure that you do not block ports 590x (used to export VNC server displays), port 6000 (used to communicate with the X Window System server), or ports 580x (if you want to communicate with a VNC server over the Web [Hack #11] ).

Connecting to a VNC Server

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.

Customizing Your VNC Server’s X Window System Environment

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.

The default VNC desktop
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 &

Tip

If directed to do so when you exit, KDE remembers its state across restarts. Figure 2-2 therefore shows two xterms being started—the one from KDE’s saved information about the last time I started it, and the one specified in the VNC startup script.

A VNC desktop using KDE
Figure 2-2. A VNC desktop using KDE

Stopping Your VNC Server

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.

Tip

If your system crashes while running a VNC server or the VNC server itself crashes, you should clean out the files associated with the VNC server in the /tmp and /tmp/.X11-unix directories. For example, if your VNC server was running on display number 1, you would delete the files /tmp/.X1-lock and /tmp/. X11-unix/X1. Doing so ensures that any newly started VNC server will start on the first available X display.

Optimizing VNC Performance

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:

  • Minimize the color depth of the desktop.

  • Eliminate window highlighting when windows get focus.

  • Don’t automatically raise windows when they get focus.

  • Don’t use opaque moves when moving windows. Configure your window manager or desktop environment to move window outlines instead.

Tip

If you stick with twm in your VNC sessions, you can further optimize VNC performance by tweaking its core capabilities to minimize graphical feedback when it’s unneeded. The old AT&T web site for VNC (http://www.uk.research.att.com/archive/vnc/twmideas.html) provides some specific tips for optimizing twm for VNC.

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:

CopyRect (TightVNC only)

Copy Rectangle encoding sends only the location and size of a rectangle on the screen from which data should be copied and the coordinates of its new location.

CoRRE (TightVNC only)

Copy Rise-and-Run-Length Encoding (RRE) is a variation of RRE that uses a maximum of 255 x 255–pixel rectangles. Limiting the number of rectangles to values that can be expressed in a single byte reduces packet size and improves efficiency.

Hextile (both)

Hextile encoding splits the rectangular portion of the screen to be updated into 16 x 16 tiles that are sent in a predetermined order. The data in each tile is encoded in the raw or CoRRE format. Hextile is the preferred choice for remote connections over a high-speed network.

Raw (both)

Sends width x height pixel values with no compression or repeat counts. This encoding mechanism is fastest for local server/viewer connections because there are no bandwidth limitations on local connections, and it requires no special processing. All VNC clients must support this encoding type.

RRE (TightVNC only)

Rise-and-Run-Length Encoding is a two-dimensional version of Run-Length Encoding (RLE) that applies RLE-encoded sequences across different subrectangles. This is extremely efficient when encoding updates consisting of large blocks of the same color.

Tight (TightVNC only)

Tight encoding uses the zlib library to compress the pixel data, but preprocesses data to maximize compression while minimizing processing time. It uses JPEG compression internally to encode color-rich portions of areas to update. This is usually the best choice for modem connections and low-bandwidth network environments.

Zlib (TightVNC only)

Zlib encoding uses the zlib library to compress raw pixel data. This provides good compression at the expense of the local CPU time required to compress the data.

ZRLE (RealVNC only)

Zlib Run-Length Encoding combines RLE with Zlib compression. Sequences of identical pixels within the rectangle to be updated are compressed to a single value and repeat count, and the resulting information is then compressed using Zlib.

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.

Table 2-1. Order of encoding mechanisms used by TightVNC

Remote

Local

CopyRect

1

2

CoRRE

5

6

Hextile

3

4

Raw

7

1

RRE

6

7

Tight

2

3

Zlib

4

5

See Also

Access VNC Servers over the Web

With a little extra software, you can access your VNC servers in any web browser.

If you use VNC often enough, you’ll eventually find yourself needing access to a VNC viewer from a computer on which it has not been installed. You can put a copy of the installer or the installed application on a public share, but manually connecting each time is a pain, especially if you just need to quickly type a command or check status on the remote machine running your VNC server—and always carrying a CD or floppy with the VNC viewer application on it is equally irksome.

Fortunately, the people who designed VNC are smart folks, and they thought of a solution to the roaming user problem—a hassle-free way to make your VNC servers available even if the system you’re using doesn’t have VNC client software installed. All VNC servers include a small built-in web server that can serve the Java classes needed for any Java-enabled browser to connect to the VNC server. This lets you access any VNC session that is already running on one of your systems using any modern, Java-enabled browser. The VNC server listens for HTTP connections on port 5800 plus the number of the display being exported. Therefore, to view a VNC session running on display 1 of the host 64bit.vonhagen.org, you would access the URL http://64bit.vonhagen.org:5801/.

As with any VNC session, the Java classes that implement the VNC client will prompt you for the VNC server’s password before connecting to the VNC server. Figure 2-3 shows a connection to my laptop’s VNC server, on which I am running the Fluxbox window manager (http://fluxbox.sourceforge.net).

A VNC desktop in the Firefox web browser
Figure 2-3. A VNC desktop in the Firefox web browser

Installing Java Classes and Associated Files for the 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.

See Also

Secure VNC via SSH

Easily encrypt your remote connections by setting up a secure tunnel.

VNC is a great way of getting access to a graphical desktop on a remote system. However, once you’re connected, VNC uses standard TCP/IP for all traffic between the local viewer and the remote server. Anyone with a packet sniffer on your local network can grab packets and monitor your traffic, which is a bad thing if you’re using the remote session for administrative tasks that will transmit passwords.

Luckily, it’s quite easy to leverage the encryption provided by SSH, the Secure Shell, in your VNC sessions. You do this by setting up an SSH tunnel, which is essentially just a mapping between local and remote ports so that all traffic to a specified port on a remote machine is forwarded via SSH to a port on your local machine. This hack explains how to combine the power of VNC with the security of SSH to provide secure connections to remote machines. For general information about SSH, see the first volume of Linux Server Hacks by Rob Flickenger (O’Reilly), which devotes an entire chapter to SSH.

Forwarding Remote VNC Ports to Your Current Host

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.

Tip

If you are using the Java VNC viewer [Hack #11] , you will also need to forward the port used by your VNC server’s internal HTTP server. A VNC server’s HTTP server uses port 580x, where x is the X Window System display that a specific VNC server is using. For example, in the previous command, the VNC server was using X Window System display:1, which meant that it was using port 5901 for standard VNC connections. Its web server is therefore using port 5801.

Public or Private VNC Forwarding

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.

Forwarding Ports Without Remote Login

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.

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

Improving Performance with Compression

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.

Optimizing Graphical Updates Between Server and Viewer

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.

Tip

To find out which VNC viewer you’re using (and therefore whether to try tight encoding), you can execute the command vncviewer --help. If you’re using TightVNC, you’ll see a string like TightVNC viewer version 1.2.9 as part of the output of this command. If you’re using an RPM-based Linux system, you can also execute the command: rpm -qf `which vncviewer` to see which package provided the vncviewer command.

See Also

Autostart VNC Servers on Demand

Eliminate the need to manually start VNC servers on remote machines.

In this age of enlightenment and whizzy graphical devices, most Unix servers have graphical consoles instead of the VT100s or LA123s of days gone by. This is certainly true of most Linux servers, though most machine rooms save space by installing a single monitor and using a KVM to switch between the systems that are actually using it at the moment. As explained in “Access Systems Remotely with VNC” [Hack #10] , the traditional mode of operation for VNC is to SSH/telnet/whatever to a remote system, manually start a VNC server, and then nip back to the system you’re actually using and start the VNC viewer there. It’s easy enough—but isn’t the whole “SSH there, stand on one leg, start this, pop back here, start that here” business irritating?

This hack explains how to avoid all that by integrating the VNC X Window System server directly into your graphical X Window System login environment. The basic idea is that you configure your machine to use your system’s Internet daemon ( xinetd or inetd) to start the Xvnc server whenever an incoming VNC connection is sensed on one or more ports. You also configure your system to use the X Display Manager Control Protocol (XDMCP) to manage any new X displays, such as the Xvnc server. When the Xvnc server starts in response to an incoming port request, it displays an XDMCP login screen, you log in, and voilà!

Integrating Xvnc with inetd or xinetd

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:

:8

Specifies the X Window System display on which the Xvnc server should start.

-inetd

Runs the Xvnc server as a daemon and expects it to be run from x/inetd.

-once

Starts the Xvnc server from scratch when a connection is initiated, and terminates the server when the connection terminates. This also blocks multiple copies of the Xvnc server from starting on the same port.

-query localhost

Tells the Xvnc server to query a specific machine for an XDMCP login (more about that in the next section). In this case, the Xvnc server will contact the loopback interface on localhost, which has the IP address 127.0.0.1.

-depth 24

Specifies the color depth of the Xvnc server’s X Window server.

-geometry 1280x1024

Specifies the virtual screen size and resolution at which to start the Xvnc server. Some common values are 800x600, 1024x768, 1280x1024, and 1600x1280. As a general rule, the value you specify should be less than the size of the display on the system you’re using to connect to the Xvnc server, or you may have problems accessing the window controls. You can use odd dimensions like 1000 x 50 to have as large a window as possible on a 1024 x 768 display that fits between graphical elements such as taskbars and sidebars.

-securitytypes=none

Specifies that the Xvnc server shouldn’t use its own internal security mechanism (vncpasswd) to allow access to the VNC server, since XDMCP will handle this for you.

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

-ac

If you’re using TightVNC’s version of Xvnc, you’ll need to use this option instead of -securitytypes=none to avoid using Xvnc’s default access controls. The -securitytypes=none argument is used by RealVNC’s Xvnc.

-fp fontpath

Some versions of Xvnc need to know the font path for the X Window System fonts that they should use. Most modern Linux systems run an X font server by default on port 7100, so an appropriate initial value to try is -fp unix:/7100. If this doesn’t work or you’re not running a font server, you can explicitly list any number of directories as a single, comma-separated argument to the -fp option.

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.

Activating XDMCP

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.

XDMCP activation in gdmsetup
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.

XDCMP configuration in SUSE’s YaST utility
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.

Warning

Updates to the X Window System are a common part of any system update or upgrade. If you have manually modified configuration files, double-check your configuration files after applying updates that modify either X or the desktop environment that you’re using to make sure that XDCMP support is still enabled in your display manager—if it isn’t, this hack will cease to work.

Starting the Viewer

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!

A successful Xvnc connection using XDMCP
Figure 2-7. A successful Xvnc connection using XDMCP

Tip

Because the X Window session running in VNC is using an alternate display, you may need to make sure that you set the DISPLAY environment variable correctly within it in order to start other X Window System applications. For example, if you are running Xvnc on port 5908, you may need to set the display in your shell appropriately using a command such as export DISPLAY=:8.0.

Troubleshooting Xvnc Startup

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!

See Also

Put Your Desktops on a Thin Client Diet

Centralize administration by using the Linux Terminal Server Project and existing or inexpensive desktop systems to give your users the computing power they need at a price you can afford.

Though the cost of hardware is constantly decreasing, it is still greater than zero. Putting a high-powered workstation on everyone’s desk is a nice idea, but not everyone needs a dual-processor Mac or Linux box to get their work done. The key requirement for most users is access to the applications and data they’re working on and enough memory to work with them.

The Linux Terminal Server Project (LTSP; http://www.ltsp.org) lets you boot desktop systems from a remote server, gives users access to their applications and data when they log in, and provides a graphical, X Window System working environment that is functionally identical to booting from a local disk. This can provide substantial cost savings by enabling you to deploy or reuse less-expensive hardware on your users’ desktops, since it reduces the amount of local storage and other hardware that any desktop system requires. A processor that is too slow to keep up with the demands of today’s applications can still function quite nicely when its sole function is to update a display and respond to mouse and keyboard input.

Centralizing system resources on high-powered servers also provides substantial benefits to system administrators by eliminating the need to individually maintain and upgrade desktop operating systems and application software. All the software that a desktop system requires beyond a boot floppy or network boot information is stored on the server.

The LTSP also provides a great alternative to deploying and maintaining dual-boot systems throughout your enterprise or installing X Window System software on every Windows box if users only need to run Linux software occasionally. Give the users LTSP boot disks configured for their desktop systems and have them reboot using these disks. Problem solved! They have Linux systems on their desktops until they reboot.

Tip

Version 4.1 of the LTSP was the latest version at the time this book was written. Installation, configuration, and conceptual information should be similar for any newer version that may exist by the time that you read this.

Understanding the LTSP Client Boot Process

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:

  1. The client boots and contacts a DHCP server to obtain its IP address, the name of the Linux kernel to download and boot, and the NFS location of a directory structure that it should use as the root filesystem for that kernel.

  2. The client contacts the TFTP server on the LTSP kernel and downloads the specified kernel into local memory.

  3. The client boots the downloaded kernel, using the NFS root filesystem as the root filesystem for that kernel.

  4. The client runs the standard Linux startup script /etc/rc.sysinit, which starts various services required by the system, sets up swapping, and so on.

  5. The client uses the information in /etc/lts.conf in the NFS-mounted root filesystem to contact whatever X Window System display manager is running on the specified system and display an X display manager login screen on the client’s screen.

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.

Tip

Though you can use lower-powered systems as LTSP clients, this doesn’t mean that every PC currently serving as a doorstop at your site can be recycled as a desktop LTSP client system. The PCs you use as LTSP clients must have sufficient resources to run the X Window System, use a reasonable screen resolution, display multiple windows that may be graphically complex, and be able to exchange data over the network relatively quickly. Pentium systems running at 166 MHz or greater, with a minimum of 32 MB of memory and a 4-MB video card, are quite suitable for use as LTSP clients. Adding 100-MB Ethernet cards, more memory, and 8-MB or greater video cards will provide a better user experience and will enable you to configure the X Window System to operate at higher resolutions and with greater color depth.

Downloading and Installing the LTSP Software

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!

Configuring and Starting the LTSP Server

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.

The initial screen of the ltspadmin utility
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.

The ltspadmin utility’s Select Packages screen
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.

The ltspcfg utility’s 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.

The ltspcfg utility’s Configuration screen
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:

DHCP

Assigns the client’s IP address and specifies values such as the location of the kernel that the client must download and boot, the path of the NFS root filesystem used by the client’s kernel, and so on. The DHCP server doesn’t need to be running on the LTSP server, but it must be configured correctly wherever it is running to provide the information required by LTSP clients.

NFS

Enables the client to access the root filesystem exported by the LTSP server, use swapfiles that live on the LTSP server over NFS, and so on.

TFTP

Enables the client to download the kernel that it will boot. The TFTP server does not need to be running on the LTSP server, but it must be configured correctly wherever it is running to provide the bootable kernel image required by LTSP clients.

XDMCP

Enables users to log in on the client system and establish an X Window System connection to the LTSP server.

Tip

I find it easier to run all the services required by LTSP clients on the LTSP server, to simplify administrative tasks such as updating the kernel boot image or changing DHCP parameters. The overhead of maintaining special DHCP and TFTP servers on the LTSP server is usually less than that of making updates on multiple systems. However, as discussed in the list above, only NFS and XDMCP must actually be running on the LTSP server.

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:

Runlevel

Set the runlevel at which your LTSP server starts. The LTSP server typically needs to be running at runlevel 5 to enable graphical logins via XDMCP, though the runlevel associated with graphical logins differs across Linux distributions. You can also use runlevel 3 (or whatever your nongraphical, multi-user runlevel is) and manually start the X Window System after each login, but that’s less fun.

Interface selection

Identify the Ethernet interface over which the LTSP server accepts connections. This information is used in setting up the DHCP and NFS services. Some sites use multiple network interface cards (NICs) in their LTSP servers and attach all LTSP clients to a specialized subnet on a dedicated interface to improve performance and minimize the chance of DHCP collisions.

DHCP configuration

Add entries to the DHCP configuration file (/etc/dhcpd.conf) that your LTSP clients require when they get Ethernet addresses from your DHCP server, and make sure that the DHCP server is started by default at the previously specified runlevel. If the DHCP configuration file doesn’t already exist, the ltspcfg utility creates a template configuration file. You must subsequently edit this to reflect your local domain, network configuration, and so on. Here are some examples of the key entries in the DHCP configuration file for LTSP:

	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.

Tip

If you need to provide specific settings for distinct LTSP clients, you can uniquely identify clients by their MAC addresses and provide client-specific configuration information in your DHCP configuration file.

TFTP configuration

Make sure the TFTP server is enabled in /etc/xinetd.d/tftp and the directory where it stores files exists.

Portmapper configuration

Make sure the portmapper, required to map ports to Remote Procedure Call (RPC) services, is running on the LTSP server so that NFS (and, optionally, NIS) services will work correctly.

NFS configuration

Configure the LTSP server to start NFS at boot time if it doesn’t already do so.

XDMCP configuration

Determine which of the available X display managers (gdm, kdm, or xdm) are installed on the LTSP server, and identify the one that is currently used in runlevel 5. This option also adds entries to the configuration file used by that display manager so that it will accept connection requests from remote LTSP clients.

Create /etc/hosts entries

Create entries in the LTSP server’s /etc/hosts for the range of IP addresses used by LTSP clients. Most RPC-based services, such as NFS, need to be able to map an IP address to a hostname and back again. If you are using DNS, you can also add these entries to your DNS server.

Create /etc/hosts.allow entries

Add entries to the /etc/hosts.allow file for the NFS portmapper and TFTP services required by LTSP clients. The /etc/hosts.allow file is used by xinetd’s TCP wrappers to enable access from specified hosts or subnets.

Create /etc/exports entries

Add entries to the /etc/exports file used by NFS to identify directories to export, the hosts that can mount them, and how to mount and access those directories. The entries added by the ltspcfg program identify the NFS-mounted root filesystem used during the LTSP client boot process and the NFS directory that contains swapfiles for LTSP clients.

Create the lts.conf file

Create a default Linux Terminal Server configuration file in etc/lts.conf, relative to the root of your NFS-mounted root filesystem (in other words, relative to the directory named in the root-path directive in your /etc/dhcp.conf file). This file provides initial values that a client uses for local configuration and to connect to the LTSP server, and it enables you to provide client-specific settings when necessary. You may have to modify this file to reflect differences between systems such as graphics resolutions or PS/2, serial, and USB mice. See the LTSP documentation for more information about its possible contents.

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!

Preparing LTSP Client Boot Media

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:

  • Via the Pre-boot Execution Environment (PXE), if supported by your Ethernet card. PXE is limited to booting files that are smaller than 32K (which doesn’t include the Linux kernel), so you’ll have to configure it to load a network bootstrap program (NBP) first, which then loads the kernel. Some network cards or motherboards with onboard networking require the use of specialized PXE bootloaders. LTSP Versions 4.0 and greater provide a PXE bootstrap program known as pxelinux.0. For more information about using pxelinux.0, see http://www.ltsp.org/README.pxe. Another open source PXE bootstrap program often used with LTSP is bpbatch. You can get additional information about bpbatch from its web site (http://www.bpbatch.org) or from http://www.ltsp.org/contrib/bpbatch.txt.

  • Via Etherboot or Netboot, two open source Linux projects for creating boot ROMs that you can plug into any network card that supports a boot ROM.

  • Via floppy disk, by creating an Etherboot image customized for your network card that you write to a floppy and boot from.

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.

Booting an LTSP Client

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.

An LTSP client’s GDM login dialog
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.

See Also

Run Windows over the Network

Stop deploying Windows systems and software for people who only need occasional access to a few applications.

Regardless of how you feel about Microsoft, you can’t escape the Windows operating system and the applications that require it. Even companies that live on Linux for development and testing still need to provide developers with access to Windows systems so that they can share various types of documents with management in formats that management can understand. This quickly gets expensive, and it’s generally a hassle for the system administrators who have to deploy and manage these machines, set up the Windows shares de jour on each computer or in user profiles, install the right software packages, and so on.

Many companies take a first stab at saving money by putting two computers under many desks, and sharing a monitor, keyboard, and mouse between them using a KVM switch. That’s fine, except that your company pays for the extra systems, Windows licenses, and KVM switches and has to deal with the administrative and security hassles inherent in deploying two desktops per user. As an alternative, some companies use the open source WINE project or its commercial variant Crossover Office (which is a great package, by the way), to run Windows applications natively on Linux machines.

If you need to give users occasional access to Windows-only applications but want to minimize costs and administrative hassles, a good solution is to install Windows Terminal Services on a reasonably beefy Windows system and purchase a pool of Client Access Licenses that are assigned to the users who need to be able to use the applications. Remote clients can then attach to the Terminal Services server and run virtual Windows sessions in windows on their desktops. Install the software that people need to use on the Terminal Services server or in shares defined in your user profiles, and any remote users connected to the server will be able to run the software they need. Luckily, access to Windows Terminal Services doesn’t even require a Windows system anymore—Linux users, including those working in an LTSP environment [Hack #14] can easily access Windows Terminal servers using rdesktop, an open source software package that speaks the Remote Desktop Protocol (RDP) used by Windows Terminal Services. This hack shows you how it works.

Opening Your Connection

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.

The Windows Terminal Services login screen in rdesktop
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.

Tip

If you centralize Windows services by running Terminal Services on your domain controller, make sure the users who want to connect to it have the “Log on Locally” user right or belong to a group with that right. Otherwise, users will receive the message “The local policy of this system does not permit you to log on interactively” and be unable to connect.

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:

Table 2-2. 

-d

The domain to which you want to authenticate.

-f

Full-screen mode. This displays the desktop in a decorationless window that takes over your desktop. You can toggle decorations (and therefore window controls) by pressing Ctrl-Alt-Enter.

-p

Your password in the remote domain.

-u

The name of the user that you want to log in as.

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

Mapping Local Devices to Your Remote Session

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.

A print queue mapped by rdesktop
Figure 2-15. A print queue mapped by rdesktop

See Also

Secure, Lightweight X Connections with FreeNX

The standard X Window System is very network-intensive. FreeNX compresses and optimizes X communications and is ideally suited for slow connections such as dialups.

FreeNX is a free, GPL implementation of NoMachine’s NX Server (http://www.nomachine.com). NoMachine has developed a compression technology that substantially reduces the size of X Window System communications and adds other performance improvements through caching and general protocol optimization. NoMachine provides several informative white papers about their technology and its performance at http://www.nomachine.com/documentation.php. If you’re already a VNC fan, NX is definitely worth a look, for performance reasons as well as for the fact that it inherently uses SSH for secure communications between client and server.

The free and commercial versions of the NX server differ in terms of capabilities (and, of course, cost). FreeNX provides all of the core capabilities of the commercial NX server for remote connection, but it does not currently include the SMB and printing (CUPS) support provided by the commercial NX server. At the moment, commercial server licenses for NoMachine’s personal edition cost around 55 euros, which is cheap. They also offer small business and enterprise licenses, which you may be interested in if you want to have product support, get updates, and get SMB and CUPS support now, rather than waiting for them to appear and mature in FreeNX. Personally, though I use FreeNX, I bought a server license because it seemed like the right thing to do. I use the free NoMachine client everywhere, and I also feel that the NoMachine folks deserve my support for having come up with a great technology and released it as open source.

This hack explains how to install and configure the open source versions of NoMachine’s NX server, the FreeNX package, and the free commercial NX client from NoMachine.

Installing the FreeNX Server

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:

Debian

By adding deb http://debian.tu-bs.de/knoppix/nx/slh-debian/ ./to your /etc/apt/sources.list file

Fedora

From http://fedoranews.org/contributors/rick_stout/freenx/

Gentoo

From the Gentoo forums at http://forums.gentoo.org/viewtopic-p-1469066-highlight-nxssh.html#1469066

Knoppix

From http://debian.tu-bs.de/knoppix/nx/ (overlays for the standard NoMachine server overlays)

Red Hat 9

From http://apt.physik.fu-berlin.de/redhat/9/en/i386/RPMS.at-bleeding/ or by adding the appropriate entries to your apt or yum configuration files, as explained at http://atrpms.net/install.html

SUSE 9.2

On the distribution DVD/CDs or from ftp://ftp.suse.com/pub/suse/i386/supplementary/X/NX

Ubuntu

By adding deb http://kanotix.com/files/debian/ ./to your /etc/apt/sources.list file

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.

Installing the NX Client

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!

Tip

SUSE fans can get the knx client from the DVDs/CDs or from ftp://ftp.suse.com/pub/suse/i386/supplementary/X/NX/. You can subscribe to a mailing list about the knx client and FreeNX in general at https://mail.kde.org/mailman/listinfo/freenx-knx.

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.

Configuring and Starting Your NX Client

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.

The initial NX Client configuration dialog
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.

Specifying NX Client protocols and size
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.

Tip

The settings you specify when configuring a NoMachine client are saved in text configuration files in the ~/.nx/config directory, with the name of your NX client and a .conf extension. You can subsequently edit these with a text editor if you decide to modify the existing settings quickly.

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

The optional NX Client Advanced configuration dialog
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.

See Also

A remote FreeNX desktop shown in nxclient
Figure 2-19. A remote FreeNX desktop shown in nxclient

Secure VNC Connections with FreeNX

FreeNX isn’t just for the X Window System—it can also provide secure VNC connections.

If “Secure, Lightweight X Connections with FreeNX” [Hack #16] got you excited about the performance and possibilities of the FreeNX server for displaying X Window System desktops over slow connections, just wait— there’s more! FreeNX also supports translating the protocols used by VNC into X Window System protocols that it can then exchange with a standard NX client. If you install an NX client (such as NoMachine’s excellent nxclient) on your desktop system, you can use a single application to both communicate with remote X Window sessions on your NX server and also proxy through to any VNC server that you can access from the NX server. The VNC server does not have to be running on the same system as the NX server—the NX server just needs to be able to contact it over the network.

Communications between the VNC server and the NX server are not encrypted, but communications between your NX client and the NX server are. This can be especially useful if you are working remotely and want to access a VNC server inside your company’s network, but you need any communication taking place over the public Internet to be secure. Your corporate firewall already supports SSH, so you don’t even need to open any other ports to support VNC.

Creating an NX Client Configuration for VNC

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.

VNC configuration in NX Client
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!

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

See Also

Secure Windows Terminal Connections with FreeNX

FreeNX isn’t just for the X Window System and VNC—it can also provide secure Windows Terminal Services connections.

If “Secure, Lightweight X Connections with FreeNX” [Hack #16] and “Secure VNC Connections with FreeNX” [Hack #17] got you excited about the performance and possibilities of the FreeNX server for displaying X Window System and VNC desktops over slow connections, get ready because FreeNX has even more tricks up its sleeve. FreeNX also supports translating the Remote Desktop Protocol (RDP) used by Windows Terminal Services into X Window System protocols that it can then exchange with a standard NX client. If you install an NX client system (such as NoMachine’s excellent nxclient) on your desktop, you can use a single application to communicate with remote X Window sessions on your NX server, proxy through to any VNC server you can access from the NX server or proxy through to any Windows Terminal server you can access from the NX server. Like the VNC server, the Windows Terminal server does not have to be running on the same system as the NX server— which is just as well, because the NX server used by both FreeNX and NoMachine’s NX runs only on Unix and Linux boxes!

Like VNC through FreeNX, communications between the Windows Terminal server and the NX server are not encrypted, but communications between your NX client and the NX server are. This can be especially useful if you are working remotely and want to access a Windows Terminal server inside your company’s network, but you need any communication taking place over the public Internet to be secure. Your corporate firewall already supports SSH, so you don’t even need to open any other ports to support the Windows Terminal server.

Creating an NX Client Configuration for a Windows Terminal Server

“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!

See Also

Windows Terminal configuration in NX Client
Figure 2-22. Windows Terminal configuration in NX Client

Remote Administration with Webmin

Webmin provides secure access to logfiles, system statistics, and many common administration tasks, all from your favorite web browser.

Administering a system can be a tough job. With user accounts to create, services to configure, logs to check, and all the other duties system administrators face, it can become quite a load. Thankfully, there’s some software out there that can help make life easier for the weary sysadmin. One of these pieces of software is called Webmin. Webmin allows you to control a large portion of the functionality of your server from an easy-to-use web interface. Most major services are covered, including Apache, BIND, SSH, LDAP, Samba, WU-FTP, Sendmail, MySQL, and many others.

A Windows Terminal server connection in nxclient
Figure 2-23. A Windows Terminal server connection in nxclient

Installation

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.

Configure Away!

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.

The default Webmin interface in a web browser
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.

See Also

Brian Warshawsky

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.139.81.254