第4章 配置 VNC
在前面，演示了如何在 Linux 平台上启动VNC，并且考虑了一些有关屏幕分辨率和颜色深度的问题， 但没有考虑有关配置和使用VNC的一些重要内容。 本文只集中讨论类UNIX 的 Xvnc 服务器的使用。除了实现配置不同外，其它系统都有相似的概念，它们通常通过菜单和对话框，而不是通过命令行和配置文件进行配置。
当vncserver首次运行在一个给定的用户帐户内时，它要求您指定VNC客户机连接需要的密码。另外，创建了一些缺省配置文件。请看一下它的首次运行：
创建缺省 VNC 配置
[vnc-user@fury vnc-user]$ vncserver
You will require a password to access your desktops.
Password:
Verify:
New 'X' desktop is fury.gnosis.lan:3
Creating default startup script /home/vnc-user/.vnc/xstartup
Starting applications specified in /home/vnc-user/.vnc/xstartup
Log file is /home/vnc-user/.vnc/fury.gnosis.lan:3.log
这里，创建了一个VNC会话。尽管在命令行上没有指定别的分辨率，将使用缺省分辨率。缺省分辨率是1024 x 768，而缺省颜色深度是8位。 前面演示了如何创建使用其它分辨率的脚本文件。
一开始要注意的事情是在首次运行期间创建的 ~/.vnc/xstartup 文件。该文件控制创建 VNC会话时发生的事情 ― 最需注意的是使用哪个窗口管理器。 首次创建 ~/.vnc/xstartup 时，指定的窗口管理器是twm ，它是一个极小的窗口管理器，几乎每台X Window系统机器上都有twm。从好的方面讲，twm 的极小本质几乎使它可能成为运行 VNC 的最为“带宽友好”的方法。从坏的方面讲， twm不具备完整“桌面管理器”（象 KDE、GNOME 或 WindowMaker）的大部分花哨功能。 许多用户都想要编辑他们的xstartup 。下面是修改过的示例：
定制的 VNC“启动”
#!/bin/sh
xrdb $HOME/.Xresources
xsetroot -solid grey
#xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
#twm &
#exec wmaker
exec startkde
在上面的示例中，我注释掉了缺省 twm 和 xterm 的缺省启动。还注释掉了曾使用了一段时间的 WindowMaker 的启动。 实际上并没有删除那些行，以防以后想要恢复它们。 利用这个帐户实际上是为了启动KDE。不过，配置了这个特殊的KDE桌面来避免背景和标题栏上的颜色渐变，并使用极少的动画效果。使桌面的繁忙程 度最小化可使 KDE 在通道带宽上变得更宽松。相似的原理适用于自己的任何一个窗口管理器。
最后要注意的是杀死已启动的VNC会话。需要在服务器端完成这个任务（包括从 vncviewer 窗口，一旦杀死该服务器，该窗口将切断连接；但这不会引起任何损害）。查看已经启动了哪些 VNC会话的快速方法是使用ps -ax | grep vnc 。 如果您想结束某个会话，可以使用 Linux 的 kill 命令，但这会留下一些悬而未决的信号文件，需要稍后手工删除它们。更干净的方法通常是使用vncserver -kill :1 － 但如果要从root 帐户强制杀死用户VNC进程，则使用kill 命令。
第5章 Desktop On-Call 和 eComStation
OS/2 Warp 的 Workplace Shell 仍远远领先于已经在 Linux、Windows、MacOS 或者甚至是BeOS上出现的任何 GUI。WPS确实很好，但继续使用的实际原因主要是这部分的惯性使然。好几年以来，构建了自己所熟悉并很适合在 OS/2 上使用的大型工具集，而且它们彼此工作得很好。当引导到其它系统时，从来没有设法填补日常使用的所有不足（90%的快乐仍需来源于偶然的重新引导）。
最近接收到一份Serenity系统的eComStation评估员副本而激动， 它是由第三方获许可者对IBM的Warp 4.5/Workspace on Demand所做的增强和重新绑定。eComStation（eCS）只是今年才发行的， 它包括“Warp 核心”的所有最新补丁和大量额外工具。
与eCS包括在一起的工具之一是名为“Desktop On-Call (DToC)”的IBM 产品。还有 Windows和Linux 版的DToC服务器，但很难在美国买到。DToC所做的事情很象VNC所做的。DToC 服务器依附HTTP协议上（缺省情况下，使用端口 80），以通过网络（LAN 或因特网）为“远程台式机”提供服务。DToC的客户机应用程序是任何启用了JavaScript和Java的Web浏览器。与使用VNC Java客户机一样，Web 浏览器基本上是至 DToC 的连接接口。而且，DToC 也有与 VNC 完全相同的问题：本地捕捉的击键、多键序列和带宽／分辨率权衡问题。
与 VNC 相比，DToC 有两个优点。安全性问题被集成到 DToC 中，而不是通过需要分别配置的其它层和转换。 依附在 HTTP 上意味着 DToC 比 VNC 更容易通过防火墙（但这有利有弊）。 此外，您会在DToC内部获得文件传送接口， 所以只要DToC在运行，就无须在服务器上运行单独的FTP、Samba、NFS 或类似的文件传送服务器。 从不利方面看，总的说来，比起 VNC，DToC 感觉上响应较慢 ― 这并不可怕，但少许差了点。
与eCS绑在一起的另一个工具是名为Hoblink X11的X服务器。至今还未对它进行过实验， 但当对它进行实验时，这可能会使得为本地网络的 OS/2 节点带来更好的集成（但还是 Linux “良好合作”做得最好）。
第6章 远程X Window系统
X Window 系统是响当当的软件思想。尤其知道它首次于1984年发明（在 Microsoft Windows 1.0 之前且刚好在第一台 Macintosh 之后的一小段时间)就更了不起了。对于大多数 Linux 用户而言，X Window系统（或“X11”， 但正确地讲不是“X Windows”）可能只是其窗口管理器为在本地显示 GUI 应用程序而调用的API。 但实际上 X11 是更有趣的东西。
X11总是有一个客户机和一个服务器，即使当它们都运行在同一台实际机器上。X 客户机和 X 服务器或许会与人们最初认为它们是服务器或客户机的想法相反。X 服务器是乐意为底层的应用程序提供显示能力的设备。X客户机是一种希望某个X服务器向它提供放置其可视输出的地方的特殊应用程序。
在本地工作站上运行时，服务器和客户机完全在一个内部通道上通信。 但当涉及到本地和远程机器时，本地机器通常是 X 服务器，而远程机器通常是 X 客户机。 然而，有时候可能想要在不在的工作站上显示某些信息，角色可能会颠倒。
X Window系统本身实际只是一个具有诸如“在这些坐标上绘制一个窗口”等调用的 API。 为了实际让X Window系统做更多的事情，通常在它的上面运行一个窗口管理器， 让用户可以做一些如移动窗口、使它们最小化和启动新的X客户机等事情。
来看一下如何启动一个远程应用程序（X 客户机），以使它在本地工作站上显示。用于演示的所有机器都是 Linux，但其它具有X服务器和客户机的系统将以相似的方式工作。首先，要决定本地机器使用的IP地址； ifconfig 是完成这个任务的好工具：
查找本地机器（X 服务器）的 IP 地址
[root@bacchus /root]# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:48:54:83:82:AD
inet addr:192.168.1.102 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:15933 errors:0 dropped:0 overruns:0 frame:0
TX packets:10426 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:10 Base address:0xe800
接下来，要确保远程机器上的应用程序将具有使用本地X服务器的本地许可权：
设置 X 服务器权限（首先全部除去）
[root@bacchus /root]# xhost -
access control enabled, only authorized clients can connect
[root@bacchus /root]# xhost +192.168.1.106
192.168.1.106 being added to access control list
接下来，需要能够启动应用程序以在远程机器上运行。可能会转到实际机器（或让其他人转去），但大多数情况下，打开远程shell 会话是最简单的事情（这里，使用不安全的 telnet 方式）：
连接到远程机器 Fury（X 客户机）
[root@bacchus /root]# telnet -l quilty 192.168.1.106
Trying 192.168.1.106...
Connected to 192.168.1.106.
Escape character is '^]'.
Password:
Last login: Tue Nov 27 18:07:51 from 192.168.1.201
如果一切都运行正常，远程机器将自动检测正在连接的机器。有关在不正常情况下要做些什么事情的信息，则请参阅下面的内容：
检查 X 客户机 Fury 上的 DISPLAY 环境变量
[quilty@fury quilty]$ echo $DISPLAY
bacchus.gnosis.lan:0
现在，可以启动X客户机。对于本示例，使用普通的（但挺有意思的）应用程序xeyes（它在屏幕上显示一双跟随鼠标光标的眼睛）：
在 X 客户机上启动应用程序以在 X 服务器上显示
[quilty@fury quilty]$ xeyes &
[1] 9939
启动远程应用程序时的一些故障
偶而，上述序列中的某些事情会发生故障。请看一下一些典型问题：
连接到远程机器 Delphi
[root@bacchus /root]# /usr/local/bin/ssh quilty@192.168.1.104
quilty@192.168.1.104's password:
Last login: Wed Nov 28 01:06:08 2001 from 192.168.1.201
Linux 2.2.19.
请尝试执行上面的序列：
检查 X 客户机 Delphi 上的 DISPLAY 环境变量
quilty@delphi:~$ echo $DISPLAY
quilty@delphi:~$ xeyes &
[1] 17668
quilty@delphi:~$ Error: Can't open display:
[1]+ Exit 1 xeyes
由于没有自动检测到 DISPLAY 环境变量的值，所以X客户机不知道哪个服务器将为它提供显示：
没有（或错误地）设置 DISPLAY，export 值
quilty@delphi:~$ export DISPLAY=192.168.1.102:0
quilty@delphi:~$ xeyes &
[1] 17669
quilty@delphi:~$ Xlib: connection to "192.168.1.102:0.0" refused by server
Xlib: Client is not authorized to connect to Server
Error: Can't open display: 192.168.1.102:0
[1]+ Exit 1 xeyes
继续前进，但Bacchus尚未授权Delphi使用它的X服务器（我们需要切换到本地xterm 来修正这个问题）：
X 服务器拒绝连接；启用它
[root@bacchus /root]# xhost +192.168.1.104
192.168.1.104 being added to access control list
一切都正常：
在 X 客户机上启动应用程序以在 X 服务器上显示
quilty@delphi:~$ xeyes &
[1] 17670
第7章 安全性问题
前面，曾经提到VNC和远程X11在因特网通道上都是不安全的。整个远程显示在公共路由器上是在未经加密的情况下传输的。不担心防火墙后面的专用LAN。 但是，如果想要使用这些技术在全世界范围（或者甚至跨城市）共享远程计算机，那么VNC或X11协议应该被放置在SSH 上。做到这一点真的没有任何损失，而且SSH甚至（可选地）添加其自己的压缩层来增强性能。 但是，您需要配置它。
将X放置在SSH上十分容易做到。假设正在使用OpenSSH， 将需要修改名为 sshd_config 的文件来允许分层。 不同的 Linux 分发版将该文件放在稍微不同的地方。Mandrake 7.1 将它放在 /usr/local/etc/ ；Slackware 7.0 使用 /etc/ssh/ 。在任何情况下， 您都必须确保该文件包含下列内容：
X11Forwarding yes
将需要重新启动 sshd 守护程序来激活该设置。
实际上，一旦正确配置了sshd ，就可以更容易地启动X客户机，以在本地X服务器上显示：
对于 X 客户机使用 sshd X11 转发
[quilty@bacchus quilty]$ ssh -X quilty@192.168.1.104
quilty@192.168.1.104's password:
Last login: Fri Nov 30 16:53:03 2001 from 192.168.1.102
Linux 2.2.19.
quilty@delphi:~$ echo $DISPLAY
delphi:10.0
quilty@delphi:~$ xeyes &
[1] 201
请注意，即使已连接到Delphi，DISPLAY变量仍似乎会指出X服务器在Delphi上。在某种程度上，就是这样，正讨论的X服务器是将显示交付给适当的远程计算机的SSH守护程序。
