Text-mode logins, as described in Chapter 10, can be handy tools for using or administering a Linux system remotely; however, they’re rather limited. Many programs—particularly user-friendly tools to perform common tasks such as word processing—require the use of a graphical user interface (GUI). Such tools can’t be used via a text-mode login alone, although as this chapter describes, using such a tool can be part of an overall remote GUI access plan. If you want to run GUI word processors, web browsers, graphics editors, and other programs remotely, you must use remote GUI access tools. These tools are most important as user access tools because most users today expect GUI environments. They can help provide relatively seamless access to multiple systems from a single keyboard and screen, or they can be part of a thin client configuration, as described in Chapter 12. Remote GUI access can also be used for system administration, either to run GUI administration frontends or to run text-mode programs in xterm or similar windows. (In the latter case, though, a simpler solution is usually to access the system via a text-mode login protocol.)
The features, requirements, and potential uses of GUI login tools are somewhat different from those of text-mode login tools, so these factors require some explanation, and this chapter begins with this topic. This chapter then moves on to the traditional Linux remote access tool, the X Window System (or X for short), which Linux also uses to manage its local GUI display. Next up is information on a popular alternative, Virtual Network Computing (VNC), which can be used to access either Linux or Windows systems remotely.
GUI logins can be used for the same broad classes of purposes as text-mode logins, as described in Chapter 10—to run user programs remotely or to administer the computer. Because GUI logins are, well, GUI, you can run a wider range of programs using them than you can with a text-mode program. This includes GUI word processors, graphics editors, web browsers, and more. Programs that work best when they can display arbitrary fonts and graphics will work best with (or even require) GUI login tools. Because Windows programs are more likely to require GUI access than are Linux programs, GUI login tools are particularly important if you want to run Windows remotely.
GUI login tools’ advantages come at a price, though: increased network bandwidth consumption, which translates into lower speed. You can use a text-mode login tool quite comfortably over a dialup link or an overloaded local network, but a GUI tool used in the same environment might be painfully slow. Details do differ, though, depending on the tool and the programs you use.
Several GUI access protocols are available today. In the Linux world, X and the Remote Frame Buffer protocol (most commonly implemented by VNC) are the most popular remote-access tools, and these are the two tools that are described in this chapter. An interesting variant is the NoMachine (http://www.nomachine.com) NX Server and NX Client. The NX Server is built around X, while the NX client can connect to other systems using the NX, X, or RFB protocols, as well as protocols that are more common in the Windows world.
Remote X access involves a lot of back-and-forth transfers, but X delivers some types of data using few bytes. VNC, by contrast, requires more bandwidth but fewer transactions. Thus, X is likely to perform best on low-latency connections, whereas VNC performs best on high-bandwidth connections. Tunneling, encryption, compression, and other options can influence both protocols’ performance, though. If speed is a problem, you may need to experiment with both protocols.
Both X and VNC are a bit odd as network protocols go, but in different ways. X reverses the usual client/server relationship, as described in the next section. VNC is frequently run as a user process rather than as a conventional all-users server, as described in Section 11.4.2. Both oddities have implications for how you use the protocols. At their simplest, they require users to log in using a text-mode protocol before a direct GUI connection can be made. Ways to eliminate this requirement exist for both protocols, but these require extra configuration, which can be intimidating to those unfamiliar with the tasks at hand.
Unfortunately, neither X nor VNC encrypts data by default, so both protocols, by themselves, are risky ways to access a computer. (VNC does encrypt initial password exchanges, though.) One common solution to this problem is to use the SSH protocol to tunnel the GUI protocol—that is, to use an SSH connection as a carrier for the GUI connection, thus encrypting the GUI traffic. Alternatively, you can use a full-fledged virtual private network (VPN) to encrypt traffic. Precisely how to handle such encryption schemes is different for X and VNC, though.