Home > PC > サーバ、OS入れ替え、トラブル発生・解決

サーバ、OS入れ替え、トラブル発生・解決

  • Posted by: おりおん
  • PC

うちのサーバAyakoではFedora 8を稼働させていたのだが、少し前にFedoraの最新版Fedora9がリリースされていた。リリース直後に導入するのはさすがにリスクが大きいと考え、少し様子を見ていたのだが、特に大きな騒ぎになっていないようなので、導入することにした。

(以下、長文なのでご注意)

 

念のため、導入前に /etc /var /usr/localといった、カスタマイズや各種ソフトを追加インストールしているディレクトリのバックアップを取った上で、システムHDD以外のHDDの電源コネクタを外し認識させないようにしてインストールを開始。Fedora 8までは、何故かFedoraのインストーラがサウスブリッジ用のata_piixモジュールより先にsata_sil24モジュールを先に導入してしまうので、このようにしないとサウスブリッジ側のSerialATAコネクタに接続したHDDより先にPCI-Express上のSiI3132側のSerialATAコネクタに接続したHDDを先に認識してしまい、後から /etc/modprobe.confを修正して認識順を修正する必要があったのだけれど、、今回のFedora9のインストーラはインストーラの挙動が変わったらしく、このような修正作業は必要なさそうであった。ただし、インストール時に生成された/etc/fstabはパーティションの指定がこれまでのようなラベル指定ではなくUUID指定になっていて、かなりわかりにくい。ま、これまでのやり方でも問題なくパーティション指定できるので大丈夫だけれど。

インストール作業自体は大きなトラブルも発生せず問題なく終了し、各種設定とデータ類の復旧もほぼ終わった。一通りの動作確認について特に問題もなさそうだったので通常運用を開始。ただ、この時点ではいくつかある小さな問題と、大きな問題があったことにはまだ気がついていなかったのである。

大きな問題というのは、このブログへ正しく記事を投稿できなくなっていたという問題のことである。インストール後のデータベースやCGIの復旧の後、いつも使っているBlogWriteで記事を作成し投稿しようとしたのだが、このときに、投稿記事がぐちゃぐちゃに文字化けすることに気づいた。本文だけではなく、タイトルまで含めて完全にぐちゃぐちゃである。しかし、MovableTypeの管理ページから投稿すると、全く文字化けせず普通に投稿できていた。かなり、不思議に思える状況であった。記事投稿自体はできるがかなり不便を強いられる状況なので、何とかして解決しようと考えた。

情報を収集してみたところ、MovableTypeで使用しているMySQLの挙動が少し前に変わり文字コードの設定が複雑化たとのネタがあったので、試しに、MySQLのデータベース側の文字コードの指定を/etc/my.cnfで明確に行うようにしてみた。しかし、これでも文字化けは解消できなかった。設定次第では、投稿記事の文字化けどころか投稿済み記事がすべて文字化けしたり、ブログのタイトルさえ文字化けしたりする状況で、まさに、どうしようもなかった。

この時点で、設定変更で何とかなる問題ではなさそうな気配がしてきた。うちのブログの文字コード体系はShiftJISメインで、これまでも小さな文字化けが発生していたこともあり、思い切って、問題が少なそうなUTF-8化を実行することにした。しかし、これも一筋縄ではいかなかった。この手の文字コード変換について情報収集を行ってみたところ、MySQLのデータベースをダンプしたファイルについてnkfやiconv等で適切な文字コードへ変換を行い、その結果をMySQLに入力して再度データベース化することでコード変換を実現したというパターンが多かったのだが、うちの環境だと、このデータベースのダンプがどうも正しく行えないような感じであった。ダンプしたファイルをUTF-8化し、MySQLに食わせてみたのだが、途中でエラーになる。ダンプしたファイルを確認してみたところ、異常なコードが入ってしまっていたらしく、結果的にエラーになっていたようだ。

データベースのダンプを使った方法もうまくいかない気配だったので、次に使った手は、データベースを含めたMovableType全体の再インストールという方法である。さすがに、これまで書きためたネタを失うわけにはいかないので、一旦、各ディレクトリのバックアップを取った上でMovableTypeの管理画面からもバックアップを実行し、データ類を含めた記事一式をバックアップファイルとして取得しておいた。このバックアップファイルはZIP形式のアーカイブファイルとして取得できるので、一旦、ローカルPC上に解凍し、記事本体が含まれるXMLファイルのエンコードをShiftJISからUTF-8化し、XMLファイルの先頭部分にある文字コード指定もShiftJISからUTF-8へと変更しておいた。この状態で、再度、アーカイブファイルとしてまとめておいた。

サーバ側でも、念のためデータベースのディレクトリ自体をバックアップしておいてからデータベースを文字コードとしてUTF-8を指定して生成し、MovableTypeの方も再インストールし、新たに生成したデータベースを使用するように設定。この状態で、ローカルPCからMovableTypeの管理画面が正しく見えることを確認し、その管理画面から、先ほどバックアップし文字コード変換を行ったバックアップアーカイブファイルを使って復元処理を実行。ここまで実行して、ようやく、管理画面で記事一覧画面が正しく見えるようになった。ただし、何故か、全記事のカテゴリ情報が消滅し全てカテゴリなしになってしまったので、前記事についてカテゴリを再設定する必要があった。また、全てのトラックバックとコメントについて復元できなかった。トラックバックについてはスパムばっかりだったので問題ないとはいえ、コメントが消えたのは少し痛い。あと、テンプレート類も正しく復元できなかったので、以前に使用していたテンプレート類を再インストール。もうひとつ、BlogWriteを使い出す前、ubicast Bloggerを使っていた時期にアップロードした画像ファイルも復元できなかったので、バックアップディレクトリから復旧を行った。

この時点でほぼ復旧できたと考えたので、改めてBlogWriteから記事投稿を行ってみたのだが、今度は、認証失敗してしまい投稿できないという状況になってしまった。この問題については、比較的あっさりと解決。最近のバージョンのMovableTypeでは、記事投稿の際にはユーザのパスワードではなくAPIパスワードが必要なのだが、これの設定がMovableType側とBlogWrite側で合っていなかったことが原因であった。正しく設定を行い、テスト投稿で正しい挙動になることを確認。

こういった経緯があり、まともな状況に復旧できるまでに時間がかかってしまった。久々に、ひやひやした出来事であった。

ちなみに、他の細かい問題というのは、

  • サーバ起動時にNICの起動に失敗する。これも現時点では原因不明だが、起動後にネットワーク周りの再起動で復旧するので、とりあえず様子見。
  • サーバ上にインターネットからファイルをダウンロードすると、そのファイルと同時に不規則な名前のファイルも生成される。このファイルの中身は下記のようになっていて、インターネットゾーンのファイルであることを示しているような気配。現状のSambaのバージョンは「3.2.0-pre3」というテストバージョンらしいので、その影響なのだろうか。

[ZoneTransfer]
ZoneId=3

というもの。ま、しばらく様子見の予定。

Comments:0

コメントする

Home > PC > サーバ、OS入れ替え、トラブル発生・解決

Search

Feeds

Return to page top