CGI プログラムによる監視
3.7 で追加された機能の目玉，CGI による監視をするには，当然 http サーバが必要です。Plamo には，Apache が付いてますから，これを使うのがいいでしょう。手前ミソですが，こちらを参考にしてください。
で，監視画面を見るには，
http://localhost/cgi-bin/multimon.cgi
を同一マシン上のGUIなブラウザ（Netscapeなど）から叩くか，他のGUIなマシンからブラウザで UPS が繋がったマシンの上記
URL を叩くと見れます。サンプル画像は，ご本家のマニュアル内にありますのでごらんください。
もし、複数台のapcupsdが動いているホストがある場合、それらを1台のマシンで一括で監視することも出来ます。その場合は、/etc/apcupsd/hosts.conf
を編集します。
また、1台しかない場合も、システム名に"Local Host"と出てくるのが気に入らない場合はやっぱりこれを編集します。
たとえば、こんな具合です。
MONITOR 127.0.0.1 "Local Host"
となっているダブルクォーテーション(")で囲まれた部分を、本来のホスト名に修正します。また、他のホストを監視対象にしたい場合は、
MONITOR 192.168.0.2 "Another Host"
といった具合に追加します。
ここで、他のホストを監視したい場合、監視されるホストの/etc/apcupsd/apcupsd.conf 内で、NETSERVERディレクティブはかならず
on になっていなくてはならず、また SERVERPORT で指定されているポート番号は一致していなくてはなりません。
1台のUPSで複数台のLinuxBoxの電源管理
Special thanx to Mr. Kern @ sibbald.com and Mr. Riccardo
@ oasi.gpa.it
apcupsd は、1台のUPSから電源を取っている複数のLinuxBoxの面倒を一手に引き受けてくれます。似たようなことは、APC
の ShareUPS というアクセサリもできるのですが、あれはそれぞれのホストをシリアルケーブルで接続しなくてはなりません。しかし、apcupsd
ではシリアルケーブルを接続するのはマスタとなる1台だけで、残りはシリアルケーブルで接続する必要はありません。但し、代わりに同一ネットワーク上にいなくてはなりません。まぁ通常、LinuxBoxをネットワークから切り離して使う事はないでしょうから、この点は問題ありませんね:-p
このようなコンフィグレーションにすると、どんな振る舞いをするかと言うと、電源異常などの情報はまずシリアルケーブルを通してマスタとなるLinuxBoxへと伝達されます。すると、マスタはその情報をネットワークを経由してスレーブとなるLinuxBoxへと伝達します。これで全部のLinuxBoxは連動され、停電時の自動シャットダウンなども揃って行われるのです。
注意すべき点は、
- HUBもUPSから電源を供給するなどして、停電時にネットワーク接続が遮断されないようにしないと、スレーブがシャットダウンされない（当たり前だ(笑)
- 停電時にDNSから名前を引けなくなる可能性があるネットワーク構成の場合は、/etc/hosts などにホスト名を記載しておく
などです。
では、その設定方法を。
- マスター側
/etc/apcupsd/apcupsd.conf 内の下記の部分を修正します。
- UPSCLASS netmaster
- マスター／スレーブネットワーキングモードのマスタであることを指示
- UPSMODE net
- マスター／スレーブネットワーキングモードを使うことを指示
- NETPORT 6666
- マスター／スレーブ間の通信ポートを定義、すべてのスレーブと同じ値である必要あり
- SLAVE <slave-name>
- UPSを共有しているスレーブのホスト名を指定。
- スレーブ側
同じく /etc/apcupsd/apcupsd.conf 内の下記の部分を修正します。
- UPSCLASS netslave
- マスター／スレーブネットワーキングモードのスレーブであることを指示
- UPSMODE net
- マスター／スレーブネットワーキングモードを使うことを指示
- NETPORT 6666
- マスター／スレーブ間の通信ポートを定義、マスタと同じ値である必要あり
- MASTER <master-name>
- UPSを共有しているマスタのホスト名を指定。
なお、マスタ／スレーブのUPSTYPEは必ず揃え、スレーブのUPSCABLEは"ether"を選びます。
これで双方の apcupsd を起動（既に動いているなら、再起動）して、正しく通信しているかどうか確かめて見ましょう。起動はどちらが先と言うことはないと、配布もとの
Kern 氏も言っていましたが、「あえていうならスレーブかな？」とも言っています(笑)
というわけでまずはスレーブを起動しましょう。
スレーブ側では、スタンドアローンで起動していたデーモンが姿を潜め、その代わり"apcslv"というデーモンが起動していることがわかります。
# ps ax|grep apc
3013 ? S 0:00 apcmain
3015 ? S 0:00 apcslv
スレーブの起動は、スタンドアローンの時とは違って、即座に起動を終了します。対象となるUPSの実体が接続されていないからでしょうね。
そしてマスターを起動します。起動後1分から2分ほどすると、マスタ側にはスタンドアローンでは現れなかった"apcmst"というデーモンが起動します。
# ps ax|grep apc
12691 ? S 0:00 apcmain
12701 ? S 0:00 apcser
12702 ? S 0:00 apcnis
12703 ? S 0:00 apcmst
マスターが起動した後、スレーブを見ると、/etc/apcupsd/apcupsd.events には、下記の様にマスターとの接続が正しく行われたという記述が残ります。
apcupsd 3.7.2 startup succeeded
Connect from master MASTER_NAME succeeded
同様にマスター側にも記述されます。
Connect to slave SLAVE_NAME succeeded
apcupsd 3.7.2 startup succeeded
では、テストのため例によって電源を落としてみましょう(笑)
/etc/apcupsd/apcupsd.conf 内の TIMEOUT ディレクティブはあまり長くしないようにしましょう。長いと結果を待つのがだるいです(笑)
マスタがシャットダウンに入ると、スレーブ側も同時にシャットダウンに入ることがわかるでしょう。マスタは自身がシャットダウンを完了する前30秒ほど、スレーブのシャットダウンを待ちます。その後、マスタがUPSの電源を落としてめでたくシャットダウン完了です。
マスタ側のログは、こんな感じです。
Power failure
Running on UPS batteries
Reached run time limit on batteries
User logins prohibited
Initiating power failure system shutdown
Connect to slave SLAVE_NAME failed
apcupsd exiting, signal 15
スレーブ側は、マスタとの接続がどうのこうのといわない（既にシャットダウンしている事になっているので(笑）だけで、基本的には同じログが残ります。時刻を見比べると面白いですよ:-)
