コンピューターの共用についてのこの2回シリーズの第1回の記事では、私のところの異種混合ローカル・ネットワークについて説明し、そのようなネットワークを使って、いろいろなオペレーティング・システムやアーキテクチャーの上でアプリケーションを比較したりテストするやり方を紹介しました。あるワークステーション上から別のワークステーションに存在するアプリケーションを実行するためのテクノロジーは多数あります。SSHは、リモートのコンピューターに対するテキスト端末となります。X Windowシステムを使えば、実際に対話型アプリケーションを実行しているワークステーションとは別のワークステーションにそのアプリケーションを表示させることができます。VNCは、リモートのデスクトップ全体を制御するための「リモコン」として機能します。

どのテクノロジーにも一長一短があります。いずれもLinux上で動作しますが、いろいろとバリエーション (ホストかリモートか) を変えることで、異種混合ネットワークに対応する他のいろいろなOS環境との対話が可能になります。これらのツールを組み合わせて使えば、どこかある1台のワークステーション (最も使いやすいモニターやキーボードや椅子のあるところ) から、さまざまなプラットフォーム上のアプリケーションを実行したりテストしたり時間測定したりすることができます (通常、まったくリブートすることなく)。

第1回では、SSHとVNCを紹介しました。この第2回では、まずVNCについて少し触れた後、リモートXとセキュリティーに話を移したいと思います。

ネットワーク・セットアップ

私のローカル・ネットワークにはノードが7個つながっています。それぞれにApollo、Bacchus、Chaos、Delphi、Echo、Fury、Gaiaの名前を付けています。これらのノードには、192.168.1.101から順に192.168.1.107までのローカルIPアドレスを振ってあります。いくつかのOSにマルチブートできる場合でも、だいたいは、同じ物理マシンには同じIPアドレスを割り当てています (ただし、DHCPを使うこともあります。DHCPは192.168.1.200よりも上のアドレスを割り当てます)。すべてのことがハードウェアによるファイアウォール / ルーターの背後で起こることであり、私はファイアウォールを信頼していますので、ローカル・マシン上で実行されるサービスに関して、もしかしたら充分に神経質になっていないのかもしれません。公共のインターネットを介してコンピューターを共用する必要のある方は、セキュリティーについて、私の場合よりも注意したほうがよいでしょう。上のような詳細を紹介したのは、以下で示すシェルの例を理解しやすくするためです。実際に私の目の前にあるマシンは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セッションが1個作成されました。コマンド・ラインから別の指定を行わなければ、デフォルトの解像度が使用されます。デフォルトの領域は1024 x 768で、デフォルトのカラーの深さは8ビットです。第1回では、別の解像度にするためのスクリプト・ファイルの作成方法も紹介しました。

開始時に注意すべきことは、最初に実行したときに作成される~/.vnc/xstartup ファイルについてです。このファイルは、VNCセッションが作成される際にどんなことを行うかを制御します。とりわけ、どのウィンドウ・マネージャーを使うか、です。最初に~/.vnc/xstartup が作成されるときに指定されるウィンドウ・マネージャーはtwm です。ほとんどすべてのX Windowシステム・マシンに存在する極めて小ぢんまりしたウィンドウ・マネージャーです。twm が小さいことの良い点は、VNCを実行する際に、最もといってよいほど帯域幅に負担をかけないという点です。逆にマイナス面として、KDEやGNOMEやWindowMakerなどのフル機能の「デスクトップ・マネージャー」が備えているいろいろな付加機能を、twm は、ほとんどを備えていません。多くのユーザーは、自分の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セッションのkillの仕方について触れておきます。killはサーバー側で行う必要があります (これには、vncviewer ウィンドウからのものも含みます。この場合、サーバーをkillすると接続を切ることになりますが、それで害をもたらすことはありません)。VNCセッションが起動されたことを確認する簡単な方法は、ps -ax | grep vnc を実行してみることです。必要なら、Linuxのkill コマンドを使ってセッションを終了させることもできますが、その場合、セマフォー・ファイルが何個か残ることがあり、後で手作業で削除しなければならないことになります。通常は、もっと奇麗なやり方として、vncserver -kill :1 を実行するわけですが、ルート・アカウントからユーザーVNCプロセスを強制killしたいときには、kill コマンドを使います。

上に戻る

Desktop On-CallとeComStation

developerWorks の私の「魅力的なPython」のコラムや今回の2回シリーズの記事を読まれた方は、私がときどきOS/2の使い方に言及していることに少し驚かれたのではないでしょうか。OS/2の人気は (そしてIBMの注目すら) 低下して何年も経つというのに。私の「公式の」お話は、たぶん、OS/2 WarpのWorkplace Shellは、LinuxやWindowsやMacOS、さらにはBeOS上に出現した、どんなGUIよりもずっと先を行っているという見解になるでしょう。WPSは、本当にそれほど素晴らしいのですが、私がまだ使い続けているのは、ほとんど私の側の事情からくる惰性だというのが本当のところです。これまで何年もの間、私は、OS/2でツールを非常にたくさん作ってきました。そうしたツールは、私にとって使い慣れた快適なものになっており、ツール同士もうまく連携して動作するようになっています。他のシステムをブートして日常の用事を済ませることができるほどには、まだ完全にすべてのギャップを埋めきれていないというわけです (90%の満足では、まだ、ときどきリブートが必要です)。

私の一徹さはさておき、最近Serenity Systems社のeComStationの評価版が送られてきたときには感激しました。これは、サード・パーティのライセンス所有者がIBM Warp 4.5/Workspace on Demandを拡張、再ビルドした製品です。eComStation (eCS) は、今年発売開始されたばかりで、「Warp core」の最新のパッチをすべて含んでおり、おまけのツールもいっぱい用意されています。

eCSに含まれているツールの1つが「Desktop On-Call (DToC)」と呼ばれるIBMの製品です。DToCサーバーのWindows版やLinux版も存在しますが、米国内では、なかなか購入できません。DToCの機能は、VNCの機能にかなり似ています。DToCサーバーは、httpプロトコルに相乗りして (それに、デフォルトでポート80を使用して)、ネットワーク (LANかインターネット) 経由でのリモート・デスクトップの役割を果たします。DToCのクライアント・アプリケーションは、JavaScriptとJavaを有効にした任意のWebブラウザーとなります。基本的には、VNC Javaクライアントの場合と同様、Webブラウザーは、DToCへの接続インターフェースとして機能します。ローカルで捕捉されたキーストローク、マルチキー・シーケンス、帯域幅 / 解像度のトレードオフに関して、DToCもVNCとまったく同じ問題を抱えています。

DToCには、VNCよりも優れている点がいくつかあります。セキュリティーの問題は、個別に設定が必要な他のレイヤーや変換器に分散せず、DToCの中にまとめられています。HTTPを流用するということは、DToCがVNCよりも簡単にファイアウォールを通り抜けることを意味します (ただし、これは良いことでもあれば、悪いことでもあります)。さらに、DToCにはファイル転送インターフェースも用意されていますので、DToCを実行しておけば、別途サーバー・マシンでFTPとかSambaとかNFSといったファイル転送サーバーを実行しなくても済みます (VNCの場合には、これが必要になります)。欠点としては、全体的にDToCは、若干VNCよりも応答が遅い感じがします。極めてひどいというのではなく、少し劣るという感じ。

他に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

次に、リモート・マシン上でアプリケーションを起動して実行します。物理的なマシンのところまで行く (もしくは誰かに行ってもらう) こともできるのでしょうが、たいていは、リモート・シェルのセッションをオープンするのが一番簡単なやり方です (ここでは、安全な方法とは言えませんが、 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 を実行してみます (マウス・カーソルに追随して画面に目玉2個を表示するアプリケーション)。

                
[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は、Xサーバーの使用をDelphiにまだ許可していません (ローカルの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ですので、心配なことはありません。しかし、こうした技法を使って、世界を股に掛けて (あるいは1つの町の中のことであっても) リモートのコンピューターを共用しようと考えるなら、VNCやX11のプロトコルは、SSHの上に「階層化」すべきです。そうすることに何の損もありません。SSHは (オプションで) 独自の圧縮層を付加して、性能を高めることもできます。ただ、そのように設定すればよいのです。

VNCの動作環境をSSHの上に設定するには、Making VNC more secure using SSHの記事 (稿末の参考文献参照) を読むのが最善です。よく書かれていますし、私だったら書くだろうことがすべて書かれています。

SSHの上にXを階層化するのは、実に簡単なことです。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デーモンです。

参考文献

• このシリーズの1回目の記事Linux (または異種混合) ネットワークでのコンピューターの共用: 第1回 (developerWorks、2001年12月) では、SSHとVirtual Network Computingを細かく比較分析しています。
  
  
  

• eComStation は、IBM OS/2 Warp/Workspace on Demandの再構築・拡張版で、とくに異種混合ネットワーク環境での快適な動作に力点をおいた製品です。
  
  
  

• XFree86 は、X Windowの実装モジュールとして人気の高いこのフリー・ソフトウェアに関することすべてを知るのに一番のWebサイト です。
  
  
• 技術的なことを言えば、XFree86は、正式なX Windowシステムのクローンです (LinuxがUNIXの「クローン」であるのとほとんど似たようなものです)。実際的な話をすれば、正式ということにこだわる必要はありません。すべてのバージョンがお互い調和して動作します。正式なシステムについては (ソース・コードの入手方法など)、X.orgのホームページ を参照してください。
  
  
• X Windowシステムには、商用バージョンも多数あります。
  • Accelerated-X
  
  
  

• developerWorksに掲載されている他のLinux参考文献もご覧ください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• ネットワーク・セットアップ
• VNCの構成
• Desktop On-CallとeComStation
• リモートX Windowシステム
• セキュリティーの問題
• 参考文献
• 著者について
• コメント