xon(1)使用時の落とし穴

-- "It won't work!" "Nobody is responsible but YOU."

xon(1) を使っていると、初めのうちはうまく動いてくれなくて 苦労します。 エラーメッセージが出ないので初めのうちはワケワカランことも。 でも、一歩ずつ問題を潰していけば使えるようになるはずです。

$Id: xon.html,v 1.3 2000-12-01 00:13:10+09 kabe Exp $

▼xon(1) は rsh(1)である

(HP-UXユーザーはremshに読み変えましょう)

xonのコードを見てもらえば分かりますが、 これは実はシェルスクリプトです。 内部的には 

	% rsh remotehost xterm -display $DISPLAY
を、さらに(かなり？)細工しているだけです。 ですから、上のrshが正常に実行できれば xonも使えるはずです。

xon がやっている細工の大部分は、ローカル側の rsh、リモート側の sh を残さずに xterm だけを動かすようにするもの。 自分でこれをやってみるのもいい勉強になります。
エラーメッセージが出ないのは stdout などをここで全部捨てているからです。

▼.rhostsは正常か？

まず 

	% rsh remotehost date
が使えるかどうか試してみましょう。 xonを使おうと思っているレベルの人ならこれが動かない ということはまずないと思いますが、 使えない場合は rlogin のマニュアルを参照して リモート側の~/.rhostsを設定しましょう。

▼xauthorityはどうか？

rshがうまくいったら、今度はリモート側に rlogin し、 

	remote% kterm -display mydisplay:0
を試してみます。
・正常に出た
…ならふつーにxonを使っても大丈夫なはずですが…
ありがちなのは、rlogin と rsh で PATH が違うというもの。

・kterm Xt error: Can't open display: mydisplay:0
mydisplayの IPアドレス が索けないということです。 FQDN (mydisp.mydomain.ac.jpな形式) で書いてみましょう。 それでもダメなら直接 IPアドレス:0 でやってみる。
サイトの方針で、外部からのＸ接続を許していない場合もあります。 IPアドレスでもつながらないようならあきらめるか、 ファイヤウォール上でＸプロトコルを中継する手段を用意します。

・Xlib: Client is not authorized to connect to Server
Xauthorityが かかってますね。 簡単に回避するにはローカル側 (XDMならログインホスト) で 
	local% xhost +
とすればつながるようになります。 が、「セキュリティを無効にする」ことなので、本当は好ましくありません。 抜本的な対策はここでは述べませんが、 xauth(1)にある例や Xsecurity(1)のマニュアルを参照して下さい。

▼リモート側に渡るDISPLAYは？

ローカル側のDISPLAY環境変数がすでに FQDN であれば (Ｘ端末ではそう設定されていることがある) xonは使えるようになっているはずですが、 FQDN でなかったり、コンソール (DISPLAY==":0.0") では まだ問題が生じることがあります。

▼コンソール (:0.0)でうまくいかない

xonのコードを見てもらえば分かりますが、 DISPLAY が ":0" や ":0.0" といった場合、リモート側には 

	`hostname`:0
が -displayの引数として 渡ります。

ここで、`hostmame`が FQDN でないような場合 (ノード名だけ…BSD4.3以前のOSなど)、 これのIPアドレスがリモート側で索けないとうまくいきません。 

	local% rsh remotehost ping `hostname`
	ping: unknown host local
このような場合の解決方はいくつかあり、
・リモート側で FQDN でなくても索けるようにしてもらう…
リモート側の/etc/hostsに登録してもらうのが割と簡単です。 が、これを歓迎しない管理者もいますから、

・ローカルの`hostname`に FQDN を入れてもらう
BSD 4.4以降はそうなっているらしいです。 でも安易にやると他のアプリケーションが発狂することも… やってみて「手に負えん」と感じたら戻しましょう。

・xonをいじる
`hostname`の部分を `hostname`.your.domain.ac.jpに 書き換えてしまいます。 (`domainname`は意味が違うので使用不可)

自分の FQDN を得る方法というのは、実をいうと「美しい」 方法がないので、こうせざるを得ない部分があります。 (だから`hostname`にFQDNを入れておく)

・DISPLAY=123.45.67.8:0にしてしまう…
・DISPLAY=FQDN:0 にしてしまう…
これでもいいです。しかし、そうすると手元のマシンで 動かすアプリケーションもすべて TCP でＸサーバーにつなぐようになります から、あまり効率が良くありません。 ":0.0" や "unix:0" では TCP ソケットを使わず、 UNIX domainのソケットを使うので効率が良く、 なるべくならそのままで使いたいところです。

▼Ｘ端末でうまくいかない

上のコンソールの事例に準じますが、DISPLAYが FQDN になっていなければ LAN 内 (/etc/hostsの勢力範囲) でしか xon できないことがあります。
.xsessionで FQDN に加工したり、IPアドレスを直に入れてしまうのがいいでしょう。

Ｘ端末なら :0.0 は あり得ないので、UNIX socket 云々は 関係ありません。

▼ウィンドウマネジャからだと起動できない

プロンプトからだと xon できるのに、twmなどのメニューに仕込むと 起動できないというような場合。 一番ありがちなのは、

{.xsession,.xinitrc} で PATH を設定してますか？

いわゆるデスクトップ環境なウィンドウマネジャならこのへんも めんどう見てくれますが、プリミティブなものを使っていたり、 .cshrcをいじり倒していて.xsessionと食い違って来たような時に 現れます。 (PATH=`$SHELL -c 'echo $PATH'` とかやるのが簡単かな)

…もっともこういった場合はメニューに仕込んだ普通の Ｘアプリケーションも起動しないはずなので xon 以前の段階で 悩んでるとは思いますが…

かべ＠dais.is.tohoku.ac.jp