今回はCORESERVER からブルーホストへの引越しを行う。
スポンサードリンク
その前に
ディレクトリとサブドメイン
何故行うかというと、負荷がかかった場合いい点が容易にできるよう、サブドメインで分けてしまうクセがついてしまったということがある。サブドメインが簡単にいくつも作成できることが原因だ。
逆に、サブドメインを作るとサーバーをあと１つ契約したのと同じ状態になるホスティング業者もある。こちらは高価だが、とても安定性に定評のある業者。どれくらい高価かといえばCORESERVERやさくらインターネットの１０倍くらい。
だから最近では安定性を求める場合、さくらインターネットを利用する。理由はこちら。簡単に言うなら、CORESERVER はサーバーやDNS の自由度が高く、いろいろなことに挑戦できる利点がある。一方さくらインターネットは厳格なリソース制限によって強者が「幅」をきかせたとしても影響を受けにくいが、当然自分もリソース制限を受ける。
リソース制限
共通するのはどちらも完全に明確ではないリソース管理が行われていて、突発的な負荷がかかるのではないかと夜も眠れない。実際、先日さくらインターネットの自動負荷レポートでCPU時間が５時間を超えていた。こういう時はGoogleクローラが原因なのがほとんど。早速Googleクローラにそんなに来ないでねと手続きをて事無きを得た。突発的なアクセスなら突然アカウントが停止されるような自体にはなりにくいとは思うが、訪問者に対して５０３エラーが頻発するからよろしくない。
検索エンジン
ところで、その高価なホスティング業者の良いところもある。それは半強制的にサブドメインが取得できなわけだが、そのおかげでメインとなるドメイン名でのコンテンツ量や運用方針が検索エンジンには気に入ってもらえるようだった。あちこち手前勝手な事情でサブドメインというカタチで分散しているサイトと比較すると評価が良いようだった。
しかし最も重要なのは、メインとなるサイトにコンテンツが空っぽになりつつあって単なるインデックスページのようにも見える。おそらくそれが検索エンジンには好まれなかった理由じゃないだろうか。そのへん詳しい人なら笑ってしまうような内容を書いているのだろうが。
ということで、本来サブディレクトリで分けたかったシステムを将来の何かを言い訳にしてサブドメインでわけていたのだが、それを統合することにした。
今回の作業の目的
今回の作業の目的としては次のようになる：
- サブドメインで分けていた、サブディレクトリで分けるものを本来の状態に戻す。もし負荷が増えたら.htaccess でサブドメインに転送する方が良いと思ったから（VPS や高度な設定が可能ならリバースプロキシを使えばよい）。もし、ネームサーバーを変更するようなことがあっても、エントリー数による制限を受けにくくなる。
- ”度を超えた”リソースの心配をして、本来すべきコンテンツ管理がおろそかになっている状態から抜け出す。
これまで行なってきた引越し作業
参考として、これまで行なってきた引越し作業
移行した際の注意点やハマったところなど
PHP
日本国内のレンタルサーバーの多くがセーフモードで動作しているが、海外レンタルサーバーではほとんど見かけない。そのため、CORESERVER のようにPHP をCGI として実行するように.htaccess などで設定している場合は解除する。
CGI
CGI は最近放置しっぱなしだったので、すっかりハマってしまった。複合的要素があったから余計だ。
あまりにも面倒になって諦めようかとした時、シンプルなテストコード（参考文献参照）をサイトトップに置いて動作したから、「動作する」「Script Alias の問題ではない」など幾つかのことがわかり、１つずつ問題を解決することで事無きを得た。
path
path は /usr/bin/perl だった。
ファイルとディレクトリのパーミッション
PHP に慣れるとCGI で苦戦した懐かしいパーミッション設定を忘れがち。サーバーによっては700 で動作することもあれば755 の時もある。また、777 ではエラーとなる場合もある。Bluehost は755 で良いらしかった。
ハマったのはディレクトリのパーミッション。うっかりしていたが、これも適切に設定しなければ動作しない。
改行コード
海外レンタルサーバーへのファイル転送は遅い。それからBluehost はタイムスタンプを無視するらしい。この２点から、CORESERVER 上のデータを一度ローカルに持ってきて、zip にしてscp で転送、展開した。（CORESERVER 上で固めなかったのはKill されるから）。この時、改行コードが正しく復元できなかったらしく、一部のCGI を含むテキストファイルに問題が出た。
.htaccess
PHP 関連の設定が行われている場合はコメントアウトしておく。あと、可能な限りシンプルにする。何ならリネームして様子を伺う。許可されていない設定などがあると意図せずハマる。
あと、index.html などがないディレクトリではファイルのリストが表示されてしまうので、表示しないように設定する。
PHP.ini
cPanel の設定でphpの動作が３つから選択できた。特に変更した覚えはないので標準だと思うが、この場合、public_html 以下にphp.ini を設置して記載することで有効になる。CORESERVER だとphp が設置されたディレクトリにphp.ini を設置するので注意が必要。
主な設定項目はエラーを非表示にすること。設置中は良いが、設置後にエラーが表示されるとアカウント情報などが漏洩する。問題が発生したときはこれが設定されていることを忘れないように。時差設定はこちら。
必要があれば memory_limit = 64M やdate.timezone=”Asia/Tokyo” などを追記。
WordPress
WordPressを設置し、プラグインにWP Super Cache を利用している場合は書き換えが必要。
concrete5 （追記2012.01.03）
concrete5 を設置したディレクトリにアクセスしたところ以下のエラーが表示された。
[an error occurred while processing this directive]
php.ini を削除すれば解決するだろうと思ったが、.htaccess を削除することでアクセスできた。ただし、アクセスできる（この場合「データベースエラーです」）ことだけを確認しただけで、運用にあたってさらに調査する必要がある。
# 検索による情報によれば、上記エラーは主にSSI の問題として解決策が書かれているようだ
以下は削除したと思われる内容（サーバー上で直接削除したためバックアップファイルから）
AddHandler application/x-httpd-phpcgi .php
mod_gzip_on Off
# -- concrete5 urls start --
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /c5/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]
</IfModule>
# -- concrete5 urls end --
# -- concrete5 urls start --
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /c5/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]
</IfModule>
# -- concrete5 urls end --
# -- concrete5 urls start --
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /c5/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]
</IfModule>
# -- concrete5 urls end --
# -- concrete5 urls start --
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /c5/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]
</IfModule>
# -- concrete5 urls end --
その他
その他細かな修正や動作チェック。
例としては時差。今回の作業ではBluehost はUTC-7 （MST：山岳部標準時）で、日本はUTC+9 （JST：日本標準時）だからサーバー時刻から+16 時間に設定する。PHPの場合は上記PHP.iniの項を参照。
コメント