Re::Monologue

サーバの移行作業を進めていたところTracが動かない。こんなエラーが。

Warning: リポジトリと同期できません (Subversion リポジトリ /home/svn/repos をオープンできません: SubversionException: ('Could not configure SQLite', 200030))。詳細は Trac のログを参照してください。

調べてみたところ、Subversionのバグのようでした。バグレポートの環境が、ばっちりFreeBSD7.1。「fixed in Subversion 1.6.2」って書いてあるけど、1.6.2はまだリリースされてないじゃん・・・。

ということで、ここの内容通りにソースコードを修正してインストールしました。手順は以下。

cd /usr/ports/devel/subversion
make extract
vim ./work/subversion-1.6.1/subversion/libsvn_subr/sqlite.c

505行目付近
------------
SQLITE_ERR_MSG(sqlite3_config(SQLITE_CONFIG_MULTITHREAD),
------------
↓
------------
int err = sqlite3_config(SQLITE_CONFIG_MULTITHREAD);
if (err != SQLITE_OK && err != SQLITE_MISUSE)
return svn_error_create(SQLITE_ERROR_CODE(err), NULL,
------------

make WITH_MOD_DAV_SVN=YES WITH_APACHE2_APR=YES WITHOUTBDB=YES
make install

tracのインストール手順は以前に書いたので省略。この作業でエラーはでなくなりました。

この手の作業でトラブルを回避するのは滅多にないので記念にメモ。でも次に見るときは解決しているだろうからあんまり意味はないですね。

常時稼働しているサーバが増えてきたので、今後は仮想環境に集約して物理サーバの追加台数を最小に抑えようと考えています。現在自宅にあるPCの数は使っていないものも含めると12台。これを徐々に減らしていきたい。

常用するメインサーバはVMware上のFreeBSD7.1に移行することにしました。メインサーバはSambaとしても使っていたのですが昨年末にVmwareのホストサーバに移動済み。今回移行したものは以下。

• apache+言語環境
• MySQL
• FTP
• Subversion+Trac
• munin

知人に貸しているWebサイトを運用しているためPerlやPHPやMySQLなどの各種文字コード環境を完全に同一の状態に整備する必要がありました。どのような環境を作ったかを思い出しながら再現していくのは思っていた以上に面倒な作業であり、全体で10時間以上もかかってしまいました。特にSubversionの不具合と、mysqldumpでの文字化けには悩まされました。
後のことを考えてサーバに施した作業は全てドキュメント化することにしたのですが、コマンドだけの手順書が今回だけで400行。大したものは乗せていないつもりだったのですが、サーバを長期動かしているといろんなものを入れてしまったりするので塵が積もって山となっていた感じです。

大変な作業でしたがなんとか完了。雨降るGWに行うには丁度良いタスクでした。

3年前に作ったサーバはshutdown。PentirumIII-S 1.26GHz/MEM 1GBという当時から見ても旧世代に属するスペックでしたが、実に安定した良いサーバでした。ありがとう、Tualatin。

shutdown時のデータはこんなかんじ。

# uname -a
FreeBSD example.com 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Sat Jun 30 12:36:29 JST 2007     username@example.com:/usr/src/sys/i386/compile/GENERIC  i386
# df -h
Filesystem       Size    Used   Avail Capacity  Mounted on
/dev/twed0s1a    1.9G    130M    1.6G     7%    /
devfs            1.0K    1.0K      0B   100%    /dev
/dev/twed0s1e    3.8G    436M    3.1G    12%    /tmp
/dev/twed0s1f    212G    149G     46G    77%    /usr
/dev/twed0s1d    3.8G    3.2G    262M    93%    /var
/dev/ad10s1d     451G    243G    172G    58%    /home1
# pkg_info | wc
     504    3819   34277
# uptime
 5:16PM  up 392 days, 17:27, 2 users, load averages: 0.15, 0.11, 0.08

ものすごく久しぶりにFFをしてみました。奇跡的に集合したリアフレとパーティプレイ。
レベルシンク、素敵です。

運用している掲示板はCAPTCHA付き。しかし最近少しずつスパムが増えてきました。CAPTCHAは現時点での最も有効な掲示板スパム対策だと思われますが、意味をなさなくなる日も近いのかもしれません。

新たな対策ということで、MT-Keystrokesの実装をコピーしてみました。キーボード押下時に発生するイベントを使えば、IEコンポーネントを使うようなボットをしのげるのではないかと。自分で書こうと思いましたが案の定既に世の中にあった。

ということで内容は以下。MT-Keystrokesの中身そのままです。Perlで書かれていれば基本的にはどのようなタイプのプログラムにも適用できるでしょう。

<script language="JavaScript" type="text/javascript">
<!-- 
function keystrokes(form) {
    form.strokes.value = 1;
}
//-->
</script>
<input type="hidden" name="strokes" value="0" />

掲示板のコメント投稿ページに上記を追加。

<textarea name="comment"  onkeypress="keystrokes(this.form)">

textarea要素に「onkeypress="keystrokes(this.form)"」を追加

<input type="submit"  onclick="keystrokes(this.form)">

submitボタンに「 onclick="keystrokes(this.form)"」を追加。

あとは書き込みスクリプト側で、「strokes」パラメータの数値が「0」でないかを確認するようにすればOK。例えばCGI.pm環境だと以下のような感じ。

use CGI;
die "error" if $q->param('strokes') < 1;

※実際にはdieで殺す処理はありえないので適当なエラーハンドリングを行います。

スパム書き込みは毎日数件あったのですが、二週間前にこの対策を施したところ現時点まで一件もスパムが来ていません。所詮はJavaScriptなのでいずれ突破されてしまうとは思いますが現時点ではかなり有効であり、かつお手軽な対策です。お試しあれ。

参考

• http://rebecca.ac/milano/mt/archives/001649.html
• http://japan.cnet.com/blog/kenn/2008/02/28/entry_25005627/

※上記はかなり単純な処理ですがキー押下時のイベントを捉えるロジックを複雑化すると強力な対策になり得るかもしれません。全角文字数とキーストローク数の相関関係は少なくとも海外のエンジンには判定できない、ような気がする。