時々VNCを使うだけであれば、以上の設定で十分ではないかと思う。しかし、幾つかの欠点もある。まず、VNC使用時は、先にtelnetなどでLinuxに接続してからVNCサーバを起動、VNCを使い終わったら再びtelnetなどでVNCサーバを停止させる必要がある(個人環境であればVNCサーバを起動させたままでもよいかもしれないが)。また、セキュリティ的に脆弱であることも気になる。一応暗号化されているとはいえ、パスワード以外にアクセスを制限する手段がないのである。
そこで思い起こされるのがinetdの存在だ。inetdはクライアントからのリクエストに応じて必要なサーバを起動させるもので、常駐させておく必要のないサーバ類(telnetなど)はinetd経由になっている。また、inetdを使えばTCP Wrapper(tcpd)で経路によるアクセス制御を行うこともできる。VNCサーバにアクセスできるマシンを特定のIPアドレスやネットワークで限定すれば、セキュリティを大幅に強化できる。いずれにせよ、インターネットからアクセスできるマシンでVNCを利用するのはオススメできないが……。
VNCサーバをinetdから起動できるようにできないだろうか? そう考えたのがAndre Moreira氏である。同氏は、VNCをinetd経由で起動させるiXvnc patch for VNC X-Server(http://www.dei.isep.ipp.pt/~andre/extern/ixvnc.htm)というパッチを作成した。パッチ登場時はVNCをソースで入手して、このパッチを当ててからコンパイルする必要があった。しかし、VNCの最新版である3.3.3R2からはこのパッチが取り込まれたため、これまでの手順でインストールしたバイナリ版はすでにinetdに対応しているのである。前編の始めで「ソース版は必要ない」と書いた理由はここにある。
VNCサーバをinetd経由で起動するためには、若干設定の追加が必要だ。
まず、rootになって/etc/servicesに以下の内容を追加する。
vnc-800x600x8 5950/tcp vnc-800x600x16 5951/tcp vnc-1024x768x8 5952/tcp vnc-1024x768x16 5953/tcp
/etc/servicesは
サービス名 ポート/プロトコル
という書式になっている。「vnc-800x600x8」などの部分は任意に設定するサービス名であり、上記のとおりにする必要はないが、この後で設定する/etc/inetd.confの記述もそれに合わせて変更すること。また、ここでは4つのサービスを追加したが、1つだけでもよいし、さらに増やしてもよい。ポート番号を重複させないことにだけ注意。
次に/etc/inetd.confの設定だ。/etc/inetd.confに以下の内容を追加する。
vnc-800x600x8 stream tcp nowait nobody /usr/local/bin/Xvnc Xvnc -inetd -query ホスト -once -geometry 800x600 -depth 8 -cc 3 vnc-800x600x16 stream tcp nowait nobody /usr/local/bin/Xvnc Xvnc -inetd -query ホスト -once -geometry 800x600 -depth 16 vnc-1024x768x8 stream tcp nowait nobody /usr/local/bin/Xvnc Xvnc -inetd -query ホスト -once -geometry 1024x768 -depth 8 -cc 3 vnc-1024x768x16 stream tcp nowait nobody /usr/local/bin/Xvnc Xvnc -inetd -query ホスト -once -geometry 1024x768 -depth 16
「vnc-800x600x8」などは、/etc/servicesで指定したサービス名。両者の対応がとれていないとVNCを起動できないので注意すること。「/usr/local/bin/Xvnc」はVNCサーバ(Xvnc)のパスである。
以降はVNCサーバを起動させる際のパラメータ指定だ。
-inetd
Xvncをinetd経由で起動させるオプション(必須)
-query ホスト
XDMCP(X Display Manager Control Protocol)を使ってユーザー認証を行う指定。「ホスト」は、VNCサーバが動作するマシンを指定する。筆者の場合はIPアドレスにした。
例:-query 192.168.33.8
-once
xsessionが終了した時点でVNCサーバを終了させる
-geometry 800x600 -depth 8 -cc 3
仮想Xデスクトップのサイズと色数の指定。-depth 8の場合は-cc 3も追加する
XDMCPでユーザー認証を行わせるため、Linuxをグラフィカルログインに変更しておく必要がある(テキストログインにしていた場合)。ディストリビューションによってグラフィカルログインに使うディスプレイマネージャはxdm、kdmなどさまざまだが、筆者が使っているLASER5 Linux 6.4の場合はGNOMEのgdmなので、これをそのまま使うことにする。
LASER5 Linux 6.4のデフォルト設定では、XDMCPが無効になっているので/etc/X11/gdm/gdm.confの以下の部分を編集して有効化する。
[xdmcp] Enable=1
これで準備は完了。後はLinuxをランレベル5で起動してグラフィカルログイン化する。グラフィカルログイン化する方法は、Linux Tipsの「テキストログインとグラフィカルログインを切り替えるには」を参照していただきたい。
なお、筆者の環境ではこれだけで問題なく接続できたが、これだけではうまくいかないというケースを聞いたことがある。VNC経由でグラフィカルログインしてもLinuxのデスクトップ画面が表示されない場合は、/etc/X11/gdm/gdm.confの[daemon]セクションにある
KillInitClients=1
を
KillInitClients=0
に変更してみよう。
あれは大学時代、バイトで某所の深夜警備員をしたときのこと……は別の機会に譲るとして、gdmの話である。
gdmの設定を変更するためにgdm.confを編集した際、ちょっとした入力ミスを犯してしまった。それに気付かず、そのままランレベル5に変更したときに「それ」は始まった。
一瞬テキストのログインプロンプトが見えたかと思った瞬間に画面が切り替わり、次の瞬間にはまたログインプロンプトが一瞬見える、という状態が繰り返されるだけになってしまったのだ。gdmの起動→失敗→gdmの起動というループに陥ったと思われる。
設定ミスは一目瞭然だが、これではログインできない。そこで、ノートPCからsshで接続しようとしたところ、sshでの接続まで失敗してしまう。telnetでの接続が可能だったので、gdm.confを直してリブートをかけることで事なきを得たが、もう少しでfsck覚悟でリセットする羽目に陥るところだった。普段はtelnetを殺しているのだが、このときはたまたま別のテストのためにtelnetを生かしておいたのが幸いした。
ログインまわりの設定をいじるときは、別の手段も用意しておくべきだということを学んだ夜であった。
VNCサーバをinetd経由で起動させる場合、Windowsからの接続方法も若干異なる。もちろん、「vncserver :1」などとして、あらかじめVNCサーバを起動しておく必要はない。
Windowsから接続する際は、まずWindows側でVNCビューアを起動する。接続先を問い合わせるダイアログボックスが表示されたら、従来のディスプレイ番号の代わりに/etc/servicesに記述したポート番号を指定する。ただし、ポート番号は5900を引いた下2けただけにする。
例えば、/etc/servicesに
vnc-800x600x8 5950/tcp vnc-1024x768x16 5951/tcp
という設定を追加しており、800×600ドット 8bitsカラーでVNCサーバを起動させるには、「192.168.33.8:50」と指定する(IPアドレスは環境に応じて読み替えること)。1024×768ドット 16bitsカラーにするなら「192.168.33.8:51」だ。
接続先を指定すると、パスワード入力ダイアログボックスをパスしてgdmの画面になる。
ここでLinuxのユーザーアカウントとそのパスワード(VNCで設定したパスワードではないことに注意)を入力する。
なお、あらかじめvncserverでVNCサーバを待機させておく方法とinetd経由で接続時に起動させる方法は共存できる。VNCビューワで「192.168.33.8:1」のようにディスプレイ番号を付加した場合は待機していたVNCサーバが、「192.168.33.8:5x」としてポート番号を指定した場合はinetd経由で新たにVNCサーバが起動する。共存させる意義には疑問がないでもないが。
Copyright © ITmedia, Inc. All Rights Reserved.