2012年3月アーカイブ

FreeBSDからは、cron(periodic)が処理したdailyやweeklyなどの結果のメールが届くのだけれど、ふと気づいたら security run outputのメールは来ているのに daily run outputのメールが来ていない。
なんでだろう?と思ってspamフォルダを覗いたら、見事にspamassassinによってspam判定されていた。
Spam detection software, running on the system "sv.wizard-limit.net", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
The administrator of that system for details.

Content preview:  Removing stale files from /var/preserve: Cleaning out old
  system announcements: Removing stale files from /var/rwho: [...] 

Content analysis details:   (8.3 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 1.7 URIBL_BLACK            Contains an URL listed in the URIBL blacklist
                            [URIs: celebdrop-better.info]
 1.6 URIBL_WS_SURBL         Contains an URL listed in the WS SURBL blocklist
                            [URIs: celebdrop-better.info]
 1.2 URIBL_JP_SURBL         Contains an URL listed in the JP SURBL blocklist
                            [URIs: celebdrop-better.info]
 1.7 URIBL_DBL_SPAM         Contains an URL listed in the DBL blocklist
                            [URIs: celebdrop-better.info]
 1.6 URIBL_SBL              Contains an URL listed in the SBL blocklist
                            [URIs: gorgeous-lovez.info]
 1.1 URI_HEX                URI: URI hostname has long hexadecimal sequence
-1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                            [score: 0.0000]
 0.0 T_URIBL_BLACK_OVERLAP  T_URIBL_BLACK_OVERLAP
 0.0 T_SURBL_MULTI1         T_SURBL_MULTI1
 1.1 TO_NO_BRKTS_PCNT       To: misformatted + percentage
どうも、メール本文に含まれる以下の部分がひっかかったらしい。
Mail in local queue:
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------

・・・(中略)・・・

1C00B295BA8     4434 Sat Mar 17 02:13:49  MAILER-DAEMON
     (connect to mail.celebdrop-best.info[219.255.7.7]:25: Connection refused)
                                         (伏せ).freemail@celebdrop-best.info
・・・(中略)・・・

-- 309 Kbytes in 61 Requests.
本文内のメールアドレスでひっかかるルールにも問題があるような気がするけど、spamassassinのルールは面倒臭くて最近いじってないので、ルールの方はほっておいてmail queue から不要なメールを削除することにする。
postfixでmail queueを削除する方法を調べたところ、
# postsuper -d メールのID(上の例だと1C00B295BA8とか)
のようにするらしい。
そこで、最初はちまちまコマンドを打っていたのだが、61回もIDを打ってられないので、現時点でqueueに残っているのは全て不要なメールと判断して、以下のコマンドで一気に削除した。(これって、普通にpostfixのコマンドでできそうな気がするので、無駄なことをしていると思われる)
# mailq | grep MAILER | sed -e 's/ .*//' | xargs -n 1 postsuper -d
これで、平和が訪れてくれると良いんだけど。
2011年の4月にMacBookProを買ってから、最初にBootCampでWindowsをインストールして、それをVMware Fusionで使っていたのだけれど、最近Windowsが通知領域でライセンス認証がどうのこうのと言い出すようになった。
通知をクリックしてWindowsライセンス認証の画面を開くと、認証が必要だと言うのでオンラインで認証する、を選ぶがエラーになって成功しない。
他の手段と言うのを選ぶと、電話をかけないといけないらしい。
そこで、どうせやるなら正式な方が良いだろうと思って久しぶりにBootCampからWindowsを起動して、フリーダイアルに電話してみた。
機械音声を相手に、ぽちぽちと画面に表示されている長い数字を打ち込む。
やがて、「再インストールなら1を、それ以外なら2を・・・」とか言い出したので、2を押してみると、「オペレータにおつなぎします」と言ってお兄さんに替わった。
そこで、入力した長い数字の最初のブロックを再度聞かれ、今度はお兄さんが読み上げる長い数字を画面に入力する。
入力が終わると、認証に成功した、と出たのでその旨を伝えると、電話を終わろうとしたので「どんなときにこの認証が必要なんですか?」と聞いてみた。 すると、「再インストールしたときとか、構成が変わった時とか」と。 「何も変えてないつもりなんですけどねえ」というと、「構成の変更はシステム内部の問題なのでこちらではなんとも・・・」と言われてしまったので、そこで電話をおしまいにした。
再度Mac OSで立ち上げて、VMwareからWindowsを起動すると、またまたライセンス認証が・・・。
検索してみると、Windows 7はBoot Campと仮想環境での使用は不可になったのか? - りんでん記と言うページを発見。
どうやら、そもそもBootCampとVMwareでWindows7を使うのはライセンス違反らしい。同じマシンの同じ場所にインストールして、同時に使わないんだから良いんじゃないかと思うけど、そこは両者が合意しないと使えないんだからしょうがないのかもしれない。
半年使えてきたのになんで?と思ったが、ときどきVMwareが既存のBootCampの設定を見失って、新しいBootCampみたいに認識してVMware Toolsを再インストールしたりしていたので、それが構成の変更としてカウントされて、ついにWindows認証の堪忍袋の緒が切れたのかもしれない。

この使い方がまずいのであれば、BootCampはほとんど使っていないのでBootCampの方をつぶすしかない。
VMwareの画面でBootCampを選び、インポートを選ぶ。そして、SSDには空きがないので、一度外付けのUSB HDDにインポートする。
インポートが終わったらBoot Camp アシスタントを起動して、BootCamp領域を削除。
今度は、SSD上に80Gのsparse bundle disk image を作成して、そこにインポートされたWindows7をコピー。
VMwareを起動して、コピーしたWindows7の領域を起動する。
前と同じようにフリーダイアルに電話して、再度同じ手続をして、なんとかVMware上でWindows7が復活したのであった。
っつーかさ、プロダクトIDからCDキーがわからないとか、電話で何桁もの数字をやり取りしないといけないとか、Microsoftのライセンス認証の仕組みはあまりに利便性を犠牲にし過ぎだと思うのよね。

2012.3.23追記
別の問題でVMwareのFAQを読んでいたら、BootCampとVMwareの同時使用(同じ場所にインストールした場合)は問題ないとの記述を見つけた。
※ 2011年10月 Boot Camp にインストール・認証済みの Windows OS を、VMware Fusion から呼び出して実行する場合には追加の Windows OS を購入する必要が無い事を弊社よりマイクロソフト社へ確認済みです。
※ この記事は、Mac OS X 10.7.3/VMware Fusion 4.1.1/Windows 7 SP1について書かれています。

会社で使っている Windows Vista(32bit)がいろいろ不都合があって我慢できなくなったので、思い切ってiMacに変えた 。
AppleStoreでCPUだけ Core i7 の 2.8GHz にして、メモリは標準の4GBに、IO-DATAの4G×2を追加して12GBにした。
そして、VMware FusionとWindows7 Pro 64bitを購入して、インストールした。
既存のWindowsで使っていた仕事のファイルは、全てMac上に作った暗号化したsparse bundle image にコピーした。(sparse bundleにした方がTime Machineのバックアップの効率が良いと考えたのだけれど、VMwareのimageとかならともかく、仕事の細かいファイルの場合は意味がない、と言うかTimeMachineで特定のファイルのちょっと前のバージョンを取り出すとかができないことに今気づいた)
このmac上のvolumeをWindowsからVMware Fusionの共有機能を使ってmountした。
そして、VMware上のWindowsにOfficeとメーラを入れて、事務仕事はほとんどWindowsで、開発はVMware上のCentOSやUbuntuでできるようになった。
ここまで前置き1。

続いて前置き2。
プロジェクトの共有ファイルは、svnかdavに置くことになっていて、Windowsのdavの扱いはかなり怪しいのでCarotDAVと言うアプリケーションを利用している。
しかし、Macの場合はFinderの移動→サーバへ移動...でhttp:のURLを指定すれば直接davが開けて、そのまま読み書きができる。
そこでちょっとしたファイルのコピーはMacでやっていたのだが、私がdavに置いたファイルを、他の人が見るとファイル名が文字化けしていると言う。
どうも、濁点/半濁点を含むファイル名を、Macから置くとCarotDAVでは文字化けするらしい。CarotDAVで濁点/半濁点を含むファイルを置いた場合は、Macから正常に読み出せる。
(今にして思えば、こちらがNFC/NFDの問題だったのだが、このときはまだ知らなかった)

さて、いよいよ本題。
ある日、顧客から「サンプルデータ.zip」と言うファイルが届いた。Windows場ではlhaplusと言うアーカイバを愛用している。
いつものようにvmwareの共有フォルダに上記添付ファイルを置いて、lhaplusで展開しようとしたら、ファイルが見つからないと言われた。
Lhaplus-1.png
ここから長い調査がはじまったのだが、前置き2の先入観のせいでてっきり「サンプルデータ」に「プ」と「デ」が入っているのが悪い、と思い込んでしまったせいでなかなか正解にたどり着かなかった

まずは、「mac 濁点」等で調べてみたところ、Mac OS Xの濁点ファイルがやってきた - miauの避難所と言うページがひっかかった。
Unicodeで濁点、半濁点を表すには、「プ」と「フ」+「゜」(\u309a)の2種類があり、「プ」に揃えようとするのをNFC、「フ」+「゜」に揃えようとするのをNFDと呼ぶらしい。
そして、Macのファイルシステム(HFS+)のファイル名は、積極的にNFDで正規化を行い、WindowsやLinuxは積極的には正規化を行わないが、結果としてNFCになっていると言うことがわかった。
っつーか、同じ文字を表すならバイト数が少ないほうが良いと思うんだけど、なんでMacはNFDを採用したんだろうか。
Macのターミナル上ではzshを使っているのだが、zshはこのNFC/NFDの正規化を行わないらしく、「サンプルデータ.zip」と言うファイルがあると、以下のような挙動をする。
  • ls サンプルデータ.zip → ヒットする
  • ls サンプ<TAB> →補完されない
  • ls サンフ<TAB> →補完されるが、「サンフ<309a>ルテ<3099>ータ.zip」と表示される
同じディレクトリを、Windowsでdir /bで見てみると、上記サイトと違い、濁点/半濁点は別れずに表示された。(この段階でも気がつくべきだった)
再現テストを繰り返すうちに、以下のことがわかった。
  • サンプルデータ.zip → lhaplus で展開できない
  • プ.zip → lhaplusで展開できる
  • longlongarchive.zip → lhaplusで展開できる
  • サンフルテータ.zip → lhaplusで展開できない
どうも、今回の問題はNFC/NFDの問題ではないらしい。上記参考サイトの場合は、Macから受け取った添付ファイルに含まれていたNFDのファイル名を問題にしているのであり、今回のようにMacのVolumeをWindowsからマウントした場合の問題ではなかった。
そもそも、Windouwsにマウントした時点で、ファイル名の文字コードはUnicodeではなくMS932になっているので、その段階でNFCの正規化が行われているらしい(推測)

振り出しに戻って、じゃあ何が原因なのか考える。再現テストの結果からわかることは、ファイル名に非ASCIIが含まれている時かつ、8.3文字を超えているとき、に問題が発生すると言うこと。
そこで、8.3 filename - Wikipedia, the free encyclopediaなどを読んでいると、dirコマンドに /x とか /-n とか言うオプションがあることを知る。
早速、問題のディレクトリで実行してみると、
2012/03/25  07:46    <DIR>                       .
2012/03/25  08:25    <DIR>                       ..
2012/03/24  22:15               131 LONG~CDD.ZIP longlongarchive.zip
2012/03/24  08:18               134 サンプ~~B2E.Zサンプルデ.zip
2012/03/24  08:18               134 サンプ~~B44.Zサンプルデータ.zip
2012/03/24  08:18               134              デ.zip
のように表示された。
詳しい原因まではわからないが、lhaplusにこの辺のLFNからSFNへの変換(もしくはその逆)の問題があるのかもしれない。
とりあえず解決策を探そうと思って、VMwareの共有ではなくてMac OS X のsmb共有を使ってみた。
すると、lhaplusでも展開に成功した。
dir /x を実行してみると、
2012/03/25  07:46    <DIR>                       .
2012/03/25  08:25    <DIR>                       ..
2012/03/24  22:15               131              longlongarchive.zip
2012/03/24  08:18               134              サンプルデ.zip
2012/03/24  08:18               134              サンプルデータ.zip
2012/03/24  08:18               134              デ.zip
のようにLFNのみが表示された。
いまいち良くわからないけど、Mac OS X のsmb共有を使っておけば問題ないってこと?
ここのところ、ずっと /var/log/messagesに perl が core を吐いたと言うメッセージが出ていた。
調べてみたところ、plaggerで落ちてる。
core ファイルができているので、gdb で bt を見てみたところ、libxml2を使っているperlのライブラリあたりで、リソースの解放あたりで落ちてる。
不思議なことに、ログインして手動でplaggerを起動すると落ちなくて、cronから起動すると落ちている。
何が原因かわからなかったけれど、とりあえず該当のperl moduleとか、perlとかをアップデートしてみたけど改善せず。
どうせだから〜と、portupgrade p5\* とかやってperlのモジュールを全てアップデートしてみた。
すると、plaggerが以下のエラーで落ちるようになった。
Plagger::Plugin [debug] Load YAML .../plagger/trunk/assets/plugins/Filter-EntryFullText/cookpad.yaml
Cannot decode string with wide characters at /usr/local/lib/perl5/site_perl/5.8.9/mach/Encode.pm line 176.
良くわからなかったが、pluginのFilter::EntryFullTextで落ちてるっぽいので、yamlをいじってEntryFullTextを外したら先に進んだ。
そして、最後にStore::FastladderでDBに入れる所で、
Plagger::Plugin::Store::Fastladder::Schema::Members::subscriptions(): No such relationship 'subscriptions' on Members at .../plagger/trunk/lib/Plagger/Plugin/Store/Fastladder.pm line 73
と言って落ちている。
どうも、DBIx::Class周りが、最近(ってほど最近でもないらしい)のバージョンでは挙動が違うらしく、その辺で落ちているらしい。
DBIC で後付けの relationship を定義してたらうまく動かなくなった - daily dayflowerとか見つけて、Store/Fastladder/Loader.pmあたりを触ろうと思ったけど、やはり読んでも良くわからず。
途方にくれて彷徨っていたら、そのものずばりryu22eBlog : DBIx::Class 0.08121ではPlagger::Plugin::Store::Fastladder 0.01が動かないのでアドホックなパッチを書いたと言うページを発見。
このパッチをあてたら、無事にplaggerが動き出した。
ここに来て再度plaggerのログを良く見たら、
Plagger [info] plugin Plagger::Plugin::Store::Fastladder loaded.

Dynamic schema detected, will run in 0.04006 mode.

Set the 'naming' attribute or the SCHEMA_LOADER_BACKCOMPAT environment variable
to disable this warning.

See perldoc DBIx::Class::Schema::Loader::Manual::UpgradingFromV4 for more
details.
なんて出てた。
さっそくperldocで該当箇所を読んでみたけど、ちんぷんかんぷんで理解できなかった。
自分の頭が大丈夫か不安になる。

しっかし、perlをバージョンアップするたびに portupgrade p5-\* とかやってたはずなのに、どうして今頃になってこの問題が表に出てきたんだろうか。
2012年3月
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

このアーカイブについて

このページには、2012年3月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2012年1月です。

次のアーカイブは2012年4月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

Powered by Movable Type 6.1.1