# Using expect to Automate System Administration Tasks > [!abstract] 概要(Abstract の日本語訳) > UNIX システム管理は、対話的用途のみを想定して設計されたプログラムを使うことをしばしば伴う。passwd や su のような多くのプログラムは、シェルスクリプトに組み込むことができない。fsck や dump のようないくつかのプログラムは特に対話的ではないが、自動化された利用へのサポートが乏しい。 > > expect は対話的プログラムと「対話」できるプログラムである。対話を導くためにスクリプトが使われる。スクリプトは高水準言語で書かれ、任意に複雑な対話に対する柔軟性を提供する。expect スクリプトを書くことで、対話的プログラムを非対話的に実行できる。 > > シェルスクリプトはこれらのシステム管理タスクを扱うことができないが、expect スクリプトはそれらの多くを制御できる。不出来に書かれたプログラムに対話的に応答するために人を専任で貼り付けなければならなかった作業を、自動化できる。大規模な環境では、節約される時間と苛立ちは計り知れない。 > > expect はシェルにスタイルが似ており、すでにシェルでプログラムできるシステム管理者なら容易に習得できる。本論文は、passwd や fsck の自動化など、expect を使ってシステム管理タスクを自動化する実例を提示する。自動化できる他のシステム管理タスクについても多数論じる。 ## 論文情報 - タイトル: Using expect to Automate System Administration Tasks - 著者: Don Libes(National Institute of Standards and Technology, Metrology Bldg, Room A-127, Gaithersburg, MD 20899) - 媒体: Proceedings of the Fourth USENIX Large Installation Systems Administration (LISA) Conference, Colorado Springs, CO, October 17-19, 1990(1992年1月21日付で再版) - キーワード: expect, fsck, interaction, passwd, password, programmed dialogue, security, shell, Tcl, UNIX, uucp ## 概要 UNIX の伝統的なシェル(sh, csh, ksh)は対話的プロセスと双方向通信ができないため、passwd・su・fsck・telnet のような対話プログラムの自動化ができないという課題を、疑似端末を用いて対話プロセスに介在する専用ツール expect によって解決したことを report する論文である。著者 Don Libes 自身が実務で使ってきた具体的なスクリプト例(passwd の非対話化、fsck の質問への自動応答、ftp のスプール処理、モデムコールバック)を通じて手法を示し、シェル・Perl・Emacs との使い分けを論じている。 ## 問題設定 - 入力: 対話プログラム(passwd, su, fsck, dump, telnet, tip, adb など)が標準入力・`/dev/tty` に対して出すプロンプトと期待する応答のパターン。 - 前提: 古典的な UNIX シェル(sh/csh/ksh)は、プロセスとの間に真の双方向接続(two-way connection)を作れないため、プロンプトを検知したり誤り応答を出したりできない。 - 制約: 多くのシステム管理プログラムは、UNIX の「小さい部品を組み合わせる」哲学に反し、パイプやシェルスクリプトへの組み込みを前提としないインターフェースで書かれている。 ## 提案手法 - **アーキテクチャ**: expect はスクリプトとプロセス群の間に位置し(Figure 1)、疑似端末(pseudo-tty)を使ってプロセス側からは実端末に見せかける。1 つの expect スクリプトが同時に複数プロセス(論文の図例では 5 プロセス)を制御でき、ジョブ制御コマンド(bg, fg 等)でプロセス間の連携も扱う。ユーザーは任意の時点でスクリプトから制御を奪い(interact)、また escape 文字でスクリプトへ制御を戻せる。 - **アルゴリズム/手法の詳細**: 中核コマンドは 4 つ。 - `spawn` — 対話プログラムを起動し、「current process」として扱う。 - `expect` — current process の出力に現れるパターン(`*` によるワイルドカードを含む)を待ち、複数パターン・複数アクションを同時に登録できる。組み込みキーワードとして `eof`(EOFの検出)と `timeout`(パターン不一致のタイムアウト)を持つ。 - `send` — current process へ文字列(制御文字含む)を送る。 - `interact` — 制御をキーボード(stdin)へ渡し、任意の escape 文字が押されるまでユーザーに直接操作させる。 - 言語は `for`/`if`/`then`/`else` など C 的な制御構造を備え、シェルスクリプトから呼び出す/呼び出されることもできる。 - **実装上の工夫**: `expect` コマンドは複数の候補パターンとアクションを 1 呼び出しにまとめられるため(Listing 2, 3)、未知の質問だけ `interact` に落として人間に判断させる、といった半自動処理が書ける。`set timeout` でタイムアウト秒数を動的に変更でき、ブート時の read-with-timeout のようにシェルでは書きにくい処理を単純化する。 ## 新規性 - 既存の解は「回避(automatable でない作業は諦める)」か「C で 1 から書く」のいずれかに限られていたが、expect はその中間に位置する専用の高水準言語を提供する。 - Tcl(Ousterhout の Tool Command Language)をベースにしたスクリプト言語であり、シェルに慣れたシステム管理者にとって学習コストが低い(参考文献 [3][4])。 - Perl や Emacs も同じ問題を解けるとしつつ、両者は「必要以上に多機能・複雑」であり、expect は対話プロセス制御という具体的な問題に絞ることでディスク容量(expect 70K 対 Perl 270K、著者の Sun 3 上での実測)と起動時間で優位だと主張する。 ## 実験設定 本論文は定量評価実験ではなく、著者の勤務先(NIST)における実運用スクリプト例を提示する実務報告である。比較対象は同じ問題領域を扱いうる代替手段(シェル・Perl・Emacs・C)であり、評価は disk footprint(expect 70K vs Perl 270K)などの実測値に基づく定性的な議論が中心。 ## 実験結果 - **passwd の非対話化**(Listing 1): ユーザー名とパスワードを引数に取り、`passwd` を spawn して 2 回のパスワードプロンプトに自動応答するスクリプト。 - **fsck の自動応答**(Listing 2, 3): `UNREF FILE...CLEAR?` や `BAD INODE...FIX?` など既知の質問に自動で `y`/`n` を返し、未知の質問だけ `interact` でユーザーに委ねる 2 種類のスクリプトを提示。 - **モデムコールバック**(Listing 4): `tip modem` を spawn し、`ATDT` でダイヤルして `CONNECT` を待つ、遠距離ユーザー向けの着信折返しスクリプト。 - **ftp スプール処理**(Listing 5): `mget *` に続けて `mdelete *` を行うと、その間隔に到着したファイルまで削除してしまう競合状態を、`ls` 結果を明示的に走査して `get`/`delete` を 1 ファイルずつ行う expect スクリプトで解消。 - その他、リグレッションテストの自動化、複数フロントエンド経由のログイン自動化、`telnet` を汎用 TCP ソケットクライアントとして流用した `sendmail.cf` バージョンチェック、`ftp` によるディレクトリ階層の再帰転送、`adb` の暗号的な出力を人間可読な問答に翻訳する介在、巨大ログファイルを `grep` した直後に `^C` を自動送信する処理、非 UNIX ホストの管理(`telnet`/`tip`/`kermit` 経由)を、いずれもコード断片なしで解決事例として列挙している。 ## 考察 - **セキュリティ**: パスワードをコマンドライン引数やファイルに平文で置く手法は、`ps` によるプロセス引数の覗き見や、バックアップメディア経由のファイル漏洩というリスクを新たに生む。著者は「限定用途のアカウント(デモ・匿名 ftp)以外では平文パスワードを保存しない」ことを推奨し、対話的にパスワードだけを一度尋ねさせて残りを事前定義済みスクリプトに任せる代替パターンも示す。同じ仕組みは逆に、辞書に基づくオンラインパスワード推測(セキュリティ診断、あるいは侵入)にも使える双方向のツールだと述べている。 - **既存ツールとの比較**: シェルは対話プロセスを制御できないため比較にならない。Perl・Emacs は解けるが過剰に複雑であり、システム管理者にとっての学習コストの低さで expect が優位だとする主張は、著者自身の経験に基づく定性的判断(本人も「哲学的選択であり論理では決着しない」と明言)である。 ## 強み / 弱点・課題 - **強み**: シェルスクリプトと同じスタイル(タスク指向)で書け、シェルスクリプトから呼び出す/呼び出されることもできるため既存の運用に馴染みやすい。小さな問題には小さなスクリプトで済み、スケールもする。 - **弱点・課題(論文が自認する限界)**: expect のセキュリティ機能はあくまで「注意して使えば安全になりうる」というものであり、誤用時のリスク(平文パスワード漏洩)は著者自身が明記している。また Perl・Emacs との比較は定量評価を伴わない定性的主張(著者自身が「哲学的選択」と述べる)にとどまる。