～ ミネルヴァの梟は黄昏とともに飛び始める ～

　以前から放置していた、社内ブログ（wordpress）のDB（MySQL）を移行したのですがめちゃくちゃハマりました。

　もともとそのサーバには、他にもサービスが同居していた事もあり、MySQLにメモリを多めに割り当てていたのですが、そのサービス達も別のサーバに移行したため、ブログのためだけに大量のメモリを確保するDBが存在する事になってしまいました。

　データセンターに太い回線を引き込んでいる共用のDBサーバがあるので、ブログのDBもそちらに移行する事に決定。

　まぁ、DBの移行だからすぐに終わるだろうと思い、DBのダンプをとり、共用DBにリストア。さらにアクセス用のアカウントを作成。コンソールからネットワークを超えてアクセスしようとすると、反応が返ってこない。

　明らかにファイアーウォールでブロックされている感じなので、そのサーバ群を設定した担当者に確認すると、（ラック内のサーバ群は、ネットワークポートが２つあり、ラック内はLANとしてアクセスできる一般的な構成で）グローバル側からは、MySQLのアクセスを拒否しているとの事で、ローカルのIPを教えてもらう。

　ついでに、彼が過去に同じ作業をしようとしてなぜか上手くいかなかったというありがたいオマケ情報も。。。

　ローカルIPを使用して、コンソールからネットワークを超えてDBに接続できる事を確認。wordpress の wp-config.php 中に書かれている DB_HOST にローカルIPを指定するも「Error establishing a database connection」エラー。

　ちょっと、ネットを調べると、「Client does not support authentication protocol エラー」というトラブルが発生する事があるとのこと。これは、認証用のパスワードの暗号化方法がMySQL 4.1.1から変更されたことに起因する問題らしい。

　一応、両方サーバ共MySQLのバージョンが同じでPHPも新しいのですが、ものは試し。。。
mysql> UPDATE user SET Password = OLD_PASSWORD('mypass')
-> WHERE Host = 'some_host' AND User = 'some_user';
mysql> FLUSH PRIVILEGES;

　が、エラー。もとに戻す。

　wordpressのバグかもしれないので、最新のwordpressを設定。アクセスしようとすると、fobidden。「ああ、SELinuxか」と、ラベルの設定。ウェブは表示されたが、同じくコネクションエラー。

　テスト用に以下のようなコードを用意。

　やはり、localhostだと動作し、別のサーバを指定すると動かない。この時点で、wordpressのバグで無い事を確信。次に、phpinfo()でステータスの確認をするも問題なし。

　この時点で、wordpressがあるサーバの問題で、恐らくphpか何かの設定だろうという話を先ほどのサーバ管理者にしたら、「あ、あ、あ、もしかして」と一言。どうやら、SELinuxの設定で、Httpdが外部へソケットを貼るのを禁止にしていたらしいです。

　結構、時間かかりました。みなまさもSELinuxには要注意です。