gnome-openが適切な関連付けを忘れてしまった件

なぜか、gnomeの「場所」からディレクトリを選ぶと、RhythmBoxが起動してしまう。しかしデスクトップなどでディレクトリをダブルクリックすると正常にディレクトリは開くことができ、そこから別のディレクトリにいくこともできる。
また、端末からnautilusを起動すると正常に起動できた。すなわち、gnome-openが諸悪の根源となっているらしい。というわけで、

gnome-open ~/Documents/

RhythmBoxが立ち上がった。どうやら関連付けが間違っているらしいので、今回は修正方法を調べた。
参考：Ubuntu 8.04でgnome-openの関連付けを変更する
ここに書いてあることがすべてだが、私の場合なぜか
.local/share/applications/mimeapps.list
というファイルに
inode/directory=rhythmbox.desktop
という設定が書いてあったのでこれを削除することで解決した。
このユーザは私のものではなかったので、きっと本人の誤操作でこういった関連付けの破壊が起こったのだろうと思うが、こういうことがあるにつけ、バックアップはとっておかないとな、と思うのであった。

サーバがまた死んだ

この間の豪雨の際、雷で三回ほど瞬間停電したのだが、どうやらこの間にサーバのデータが壊れていたようで、起動不能になった（起動中にエラーを吐いてランレベル６に移行するのだが、そっちでもエラーを吐いて止まる）。

ちょっと調べても原因がわからなかったので、（この間やったばかりなので覚えているということもあり）Debian Lennyを再設定することにした。

ApacheとSubversionのインストール（ + ApacheのWebDAVを使ってSVNを動かす）

必要なパッケージのインストール

# aptitude install subversion libapache2-svn

libapache2-svnをインストールした時に、apacheのdavというモジュールが有効になる（apache2をパッケージで入れた場合、無効になっているだけで既に入っている）。

# mkdir /var/svn

# svnadmin create /var/svn

# chown -R www-data:www-data /var/svn

リポジトリを作成する。ただし、ここでリポジトリの所有者をapacheにしておかなければならない。

以下の内容を/etc/apache2/conf.d/以下に適当な名前（svnなど）で作る。

<Location /svn/miku>
DAV svn
SVNPath /var/svn/miku

Order Deny,Allow
Allow from 192.168.1.0/24
Deny from all

</Location>

Order ~ Deny from allまでは、192.168.1.*しか許可しないという意味になるので、外からのリポジトリへのアクセスを一切拒否している。外からアクセスしなければならない時はSSHでトンネルを張れば良いだけのことなのでこれで十分。なお、ローカルからもトンネル経由でないと許可しない、という設定にする場合は、Allowのところにlocalhostと書いてもいいかもしれない。いずれにしろ、SVNはソースコードなどの重要なデータがインターネット上を流れるので、SSH、VPN、SSL等で暗号化するのが望ましい。

ここまでの設定を確認。ローカル（別のPC。別に同じマシンでも可）にてチェックアウト。

本当はインポートとか使うんだろうけれど、普段やり慣れている方法でやってしまうよね（その方がミスが少ない・・・成長を妨げる要因だ）。

$ svn checkout http://server/svn

$ cp -ra /path/to/original svn/

$ svn add svn/*

$ svn commit

コミットできたら一応成功。

コミットしたら公開

こういうのを何て呼ぶのかは忘れたが、リポジトリのhook scriptを触れば実現できた。

/var/svn/hooks/post-commitに以下のように書く。

#! /bin/sh

/usr/bin/svn export --force file:///var/svn/ /var/www/

post-commitはコミットが成功した後に実行されるコマンドなので、この中にエクスポートするコマンドを書いておけばいいのだ。

これで、コミットの度にファイルが/var/wwwにエクスポートされるようになった。

eRubyを有効にする

参考：　eRuby(mod_ruby)のインストール方法

RubyをPHPみたいに組み込みっぽく使いたいので（というか我がWebサイトで使っているので）eRubyを導入する。普通のHTMLのように書けるが、の間に書いた文章はRubyスクリプトとして実行される。

このインストール作業が意外と面倒。

# aptitude install euby eruby libapahe2-mod-ruby

まずは普通にインストール。

そして、/etc/apache2/mod-enable/ruby.loadに以下を追記（参考サイトからコピー）。

<IfModule mod_ruby.c>

RubySafeLevel 1

RubyRequire apache/ruby-run

RubyRequire apache/eruby-run

<Files *.rhtml>
SetHandler ruby-object
RubyHandler Apache::ERubyRun.instance
</Files>

</IfModule>

なお、私の場合はRuby Script内でファイルの最終更新日を調べているが、これはsafe levelが0でなければ動かないらしい。なんだか気味が悪いが、とりあえず0にした。

これだけでは、*.rhtmlをクリックしてもファイルダウンロード画面になってしまう。原因は、Live HTTP Header等で調べれば一目瞭然だが、MIME Typeが「application/x-httpd-eruby」というよくわからないものになっている（通常、text/htmlになっている）。これを正すために、/etc/mime.typesにちょっと手を加える。

以下のような行があるので、その行頭に # （コメント）をつける

application/x-httpd-eruby rhtml

これで完了。なんでも、eRubyがこういう風にmime typeを決め打ちされることを想定していないらしい。

これで私の環境復元は終了したのだが、6月、8月と二度も立て続けにクラッシュしたという事実をみすみす見逃してはいられない。あまりにもばかばかしいことだが、一応まとめると：

• 停電対策（UPS）がまったくなされていない
• バックアップサーバ自体のバックアップは取られていない

という問題があった（というか、ある）。

まず、UPSは雷の多い地域なので見当の余地はあるが、お金のかかることなのですぐには手は出ない。

問題は二つ目である。これは絶対にやっておくべき対策で、今すぐにでも手を打つべきだ。いままでやってなかった理由としては、「HDDの空き容量がないよ！」だったのだが、今やサーバにHDDを４台ほど積めるスペースがあり、バックアップ用HDDも搭載しているので、やろうとおもえばすぐにできる。

異常気象とはいえ、組んだばかりのサーバをあまり痛めつけてほしくないものだ。

Emacs22の文字コード判別の頭が悪い

Emacs22から文字コードの判別にmule-ucsを使わなくなり起動が早くなったらしいが、そのせいで時々文字コードを間違えるようになったみたいだ。
写真は、二行目に「初音ミク」と書いてutf-8で保存されたものを開いた時のスクリーンショット。ステータス行を見ると、Shift-jisと誤認していることがわかる。こういう時は、C-x RET c utf-8-unix RET C-x C-v RETとタイプすればUTF-8で開き直せるが、あまりにも長すぎる。
以下のような行を入れておくことで、そのファイルの文字コードを指定できる。

# -*- coding:utf-8 -*-

（#はコメント。言語に合わせてセミコロンなどでも良）
これがファイル内にあれば、utf-8でファイルを読み込んでくれるようになるのだが、いちいち全部のファイルにこれを書くわけにはいかないし、何より読み込んでからでは遅い。

coding-category-listという変数の中に、文字コードの優先順位が書いてあり、先頭のほうが優先順位が高い。

coding-category-list
=> (coding-category-iso-8-2 coding-category-iso-7-tight coding-category-sjis coding-category-iso-7-else coding-category-iso-8-1 coding-category-utf-8 coding-category-utf-16-be coding-category-utf-16-le coding-category-iso-7 coding-category-iso-8-else coding-category-emacs-mule coding-category-raw-text ...)

確かに、coding-category-utf-8より前にcoding-category-sjisがある。
この優先順位を上げてやるといいらしい。以下の式を評価してから、問題のテキストファイルを開く。

(prefer-coding-system 'utf-8-unix)
=> (mule-utf-8 . mule-utf-8)

図のように、無事にutf-8と認識するようになったので、これを~/.emacs.my.elに追記しておく。
どうやら、coding-category-listを最初から順番に試していって、最初にファイル内全てを文字として表現できたものを問答無用で使うようになっているらしい。

# しかし、初音ミクで化けるとは・・・。