webcache (v0.1.0) (55.6 kB)

参考)
ログ総数訳7,000のWikiで除外ページリストを再生成すると約25秒掛かった(Oblivion Mod 翻訳所)。

1. クライアント側のキャッシュを有効に利用してもらう形

　PukiWikiで304を送信する仕組みを色々調整していたのですが、はまった点があったので備忘録代わりに記事にします。

Cache-Control&Expiresヘッダの送信はApacheとScriptの両方が絡む
　レスポンスヘッダのCache-Control&Expireはローカルキャッシュの寿命を指定できます(順に、キャッシュは使用しない・キャッシュ有効期間は今から3,600秒・グリニッジ標準時2010-09-08 00:00:00まで有効)。

Cache-Control: no-cache

Cache-Control: max-age=3600

Expire: Wed, 08 Sep 2010 00:00:00 GMT

これはPHP Scriptでも送信できます。例えばCache-Controlなら

header("Cache-Control: no-cache");

header("Cache-Control: max-age=3600");

と出来ますでも、Apache側でも設定をいじって送信するように出来ます(.htaccess他, Apache 1.3系でも可能)。

ExpiresActive On
ExpiresDefault "access plus 10 days"

　ではここでApache側のその設定を残したままでScript側からもCache-Controlヘッダを送信してみましょう

header("Cache-Control: no-cache");

さあ、どう返ってくるでしょうか。

Cache-Control: no-cache, max-age=864000

えーっ？追加されちゃうんですかっ。ブラウザさんはどう解釈するんだろう、これ^[2]。

　ではScript側を修正してみましょう。max-ageを既に準備しちゃえばApacheさんも遠慮するに違いない。

header("Cache-Control: no-cache, max-age=0");

するとこうなります。

Cache-Control: no-cache, max-age=0, max-age=864000

えーーっ。まぢっすかっ。ブラウザさん(以下同文)。

　色々試行錯誤してScript側からこう出力すると

header("Cache-Control: no-cache");
header("Expires: Wed, 08 Sep 2010 15:41:03 GMT");

Cache-Control: no-cache
Expires: Wed, 08 Sep 2010 15:41:03 GMT

となり、ようやくApacheさんは遠慮してくれました。つまり、ExpiresヘッダもScript側で準備しないといけないみたいです。Apache側でこの機能を提供するmod_expiresのドキュメントによるとCache-ControlとExpiresの両方の出力に影響するとの事なのでこの挙動はそう不自然ではありません。Cache-Controlにどんどん追加してくだけってのはちょっとアレですが。

　じゃあ、Script側でこうしたら…

header("Cache-Control: no-cache");
header("Expires: HOGE");

Cache-Control: no-cache
Expires: HOGE

Apacheさん、チェックがあまいっすー。またこんなのも

header("Cache-Control: max-age=65535");
header("Thu, 01 Jan 1970 00:00:00 GMT");

Cache-Control: max-age=65535
Expires: Thu, 01 Jan 1970 00:00:00 GMT

Cache-ControlとExpiresの内容のミスマッチでもApacheさんスルーします。まぁいちいちチェックされると不便な事もあるのでこれらの挙動はそう問題ではないのですが…ブラウザさん(以下同文)。

　色々面白い現象も見られましたが、結論としてはExpiresヘッダをScript側で(値はどうであれ)出力すればCache-Controlで発生する現象は回避できるという事です。

　あと、ApacheのExpiresヘッダ送信機能はファイルのMIME毎に指定も出来ます。

ExpiresActive On
ExpiresByType image/jpeg "access plus 30 days"

これは通常の画像ファイル直のアクセスでは当然のごとく作用しますが、Script経由で画像等を表示する場合^[3]でも適用されます。深く考えずに利用できるのは便利なのですが、場合によってははまる箇所になりそうなのでこれもメモしておきます。

1. 一本なら軽自動車にも入りますが運転は多少厳しくなります
2. 無難に考えるならorで判定？調べるの面倒なんでやってませんが
3. 例：PukiWikiのrefプラグイン

IP規制の多少の緩和
　先日、spammer対策のアクセス禁止処置の緩和を行いました。
　今までspam行為が酷い海外のISP(若しくはIP範囲)はアクセス禁止を行っていました^[1]。こういうspammerは投稿フォームを見つけたら見境無く投稿を行うような自動プログラムを走らせてspam行為を行っているので閲覧すら禁止するのは一定の効果があると考えていました。またネット上にはE-Mail収集Crawlerも徘徊しており、これらによって収集されたアドレスにspamがバンバン送られるような事も発生する為、これらの閲覧を禁止するのも予防としては悪くない選択でした^[2]。アクセス禁止は厳しい上に誤爆の危険性も高かったのですが、同時に『報告して貰えば即効で解除する』という対応もとっていたので問題性は低いと思っていました。が、日本人の特性か『見れなかったら諦める』というパターンが多かったようです^[3]。
　声なき声を察する事は間違った結論に達する危険性も無いではありませんが、善意の方が不利益を蒙る事の方が問題です。よって規制の緩和処置を行いました。具体的にはアクセス禁止ではなく投稿禁止に変更しました。これにより今までWikiを閲覧できなかった方も利用ができるようになりました。但し、『投稿禁止』なので編集は勿論、Wiki検索の一部^[4]等は利用できません。また、一部の悪質と思われる行為を行ってきたIP群は依然アクセス禁止のままにしています^[5]。
　緩和からしばらくその事実を伏せていましたがこれは緩和によるspammerのアクセス増加がどれくらいになるか調べる為でした。現在のところはあまり大きな動きは見られませんが今後も監視は必要かと思います。spamにまみれたSiteもまた善意の利用者にとっては価値の無いものでしょうから。
　因みに、投稿禁止エラーのログは取っていません^[6]。よってこれもまた誤爆が発生した場合でも当方が確認できない可能性が有ります。よってWikiの編集を行いたいが規制誤爆が発生している場合、以前と同様に当方までお知らせくだされば対応します。blogメニューのコンタクトフォームからご連絡ください。

304 Not Modified機能追加
　先日の作業でWikiのrefプラグインに304 Not Modified送信機能をつけましたが、今度は本体のページ表示にもその機能を付加しました。ただし、後ろ向きな仕組みで対応させました。
　何が後ろ向きかというと、Wikiの全てのページに対応できないという点です。これは、一部のプラグインにはそのページのWikiソースに変動が無くとも表示が動的に変化するものがあります^[7]。そういう事例の対応が極めて困難な為、そういうページでは304送信処理を行わない事にしたのです^[8]。どうせそのようなプラグインを使用したページは多くないでしょうし、そう問題は無いと判断しました^[9]。とりあえず管理下のWiki全てに導入しました。キャッシュ利き過ぎ等を疑う場合はブラウザのキャッシュクリアで解決できるとは思いますがもし不具合があったらご連絡頂けると嬉しいです。
　ちなみに今回これを実装したのはNew Vegasの方の発売時のアクセス集中の対策を考えた結果です。Fallout 3 Wiki JPの方の発売時のアクセス集中はミラーを準備する事で回避しました。今回はサーバを変えたおかげでそこまでする必要は無いでしょうが、だからといって対策を何もしないのも問題という事で今回の改造と相成りました。
　需要は無いとは思いますが興味のある方はどうぞ。PukiWiki 1.4.7 UTF-8版をベースにしてあります。導入方法はrefの方は上書き、本体改造ファイル(webcache)は添付文書を読んで下さい。PukiWiki 1.4.7 EUC-JP版は文字コードを変換するだけで大丈夫かと思います。Plus!は検証していません^[10]。
webcache (v0.0.1) (42.2 kB)
ref.inc.php (v0.0.1) (8.7 kB)

完璧雑談
　Twitterとか流行っていますが自分は当分する事はない気がします。慣れなのかもしれませんが、閲覧側としてもなんとなく読みにくいし、発信側としても未整理で質の低めな情報をオープンにするのは色々申し訳ない気もするからです。自分には発信するならそれなりに整理・資料化等して分かりやすくしなければというポリシーみたいなものがあります。まぁ、有意義な情報が未整理のまま埋もれていくよりは公開し、閲覧側が必要情報を取捨選択するのはそう悪い方向性ではないのでしょう。それに理由有る無しに関わらず叩かれる原因になるというような状況も日本では散見されます^[11]。叩かれるような発言をする方が脇が甘いのかもしれませんが、しかしTwitterとは揚げ足取りの事まで考えて利用する場ではないと思います。勿論脇の甘い発言をしがちな人は大体その人の性向がそうである可能性が高いのは否定できませんが。
　きちんと推敲して記事化する事でそういう問題を完全に回避できるとは思いませんが、それでも或る程度はその確率を減じる事が出来ると思います。
　そういえばmixiもアカウント取っただけでやってないですね。流行に流されないといったら聞こえは良いのですが、頑迷なだけなのかもしれません、あははー。

　過去ログ保管を好きでやっているのは良いのですが、正直な話スレが増えすぎっ。そんな訳で完全にスレの中身を追えていません。よって何かあったらスレではなくWikiの運営ページか、このbogか、このblogのコンタクトフォームまでお願いします。手を広げすぎ？いやいや、例えばOblivionプレーヤーでも2chの関連スレを全部読破している人はそう多くないと思うです。また、スレが増えすぎて存在に気づかないでスルーしているスレも有るかもしれません。そういうのが有った場合も遠慮なく教えて下さると助かります。
　

1. 但し、Wikiのみ。過去ログ置き場や当blogは殆ど規制なし
2. そういうCrawlerの探知の為の罠を管理サイト群では設置しており、実際に捕獲している
3. 日本のISPはアクセス禁止処置から基本的に除外していたので、多くは海外在住の日本人
4. Namazu検索ではないWiki組み込みの方
5. クラッキング等。本当に能力があるならアクセス禁止なんて問題じゃないのでしょうけど
6. アクセスログを読めば分かりますが、投稿禁止エラーだけ抽出したログは無い
7. #lsや#include、#tracker_list
8. 例えば、あるページから#lsで以下の階層にあるページをリストアップしたとする。この場合、リストアップされたページの削除や更新も調べない事には304を送信すべきか否かを判断できない。この調べなければいけない対象の絞り込み方ががプラグインによって異なるので最悪プラグイン毎に対応コードを書かねばならず極めて非効率的
9. 例えば Oblivion Wiki JPではページ数は約600弱でその中で304送信機能で不都合なプラグインが使用されているのは約70程
10. 多分いけそうな気はするが
11. 海外ではどうなのかは知りませんが

雑談雑談ー。

304 Not Modified処理をrefプラグインに組み込み
　PukiWikの場合、画像をUploadしてWiki上のページに表示できます。セキュリティの問題上、画像等はファイルへの直接のリンクではなく、refプラグインを介して呼び出されています。これは普通問題は無いのですが単一ページに画像をたくさん表示した時に足かせになります。『プラグインを介して～』という事は即ち画像と同じ数だけPHP Scriptが走らされるという事です。これは何が問題なのかというと、勿論サーバ負荷の問題も一つありますが、レンタルサーバによっては同時に実行するプロセス数^[1]を制限しているものがあります。また同時リクエスト数制限を行っている可能性も有ります。それらに引っかかると、画像が表示されなくなったりサーバエラー(500や503等)が表示されるでしょう^[2]。サーバに多くの利用者を詰め込んでいる廉価サーバ程これは顕著に現れるでしょう。多分経験のある方も多いのではないでしょうか。そのような制限は共用サーバではどうしても必要なものなのですが、利用者にとっては不便に違いありません。この問題の回避をいくらか期待できる方法があり、これが “Last-Modified”ヘッダと”If-Modified-Since”ヘッダを使う方法です。

　これは、はじめのサーバからのファイル送信時に『このファイルの更新時間は～だよ』(Last-Modified)を送り、ブラウザ側は再度それをサーバから取ってくる時に『前にリクエストした時、このファイルの更新時間は～だった。もしそれより新しかったら頂戴』(If-Modified-Since)と送信します。サーバ側はこの申告をチェックして『前に見た時より新しくなっているから送信するね』と新しいファイルを送信するか、『前と変わって無いや、キャッシュを利用してちょ』(304 Not Modified)というような感じのやり取りで実現されます。これにより転送量が節約できるのは勿論ですが上述のrefプラグインの件に関しても同時起動数や同時接続数の節約およびWiki閲覧の快適化が期待できます^[3]。

　分かっている人には何を今更(しかもかなり適当)、分からない人にはチンプンカンプンかもですが、本題はここから。上記の事実は把握はしていたのですが、PukiWikiも或る程度は実装しているだろうと思って気にしてませんでした。しかし、ふとrefプラグインのコードと実際のHTTP通信の様子を見たら……あれ、もしかして実装されてない？そういう訳でがしがしと改造しました。実際に画像の多いページで試すと表示終了までかかる時間が短縮されていますので効果はあるようです^[4]。実際のHTTP通信の様子も期待通りになっています。とりあえずは成功ということでしょう。あとは本来のサーバ負荷やらの部分で改善が図れるかという点です。まあ、z49.org以下のWikiにはあまり画像は無いので殆ど意味は無いかもしれませんし、独学＆資料の勝手解釈で修正したので必ずしも実装が正しく出来ているかは自信ないですが^[5]、とりあえず問題ないので良しとしましょう。

　しかし、ぽんこつな私が片手間でも書き上げられるコードなのにOfficcialで実装されていないのはなぜなのか多少気になるところです。何らかの問題があったのかもしれません。あと、PukiWikiのページ表示自体にもLast-Modifiedを送信する機能はあるのですが^[6]、これはいまいち活用されていないように見受けられます^[7]。ブラウザ側の『前の更新時間から～時間以内は再リクエストせずキャッシュから読む』みたいな挙動を期待しているのかなぁと思いますが、このいわゆる『ブロードバンド時代』ですし大抵は『Webサイトを表示するたびに確認する』のような設定にしている方も多いでしょうから効果は薄い気もします。ページ表示自体にもこの仕組みを組み込むことは試してみて動く事は確認したのですが^[8]、pluginではなく本体部分の改修で影響範囲がつかめない^[9]ので修正はちょっと躊躇しています。PukiWikiのプログラム構造を完全に把握していませんし。

Fallout New Vegas Wiki JP設置
　Bethesdaファンの私がやらない訳無いじゃないですか！
という訳で設置してみました。色々今まで検討した修正を突っ込んであります。

　URIは以下になります。

http://newvegas.fallout.z49.org/

いつもこの辺のサブドメインの選定は悩んでしまいます。URIは出来るだけ短くすべきなのですが、分かり難くなってもいけません。他に候補は

1) wiki.newvegas.fallout.z49.org
2) wiki.nv.fallout.z49.org
3) falloutnewvegas.z49.org
4) fallout-newvegas.z49.org

と考えましたがどれもいまいちな印象で却下しました^[10]。

　中身はFallout 3 Wiki JPのものをかなり転用しています。というか、そのログからFallout 3なものをばっさり削除した形です。Fallout 3の時もOblivionの転用だったのでまぁ問題は無いでしょう。

1. Scriptもしくはプログラムの数と読み替えても良い
2. デフォルトのPukiWikiはCSSもPHP Scriptであるので同じくこの問題に影響される。解決策として通常のCSSファイルに変更する方法もよく用いられる
3. ファイルが更新されてなければScriptをそこで即座に終了出来る為
4. wiki.oblivion.z49.orgのMOD/特集記事/VWD_Mod比較/検証 等
5. refプラグインのみ手を加えてattachプラグインはそのままなので実質にはページに貼り付けた画像の表示にのみ関係する修正。attachプラグイン経由でDLや画像の表示を行う場合は無関係。画像のキャッシュがおかしいと思う場合はattachプラグイン経由で確認すればよい
6. pukiwiki.ini.php $lastmod
7. If-Modified-Sinceを受け取って処理する部分がPukiWikiのどこにも無い。更にデフォルトで”Cache-control: no-cache”, “Pragma: no-cache”なんてヘッダを送信している(skin/pukiwiki.skin.php)。確かに普通のファイルはキャッシュが変かなと思ったらURI末尾に”?”をつけてリクエストすれば簡易的に確認できるが、PukiWikiの場合は同じ方法が出来ないのでローカルキャッシュクリアしか方法が無いが
8. lib/html.phpのcatbody()の前の方で行えば良い
9. 現時点で、include等のプラグインを使ったページ等の場合は処理が面倒な事は確認済
10. 1は一番明快だが長すぎ。2は長さの元凶を短縮したが訳が分からなくなっただけ。3は英語圏では普通だけどキャメルケースな記法(FalloutNewVegas.z49.org)にしないと激しく可読性が悪い。4は分かりやすいが今までの管理サイトのパターンから外れるので微妙。そもそもドメイン文字列も基本的にはドットで区切られた階層構造的設計が普通

　さて、今回も管理周りの雑談です。殆どの人には不要な情報ですけど自己満足兼誰かのお役に立てるかもという趣旨で色々と。

　プログラム上の問題を解決する手がかりにする為にサーバ側で取得できるエラーログは全て出力する設定にしています。PHPに関しても同様で、サーバの設定で出力するようにしてある…のですが、先日確認したらとんでもない事になっていました。なんと、エラーログファイルサイズ4GB。メガじゃないです、ギガ。10の9乗です。いつもは数MD程度に収まっていたのですが。何が起こっているのかとても興味は有ったのですが流石に4GBを落とすのは時間かかってしょうがない上に原因はなんとなくつかめていたのでさくっとサーバ上で削除しました(サーバ上で圧縮してDLする手も有ったが時間かかり過ぎてサーバ上でプロセスが殺される可能性が高かった)。

　そこまでサイズがでかくなった一因と思われるのはサーバ上のphp.iniの設定で

error_reporting = E_ALL
display_errors = Off
log_errors = On
error_log= /hoge/fuga/php_error.log

なんていう設定にしているせいでもあります。簡単に言いますと、”error_reporting”で”E_ALL”(致命的でない些細な問題も報告対象にする)という所がこの原因です。実運用では

error_reporting = E_ALL & ~E_NOTICE

のようにして些細な問題は記録しないようにするのが普通なのですが、ここは個人的な理由でそうしています。即ち、瑣末な問題も解決できるものは解決しよう、目指せエラーログサイズ0！なんていうアホな方針を持っているからです。いや、そうすればたぶんサーバ負荷も最終的には低減できますし…あ、いやー、えーと、かなり自己満足です、はい…。

　で、エラーログの肥大の原因は恐らく使わなくなったCGIでエラーを吐くようになった物があり、これをWeb検索サイトのCrawlerが頻繁に叩き始めた事と推測されます。物によっては一回のアクセスでエラーログが数行生成されるらしく、そのせいで膨大なエラーが発生するという構造です。面倒なので原因と思われるCGIをさくっと削除しました。とりあえずこれで様子見です。

　今まで機会が無かったのでアナウンスしなかった事をついでに一つお知らせしておきます。OblivionとFallout 3の過去ログ検索に人気の検索語というページを作成しています(Oblivion、Fallout 3)。これはログを調べる際に参考にしてもらう為に作成しています。FAQなネタを探すにもたぶん便利でしょうし。で、これのデータは更新Scriptで半自動的に作成しているのですが^[1]、実は一部の語句はNG Wordとして集計から除外しています^[2]。除外語句は誹謗中傷関連や成人指定的な物が多いです。無駄に荒れる要因は除外したい所ですし、又、z49.org上のSiteは成人指定ではありません^[3]。多分そのようにしていた事にお気づきの方は多くなかったかもしれませんが、公開できる情報は公開すべきという方針の下、ここにアナウンスしておきます。

1. 集計済みデータのUPは手動
2. 集計から外しているだけであり、自分で検索フォームに突っ込んで検索しても弾かれるという訳ではありません。そこまでやったら検閲ですから
3. 過去ログ置き場Siteのトップには成人指定カテゴリの項目を載せてないのはこれが理由

　Google等はSitemapという仕組みを提案しており、実際にそのCrawlerはそれを利用しています。Sitemapを準備することで効率的に検索が出来るようになることが出来るのですが、Wikiの場合、Sitemapを手動で作成するのは結構面倒です^[1]。GoogleではXMLなSitemapの代わりにRSSも利用できるとの事ですが、PukiWikiのRSSプラグインでは更新が新しい順から～件(設定による)しか出力されず、その目的には利用できません。全ページ出力するのは問題が多すぎます。そこで『無いなら作っちゃえ』の方針でPukiWiki用のSitemapを作成するScriptを作成しました。最初は外部Scriptでした。当方は複数のWikiを稼動させている関係上、それらのSitemapを一元的に管理出来るようにする事が最大の目的であり、それを実現するにはpluginでは不可能だったのです^[2]。pluginなら探せば有るでしょうが、そのような特殊事情向けにScriptを公開している人はいないでしょう。それが自作しようという動機でした。ま、でも大抵の方はそんな複数も管理してないでしょうからpluginで十分だよなぁ…って事でplugin版も作ってみました。コードが転用できるという目論見の元^[3]。

　このplugin/Scriptの特徴は次のとおりです。
・更新間隔の制限が可能 (Wikiが更新されて無ければ更新しないようにも出来る)
・Sitemapに載せたくないページを正規表現で指定可能
・外部Script版はさまざまな追加機能あり^[4]

　外部Script版とplugin版はいろいろ機能の差が有るのでそのへんは添付文書をご参考ください。

　ダウンロードは次のリンクから出来ます。
make_sitemap (v0.0.1) (19 kB)

　検証が十分とはいえないのでもし何かありましたら遠慮なくどうぞ。

1. 更新が頻繁なため
2. 各Wiki毎に導入する必要あり
3. 実際はあまり転用できなかったし、後に検索したらたくさんSitemap作成pluginは公開されており、当方作のものより多機能なものも散見された。まあいいのです、自分の勉強になったので
4. 複数のWikiを一括管理、Alias機能、GZIP圧縮機能他

　先日の記事の段階では特徴もつかめず何のソフトによるものか分かりませんでした。そこでその妙なアクセスパターンでアクセスログを検索してみました。すると以下の点に気がつきました

・類似のアクセスは日本各所から確認できる事
・そのアクセスの殆どがFirefox

つまり、そのアクセスは特定の個人が行ったのではなく、Firefoxのアドオンか何かなのではないかという推測が成り立ちます。では何のアドオンなのでしょうか。探してみたところ、いくつかのアドオンがリリースされているようです。検証する手間が面倒なのでどれが怪しいのかは確認してませんが。

　おそらくアドオンのバグか設定がまずい事によるものなのでしょう。…にしては、1日で3万リクエスト、ほぼHTMLファイルだけだというのに100MBもDLしていくという快挙を成し遂げる事例を見るとうっへりしちゃうところもあったりなかったり^[1]。とは言え、サーバ全体で多い日でも6GB/dayにいく事はそうないのでサーバ負荷という点ではあまり問題は無かったりします。しかしながら共用サーバですしある程度の対策はとらざるを得ないと思っています。

　しかし、ダメダメ言うだけでは建設的ではないので一括DLソフトでの保存に使えそうな条件を色々メモしておきます。

・下手にプログラムにリンクを追わせるよりWikiの『一覧』(cmd=list)を食わせて対象ページをリストアップするのが一番スマート
・同じく添付ファイルも一覧で表示出来るのでそこからリストアップ (plugin=attach&pcmd=list)
・Wikiのページは以下の正規表現で表現可能
　　

\?[a-zA-Z0-9%_.-]+

　これで無駄な編集ページやバックアップページ (?cmd=edit等)を除外できる
・添付ファイルは同じく次のように書ける
　　

\?plugin=(?:(?:ref&[^"]+&src=([^"&]*))|(?:attach&[^"]+(?:openfile|file)=([^"&]*)))

　　少し難解だが要するに
　　　

\?plugin=ref&******&src=添付ファイル名
\?plugin=attach&******&openfile=添付ファイル名
\?plugin=attach&******&pcmd=open&file=添付ファイル名

　　の3パターン。これを一括で表現しただけ^[2]
　　多少の問題^[3]を無視するなら
　　　

\?plugin=(?:ref|attach)&[^"]+(?:src|file)=([^"&]*)

　　ともう少し簡単に書ける

このように正規表現が使えるならWikiの保存自体はそう面倒ではありません。逆を言うと、正規表現でinclude/excludeが制御出来るプログラムでないとWikiの保存は簡単ではありません。自分はGetHTMLWとWeBoXしかためしに使ったことはありませんが、そのどちらもWiki保存には役に立ちません。サイトごとの細やかな設定が出来ませんし、そもそもページ名やファイル名を上手く処理出来ません^[4]。仮に上手く保存が出来たとしてもWiki内のページ間リンクが相対Pathではなくhttpから始まるURIであるのでこれの置換処理を行う必要があります(もちろん添付ファイルも)。ここまで読んで結構面倒だと分かった方はそれ正解です。自分だったら変にソフトの設定で苦労するよりは専用Script書いちゃうかなってくらいです^[5]。そう考えるとWiki保存特化のプログラムってそれなりに需要あるかもしれません。そう難しくない上にまとめサイトも多い現状を考えると公開したら人気出るかもしれません。自分は使う事もあまり無いですし、むしろWiki管理側としてあまりそういうソフトは喜ばしくないと思うほうの立場なので手を出すことは無いでしょうが。

　そこまで嫌がるならローカル閲覧用HTML化済データを置いた方が良いという方も居られる思いますが、色々問題があるので現時点では採用していません。dump2htmlというプラグイン^[6]の存在も知っていますし、自動化が不可能でない事も見当がついています。ですがWiki全頁のサーバ上での一括変換は流石に負荷を気にすべきでしょう^[7]。Oblivion Wiki JP (避難所)ですら約600ページは有るのですから。どうしても言う方には個別対応をする方針ですので必要ならフォームから連絡をどうぞ。

　ついでに。z49.orgのドメインの期限が近かったので更新しておきました。一年おきだから結構忘れやすいんですよね。期限切れが近くなったらメールで連絡が来るのですが、英語だとかspamに埋もれてしまう、もしくはネットワーク上の問題でメールが行方不明になるとか良くありますし^[8]。更に自分の場合は無駄？に独自ドメインを他にも10個以上^[9]持っており更新時期が少しづつずれているものだから余計やってしまいそうです。まあ、結構大手でも更新を忘れてある日突然Siteにアクセスできなくなったなんて事例は枚挙に暇が無いのではありますが、自分がやってしまったらそういう事例を笑えなくなるからちょっと必死です。
…え？何か違う？気にしたら負けです。

(2010-07-17追記)
　そういえば岡崎市立中央図書館事件なんていうタイムリーな一件も有ったようですね。正直『警察沙汰にするようなことじゃない』ような内容であきれ果てる限りです。同じSite管理側の視点からしても。黙って403返せば良いだけなのに、と。…という訳で、若し負荷の掛かるようなアクセスがあっても脊髄反射で警察に通報するような馬鹿な事はしませんのでご安心を^[10]。因みに先日から負荷調整の為に軽いルーチンを突っ込んであります。アクセスを重ねた上で表示されるページが空白になってしまった場合、それに引っかかった恐れがあります。その場合は時間を置けば解除されますので若しもの場合はお試しください。

1. 例えばOblivion Wiki JPは生のWikiログで約5MB、それをHTML化した場合でも多く見積もって25MB。更にこのサーバではHTMLファイルの転送にGZIP圧縮を掛けているのでたとえ25MBのHTMLでも実際の転送量はその半分くらいになる。つまりアクセスログ上の100MBの転送量は無対策であったなら200MB位は行っている可能性がある
2. “&”が”&”と表現される場合も有るのでそれも考慮するともうちょっと面倒
3. refとsrc、attachとopenfileは本来セットである
4. ***?+++というURIならば***というファイル名で保存したりする。atwiki等の一見”?”を使わないアドレスのWikiならば問題ないのですが
5. PHPで1から書いてもソースのサイズ10kbも要らないんじゃないかな
6. 添付ファイルに対応してない筈
7. Wiki自体にキャッシュ機構を組み込んで負荷低減を図っている現状
8. メールなんて確実に届く事が保証されている手段ではないですからね。昔より改善されているとは言え
9. 実際に使っているドメインはその中の4つくらい。後は塩漬け？いや良いんです、独自ドメインは早い者勝ちなのだからほしいものはある時に取らないと！”z49.org”もトップレベルドメインで短い文字列は無いかって探した結果、衝動取得しちゃった過去が有ったりします、ぢつは。
10. しかし『過失』と『故意』の区別が無い法律ってのにもびっくり…

　項目ごとにその性質を個人的な観点から3段階で分類しています。
事前対策難易度：事前に予防的に対応できるか
事後対応難易度：事後に対策が取れるか
迷惑度：利用者に対する迷惑
危険度：利用者へのSecurityの上での危険性

荒らし
　基本的に『荒らす』ことが目的な事例です。愉快犯や個人的なフラストレーションの発散を行なう者による物をここに含めます。

【迷惑度：2】
　荒らしに於いてはSiteの大事なコンテンツである記事の削除や改竄を行なう為、迷惑極まりない物です。利用者側としては当然ですが、管理者にとっても事後対応(復旧や通報)が必要になるので当然のように迷惑です。

【事前対策難易度：2】
　現在のそういう輩は基本的に技術が高いわけではないのでWeb Program(BBSやWiki)のシステムの枠組みの中でしか行動しません/出来ません。つまり、致命的な悪さをされることは無いのですが、逆にシステムの中で許容できる行動を行なっているので事前に予防する事は困難です。確かに連続投稿規制やNG Word等は可能ですが、大抵はそれが善意の利用者に不便をもたらします。よってこれを予防したいならばSite運営の方針を考えた方が効果的と思います((『Siteの質(管理運営方針、若しくはSiteの雰囲気)と利用者の質はかなり相関性がある』ものだと当方は思っています。『恨みを買わない事』『恨みを買うような不誠実な管理を行なわない事』『きめ細かな管理をしている(様に思わせる)姿勢』が低コストありながらも効果が一番高いと思います))。

【事後対応難易度：1】
　逆に事後対応は簡単です。きちんとログを取ってさえ居れば荒らしを行った者の特定は容易です。そういった人の多くは『スキル』が低い為IPの偽装も行なわず/行なえずに悪さをして自分で尻尾を出しています^[1]。あとはISPに通報するだけです。ISPの対応が不誠実な事も多いと思いますが大昔に比べればずいぶんマシになったものです。それでも効果がない場合はISPごと投稿禁止にしてしまうしかありません。そこまでダメダメなISP、若しくは骨のある荒らしに遭遇した事は有りませんが。
　荒らされた内容の復旧は大抵は比較的容易です。これは荒らしがシステムを利用した行動しかしない/出来ない事に尽きます。Web Programによってはバックアップをきちんととるものも多く、そこから巻き戻すだけで復旧できてしまいます。そうでなくとも管理者側で定期的にログをバックアップしていさえすれば復旧は困難では有りません。面倒なだけです。
　因みに、当方管理下のSiteへの荒らしは例外なくISPへの対応依頼を行なっています。厳しいかもしれませんが自身のやった事の責任を取る事は当然の事ですしそういう姿勢を見せる事は抑制力にも繋がるからです。対応依頼用のメールのテンプレートや作業手順をある程度定型化そういう輩は大抵それを知らずにやる事が多いでしょうが。

【危険度：1】
　こういった輩は上述の通り『スキル』が低いのでSecurity上の危険性は殆どないに等しいです。せいぜい、ブラウザクラッシャーやウイルスのアドレスを張る位しか出来ないでしょう。大して脅威ではありません。寧ろ、通報時に強い対応を要求できる良い理由です。

【補足】
　現在発生する物の殆どは『低スキル』な者が行なう事が多いので大した重大性は有りません。攻撃者がScript kiddie位までレベルが上がると多少厄介ですが、『DUKE』の類が流行った時代に比べればISPの対応や法制度が幾らかはマシになっているので気にするほどではないでしょう。ただ、『荒らし』の行動者は大抵人間の手作業(若しくは手作業での攻撃対象への対応)である為、後述のspamのように機械的に弾く事は困難です。人間の目で見れば明らかに不適切な物であってもProgramでは簡単に識別できないという好例です。結局、予防の為の対策よりも事後対応の方に重点が置かれてしまう事はやむをえない事でしょう^[2]。

悪意の改竄者
　これは『荒らし』とは異なり、攻撃者が利益を得る為にSite利用者に明確な害を与える物です。具体的には個人情報を奪取するウイルスをSiteに潜り込ませる等です。他人の作によるウイルスやブラウザクラッシャーのアドレスをSiteに投稿する行為はどちらかというと荒らしに含まれるのでここではふれません。

【迷惑度：3】
　盗む情報はNet上のサービスのID&Passwordやクレジットカードの情報が多いようです。それらのアカウント等を持ってない人にはなんら被害は発生しませんが、そうでない場合は極めて危険です。

【事前対策難易度：2】
　改竄の手法は2パターン有ります。1つ目は『通常の投稿に危険なMalwareのアドレスを潜ませる』で、もう一つは『ServerやWeb Program自体のセキュリティホールを利用してMalwareを埋め込む/Malwareに誘導する』ものです。
　前者の手法も多く見られます。それは恐らくMalwareのアドレスをばら撒くだけなら技術も不要故人海戦術を採用できるからなのでしょう。即ち前者は大抵は『低スキル』なので拒絶する事はかなり容易です。投稿されるMalwareのアドレスは大抵個性が有りますし、攻撃者が外国人であることはそれが即ち投稿情報に現れる事が多いからです^[3]。ただ、Malware置き場として改竄されたWeb Serviceを利用する事も多く、これは管理上の悩みの種となっております。たとえばFC2 blogですが、ここはたびたびそのような悪意の攻撃者によりMalware置き場として利用されています。FC2 blogが大手である事(しかし、管理側の対応が甘すぎる事)を逆手に取った物でしょう。当方の管理Site群ではそのドメインを含むアドレスは投稿できないようにして有ります。FC2 blogはかなりの方が利用している為、当方のSite利用者にとっては不便((参考アドレスとして紹介する等が出来ない))なのですが、Site利用者の安全を考えるとどうしても解除をする気にはなりません^[4]。
　このバリエーションとしてアップローダやWikiの添付ファイルにMalware等をUPするという事例も有ります。これはファイル自体の危険性は人間がチェックしなければ判断できないものであり、事前予防は簡単では有りません。Malware等であればサーバ側にアンチウイルスプログラムを走らせる事で対応できなくもありませんが、共用サーバでは利用できるものではありません。更にMalwareではない不正なファイルをファイル交換目的でUPする事例もあり、その場合は更に対策が厳しくなります^[5]。当Siteではファイル添付等の設定を絞る事でこれへの対策を行なっています^[6]。
　後者の『ServerやWeb Program自体のセキュリティホールを利用してMalwareを埋め込む/Malwareに誘導する』に関しては当方側ではあまり対策は出来ません。共用サーバを利用している関係上、サーバ側の脆弱性に関してはレンタルサーバ管理会社を信用するしか有りませんし、Web Programに関してはその開発サイトのアナウンスに注目し最新のものに出来るだけ早く更新する事しか出来ません。とはいえ、利用しているレンタルサーバ会社のさくらさんはそう信用に足る所だと思っていますし、多くの攻撃者は機知のセキュリティホールを狙う為、大抵は既に対策パッチやバージョン更新が行なわれているものです。よって対策はそう難しいものでは有りません。

【事後対応難易度：3】
　これは犯行者の多くが海外の者である為、ISP通報が余り意味を成しません。欧米ならまだしも中国等の場合は期待するだけ無駄です。

【危険度：3】
　当然の事ながら利用者にとっては危険きわまり有りません。

【補足】
　この類は近年とみに増加しています。良くある事例はネットゲームのアカウントを盗み、キャラやアイテムをリアルマネーで売り飛ばして利を得るという形態です。しかも犯人は大抵海外^[7]である事や、不十分な法制度^[8]の為、本質的解決は絶望的です。
　結局Site管理側では一定の対応しか取れない為、Site利用者側できちんとセキュリティ対策を行なう事が重要です。Microsoft Updateは当然の事ながら、AntiVirusプログラム、Personal Firewallの導入、各種プログラムの更新^[9]。

spam
　皆さんおなじみ？のspam。Wikiや掲示板への宣伝spamがここに含まれます。尚、用語としてのspamは大文字ではなく小文字で書く事が望ましいようです^[10]。

【迷惑度：3】
　最近ではspamへの対策が弱い掲示板やWiki・blogのコメント欄はすぐさまspamで埋め尽くされてしまいます。しかも自動プログラムによって行なわれるので人間の手での復旧作業は人間側が消耗するだけになってしまいます。

【事前対策難易度：1】
　自動プログラムが行なう物であるため、対策は容易な部類に入ります。海外のIPならば一気に範囲で規制してしまえばよいですし、NG Wordも効果が有ります。日本のものは少なく海外のものが多いので投稿内容に日本語が含まれない事も投稿拒絶条件に出来ます。また自動プログラムである関係上、攻撃側が吐く環境変数もかなり特徴的で網に掛けやすいものです。更に、大抵のプログラムはFormを解析後に『textarea』に投稿内容を入れて送信してきますので通常のブラウザからは見えないダミーの『textarea』を作成し、そこに入力があった場合はspamプログラムの投稿であると断定できたりもします。
　日本のspammerの場合は多少対策が厄介になりますが^[11]、公開Proxy規制を導入する事でISP通報が出来る可能性が高くなります。ただ、CSRFを利用したspamの場合はIP規制は意味が有りません。リファラー等を調べる事で利用されている攻撃ページを特定し、そこを管理するところに通報するのがベストでしょう。
　また、spammerはユーザーの多いProgramを良く狙います。大抵のWeb ProgramはそのURIにそれに特徴的な文字列が出るものです^[12]。その特徴的な文字列でWeb検索するだけでそのProgramを使用している場所をリストアップできちゃいます。それらは大抵デフォルトで設置されているので一度それへの自動投稿設定を作ってしまえば後は使いまわすだけで楽勝という方法があります。これへの対策も特に面倒では有りません。要は特徴的な文字列が出ないようにすればよいのです。即ちWeb Programの名前やディレクトリ名を没個性的にしてしまえば良い訳です。単純でありながらもきわめて効果的な方法である事を強調しておきます。
　攻撃側は対策が取れている場所に固執するより山ほどあるそうでないSiteにspamを打ち込む方が手っ取り早いでしょうから一定の対策をとるだけで十分でしょう。手動でspamを行う輩はそんなに大したことないのであまり考慮しなくてもOKだったりします。

【事後対応難易度：2】
　海外のものの場合は、対応が面倒であればIP範囲ごとアクセス禁止/投稿禁止にしてしまえばよいでしょう。国内であればログをまとめてISPに通報すれば大抵は対応してもらえます。
　当方の管理Siteではspamと判定した投稿は全てログを取ってあり、NG WordやNG Domainの充実、禁止IP範囲の特定に利用しています。

【危険度：1】
　セキュリティ的な問題はほぼ有りません。

【補足】
　IP規制が誤爆する事も有るのでそれへの対応はまめに行なう必要が有ります。

利用者同士の争い
　歩み寄る為の議論ではなく、ただの口喧嘩がこれです。或いはWikiでの編集合戦等がここに含まれます。

【迷惑度：3】
　空気が悪くなりますので極めて迷惑です。

【事前対策難易度：2】
　Programで対策できるものではありません。明確な対応策も殆ど有りません。数少ない事前に出来る事は『管理者の運営姿勢を明確にしておく』『Siteの空気を良くしておく事』位でしょう。

【事後対応難易度：2】
　混乱が発生した場合は出来る限り公正中立に対応する事としか書くべき事は有りません。

【危険度：1】
　セキュリティ的な問題はほぼ有りません。

【補足】
　当方は基本的に『管理人は黒子であり、利用者の環境を良好に保全するのが仕事』という方針で行動しています。ですが全くの放任という訳ではありません。常日頃で発言していますが『Wikiや掲示板は設置するだけ育っていくものではない。仮に育ったとしても大抵はそのエントロピーの増大は著しいものになる。よって或る程度の管理者の方針と管理が極めて重要』だと思っています。これもどこかで書きましたが、『Wikiや掲示板の管理は園芸みたいなもの』でしょう^[13]。
　加えて、管理者の個性も出来る限り抑え無色透明である事を是としています。個性を出すという事は利用者ウケという点で諸刃の剣であり、その匙加減はとても難しいのです。しかしながらそうでありつつも利用者と管理者の距離を出来る限りなくすような運営方針は重要だと思います。管理者の存在感が希薄すぎるのも良くない事だと思います。どこかで書きましたが、管理者は孤独です。特にWikiや掲示板の管理者はそうです。何か有ったとしても、物が分かった方々は管理者を慮って敢えて言わない、普通の方々は面倒くさいから言わない、物を知らない人は好き勝手にどうでも良い事を言う、そんな状況は良くある事です。孤独感は管理のモチベーションにも影響するものです。よってその為にも距離感をなくす事は重要だと思います。お互いに意思疎通がしやすくなればSite全体の発展にもつながります。勿論、これは上で書いた『個性を抑える』事と微妙に矛盾しますので簡単な事ではないのですけれども^[14]。

管理者の行方不明
　利用者だけではなく広い範囲に迷惑を及ぼすものです。

【迷惑度：3】
　利用者にとっては極めて迷惑です。引継ぎが成されれば良いのですが、大抵はそうではないので後継Siteが現れるまでは利用者に多大な不便を強いることになります。また、後継Siteが現れたとしても基本的にログの移行は困難なので^[15]後継管理者にも多大な苦労を強いる事になります。加えて、サーバやドメインが有効期限切れでアクセスできなくなる場合はログのサルベージが極めて困難に成ります。
　利用者以外にも害を成します。最近では管理されてないWiki/掲示板/blogはspammerの格好の餌食であり、spamによるWeb上の貴重な情報の埋没は一般のNetユーザーにも不利益を与えます。また、ただのspamなら良いのですが個人情報奪取のトロイ等のアドレスのspam行為も少なくありません。更にWeb Programのセキュリティホールの修正も成されないため有害なクラックが行われる可能性も有ります。

【事前対策難易度：2】
　簡単な様で難しいのが事前対策です。管理のモチベーションを出来る限り保てるよう工夫するのもひとつの方法です。具体的な策が取り立ててある訳ではないのは問題ですが。ただ、出来る限り自動化を導入するのはある程度有効と思います。
　当方はWikiに関してはある対策をとっています。それは一定期間管理者がログイン作業をしなかった場合、Wikiの生ログをDL出来るようにする仕組みを設置しています (例：http://wiki.oblivion.z49.org/livingcheck.php )。

【事後対応難易度：-】
　発生してからでは遅いです。

【危険度：2】
　利用者の安全を脅かす可能性は有ります。

【補足】
　Oblivion関連のWikiで2つは現在も『避難所』を付けたままです。これはこの項目で触れた事も関連します。
　それらのWikiは以前はvaglemさんという方がそれらのWiki(以降、本家と略す)を運営されていました^[16]。しかしながら気づいたらいつのまにか管理人さんの消息が不明になってしまいました。とりあえず大きな問題が無かったものの、今後に不安を感じた為後継Wikiの立ち上げを2007年の暮れに実行、受け皿を作りました。勿論面倒な仕事である事は重々承知していましたが、元々Web関連の技術には強い関心を持っていた上にコミュニティの発展を裏方として支える事が出来るというのが決断理由でした。
　簡単に『受け皿を作った』と書きましたが、結構面倒がありました。例えば本家はPukiWiki plus!を利用していましたが、当方は無印のPukiWikiを採用しました。それは元々PukiWikiの方に習熟していたということが大きいですが、派生版よりは本家のほうを使ったほうが良いという判断もありました。何らかの問題があっても自力で修正できるという目算もありましたし。ただ、このことにより一部のWiki文法互換性の問題が発生し、ログ移植の際に手間になったことがマイナス点でした^[17]。オリジナルのログの取得も手間が掛かりました。これは自前で書き捨てScriptを書いて何とかしました^[18]。
　まぁ上記のように管理側ではかなりの苦労をしました。年末年始の休みを大いに潰して格闘したので初詣に行かなかった記憶があります…。
　現在でも『避難所』の文字を外すことは考えていません。本家は現在はまっさらになっておいますが、未だに検索では本家が引っかかる事がまずひとつの原因です。

Google：http://www.google.co.jp/search?hl=ja&source=hp&q=oblivion+wiki
Yahoo!：http://search.yahoo.co.jp/search?p=oblivion+wiki
Bing：http://www.bing.com/search?q=oblivion+wiki

このような状況では『避難所』の文字列を外すと混乱の元になるのは明らかです。また、本家の管理人のvaglemさんの意思表示が全く無い事も理由です。現在も本家のドメインおよびWikiが稼動している事^[19]よりvaglemさんが生存している事はほぼ明らかなのですが。

　なんにせよ、この辺の事情と経緯は他山の石として自身への戒めとしています。

最後に
　コミュニティの発展をSite管理者として参加できる機会を頂いた事はとても幸運なことであり、有り難い事だと思います。全ての利用者の方に深く感謝致します。その為にも今回の記事に取り上げたようなトラブル対策に関しては出来る限りの事前/事後の対策を行っていく所存です。

　ここまで読んで頂いた方へのサービス？として、保管している2chの過去ログを一括でDLできるアドレスをお教えいたします。例えばこんな感じです。

　oblivion.z49.org/logs/html-logs-ob.tar.bz2

falloutその他も同じように配置してあります。falloutならhtml-logs-fallout.tar.bz2と成っています。また、他のログ置き場も識別文字列をgameもしくはpcに置き換えるとDLできます。興味がおありでしたらお試しあれ。

　こんな風にログの公開を始めようと思ったのは、検索用INDEXや保管ログの一括更新システムを作ったついで…だったりします(こんな感じ)。同じくこの副産物としてOblivionの日本語化Wikiと翻訳所のアクセスログの更新も同時にアップデートできるようになりました。

1. IP偽装といっても公開Proxy規制で弾ける程度の事しか出来ない。若しくはTrackingを回避するほどの術や知識を持たない
2. だからこそ逆に『Siteの空気の改善』は重要である
3. 具体的に言えばIPその他の環境変数
4. FC2に於いては改竄後の管理側の対応や情報公開が極めて不十分であると感じた為、解除は不適と判断。改竄の再発もそれを後押しする
5. 国際的テロ団体が日本のアップローダでファイルをやり取りしていた事例がある
6. 特にWikiへのファイル添付。ファイルサイズ制限に加え簡易フォーマットチェックを行い画像しか添付できないようにしている
7. 特に中国
8. アカウントはアカウント所有者ではなくアカウント発行側の財産であるという扱いなので、アカウントが盗まれたとしても被害届けが出せない。故に(えてして多く見られるが)発行側が積極的行動を行なわない体質の場合は被害者は泣き寝入りとなる事が多い
9. 特に最近はFlashやAdobe Readerの脆弱性を攻めるものが多い。巨大化しつつもセキュリティの対応が貧弱なAdobeに過去のMicrosoftの姿を見る人も多い
10. “SPAM”は商標登録された食品の名前
11. IP規制や日本語未使用による拒否が出来ない
12. 例えば一昔前に流行ったKent WebのJoyfule Noteという掲示板なら joyful.cgi という文字列がURIに出てくる
13. この点において、Site管理は討論の議長の仕事にかなり似通っていると思います
14. 当方の実践的な方法としては、必要な場合はアナウンスを欠かさないようにする事や運営情報を色々公開する事が挙げられる。Wikiに必ず運営ページを設置することやこの管理blogの運用がその一例
15. 管理者権限等がないと生の形でのログが取り出せない事が多い
16. vaglem.net上に残っているものがそれ
17. そのほか、デザイン周りもかなり仕組みが異なったので似せるのが面倒だった
18. 原理は簡単で、?cmd=list にアクセスしてページ一覧を取得、次にそれぞれのページの編集モードを呼び出し、生のWikiログを表示させ、あとはそこから正規表現で生のWikiログだけをローカルに保存するという感じ。添付ファイルも類似の手法で可能
19. 両方とも有料サービスである

ログバックアップ体制
　サーバ側で定期的にcronでScriptを回してblogで使用しているMySQLのデータとWikiのログをバックアップしています。ただ、完全に全てをバックアップすると圧縮しても100MB以上のサイズになります。そこで、毎日ではなく例えばWikiでは月1で全ログ^[1]をバックアップ、週1で重要ログ^[2]をバックアップという工夫を行ないました^[3]。この工夫自体はcronで走らせるScriptに組み込みました(理由は後述)。まぁ、サーバ容量は150GBも有るので実際はあまり気にしなくても良いのですが節約の精神は大事でしょう。
　また、全てのバックアップを同時に行なうのはサーバにとって宜しくありません^[4]。ならばバックアップ対象のWiki&blog毎に時間帯を変えて分散化すれば良いとなりますがここで問題があり、利用しているプランでは設定できるcronのjob数は5つまでなのです。そこでcronで走らせるScriptに時間判定を行なう工夫も突っ込みました(これが上で省略した理由の内容)。cron job自体はバックアップを行なう時間帯に1時間おきで走らせ、その時々で行なう処理を決めるという方法です。

上記二つをあわせて当初はこんな感じに記述しました^[5]。

#!/bin/sh

# ---------- Setting
WWW_BASEDIR=/home/ACCOUNT_ID/www
PATH_WIKI_BACKUP_BASEDIR=/home/ACCOUNT_ID/Backup/PukiWiki

BACKUP_ALL_TARGET="attach/ backup/ counter/ wiki/"
BACKUP_NORMAL_TARGET="backup/ wiki/"

# ---------- 日時取得
DATE=`date +%F-%H%M%S`
DAY=`date +%d`
HOUR=`date +%H`

# ---------- FLAG初期値
BACKUP_FLAG_WIKI01=OFF
BACKUP_FLAG_WIKI02=OFF

# ---------- 実行
# ----- FLAG決定
# 月2回バックアップ：毎月1日には完全Backup、15日には通常バックアップ
# YYYY-MM-01
if [ ${DAY} = 01 ]
    then
    # Target dir
    PARAM=${BACKUP_ALL_TARGET}
    MODE=ALL

    # AM 04
    if [ ${HOUR} = 04 ]
        then
        BACKUP_FLAG_WIKI01=ON
    # AM 05
    elif [ ${HOUR} = 05 ]
        then
        BACKUP_FLAG_WIKI02=ON
    fi

# YYYY-MM-15
elif [ ${DAY} = 15 ]
    then
    # Target dir
    PARAM=${BACKUP_NORMAL_TARGET}
    MODE=NORMAL

    # AM 04
    if [ ${HOUR} = 04 ]
        then
        BACKUP_FLAG_WIKI01=ON
    # AM 05
    elif [ ${HOUR} = 05 ]
        then
        BACKUP_FLAG_WIKI02=ON
    fi
fi

# ----- Backup
# Wiki01
if [ ${BACKUP_FLAG_WIKI01} = ON ]
    then
    PATH_CD_DIR=${WWW_BASEDIR}/Wiki01_dir
    PATH_ARCHFILE=${PATH_WIKI_BACKUP_BASEDIR}/[${DATE}][${MODE}]wiki01.tar.bz2

    cd ${PATH_CD_DIR}
    tar jcf ${PATH_ARCHFILE} ${PARAM}
fi

# Wiki02
if [ ${BACKUP_FLAG_WIKI02} = ON ]
    then
    PATH_CD_DIR=${WWW_BASEDIR}/Wiki02_dir
    PATH_ARCHFILE=${PATH_WIKI_BACKUP_BASEDIR}/[${DATE}][${MODE}]wiki01.tar.bz2

    cd ${PATH_CD_DIR}
    tar jcf ${PATH_ARCHFILE} ${PARAM}
fi

　ご覧の通りシェルスクリプトを利用しています。ここで注意する事があり、さくらはFreeBSDで動いているのでtarで作成される書庫がちょっと違う事です。一応統合アーカイバプロジェクトのTAR32.DLLでも処理できますが、見慣れない”PaxHeader”というディレクトリ^[6]が出てきたりディレクトリ構造がおかしくなったりします^[7]。これはTARが”–format=pax”のオプションで動いているせいっぽいです。現在のところは困ってませんし、必要になったとしてもサーバ上で展開すれば良いのでなんら気にする必要は有りませんが、気になる場合は上のコードの圧縮処理部分をちょっと書き換えれば良いと思います^[8]。

2010-07-04追記)
　最新のTAR32.DLL(v2.34)に更新しましたらば”POSIX形式のTAR書庫に対応”という更新情報がありました。そこで上述のアーカイブに試してみた所、上手く展開できずディレクトリ構造が壊れる問題は解決しました。サブディレクトリ内に”PaxHeader”というフォルダも出てきてしまう事例は観察されますけどそれ以外の問題はないようです。

tar jc --format=gnu -f 出力アーカイブ名 アーカイブ対象

　一応上のコードでも期待通りの動作をするのですが、なにせシェルスクリプトは記述法の自由度が高い訳ではないので保守性に乏しいという欠点が挙げられます。上の例でも、動作する時間帯や対象Wikiが増える度にコードを追記していく必要があり面倒です。そこで手っ取り早い解法としてPHPでリライトする事にしました。

<?php
// ---------- Setting
$LGBCK['PATH_WIKI_BACKUP_BASEDIR'] = '/home/ACCOUNT_ID/Backup/PukiWiki';

// 各Wikiのサーバ内Path
$LGBCK['TARGET_WIKI_DIR']['WIKI01']   = '/home/ACCOUNT_ID/www/Wiki01_dir';
$LGBCK['TARGET_WIKI_DIR']['WIKI02']   = '/home/ACCOUNT_ID/www/Wiki02_dir';

// Backup対象
$LGBCK['BACKUP_TARGET']['ALL']        = 'attach/ backup/ counter/ wiki/';
$LGBCK['BACKUP_TARGET']['NORMAL']     = 'backup/ wiki/';

// "DD-HH"で設定。設定値頭に#が有る場合は全Backup(ALL)。それ以外は最小Backup(NORMAL)
$LGBCK['EXEC_DAY']['WIKI01']       = array('#01-04', '11-04', '21-04', );
$LGBCK['EXEC_DAY']['WIKI02']       = array('#01-05', '09-05', '17-05', '25-05', );

// ---------- 日時取得
date_default_timezone_set("Asia/Tokyo");
$date0 = date('Y-m-d-His');
$date1 = date('d-H');

// ---------- Backup実行
while (list($key1, $array) = each($LGBCK['EXEC_DAY'])) {

    $mode_flag = 'NORMAL';

    while (list($key2, $exec_date) = each($array)) {

        if (substr($exec_date, 0, 1) == '#') {
            $mode_flag = 'ALL';
            $exec_date = str_replace('#', '', $exec_date);
        }

        // Backup時間ではない
        if ($date1 != $exec_date) {
            continue;

        // Backup時間
        } else {
            $param       = $LGBCK['BACKUP_TARGET'][$mode_flag];
            $arc_path    = $LGBCK['PATH_WIKI_BACKUP_BASEDIR'] . '/' . "[$date0][$mode_flag]$key1.tar.bz2";

            chdir($LGBCK['TARGET_WIKI_DIR'][$key1]);
            $cmd = "tar jcf $arc_path $param";
            exec("$cmd");
        }
    }
}

?>

　これならばバックアップ時間の変更や対象Wikiの増加が発生しても設定を変えるだけでOKなので極めて楽です。ただし気になる問題も有り、それはPHPを利用する事で発生するオーバーヘッドです。場合によってはバックアッププロセスを叩き落されるかもしれません^[9]。しかしながら、メンテナンス性とても魅力なのでとりあえずやってみて上手く行くなら後者のPHPを利用した方法に乗り換えようかとは思っています。

　ところで、バックアップファイルはSiteと同一サーバ内に作成しています。これは多少不安要因に成ります。例えば、サーバのデータが完全に吹っ飛ぶという事態になったらどうしようも有りません^[10]。以前は定期的にローカルに保存していたのですが、現在は常時そんな事は出来ない状況です。バックアップファイルサイズも小さくは有りません。更に、サーバとの接続をftpで行なうには危険過ぎます(特に信用できない環境で行なう場合)。そこでscpやsftpを使うべきなのですが、自動化^[11]を行なうに良いツールが今の所見当たりません。一応今まで自動化処理で多用していたlftpにもsftpが利用できるらしいので今後検討するべきかもしれませんが、バックアップファイルのDL自動化に限るならば、無駄に苦労するよりはhttpからアクセス出来る場所に置いてwgetという手の方が楽かもしれません^[12]。別解として、別にバックアップデータ置き場にもう一つ別のサーバを借りてcronで定期的にバックアップファイルを引っ張ってくるという案も有ります^[13]。この方が楽なので良いのですが、バックアップファイルのサイズがどうしても大きくなる事を踏まえるとそれなりのサーバスペースを利用できるサービスが要求されます。よって非現実的でしょう。そういう訳で、バックアップの自動化が一番現実的かと思います。

ログ保存階層の整理
　管理下のSite群のScript等で作成されるログを出来る限り管理しやすいように整理統合を行ないました。それがどうしたって方も多いでしょうが、管理側から言えばとても重要です。ある程度の規模のSiteを管理されている方には分かりやすいと思いますが、複数のScriptを使用した場合、ログファイルがこれまた複数発生します。勿論Script毎に保存される場所が異なります。これを定期的にバックアップするのは正直面倒です。サーバ内のパスをあっちこっち行ったり来たりしてその間に大事な物を忘れるとか十分に有り得ます。lftpを使用する等して自動化を図るという手も有りますが、サーバ側でログの置き場をまとめちゃうのが一番です。という訳で今まではこんな感じの構成にしていました。現在のログディレクトリ構成はこうなっています。

/Log_Dir/oblivion.z49.org/ログファイルA
/Log_Dir/oblivion.z49.org/ログファイルB
/Log_Dir/oblivion.z49.org/ログファイルC
/Log_Dir/oblivion.z49.org/ログファイルD
/Log_Dir/fallout3.z49.org/ログファイルA
/Log_Dir/fallout3.z49.org/ログファイルB

ご覧の通り、Site毎にログ保存階層を作って全部突っ込むという方法です。これならば手動だとしてもSiteの数だけバックアップを行なえば良いのでかなり楽になります。Script設置時にその設定をきちんと変えなければいけませんが、後で楽が出来る事を考えたら大した苦労じゃ有りません。

　ところが、これでも不便を感じるようになってきました。その原因は、月毎に作成されるようなログファイルが複数有るのでそれを含めたバックアップがとても煩雑になってしまうという事です^[14]。よってこれの改善も図りました。

　改善の方法は単純で、cron jobで使わなくなった旧ログを定期的に保存用ディレクトリに移動させるという方法です。管理側はその保存用ディレクトリだけDLしてくればOKというとてもお手軽な感じになります。ただ、この移動処理を行なうScriptが作業をしやすいように以下のようにログディレクトリの構成を変えました。

/Log_Dir/スクリプトA/oblivion.z49.org.ログファイル
/Log_Dir/スクリプトA/fallout3.z49.org.ログファイル
/Log_Dir/スクリプトB/oblivion.z49.org.ログファイル
/Log_Dir/スクリプトB/fallout3.z49.org.ログファイル
/Log_Dir/スクリプトB/game.z49.org.ログファイル
/Log_Dir/スクリプトC/oblivion.z49.org.ログファイル

ログファイル名に利用しているSiteのドメインを識別用文字列として入れました。そして保存用ディレクトリはこんな感じです。

/Backup_Dir/201001/スクリプトA/oblivion.z49.org.ログファイル
/Backup_Dir/201001/スクリプトA/fallout3.z49.org.ログファイル
/Backup_Dir/201001/スクリプトB/oblivion.z49.org.ログファイル
/Backup_Dir/201001/スクリプトB/fallout3.z49.org.ログファイル
/Backup_Dir/201001/スクリプトB/game.z49.org.ログファイル
/Backup_Dir/201001/スクリプトC/oblivion.z49.org.ログファイル

　ログの日付(月毎)で仕分けを行なうようにしたのでローカルへのバックアップは1回の作業で済む様になりました。バンザイ。また、月毎に仕分けされる為、もう保存しておく必要のない物も明確になるので削除も容易でサーバ内の整理整頓にも繋がります^[15]。ここまで整理すればlftpを使ったような自動化処理もとても楽になります。

Wikiの自動Namazu化
　これは現在停滞しています。当初は深夜にcronでmknmzを一回走らせて自動的にINDEXを更新するようにしようと考えていました^[16]。そこでサーバに既にインストールされているNamazuを利用しようと思ったのですが、なんとkakasi^[17]が入っていませんでした(代わりにMeCabが入っている)。kakasiベースで既にINDEXを構築しているのでここでMeCabに変更するのは手間と時間が必要です^[18]。しょうがないのでNamazuとkakasiを自前でインストールです。ここまでは上手く行きましたし、Namazuとkakasiの連携も取れているようでした。で、あとはサーバにPukiWiki用のフィルタをアップしてmknmzrcでちょいちょいと指定してやれば…と思ったのですが話はそう上手くいきませんでした。INDEX作成自体は始まるのですが、すぐにそれが終了してしまいます。これは恐らくサーバ側の制限で叩き落されているのだろうと推測しました^[19]。ならばそれを回避できるText::Kakasiを導入するしかないと思い試行錯誤したんですがこれが上手く行きません。多分些細なミスが原因だと思うのですが。
　…という訳でWikiの自動Namazu化はしばし保留です。

VirtualPC & VirtualBox
　以前はVirtualPCを利用していましたが、結局使い慣れたVirtualBoxに戻しました。確かにVirtualPCはD&Dも出来て便利です。ですがLinuxをゲストとしては利用しにくい問題がありました。更に一般には多く使われているWindows XP homeはホストPCとしては対象外になっている事があげられます。特に後者のせいか一番の目玉のD&Dが出来ませんでした。VirtualBoxでのホストとゲストのファイルのやり取りはゲスト側に”Guest Additions for Windows”を導入する事で実現できますので多少面倒ですが致命的な程ではありませんし。
　尚、VirtualBoxはVirtualPCで利用したディスクイメージも利用できるので戻すのは簡単でしたが今後の事も考えてNHCでVDMK形式に変換しました。この時、VirtualPCで”バーチャル マシン追加機能”を使用していた場合はそれを削除しておかないとVirtualBoxではゲストOSが立ち上がらない現象が観察されました。当たり前かもしれませんが。

spamホイホイ
　Internetにはspamメールを送信するためにE-Mailアドレスを収集するCrawlerが跳梁跋扈しています。そこで、当方が管理するサイトにはそういうCrawlerのアクセスを捕捉する工夫をして有ります。具体的に言いますと、アクセスログを取れるページを一つ作り、そこへ管理下のサイトからリンクを張ります。このリンクの張り方が味噌で通常のブラウザでは見えないようにします^[20]。これでソースを解釈する事でリンクをたどるCrawlerのみがそのページに来るようになる訳です。でもってそのアクセス解析ページにダミーのメールアドレスを記載して置き、そのダミーアドレスにspamが来たらそのアクセスはE-Mail収集Crawlerであると断定できるというわけです。ダミーアドレスはそのページへアクセス時間から自動的に作成しており^[21]、メールアドレスの文字列を見る事でどのアクセスか特定できるようにしています^[22]。これでどのアクセスがそういうCrawlerか断定できたらおもむろにそのIPをアクセス禁止すればいいという流れです。
　で、ここ最近そのダミーアドレスに同一人物からと思われるspamが舞い込んで来るようになったので保存していたログを調べてみる事にしました。

1) 200811022303
Date        : 2008/11/02 23:03
REMOTE_ADDR : 89.161.75.190 (PL)
REMOTE_HOST : 75-190.89-161.tel.tkb.net.pl
USER_AGENT       : Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
REFERER          :
CONNECTION       : close
ACCEPT_LANGUAGE  : en
ACCEPT_ENCODING  :
ACCEPT_CHARSET   :
ACCEPT           : */*
備考             : mailtoタグのアドレスを拾われる

2) 200812211256
Date        : 2008/12/21 12:56
REMOTE_ADDR : 118.127.214.76 (KR)
REMOTE_HOST :
USER_AGENT       : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
REFERER          :
CONNECTION       : close
ACCEPT_LANGUAGE  : en
ACCEPT_ENCODING  :
ACCEPT_CHARSET   :
ACCEPT           : */*
備考             : mailtoタグのアドレスを拾われる

3) 200904122359
Date        : 2009/04/12 23:59
REMOTE_ADDR : 88.189.244.202 (FR)
REMOTE_HOST : bot35-1-88-189-244-202.fbx.proxad.net
USER_AGENT       : Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
REFERER          :
CONNECTION       : close
ACCEPT_LANGUAGE  : en
ACCEPT_ENCODING  :
ACCEPT_CHARSET   :
ACCEPT           : */*
備考             : mailtoタグのアドレスとべたで書いたアドレスを拾われる

　赤字で強調しましたが、該当するアクセスは2008/2009頃の物という結構古い物でした。これは長期的にCrawlerを走らせていたのか、それともようやくその収集アドレスを買ってspamする奴が出てきたのかなのかもしれません。昔のE-Mailアドレス収集Crawlerは分かりやすいUSER_AGENT文字列の物が多かったのですが、これらはそうではありません。事前に対策するのは難しそうです。IPに関してはProxyの可能性も有りますが面倒ですし一括でアクセス禁止でよいでしょう。

　ところで、上で言及したように全て同一人物による送信と見ています^[23]。そこでそのspamのメールヘッダも見てみました(“******”は伏字)。

Return-Path: 
Delivered-To: ******
Received: (qmail 90391 invoked from network); 12 May 2010 07:50:56 +0900
Received: from unknown (HELO mgw5.zenno.net) (192.168.0.150)
  by mail7.zenno.net with SMTP; 12 May 2010 07:50:56 +0900
Received: from s104.xrea.com (s104.xrea.com [220.151.238.229])
	by mgw5.zenno.net (Postfix) with SMTP id B99FD2401B1
	for <******>; Wed, 12 May 2010 07:50:55 +0900 (JST)
Received: (qmail 12933 invoked by uid 89); 12 May 2010 07:50:54 +0900
Delivered-To: ******
Received: (qmail 12925 invoked by uid 89); 12 May 2010 07:50:53 +0900
Received: from 91-64-245-209-dynip.superkabel.de (HELO qskxq.superkabel.de) (91.64.245.209)
  by 192.168.1.96 with SMTP; 12 May 2010 07:50:53 +0900
Received-SPF: none (192.168.1.96: domain at bullelesite.com does not designate permitted sender hosts)
MIME-Version: 1.0
Content-Type: multipart/related;
 boundary="-59de248419ce705d5dcdb2ec33d7c8eb"
From: Gasior Yorks 
List-Unsubscribe: 
List-post: 
List-Subscribe: 
List-id: Were already several succes
Message-ID: 
Date: Wed, 12 May 2010 00:51:00 +0200
Subject: Ere to accept, in 1861, the alternative of war rather than dissolution. The course of Do
To: Gouras Bashi <******>
X-EdMax-Attachment-File: 20100519_155048_pfwh2o\Attach$.html,
                         20100519_155048_pfwh2o\angelical.bmp,
X-EdMax-Status: 0

xreaのcatch all機能を使って無限アドレス^[24]を実装しています。手持ちの他のxrea経由のメールのヘッダを踏まえると上の青字の部分も信用できる行です^[25]。意味は『”192.168.1.96″というサーバが”qskxq.superkabel.de”と自称する”91.64.245.209 (91-64-245-209-dynip.superkabel.de)”からメールを受け取ったよ』という感じです。ここで192.168.1.96はローカルアドレスとされる物ですが、恐らくxrea内のサーバではないかと推測されます。つまりspam送信元は”91.64.245.209″と分かります。ところが他のspamも見ますと、それ以外のIP/HOSTも多いです。よってBotnet等の利用が考えられます。また、HOST名に”dynamic”や”dynip”という文字列も多く見られることより^[26]、その推測を補強しそうです。
　加えて、メールヘッダ内にメールマガジンの購読停止で良く有りそうな文字列”“が有ります。これはspamの停止が出来るのではなく、購読停止手続きとして誤解した人がそこに返信する事で『生きているメールアドレス』である事を判別する物かと思います。ただ、全てのspamでそのアドレスのドメイン名が違ったので気休めのダミーかもしれません^[27]。

.htaccess管理
　先日さくらから『コメントは行頭開始じゃ、ごるぁ』と怒られたのをきっかけに.htaccessの更新を自動化するものも作ってみました。基本は元々適当に作っていた、各サイト用の.htaccessのテンプレートを作っておきそれを元に更新Scriptがアクセスコントロール情報を記入した新しい.htaccessを作るといった仕組みを書き直して拡張しました。キモは特にアクセス禁止＆禁止除外IP付近です。さくらに言われた時に思い付いたのですが、チェックすべきIPをきちんとデータベース化してそちらで管理すれば.htaccessにコメントを書きまくる必要は全然無いじゃないか、と。そのDBに規制/解除の日時や理由等を情報として入れておけば調べるのも.htaccessで利用するにも容易じゃないか、とも。
　そうやってKIANで書き直したScriptですがかなりの省力化に繋がりました。追加しようとするIPから既出のものをはじき出したり、そのIPの所属するCIDRや所属国^[28]を出力したりと便利便利です。何で今までやらなかったんだろうと思うくらい^[29]。
　『手を抜くためには努力を惜しまない』、ヤッパリ大事な事ですね。

メインPCのCPUを換装
　ここからは完全に雑談です。
　今までAthlon 64 X2 5600+ (Windsor)を利用していたのですが、Phenom II X4 965 (C3)に換装してみました。何でThubanやZosmaじゃ無いのって話も有りますが、別に6コアなCPUを生かせるアプリを使ってもいませんし。
　Oblivionへの効果は…やはり良く言われている様にあんまり差が有りませんでした。それよりも日常的に行なう作業への効果の方が重要という事で、管理SiteのサーバのApache logの統合&分割処理^[30]を換装前と後で実行し、比較してみました。

[実際の処理]
1) 日毎に作成されているapache logを展開 (例：access_log_20100201.gz -> access_log_20100201)
2) 対象月のapache logを統合  (例：access_log_20100201 ～ access_log_20100228 -> access_log_201002.log)
3) 統合ログをドメイン毎に切り分け (例：access_log_201002.log -> z49.org.201002.log, oblivion.z49.org.201002.log ...)
4) 切り分けたログをgzip圧縮 (例：*.201002.log -> *.201002.log.gz)

実際の結果です。ついでにアンチウイルスソフト(Avira AntiVir)の常駐機能のON/OFFも比較してみました^[31]。因みに処理対象のログは1ヶ月分、圧縮状態での合計サイズ約200MBです。

[分割処理]
・PHP Scriptを使用 (PHP 5.2.9 (cgi), Cygwinでコンパイル)
・GIGABYTE MA790GP-UD4H
・DDR2 2GB*2 (但しOSからは3.25GBの認識)

[Athlon64 X2 5600+ (AntiVir Guard ON)]
　1) 展開         78s
　2) 統合        258s
　3) 分割      4,157s
　4) 圧縮        335s
　   Total     4,828s

[PhenomII X4 965 (AntiVir Guard ON)]
　1) 展開         35s
　2) 統合         74s
　3) 分割      2,186s
　4) 圧縮        197s
　   Total     2,492s

[PhenomII X4 965 (AntiVir Guard OFF)]
　1) 展開         43s
　2) 統合         80s
　3) 分割      1,899s
　4) 圧縮        188s
　   Total     2,204s

　利用しているPHPはマルチコアを上手く利用できる訳ではない筈なのでほぼコア対決になっていますが、Phenomでは処理時間が半分近くまで短縮しています。PhenomでのAntiVir Guard ON/OFFの結果が腑に落ちませんが色々な細かい理由でもあるのでしょう。ともあれ、細かい理屈なぞ抜きにしても当方にとってはIYH!の意味は十二分に有りました。懸念はこの夏をどれだけ受け流せるか、位でしょう。一応それなりの対策はして有るので乗り越える分には無問題でしょうけど。

HDD換装
　メインPCの起動ドライブが不調に陥りましたので換装しました。今まではST3500320AS (500GB, 7200.11)だったのですが倍の容量のST31000528AS (1TB, 7200.12)になりました。起動ドライブにはOSとアプリしか入れてないのでそんなに大容量はいらないのですが、かといってSSDやRaptorを導入する程速度に飢えている訳でもないので無難な選択にしました。SeagateならRMAも楽ですし^[32]。
　その不調とは時々唐突にOSの反応が凍ったかと思うくらい無反応になる症状です。暫く放置していると『遅延書き込みに失敗た』という内容のエラーが出ました。もしやとデバイスマネージャを覗くと転送モードがPIOに落ちてました。また、イベントログを見ると”ページング操作中にデバイス \Device\Harddisk0\D 上でエラーが検出されました。”(イベントID 51)という内容がずらずらずらと出ていました。再起動すれば転送モードは元通りになり何事も無かったかのように順調さを取り戻すのですが、そのうちまた唐突に同じような症状を発生させるのです。SMARTには何も異常は出ていませんでしたし暫くはめんどくささから騙し騙し使用していましたが、とうとうMFTをぶっ壊してくれました。幸い緊急時用にUltimateBootCDをRに焼いておいたのでその中にあるtestdiskで修復、復活できました。備え有れば何とやら。
　しかし流石にもう堪忍出来ません。おもむろにPCショップから上記の新HDDを確保して元々所有していたTrue Image 2009で移植を行ないました。面倒くさがりなので新HDDはUSBアダプタで接続、Windows上からTrue Imageを起動して移植を図りました。True Imageデフォルトの移植プランではHDDが倍になっているので各パーティションも素直に倍にするようになっていましたが自分なりのレイアウトに調整してみました。設定後、実行させてみたらやはりWindows上では完結できず、再起動後にOS起動前にTrue Imageが立ち上がり移植作業を行なっていました。ソフト側のチップセット等への対応が出来ているのかちょっと心配でしたが問題なく認識・進行しました^[33]。ところが、何かTrue Imageさん、凄い面倒くさい事してます。まず、新HDDを旧HDDの割合でパーティションを設定・ファイル移動、その後パーティションのサイズを調整といった感じに動きました。最初から設定どおりに切ればいいじゃん！と思いつつものんびり眺めていました。しかしここでまたびっくり、終わったはずなのにまた最初から同じ事を繰り返しています。なんでー。結局その作業セットを10回くらい繰り返していたようです(途中から放置)。もしかすると、Windows上のTrue Image上であれやこれやと新HDDのパーティション設計を色々こねくり回していたその過程を全て再現したのかしらん、という気もしますが良く分かりません。それを確認するだけにまたやるのは面倒なので真相は不明ですが若し今度やるときは気をつけねばなぁ、と思います。そのときは新OSと新VersionのTrue Imageを使っていそうですが。

　ただ、不調に陥ったHDDの症状が当方には未経験のものだったのが多少気になります^[34]。もっとも使用時間は1,566時間(約652日)だったので元は取れたというべきでしょうか。それに、とりあえずは普通に動くのでデータを消去する事も可能ですし、もう1基死亡しているHDD^[35]が有るので一緒にRMA送りするのに丁度良かったです^[36]。そもそも今回いかれたHDD(7200.11)はFirmwareバグによるロック問題が発生した物なので厄介払いをするには丁度良い機会だったのかもしれません。…まぁ大抵は同じ機種で戻ってくるので期待はしていませんが^[37]。

まとめ
　管理の関係上、見えないところに大きく手を入れました。　しかし当然のように、問題が1つ有りまして。サーバ内のログディレクトリを大幅に整理した関係で(ぽんこつ属性持ちの私にはよくあることですが)Scriptがまともに動かなくなってしまっているところがあるかもしれません。その時は遠慮なく当方まで教えて頂ければ嬉しく思います。

1. attach/ backup/ counter/ wiki/
2. backup/ wiki/
3. バックアップ間隔は夫々のWikiの編集頻度を見て個別に設定
4. サーバ設定でプロセスが叩き落されバックアップが完走しない可能性も
5. 記事用に書き直した物で実際のものとは異なる
6. 書庫内のファイル情報が記述されたファイルが格納される
7. Explzh等で確認。DLL側とアプリ側のどちらが理由かはよく分からないが恐らくDLL側。7-zipが提供するアーカイバやCygwinのTARでは正常に展開できる事は確認済
8. 未検証
9. ビジネスプロプランを利用しているので考慮しなくてよいが、もしそうでなかったのなら大抵PHPはセーフモードで動作しているのでexec等がしにくいという問題もあった
10. 実はさくらさんの方でサーバ内データの定期的バックアップは行なわれているらしいが、そういうものは過信すべきではない。データが吹っ飛ぶような事態は以前使っていたxrea/CoreServerではぼちぼち発生していた様だがさくらでは殆ど無かったと思う
11. やる事多過ぎで手動でなんかいちいち面倒くさ過ぎだが手順はほぼ決まっている為自動化が適用可能
12. バックアップファイル名は基本的に不定(∵月ごと等に新生される)のでちょっと工夫が要る
13. この場合もftpは危険で、scp/sftpも使えないのでhttpがベスト
14. spam対策の投稿記録ログ等は基本的にサイズがとても大きくなるので月毎に新生している。ただ、同じ階層にばらばらっと現行ログと旧ログが混在する形になっているので旧ログだけを選びながらDLをするのはしち面倒くさい
15. テキトー管理をやっていると案外サーバ内は汚れていくんです。気の利くお掃除メイドさんでもいたらなーっ。…え？私がだらしないだけだろ、って？ノーコメントっ
16. 投稿毎に走らせるのは負荷の上で問題
17. Namazuが利用できる分かち書きプログラム
18. しかも、以前はMeCabを利用していたがどうも検索が上手く行かないのでkakasiに変更したという経緯もある
19. 1文書毎にkakasiをその度に起動させているのでプロセス数の上限に引っかかった物と思われる
20. CSS等を利用
21. 2001_05_01_230205@example.com というような感じ
22. 記述もメールタグを利用した記述法や数値参照を用いた方法等を色々用いてそのCrawlerがどの記述法のアドレスを拾うかで収集能力を探る事も行なう
23. 内容がほぼ同じなので
24. メールアドレスの@の前が何であっても受信し、特定アドレスに転送する
25. 時には偽装ヘッダを入れるspamも有るので解釈は気をつける必要がある
26. DDNS等を利用して自鯖を建てる時に割り振られるHost名にもそういうのは多いが、そうでない通常ISP利用者のHost名もそんなものになることが多い
27. ドメインも安いとはいえspamの為に何個も取るのは非効率的。ただ、そのアドレスが少なすぎる場合はメールヘッダを解釈するspamフィルタ等で簡単に対策出来てしまうのでそのバランスが難しいだろうと推測
28. GeoIPを使っても良かったがライブラリ要求とか面倒くさかったので各NIC(AFRINIC, APNIC, ARIN, LACNIC, RIPE-NCC)のIPリストをDLしてきて自前でIPのDBを作成、処理に利用している
29. 今にして思えば更新が面倒で、メンテはかなりサボってた
30. 利用プランでは同居させているSite群のApache logが全てまとめて日毎に出力される(xreaではドメイン毎に分割されて出力される)。これはログ分析上不便なので、月毎にログを統合させた後、ドメイン毎に分割するという処理をローカルで行なっている
31. NamazuのINDEXを作成する時では如実に差が出て来る
32. WDだとシンガポールに送る必要があるがSeagateなら国内でOK
33. True Imageの中身はLinuxなのでどうしても新しいチップセットに対応しない事例が出て来る
34. 『カッコンカッコン』とか『きゅいーーーん』とか『かかかかかかっ』という異音でご臨終した経験は夫々1回づつ有りますが
35. Seagate ST3300622A1, 300GB, 7200.9, PATA
36. 両方ともRMA対象期間5年の機種
37. 時々容量がもとより多い機種で返ってくる事もある模様。逆に容量同じでもプラッタ数が増える事とかもあるらしい

　脱線修正。で、今回話題にするのは過去ログの保管と過去ログ&WikiのNamazu検索インデックスの作成と更新です。これらを行うには結構な時間・スペック・回線が必要なので、ネットトップなPCをマクド等で使うなんてのは無理です。そもそもマクドなんてどこー。

　そこで、まずSite管理に必要な事柄を必要環境に応じて三つに分類しました。A(大した環境は必要でない)、B(マシンスペックが必要)、C(安定した通信環境が必要)です。

A) スレのDATを取得
A) DATのコンバート
B) HTML化したログからNamazu用のINDEXを作成する
C) コンバートしたHTMLと作成したINDEXをUPする
C) Wikiのログを取得する
B) Wiki のログからNamazu用のINDEXを作成する
C) 作成したINDEXをUPする
A) Wikiや管理blogでの対応

注)
・ NamazuのINDEX作成環境の構築は面倒
・今まで更新に使っていたlftpはWindowsではCygwin版しかない(つまりCygwin環境も場合によっては必要)

　AはぶっちゃけマクドでもOKなレベルですので省略。

　Bはなかなか面倒です。通常、スレのログは更新された部分だけINDEXを再構築するようにしていますが、そうでない場合はとんでもない時間を要求されます。たとえば、Oblivion関連のログだけで現在600弱有ります。『600？ちょろいじゃん』と思われる方はある程度正解です。普通にINDEXを構成するだけなら600程度のHTMLなんて大して時間がかかりません。ですが、です。一度でも過去ログ検索を利用された方ならお気づきでしょうが、レスごとに検索できるようになっています。これは内部的にはスレッドのレスを1つの文書とみなしてINDEXを構築しているからです^[1]。つまり1からINDEXを作り直す場合、実質600*1000=600,000の文書のINDEXを構築するのに等しくなるのです。ここまでくるとCPU速度よりもDIｓｋの読み書きで手間がかかりそうなのが見えてきます。あと、当方のデスクトップはPhenom X4 965BEなのですが、Namazuの中身はPerlなのでどうもマルチコアを上手く使えてないようなのです。これはしょうがないことでしょう。

　で、注)にも書きましたが、Namazuが動き出すように設定するには結構手間がかかります。大体は何も見なくても出来るようにはなっていますが、激しく面倒です。さらにネットカフェのPCがリブートした日には…。そういう訳で、更新環境には仮想PCを利用することになりました。これならディスクイメージと仮想PCのインストーラを持ち歩くだけでどこでも更新作業に最適化された環境を利用できます。わざわざネットカフェでPC立ち上げ後、30分位も無駄に設定作業をしなくてすむのは嬉しいことです。

　ところで、スペックの話のところで仮想PC？と疑問に思われるでしょうが、実際密接にかかわってきています。接続後、大概は更新されたデータがあります。それのためにINDEXの更新作業は必要になってきます。ところがどっこい、仮想PCはホストのPC内でシミュレートされているものなのでどうしても能力は貧弱になります。この貧弱さがINDEX更新の際には激しく障害となるのです^[2]。

　結局、激しく時間の掛かりそうな作業は持ち帰って自宅でぶん回し、次の機会に更新するというパターンになりました。

　Cもなかなか大変です。実はz49.org上のNamazu用INDEXは大体1GB位になります。これはマクドじゃむりっ^[3]。で、実際に使ってみて感じたのですが、仮想PCのネットワークは基本的に使い物にならないと思いました。普通にWebを閲覧する分には十分出来るんですが、継続的な通信を行うとちょいちょいパケットの取りこぼし？みたいなものが発生して通信が途切れてしまいます。また、速度もありません。これらは仮想PCとハードとの相性もあるのでしょうが、こんな不安定な要素を頼りにするわけにはいきません^[4]。結局、ローカルで更新ファイルを1つに固め、仮想PCではないホストのPCからサーバに送信し、サーバ上で展開することにしました。

　という感じで、一応A-Cの対応方針を決め、ちょくちょくと作業をしています。実際にやってみて上手くいかないことも結構見つかっている^[5]ので安定稼動にはしばらく掛かりそうですが、大目に見ていただければ幸いです。

追記 2010-04-18)
　結局lftpでのデータのDL&UPは非効率的と判断、wikiデータの取り出しはwiki組み込みのdumpプラグインを使用することにしました。また、それを仮想環境内で展開＆NamazuのINDEXを作成。その後に作成したINDEXをtarでアーカイブし、これをホストPCに移動、ホストPCからWinSCPでUP&サーバ上で展開して反映という流れになりました。もちろんこれらの間にあるこまごまとした処理はBATファイルやシェルスクリプトで省力化を図っています。2chのスレッドログの保管も大体似た感じです。●を所有しているので落ちたログも拾えますし。更新されたスレッドだけの更新なら仮想PC上でも十分実用になります。

　仮想PCはVirtualPC 2007(以下VPC)を利用しています。VMWareはちょっと面倒ですし、VirtualBoxはVirtualPCより動作が軽快な状況もあるのですが、VPCはドラッグアンドドロップがホストとゲスト間で出来るという気軽さが魅力でした。VirtualBoxでは共有周りを弄らざるを得ず場合によってははまりそうな気配が見えました。ネットカフェで利用する関係上、再起動したら負けですし。

　セキュリティ周りはAvira AntiVirを起動後にDLしてきてインストールするようにしました。無料で利用できる中でも検出力には定評がありますし。

1. 実際に、内部的にはレス毎にHTMLを分割してテンポラリとして書き出し、それから夫々に対して解析を行っているっぽい
2. 因みにz49.org上に保管してあるログ全てのINDEXを再構築した場合、PertualPC上では14時間、VirtualBox上では8時間掛かった
3. もちろん更新部分だけすればいいので常に1GBではないが、それでも1カテゴリで数十~数百MBは有る
4. 更新作業は自動化がとても楽に出来るlftpを愛用していたのですが、ぶちぶち通信が切れるようではやってられません。VirtualPCでもVirtualBoxでも、ネットカフェの場所を変えてもそれは同じでした。まぁ、田舎なので回線品質があまりよくないこともあるのかもしれませんが
5. たとえば、上述の仮想PCのネットワーク能力