WordPress 2.8 の自動アップグレード問題、つづきです。Nire.Com でも似たような環境だったという話と、ある日突然起きるこのようなサーバのトラブルに、どう自衛策を講じればいいんでしょうね、という話。

WordPress 導入初期には似たような環境だった

微妙に jgbutler 氏とは違うかもしれませんが、もともとスタティックな HTML ファイル手書きのコンテンツを大量に抱える Nire.Com は、あんまり DocumentRoot を汚したくないので、WordPress インストール当時、

  • http://www.nire.com/wpfiles/ のようなサブディレクトリを掘って、そこに WordPress 関連のファイルをインストール
  • でも、記事のパーマリンクは http://www.nire.com/2009/06/ のように DocumentRoot にあるように見える

ような運用をしていたのです。が、

  • どうもサブディレクトリに WordPress ファイルを置く形態に対応していないプラグインがあるらしい
  • WordPress 関連のファイルが大半 wp で始まる
  • 何回もインストールしているうちに目が慣れた 🙂

ため、ある時期、DocumentRoot 以下にすべての WordPress ファイルを置く、デフォルトなインストール形態にもどしたのでした。

投稿テキスト本文のパーマリンクは変化しませんが、wp-content/upload/ 以下にアップした画像はすべて 1ディレクトリ上にパスが変更になるので、すべての投稿中に埋め込まれているディレクトリを変更する羽目に。

http://www.nire.com/wpfiles/wp-content/uploads/…
↓
http://www.nire.com/wp-content/uploads/…

MySQL の中に埋め込まれた http://www.nire.com/… というパスもすべて検索してつじつまが合うように変更することになり、面倒なことこの上ありません :mrgreen:

「標準的」なインストール以外はしない

これだからフリーの CMS は…という結論に持っていくのは簡単ですが、WordPress に限った話ではなく、デフォルトおまかせのインストールフォルダ以外にインストールされたとき、問題を引き起こすアプリケーションや、プラグインの例は他にもあります。

何かヤバいと思ったので、Nire.Com の場合は早期にトリッキーなディレクトリ構成を、標準的な DocumentRoot に入れるように戻したわけですが。

利用者数の多いソフトでも、カスタマイズされたインストールシナリオはどうしてもテストが手薄になりがちですので、安定動作を望むなら標準インストール、というのが、とても保守的ですがささやかな自衛方法、と言えるかもしれません。

1つの OS に機能を詰め込まない

WordPress が他のファイルを消さないような安全な作りにすれば、という意見もあるかもしれません。例えば、WordPress 専用のユニークなユーザアカウント / グループで動作するとか。いや、WordPress を複数インストールするような場合はそれだけでは不十分そうですね。

これもユーザの自衛策としては、あんまり 1つの OS にサーバソフトを詰め込まないで、どうしても何種類も運用したいなら Hyper-V / Virtual Server / VMware で仮想化とか、が良いのかもしれません。

バックアップを要所要所で取る

そして、基本中の基本ですが、バックアップを取ることにつきるでしょう。

ゲームだってボスキャラっぽい予感がしたら  SAVE するでしょう?

私の場合は、phpMyAdmin によるバックアップと VMware のイメージごとバックアップを併用しています。それも、直前 1回分だけではなく、WordPress バージョンアップするとか、大規模なメンテとか、何かを変更するときにスナップショットとしてバックアップを取り、数回のバックアップ分は遡れるようになっています。

疑わしきは「罰する」のがサーバ管理の鉄則

Nire.Com の自動アップグレードした環境も、「以外」って言われてもさすがにゲスト OS 内のすべてのファイルの diff までは取っていないので、問題の範囲が明示されない以上グレー、とせざるを得ないのが職業病。

インストーラの問題だけで、多分 SQL データベース内は問題ないと思うのですが、グレーなものからの phpMyAdmin バックアップも信用できないし、WordPress 本体のバックアップ機能にいたっては、試しましたが期待通りに動作しなかった 👿 ので、結局以下のように手間のかかる作業をすることにしました。

  • 自動アップグレードして以降 1週間分の投稿テキスト、タグといったすべての情報を、テキストエディタに手動でコピペ。画像もバックアップ。
  • WordPress 2.7.1 の VMWare イメージのバックアップを出してきて
  • 手動で WordPress 2.7.1 → 2.8 にアップグレード
  • テキストファイルで残してある投稿をすべて up し直し。
  • 画像も全部 1つずつ手でアップロード、挿入し直し。

とどめに、あんまり関係ありませんが、夏に向けてサーバのケースを開け、きれいに掃除機で掃除しましたとさ。

いやー休みつぶれたつぶれた。 🙂