expect

tarとDAR、DARのよくあるエラーと対処法でも触れたバックアップの話題ですが、実際にできたアーカイブを外部のストレージなりメディアなりに保存しないと意味がありません。今回はマウントする類の話ではなく、NASやストレージサーバーに転送する話。

よく使われるのがscpやsftpだと思いますので、今回はscpを使います。scpは基本的にSSHベースなので、既にSSHでクライアントから操作している場合は、特に何の設定もなく利用することができるのが利点でしょうか。個人的にはGB単位のデータを転送してみたりしましたが、ローカルネットワークを使うならば特に遅いなどとは感じませんでしたので、余程ファイルサイズが巨大といったことがなければscpを利用するのが良いかと思います。ちなみにscpとはSecure CoPyの略。

んではまずscpをシェルで利用する場合。基本的な使い方をする分にはcpと似たようなもんなのでさほど困ることはないかと思います。

# scp report.tex username@hostname.com:filename

ハイ。scp コピーするファイル コピー先 と、cpと変わりません。これがリモートサーバからローカルへ、という場合は引数の順序が逆になるだけです。ディレクトリをコピーする場合は、scp -r としてやればOK。簡単ですね。

ではスクリプトに埋め込む場合ですが、以前も書いたように、セキュリティの観点からは、シェルスクリプトでexpectを使うのは良い方法とは言えません（ローカルからしか参照できない・しない、とかなら別ですが）。いろいろ方法はあると思いますが（パスワードなし鍵認証にするとか）、自分の場合はPerlモジュールにあるNet::SCPやNet::SCP::Expectを用います。Net::SCPは鍵認証用で対話機能がないので、ユーザー名・パスワードを利用して認証をしている場合の対話処理はNet::SCP::Expectを用います。とりあえずこれらが入っていない場合は

# perl -MCPAN -e shell　←初回起動の場合は設定に入ります。標準的な構成であれば、基本的にEnter（デフォルト）で問題ありません
↓　こうなるので
cpan> install Net::SCP　←install 必要なモジュール名 を。

…とやると、簡単にCPANからモジュールがインストールできます。（※ちなみに先ほどCentOS5.2でやったら、perl -MCPAN -e shellではなくcpanだけでも起動しました…んー？）

サーバーにあわせて必要なモジュールをどっちかまたは両方導入したら、Perlスクリプトで use Net::SCP::Expectなど利用するモジュールを書いときます。んで簡単なスクリプトとしましては

#!/usr/bin/perl

$usr = ‘root’;
$pwd = ‘xxxxxxxx’;

use Net::SCP::Expect

my $scpe =　Net::SCP::Expect->new(user=>”$usr”,password=>”$pwd”);
$scpe->scp(’192.168.0.2:/dir/filename’,”/dir/filename”);

これがリモートサーバーからローカルサーバーに落とす場合です。詳しい記述法は各モジュールの配布元などをごらんください。
ちなみにファイル単位ではなく、ディレクトリごと落としたい場合はコレだとエラーになるので、上の「my $scpe =…」の行を

my $scpe =　Net::SCP::Expect->new(user=>”$usr”,password=>”$pwd”,recursive=>’1′);

とrecursiveオプションを追加して1にします。

　買い物に行きそびれて米しかない生活を送っていたここ数日、たまごや納豆や牛乳などを購入してなんとか栄養ある生活に戻れそうです。今日米が丁度無くなったのでホントギリギリ。いや、スーパー近すぎて後回しにしちゃってただけなんだけど。

　さて、会社でサーバーの稼働状況を24時間自動監視、異常があるとサーバー管理者にメールが飛びます。まあひどいと夜中に呼び出されたりするわけですが、通常はリモートで復旧したり、軽度ならばサーバーが一定条件で自動再起動をかけるようになっているなど、それなりの対策は当然してあります（俺じゃなくて主に上司が、ですが…）。
　そんな中、監視を行っているサーバーがアラートメールを送ると同時に、スクリプトを起動して外部のサーバのサービスを再起動する仕組みを何とか作れーという話が飛んできました。もちろん方法は幾つかあるのですが、どれを取るか、またはどう実装するかという話になると正解のない面倒くさい話になってくるわけです…。

　expectという、SSHやSCP、FTPなどといった対話が必要になる処理を行えるツールがLinuxなんかにはあるのですが、不特定多数がアクセスするようなサーバーでパスワードを平文で置いておいたり、そんな処理を行うのはよろしくない、という記述を見かけました。現状では、鍵認証方式を使ってパスワード無しでログイン処理をしてしまい、そして自動実行を行うユーザーアカウントの権限を最小限にとどめておく、というのがもっともマシで、万一の場合も被害を抑えてかつ迅速な処理が出来る方法のようです。
　まあそもそもLinux系のOS使ってるクセに、権限設定が緩かったらもっと根本的に問題があるとも思えますが、とにかく自動実行用のアカウントなどを用意し、本当に実行する最小限のコマンド以外許可しないように設定してしまいます。これで万一鍵をクラックされても影響を最小限に抑えることができるということです。