社内サーバーでテスト中のEC－CUBEで作ったサイトの見た目が微妙におかしい。という連絡を受けまして色々調べました。 結果にたどり着くまでには色々と苦労があったのですが、要はdata/Smarty/template_cディレクトリに古いファイルが残ってたのが原因でした。ということでdata/Smarty/template_c配下をばっさりと消去して無事解決しました。 しかし、なぜtemplate_cに古いファイルが入ってたのか、移行前はそんな問題なかったのにと不思議に思い移行時の手順を思い出してみました。 破損ファイルが含まれているかもしれないディレクトリ全体をコピーしてくるよりはSubversionで管理されているファイルに関しては、ある程度の整合性は保障されてるかなと思い、まず、新しい環境で最新リビジョンをチェックアウトしてから、管理外のファイルだけをrsyncを駆使してコピーしました。 ここで気づきました。要はSubversionにtemplate_cの中の古いファイルがコミットされてたのです。つまりチェックアウト時に古いファイルが配置されてしまっていたのです。サーバー側のファイルはアップデートしかしませんから、リポジトリより実際のファイルが新しい分には問題が出なかったわけですね。 サーバー移行時にはキャッシュを消しましょうなんて常識的なことを忘れていたため、30分も無駄にしてしまいましたorz

社内サーバー（CentOS4.6）のHDDが壊れかけていた（IOエラーが発生して強制的に読み取り専用モードでマウントされる）ため、昨日は1日復旧作業に費やしました。 その復旧作業の中で詰まった点などを書いておきます。たまたま自分の環境でうまくいっただけかもしれませんので、ここに書いてあることを真似するときは自己責任でお願いします。 １．新マシンに旧マシンのHDDを繋いでも普通に起動する これは壊れかけてるHDDにトドメを刺すことになるかもしれないし、こんなことしなくでもデータの吸い出しはできるので、全くおすすめしない方法ですが、Linuxでは特殊な構成のハードウェアで無い限り、他のマシンのHDDを移植しても起動時にハードウェアの変更が自動的に検出されて、いくつか質問に答えるだけで普通に使える状態で起動できるようです。 今回、fsckを何周かさせてエラーが落ち着いたので、試しにやってみたのですが、旧マシンが昔Dellで買ったCeleron（多分Northwood以前）＋インテルチップセットのマシンで、新マシンがVIA PC1500という、Windowsだったらドライバの問題で確実にまともに動作しないだろうなという組み合わせでも普通に元マシンの環境が新マシンで立ち上がりました。 あと、旧マシンは再利用頻度の低いファイルの置き場所として使ってたり、Subversionサーバー（つまり作業コピーがどこかのクライアントに存在する）として使ってたり、今回は消えたらアウトなファイルが無かったため、fsckを掛けまくりましたが、普通はそれでいくつかファイルが消えたりするし、今回もその課程でいくつかのファイルが実際に消えたので、まったくおすすめできません。 ２．旧マシンのHDDをマウントするにはちょっと操作が必要 普通は１．の操作をするよりこの操作をした方がサルベージしやすいと思います。新マシンに新しいHDDを取り付けてCentOS5.2をインストールし、旧マシンのHDDをセカンダリに取り付けてマウントしようとしたのですが、普通にはできませんでした。つまり # mount /dev/hdb2 /mnt とかの操作ができませんでした。で、色々調べたのですが最近のRedHat系はLVMという、パーティションの中にさらに仮想的にパーティションを切るような方法でインストールされるらしく、そのLVMの中身をマウントするには少々操作が必要になります。 基本的には、LVMの中のパーティションをアクティブにし、# mount /dev/VolGroup00/LogVol00 /mntみたいな感じでマウントできるのですが、デフォルトのままLinuxをインストールしてると、起動中のHDDとマウントしたいHDDでボリューム名が両方VolGroup00とかでかぶってしまい、操作できません。 ということで、HDDのボリューム名を変えるには、まず、変えたいHDDのUUIDを調べて、そのUUIDを指定してボリューム名を変更するコマンドを実行します。具体的には # vgdisplay— Volume group —VG Name VolGroup00・・・省略・・・VG UUID mK5km2-IgeS-IJN9-wz4i-kR6T-6d6n-ozxFqe # vgrename mK5km2-IgeS-IJN9-wz4i-kR6T-6d6n-ozxFqe OldVolGroup00 くれぐれも稼働中のボリュームの名前を変えないように！多分エラーが出て実行できないとは思いますが。 あとは以下のようにしてアクティブにし、マウントするだけです。 # vgchange -ay OldVolGroup00# mount /dev/OldVolGroup00/LogVol00 /mnt 最初LVMの存在さえ知らなくてちまちまと外付けHDDにコピーしてしまいました。それ自体がバックアップになるから無駄じゃないけど、時間がすごいかかった。 ３．MySQLの移行は簡単 /var/lib/mysqlをコピーしてくるだけで動作しました。オフラインの移行は超簡単です。オンラインは気を遣いますけどね。 ４．Subversionの修復 リビジョンが1600弱に達してるリポジトリがあったのですがどうも1450あたりのリビジョンデータが破損してるようで、svnadmin dumpでもエラーが出てダンプできませんでした。 たまたま、リビジョン0-1500までのダンプデータがあったのでそれを使いsvnadmin loadした後# svnadmin dump /path/to/repos -r 1501:1600 –incremental [...]

何か以前も同じタイトルで書いたような気がしますが、そのときは確か権限の問題で、svnserveをroot権限で実行するという苦肉の策で回避した覚えがあります。 今回もまた、何かの拍子にupdateされなくなった訳です。とりあえずログを見てみると svn: 有効な UTF-8 のデータ(16 進数: c5 b9)の後に無効な UTF-8 文字列(16 進数: c6 e2 a3 b1)があります というエラーが。日本語のファイル名が含まれているからだろうなとは思いましたが、具体的にどのファイルかは分からず。今まで日本語のファイルで問題は出てなかったので、どのファイルが問題を起こしてるのか見当もつきません。 sshでログインして直接updateすると何のエラーも出ず正常に終了します。 いろいろ調べてたら、svn upの前にLANG=ja_JP.UTF-8を付けると良いよという情報が。早速post-commitを書き換えてみてテストしましたが、やはり同じエラーで正常にupdateされず。 どうしたものかな～とちょっと途方にくれながら、sshでログインし、何気にenvコマンドを実行してみたら、なんと、LANG=ja_JP.UTF-8ではなく、LANG=ja_JP.eucJPになってました。 ということで、post-commitのsvn upをLANG=ja_JP.eucJPで実行するように書き換えたらうまくいきました。 とりあえず、post-commitに限らずこれからシェルスクリプトを書くときは、冒頭にexport LANG=ja_JP.eucJPとか、envコマンドで返されるLANGの値と同じものを書いておこうと思います。