Ubuntu 10.04 にVNCをインストールしてみた

以前、Ubuntu 8.04にVNCをインストールしてからは安定して動いていたのでOSのバージョンアップとかはしていなかった（以前のメモ→“VNCサーバの設定”）。Ubuntuの新LTSも出たので新規にUbuntu 10.04にVNCをインストールしてみたのだが、色々と変わっていた。特にダメダシは“ここ”ということで、なんと10.04のGNOMEではXDMをサポートしてない。つまりvino（Ubuntuではリモートデスクトップと呼んでいる、Windowsで言うところの“リモートアシスタンス”）はサポートしているが、XDMを利用したXvnc（Windowsで言うところの“リモートデスクトップ”）はサポートしなくなってしまった。言い換えると、現在ログインしている状態であればVNCを使ってアクセスできるが、ログイン待ちの状態ではアクセスできないということになる。これではリモート（外出先）から頻繁にアクセスする私としては大変困ったことになる。場合によっては、またUbuntuからFedora（もしくはWindows7）に切り替えなければならない。

で、色々試したみた。まず、10.04（のGNOME）がサポートしていないというのは、単にバグの様だ（ただし、バグレポートの履歴を見ると、信じられないことにGNOMEの開発チームは当初は本気でサポート（修正）する気はなかった様に思える）。試してみると、実は64bit版では問題なく動く。また32bit版でも動く“場合がある”。32bit版では、どのような条件で動かなくなるのか再現性がないのでイマイチわからなかったが、確かにうまくいくこともあった。

将来、バグが修正されることを祈りつつ、64bit版での設定方法と、32bit版でのVINOを利用した回避策についてメモしておく。

■ Ubuntu 10.04 amd64での設定

Xvncの設定方法は色々あるが、ここではXDMCPを利用してログイン画面へ接続して、任意のユーザでログインする方法だけをメモっておく。（なお、以下の操作はroot権限で実行している。予め“sudo -s”でroot権限になっておく。）

先ずは、次の2つのパッケージをインストールする。

# apt-get install xinetd
# apt-get install vnc4server

Xvncはinetdを使わないで/etc/rc.localあたりから直接デーモン化して使うこともできる。inetdは昔、昔、UNIXのメモリが貧弱だったころにデーモンをメモリに常駐化しない手法として編み出された機能だが、現在のようにメモリがふんだんにあるマシンでは必要ない。出来れば不要なパッケージは入れたくないので、最初はXvncを直接起動する方法を試したが、Xvnc自身がUpstartやinitに対応していないので、サービスの一時停止や再起動に手間がかかり運用上は結構面倒なことになる。そこでXvncだけのためにinetdをインストールするのもイマヒトツではあるが、今回もinetdを使うことにした。

また、UbuntuのXvncには“tightvncserver”というパッケージと“vnc4server”がある。実際に使って比較したわけではないが、ネットで調べてみるとtightvncserverは問題があるといった書き込みがいくつかあったので今回もvnc4serverを採用した。

次に、/etc/xinetd.d/Xvncを作成する。

service xvnc
{
	disable		= no
	socket_type	= stream
	wait		= no
	user		= nobody
	server		= /usr/bin/Xvnc
	server_args	= -inetd -geometry 1024x768 -depth 16 -desktop Ubuntu_1004 -PasswordFile /etc/passwd.vnc -once -query localhost
}

server_args行で“-inetd”までが“オプション”、“-geometry”から“-PasswordFile”までがパラメータ、“-once -query localhost”はxinitに渡す引数、ということで、今回は順番に分けて記述した。パラメータの“-geometry 1024x768 -depth 16”はデフォルトなので省略可能。以前（Ubuntu 8.04）の様に隠しオプション“-extension XFIXES”は必要なくなった。

Xvnc起動時のユーザは“nobody”とした。ネットでは“root”とするケースも見られたがセキュリティの観点からnobodyの方がベターだろう。今回はgroupは省略した。（group省略時にはユーザの標準のグループ（この場合はnogroup）となる。ちなみに以前は“tty”とした。私としては一応、それなりの理由はあったのだけども。（ネットのVNCの解説を見ていると何故かグループを“tty"にしているのが多かった。次のパスワードファイル名も/etc/passwd_vncだったりして。苦笑））

/etc/xinetd.d/Xvncではポート番号を指定してないので、サービス名として/etc/servicesの方で定義する。 /etc/servicesに次の行を追加する。

xvnc	5900/tcp

一応、検証確認したのだけど、vino（Ubuntuの表現では“リモートデスクトップ”）を“有効”にしていてもXvncのポート番号は5900でOKだった。vinoが有効な場合、vinoはポート5900番を使うが、サーバで誰もログインしていない状態（つまりvinoがまだ起動していない状態）で5900番へアクセスするとvinoではなくXvncへつながる。Xvncは“:0”以外のディスプレ（例えば、:1や:2）を割り当てて、そのディスプレへのアクセスになる。これはバグの副作用かどうが分からないが、大変便利だ。リモートからアクセスする方は一々ポート番号を変えなくて済む。

次に、VNCのパスワードを設定する。

# vncpasswd /etc/passwd.vnc
Password:
Verify:
# ls -l /etc/passwd.vnc
-rw------- 1 root root 8 2010-08-09 22:06 /etc/passwd.vnc
# chown nobody\: /etc/passwd.vnc 
# ls -l /etc/passwd.vnc
-rw------- 1 nobody nogroup 8 2010-08-09 22:06 /etc/passwd.vnc

今回は“/etc/passwd.vnc”にした。以前は“/etc/passwd_vnc”だったが、やはり“_”で区切るより、“.”で区切る方がスタイルだと思う。（実は以前も悩んだのだけども。あるOSだと“_”だと“一語”としてみなしてくれるので、コピペをする際に便利かと思って。）

そして、/etc/gdm/custom.confを作成する。内容は以下の通りシンプル。

[xdmcp]
Enable=true
DisplaysPerHost=2

以前（Ubuntu 8.04の頃）では“/etc/gdm/custom.conf”ではなく“/etc/gdm/gdm.conf-custom”だったが、最近のGNOMEではファイル名が変わったらしい。

最後に“vncconfig”をXvncと同時に起動するように設定しておく。vncconfigが動いてないとクライアントとサーバ間でコピー＆ペーストが出来ない。一々、手動でvncconfigを起動するのも気が利かないので、自動的に起動するようにする。この方法はマニュアル等には出ていないので、どのファイルで設定すれば最適なのか今ひとつ迷ったが、多分 /etc/gdm/PostLogin/Default に設定するのが正解だと思う。 /etc/gdm/PostLogin/Defaultを以下の内容で作成する。

#!/bin/sh
#

vncconfig -nowin &

以上の設定が終わったら、デーモン（xinetdとdgm）を再起動する。

# service xinetd restart
 * Stopping internet superserver xinetd                                            [ OK ]
 * Starting internet superserver xinetd                                            [ OK ]
# service gdm restart
gdm start/running, process 2468

■ Ubuntu 10.04 i386での設定

64bit版と同様の方法で設定しても32bit版では、上手く接続できる場合と失敗する場合がある。（圧倒的に上手くいかない場合の方が多い。リモートからの操作で、それは致命的だ。）
そこで、仕方なく将来バグが修正されることを祈りつつ、次のような方法でしのいだ。

  • vino（Ubuntuの言う"リモートデスクトップ”）を使う。"リモートデスクトップ”の設定でアクセス＆コントロールできるようにしておく。
  • vncを使ってログインの制御は出来ないので、"ログイン画面”設定でシステム起動後、特定のユーザに自動ログインするようにしておく（そして、vinoでのアクセスが可能となる）。
  • キーリング（パスワードへのアクセス制御）を無効にしておく。

最初の2つについては、特に説明いらないだろう。最後のキーリングの設定についてだけメモしておく。
ネットで調べてみるとキーリングは随分と評判の悪い仕組みのようだ、特にVNCユーザにとっては。“リモートデスクトップ”設定画面で“アクセスの確認をしない”を選択（チェックを外した状態）しておいてもリモートからvncのアクセスがあると、パスワードへのアクセスのためにパスワードと聞いてくる（“リモートデスクトップ設定画面”で設定したのと同じパスワードなのだけども）。つまり、サーバ側で誰かの介入がないとリモートからはアクセスできない。リモートアシスタンスなら分かるが、リモートデスクトップとしては大変使い勝手が悪い。

しかし、これを回避する方法がなかなか分からなかった。試行錯誤の上、次の様にして回避した。（以下、メニュー名などが英語になっているが適宜日本語に読み替えて欲しい。私はLinuxを英語版で使っているので。）

  1. "Applications" > "Accessories" > "Password and Encryption Keys"を開く
  2. "File" > "New" から "Password Keyring"を選択して"Continue"
  3. 適当な名前、例えば“vino”を入力して"Add"。ここでパスワードを聞かれるが入力せずに"OK"。“安全でない”確認が出るが、"OK"する。
  4. "Passwords:vino"を選択してマウスの右ボタンメニューから"Set as default"（日本語だと“デフォルトに設定”かな）を選択。
  5. 一旦、"Password and Encryption Keys"を閉じる。
  6. 再度、リモートデスクトップ設定画面でパスワードを入力しなおす。
  7. "Password and Encryption Keys"を再度開くとデフォルトの"Passwords:vino"にvinoのパスワードキーが登録されている。
  8. 再び"Passwords:login"を"Set as default"（日本語だと“デフォルトに設定”かな）に戻して終了。

要約すると、キーリングは目的ごとに複数設定できるが、パスワードへのアクセスにパスワードを聴かれないキーリングを用意して、そこにvinoのパスワードキーを登録してしまう、という方法。これが正解かどうかは分からないが、今のところ気分よく使えている。（もちろん、リモートからアクセスする際にはvinoのパスワードを聞かれる、しかし、サーバ側でのユーザの介入は必要ない。）