今日はプロセス監視ツールMonitで、自作のデーモンプログラムの死活監視と、死んじゃったら(+おかしくなったら)再起動してもらうという仕組みを構築する方法をご紹介したいと思います。

まず、自作プログラムですが、どこか適当なところに自分のプロセスIDを記録するファイル(pidファイル)を作ってもらう必要があります。今回作業したマシンはUbuntu Linuxでしたので、/var/run/hoge.pidのような感じで、プロセスIDを格納しただけのファイルを置いておきます。

Monitくんは、このファイルの場所を教えておき、このファイルに記録されているIDのプロセスが死んでいたり、メモリを以上に消費していたり、CPUを100%使っていたり、といった条件で再起動を行わせるよう設定できる便利ソフトです。

Ubuntu Linuxにはパッケージ管理システムaptがあるので、以下のようにしてインストールできます。

$ sudo aptitude install monit

設定ファイルは/etc/monit/monitrcになります。以下のように書き換え＋書いてやればokです。

# 最初の方の基本設定を書き換え
set daemon 120 # 120秒ごとに監視
set alert tomotaka@bpsinc.jp # アラートメールが飛ぶあて先

# (snip)

# 自分のデーモンの監視設定を追加
check process hogehoge
    with pidfile "/var/run/hoge.pid"
    start program = "/home/bps/bin/hoge.sh start"
    stop program = "/home/bps/bin/hoge.sh stop"
    if 2 restarts within 3 cycles then timeout
    if totalmem > 100 Mb then alert
    if cpu usage > 95% for 3 cycles then restart

それぞれの意味はなんとなくわかる通りです。起動コマンドはstart program, 停止コマンドはstop programで指定して、メモリを100MB以上消費していたらアラートを投げるなどといった細かい条件を設定できます。より細かい設定項目についてはMonitプロジェクトのドキュメントを見てみてください。
TCPによる接続がダメだったら、とかファイルのMD5チェックサムが変わっていたら、パーミッション、inode、タイムスタンプが変わっていたら、などさまざまな条件設定が可能です。
URLのチェックや、SIP、pingのチェックなども条件に設定できます。これはすごい。

とりあえず、自分のデーモンを監視させたいだけでしたらmonitrcにデフォルトで入っている他のデーモン監視設定は全部コメントアウトして、慣れてきたら少しずつコメントアウトをはずしていくのがオススメです。

設定が終わったらmonitを起動してあげましょう。

$ sudo /etc/init.d/monit start

自分のデーモンが死んでしまったら、ちゃんとmonitによって、再起動されるかどうか？ psで自分が走らせているプロセスを見つけてkillコマンドで殺すと、うまくいっていれば、次にmonitがプロセスをチェックしたタイミングでアラートメールでmonitが再起動した旨を伝えてくれるはずです。

Apacheなどをmonitで監視するという例はよく見かけましたが、自分で作ったデーモンをmonitで監視させるという記事があまり(とくに日本語では)見つかりませんでしたので書いてみました。
デーモンのように、落としてはいけないプログラムを自分ひとりでApacheやMySQLなどのたくさんの人がブラッシュアップしているクオリティに持っていくことは難しいです。
デーモンプログラムにもきちんと例外補足やロギングの仕組みを入れておけば、デバッグもしやすく、落ちにくいプログラムにしていくことが可能ですが、個人で実験できる量というのは24時間365日連続稼動時にアプリケーションが遭遇する無限の可能性の前では、残念ながら十分とは言えないでしょう。またテストのしすぎも費用対効果がよくない場合が多いかと思います。
それでも随時処理を行いたい場合には常駐型のプログラムを作成する必要があるわけで、そんな僕らこそ、Monitを使って可用性を確保するべきではないでしょうか。

ユーザ名やグループ名にスペースが入っていると、引数の指定がおかしくなってしまうので、バックスラッシュでエスケープしましょう。ダブルコーテーションで囲ってはダメです。

$ chown LAB+baba:LAB+domain\ users hogefile

簡単ですが気づくまで地味に困っていました。

しかし、ユーザ名がむやみやたらと長いとき、途中で切れてしまうことがあります。
特に、ActiveDirectoryと連携するとグループ名が「ドメイン名+domain users」などになるため、危ないです。

[/home] # ls -l
drwxrwxrwx   17 LAB+inte LAB+doma     4096 Mar 26 09:29 baba/
drwxrwxrwx    3 LAB+admi LAB+doma     4096 Mar 26 08:35 peter/

domain usersかdomain adminsかどっちだよ！という感じですね。

ちゃんとしたLinuxなら回避法がありそうですが、今回はQNAPのNASでこの問題が発生しました。
組み込みLinuxなので、コマンドやlsのオプションが少なくて、良い回避策が見つかりません。

そこで、完璧ではないですが、以下の方法を教えてもらいました。
ls -ln

これで、ユーザ名・グループ名の代わりにユーザID・グループIDが表示されるため、面倒ですが事足ります。

■手順

1. ssh-keygen -t rsa で、パスフレーズなしのSSH鍵を生成する
2. ~/.ssh/id_rsa.pub を、リモートホストにコピーする
3. リモートホストで、cat id_rsa >> ~/.ssh/authorized_keys する
4. リモートホストで、authorized_keys のパーミッションを600にする
5. ssh -i (IDファイル) (リモートホスト)

だけなのですが、authorized_keys の所有者がrootになってしまっていました。
パーミッションを600にしても、ownerが間違っていたらだめですよね・・・

今回練習がてら、自宅サーバでSVN環境を構築したのですが、コミット時に自動でdeploy（svn update）する処理が上手くいかずに苦労しました。

post-commitフックでsvn upするだけなのですが、リポジトリの所有者とコミット者が違う場合、deploy用のディレクトリへの書き込み権限が無くて失敗します。
（さすがにdeploy用フォルダを777にするのは無しという前提です）

例：リポジトリの所有者はbps（bpsグループ）で、コミット者はbaba（bpsグループ）の場合

$vi /home/bps/hoge-project/repos/hooks/post-commit

#↓だとPermission Deniedで失敗するので
svn up /home/bps/hoge-project/deployed

#↓このようにしないといけない
sudo -u bps svn up /home/bps/hoge-project/deployed

しかし、これだとsudoの際にパスワードを求められて、Eclipse等からコミットした場合に入力待ちで永久に処理が完了しません。
そこで、この処理だけパスワード無しでsudo出来るようにしないといけないようです。

/etc/sudoersファイルを編集して設定します。専用のvisudoコマンドを使うと安全なようです。

$visudo  

#以下の記述を追加
%bps ALL=(bps)NOPASSWORD:/home/bps/hoge-project/repos/hooks/post-commit

これでようやくコミット後にsvn upが実行されました。

システム管理部の先輩が目をつぶっても出来るような作業に、半日近くかかってしまいました。
もっと修行します。

結論から述べると、昨日のRAID監視スクリプトの設定で監視対象をCentOSにした場合、そのままでは動きません。その原因はsudoの設定にあります。

まず、事前に確認すべきこととして、監視対象ホストの端末から以下のコマンドは実行可能ですが、

# sudo -u nagios /usr/lib/nagios/plugins/check_sakura_raid
RAID OK : u0 RAID-1 OK - - - 232.885 ON -

監視ホストから下記のコマンドを実行しても監視対象ホストから結果が取得できません。

# /usr/lib/nagios/plugins/check_nrpe -H (hostname) -c check_raid
NRPE: Unable to read output

つまり、端末からコマンドを実行した場合は実行できるのにも関わらず、リモートから実行すると何故か実行されないというわけです。

ここで、sudoに関係するログとして/var/log/secureのログに注目します。

Oct 28 11:58:28 localhost sudo: nagios : sorry, you must have a tty to run sudo ; TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/local/bin/tw_cli info c0

このログが意味することとしては、端末(tty)でないとsudoが実行できない、ということで
シェル以外から実行した場合（cronなど）sudoが実行できないように設定されています。

これは、CentOSの初期設定で/etc/sudoersファイルに”Defaults requiretty”として設定されていることによるものです。
このため、この問題は該当行をコメントアウトすることで解決します。

# visudo

#Defaults    requiretty

これで監視ホストから下記コマンドを実行すると結果が取得できるようになるはずです。

# /usr/lib/nagios/plugins/check_nrpe -H (hostname) -c check_raid
RAID OK : u0 RAID-1 OK - - - 232.885 ON -

やはり問題に直面した時は素直にログを追いかけるのが鉄則ですね！

以上です。

http://faq.sakura.ad.jp/faq/1032/app/servlet/qadoc?000494

弊社では既にNagiosによるサーバ監視体制を構築していますので、今回はNagios(NRPE)プラグインを自作・設定してさくらインターネットのRAID監視を自動化してみようと思います。

しかし、”RAID制御コマンドがrootでのみ実行可能”と”NRPE-serverがrootで起動不可”という相反する制約があるため、セキュリティ上の制約を考慮したうえでsudoコマンドを利用してＲＡＩＤ制御コマンドを実行することでこの問題を回避します。

では、早速ですが、今回設置の前提となる環境は以下の通りです。

• 監視対象ホストがさくらインターネットの専用サーバRAIDプラン
• 監視対象ホスト、監視ホストはともにLinux(Ubuntu 8.04)
• 監視ホストにnagios2, nagios2-commonがインストール済み
• 監視対象ホストにnagios-nrpe-server, nagios-nrpe-pluginがインストール済み

以上の前提を踏まえたうえで、大まかな設定を以下の手順で行います。

1. RAID監視プラグインを監視対象ホストに設置
2. nagios実行ユーザに対してRAID制御コマンドの実行権限を付与
3. 監視対象ホストで監視ホストからRAID監視を可能にする設定
4. 監視ホストから監視対象ホストに対してRAID監視を行うように設定

1. RAID監視プラグインを監視対象ホストに設置

まず、以下のシェルスクリプト（#!/bin/sh以降の行）を監視対象ホストのプラグインディレクトリ（/usr/lib/nagios/plugins）に設置し、実行権限を与えます。
今回はcheck_sakura_raidというファイル名で設置しました。設置後はrootで実行して問題なく実行できることを確認してください。

# cd /usr/lib/nagios/plugins
# vim check_sakura_raid

#!/bin/sh
DESC=`/usr/bin/sudo /usr/local/bin/tw_cli info c0 | /bin/grep "RAID-1"`
STATUS=`/bin/echo $DESC | /usr/bin/awk '{print $3}'`
case $STATUS in
  OK) echo "RAID OK :" $DESC; exit 0 ;;
  DEGRADED) echo "RAID WARNING :" $DESC; exit 1 ;;
esac

# chmod 755 check_sakura_raid
# ./check_sakura_raid

2. nagios実行ユーザに対してRAID制御コマンドの実行権限を付与

nagiosの実行ユーザ（初期設定ではnagios）がＲＡＩＤ制御コマンドを実行できるように細工をしてやる必要がありますので、visudoコマンドなどを使って/etc/sudoersファイルに以下のように設定を追加します。

# visudo
nagios ALL=NOPASSWD: /usr/local/bin/tw_cli

上記の設定ではnagiosユーザがパスワード無しでＲＡＩＤ制御コマンドを実行できるように設定していますので、設定後にnagiosユーザで実行可能かどうか確認します。

# sudo -u nagios /usr/local/bin/tw_cli

3. 監視対象ホストで監視ホストからRAID監視を可能にする設定

次に、監視対象ホストのnrpe-serverの設定ファイル（/etc/nagios/nrpe.cfg）に下記の行を追加し、監視対象から設置したプラグインを実行できるように設定します。設定後はnrpe-serverを再起動します。

# vim /etc/nagios/nrpe.cfg
 command[check_raid]=/usr/lib/nagios/plugins/check_sakura_raid

# /etc/init.d/nagios-nrpe-server restart

4. 監視ホストから監視対象ホストに対してRAID監視を行うように設定

最後に監視ホストの監視サービス設定にRAIDを追加します。

# vim /etc/nagios2/conf.d/services_nagios2.cfg

define service {
　　hostgroup_name                  nrpe-raid-servers
　　use                             generic-service
　　service_description             [NRPE] RAID
　　check_command                   check_nrpe_1arg!check_raid
}

また、上記で追加したRAID監視設定を監視対象ホストに対して適用します。

# vim /etc/nagios2/conf.d/hostgroups_nagios2.cfg

define hostgroup {
 hostgroup_name nrpe-raid-servers
 alias          [NRPE] RAID servers
 members        server1, server2
}

ここまで設定を変更したらnagiosを再起動します。

# /etc/init.d/nagios2 restart

最終的に監視ホストのnagiosの管理画面から監視対象ホストのRAIDに関するステータスが表示されるようになれば監視設定は完了です。

以上です。

• PHP5以上
• cURLのエクステンション

が必須です。

クライアント側では、

require_once './XML/RPC2/Client.php';
$options = array('debug' => true);
$client = XML_RPC2_Client::create('http://www.bpsinc.jp/xmlrpc.php', $options); //URLはダミー
try {
    $result = $client->Version(); //関数名はサーバ側で定義したもの
    print_r($result);
} catch (XML_RPC2_FaultException $e) {
    var_dump($e);
} catch (Exception $e) {
    var_dump($e);
}


のように使えます。

しかし、これだとなぜか結果が全部NULLになることがあります。
debugメッセージを見ると、Server Responseは正常なのに、Decoded ResultがNULLになっているように見えます。

この問題、Server側かHttpRequestの実装の問題だと思うのですが、Server ResponseのBodyの最初に改行が入っているのが原因でした。
"\n<?xml version="1.0"?><methodResponse> …"

PEAR/XML/RPC2/Backend/Xmlrpcext/Client.php の112行目付近で、
$result = xmlrpc_decode($body, $this->encoding);
となっているところを、
$result = xmlrpc_decode(trim($body), $this->encoding);
とすれば直ります。(マルチバイト対応のtrimを書いた方が良いかもしれません)
※XMLRPCEXT拡張モジュールが入っていない場合は、PEAR/XML/RPC2/Backend/PHP/Client.phpになります。

ライブラリを書き換えるのは強引ですが、xmlrpc_decode関数自体がEXPERIMENTALのままですし、あとはHttpRequestやサーバ側を変更しなければ行けないので、スマートな解決方法は思いつきません。
とりあえずresultがnullになる問題は回避できました。

• Subversionでバージョン管理
• SVN+SSHでアクセス
• 認証は公開鍵
• クライアントはSubclipse

SSHサーバはすでに構築してあったので、まずはSubversionのインストールして、リポジトリを作成。
aptitude install subversion
svnadmin create ~/project/test/svn

しかし、Eclipseで鍵認証で入れません。Puttyでは入れるし、Eclipseでもパスワード認証なら入れるのに。
ここで数時間詰まった結果、原因は秘密鍵の形式がPutty形式だという単純なものでした。puttygenで鍵を作ったとき、”Save private key”ボタンを押すと、putty形式の秘密鍵が出力されますが、それはSubclipseでは使えません。メニュー”Conversions”->”Export OpenSSH Key”で作った秘密鍵を使う必要があります。(公開鍵は共通です)

仕方ないので鍵を作り直し。以前の公開鍵も使いたいので、

ssh-keygen -i -f new.pub >> new_key
cat new_key >> authorized_keys
rm new_key
rm new.pub

のように公開鍵を追加しました。

以上の作業で、Subclipseで鍵認証を使えるようになりました。環境変数の設定が必要という情報が多かったですが、今回は設定無しでも動きました。

その後、サーバ側でCheckoutしないで「svn updateができない」とか言ったり、post-commitが動かないと思ったらbashをbachと書いていたり、ヘボいミスで時間がかかりましたが、何とか使える段階に持って行けました。

引き続き、一人前のサーバ管理者目指して頑張ります。

Ubuntu(Debian)のバグ？というか/etc/hostsに勝手に書かれた設定の影響みたいです。

> Jan 17 12:34:50 xxxx proftpd[18744] xxxx.xxxxx.xxx: 127.0.1.1:21 masquerading as
127.0.1.1
（あるのかわかりませんが）意図があるのだとしても、これによって動かなくなるソフトウェアはあるようなので、

ネットワーク周りを扱うソフトウェアでかつDebian系列で、はまった時は/etc/hostsの設定を見直してみることをお勧めします。

<参考＞

http://itmst.blog71.fc2.com/blog-entry-100.html