NetBSDでVNC/Virtual Network Computing

NetBSDでVNC/Virtual Network Computing

　VNC機能やVNCソフトウェアとは、UNIX系であるUNIX、Linux、*BSD、Mac OS X/OS XやWindowsなど様々なOSで相互に利用可能なGUIによる遠隔操作(リモートコントロール)を可能とするものです。

　Windowsの場合、Vistaの一部エディションや7などならクライアント用WindowsをVNCサーバとすることもできますが、その場合には、デスクトップを1つしか利用できないという制約から当該マシンのデスクトップそのものが遠隔操作画面に表示され、当該マシン、遠隔操作側何れか一方はロックがかかり、2008や2012のようなWindowsサーバをVNCサーバとする場合には、遠隔操作するモニタ数に応じて別途サーバライセンスを保持していれば、こうした制約もなく利用できる模様、プロプライエタリな有償製品もあるようですが、オープンソース・フリーソフトウェアも多々あります。

　こうした機能を利用する場合、後述のようにVNCソフトウェアを使うか、SSHのX11Forwarding機能を利用するという方法があります。

　ここでは、NetBSDでVNCソフトウェアを使う方法について記します。

VNCソフトウェアを使う

　VNCソフトウェアはVNCサーバとVNCクライアント(ビューワ)から成り、VNCクライアント(X/Win32/Javaの一部、または全て)でVNCサーバが動作するリモートホストのGUI(X/Win32)を遠隔操作することができます。

　リモートでGUI操作する為の通信プロトコルRFB/Remote FrameBufferをベースとしたものならVNCクライアントとVNCサーバは、同一のVNCソフトウェアである必要はありません。

　同様の機能を持つWindows用のオープンソースのRDP/Remote Desktop Protocolをベースとしたものには、この通信プロトコルに対応したVNCクライアントを使うことになります。

　何れにしてもNetBSDの/usr/pkgsrc及びバイナリのリポジトリにも結構いろいろなVNCソフトウェアがあります。

TightVNC・TigerVNC

　当初、同じVNCソフトウェアである必要があるのかと勘違いしていたこともあり、NetBSDでもFedoraが標準採用しているTigerVNCにしようかと確認、バイナリはなかった為、make installしてみたものの、インストールできるまでに至らず、バイナリもあったTightVNCをインストールしてみることに。

　最初は、パッケージ名＋serverやパッケージ名＋viewerというコマンドを想定していたものの、見当たらないのでls /usr/pkg/binを確認するとvncserver、vncviewer他コマンドがあり、manを見るとこれらはVNCソフトウェアのラッパとのこと。

　そこでリモートサーバ側で単にvncserverとしたらdisplayが:1で起動、クライアント側で単にvncviewer　hostname:1としたらリモートホスト側のウィンドウマネージャtwm上にxtermが起動し、xtermからgeditやcajaを起動してみると無事、GUI起動しました。

　manで改めて確認してみるとリモートサーバ側でvncserver :diplay_numberとすれば、クライアント側で同じdisplayを指定してvncviewer host_name:diplay_numberのようにできるとあります。

　一部アイコンが無地(白地)になっていますが、これは、Cajaのみインストールした結果、ファイルマネージャcajaの起動に伴って表示されたmate-desktopであり、Caja用のアイコンテーマを含め、NetBSDにMATEデスクトップをフルインストールしていない為です。

　また、VNC越しのtwm上で常用しているPlumaがなく、何も考えずにgeditを起動したものの、以前からPlumaやKate、KWrite、Leafpad、Mousepadなどでは正常に機能する一方、geditでは、日本語表示は問題ないのに日本語入力ができない事象があり、scimとの相性かと思っていたら、scimを使う他のNetBSDマシンでは起きないことが判明、今回、これに加えてNetBSD同士のVNC越しだと起動したgeditが英語バージョンとなっており、リモートホスト側で直接操作してみると(通常は日本語バージョンなのに)、やはり、geditが英語バージョンとなってしまい、入力メソッドが落ちたのか、日本語が入力できない状態になり、何れもリモートホスト側については再ログインしたら直る(NetBSDからVNC越しにFedoraを操作、geditを起動すると日本語バージョンでかつ、日本語表示・日本語入力共に正常に機能する)という状況はあるにせよ、起動することは確認できました。

　表示させるデスクトップなどの設定は、初めてvncserverを起動させると生成される~/.vnc/xstartup(.vnc/、xstartup共にパーミッションビットは755等)において設定をすればよいようで当該ファイルを直接編集するか、~/.xinitrcのリンクを張るなどすれば、うまく機能する模様。

　そこで試しに、twm &をコメントアウトしてjwm &としたら若干解像度が合っていないようでスタートメニューやタスクバー部分などはスクロールする必要がありましたが、JWMが起動し、GUI起動はもとより、日本語入力もできるようになりました。

　もし、日本語表示や入力ができない(~/.xinitrcのシムリンクだとうまくいかない、$HOME/.xinitrcなどがうまく読み込めない...etc.)場合には、$HOME/.xinitrcの該当する設定部分を~/.vnc/xstartupに追記するという手もあります。

　が、ここでgnome-session &やstartxfce4 &としてみても、なぜか起動しません。。。ちなみに前者はリモートホスト側で、後者はクライアント側で使っているデスクトップで(前者の結果から、もしかしてクライアントのリソース使ってるのか！？と深読みしてて試しにやってみただけ)、前者だと閉じるボタン付きで[Could not acquire name on session bus]というメッセージのポップアップが表示され、後者だとグレー一色で何も起こる気配がありません。

　このメッセージをキーに調べてみるとhttp://mitsuakikawamorita.com/blog/?p=1185のxstartupにその対策として[unset DBUS_SESSION_BUS_ADDRESS]とするとあり、やってみたら、GNOMEが起動、日本語入力も問題なくできるようになりました。(当然ながらリモートホストにインストールされていないxfce4は起動しない。)

　ただ、twmやjwm、Xfce4では問題ないのでGNOME固有(ちなみに試したのはGNOME2)の問題のようですが、[s]と[h]がショートカットキーとなっているようで前者ではメニューが開き、後者では開いたソフトウェア画面がタスクバーにしまわれてしまうという状況でキーバインド・キーマップが変。。。この2つのキーは意外と重要であれもこれもできなくなってしまう。。。XKL_XMODMAP_DISABLE=1なども試してみましたが、解決に至らず、調べてもよくわかりませんでした。

　ちなみに検証時、無線LAN接続しているノートパソコン/NetBSD上のXfce4にはxfce4-netload-pluginやxfce4-wavelan-pluginを入れているのですが、VNCクライアント上のXfce4でも受信感度や送受信サイズをリアルタイムで確認でき、VNC接続におけるデータの送受信があるようで何もしていなくても受信が1〜2KiB、送信が22KiB前後でひっきりなしに通信が行なわれています。

　先の画像では、解像度が若干あっていないのでスクロールバーが表示されていますが、例えば、コマンドライン上でvncserver :display_num -geometry WIDTHxHEIGHTとすれば、任意の解像度を指定することができ、起動したvncserverを終了するには、リモートホスト側でvncserver -kill :display_numとします。

　尚、-geometryで解像度を指定してVNCサーバを起動、vncviewer側で何らかのソフトウェアを開いたり、編集し、VNCを終了した後、リモートホスト側で先に開いたソフトウェアを起動すると(リモートホストのモニタの実際の解像度と-geometry指定したVNCの解像度が異なる場合、顕著にわかるが、)VNCで-geometry指定したサイズになっていたりします。

　ちなみにvncviewer側では、サウンドの出力はできず、一方、YouTubeやGyao!などの動画は再生できる(音声は出ない)ものの、カクカクしたり、スローモーション状態になったりします。

　また、この例は、NetBSD上でウィンドウマネージャをJWMとしてTightVNCのvncserverを起動し、Fedora上で、TightVNCの派生であるTigerVNCのvncviewerでリモート表示したものですが、OSの違いはもとより、リモートでGUI操作する為の通信プロトコルRFB/Remote FrameBufferを使ったものであれば、このようにリモートホスト側とローカル側で必ず同一のソフトウェアを使わなくてもリモート操作可能となっています。

　FedoraのTigerVNCサーバ、NetBSDのTightVNCクライアントだとなんでできないんだ。。。と思っていたら、後述のSSHポートフォワーディングでその必要もなくなったものの、vncserverを直接起動させている時点では、Fedora上のファイアウォールでブロックされていただけでファイアウォール設定でvncを通したらできました。

　*BSD/PC-UNIX/Linux上のVNCサーバにMac OS XやWindowsをVNCクライアントとすることもできる一方、サーバライセンスが必要になる模様もWindowsをVNCサーバとする場合には、Windows固有のRDP/Remote Desktop Protocolを使ったVNCサーバ用のUNIX系用VNCクライアントとしてrdesktopや、その派生であるFreeRDPがあり、これらもNetBSDのリポジトリにあります。

　これらに加えてNetBSDのリポジトリには、gtkベースの簡易GUIパネルやフロントエンド、VNCセッションをflash動画として記録するソフトウェアなどもあります。

　当初、遠隔ユーザーサポートしかイメージしていなかったのでリモートデスクトップって。。。と思っており、今回のようにリモートホストの物理モニタ上に表示されているデスクトップとは別のデスクトップを使って利用できるなんて思いもよりませんでしたが、単に自身の理解不足により様々な利用シーンをイメージできていなかっただけでssh(トンネル)も使えますし(というか使うべきですが)、ここまでできるとビジネスシーンだけでなく、パーソナルユースでも結構便利だと今更ながら思うに至った今となってはSSHポートフォワードを使って頻繁に利用しています。

SSHトンネル／ポートフォワーディング

　SSHトンネル(ポートフォワード・ポートフォワーディング)とは、IPv4プロトコルにおいて通信が暗号化されない任意のサービスを通信が暗号化されるSSHを通して利用することで安全性を高めることができる機能で、その場合、SSHで通信できる状態であれば、SSHのポートを使って通信が行なわれる為、ポートフォワードによってSSHを通したいサービスのポート自体は開ける必要がないという副産物もあります。

　当然のことながら、あらかじめ、VNCサーバを起動しておきます。

　SSHを介す方法は、リモートホスト側から、ローカルホスト側から、更にその指定によって、一通りではありませんが、例えば、次のようにするだけです。

　そして端末からVNCクライアントとするローカルホスト上でsshコマンドをローカルの空きポートとリモートホストのVNCサーバ用のポートを1つのコロン区切りで紐付けて実行させておきます。

　この[-N]スイッチは、SSH2で利用可能な「遠隔操作を実行しない」指定であり、結果、リモートホストにログインもせず、VNCサーバがマシンの起動と同時に有効かつ起動している場合などに最適なオプションで、もし、VNCサーバが起動していない場合には、このスイッチを指定せずにログイン後にVNCサーバを起動させた状態にして下記の操作へ、また、サーバマシン・クライアントマシン共にユーザー名が同名なら[-l username]は省略可能、名前解決済みならIPアドレス部は、ホスト名でも可です。

　尚、標準のListenポートは、NetBSDのmanによるとTightVNCが5500+1～、FedoraのmanによるとTigerVNCが5900+1～となっていますが、NetBSDのTightVNC同士でポートフォワーディングせずにvncserver/vncviewerを実行するとポート番号は5901〜でないと機能しないのでNetBSDのman TightVNCの誤記？のようです。

　次に同じくVNCクライアントとなるローカルホストで別途端末を開いてvncviewerで先ほど紐付けたローカルホスト(自マシンで自マシン)のポートを指定します。(この場合、ssh実行も指定ポートもVNCサーバ側でないことに注意。)

　これでリモート画面が表示されれば、通信内容が暗号化されているので、より安全にリモート操作できるようになります。

　終了させる場合には、sshを実行中の端末で[Ctrl]+[c]とします。

関連リンク