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
という設定が書いてあったのでこれを削除することで解決した。
このユーザは私のものではなかったので、きっと本人の誤操作でこういった関連付けの破壊が起こったのだろうと思うが、こういうことがあるにつけ、バックアップはとっておかないとな、と思うのであった。

【LVM】1TBのHDD増設レポ

LVM(Logical Volume Manager)は、パーティションの前後関係やディスク容量を気にすること無く、望むなら二つ以上のディスクに渡ったり別のボリュームを飛び越えてでもボリュームを作ることが出来るツールで、このブログでは一度も言及していないが私はいつもお世話になっている。

今回は、右図のように、1TBのHDD（SATA2）を組み入れる。もともと、ボロボロの80GBのHDD（以下、sdc）がバックアップ用、OSを含むマスターファイルが120GBのボロボロのHDD（以下、sdb）に割り当てられていた。それぞれ、backup、storageというVGを割り当てて管理していたが、今回バックアップが溢れそうになったこと、サーバにデータを置いてnfsで管理する方法を採ることにしたことなどが原因で、新品の1TB（以下、sda）のHDDを購入した。既存の２つはIDEであるうえ、どちらもたいした容量がないため、二つ合わせてbackupとする※。また、アクセス速度と容量を兼ね備えた新品のHDDには、storageの役割をになわせるのが最適だ。つまり

1. sdaをLVMでフォーマットし、
2. sdbのデータをsdaに移行し、
3. sdbをbackupに参加させる

という作業が必要となってくる。自宅サーバであること、当日疲れていたことなどがあり、あまり止めても要られないので、サーバの停止時間は1時間程度に収めたいが、LVMを使用していればOSの再インストールなしでこれらの一連の作業ができた。

※　pdumpfsで、一時ファイルや大きすぎるファイル（動画など）を除外してバックアップしているので、バックアップにはたいした容量は必要ない

1. sdaのフォーマット

このセクションは、新しいディスクをフォーマットしたりするだけなのでサービスを動かしたままで行えるが、運用中のディスクからコピーをとるので、CDブートが望ましい。
ただのフォーマットだが、これが案外ややこしい。sdbをバックアップに降格させるため、sdbのMBRと/bootパーティションをコピーすることが必要になる。
今回の場合は、sdbはsdb1(200MB,ext2)、sdb2(120GB,lvm)となっている。したがって、sda1とMBRだけあればいい。
ここで荒技なのだが、ddを使ってコピーをとる。

# dd if=/dev/sdb of=/dev/sda

これの欠点は、sdbの大きさ分、つまり120GBをすべてコピーしてしまうということ。当然意味が無いので、数秒で止める。すると、コピー速度が出てくるので、sdb1の大きさから、必要な部分がコピーし終わるまでの時間を計算して、その時間待つ。これで、狙った部分のみコピーできる。ちゃんと大きさを指定することもできるが、どうせフォーマット前のディスク、こっちのほうがはるかに速い。
あとは、fdiskでsda2を作成してやればできあがり。sda2はゴミが入っているので、pvcreateに-ff(force)オプションをつける。

# pvcreate -ff /dev/sda2
# vgextend storage /dev/sda2

ここまで終われば、現在VGstorageは現在1.12TBの大所帯になっている。これから、0.12TBを追い出すわけだが、ここからはオンラインではできないので、CDブートで残りの作業を進める。

# reboot

2. sdbからデータを追い出す

現在、storageはsda2とsdb2が使われているが、sdbは一度空にしなければならないので、sdbからデータを追い出す。そのためのコマンドが用意されている：pvmoveだ。

# pvmove -v /dev/sdb2

これで、すべてのLVがコピーされるまで待つ。ddとちがってLVだけをコピーするのでまだ速いが、結構時間がかかるので、-vオプションで暇つぶしをするのは必須。
そして、これが終わったら/dev/sdb2をstorageから脱退させる。

# vgreduce -v server /dev/sdb2

実際には、pvmove終了後からはサービスの稼働は可能と思われるが、念のためこのまま最後まで作業を進めた。

3. sdbをbackupにする

これで、sdb2は宙に浮いてしまった。これを今度はbackupに参加させる。また、backupの唯一のLV「backup01」を200GBまで拡大する。backup01はxfsなので、xfs_growfsコマンドを使えばマウントしたままリサイズすることができる。ひとつ注意点は、xfs_growfsは、デバイスファイルではなくマウントポイントを指定するということ。

# vgextend backup /dev/sdb2
# xfs_growfs /backup

まとめ

以上の行程を踏めば、pvmoveの時間に依存するが1時間かからずにすべての作業が完了する。割とクリティカルな端末でもLVMが効力を発揮できることが実証できたと思う。
ただ、今回のpvmoveは今回初めて使ったので、もしかしたら運用中に実行できたのかもしれない。これが可能ならば、システムを一切止めること無くディスクを増設することができるようになるかもしれない。

重複ファイルを表示「difflatten」

ファイル名などには意味がなく、内容だけに意味があるファイルの集合に、同じルールで適当に集められたファイルをマージする話。（製作動機は後述）

概要

普通、ファイルが同じかどうかはdiffコマンドで調べることができる。

$ diff a.jpg b.jpg

しかし、最初に述べたような状況の場合、diff a.jpg storage/などとはできない。私は「echo storage/* | xargs diff a.jpg」と考えたがこれはstorage以下にディレクトリがあるとうまくいかない。また、一気に多数のファイルの重複を確認しようとした場合、ちょっと頭をひねらなければならない。

そこで、「ディレクトリAとディレクトリBの中のファイルで同じものがあれば、そのファイル名を出力する」スクリプトを書いた。外出っぽいけどちょっと見つからなかったので。

うちのWebページで配布してます。

以下のように実行すると、「A = B」のような行が出てくる。これは、二つのファイルが同じであることを示している。

$ difflatten.rb src/ dst/
src/1880.jpg = dst/images/sky/sunset14.jpeg
src/994.jpg = dst/images/material/takuan.jpg

これを応用すれば、以下のようにするとdst/以下のファイルでsrc/以下にもあるファイルは（dst側から）すべて削除できる。

$ difflatten.rb src/ dst/ | awk -F' = ' '{print $2}' | xargs rm

仕組み

今回はRubyで実装し、ライブラリは標準のものしか使っていない。
まず、src以下を再帰的に走査して、すべてのファイルのサイズを取得し、dst以下を走査して、srcと同じサイズのものがあれば、ダイジェスト（SHA512）で二つを比較している。当初はダイジェストのみで比較していたが、srcに500個、dstに2000個程度のファイルを入れて試したところ37秒もかかってしまった。そこで、まずサイズを比較することで、ダイジェストの計算回数を最小限に抑え、実行時間を0.2秒にまで縮めることに成功した。実際には、dstに同じファイルが２つ無い限り、ダイジェストより直接比較した方が速いのだが、そこまで速度的に不利にはならないと思われる。

動機とか

最近、というかずっと画像収集をしているのだが、あまり時間も裂けないのでとりあえずzipで落としてきて、「うーん」と思った奴は適宜削除、というスタンスをとっていた。しかし結構同じ画像が入っていることが多かったので、自分のコレクションに入れる前に重複を確認するスクリプトを作って既に持っている画像を弾き出そうと考えた。
もちろん、加工されるとハッシュ値が変わるので、本当は画像の類似度などを考慮する必要があるが、補助的には使えると思う。
今回は「削除する」ではなく「重複を表示する」だけに止めたので、いろんな使い方ができるかもしれない。

ちなみに、動作にはruby（作者環境1.8）がインストールされていること、diffなのに同じ物を表示してるじゃん！とか言わないこと、引数を必ず2個与えることが要求されます。

postfixのインストール

月並みなタイトルだけど、Debian Lenny on Niftyな環境でのSMTPサーバであるpostfixのインストール記録。

今回は、自分のメールアドレス（foo@mail.comとする）に対して、サーバ内のroot及び自分のアカウントに届いたメールを転送する設定をする。したがって、POPやIMAPといったメール受信サービスは提供しない。

インストール

aptで済ます。ただし、exim4を削除して入れる場合にはmailutilsパッケージが削除されてしまうようだ。最小構成の場合にはそもそも入っていなかったようだったので、どちらにしても同時に入れておく必要がある。

# aptitude install postfix mailutils

postfixのインストール中に、用途を聞かれるので「インターネット」とする。

設定

/etc/postfix/main.cfを修正。

smtpd_banner = $myhostname ESMTP

（Postfixであることを隠す）

myhostname = toshia.dip.jp

（自分のサーバのFQDN）

mydestination = toshia.dip.jp, server, localhost.localdomain, , localhost

（このドメイン名宛のメールはこのマシンで受ける。myhostnameを追加しておく）

relayhost = smtp.nifty.com

（外向きメールはこのメールサーバを経由させる。上記はプロバイダがNiftyの場合には絶対必要）

mynetworks = 192.168.1.0/24 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

（リレーを許可するネットワーク。LAN内の全マシンがサーバ経由でエラーを通知できるようにしたいので設定した）

そして、/root/.forwardに自分のユーザ名、~/.forwardにfoo@mail.comと書いておけば、rootと自分のユーザに来たメールがfoo@mail.comに転送されるようになる。ただ、エイリアスファイルを作る方法もあり、それはrootでしか設定できないようになっているし、実在しないユーザ(postmasterとか)に対しても転送がかけられるので、そちらを使う方がベターだ。今回は割愛。

これで、rootで実行しているcronのジョブの結果も届くようになるし、その他何かあれば通知がくるようになる。SSHで誰かがログインする度にその旨をメールしてもいいかもしれない。

また、http://www.aconus.com/~oyaji/security/relay-mail.htmで紹介されているサービスを利用して、外部中継チェックを念のためにかけておく。今回はしなかったが、外部からのメール受信をすべて拒否して、メール送信専用にしてしまってもいいかもしれない。

サーバがまた死んだ

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

ちょっと調べても原因がわからなかったので、（この間やったばかりなので覚えているということもあり）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も搭載しているので、やろうとおもえばすぐにできる。

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

Ultimate Boot CD

Ultimate Boot CD

という、ダサすぎる名前のCDを発見した。

「究極の起動ディスク」

・・・実は今回、sda4に残しておいたWindows XPのリカバリパーティションを使おうと思ったのだが、なんとgrubで叩いても起動しない。そこで適当にぐぐっていたらこんなものを発見し、ダメ元で試したらいけたという話。

これを起動すると、

boot:

というプロンプトが表示されるのでエンター。するとメニューが出てくるので、Boot Manager → Smart BootManager 3.7.1と選択。そして、fat32のパーティションを指定すると、なぜか起動できた。理屈はよくわからないが・・・名前に恥じない究極のCDだ。

しかもこれ、パーティションを編集するツールとか、ハードウェアをテストするツールとか、いろいろ入っている。さしあたって必要がなくても、念のため普段からもっておけばいざと言うときに役に立ちそうだ。

※起動しない理由は、パーティションにアクティブフラグとかいうのがついているのが原因らしい。インストールしたらNTFSについてしまい、仕方なくこのCDで起動して使っているが、アクティブって何なのか未だに不明・・・。

VMPlayer + iTunesにご用心

そんな環境でつかっている人、あまりいないと思うけれど。

wineでiTunesがうまく機能しない。

というのは、起動するのだが、あろうことかiPodを認識しないのだ（私はiPhoneだが同じ）。

そこで、当然諦めてVMWare PlayerのWindows XPに逃げるのだが、こちらではあっさり同期もできるし、満足していた。

アップル、iPhone OS 3.0.1提供開始。SMS脆弱性を修正（AV Watch）

iPhone OSのアップデートが先日リリースされた。それで、「アップデートも余裕だぜ☆」と、VM上でやってみたのだが、こともあろうにエラーで止まる。しかも中途半端に書き込んだようで、見事に起動しない。何度やっても同じ。

オワタと思ったがこの記事を参照して、「あぁ、仮想マシンだったらダメなんだ」と納得。時々VMWareでもダメなことってあるものなのだ。

そして、紆余曲折を経てWindows XP HOMEをインストールし、iTunesをインストールしてiPhoneをつないだら動き始めた。

その次は仮想マシン（普段同期とかやってるマシン）から復元。見事に元の環境に戻った。

こんなことに7時間もかかった（窓のインストールが主な原因）。滅多にいないと思うが、同じような環境にいる方は気をつけてください。