ふと思い出した20年前
攻撃のデモで、「ここはどこ、私は誰?」はよくやりますね $ pwd; whoami
— 徳丸 浩 (@ockeghem) 2016年3月3日
私がITというか計算機管理に関わるようになったきっかけは20年前。
当時計算機を苦手としていた私は、大学の講義課題をやる中であるトラブルを起こす。
計算機のことを分かってなさ過ぎた故にありえない操作を行ってしまい、
ローカル権限昇格のバグ?セキュリティホール?を突いてしまったのである。
当時の状況
私「え!課題で作ったファイルが全部消えた~!」
実際には権限昇格したため/roor/に移動していたのである。
真に、引用のpwdやwhoamiという知識があれば活かされたであろうシーンである。
嘆いてたところ、計算機管理を担っていた先輩が見てくれて、状況把握した上で
先輩「君面白いね。計算機管理やってみない?」
と誘いつつ、直してくれた。(今思えばexitしただけかも)
数年後にこの先輩から聞いたのだが、
先輩「今の君なら分かるかもしれないけど、あれローカルの権限昇格してたんだよ。
そんな危ないことする奴、放置してられないから『教えてやるよ』って言って
飼い慣らした方が安心できるだろ」
という事だったらしい。
先輩たちからは様々な知識や技を頂いて、おかげでいまもいっぱしのエンジニアとしてやっていけてる。
だが、そもそも計算機の世界に引き込まれたことが良かったのかどうかは答えに自信が無い。
expectのおさらい
この投稿はNetOpsCoding Advent Calendar 2015 - Qiita19日目分です。
(なお、特に新しい知見は含んでいない10年前の内容であるかもしれません。)
昨日はcodeoutさんの netconf / restconf 時代にもxlogin 使いまくってる話 - LGTM
という素晴らしい記事でした。
xloginを提供するrancidは2.3.1が2004年、2.3.8p4が2013年にリリースされるなど枯れて安定しているものの、3.0が2014年にリリースされるなど今も開発・改善が継続されている素敵ツールです。
expectがカバーできること
ネットワーク機器の作業を自動化/コード化/CI&CD化するにはいくつか段階があります。
expectは最初の段階にあたる、手作業と同じ内容をマクロ的に実行することに特化した、スクリプト言語tclの拡張実装です。
expectの良いところ
サーバーとネットワークの技術者が別れている場合、例えばInfrastracture as Codeなどの潮流にさらされているサーバー技術者と、プログラムは書いたこと無いというネットワーク技術者の間に暗くて深い川が流れている場合もあります。
しかし作業の自動化コード化の恩恵はネットワーク技術者にもあるはずです。
以下にネットワーク技術者がexpectに触れるメリット/甘言を挙げてみます。
- 使い始めるまでの学習コストがきわめて小さい
expectスクリプトの例を見てみましょう。
#!/usr/bin/expect
set timeout 60 spawn telnet rauter.example.com expect "Password:" send "ExpectExample101\n" expect ">"
send "exit\n"
コマンドプロンプトの応答をexpect、入力するコマンドをsendで送る、という大まかな流れなので分かりやすいかと思います。
また、expectは古くからある枯れた実装なので、参考書籍も1994年刊のオライリー本がほぼ唯一なので迷うこともありません。
JavaScriptのような変化の激しい処理系に比べると、多少腰を据えて学習しても陳腐化することは無いというのは作業を楽にしたいだけのエンジニアにとってはメリットになるでしょう。
それでもプログラムやDSLを書くのはイヤだ、という方にはautoexpectというツールがあります。
こちらはLinuxであればexpectパッケージに含まれる便利コマンドで、MS OfficeやTeraterm、RLoginのマクロ記録 - マクロ実行と同じような感覚で、コマンドラインの作業をexpectスクリプトに記録して再実行可能にするものです。
$ autoexpect
~~作業を行う~~
$exit
作業内容をexpectスクリプトにしたscript.expというファイルが生成されます。
もう一度同じ作業を行う場合は、./script.expと生成されたファイルを実行するだけでOKです。簡単ですね!
- ネットワーク機器作業に特化したラッパーrancidの存在
詳細は先述した昨日のcodeoutさんのエントリの通りですが、rancidは主要ベンダー製品への自動ログイン機構を備えており、configのバージョン管理や定期取得、差分検知などの基本的かつ広く共通したニーズが満たされるます。
まだこれらが実現できていないという環境には、とっかかりとして良いのではないでしょうか。
- tclはネットワーク機器ファームでもサポートされていたりする
私もNetworkers 2006のIOSセッションで知ったのですが(もう9年前。NMS-301のセッションで、Kronもこの時に知りました)、例えばCisco社のファームウェアにはtcl/tclshが実装されていて、ルータ上でtclスクリプトを動かすことができます。
ルータの一機能だと思えば抵抗感も少なくなるのではないでしょうか。
一方、expectの注意すべきところ
記録&再生マクロのように気軽に使える分、極めて狭いスコープを対象とした特定の作業のみを行う、似て非なるスクリプトが量産されてしまう事態に陥りやすいです。
これを避けつつスケールさせていくためには、ある程度スクリプト作成に慣れたところで
共通部分のテンプレート化と変数の抜き出し
直接expectスクリプトを作るのではなく置換などでexpectスクリプトを生成するようなメタスクリプトの作成
といったことを視野に入れる必要があります。
テンプレート化とメタスクリプティング、面倒だなー、誰か作ってないかなー、記述にDSL使えそうだなー、AnsibleとかFabricとか使えそうだなー、あれexpect要らなくね?
....おや、こんなところに大勢の足跡が
明日はバラ色の主日、早いですねえ。
参考リンク:
expect本家サイト http://expect.sourceforge.net/
rancid http://www.shrubbery.net/rancid/
OpenNetAdmin (rancid同様の管理&自動化機能を持つツール。2013年以降開発停滞気味?) http://opennetadmin.com/
(IOS) http://www.cisco.com/cisco/web/support/JP/docs/CIAN/IOS/IOS15_1M_T/CG/009/nm_script_tcl.html?bid=0900e4b18252971b
(IOS-XE) http://www.cisco.com/cisco/web/support/JP/docs/SEC/IdentityMGMT/SecureAccessCntrlServer4W/IG/002/nm_script_tcl_xe.html?bid=0900e4b1825ae544