Sealyu

2001 年 12 月 01 日

本文是兩篇比較 SSH、遠程 X、VNC 和其它技術作為遠程運行應用程序方法的文章的第 2 部分。在這一部分中，David 研究了一些 VNC 配置問題，提到了 IBM 的 Desktop On-Call，介紹了遠程 X 并討論了一些有關安全性的問題。

在有關共享計算機的這兩篇文章中的 第 1 部分中， 我描述了我的異構本地網絡以及如何使用它來比較和測試不同操作系統和體系結構上的應用程序。 有幾種技術使一臺工作站上的用戶可以運行位于另一臺工作站上的應用程序。SSH 提供到遠程計算機的文本終端；可以使用 X Window 系統在一個并未實際運 行交互式應用程序的工作站上顯示該應用程序；VNC 可以作為對整個遠程臺式機的“遙控器”。

每種技術都有優缺點。它們都在 Linux 上運行， 但不同變體（主機或遠程）都允許與異構網絡的其它各種 OS 環境進行交互。 使用這些工具的組合，我可以坐在一臺工作站（比方說，具有最好的顯示器、鍵盤和椅子的那一臺）上，然后運行和測試多個平臺上 的應用程序并對它們設定運行時間 ― 通常不用重新引導任何系統。

第 1 部分介紹了 SSH 和 VNC。第 2 部分將更多地討論 VNC，然后再討論遠程 X 和安全性。

我的網絡設置

我的 本地網絡上有七個節點，分別命名為 Apollo、Bacchus、Chaos、Delphi、Echo、Fury 和 Gaia。按所列的次序為這些節點分配了從 192.168.1.101 到 192.168.1.107 的本地 IP 地址。大多數情況下，同一物理機器在多重引導到不同 OS 時總是獲得相同的 IP 地址（但有時我使用 DHCP，它分配 192.168.1.200 以上的地址）。整個網絡位于一個硬件防火墻／路由器后，而且我充分信任防火墻，以至于對于運行在本地機器上的服務，我也許并沒有象應有的那樣猜疑提防。需 要在公共因特網上共享計算機的讀者應該比我更擔心安全性問題。上面的詳細信息將讓讀者理解下面給出的一些 shell 示例。我實際坐在 Bacchus 面前，它的 IP 地址是 192.168.1.102。

回頁首

配置 VNC

在 第 1 部分中， 我演示了如何在 Linux 平臺上啟動 VNC，并且考慮了一些有關屏幕分辨率和顏色深度的問題， 但沒有考慮有關配置和使用 VNC 的一些重要內容。 本文只集中討論類 UNIX 的 Xvnc 服務器的使用。除了實現配置不同外，其它系統都有相似的概念，它們通常通過菜單和對話框，而不是通過命令行和配置文件進行配置。

當 vncserver 首次運行在一個給定的用戶帳戶內時，它要求您指定 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 位。 第 1 部分演示了如何創建使用其它分辨率的腳本文件。

一開始要注意的事情是在首次運行期間創建的 ~/.vnc/xstartup 文件。 該文件控制創建 VNC 會話時發生的事情 ― 最需注意的是使用哪個窗口管理器。 首次創建 ~/.vnc/xstartup 時，指定的窗口管理器是 twm ， 它是一個極小的窗口管理器，幾乎每臺 X Window 系統機器上都有 twm。從好的方面講， twm 的極小本質幾乎使它可能成為運行 VNC 的最為“帶寬友好”的方法。從壞的方面講， twm 不具備完整“桌面管理器”（象 KDE、GNOME 或 WindowMaker）的大部分花哨功能。 許多用戶都想要編輯他們的 xstartup 。下面是我修改過的示例：

#!/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 命令。

回頁首

Desktop On-Call 和 eComStation

developerWorks 上我寫的“可愛的 Python”專欄和這兩篇文章的讀者 可能已經對我偶然提及 OS/2 的使用稍感驚訝，因為使用它的人數已在幾年內 逐步減少（甚至在 IBM 內部更是如此）。 我的“正式”說法是大概觀察到：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 “良好合作”做得最好）。

回頁首

遠程 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 是完成這個任務的好工具：

[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 服務器的本地許可權：

[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 方式）：

[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

            

如果一切都運行正常，遠程機器將自動檢測正在連接的機器。有關在不正常情況下要做些什么事情的信息，則請參閱下面的內容：

[quilty@fury quilty]$ echo $DISPLAY

            bacchus.gnosis.lan:0

現在，我們可以啟動 X 客戶機。對于本示例，使用普通的（但挺有意思的）應用程序 xeyes （它在屏幕上顯示一雙跟隨鼠標光標的眼睛）：

[quilty@fury quilty]$ xeyes &

            [1] 9939

            

啟動遠程應用程序時的一些故障

偶而，上述序列中的某些事情會發生故障。請看一下一些典型問題：

[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.

            

請嘗試執行上面的序列：

quilty@delphi:~$ echo $DISPLAY

            quilty@delphi:~$ xeyes &

            [1] 17668

            quilty@delphi:~$ Error: Can't open display:

            [1]+  Exit 1                  xeyes

            

由于沒有自動檢測到 DISPLAY 環境變量的值，所以 X 客戶機不知道哪個服務器將為它提供顯示：

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 來修正這個問題）：

[root@bacchus /root]# xhost +192.168.1.104

            192.168.1.104 being added to access control list

            

一切都正常：

quilty@delphi:~$ xeyes &

            [1] 17670

            

回頁首

安全性問題

在 第 1 部分中， 我曾經提到 VNC 和遠程 X11 在因特網通道上都是不安全的。整個遠程顯示在 公共路由器上是在未經加密的情況下傳輸的。 我不擔心防火墻后面的專用 LAN。 但是，如果我想要使用這些技術在全世界范圍（或者甚至跨城市）共享遠程計算機，那么 VNC 或 X11 協議應該被放置在 SSH 上。做到這一點真的沒有任何損失，而且 SSH 甚至（可選地）添加其自己的壓縮層來增強性能。 但是，您需要配置它。

要在 SSH 上配置 VNC，最好是閱讀文章“Making VNC more secure using SSH”（請參閱本文后面的 參考資料）。 這篇文章寫得很好，描述了我可能要講到的每一件事情。

將 X 放置在 SSH 上十分容易做到。假設正在使用 OpenSSH， 將需要修改名為 sshd_config 的文件來允許分層。 不同的 Linux 分發版將該文件放在稍微不同的地方。Mandrake 7.1 將它放在 /usr/local/etc/ ；Slackware 7.0 使用 /etc/ssh/ 。在任何情況下， 您都必須確保該文件包含下列內容：

 X11Forwarding yes 

將需要重新啟動 sshd 守護程序來激活該設置。

實際上，一旦正確配置了 sshd ，就可以更容易地啟動 X 客戶機，以在本地 X 服務器上顯示：

[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 守護程序。

參考資料

• 您可以參閱本文在 developerWorks 全球站點上的 英文原文.
  
  
• 本系列的第一部分， 在 Linux（或異構）網絡上共享計算機，第 1 部分（ developerWorks，2001 年 12 月），對 SSH 和“虛擬網絡計算”做了詳盡的比較。
  
  

IBM Desktop On-Call 參考資料

• IBM 在 Desktop On-Call for Multiplatforms V4頁面上提供了 Desktop On-Call 的產品信息。
  
• eComStation 是 IBM OS/2 Warp/Workspace on Demand 的重新綁定和增強版， 它特別強調了在異構網絡環境中更好地運行。
  
• 將 Desktop On-Call 版本作為 eComStation 的一部分提供的 Serenity 系統還提供了 DTOC v4.0 手冊的 在線版本。
  

X Window 系統參考資料

• XFree86網站是查看與這一受歡迎的自由軟件 X Window 實現相關的所有信息的好地方。
  
• 從技術上講，XFree86 是正式的 X Window 系統的克隆（很象 Linux 是 UNIX 的“克隆”那樣）。 實際上，您不必擔心什么是正式的 － 所有版本彼此都會很好地合作。有關正式系統的信息（包括可用的源代碼）， 請轉至 X.org 主頁。
  
• 還可以獲得 X Window 系統的許多商業實現：
  • Accelerated-X
  • Metro-X

其它參考資料

• 如果有興趣，可以查看 Graphical User Interface Timeline，它幫助提供 X11 和其它 GUI 的一些歷史環境。
  
• 請瀏覽 developerWorks上 更多 Linux 參考資料。

關于作者

		David Mertz 是個討人喜歡的人。他是計算機問題的克星。可以通過 mertz@gnosis.cx和 David 聯系；可在 http://gnosis.cx/publish/上了解他的生活。歡迎對本文、過去的和以后的專欄文