لطفا منتظر باشید ...
Running a VNC
Server
Because X is the GUI environment that's most
common on Linux, and because X was designed with network operations in mind, X
is a common method of remote GUI access in Linux. X is not, however, the only
method. Another tool, VNC, is available for providing remote GUI access to
Linux. As described shortly, VNC uses a different network model than does X,
and so has certain inherent advantages and drawbacks. Installing and
configuring a VNC server is also a very different task than is installing and
configuring an X server. Likewise, using a VNC client for remote access is
different than using an X server.
Understanding the VNC Client/Server Relationship
I've taken pains in the preceding discussion
to make the client and server roles of different programs explicit. This can
become confusing at times, because in any connection, one computer functions as
a client and the other as a server for one protocol, but this client/server
relationship is reversed for another. VNC is somewhat easier to discuss because
the connections between the two computers are simpler and more intuitively
understandable to most people: The user sits at a VNC client and runs programs
on the VNC server. This relationship is like that of a Telnet or SSH server.If you recall the earlier discussion of the
relationship between X clients and servers, though, you may wonder how this
happens. After all, the X server controls the keyboard, mouse, and display, so
how can the user not sit at the X server but
still use X programs? The answer is an added layer of network complexity that's
hidden from the user. The VNC server computer runs the X clients, which talk to
an X server that runs on the local computer. This X server interfaces to the
VNC server as if the VNC server were the human input and output devices. Instead
of using the local keyboard, mouse, and display, though, the VNC server uses a
network connection to communicate with a remote VNC client, which provides the
input/output devices. This arrangement, and a comparison of it to a normal
local X server and a networked X server, is shown in
you can see, it adds considerable complexity compared to a traditional remote X
server configuration, but this complexity is largely hidden from the user.
Figure 14.5. A VNC server
runs its own custom X server locally, and interfaces to a simple remote network
client that provides a keyboard, mouse, and monitor for the X server.
system can maintain its state even if the VNC link is broken. For instance, if
the VNC client system crashes, or if the user simply exits from the VNC server
without logging out, the VNC server continues to run, and the next time a user
makes a connection to the VNC server, all the applications that were run on the
VNC server will remain open. This feature can be extremely convenient in some
environments, but you shouldn't rely on it too heavily. Just as when you step
away from a computer console for an extended period, the VNC server might
crash, or the connection might be hijacked. (This maintenance of the local
state doesn't apply when you use VNC in conjunction with XDMCP, as described in
the upcoming section, "
plain X connection via Telnet or XDMCP and an SSH-encrypted X connection. VNC
encrypts its passwords, so they should be reasonably secure; but VNC doesn't
encrypt other data, so anything you type or display after logging in could
conceivably be viewed by others, particularly if your connection passes over
the Internet at large.X was designed with network operations in
mind; it passes data in terms of lines, characters, and so on, not the bitmaps
that are displayed on the screen. This results in a large number of
back-and-forth transactions that transfer relatively little data. VNC, by
contrast, is more bitmap-oriented; it performs relatively few transactions,
each of which transfers more data. This fact means that on some networks and
for some applications, VNC is more sluggish than a normal X connection, because
more data must pass between the computers. For instance, if you use a text
editor, the text editor can pass words to the X server, which generates the
bitmaps for those words locally. VNC, however, must pass the entire bitmap,
which is usually larger than a higher-level description of the display. This
advantage may be small or nonexistent on a fast network or when running
programs like bitmapped graphics editors, though. On the other hand, VNC's use
of fewer data exchanges means that it can be faster if your connection has a
very high latency, such as a satellite link; the many back-and-forth exchanges
of conventional X slow it down in such situations. If you're dissatisfied with
VNC's speed, you might look into an expanded version of VNC that supports more
efficient encodings, such as TightVNC ( target="_blank">http://www.tightvnc.com ) or TridiaVNC ( target="_blank">http://www.developvnc.org ). These more bandwidth-efficient encodings consume more CPU time,
though, so they're best used when both systems have fast CPUs. Likewise,
tunneling VNC through SSH and using its compression features can improve or
degrade performance, depending on available bandwidth and CPU time.One of the big advantages of VNC over X is
that you can use VNC to control a Windows or MacOS system. Although they don't
use an X server internally, as shown in
servers for Windows and MacOS are available. These servers intercept the
Windows or MacOS screen display and user input calls and echo the results to
the VNC client, or take input from that client. I don't describe the operation
of these Windows and MacOS VNC servers, though. They're conceptually similar to
the Linux VNC server, but the Windows and MacOS servers offer fewer options and
are configured through dialog boxes rather than text files. You can connect to
the Windows and MacOS VNC servers exactly as you connect to a Linux VNC server.
Because the Windows and MacOS VNC servers intercept screen calls, it's only
practical for one person to use the computer at once.
Installing a VNC Server
You can obtain a VNC server from the main VNC
Web site, http://www.uk.research.att.com/vnc/ . Both the VNC server and the VNC client also ship with many Linux
distributions (VNC is an open source package). Some distributions ship both
server and client in a single package (usually called vnc ), but
others break out the server and client packages (usually called vnc-server and
vnc , respectively). The TightVNC and TridiaVNC sites have their own
packages, but their installation and use is similar to what's described here.If your distribution ships with VNC, or if
you want to install it from an RPM or Debian file obtained from another source,
you should be able to accomplish the task by installing the package in the
usual way. As of version 3.3.3r2, the original VNC's official distribution form
is precompiled x 86 binary code in a tarball or
zip file, or source code. Assuming you obtain the code as a binary tarball, you
can install it as follows:
command such as tar
xvfz vnc-3.3. 3r2_x86_linux_2.0.tgz . This
creates a directory called vnc_x86_linux_
2.0 .
2. Copy the files vncviewer , vncserver , vncpasswd , vncconnect , and
Xvnc from the vnc_x86_linux_2.0 directory to a directory on your path, such as /usr/local/bin .
Alternatively, you can move the entire vnc_ x86_linux_2.0 directory to a location such as /opt and either add it to your path or
create links from these program files to a location on your path.
3. Create a directory called .vnc in the
home directory of the user who is to use VNC. This directory should be owned by
the user in question. It will hold individualized VNC configuration files,
including a VNC password file. To prevent snooping, you might want to set this
directory's permissions to 700 ( rwx------ ).
4. . As the
user who will use VNC, type vncpasswd .
The vncpasswd program, as you might expect, sets a password. Unlike most other
Linux login servers, VNC doesn't rely on the Linux username and password
database to control access. Instead, it's run as a normal user, and so the
server itself must provide password authentication. (If you pair VNC with an
XDMCP server, as described shortly, Linux handles authentication, so you can
skip this step and Step 3.)
NOTE
align=left border=0> These instructions describe installing and
using the conventional VNC server and client. VNC also supports a Java server
mode, which allows you to access the VNC server from any Java-enabled Web
browser. The necessary Java classes appear in the classes subdirectory of the installation directory. Read the README file
for more information on installing and using these classes.
Running a VNC
Server
At this point, the VNC server is installed
and configured. To run it, you must first log into the server as an ordinary
user. Typically, you'll do this from the computer from which you want to use
VNC, much as you'd log into a remote computer using Telnet or SSH in order to
use X programs via an X server. There are other ways to do this, though; for
instance, you could run VNC from the console in preparation for accessing the
system from some other location. You can run the server by typing its name as an ordinary user: $ vncserver New 'X' desktop is vncserv.threeroomco.com:1 Starting applications specified in /home/rodsmith/.vnc/xstartup Log file is /home/rodsmith/.vnc/vncserv.threeroomco.com:1.log
It's important to pay attention to the output
of this command, and particularly the line that identifies the desktop number1
in the preceding example, as indicated by the number at the end of the hostname
( vncserv.threeroomco.com:1 ). VNC operates by starting an X server (the Xvnc program),
which doubles as a VNC server. You can think of this X server as being like an
X session started from a text-mode console login by typing startx it
has no login prompt, and starts an individual's desktop environment or window
manager, as described shortly. If two or more individuals run VNC servers on a
single computer, they must be differentiated from each other in some way. The
method used is the X server number. The number 0 is often taken by the local
console's X server, so chances are the first VNC session will use a number of
1. Subsequent VNC sessions may use higher numbers.WARNING
align=left border=0> If you used SSH to log into the VNC server
system in order to run the VNC server, you may find that the VNC server runs,
but all X programs (including window managers) fail to run in it. The result
is that when you try to access the VNC server, you see a gray background with
no windows, and you can't do anything with it. The cause is that SSH adjusts
the xauth configuration for its own X forwarding features. A quick and
dirty workaround is to type export XAUTHORITY=~/.Xauthority before
running vncserver . This resets the X authority file to its default, so VNC won't
become confused. Another workaround is to copy the authority entries from the
default file into SSH's temporary authority file, which it maintains in the /tmp directory tree (typing xauth from an SSH login will use this file).
If you've finished with a VNC session, you
can shut it down by using the -kill option, thus: $ vncserver -kill :1
The number you use is the VNC session number,
as reported when you started that session. Shutting down the VNC server when
it's not in use isn't necessary, but reduces the memory load on the server
computer and improves securitya server that isn't running can't be broken
into. Be sure you've exited from any important programs before you do this,
thoughwhen you shut down a VNC server in this way, you won't be prompted if
you want to save open files.
Using a VNC Client to Access the Server
The Linux VNC client is called vncviewer .
To use it, you type its name, optionally followed by the name of the VNC server
and its display number, thus: $ vncviewer vncserv.threeroomco.com:1 VNC server supports protocol version 3.3 (viewer 3.3) Password:
The password doesn't echo when you type it. The
VNC client then displays additional information on the nature of the
connection, such as the color depth and some other technical information. If
all goes well, you'll see a window appear showing a Linux desktop on the VNC
server. As noted in the next section, however, the defaults for the VNC server
may not be to your liking, so you may want to adjust them.If you don't include the display number, the
VNC client tries to connect to display number 0, which won't work with most
Linux systems, since that number is generally used by the local X server. Omitting
the display number will usually work when connecting to a Windows or MacOS VNC
server, though. If you omit the hostname, in addition to the display number,
the VNC client prompts you for the hostname and password using an X-based
dialog box.Windows and MacOS VNC clients work in a way
that's similar to that of the Linux VNC viewer, but the program is somewhat
more GUI-centric. Specifically, you double-click the VNC viewer icon to launch
the program. It then presents a dialog box in which you enter the VNC server's
name and display number (such as vncserv.threeroomco.com:1 ). If this
corresponds to a valid VNC server, the program then asks for a password and, if
the password is correct, displays a window in which the VNC server's desktop
appears.
Adjusting VNC Server Configuration
VNC can be a useful remote-access tool, but
it's not without its problems. Some of these are inherent to VNC. For instance,
many people report problems with the NEdit editor (
essentially useless. Fortunately, such serious problems are rare. Other VNC problems
aren't so severe; they can be overcome by adjusting VNC's configuration. You
can change several basic features by editing the main VNC server startup
script. You can set other features by customizing users' configuration files.
Adjusting Basic Server Features
The main VNC server program is Xvnc . This
program includes both an X server (which communicates with local X programs)
and the VNC server (which communicates with the remote VNC client). You'll
note, though, that the preceding instructions don't refer to Xvnc . This is
because this program is called by a script, which is used to start the server: vncserver . This
script is written in Perl, and you can edit it yourself to adjust many of the
VNC server's default settings. Some that you might want to change include the
following: Auto-configured X
defaults Recent versions of vncserver use
the &GetXDisplayDefaults() call to retrieve various defaults for the X display, such as the
display size and bit depth. Unfortunately, the system may recover a size that's
inappropriate for your desired clients. You can comment out this line by
preceding it with a pound sign ( # ) if you want to use a different display
size. You'll then need to set the display size separately. The default script
includes lines to do this before the &GetXDisplayDefaults() call, as described shortly. Display size When Xvnc starts, it creates a virtual screen of a specific size. If you
don't use the automatic X defaults option, you can set this display size with
the $geometry variable. For instance, you might include a line like the following
to set up a 900x675 display: $geometry = "900x675";
TIP
align=left border=0> Because VNC clients display a VNC server's
desktop within a local window, it makes sense to create a display size that's
slightly smaller than the client's screen size to provide for window borders.
If the VNC display size is too large, users will have to scroll their local
VNC windows to see the entire server desktop.
Color depth As with the display size, you can set the color depth by setting a
variable, which is called $depth in the standard script. Sixteen bits is generally a good minimum
for X, because color-hungry programs can rob colors from other programs. This
rule doesn't apply to VNC, though; 16-bit displays tend to create corrupted
color maps. This problem may be fixed in the future, though. Font path The default vncserver script uses the default font path for the server. You can adjust it
in the section that's commented Add font path and color database stuff here . The relevant line adds a font path using the -fp parameter
to the $cmd string, which is ultimately used to call Xvnc . You can
even configure VNC to use a font server, as described in
manager The default vncserver script includes a variable called $defaultXStartup , which stores the
contents of the default user startup script. The vncserver script writes
this file to the user's directory the first time the user runs the script. The
default window manager is twm , which few people use today. You can adjust this default by
changing the twm call to a call to whatever window manager or desktop environment
you like, such as startkde , sawmill , or icewm . Adjusting the vncserver script will only affect the default for users who have not yet run
the script, though. Consult the upcoming section, "
can peruse the script to find more advanced features you might want to adjust. Mostly
the script sets options to be passed to Xvnc by adding them to
the $cmd string, so if you can decipher the options added to that string,
you can modify them. Typing Xvnc -help &> Xvnc-help.txt creates a text file called Xvnc-help.txt that contains information on available Xvnc options.WARNING
align=left border=0> Be sure to back up the vncserver script before making any changes. If a change you make should render the
script unusable, you'll be glad to have the backup.
One important caveat is that the vncserver scripts shipped with some distributions differ substantially from the original.
Debian's script, in particular, is quite different from the original. That
said, the advice presented here applies to them all, but you might need to go
about making changes in slightly different ways. For instance, Debian's vncserver script creates a variable called $fontpath in which it holds the font path.
Customizing Individual Users' Settings
Global VNC server settings are controlled
through the vncserver script. If your users want to change these settings themselves,
they have three choices: Create a customized
startup script Individual users may copy the
normal VNC server startup script to their home directories and modify these
copies, as described earlier, then use their customized scripts to start the
server. Pass options to the
script The vncserver script accepts
several options that can be used to override the defaults. For instance, -geometry width xheight sets the
desktop size. These options are largely the same as the underlying Xvnc options. Use individualized
option files The standard VNC server script
runs the ~/.vnc/xstartup script at the end of its running process. This is where the default
script places commands to start a window manager and xterm window. Users may
modify these files as they would ordinary X startup scripts. Some distributions
alter the name or location of this script. For instance, Debian's configuration
calls the /etc/X11/Xsession script, which in turn calls the user's ~/.xsession script.On the whole, the last two options are
usually the simplest. Each option has its role to play. For instance, users can
set their desktop sizes with the -geometry option to the vncserver script, but not via an option file; and they can adjust the window manager they
use by setting it in their personal startup scripts, but not by passing an
option to vncserver . As a general rule, the vncserver options let
users adjust how VNC's X server as a whole operates (similar to standard X
server options), but their startup script options let them adjust how their
desktop environments and window managers behave (as do their X session options
in more conventional X servers).
Running an XDMCP Login Server in VNC
One potentially serious problem with VNC is
the fact that, as just described, it requires you to log in using a standard
remote-login protocol, launch the server, and remember the display number to
connect to the correct display. This process can be tedious, and it requires
you to run a conventional login server, assuming you want to allow convenient
and truly remote access. One solution to these problems is to combine the VNC X
server with an XDMCP server run on the local system.The VNC X server supports management of its
display by an XDMCP server, just as do most X servers. To enable this feature,
you must launch the VNC X server with the -query hostname option, as described earlier, in "
server, as described in
example, consider the following xinetd configuration entry: service vnc { disable = no socket_type = stream protocol = tcp wait = no user = nobody server = /usr/local/bin/Xvnc server_args = -inetd -query vncserv -once }
The server arguments are extremely important.
Specifically, -inetd tells Xvnc that it's being run from a super server, -query vncserv tells it to call the computer vncserv for the XDMCP login prompt, and -once tells
the server to quit after it's been called one time, which has the effect of
terminating the VNC link after a user logs out. You can add more Xvnc options,
such as -geometry or -fp , to customize the setup. This entry should be combined with an
entry in /etc/services that defines the vnc port number: vnc 5900/tcp
VNC uses port numbers 59005999 for normal
connections, or 58005899 for Web browser (Java) access. Port 5900 corresponds
to display 0, 5901 to display 1, and so on. Thus, this definition sets up VNC
to respond to its first display (0), and to immediately present an XDMCP login
prompt. Of course, an XDMCP server must be running on the system specified by -query for
this to work. You can even set up multiple ports to respond to VNC clients, but
configure them differently. For instance, you might set up display 0 to present
an 800x600 desktop, display 1 to use 1024x768, and so on. You'll need multiple /etc/services entries to identify these servers, each with a unique name and port number. When
run in this way, VNC doesn't prompt for a password; it leaves that detail to
the XDMCP server. (Note that the username and password are transmitted
unencrypted, unlike a more conventional VNC login.) One other feature of VNC
when run like this is that it can accept multiple logins to the same port by
different users, so users don't need to remember a potentially changing port number.
As a rough approximation, then, when you run VNC with an XDMCP server, the
effect is very similar to running an XDMCP server directly and using a remote X
server. There are a few major differences, though: The VNC solution requires a single connection
between the two computers. This may be helpful if the system at which the user
sits is protected by a firewall, and it can help you reduce the number of
servers that are available to the outside world. The VNC solution uses a VNC client where the
user sits, rather than an X server. As open source software, a VNC client is
inexpensive, but most X servers for Windows and MacOS are commercial software. The VNC protocols, as noted earlier, have their
own unique quirks. When compared to a native X server on the user's computer,
VNC may be superior or inferior in this respect, depending upon the quality of
the X server and the users' specific needs. The VNC protocols, as noted earlier, tend to be
slower than X protocols on most connections, although they may be faster on
some, so using this solution has speed implications.
