サーバがまた死んだ

この間の豪雨の際、雷で三回ほど瞬間停電したのだが、どうやらこの間にサーバのデータが壊れていたようで、起動不能になった（起動中にエラーを吐いてランレベル６に移行するのだが、そっちでもエラーを吐いて止まる）。

ちょっと調べても原因がわからなかったので、（この間やったばかりなので覚えているということもあり）Debian Lennyを再設定することにした。

ApacheとSubversionのインストール（ + ApacheのWebDAVを使ってSVNを動かす）

必要なパッケージのインストール

# aptitude install subversion libapache2-svn

libapache2-svnをインストールした時に、apacheのdavというモジュールが有効になる（apache2をパッケージで入れた場合、無効になっているだけで既に入っている）。

# mkdir /var/svn

# svnadmin create /var/svn

# chown -R www-data:www-data /var/svn

リポジトリを作成する。ただし、ここでリポジトリの所有者をapacheにしておかなければならない。

以下の内容を/etc/apache2/conf.d/以下に適当な名前（svnなど）で作る。

<Location /svn/miku>
DAV svn
SVNPath /var/svn/miku

Order Deny,Allow
Allow from 192.168.1.0/24
Deny from all

</Location>

Order ~ Deny from allまでは、192.168.1.*しか許可しないという意味になるので、外からのリポジトリへのアクセスを一切拒否している。外からアクセスしなければならない時はSSHでトンネルを張れば良いだけのことなのでこれで十分。なお、ローカルからもトンネル経由でないと許可しない、という設定にする場合は、Allowのところにlocalhostと書いてもいいかもしれない。いずれにしろ、SVNはソースコードなどの重要なデータがインターネット上を流れるので、SSH、VPN、SSL等で暗号化するのが望ましい。

ここまでの設定を確認。ローカル（別のPC。別に同じマシンでも可）にてチェックアウト。

本当はインポートとか使うんだろうけれど、普段やり慣れている方法でやってしまうよね（その方がミスが少ない・・・成長を妨げる要因だ）。

$ svn checkout http://server/svn

$ cp -ra /path/to/original svn/

$ svn add svn/*

$ svn commit

コミットできたら一応成功。

コミットしたら公開

こういうのを何て呼ぶのかは忘れたが、リポジトリのhook scriptを触れば実現できた。

/var/svn/hooks/post-commitに以下のように書く。

#! /bin/sh

/usr/bin/svn export --force file:///var/svn/ /var/www/

post-commitはコミットが成功した後に実行されるコマンドなので、この中にエクスポートするコマンドを書いておけばいいのだ。

これで、コミットの度にファイルが/var/wwwにエクスポートされるようになった。

eRubyを有効にする

参考：　eRuby(mod_ruby)のインストール方法

RubyをPHPみたいに組み込みっぽく使いたいので（というか我がWebサイトで使っているので）eRubyを導入する。普通のHTMLのように書けるが、の間に書いた文章はRubyスクリプトとして実行される。

このインストール作業が意外と面倒。

# aptitude install euby eruby libapahe2-mod-ruby

まずは普通にインストール。

そして、/etc/apache2/mod-enable/ruby.loadに以下を追記（参考サイトからコピー）。

<IfModule mod_ruby.c>

RubySafeLevel 1

RubyRequire apache/ruby-run

RubyRequire apache/eruby-run

<Files *.rhtml>
SetHandler ruby-object
RubyHandler Apache::ERubyRun.instance
</Files>

</IfModule>

なお、私の場合はRuby Script内でファイルの最終更新日を調べているが、これはsafe levelが0でなければ動かないらしい。なんだか気味が悪いが、とりあえず0にした。

これだけでは、*.rhtmlをクリックしてもファイルダウンロード画面になってしまう。原因は、Live HTTP Header等で調べれば一目瞭然だが、MIME Typeが「application/x-httpd-eruby」というよくわからないものになっている（通常、text/htmlになっている）。これを正すために、/etc/mime.typesにちょっと手を加える。

以下のような行があるので、その行頭に # （コメント）をつける

application/x-httpd-eruby rhtml

これで完了。なんでも、eRubyがこういう風にmime typeを決め打ちされることを想定していないらしい。

これで私の環境復元は終了したのだが、6月、8月と二度も立て続けにクラッシュしたという事実をみすみす見逃してはいられない。あまりにもばかばかしいことだが、一応まとめると：

• 停電対策（UPS）がまったくなされていない
• バックアップサーバ自体のバックアップは取られていない

という問題があった（というか、ある）。

まず、UPSは雷の多い地域なので見当の余地はあるが、お金のかかることなのですぐには手は出ない。

問題は二つ目である。これは絶対にやっておくべき対策で、今すぐにでも手を打つべきだ。いままでやってなかった理由としては、「HDDの空き容量がないよ！」だったのだが、今やサーバにHDDを４台ほど積めるスペースがあり、バックアップ用HDDも搭載しているので、やろうとおもえばすぐにできる。

異常気象とはいえ、組んだばかりのサーバをあまり痛めつけてほしくないものだ。