2009年04月29日
レンタルサーバ移行完了
2009/04/29
自社ドメインのレンタルサーバの移行作業が一応完了した。
思ったより手間がかかってしまった。
一番の原因はプログラムの修正が発生したため、動作確認に時間がかかったためだ。
また、異なるドメイン名で確認を行なっていたため、htmlファイル中のリンク確認にも時間を要した。
次回、もし移行することがあれば、かなり早く作業をできるだろうから、今回の作業は無駄にはならないだろう。
現在の状況は以下の通り。
【メール】
以前からレンタルサーバーで運用しており、メールのロストもなさそうだ。
普段は電源を入れていない経理に使っているパソコンでメール受信を忘れていたことに
最後の最後に気が付いた。すべてのメールボックスのメールが0件になったことを確認したので、
もれはないだろう。
メールソフトだけでなく、ログ自動収集ソフトなどWindowsアプリケーションに設定していた
メール設定情報の更新も行なった。
【Web】
社内テストサーバーからレンタルサーバーに一応移行できた。
一部のPHPスクリプトにおいてコードの修正を行なった。
レンタルサーバはphpがCGIモードで動作するため、.htaccessの記述を一部変更した。
【デモサービス】
自社ドメインのコンテンツのみの移行したので、自社ドメインで
運用していたデモサービスはすべて削除した。今後、見直しを行い他のドメイン/サーバーで運用する。
・Webカメラリアルタイムキャプチャー
・空メール自動応答
・通信機器の遠隔制御
・写真添付メールの写真をWebに自動公開
【DNS】
自社テストサーバーで運用していた時は無料のDDNS「私的DynamicDNS」を利用していたが、
新レンタルサーバーに移行したドメイン分の設定を解除した。
【その他】
今回、ヘテムル(heteml)(発音しにくい＾＾；)という廉価なレンタルサーバに移行したが、何点か気付いたことをメモ。
自社ドメインのレンタルサーバの移行作業が一応完了した。
思ったより手間がかかってしまった。
一番の原因はプログラムの修正が発生したため、動作確認に時間がかかったためだ。
また、異なるドメイン名で確認を行なっていたため、htmlファイル中のリンク確認にも時間を要した。
次回、もし移行することがあれば、かなり早く作業をできるだろうから、今回の作業は無駄にはならないだろう。
現在の状況は以下の通り。
【メール】
以前からレンタルサーバーで運用しており、メールのロストもなさそうだ。
普段は電源を入れていない経理に使っているパソコンでメール受信を忘れていたことに
最後の最後に気が付いた。すべてのメールボックスのメールが0件になったことを確認したので、
もれはないだろう。
メールソフトだけでなく、ログ自動収集ソフトなどWindowsアプリケーションに設定していた
メール設定情報の更新も行なった。
【Web】
社内テストサーバーからレンタルサーバーに一応移行できた。
一部のPHPスクリプトにおいてコードの修正を行なった。
レンタルサーバはphpがCGIモードで動作するため、.htaccessの記述を一部変更した。
【デモサービス】
自社ドメインのコンテンツのみの移行したので、自社ドメインで
運用していたデモサービスはすべて削除した。今後、見直しを行い他のドメイン/サーバーで運用する。
・Webカメラリアルタイムキャプチャー
・空メール自動応答
・通信機器の遠隔制御
・写真添付メールの写真をWebに自動公開
【DNS】
自社テストサーバーで運用していた時は無料のDDNS「私的DynamicDNS」を利用していたが、
新レンタルサーバーに移行したドメイン分の設定を解除した。
【その他】
今回、ヘテムル(heteml)(発音しにくい＾＾；)という廉価なレンタルサーバに移行したが、何点か気付いたことをメモ。
- PHP:socket関数が使えない
メール送信関数でエラーが起こっていた。
確認すると、会員メルマガ配信用にBccメールを送信できる送信ライブラリを使っており、
簡易的にSMTPプロトコルを実装して、サーバーとの通信にsocketライブラリを使っていた。
レンタルサーバでは、メルマガ配信は行なわないし、問い合わせメールを送信するだけなので、
送信ライブラリを使わずmail関数で送信するように修正して対応。
- メール転送
転送先に送信される転送メールのReturn-Pathが<postmaster-error@heteml.jp>に差し替えられている。
これまで使っていたレンタルサーバ「ロリポップ(lolipop)」では、差出人のメールアドレス(MAIL FROMで指定したアドレス)のままだった。
転送失敗のトラブルを発見しずらくなるが、運用上は問題ないだろう。
2009年04月29日
レンタルサーバ変更に伴うWeb、メールサーバーの切替メモ
2009/04/28
[レンタルサーバ移行作業のメモ]
今回は、Webサーバー、メールサーバーの順番に切り替えを行いました。
---------------------------------------------------------------------------
【Webサーバーの切替】
Webサーバーはもともとhtmlで自社テストサーバ(違うドメイン名)に移動するようにしていたので、
新サーバーに同じhtmlファイルを置き、DNSのWebサーバの設定を新サーバーに変更。
自社テストサーバーのコンテンツは最終的に新サーバーに移動させますが、現時点で一部の
PHPスクリプトが動作しないので、動くようになってから新サーバーでの運用を開始します。
---------------------------------------------------------------------------
【メールサーバーの切替】
DNSのMXレコードを移行先のメールサーバに変更すれば完了です！
と言えればラクチンですが、現実にはそうはいきません＾＾;
単に切り替えて使い始めてしまうと、切り替え前後に一部のメールが届かない不具合が発生してしまいます。
（メールのやりとりがほとんどない場合は気にしなくていいのかもしれませんが・・・）
そこで、切り替え前後で届いているメールの受信もれがないように以下の手順で受信します。
（切り替え前のメールソフトの設定は旧サーバーを使って送信・受信しているものとします）
(1)新メールサーバーにメールアカウントを登録
(2)旧メールサーバーにてメールを受信
(3)DNSのメール設定を新サーバーに変更
(4)メールソフトのメール送信・受信の設定を新サーバーに変更
(5)テストメールを送信してメールを受信できることを確認(送受信テスト)
(*)以下の(6)はまだ実施しません。
(6)旧レンタルサーバーのドメイン設定を解除
(5)まで行うと、基本的にメール切り替えが完了していますが、DNSのメール設定が
全世界に反映されるまでの間は、旧サーバーにメールが届きます。
そこで、(6)の実施は少し時間を置きます。(私は24時間後に実施しました)
(参考)旧メールサーバーを使う他の利用者からのメールは「(6)のドメイン解除」を行なうまでは、
旧メールサーバに届きます。同じレンタルサーバーを使っている取引先がある場合には要注意です。
(6)の実施前に旧メールサーバーにメールが届いているかどうか確認します。
メールが届いておれば、メールソフトのメール受信設定を旧メールサーバーに戻して受信します。
メールサーバー名が新サーバーと旧サーバーで同じ場合は、旧メールサーバーのかわりにIPアドレスを入れて受信します。
受信が完了したら、メールソフトの設定を新サーバーに戻して(6)の解除を行ないます。
これで、移転作業は完了です。
---------------------------------------------------------------------------
【最後に】
上のように書いたことを眺めると簡単そうですね。
現実は、手間をかけて自分が動かないと実現できません。
移転作業をされる方は、じっくりがんばってください＾＾。
私の場合、メールアカウントに届いているメールの確認作業をとても手作業でできず、
プログラムを書きましたので、参考までにご紹介します。
旧サーバーにメールが残っているかを確認するのは、メールアカウントが数個なら
それほど手間はありません。しかし、個数が多くなると確認するだけでも大変です。
（確認の結果1通もメールがなかったら確認した手間が無駄になったような気になりますが、
1通も失うことがないようにするためには、この確認は必須です）
私はテストアカウントを100個以上登録していたので、手作業ではしんどい状態でした＾＾；。
そこで、以下のようなPHPスクリプトを書いてすべてのメールアカウントを確認しました。
無保証、無サポートですが使いたい方は、ご自由にお使いください。
<?php
// 2009/04/28-29
// 指定アカウントのメールボックスにメールが残っているかどうかを調べます
// 0件なら正常、アクセスエラー、1件以上ある場合はエラー表示します
// $account、$hostを適切に記述して使ってください
error_reporting( 0 ); // 0件の時「PHP Notice: Unknown: Mailbox is empty (errflg=1) in Unknown on line 0」と表示されるのを抑制
$account = array(
array("name1@somedomain.name","user1","pass1"),
array("name2@somedomain.name","user2","pass2"),
);
$host = "pop.somedomain.name";
$port = 110;
for ( $i = 0; $i < count( $account ); $i++ ) {
$email = $account[ $i ][ 0 ];
$user = $account[ $i ][ 1 ];
$pass = $account[ $i ][ 2 ];
$sum = get_mbox( $host, $user, $pass, $port );
if ( $sum < 0 ) {
$msg = "(x)$email POP access error.\r\n";
} else if ( $sum > 0 ) {
$msg = "(x)$email has $sum message.\r\n";
} else {
$msg = "(o)$email\r\n";
}
echo $msg;
}
function get_mbox( $host, $user, $pass, $port = 110 )
{
$sum = -1;
$str = "{".$host.":".$port."/pop3}INBOX";
$mbox = @imap_open( $str , $user, $pass );
if ( $mbox !== false ) {
$sum = @get_msgnum( $mbox );
imap_close( $mbox );
}
return $sum;
}
function get_msgnum( $mbox )
{
$check = imap_check($mbox);
return $check->Nmsgs;
}
?>
[レンタルサーバ移行作業のメモ]
今回は、Webサーバー、メールサーバーの順番に切り替えを行いました。
---------------------------------------------------------------------------
【Webサーバーの切替】
Webサーバーはもともとhtmlで自社テストサーバ(違うドメイン名)に移動するようにしていたので、
新サーバーに同じhtmlファイルを置き、DNSのWebサーバの設定を新サーバーに変更。
自社テストサーバーのコンテンツは最終的に新サーバーに移動させますが、現時点で一部の
PHPスクリプトが動作しないので、動くようになってから新サーバーでの運用を開始します。
---------------------------------------------------------------------------
【メールサーバーの切替】
DNSのMXレコードを移行先のメールサーバに変更すれば完了です！
と言えればラクチンですが、現実にはそうはいきません＾＾;
単に切り替えて使い始めてしまうと、切り替え前後に一部のメールが届かない不具合が発生してしまいます。
（メールのやりとりがほとんどない場合は気にしなくていいのかもしれませんが・・・）
そこで、切り替え前後で届いているメールの受信もれがないように以下の手順で受信します。
（切り替え前のメールソフトの設定は旧サーバーを使って送信・受信しているものとします）
(1)新メールサーバーにメールアカウントを登録
(2)旧メールサーバーにてメールを受信
(3)DNSのメール設定を新サーバーに変更
(4)メールソフトのメール送信・受信の設定を新サーバーに変更
(5)テストメールを送信してメールを受信できることを確認(送受信テスト)
(*)以下の(6)はまだ実施しません。
(6)旧レンタルサーバーのドメイン設定を解除
(5)まで行うと、基本的にメール切り替えが完了していますが、DNSのメール設定が
全世界に反映されるまでの間は、旧サーバーにメールが届きます。
そこで、(6)の実施は少し時間を置きます。(私は24時間後に実施しました)
(参考)旧メールサーバーを使う他の利用者からのメールは「(6)のドメイン解除」を行なうまでは、
旧メールサーバに届きます。同じレンタルサーバーを使っている取引先がある場合には要注意です。
(6)の実施前に旧メールサーバーにメールが届いているかどうか確認します。
メールが届いておれば、メールソフトのメール受信設定を旧メールサーバーに戻して受信します。
メールサーバー名が新サーバーと旧サーバーで同じ場合は、旧メールサーバーのかわりにIPアドレスを入れて受信します。
受信が完了したら、メールソフトの設定を新サーバーに戻して(6)の解除を行ないます。
これで、移転作業は完了です。
---------------------------------------------------------------------------
【最後に】
上のように書いたことを眺めると簡単そうですね。
現実は、手間をかけて自分が動かないと実現できません。
移転作業をされる方は、じっくりがんばってください＾＾。
私の場合、メールアカウントに届いているメールの確認作業をとても手作業でできず、
プログラムを書きましたので、参考までにご紹介します。
旧サーバーにメールが残っているかを確認するのは、メールアカウントが数個なら
それほど手間はありません。しかし、個数が多くなると確認するだけでも大変です。
（確認の結果1通もメールがなかったら確認した手間が無駄になったような気になりますが、
1通も失うことがないようにするためには、この確認は必須です）
私はテストアカウントを100個以上登録していたので、手作業ではしんどい状態でした＾＾；。
そこで、以下のようなPHPスクリプトを書いてすべてのメールアカウントを確認しました。
無保証、無サポートですが使いたい方は、ご自由にお使いください。
<?php
// 2009/04/28-29
// 指定アカウントのメールボックスにメールが残っているかどうかを調べます
// 0件なら正常、アクセスエラー、1件以上ある場合はエラー表示します
// $account、$hostを適切に記述して使ってください
error_reporting( 0 ); // 0件の時「PHP Notice: Unknown: Mailbox is empty (errflg=1) in Unknown on line 0」と表示されるのを抑制
$account = array(
array("name1@somedomain.name","user1","pass1"),
array("name2@somedomain.name","user2","pass2"),
);
$host = "pop.somedomain.name";
$port = 110;
for ( $i = 0; $i < count( $account ); $i++ ) {
$email = $account[ $i ][ 0 ];
$user = $account[ $i ][ 1 ];
$pass = $account[ $i ][ 2 ];
$sum = get_mbox( $host, $user, $pass, $port );
if ( $sum < 0 ) {
$msg = "(x)$email POP access error.\r\n";
} else if ( $sum > 0 ) {
$msg = "(x)$email has $sum message.\r\n";
} else {
$msg = "(o)$email\r\n";
}
echo $msg;
}
function get_mbox( $host, $user, $pass, $port = 110 )
{
$sum = -1;
$str = "{".$host.":".$port."/pop3}INBOX";
$mbox = @imap_open( $str , $user, $pass );
if ( $mbox !== false ) {
$sum = @get_msgnum( $mbox );
imap_close( $mbox );
}
return $sum;
}
function get_msgnum( $mbox )
{
$check = imap_check($mbox);
return $check->Nmsgs;
}
?>
2009年03月25日
xoopsでテスト環境を構築したが文字化けしていた
xoopsのモジュール改造の仕事をいただいた。ありがたいことです。
まず、お客様のデータをいただきテスト環境を構築したが、気付いたことがあるのでメモ。
お客様の環境はphpスクリプト、MySQLデータベースともEUC-JP。
テスト環境はutf8、MySQLのデフォルトエンコーディングもutf8。
テスト環境でxoopsのindex.phpを実行すると、日本語文字がすべて「????」と文字化けしている。
お客様のphpスクリプトはEUC-JPのままコピーしている、テーブルデータはujis(EUC-JP)でインポートしている。
phpMyAdminでテーブル内容を確認する限り、問題なく日本語は読めている。
文字化けの原因は、(1)phpスクリプトか、(2)MySQLのエンコーディングと思われる。
(1)phpスクリプトはmbstring関係があやしいので、/index.phpから読み出している/mainfile.phpに次の文を追加してみた。
ini_set( "mbstring.language", "Japanese" );
ini_set( "mbstring.internal_encoding", "EUC-JP" );
変化はない。
(2)次にMySQL側を調べてみよう。以前SJISのデータを扱う時に
MySQLのクエリに実行の都度以下のようなコマンドを渡した記憶がかすかにある。
SET CHARACTER SET SJIS
Googleで「xoops 文字化け mysql」を検索してみると、まさにそのものという情報があった。
[XOOPSを引越ししたら文字化け]
http://blog.karakuriya.biz/xoops/000587.html
/class/database/mysqldatabase.php を修正するとよいらしい。
具体的な修正箇所は、236行目付近の
$result = & mysql_query($sql, $this->conn);
の上に
mysql_query("SET CHARACTER SET ujis", $this->conn);
を追加すること。
この修正でほぼ文字化けは解消した。
「ほぼ」と書いたのは、すべてのモジュールで直ったわけではないからだ。
一部のモジュールは相変わらず「????」のままなのだ。
今回の対象モジュールではないので、放置しておく。必要になった時に調べることにする。
おそらく/class/database/mysqldatabase.phpの「XoopsMySQLDatabase」クラスを利用せず、
独自にmysql_query()を利用しているのだろう。
さぁて、次はターゲットモジュールをすべて読むことにしよう。
まず、お客様のデータをいただきテスト環境を構築したが、気付いたことがあるのでメモ。
お客様の環境はphpスクリプト、MySQLデータベースともEUC-JP。
テスト環境はutf8、MySQLのデフォルトエンコーディングもutf8。
テスト環境でxoopsのindex.phpを実行すると、日本語文字がすべて「????」と文字化けしている。
お客様のphpスクリプトはEUC-JPのままコピーしている、テーブルデータはujis(EUC-JP)でインポートしている。
phpMyAdminでテーブル内容を確認する限り、問題なく日本語は読めている。
文字化けの原因は、(1)phpスクリプトか、(2)MySQLのエンコーディングと思われる。
(1)phpスクリプトはmbstring関係があやしいので、/index.phpから読み出している/mainfile.phpに次の文を追加してみた。
ini_set( "mbstring.language", "Japanese" );
ini_set( "mbstring.internal_encoding", "EUC-JP" );
変化はない。
(2)次にMySQL側を調べてみよう。以前SJISのデータを扱う時に
MySQLのクエリに実行の都度以下のようなコマンドを渡した記憶がかすかにある。
SET CHARACTER SET SJIS
Googleで「xoops 文字化け mysql」を検索してみると、まさにそのものという情報があった。
[XOOPSを引越ししたら文字化け]
http://blog.karakuriya.biz/xoops/000587.html
/class/database/mysqldatabase.php を修正するとよいらしい。
具体的な修正箇所は、236行目付近の
$result = & mysql_query($sql, $this->conn);
の上に
mysql_query("SET CHARACTER SET ujis", $this->conn);
を追加すること。
この修正でほぼ文字化けは解消した。
「ほぼ」と書いたのは、すべてのモジュールで直ったわけではないからだ。
一部のモジュールは相変わらず「????」のままなのだ。
今回の対象モジュールではないので、放置しておく。必要になった時に調べることにする。
おそらく/class/database/mysqldatabase.phpの「XoopsMySQLDatabase」クラスを利用せず、
独自にmysql_query()を利用しているのだろう。
さぁて、次はターゲットモジュールをすべて読むことにしよう。