スナップショットからインスタンスを作成する手順が変わったのでメモ
2014/11/12からログイン用認証キーを作成しなければならなくなった。
１、ログイン用認証キー作成
KAGOYA/VPSコントロールパネルからキー作成を行う。
ここでは「.key」というサフィックス（接尾語）で作成される。
詳細URL

２、インスタンス作成
インスタンス作成時の手順１の認証キーを作成していないとエラーメッセージが出ます。
従来はインスタンス作成時にrootパスワードを入力していたが、rootパスワードに代わりに認証キーを設定するようになった。
（注意）2014/11/27時点ではオンラインマニュアルがrootパスワード入力になっていたので実際の画面と差異があった。
ここでは「.key」というサフィックス（接尾語）のファイルを使う。

３、PuTTY設定
KAGOYA/VPSコントロールパネルから手順１で作成したキーを変換し、PuTTYの認証キーとして設定する。
ここで「.key」というサフィックス（接尾語）のファイルから「.ppk」というサフィックス（接尾語）のファイルに変換される。
PuTTYの設定時は変換後の「.ppk」というサフィックス（接尾語）のファイルを指定する。

PuTTYのインストールはこちらのURL

これで、PuTTYから接続するとrootのパスワードを入力せずに認証されサーバにログインできる。
混乱したので整理してみた。
（注意１）
validates()、validate
s() は別物です。
valida
teErrors()、valida tionErrors は別物です。
（注意２）
validationErrorsに値が入っているはずなのにエラーメッセージが表示されない時はスクリプトファイルの文字コードが違う場合があります。
pr()やvar_dump()で表示するとすぐに文字化けが分かります。
Model::validates()
バリデーションを実行しエラーがないときは「真：true」を返す
一つでもエラーがあるときは「疑：false」を返す
Controller::validates()
Controller::validateErrors()
バリデーションエラーのメッセージを取得する
$this->[Model名]->validationErrors
■使用例（コントローラ内記述）
【validates()】
$this->[コントローラ名]->set($this->data);
if($this->[モデル名]->validates()) {
// true:エラーがない時の処理
} else {
// false:エラーが一つでもある時の処理
【validate()】
$this->[コントローラ名]->set($this->request->data);
if($this->validate($this->[モデル名]) > 0) {
// エラーがある時の処理
// エラーがない時の処理
【validateErrors()】
$errors = $this->validateErrors($this->[モデル名]);
【validationErrors】
$this->set( ‘valerror’, $this->[Model名]->validationErrors);
「/etc/php.ini」ファイルのタイムゾーン設定を「timezone=Asiz/Tokyo」にしてもCapePHPの時間が9時間ずれる。
タイムゾーン設定だけでは駄目なようで下記命令を「beforeRender()」に追加。
■こんな感じ
public function beforeRender() {
date_default_timezone_set(‘Asia/Tokyo’);
これでLinuxのdateコマンドの結果とPHPのdate関数の結果が同じになる。
netcommondsでファイルをアップロード時に容量不足エラーが出た場合の設定変更方法。
今回はディフォルトの2Mから20MBへ変更。
【エラーメッセージ】
「ファイルが大きすぎます。200000byteまでにして下さい。」
■PHP設定ファイル変更
・変更ファイル
/etc/php.ini
・変更箇所（2M⇒20M）
upload_max_filesizeを20Mに変更
post_max_sizeを20Mに変更
■netcommonds設定ファイル変更
■apache再起動および可動確認
・再起動
/etc/init.d/httpd restart
・状態確認
/etc/init.d/httpd status
ドメイン登録情報の正確性確認なるものがあり、期限内の確認を怠ると15日でドメインが使えなくなる。
ドメインが使えない状態は「クライアントホールド」というようです。
13日目に再送のメールが来るので再確認できるのだがそもそもケアしていないと意味が無い。
最近新しく追加されたドメインが対象なので今まで問題無かったからと言って安心できません。
ちなみに、今回は「.support」ドメインで参照できなくなりトラブルました。
最近新しいドメインが増えていますが要注意です。
■「クライアントホールド」解除時の主な流れ
１、ドメイン登録
２、正確性確認のメールが届く
件名も本文も英語「Request for email address validation」なので要注意です。
さらに送信者は「noreply」なのでメールを捨てないように注意して下さい。
ちなみに、私は削除済みにもスパムメールにも存在してしない。
今回はレジストラに連絡しメールを再送してもらいました。
正直、英文の件名のメールは基本削除しているし、本文も英文なので本文中のURLは押さないですね。
（注意）
複数ドメインを登録した場合で登録メールアドレスが同一の場合はドメイン毎に確認メールは来ない。
確認メールは一通のみになります。
メール内に記述してあるドメイン名は一つのみですが同時に登録した他のドメインも心配要りません。
３、メール内のURLをクリックし承認する
メール内の下記URLを押すと承認画面に変わり作業完了です。
承認完了画面はこんな感じです。
４、約一時間で解除される
■問題切り分けで行ったこと
１、サーバ接続
SSH接続
⇒サーバは生きてる
２、apacheの確認
⇒apacheは生きてる
３、同一サーバ内アプリケーションの挙動
phpMyAdminに接続確認
⇒MySQLは生きてる
４、IPで接続
ブラウザからIP直で接続しアプリケーション動作確認
⇒アプリケーションの問題ではない
５、nslookupで確認
ドメインが見つからない
⇒問題はこれだ
しかし、DNSに関する変更はここ数週間行っていない・・・
６、DNS設定確認
⇒サーバの設定もレジストラの設定も問題ない
７、サーバ会社のDNS確認
DNSは問題ないがドメインが「クライアントホールド」状態らしい
⇒レジストラに確認必要
８、レジストラに確認
whois情報の正確性確認が必要と判明
⇒確認を行うためのメールが削除済みにも迷惑メールにも見当たらないので再送を依頼