| ■ あまつぶWiki □ あまつぶ過去ログ □ Macソフト □ Winソフト □ 掲示板 □ | |
| ＜カレンダー＞
2003 | 09 | 10 | 11 | 12 |
2004 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 12 | 2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 2009 | 01 | 02 | 03 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 2010 | 01 | 03 | 04 | 05 | 06 | 07 | 09 | 11 | 2011 | 02 | 07 | 08 | 11 | |
[Diary]名古屋情報セキュリティ勉強会 #2
[POPFile] POPFile 1.1.2 が公開されました。 [Diary] Lion メモ [Diary] Adblock Plus で特定の要素を非表示に 雪！ geko のファームウェアアップデート Bad Elf GPS 購入 やっと届いた！ 整理券げっと 135 |
無事帰宅しました。
講師のみなさん、おつかれさまでした。たくさんのお話が聞けて刺激を受けました。最後はちょっとばたばたとしてしまいましたが、大変いい機会をいただいて、楽しめました。ぜひ定期的に集まりたいですね！
スタッフのみなさんも、タイトなスケジュールの中でいろいろと調整をいただき、ありがとうございました。
参加者のみなさんもご清聴ありがとうございました。自己紹介の雰囲気では、メールサーバの管理をされている方が多く、クライアント系の POPFile の話がどれだけ参考になったかはわかりませんが、何か役に立つことがあれば幸いです。
とりあえず資料あげておきます（OOo Impress 版／PDF 版）。もう少しネタをしぼるべきだったかなと反省です。
それにより、次に向けてなんか新ネタ仕込まなくちゃ… という心理的圧迫を作るのが目的の一つだったりしますし。
「肉リリース」みたいなみんですね。
せいぜい95%くらい選り分けれる学習済みコーパスを提供してはどうでしょうか。
僕らはメール数が多いので、学習もすぐさせることできますが、メール数が（スパム・ハム共）それほどでもない人は、なかなか学習が進まなくて、学習が進む前に飽きてちゃんと使わなくなるとか、あるかなと。
でもスパムがたくさん来てて困ってるからPOPFile導入するわけで、そんなこともないのかな？とも思いますが。
そうですね。モチベーションの維持にもつながりますよね。私も話すネタを作らないと。
肉リリース、いいですね（笑） 月一は厳しそうですが、私も何か新しいことに取り組もうと思いました。
既存のメールから簡単に学習させるツールができれば、サンプルのメールとの組み合わせでもいけるかなと思いました。
サンプルだけを使ってもいいし、受信済みのメールを追加してもいいという感じで。
XMLRPC インターフェースを使えばそれほど難しくはなさそうなので、考えてみます。サンプルメールを用意するのが難しそうですが、うまくいけば次回のネタに……（＾＾；
で、POPFileのサーバ版をそういうコメントスパムやWikiスパムのフィルタリングにも使うっていう需要、結構ありそうに思うんですがどうでしょ？
次回のネタに向けて :)
PukiWiki使ってる人ってレンタルサーバの人が多いので、POPFileをデーモンとして起動して独自httpd経由で利用する、というような運用出来ない場合が多いのです。
なので、POPFileをCGIとして呼び出せるように改造してるような実装どっかにないかな〜、と探したんですがなくって。
さすがにこれは即解決とはいかないか…
POPFile には、コマンドラインから動かすユーティリティスクリプトがいくつかありますので、そのあたりを改造すれば比較的容易に実現できるのではないかと思います。近いのは bayes.pl ですかね。
http://getpopfile.org/docs/jp:utilityscripts:bayes
入力の部分は、標準入力からの方がいいかもしれませんので、そこは pipe.pl が参考になるかもしれませんね。
http://getpopfile.org/docs/jp:utilityscripts:pipe
CGI からだとどういうインターフェースがいいでしょう。
確かbayes.pl/pipe.plってXMLRPC呼んで判定したりしてるんじゃなかったでしたっけ？そこのソース見て、こりゃ簡単、と思ってPukiWikiからの呼び出しを試した記憶が有ります。
判定に回す部分は、スパム判定用のプラグイン的なモノをつくってやり、そこからXMLRPC呼び出して行うということでいけるので、その点についてはPOPFile側の修正は現状のままでいけると思います。
スパムコメントの管理、つまり投稿されたものをスパム・ハムに選り分ける部分をPOPFileのWebUI使ってやりたかったのですが、そのあたりはどうしたら良さそうでしょうか。
POPFile の UI を使うには、やはり POPFile をデーモンとして動かしておく必要がありますので、そのまま使うのは難しいと思います。
投稿されたコメントは別に管理しておいて、学習させるのは insert.pl を使うというのではどうでしょう。
http://getpopfile.org/docs/jp:utilityscripts:insert
XMLRPC で学習させるツールを作りかけていますが、結構おもしろいですね。ドキュメントに書かれていない（書き忘れ？）コマンドなんかもあるので、一度そのあたりもまとめてみようかなと思っています。
意外とあっさり動いてしまって驚きましたが、結構おもしろいですね、これ。
とりあえず、投稿したメッセージにちょっとしたヘッダを加えて bayes.pl で判定させるもの。
http://amatubu.skr.jp/popfile/test/post.cgi
(ソース)
http://amatubu.skr.jp/popfile/test/post.pl
insert.pl も問題なく動きますね。
あまり考えたことはなかったですが、この使い方はいろいろと使えそうですね〜。
なんか自分の書いたテストコードが出てきたんでみたら、やっぱXMLRPC呼んでやってました。短いんで、ここにそのまま書けるかな？
#!/usr/bin/perl
use strict;
use XMLRPC::Lite;
my $sk = XMLRPC::Lite ->proxy('http://localhost:8081/RPC2')
-> call('POPFile/API.get_session_key','admin','')
-> result;
print "session key: $sk\n";
my $word_count = XMLRPC::Lite ->proxy('http://localhost:8081/RPC2')
-> call('POPFile/API.get_word_count', $sk)
-> result;
print "word count: $word_count\n";
my $spam_classify = XMLRPC::Lite ->proxy('http://localhost:8081/RPC2')
-> call('POPFile/API.classify',$sk,'/home/stealth/spam.txt')
-> result;
print "spam classify: $spam_classify\n";
XMLRPC::Lite ->proxy('http://localhost:8081/RPC2')
-> call('POPFile/API.release_session_key',$sk);
でもやっぱこれだと、デーモンとして立ってなくっちゃいけないから、レンタルサーバだと使いにくいですね。
やっぱりCGIとして使えるように、amatubuさんのテストコードみたいな方向で進めたほうが良い感じです。
CGIからどっかの関数叩いたら、POPFileのUIが表示される、みたいな便利なのってないですかね :)
そうですねー。
UI の表示は、UI::HTML で行っていますが、基本的にデーモンで動いていることを前提にしているのでそのままではうまく動かないですね。
モジュールをちゃんと初期化してあげて、UI::HTML の url_handler__ を呼べば UI の HTML ソースが得られるので、リンク先などを加工しつつ表示してあげればいけそうですが、すべてうまく動くようにするのはなかなか大変そうです。
でも、UI使わなければ利用出来そうだから、管理者がspam/hamの判定だけを行えるようなUIだけ用意できれば、いけるのかな？
とりあえず、試しにうちの掲示板に設置してみました。
http://amatubu.skr.jp/treebbs/treebbs.cgi
上でテストしていたものを既存のCGIに組み込んだという感じなので、まだまだ汎用というわけにはいきませんが、とりあえずは動いているようです。
ちょくちょく spam 書き込みが来ていますので、２、３適当に学習させてみました。普通の書き込みの情報があまりないので、うちでメールの判定用に使っているデータベースをそのまま使ってます。
しばらくテストして様子を見てみようと思います。
UI を使わなければ、比較的導入は容易だと思います。必要となるファイルも少ない（最低限必要なのは、Classifier フォルダと POPFile フォルダ、それと使いたいスクリプト（bayes.pl とか）で、それ以外はなくても動きます。
もう少しまとまったら、簡単な使い方を書いたり、判定や学習をさせるための汎用的な Perl モジュールを作成したりしてみたいと思います。
POPFileのUIが使えない場合、誤判定したコメントをどうやって救済するか、救済用の仕組みを別で考えなくちゃいかんので、それを各コメントCGI毎に書かないといけないから、なんとか出来れば、と思ってました。
でも結局、救済したものを再度コメントに反映させるには、やはり各コメントCGI毎に実装しないといけないんで、手間は同じかもしれませんね。
あ、スパム判定された場合、CAPTCHA出すようにして、それ抜けた場合には、誤判定だったとして、ハムとして学習させればよいのかも。
それだったら事前フィルタとして汎用的なものが書けそう。
一応、UI は使えないものの、POPFile のデータベースに履歴としてつっこんでいくことは可能だと思いますので、それを表示させて学習させるインターフェースという感じであれば汎用的にいけるかもしれません。しかし、コードが複雑になるのが難点ですね。
おお、それいいですね〜。＜CAPTCHA と組み合わせ
自動的に救済されるようになれば管理する側も楽ですもんね。また考えてみます〜。
これだとreCAPTCHAのAPI呼ぶだけなので簡単です〜
Perl にも Captcha::reCAPTCHA というモジュールがあるようなので試してみようと思います！
プラグインのような形にできると一番いいのかなと思うのですが、そのあたりの知識がまったくないので、とりあえずは汎用的なモジュール（判定させる、学習させるだけ）と、実装方法をまとめたドキュメントの提供あたりでいこうと思います。