WordPressの移行 (サーバ名変更とReverse Proxy下へ移動）
テストで動かしていたWordPressですが、ログイン時と認証後のアクセスはオレオレ証明書にてHTTPS化して運用していました。 こちらを、なんとか正規証明書の下で動かすことに。
ただし、自ホストで正規証明書を利用することは運用上難点があったので、リバースプロキシにHTTPS化してもらうことになりました。
今までアクセスしていたホスト名はDNSを変更して、リバースプロキシ側に譲ります。一方、WordPressを稼働させていたホスト自身は、また別の名前に付け替え。
* * *
リバースプロキシの設定も、ホスト名の変更もそんなに手間はかかりません。 ホスト名変更の場合は、/etc/hostsと/etc/sysconfig/network を変えて、再起動でOK。
再起動を待ち、「いざ、WordPressにアクセス！」となったのですが、何か変..。
wordpress + 移行で検索すると、結構記事が出てきます。 ただし、Reverse Proxy下に置かれたパターンはあまり事例がありません。
まずは、MySQLのデータをバックアップ（ダンプ）しておきます。
バックアップの意味、というよりは、データをテキスト化してダンプし、そのテキストをエディタで編集し、インポートし直す、という作業が必要だからです。
今回は、http –> https に全部置き換えになったため、テーブルの中にあるバイナリコンテンツのURL（プロトコル部分）を修正する必要があります。
で、これをSQLで行うというのは結構面倒(^^;
そこで、テキストの形でエクスポートしたWordPress DBの中身を、スクリプトを使って置換し、インポートしなおすという作業になった次第です。
置換はPerlのワンライナーで。http://blog –> https://blog に置き換えるだけのものです。
その後に編集したファイルからインポートします。
こちらの設定で、DBで定義したsiteurl, homeを上書きする形になります。
WP＿SITEURL,WP_HOME,WP_CONTENT_URLが設定画面（DBで定義）したものと同じなら、wp-config.phpに記載する必要はありません。
大事なのが、下３行。
今回の場合は、常にHTTPSなので、$_SERVER['HTTPS'] = 1; が必要でした。
この下３行が無いと、どうしてもログインできませんでした。
curl に –v オプションをくっつけて詳細を表示できます。
正規の証明書が入ったので、Windows Live writerなどのブログツールも問題なく使えるようになりました。（オレオレの場合は手作業で証明書をインポートしたりしないといけなかったので）
大掛かりではないけれど、移行してみて感じたのは、テキストにダンプして編集してインポートしなおせるって、便利だなあ～ということでした :)
ただし、自ホストで正規証明書を利用することは運用上難点があったので、リバースプロキシにHTTPS化してもらうことになりました。
今までアクセスしていたホスト名はDNSを変更して、リバースプロキシ側に譲ります。一方、WordPressを稼働させていたホスト自身は、また別の名前に付け替え。
* * *
リバースプロキシの設定も、ホスト名の変更もそんなに手間はかかりません。 ホスト名変更の場合は、/etc/hostsと/etc/sysconfig/network を変えて、再起動でOK。
再起動を待ち、「いざ、WordPressにアクセス！」となったのですが、何か変..。
- アップロードした画像が表示されない。
- ログイン画面に遷移し、正しいアカウント＆パスワードを指定してもログインできない。
対応1. バイナリコンテンツの復旧
wordpress + 移行で検索すると、結構記事が出てきます。 ただし、Reverse Proxy下に置かれたパターンはあまり事例がありません。まずは、MySQLのデータをバックアップ（ダンプ）しておきます。
バックアップの意味、というよりは、データをテキスト化してダンプし、そのテキストをエディタで編集し、インポートし直す、という作業が必要だからです。
mysqldump -u root wordpress > wordpress.dumpWordpressの記事のURL（パーマリンク）は、相対パスで生成されるようなので大丈夫なのですが、アップロードしたコンテンツのURLは、DBのテーブルの中に、絶対パスでサイトのドメイン名込みで登録されてしまっていました。 （これは、バイナリコンテンツと、テキストをメインとしたDBを分散させて管理できるようにしているWordPressの仕様なのかなと思いました。大規模サイトであれば、バイナリコンテンツはキャッシュサーバなどを利用するのが定石なんでしょうか。識者の方、コメントいただければ幸いです）
今回は、http –> https に全部置き換えになったため、テーブルの中にあるバイナリコンテンツのURL（プロトコル部分）を修正する必要があります。
で、これをSQLで行うというのは結構面倒(^^;
そこで、テキストの形でエクスポートしたWordPress DBの中身を、スクリプトを使って置換し、インポートしなおすという作業になった次第です。
置換はPerlのワンライナーで。http://blog –> https://blog に置き換えるだけのものです。
perl -pe 's/http:\/\/blog/https:\/\/blog/g' < wordpress.dump > wordpress-2.dumpこのあと、一度WordpressのDBをDrop –> Create。
その後に編集したファイルからインポートします。
mysql -u root -p パスワード wordpress < wordpress-2.dumpこれでApacheの再起動後、ちゃんと画像が復活してくれました。
対応2. Reverse Proxy対応
wp-config.php に、下記の設定を追加しました。こちらの設定で、DBで定義したsiteurl, homeを上書きする形になります。
WP＿SITEURL,WP_HOME,WP_CONTENT_URLが設定画面（DBで定義）したものと同じなら、wp-config.phpに記載する必要はありません。
大事なのが、下３行。
/**設定に関しては、こちらを参考にさせていただきました。たいへん助かりました！
* For reverse proxy
*/
define('WP_SITEURL', 'https://ユーザに公開されるBlogのURL’);
define('WP_HOME', 'https://ユーザに公開されるBlogのURL’);
define('WP_CONTENT_URL', ‘https://ユーザに公開されるBlogのURL/wp-content');
$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_FORWARDED_FOR'];
$_SERVER['HTTPS'] = 1;
今回の場合は、常にHTTPSなので、$_SERVER['HTTPS'] = 1; が必要でした。
この下３行が無いと、どうしてもログインできませんでした。
対応3. 動作確認
有効な証明書で通信が行われているか、ブラウザでもチェックできますが、ここはコマンドラインで。curl に –v オプションをくっつけて詳細を表示できます。
# curl -v -I -X GET https://ユーザに公開されるBlogのURL’/ちゃんと証明書情報が確認できました。これでオレオレ卒業です。
* About to connect() to **** port 443
* Trying xx.xx.xxxx.xxx... connected
* Connected to **** (xx.xx.xxxx.xxx) port 443
* successfully set certificate verify locations:
* CAfile: /etc/****.crt
CApath: none
* SSLv2, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
…………
* Server certificate:
* <-- このへんに証明書情報
* SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/xxxxxxxx
> Host: ****
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
--- [ Snip ] ---
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
正規の証明書が入ったので、Windows Live writerなどのブログツールも問題なく使えるようになりました。（オレオレの場合は手作業で証明書をインポートしたりしないといけなかったので）
大掛かりではないけれど、移行してみて感じたのは、テキストにダンプして編集してインポートしなおせるって、便利だなあ～ということでした :)
コメント
コメントを投稿