ddコマンドで/dev/hdaを丸ごとsshでXenのサーバに転送して、
完全仮想化用の設定ファイルを修正したら、起動した。
完全仮想化用の設定ファイルは、一度CentOS5.4を完全仮想化したものをコピーして編集したのだが、uuidとMACアドレスを修正しただけで案外動いてくれる。

ハードディスクを丸ごとバックアップする方式なので、ハードディスク使用量が少なかったとしても、ハードディスク容量分の転送時間がかかる。今回のは、7GB程度しか使ってないサーバにも関わらず、元が40GBのハードディスクなので、結構時間かかった。Mondo Rescueで移動できたんならよかったのになぁ。Mondo RescueからXenへのP2Vは未だにやり方がわからんまま。7GBしか使ってないなら移動しなくてもいいんじゃないの？って思うかもしれないが、Subversionで大量のファイルを管理したいというような要望が出てきているので、40GB程度だとあっという間に使ってしまいそうだと判断してのこと。

Xen側の設定ファイルのMACアドレス設定を、元々のサーバのMACアドレスに変更しないと、NICが起動してくれない。まぁ、そりゃそうかって気がした。

完全仮想化したサーバの設定をどのように変更していったらいいかは、まだよくわかっていない。
とりあえず起動しただけでも、いちいち最初からクリーンインストールして設定していくよりも楽だから、ありがたい。タイミングをみて物理サーバを停止して仮想サーバにリプレースしないとなぁ〜。Subversion運用してるサーバだから、みんながコミットしないときに作業しないといかんというのがネックだ。来週の金曜日あたりに残業して片付けるかなぁ〜。

Railsを書けるようになるのも大事だけれど、Railsの思想とかがわかるようになると、勉強になるなぁと思いますね。考え方はいろんなところで使いまわせたりしますしね～。まだまだ進んでないけれど、頑張ってみよう！

PHPList-Form-Integration内のpholist.phpを書き換えたり、デバッグモードでcURLの内容を出力したりしたら、セッションが引き継げてないのが原因だとわかった。そのセッションが引き継げてない理由自体は全然わかってなかったのだが、他の案件が忙しくなってこの件を一旦放置していた。CakePHPの案件にも一旦目処がついたので、この件の調査を再開しようと思った矢先、閃いた。もしかしたら、モード（版）が違うのではないか？と。

モード？それはすなわち、CoreServerだとPHPはモジュール版とCGI版がある。PHPListはセーフモードだと警告メッセージが出続けるのでCGI版で動かす必要がある。そのときに、CGI版で動かす設定を/lists/admin/以下の.htaccessとphp.iniに記述していた。ところが、/lists/以下には設定してなかったので、/lists/以下はモジュール版で動いていた。

PHPList-Form-Integrationの購読フォームの動作は、

1. cURLで管理者としてログイン
2. メールアドレス確認をしない場合、管理者としてメールアドレスを登録処理する

である。
管理者ログインがCGI版でログイン、メールアドレス登録がモジュール版で処理をしようとしていたため、モジュール版とCGI版ではセッション管理が異なるためメールアドレス登録が管理者扱いではなくなり、処理できてなかったわけである。ということは、/lists/以下もCGI版にしてしまえばよい。

PHPList全体をCGI版で動かすように.htaccessとphp.ini（CoreServerの場合のやつ）を修正したら、メールアドレス確認なしで動いてくれるようになった。気付けばなんともあっけないのだが、原因がわからずに深夜まで残業してしまったりしていたので何気に悔しかった。まあでも閃いてよかったわ〜。

ちなみにメールアドレス確認なしにした理由は、ケータイから登録された場合にPHPListのメアド確認用画面がケータイからは確認できないからです（テーブルレイアウトででかい！）。

$form->create で出力されるfieldsetを消す方法

昨日の投稿にも書きましたが、SecurityComponentを使うとAUケータイではdisplay:noneになってるfieldsetタグ内のトークンがPOSTされません。よって、fieldsetタグのみを削除すれば動くに違いないということで、fieldsetタグを削除する方法です。

参考にしたサイトは以下です（英語）。
http://cakeqs.org/eng/questions/view/disable_fieldset_around_an_hidden_form_element

CakePHPユーザ会のほうに書いた方法でもいけると思いますが、何度も使いたいので自分はKtai LibraryのKtaiヘルパーにメソッドを追加しました。

/app/views/helpers/ktai.php

/**
 * Ktai helper class for CakePHP1.2
 */
class KtaiHelper extends Helper {

	var $helpers = array('Html', 'Form'); // 'Form'を追加した

	var $_lib3gk = null;

// ... 最後に以下の2つのメソッドを追加
	function form_create($model = null, $options = array()){
		$out = $this->Form->create($model, $options);
		return strip_tags($out, '<form><input>');
	}

	function form_end($options = null){
		$out = $this->Form->end($options);
		return strip_tags($out, '<form><input>');
	}
}

View側では、以下のように使います。

<?php echo $ktai->form_create($model, $options); ?>

AUケータイで試してみましたが、結果は上々でした。

データベース設計は同僚がやってくれたので（彼はDBのスペシャリスト）、俺はBakeでソースを生成し、デザイナが作ったデザインをViewに組み込み、Modelの設定を行い、Captchaコンポーネントを使った画像認証を組み込み、コントローラーに処理をゴリゴリと書き（Fat Modelになるような仕様ではないため。まぁ汎用的なメソッドはModelに作ったけど）、FireMobileSimulatorで確認しながら開発。

一通り実装が完了したので、実機（俺のAU携帯と後輩のSoftbank携帯）とDoCoMoのシミュレータで試すとやっぱり動かなかったりした。まぁそういうことを試すためだからいいんだけど。ソースを修正しては試す。これによりDoCoMoはOK。SoftbankもOK。しかし、AUだけPOSTしたら404と言われる。なぜだ！

Ktai Libraryを使ってたら、redirectのところでURLの組み立てで変になった箇所があったので（Controller::redirect()の引数に配列形式で値を渡すと壊れる。引数をis_arrayでチェックすると直った）、また似たようなことが起こってるのかなぁ～とApacheのアクセスログを見てみると、ちゃんとPOST先のURLにアクセスしている。しかし、Content-lengthが0。0とはおかしいじゃないか！

まさかと思ってCSRF対策用に使っていたSecurityコンポーネントのBlackHoleCallback関数を設定してログを出すようにしてみたら、ビンゴ。BlackHoleに吸い込まれているじゃないか。しかも、俺はここのPOSTはデータベース更新に関係していないのでCSRF対策してない（$this->Security->requireAuthに追加していない）。にもかかわらず、トークンが発行されてるのにも納得がいかない。

何がなんだかわけがわからないので、CakePHPユーザ会で検索してみたら、有力な情報を得た。

携帯のblackhole 対策

Securityコンポーネントのトークンはfieldsetタグ中に囲まれているのだが、このfieldsetタグにはdisplay:none;が設定されている。AU携帯はPOSTするときにdisplay:none;が設定されている領域の値をPOSTしないらしい。サーバ上にはトークンが設定されているにも関わらずトークンがPOSTされないから、トークン不一致でブラックホール行きという仕組みだったのか。

今思いついてる解決策は、

• Formヘルパー自体を修正する（ライブラリ自体の修正はやりたくない）
• $form->create(), $form->end()で取得したソースからfieldsetタグを正規表現で取り除く処理を実装する（若干難しそうだが一番意味がありそう）
• Securityコンポーネントを使わずに独自のCSRF対策を施す（一番現実的か？）

である。まぁ時間があれば2番目で行きたいが、3番目かな。原因が突き詰められたので、Securityコンポーネントを外してAUで試したところ、普通に動いてくれた。あ～、よかったぁ～。ひとまず安堵。

まぁセキュリティ系の課題はあるものの、処理自体は2人日で実装完了。やはりCakePHPの開発効率はかなりいいなぁと思う。簡単かつ早いかつ安心。ただ、時々超ハマる…。

【解決しました！】
次の投稿でこの問題は解決したのでリンクはっておきます。
CakePHP:【解決】AU携帯でSecurityComponent

まぁなんでこんなことを書いているのかというと、制作サイドの都合（工数がないだの、改修が大き過ぎるだの）で屁理屈をいって現在の仕様でお客様をごまかしたとしても、利用者からの反応が返ってくるのはお客様なので、その時点でお客様の不信感を買ってしまうのではないかと思うからだ。ちゃんとやってくれないと思われてしまう(必要な費用を出してくれていないという点は大いにあるのだが)。もちろんやれる技術力はあるのだが、そこはコストとの相談になるので、ごまかすのではなく、やはり松竹梅的なプランを掲示してお客様主導で決定するプロセスがないとお客様は納得しないと思う。お客様が選択した結果、利用者の反応が芳しくなければ、プランをアップグレードするという方法をとらなければ、お客様も学習できないし、我々の掲示に納得してもらえない（その時点で判断材料が少ないからまともな判断ができないパターン？）。

下請けでいつも感じるのは、マネジメント層のコスト意識が強すぎて我々の提案を屁理屈に変えてしまい(必要経費すら無駄扱い？)、お客様との折衝が長期化して、いいものができないというジレンマだ。コストを最小化しようとした結果、要求が満たせず、折衝のみでコスト増大してしまうパターン。まぁ俺は常に富豪仕様にしろって言ってるつもりではない。ただ、不特定多数の利用者のサイトの場合、正しいのは利用者であってお客様でも制作サイドでもない。
お客様自身が利用者の場合は、富豪仕様でなくても運用でカバーすることが可能だが（マニュアルを作ったり）、そうでない場合はお客様にも納得してもらった上で、我々から見たら富豪仕様でも作らなければならないと思う。損して得取れ。というか、その損は損ではなく、得をとるためのコストであるので、コストかけて得取れと言いたいわけです。それと、明らかな損は、お客様が制作サイドを貶めている（ように感じる）ので明らかにモチベーションが下がります。まぁそこはマネジメント層の腕の問題かもしれない。

ネットにおいては、Win(お客様)-Win(制作サイド)では足りない。Win(利用者)-Win(お客様)-Win(制作サイド)の関係を築けるように、お客様と制作サイドで友好関係を築く努力のためにも、仕様決定プロセスの透明性を高めるべきではないかと思う。

ここ数日でよかったことは、WSH(Windows Script Host)が使えるようになったこと。まぁリファレンス本は必要だけれど、今までは自分の実力では、コマンドプロンプトでバッチファイルを作ることでしかWindows上の作業の自動化はできないと思っていたので（コマンドライン版PHPやRubyが入ってるところだとそれらでできるけれど、プログラム言語がインストールされていることに依存するからという意味で、です）、WSHでJScriptが使えるということを知った時にはすごく嬉しかった。JScriptはWindows版JavaScriptだから、これで一気に自動化のやり方の幅が広がったというわけ。

WSHのおかげで3月からの運用案件のログ取得処理やエラーログ抽出処理をすべて自動化することに成功。手作業でやっていたらおそらく10分くらいはかかるであろう作業が、多分2分くらいで確認できるようになった。時間短縮もなによりの効果であるのだが、一番の効果はヒューマンエラー（ログダウンロードし忘れ、エラーの見落とし）が発生しにくくなることである。こういうことをできるようになるとコンピュータを使えてる感じがして楽しいし、役に立ってる実感が湧いて嬉しい。

ここのところ家でのWebアプリ開発から遠のいているので、すこしずつ環境整備してストレスをコントロールしながら楽しく生きていきたい。

ということで、このプラグインの機能を参考にしつつ、今作成中のプラグインを実戦で使えるレベルにまで昇華していこうと思えた。まだまだ使えね～…。データベースの設計からちょっと見直さないといかんので、クエリ書き換えんといかんのが面倒。あー、ActiveRecordだったら簡単なのにな～とすげー思う。

というか簡単なのだったら抽象クラス作っちゃえばいいのか…。

で、そのバウンスメールをカウントして、どうも宛先がなさそうだったり、メールサーバがなさそうだったり、放置されているメールアドレスみたいだったら、データベースから対象メールアドレスを削除して無駄なメール送信をなくそう！ということみたいだ。考えられているねぇ〜。

メルマガシステムを扱ったことなかったから、参考になった。