BIND9(named)をsupervisordで管理する

CVE-2016-2776対応されているみなさま、お疲れさまです。一緒に頑張りましょう。

今回の脆弱性はかなり簡単にプロセスをダウンさせられるようなので、
自動復旧させるためにCentOS6上でsupervisorで管理してみます。

外部からの監視ベースだと監視間隔が1～5分程度あると思いますので、
ダウン発生から検知復旧に間が空いてしまいます。
その場しのぎではありますが、ダウンタイムの最小化の一案として試してみます。

(CentOS7系はsystemdで同様の管理ができるのでsystemdで行えば良いでしょう。
また、daemontools派の方も同様の事ができると思います。
商用のコントロールパネルにも自己監視機能があったと思います。)

以下、実手順です。

参考: Men and Miceのサイト

・インストール

EPELレポジトリから導入できます。

# yum install supervisor
読み込んだプラグイン:product-id, security
インストール処理の設定をしています
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> Package supervisor.noarch 0:2.1-9.el6 will be インストール
--> 依存性の処理をしています: python-meld3 のパッケージ: supervisor-2.1-9.el6.noarch
--> トランザクションの確認を実行しています。
---> Package python-meld3.x86_64 0:0.6.7-1.el6 will be インストール
--> 依存性解決を終了しました。

依存性を解決しました

========================================================================================================================
パッケージ アーキテクチャ バージョン リポジトリー 容量
========================================================================================================================
インストールしています:
supervisor noarch 2.1-9.el6 epel 292 k
依存性関連でのインストールをします。:
python-meld3 x86_64 0.6.7-1.el6 epel 71 k

トランザクションの要約
========================================================================================================================
インストール 2 パッケージ

総ダウンロード容量: 364 k
インストール済み容量: 1.4 M
これでいいですか? [y/N]y
パッケージをダウンロードしています:
(1/2): python-meld3-0.6.7-1.el6.x86_64.rpm | 71 kB 00:00
(2/2): supervisor-2.1-9.el6.noarch.rpm | 292 kB 00:00
------------------------------------------------------------------------------------------------------------------------
合計 8.0 MB/s | 364 kB 00:00
rpm_check_debug を実行しています
トランザクションのテストを実行しています
トランザクションのテストを成功しました
トランザクションを実行しています
インストールしています : python-meld3-0.6.7-1.el6.x86_64 1/2
インストールしています : supervisor-2.1-9.el6.noarch 2/2
Verifying : python-meld3-0.6.7-1.el6.x86_64 1/2
Verifying : supervisor-2.1-9.el6.noarch 2/2

インストール:
supervisor.noarch 0:2.1-9.el6

依存性関連をインストールしました:
python-meld3.x86_64 0:0.6.7-1.el6

完了しました!

・設定

/etc/supervisord.confに、先のMen&Miceのサイトの例の以下部分を追記します。

[program:named]
command=/usr/sbin/named -u named -f
process_name=%(program_name)s
numprocs=1
directory=/var/named
priority=100
autostart=true
;autorestart=unexpected
autorestart=true
startsecs=5
startretries=3
exitcodes=0,2
stopsignal=TERM
stopwaitsecs=10
redirect_stderr=false
stdout_logfile=/var/log/named_supervisord.log
stdout_logfile_maxbytes=1MB
stdout_logfile_backups=10
stdout_capture_maxbytes=1MB

(autorestart=unexpectedがエラーになったので一旦trueにしています)

・起動

# ps -ef | grep named
root 6991 6321 0 20:08 pts/0 00:00:00 grep named
# service supervisord start
supervisord を起動中: [ OK ]
# ps -ef | grep named
named 7004 7002 0 20:08 ? 00:00:00 /usr/sbin/named -u named -f
root 7011 6321 0 20:08 pts/0 00:00:00 grep named

supervisordを起動することでnamedも上がってきました。

・確認＆障害復旧テスト

プロセスを強制終了して疑似障害を起こしてみます。

# supervisorctl status
named RUNNING pid 7004, uptime 0:00:09
# kill -KILL 7004
# supervisorctl status
named STARTING
# ps -ef | grep named
named 7013 7002 0 20:08 ? 00:00:00 /usr/sbin/named -u named -f
root 7020 6321 0 20:09 pts/0 00:00:00 grep named
# supervisorctl status
named RUNNING pid 7013, uptime 0:00:11

プロセス強制終了後、すぐにsupervisordによって検知＆再起動が行われ、新たなプロセスIDで起動しています。

・停止

# service supervisord stop
supervisord を停止中: [ OK ]
# ps -ef | grep named
root 7051 6321 0 20:09 pts/0 00:00:00 grep named