月別: 2013年5月

複数ブログ機能(マルチサイト)利用時のサーバー移行手順

複数ブログ機能(マルチサイト)利用時のサーバー移行手順

基本的には普通の移行と同じで、wp-configのマルチサイト設定を編集するかどうかなだけです。

環境

旧サーバー

ドメイン demo.hogehoge.com
ドキュメントルート /var/www/demo

新サーバー

ドメイン www.hogehoge.com
ドキュメントルート /var/www/www

上の新サーバーに移行する手順を例とします。
基本的にはwordpressのインポート/エクスポート機能は使用しません。

1.旧サーバーのMySQLのデータベースをダン

phpMyAdmin等が使えればログインし、wordpressが使用しているDBを選択したのちエクスポートタブを選択します。
「ファイルを保存する」にチェックを入れて実行するとdemodb.sqlみたいなファイルがダウンロードできます。
SSHログインができてmysqlコマンドが実行できるなら以下のコマンドでも。

mysqldump -uユーザ名 -pパスワード --databases DB名 > demodb.sql

2.取得したダンプファイルを一括置換

とってきたdemodb.sqlを一括置換します。
テキストエディタとかで開いて置換すればOKです

demo.hogehoge.com を www.hogehoge.com に一括置換
/var/www/demo を /var/www/www に一括置換
旧DB名 を 新DB名 に一括置換

WordPressで作成した記事内容の中も置換されるのである程度の確認はいるかもしれませんが基本的には全部置換して問題ないでしょう。
マルチサイトを使用していない場合や、サブディレクトリ形式のマルチサイトであれば上記でOKですが、
サブドメイン形式のマルチサイトであればそれらもすべて置換を行います。

blog1.hogehoge.com を blog1.hogehoge.com に一括置換
blog2.hogehoge.com を blog2.hogehoge.com に一括置換
...

3.旧サーバーのファイルをすべて新サーバーにコピー

FTPなどで旧サーバーのファイルをすべてコピーします。
wordpressディレクトリとかもそのままごっそりと。

4.新サーバーのMySQLのデータベースを作成してリストア

新サーバーにデータベースを作成します。
phpMyAdmin等が使えればログインし、「新規データベースを作成する」から作成すればOKです。

データベースの作成ができたら、先ほど置換したファイルをリストアします。

phpMyAdminが使えればログインし「インポート」メニューからファイルを選択する事ができますが、PHPで許可されている最大容量までしかアップロードできないので、容量制限の問題でアップロードできない場合はphp.iniや.htaccessでアップロード可能な最大サイズを変更する必要があります。

また、コマンドが使用できるのであれば以下のようなコマンドでリストア可能です。

mysql -u ユーザ名 -pパスワード DB名 < demodb.dump

5.新サーバーのwp-config.php.htaccessの修正

wp-config.phpをのDB設定を変更します

/** WordPress のためのデータベース名 */
define('DB_NAME', '新DB名');
/** MySQL データベースのユーザー名 */
define('DB_USER', '新ユーザー名');
/** MySQL データベースのパスワード */
define('DB_PASSWORD', '新パスワード');
/** MySQL のホスト名 */
define('DB_HOST', 'localhost');

複数ブログ機能を使用している場合は以下の項目もあるはずなので
ドメイン名を編集します。

define('WP_ALLOW_MULTISITE', true);
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
$base = '/';
define( 'DOMAIN_CURRENT_SITE', '新ドメイン名' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

5.確認

あとは動作確認を行えばOKです。

Debian wheezyをsqueezeと同じつもりで使って起きた問題

Debian wheezyが2013/05/04にリリースされました。

カーネルも一気にバージョンがあがって、いろいろなパッケージも新しめのバージョンが入って・・・
と、モダンな雰囲気を感じれていい感じです。
が、当然バージョンが変わったのでsqueezeと同じつもりで使ってるといくつか問題が起きたのでその備忘録です。
全体的には思ったよりも問題は発生せず、いままで通り使えています。

パッケージがいくつかなくなってる

普段使用しているパッケージでは以下の二つがなくなってました。
libssl0.9.8
libreadline5-dev

libssl1.0.0とlibreadline-gplv2-devに変更しました。

apt-get install libssl1.0.0 libreadline-gplv2-dev

tls v1をデフォルトで拒否するようになってた

上記に関連して。
libsslバージョンアップの影響か、特定のhttpsサイトにcurlwgetで接続行くときにエラーが出るようになりました。

curl https://xxxxx.xxx/xxx
url: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

curlに「-1」のオプションをつけると接続できるようになりました。
このオプションはtlsv1の暗号化でも接続を開始する、というオプションなようです。

curl -1 https://xxxxx.xxx/xxx

wgetコマンドではどうやればtlsv1を許容できるようになるのかわかりませんでした

autoconfのバージョンエラー

autoconfのバージョンが上がってる事が原因か、いくつかの古めのソフトウェアのconfigureでautoconf関係のエラーが発生しました。
今回の例ではqmailadminをインストールしようとconfigureしたところ、以下のエラーとなりました。

cd . && /bin/bash /usr/local/src/qmailadmin-1.2.16/missing --run automake-1.11 --gnu
aclocal.m4:16: warning: this file was generated for autoconf 2.65.
You have another version of autoconf.  It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically `autoreconf'.
configure.in:4: version mismatch.  This is Automake 1.11.6,
configure.in:4: but the definition used by this AM_INIT_AUTOMAKE
configure.in:4: comes from Automake 1.11.1.  You should recreate
configure.in:4: aclocal.m4 with aclocal and run automake again.

つたない英語力ですがとりあえず書かれている通りにautoreconfを実行してからconfigureしたらうまくいきました

autoreconf
./configure
make
make install

MySQL5.6にしていくつかのSQLでエラーが出るようになった

MySQL5.6にしていくつかのSQLでエラーが出るようになっちゃいました。

具体的にはINSERT文を実行した時、以下のようなエラーとなり処理が実行されなくなりました

SQLSTATE[HY000]: General error: 1364 Field 'hoge' doesn't have a default value

エラー文からデフォルトバリューが設定されてないカラムにNULLを入れようとした為のエラーのようです。
ぐぐるとずばりな回答をされてるブログが見つかりました。

iをgに変えるとorangeになることに気づいたoranieの日記
MySQL5.6で今までのVerでは問題無かったSQL文がエラーになった場合の対処法
http://d.hatena.ne.jp/oranie/20130402/1364906656

日々の覚書
MySQL5.6が勝手にsql_modeを書き換えてくれる話
http://yoku0825.blogspot.jp/2013/03/mysql56sqlmode.html

対処法

sql_modeの設定がMySQL5.5と5.6で異なる事が原因です。
sql_modeのSTRICT_TRANS_TABLESをはずせば、MySQL5.5と同じ動作となる為、
適切と判断した値を勝手に挿入して、警告を出力するだけにとどまり、上記エラーはおきません

mysql> SELECT @@GLOBAL.sql_mode;
+--------------------------------------------+
| @@GLOBAL.sql_mode                          |
+--------------------------------------------+
| STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION |
+--------------------------------------------+
1 row in set (0.00 sec)
mysql> SET @@GLOBAL.sql_mode='';
Query OK, 0 rows affected (0.04 sec)
mysql> SELECT @@GLOBAL.sql_mode;
+-------------------+
| @@GLOBAL.sql_mode |
+-------------------+
|                   |
+-------------------+
1 row in set (0.00 sec)

上記だと再起動すると設定が戻ってしまうのでmy.cnfの設定を変更する必要があるのですが注意が必要なのは、mysql5.6から「scripts/mysql_install_db」を実行した場合にMySQLのbasedirにmy.cnfを自動的に作成してくる事です。
このmy.cnfには以下のようなsql_modeが設定されていますので値を空に変更します。

sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
↓
sql_mode=''

/etc/my.cnfなど、他のmy.cnfを普段使用している場合、こちら設定してもbasedirのmy.cnfが設定を上書きしてくる為、必ず確認が必要です。(はまりました)

sql_mode STRICT_TRANS_TABLES

sql_modeは公式には以下のようにかかれています。

SQL モード – http://dev.mysql.com/doc/refman/5.1/ja/server-sql-mode.html

SQL シンタックスを MySQL がサポートし、どのようなデータ バリデーション チェックを実行するべきかを定義するもの

mysql5.6で設定されているsql_modeのSTRICT_TRANS_TABLESは通称「ストリクトモード」と呼ばれているもので、無効なデータなどの挿入、更新時にエラーを発生させるモードです。

まとめ

mysql5.6からbasedirに作られるmy.cnfでsql_modeをストリクトモードとして動かすSTRICT_TRANS_TABLESが設定されている。

今後、新規につくるサービスなどであればデフォルト通り有効にする事が望ましいと思いますが、すでに運用しているMySQL5.5のサービスを5.6にアップグレードする場合などは上記のようにSTRICT_TRANS_TABLESをはずせばOKです。

アカウントadminへの不正ログイン攻撃

最近、WordPressの不正ログイン被害が多く発生しているそうです。

WordPressは何も考えずインストールすると、管理ユーザー名は「admin」となってしまいます。
今回の不正ログインでは管理ユーザー名の「admin」に対して、さまざまなパスワードにて
ログインを試みる、いわゆるブルートフォースアタックと呼ばれるものです。

簡単なパスワードにしていると高確率でログインされてしまい「フィッシングサイト」に利用されたり「情報漏えい」したりとんでもないことになってしまいます。

そんな事になる前に対策を行っておきましょう

管理画面へのログインをIP制限

・特定のIPアドレスからしか編集を行わない
・サーバーが.htaccessを使用できる
上記の場合はそもそも管理画面にログインできるIPを制限してしまったら安心です。

.htaccess
[code]
<Files “wp-login.php“>
order deny,allow
deny from all
allow from xxx.xxx.xxx.xxx
</Files>
[/code]

上記のように記述した.htaccessをwp-login.phpと同階層に置けば特定のIP以外からのログイン画面への接続を制限する事が出来ます。

インストール時に作るIDをadminではなく別のものに

最新のwordpressではインストール時に作成するIDを任意に決定できます。
こちらでadmin以外のユーザー名を指定して下さい。

すでにインストールされたWordPressのIDを変更する

すでにadminユーザーとしてインストールされたWordPressの場合はすこし手間がかかります。
手順としては以下の通り

1.adminユーザーで別のIDの管理ユーザーを作成

ユーザー > 新規作成 で新規のユーザーを作成します。
権限を管理者にするのを忘れずに

2.adminユーザーをログアウトして新規のユーザーでログインします

するとadminユーザーが削除できるようになってますので削除。

マルチサイトWordPressのIDを変更する

すでにadminユーザーとしてインストールされたマルチサイト用のWordPressの場合はさらに手間がかかります。
手順としては以下の通り

1.サイトネットワークの新規ユーザー作成

参加サイト > サイトネットワーク管理者 > ユーザー > 新規追加 にて新規ユーザーを追加します。

2.作った新規ユーザーに「特権管理者権限」を与える

参加サイト > サイトネットワーク管理者 > ユーザー > 一覧 にて作成した新規ユーザを編集し、
「このユーザーにネットワーク特権管理者権限を与える」にチェックを入れて更新します。

3.各サイトにサイトネットワーク管理者のユーザーを追加する

各サイトのユーザー > 新規作成 で新規のユーザーを作成します。
マルチサイトの場合は既存のユーザーをメールアドレスから追加します。
この作業を全サイトぶん繰り返します。

4.adminユーザーの権限を削除する

adminユーザーをログアウトし、新規作成したユーザーでログインします。
新規作成したユーザーでadminユーザーの権限を削除します。
各サイトのユーザー > adminユーザーの編集を行い、権限を「このサイトでの権限なし」に変更します。
この作業を全サイトぶん繰り返します。

この作業が完了するとネットワーク管理者一覧でのadminユーザーの「サイト」に何も表示がなくなります。

この状態を確認したらadminユーザーの管理者権限をはずし

後はサイトネットワーク管理者からadminを削除して完了です。

パーマリンクをpostnameにて自動採番

WordPressの採番について。

記事のURLがランダムな数字であれば問題ないという場合、
記事ごとのパーマリンクの設定を%post_id%とする事は多いと思います。

しかし、この%post_id%はたしかに記事固有IDなのですがいろいろな問題があります。
ひとまず直面した問題は以下の通り

・特定の記事のURLを変えたい時があったとしても変更ができない
・サーバー移転時にパーマリンクが変わる

その為、%postname%を使用しつつ、新規投稿時のみ%post_id%が入る形ができるように頑張ってみました。

パーマリンクの修正

WordPress管理画面の
設定 -> パーマリンク設定
から%post_id%としていた部分を %postname% に変更します。

meta-boxes.phpの修正

wp-admin/includes/meta-boxes.php の post_slug_meta_box関数を編集します。
おそらく500~510行目あたりです。

[code]
function post_slug_meta_box($post) {
?>
<label class=”screen-reader-text” for=”post_name”><?php _e(‘Slug’) ?></label><input name=”post_name” type=”text” size=”13″ id=”post_name” value=”<?php echo esc_attr( $post->post_name ); ?>” />
<?php
}
[/code]

こちらを以下のように修正します。

[code]
function post_slug_meta_box($post) {
?>
<label class=”screen-reader-text” for=”post_name”><?php _e(‘Slug’) ?></label><input name=”post_name” type=”text” size=”13″ id=”post_name” value=”<?php
if(get_post_status() == ‘publish’ || get_post_status() == ‘future’ || get_post_status() == ‘draft’ ){
echo esc_attr( $post->post_name );
} else {
echo $post->ID;}
?>” />
<?php
}
[/code]

変更点はvalueの部分ですが、少し解説です。
まず条件分岐している部分ですが、get_post_status() で現在のpostの状態を取得できます。
このpost状態が「公開」「予約投稿」「下書き」の場合とそれ以外の場合で条件分岐させています。
なぜこんな条件分岐を入れているかと言うと、
すでに投稿された記事以外はあらたな番号を採番する必要がないからです。
この条件分岐がなければ、記事を更新する度に記事のパーマリンクが変更されてしまう事となります。

つまり、すでに投稿されていれば、入力されているスラッグを表示、
新規の投稿であれば自動採番 といった形です。

以上でpostnameでの自動採番は完了です

(おまけ)自動連番

試してないのですが、googleで検索したサイトなどを確認したら
get_usernumposts で そのユーザーの投稿数を+1する方法が多く見つかりました。
ただget_usernumpostsは今は非推奨、との事なのでcount_user_postsをつかう方がよさそう。
連番にしたい場合は上記のソースのecho $post->ID を echo count_user_posts(1) + 1 に変更すればOKだと思われます。
おそらく記事を完全に削除したりするとIDが狂いそうな気もしますが、、

未検証です。
[code]
function post_slug_meta_box($post) {
?>
<label class=”screen-reader-text” for=”post_name”><?php _e(‘Slug’) ?></label><input name=”post_name” type=”text” size=”13″ id=”post_name” value=”<?php
if(get_post_status() == ‘publish’ || get_post_status() == ‘future’ || get_post_status() == ‘draft’ ){
echo esc_attr( $post->post_name );
} else {
echo count_user_posts(1) + 1;}
?>” />
<?php
}
[/code]

© SEEDS Co.,Ltd.