というわけで、日付が変わったが、ぢつは2月4日の続きだったりする(笑)。
bindの設定をした後、気づいたのだが、無線LANのアクセスポイントにも固定IPが付いていたことを思い出した。忘れないうちに、/var/named/lan.zoneと、/var/named/lan.revに無線LANアクセスポイントのエントリーを加えてbindを再起動。テストしてみるがまったく問題なく設定変更が完了した。
さて、RedHatのディストリビューションにもup2dateという自動アップデートツールがついているのだが、以前、インストール直後に実行したみたらredhat networkに登録されていないということをいわれてしまってアップデートできなかった。
ところが、さっきrpm -qaかなんかしてインストールされているパッケージを確認していたらrhn_registerというのがあるのを発見。というわけで、さっそく試してみる。
ぢつは、以前up2dateしてみて駄目だったときにすでにredhat networkにつないでIDは登録してあったので、rhn_resisterを起動したときに出てきたダイアログでそのときのIDとパスワードを入力。すると、fujirushiサーバの情報をさくっと送信してくれる。
で、次はup2date。最初はup2date --listとかしてアップデート可能なパッケージを確認。なんか、アップデートパッケージがずらーっと出てくる。まあ、RedHat 7.3がリリースされてから一年近く経っているので当たり前といえば当たり前。
というわけで、動作は大丈夫そうなので、実際にアップデートしてみることにする。
アップデートはネットワークログインしてやると、途中で端末側の電源を落とせなくなる。それに、WLI-PCMだと速度的に不利なので、WLI-PCM-L11でやることにする。というわけで、サーバを手元に持ってくる。こういうとき無線LANで構成したネットワーク(とノートPCベースのサーバ)は便利である。
おもむろにWLI-PCMを引っこ抜く。カーネルパニック(笑)。そりゃそうだ。生きているeth0をいきなりはずしてしまえばそうもなるだろう、って、待てよ、たしかWLI-PCM-L11を引っこ抜いたときは全然問題なかったような気がする。ということは、これはlinux-wavelanのドライバ側の問題か。今度から気をつけよう(笑)。
カーネルパニックに陥ったマシンは、CTL+ALT+DELや電源スイッチ長押しでも落とせなかった。というわけで背面のリセットスイッチを押し、WLI-PCM-L11を入れてサーバを再起動。無事起動。よかったよかった。
そんなこんなあったけど、まあ、とりあえず、ということで気を取り直してコンソールからrootでログイン。その後、up2date --updateとかやってアップデートをかける。
最初、いろいろとやっていたあと、パッケージのダウンロードが始まる。平均で1Mbps程度の速度が出ているようだ。今日はDNSがうまくつながらなかったり、pingが通らなかったりという具合で、Yahoo!BBのネットワークがどうも怪しい感じなので速度的な期待はしていなかったのだが、まあまあ速度は出ているようだ。
問題は、そのあとのインストールの準備とインストール。ハードディスクが死にそうな音を立ててカラカラと回っている。さすがに、32MBのメモリはきつそうだ。はやいところDIMMを買ってやらないといけないな。
なぁんてことをいっているうちにインストールも完了。サーバを再起動して動作を確認。pcmcia-csあたりをいじっているのでどうなるかなと思っていたのだが、とりあえずWLI-PCM-L11では問題なく動いているようである。WLI-PCMの方がどうなっているかは神のみぞ知るだが、諸般の事情でWLI-PCM-L11にスペアができてしまうという事態に陥ったのでこれをそのまま使うことにする。っていうか、それくらいしかこのカードの将来的な利用方法を思いつかない。WLI-PCM-L11は、速度はもちろんのこと、カードの発熱もWLI-PCMに比べて少ないのでサーバのNICとして利用するにはこちらのほうが好ましいことは言うまでもない。しかし、つい数日前まで、WLI-PCM-L11に予備がなかったのでWLI-PCMの方を使っていたのだが、結果、WLI-PCM-L11が余剰パーツになったのでこちらで運用していくことがよりベターだろう。WLI-PCMは予備としてお蔵入り。なぜWLI-PCM-L11が余剰パーツになったのかについての詳細は週末あたりに記述することになるだろう。
サーバ設定の続き。
本日はsshdの設定変更をおこなう。
というのも、現状の設定ではsshdがパスワードログインを全世界から受けつけてしまう。もちろん、うちのプチサーバを狙うような悪いはっかーがそうそういるとは思わないが、セキュリティの甘さをつかれて踏み台にされたりした日には洒落にならない。というわけで、暗号化キーを生成してそれがない端末からはログインできないように設定を変更しておく。
sshの設定自体はあちこちのたくさん書かれているので、詳細は書かないけど、のちの自分への参考がてら書いておくことにする。
とりあえず、ログインして、
cd ssh_keygen -t rsa1 cd .ssh cp identity.pub authorized_keys |
これでキーの生成と登録は完了。次は、sshd_configの設定。
/etc/ssh/sshd_configの該当部分を、
RSAAuthentication yes PasswordAuthentication no |
という風に変更。変更保存後、sshdを再起動。秘密キーを落としてきてログインしてみるものの見事失敗(笑)。
/var/log/secureのログを確認してみると、
| Feb 8 22:36:52 fujirushi sshd[8896]: Authentication refused: bad ownership or modes for file /home/fujirushi/.ssh/authorized_keys |
とある。パーミッションが悪いようだ。
| chmod 644 /home/funayama/.ssh/authorized_keys |
としてパーミッションを変更。再度、sshdを再起動。今度はログインOK。これで、世界中から私だけがサーバにログインできるようになった(笑)。
本日は家庭内タイムサーバ。
さて、いろいろと設定が進んでくると欲しくなるのが家庭内タイムサーバである(ほんとか？)。まあ、いろいろと事情はあるのだが、とりあえず、LAN内にだけ向けてのNTPサーバを構築することにする。
とりあえずntpdをインストール。RedHatのサイトからntp-4.1.1-1.i386.rpmをとってきてインストールしようとすると、libcapがないと怒られてしまった。そこで、libcap-1.10-8とlibcap-devel-1.10-8を拾ってきてインストール。その後、ntpdを入れてインストール完了。
次に、/etc/ntp.confを設定。設定しなくてはいけないのは、時刻を取得するサーバの項目と、アクセスの制限の二ヶ所。とりあえず、日本の公開サーバを探して、これを利用することにする。
| server 130.xxx.xxx.xxx |
アクセスの制限はコメントで例があるので、コメントを外して、LANのIP範囲を設定するだけ。
| restrict 192.168.xxx.0 mask 255.255.255.0 notrust nomodify notrap |
設定が完了したらntpdを起動する。
起動後動作の確認。クライアントには、Windowsの桜時計を利用する。自宅サーバのIPを入力してオンラインにすると、
| サーバーの準備がまだのようです(LI=ALARM) |
とでてきてつながらない。もしかして、まだうまくサーバが時刻取得できてないのかと思い、サーバの時刻をdateコマンドで確認。するとずれている。ということで、先に時計袷をしなくてはいけないのかもしれないと考えた。
とりあえず、時計あわせ。
/usr/sbin/ntpdate 130.xxx.xxx.xxx 8 Feb 23:43:47 ntpdate[9411]: step time server 130.xxx.xxx.xxx offset 214.934407 sec |
次に、ハードウェアクロックへの書き込み。
| /usr/sbin/hwclock --systohc |
これでどうだと再度桜時計を起動、接続。つながらない。しょうがないので、もういちどGoogleを利用してよく調べてみる。すると、こんなページを発見。どうやらntpというのは起動後安定するまでしばし待たなくてはいけなそうだ。
当該ページにあったようにntpqコマンドでステータスを確認。すると、
[root@fujirushi ntp]# /usr/sbin/ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
ntp.hoge.jp 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
LOCAL(0) LOCAL(0) 10 l 62 64 7 0.000 0.000 0.004
|
こんな感じ。というわけで、ほってくことにする。なんか六時間かかるとか書いてあるので明日あたりに再確認してあげよう(笑)。
で、一応、
| chkconfig --level 35 ntpd on |
なんてことを書いているうちに使えるようになっていた(笑)。その間10分かそこら。もういちどntpqしてみると、
[root@fujirushi ntp]# /usr/sbin/ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
ntp.hoge.jp 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
*LOCAL(0) LOCAL(0) 10 l 63 64 77 0.000 0.000 0.004
[root@fujirushi ntp]# /usr/sbin/ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
ntp.hoge.jp 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
*LOCAL(0) LOCAL(0) 10 l 11 64 177 0.000 0.000 0.004
[root@fujirushi ntp]# /usr/sbin/ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
ntp.hoge.jp 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
*LOCAL(0) LOCAL(0) 10 l 22 64 377 0.000 0.000 0.004
|
どんどんステータスが変わっていく。桜時計からも確認。OKのようである。というわけで、設定完了。念のため、最新のntpがあるかを
| /use/sbin/up2date -l |
で確認。ntpはなかったが、他のものがいくつかあったので
| /usr/sbin/up2date -u |
で更新しておく。
さて、次はWindowsに対応した手ごろなntpクライアントを探さなくてはいけない。桜時計は悪くないのだが、起動時にWindowが出てきてしまうので、用途によってはちょっと困るときがある。
とそのとき、そういえばBorland C++ Builder 5.0になんかそんな感じのコントロールが付いていたことを思い出す。さっそく、BCB5を起動、確認。
NTPクライアントではなく、timeクライアントだった。まあ、LAN内で使うだけならtimeプロトコルでもいいだろうということで、/etc/xinetd.conf/timeを編集。
# default: off
# description: An RFC 868 time server. This protocol provides a \
# site-independent, machine readable date and time. The Time \
# service sends back to the originating source the time in \
# seconds since midnight on January first 1900. This is the \
# tcp version.
service time
{
type = INTERNAL
id = time-stream
socket_type = stream
protocol = tcp
user = root
wait = no
#disable = yes
disable = no (ここ・有効にする)
only_from = 192.168.xxx.0/24 (ここ・LAN内専用にする)
}
|
これでtimeプロトコルで時刻が取得できることをBCBのIDEから確認(笑)。あとは、PCのハードウェアクロックに時刻を設定するコードがあればいいのだけど、今日はめんどくさいのでここまでにする。まあ、API一発で終わりなので適当なクライアントは作れるだろう。というわけで、いずれ、timeプロトコルを使った適当なWindows用クライアントを作る予定ですので、公開をお待ちください。もっとも、timeクライアントなんぞ作って誰が使うのかは非常に謎ですが(笑)。
無線LAN騒動記。
先週末、PC2(CF-M2EV)が液晶破損でお蔵にはいった。詳細は省くが、出先に持っていく途中どこかでなにかにぶつけたか、あるいは入っているかばんを誰かに蹴られるとかしたようだ。
このCF-M2EV、購入から2年ほど経つのだが，その間にキーボードトラブルが二回、液晶のバックライト不良が一回あって、そして今度の液晶割れである。しかも、ACアダプタのコネクタ部分がかけてしまっていて、さらに、今回のトラブルでPCカードスロットも動作しなくなった。
というわけで、修理すればおそらくメインボード交換＋液晶交換で10万円コースになるわけで、新規PCの購入とあいなった。
ちなみに、このCF-M2EVは、今後、CF-M2Rの予備パーツとして待機する予定になっている。
さて、新規購入したPCは、NECのLavie G Type Jの2003年冬モデル、すなわち、春モデルが出た後値下がりしたやつである。これをNECの直販ウェブサイトの121ware.comで購入。機種選定の決め手は、値下がりした価格と、無線LAN内蔵可能というあたり。
本来、セミデスクトップ用途なので、2スピンドルマシンが望ましいのだが、このところ2スピンドルマシンの選択肢が少なめなので、今回は1スピンドルのB5サブノートまで選定対象にいれた。
このLavie G(っていうか、121ware.comで購入できるPC)は、購入時に1万円ほど余分にお金を払っておくと、3年間の延長保証が受けられる。しかも、この保証、落下や火災でもOKという太っ腹なものである。この保証があるので、今回の機械についてはCF-M2EVのようなことにはならないですみそうである。っていうか、購入後2年しかPCが持たなかったことに関して正直内心忸怩たる思いあふれまくっているのである(笑)。
というわけで、先週末に121ware.comで注文したものが、金曜日に届いた。いろいろと忙しく昨日からようやくセットアップにこぎつけたのだが、これが、いきなり無線LANの接続でトラブル羽目になった。
最初、まあ、普通にバッテリとか付けて起動して、一連の起動動作が完了した後、無線LANのパラメータを設定したところ、接続ができない。ESSIDもチェックしたし、無線LANユニットにMACアドレスも登録した。っていうか、無線LANユニットは、Lavieからの電波をきちんと検知している。しかし、接続だけがうまくいかない。
しょうがないので、Google検索(笑)。すると、Lavieの無線LANは、1-11チャンネルしか使えないらしい。
なにか方法があるはずだと信じていろいろとGoogle検索を繰り返すが、めぼしい情報は見つからない。そんななか、有用な情報を発見。
海外仕様の無線LANカードは、1-11チャンネルしかファームウェアがきちんとサポートしていないことがあるそうだ。というのも、アメリカでは無線LANの帯域として認可されているのが1-11チャンネルなんだそうだ。
ちなみに、ヨーロッパは1-13チャンネル。日本が1-14チャンネルらしい。この14チャンネルというのも、国内で2M無線LAN時代に製品がリリースされていたゆえの接続互換性のためのものだということ。つまり、それこそ、WLI-PCMみたいなカードを接続することが目的のものらしい。逆にいうと、14チャンネルをきちんとサポートしてくれるのは、2Mのカードを出していたベンダーだけという風な考え方もできる。
というわけで、メルコがためでもしない限り、14チャンネルの利用は難しいらしい。そういえば、最近のメルコのアクセスポイントはデフォルトのチャンネルが11チャンネルになっているという話を聞いたことがある。さすがに、メルコといえども、他社製品がつながらないというトラブルを防ぐためにそういう風に変更したのであろう。
なんていいながら、我が家は結局ほとんどメルコがためになっているというのはどうしたものだろうか(笑)。
さて、そうこういっても、しょうがない。無線アクセスポイントを11チャンネルに変更して再度Lavieの接続を試みる。するとすんなりと接続がうまくいった。
しかし、APを11チャンネルに変えるというのは、これまで使っていたWLI-PCMが使えなくなるということを意味している。というわけで、大あわてでヤマダ電機に行き、WLI-PCM-L11GPを購入。これまでのWLI-PCM-L11をWLI-PCMの代わりにして、家庭内LANの再構築も一段落かと思われた。
ところが、このLavieの内蔵無線LANによる接続、異様に不安定である。どうやら、電波の受信状態が非常に不安定らしい。確かに、筐体の中にアンテナがあるというのは、それだけでも受信性能的には不利になりそうである。
以前、メルコのWLI-PCM-S11-CFというCFタイプカードを試したとき、やはり接続が非常に不安定で、結局もとのWLI-PCM-L11に戻したという経緯があった。正直このままでは使い物にならない。というのも、APから1メートル離れたところですらすぐに電波が途切れてしまう。これでは無線の意味が全然ない。
かといって、Lavieに無線LANカードをさして運用するのでは無線LAN内蔵のオプションを付けた意味がなにもない。というわけで、どうすれば電波を良好に受信できるかを調べてみた。
通常の無線LANカードならば、メルコなんかでも外づけのアンテナのオプションが付けられたりする。しかし、Lavieに外づけのアンテナというのもへんな話だし、第一そんなことしたらたとえ家の中がほとんどとはいえ、持ち歩くのが不便でしかたない。
と、そのとき、私はいいことを思いつきました。
そうだ、メルコのアクセスポイントに外部アンテナをつけて発信する電波がいっぱいになるようにすればいいんだ！
というわけで、さっそくメルコのページを見に行って、無線LAN用の無指向性アンテナがあること、最近値下げがあって6000円程度で売っているらしいことを確認した。
ではこれをどうやって入手するか。この手の物品は、このへんではなかなか売っていないことはこれまでの経験で了解済みである。あるいは、前橋のヤマダ電機本店まで行けばあるかもしれないが、さすがにそうそういっているひまもない。というわけで、ここは通販に頼ることにする。
Googleで検索すると、こんなあたりが引っかかってくる。銀行振り込みはうざいのでカードが使えるところを探すと、TwoTopの通販で取り扱っているらしい。
ふだんは、bicbic.comをPC関連品通販の定番にしている。というのも、以前Planexの無線プリンタサーバを探していたときに、ここが比較的安価で扱っていたからなのだが、今回の品は残念なことに扱っていなかった。あるいは最近の価格改定の関係もあって品薄なのかもしれん。
というわけで、TwoTopの通販。TwoTop自体は、東京にいた頃にはよくうろうろしていたし、その後も秋葉原にいけば必ずざらっと見て回るショップだったのだが、経営が傾いたあたりからとんとご無沙汰になっていた。
通販申し込み自体は、さくさくと終了。ふと気がつくと、40Gの2.5インチハードディスクを購入してしまっていたのはご愛敬である。っていうか、最近の2.5インチドライブって安いのね。まあ、容量はデスクトップに比べて格段に少ないけど、家庭内のファイルサーバとしては40Gあれば当面充分そうである。まあ、きたらぼちぼちとセットアップをしていくことにしよう。ってことは、ここまで設定したRedHatは全部再インストールか(涙)。
apmdの秘密。
ノートパソコンにはふつーもれなくバッテリが付いている。一般に古いノートパソコンをサーバとして再利用する際の言い訳に、ノートパソコンにはバッテリがついているので停電時のUPS代わりになる、というのがある。確かに瞬時停電とかだったら、すぐにACが復帰するのでノートパソコンのバッテリは良いかもしれない。しかし、私の住んでいるところは雷と空っ風とかかあ天下が名物の群馬県である。特に雷は、夏場、たまにとはいえ30分以上の停電の原因になることがある。そういった場合、へたれてきている古いノートのバッテリでは長時間のシステムの維持は期待できない。バッテリが切れればそのままサーバがおなくなりである。まあ、運がよければサスペンドなりに入ってくれるだろうし、家庭内サーバだからそうそう頻繁にデータアクセスがおこるとも思わない。ということは、データクラッシュの可能性は低いだろうということなのだが、危険があることには変わりはない。
一般に、UPSというのは、電源断があったときにマシンに電源を供給し、供給できなくなったらマシンを安全にshutdownしてくれるものである。というわけで、こういう機能をノートのバッテリでやってみようというわけである。
そんなわけで、バッテリ残量が少なくなったら自動的にシステムがshutdownするような設定をおこなうこととした。
Linuxでの電源管理はapmdが担っている。このapmd、ACとバッテリが切り替わったり、バッテリ残量が少なくなったりしたとき、あらかじめ設定されているスクリプトを実行するようにできている。このapmdのトリガを利用することでバッテリ残量が少なくなったときに自動的にshutdownできるようにできるはずである。
とりあえず、ドキュメントとかを確認してみると、この自動実行されるスクリプトは、/etc/apmd_proxyというものらしい。しかし、/etcを確認してみてもそういったスクリプトは見当たらない。というわけで、とりあえず、/etc/apmd_proxyに
#/bin/sh echo $1 $2 >> /tmp/hoge |
という感じのスクリプトを入れてみて、どういう反応が出てくるか確認してみることにした。
スクリプト作成後、とりあえずACアダプタのコンセントを抜いてみる。しかし反応なし。
Googleでもう少し検索してみると、どうやら/etc/sysconfig/apmdあたりがなんかあるらしい。そこで、sysconfigのなかをのぞいてみると、apm-scriptsというディレクトリを発見。その中を見てみると、apmscriptというのがある。とりあえず読んでみると、
# DO NOT EDIT THIS SCRIPT, CREATE AND EDIT apmcontinue IN THIS DIRECTORY; you # can put your stuff into apmcontinue for every link you create to apmscript; # for a start and definitely enough for most laptops we have two links and # according subroutines defined here: suspend and resume; all other links # will be redirected directly to apmcontinue which you can create; also # suspend and resume call apmscript, so you can also do other things (like # reinitialising some PCMCIA-Card) there; apmcontinue will get the name # as which it was called as $1; for debugging see the logfiles |
なんて書いてある。どうやらapmcontinueがユーザーカスタマイズのためのスクリプトのようだ。そこで、
mv /etc/apmd_proxy /etc/sysconfig/apm-scripts/apmcontinue |
なんてことをして、再度ACのコンセントを抜いて、その後差しなおしてみる。すると/tmp/hogeに、
power change power change |
とでてきた。どうやらこれでよさそうである。では、こんなふうなスクリプトだとどうだ、
#/bin/sh
if [ "$1" = "power" ]; then
if [ "$2" = "change" ]; then
echo AC changed >> /tmp/hoge
fi
fi
|
というわけで、同じようにテストをしてみると、今度は/tmp/hogeに
AC Changed AC Changed |
とでてきた。では、そろそろと本題に移ろうというわけで、
#/bin/sh
if [ "$1" = "power" ]; then
if [ "$2" = "change" ]; then
#echo AC changed >> /tmp/hoge
/sbin/shutdown -h now
fi
fi
|
というスクリプトでまずは試してみる。編集後、コンセントを抜く。するとすんなりとshutdown開始。すばらしい。
では、今度はlow batteryを検出しようというわけで、再度起動。コンソールでログインする。と、ログインした途端にいきなりshutdown開始…。おいおい、というわけで、今度はinteractive startupでapmdをつぶして起動し、スクリプトをチェックする。見た目には問題がないようにみえるが、もしかしたらapmd起動のタイミングでautocontinueが呼ばれているのかもしれないと考えた。そこで、
#/bin/sh
date >> /tmp/hoge
echo $1 $2 >> /tmp/hoge
if [ "$1" = "power" ]; then
if [ "$2" = "change" ]; then
#echo AC changed >> /tmp/hoge
#/sbin/shutdown -h now
fi
fi
|
とかいう風にスクリプトを変えてみて再起動。もし、起動時にapmdがpower changeを吐いているならばこれで引っかかってくるはずである。しかし、起動後に/tmp/hogeを確認してみると、
Tue Feb 11 21:09:19 JST 2003 start |
とだけ書いてある。どうやら目論見に反してchange powerは来ていないようだ。ならばさっきのshutdownはなぜ？
ここでこの原因を追及するのが真のハックの道なのかもしれない。っていうか、えらいハッカーならここでapmdのソースコードを読み出すだろう。しかし、私はえらくないし多分ハッカーでもないのでこの問題には目をつぶり、とりあえず本命の、change batteryに反応するように、
#/bin/sh
if [ "$1" = "power" ]; then
if [ "$2" = "battery" ]; then
/sbin/shutdown -h now
fi
fi
|
というふうにapmcontinueを修正してしてシステムを再起動する。これでさっきと同じことがおこるようならばさらなる追求は必至になるのだが、今度はログインしてもshutdownはおこらなかった。ならば、さっそくというわけで、そのままACを抜いてバッテリのランダウンテストに突入する。しばし放置していると、忘れかけた頃にハードディスクがからからとまわりだしshutdownが始まった。
途中でバッテリがつきることもなかったような感じでシャットダウンが終了。とりあえずACをつないで再び起動してみる。起動後、まずはapmコマンドでバッテリ残量を確認。5%と出ている。どうやらバッテリがつきる前にshutdown自体は終了できたようだ。
次に、/var/log/messageから、apmd関連のログをgrepで拾い出してチェックすると、
Feb 11 21:29:13 fujirushi apmd[709]: Version 3.0.2 (APM BIOS 1.2, Linux driver 1.16) Feb 11 21:29:13 fujirushi apmd: apmd startup succeeded Feb 11 21:29:14 fujirushi apmd[709]: Battery: * * * (50% unknown) Feb 11 21:34:08 fujirushi apmd[709]: Now using Battery Power Feb 11 21:45:19 fujirushi apmd[709]: Battery: 0.621762 (0:16) 1:04 (40% unknown) Feb 11 21:54:23 fujirushi apmd[709]: Battery: 0.834990 (0:25) 0:35 (29% unknown) Feb 11 22:03:16 fujirushi apmd[709]: Battery: 0.910872 (0:34) 0:21 (19% unknown) Feb 11 22:12:03 fujirushi apmd[709]: Battery: 0.957571 (0:43) 0:09 (9% unknown) Feb 11 22:14:08 fujirushi apmd[709]: Battery Low Notification from APM BIOS (6% unknown) Feb 11 22:14:20 fujirushi apmd[709]: Battery Low Notification from APM BIOS (6% unknown) Feb 11 22:14:45 fujirushi apmd[709]: Exiting Feb 11 22:14:47 fujirushi apmd: apmd shutdown succeeded Feb 11 22:21:11 fujirushi apmd[709]: Version 3.0.2 (APM BIOS 1.2, Linux driver 1.16) Feb 11 22:21:11 fujirushi apmd: apmd startup succeeded Feb 11 22:21:12 fujirushi apmd[709]: Charge: * * * (4% unknown) Feb 11 22:21:56 fujirushi apmd[709]: Now using AC Power |
こんな感じになっていた。ACを抜いたのが21:34でapmdが落ちたのが22:14。ということは、40分間は停電時でもバッテリでサーバは稼動し、その後自動的にshutdownされるということになりそうだ。ログではバッテリの開始が50%になっているが、このサーバに利用してるAL-N2という機種はバッテリを二個内蔵するタイプで、その内の一つが死亡しているのでバッテリ一個だけで動かしている。つまり、ログでは50%とあるが、実質的には100%ということになる。逆にいうと、死亡したバッテリを再生するなりして装着できれば、停電時でも80分はサーバをバックアップできるということになるだろう。これなら、家庭内で起こりうるさまざまな電源事故、すなわちブレーカー断とか、コンセントまちがって引っこ抜きとかでも障害は起こるまい。