SourceForge.JP: Open Source Software

私たちが最初に考えた候補は、標準Unixユーティリティのscriptを使ってログをとるという案だ。しかしscriptはいくつかの問題点を抱えている。例えば、結果の出力がすさまじい（scriptは、キャリッジリターンや訂正を含めた何から何までを保存する）という、無視しがたい問題点がある。加えて、scriptではインタラクティブ性が完全になくなる。同僚が質問したかったり、説明を必要としたら、後から電子メールでのやり取りが必要になっただろう。これでは彼にとっても私にとってもイライラが募る。

次に検討した候補は、VNCだ。VNCを使った場合、同僚が私のディスプレイへと接続し、彼と私とで、マウスとキーボードを交互に使うことになる。しかしこの方法は過剰に思えた。というのも、私が見せたかったのは純粋にコマンドラインでの作業だったからだ。それにVNCセッションのログを生成するのもややこしいことになっただろう。さらに技術上の制約から、このデモのために彼が私のマシンへと接続する唯一の方法が単純なSSH接続であったため、解決法は純粋にコマンドラインのものである必要があった。

最後に辿り着いた候補はscreenだ。最終的に私たちはscreenを使うことに決めた。screenは、口で説明されてもピンと来ないが、実行されているところを見れば、その非凡さに驚嘆するという類いのツールの一つだ。screenの公式ウェブサイトの説明を見ても今一分かりにくい。

screenは、物理端末を複数のプロセス（典型的にはインタラクティブシェル）間で多重化する、フルスクリーンのウィンドウマネージャです。

基本的にはこういうことだ。screenを使うと、実際のxtermやコンソール画面へと接続されていない、仮想的な端末を作成することができる。そしてシェルとそのシェル上で実行中のプロセスを保存しつつ、screenのセッションから接続を切ったり、どこか別の場所から再接続したりすることができる。（screenの入門としては、このLinux.comの記事を参照のこと。）

しかもこれは、screenのパワフルさや柔軟性のほんの一端でしかない。例えば、screenに引数-xを与えると、1つのscreenセッションに複数のプロセスから接続が可能になる。つまり、例えば仕事場で（screen上の）端末内で実行しているメールプログラムをそのままにしておき、家に帰って家から接続しても、同じプロセスを使って仕事場での続きからメールを読むことができるということだ。仕事場で接続を切る必要はなく、翌朝、仕事場に戻ってきたときには、家で変更した全状態が完全に反映されていて、昨夜、家で最後にメーラを使った状態がそのまま再現されている。

この機能は「マルチディスプレイモード」と呼ばれているものだが、screenではそれをさらに発展させて「マルチユーザモード」と呼ばれるモードも備えている。「マルチユーザモード」では、二人以上のユーザが同じ一つのscreenセッションへと接続し読み書きすることができる。ただ、このモードが抱える問題点は、セットアップの方法が分かりにくいということだ。そこで以下に、Googleサーチにも助けを借りてやっとのことで把握したことを示す。

1. screenのバイナリ（/usr/bin/screen）をsetuid rootに設定する。screenはデフォルトでは、（セキュリティホールになる可能性があるため）setuidビットがオフの状態でインストールされている。

2. 教師側がscreenを（例えばscreen -S SessionNameとして）ローカルのxtermで起動する。-Sスイッチによりセッションに名前が与えられ、複数のscreenセッションの管理が楽になる。

3. 生徒側が、SSHを使用して教師側のコンピュータに接続する。

4. 教師側が、Ctrl-a :multiuser on（screenのコマンドはすべてscreenのエスケープシーケンスであるCtrl-aから始まる）というコマンドによってscreenのセッション内でのマルチユーザアクセスを許可する。

5. 教師側がCtrl-a :acladd student （studentは、生徒のログイン名）とし、screenセッションへのアクセスを生徒側ユーザに対し許可する。

6. ここまでで生徒側が教師側のscreenセッションに接続することが可能になった。実際に接続するには、（自分のscreenセッションではなく、他のユーザのセッションに接続することになるので、ユーザ名を指定して） screen -x username/sessionとする。

この時点で教師側と生徒側の両方がセッションの読み書きをできるようになったことになる。ただしこれにはセキュリティ上の問題が潜んでいることに注意しよう。生徒が教師同様にセッションに読み書きすることができるので、もしかしたらシステムにダメージを与える何らかのことを生徒が行なうことができてしまうかもしれない。自分の生徒を信頼できない場合には、おそらく、いつも使っているログインアカウントとは別の、特別な教師用アカウントを使用するべきだろう。あるいは、生徒からは教師のセッションの読み取りのみを可にしておくことも一つの手だ。そうするためには、「Ctrl-a :aclchg student -w "#"」のように、screenのコマンド「aclchg」を使用して生徒の書き込み権限を削除する。これにより生徒は教師の動作を見ることのみができるようになる。そうようなことをしない場合、教師は生徒を完全に信頼して自由に作業させる、ということを意味する。

ここでの例は教師側と生徒側がそれぞれ一人ずつの場合に基づいているが、1つのセッションには複数のユーザが接続することもできる。教師側と生徒側をともに複数人にすることも可能だ。

さて、教師と生徒との質疑応答はどうするのか？まあ私たちの場合は電話を使ったのだが、インスタントメッセージやIRCやVoIPを使って質疑応答を行なうことも可能だろう。また、screenのマルチユーザセッションにはメッセージ機能も用意されている。Ctrl-a :wall messageとすることで、同じscreenセッションに接続している全ユーザに対してメッセージを書き込むことができる。screenのメッセージ機能を使用する上での問題点は、端末状態行（terminal status line）を使用するということだ。xtermの場合、端末状態行はウィンドウのタイトルバーの場所に当たるため、ウィンドウマネージャによっては分かりにくいかもしれない。

screenを指導用ツールとして使用するための最後の仕上げはログだ。同僚と私には端末の全出力のログがあったため、後で疑問が湧いた場合でも自分達が行なったことの正確な記録があった。前述したように、標準Unixツールのscriptを利用するというのも確かに一つの手ではあるが、scriptは非常に貧弱なツールであり、あまり読みやすい出力をしない。また、例えばテキストエディタのようなフルスクリーンのツールを実行したい場合に、セッション内でログ機能のオン・オフを切り替えることができない。

幸いにもscreenにはscriptよりも洗練され充実したログ機能がついている。screenのログ機能では、Ctrl-a Hでいつでもオン・オフを切り替えることができる。あるいは-Lスイッチを使用して、最初からログ機能をオンにした状態でscreenを起動することもできる。ログファイルは、「screenlog.n」という名前でカレントディレクトリに生成される（nは、新しいログファイルになる度に1を増加した数になる）。

ログファイルの中身には、セッションで出力された文字がすべて含まれていて、評価・適用済みの訂正やカーソルを移動するための文字も含まれている。一つ注意すべきことは、画面に制御シーケンスを送るプログラムが出力を混乱させてしまうことがまだあるということだ。この例としては、デフォルトで出力に色を付けるGNU lsがある。以下のようなbashのエイリアスを使って、この機能をオフにしておくと良いだろう。

 alias ls='ls --color=none'  

以上で、すべての準備が整った。あらゆるコマンドラインベースの命令について、複数のユーザでscreenのセッションを共有することができるようになった。また、教師はいつでも、他のユーザ（生徒）のアクセスを読み取りのみ可に変更してセッションへの書き込み権限を自分だけが持つようにすることができるようになった。さらに、screen内でのログ機能をオンにして、セッション全体（あるいは、そう望むなら、セッションの一部のみ）の正確で便利なログを得ることができるようになった。

遠隔教育という今回の目的のために、screenはきわめて有効に働くことが分かった。そして同僚もその結果に満足した。screenは非常にパワフルで柔軟であるため、screenの一部のオプションや使い方は分かりづらい。しかし私はこのツールをこれからも使っていこうと思っており、同様の状況にある方々にも是非お奨めする。

NewsForge.com 原文