![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
Sendmail-PMilterの不具合原因判明。
子プロセスが死んだときに、親プロセスではSIGCHLDっていうシグナルを受けるのだが、 これでソケットの受信処理acceptが中断される。
ここまではいいのだが、中断され、accept()から戻ってきたときの戻りコードが 不適切なようだ。コード上はEINTRっていうコードを検査して処理を行っている ようだが、実際にはEINTRで戻ってこないので、この処理を通過して、 子プロセスの生成を行ってしまう。処理の条件を書き足して対応。
一応開発元にもメールなりしたほうがいいんだろうな。
あと、とってもドキュメントが少ないので、(Sendmail-PMilterではなく) Sendmail-Milterのドキュメントも見ながらコードかかないとダメみたい。
一応計算機ネタだが、Plamoじゃなくてすみません。
今年度も今日で終わり。
昨日書いたsendmailのMILTER (Mail Filtering API)だが、Perlで実装したフィルタ Sendmail-PMilterというのがよさげ (Perlによる実装は、Sendmail-Milter というのがメジャーらしいが、こっちは-Dthread付きでPerlをコンパイルしとかないと 使えないようだ)。
とりあえずサンプルスクリプトは動くようになったんだけど、フィルタ動作後、 負荷の高い状態がしばらく続く。調べてみると、子プロセスを生成→子プロセスが すぐ死ぬ、という状態を繰り返してるっぽい。 PMilterはsendmailとUnixドメインソケットで通信するので、ソケットまわり、 あるいは子プロセスのディスパッチ回りを調べてみよう。
最近はbad knowhowの典型みたいに言われているsendmailだが、 ちょっと変わったことをしてみようとすると、やっぱり一日の長があるのでは ないかなあ、それなりに。
実験に使ってるマシンでは、この他にも
このところ巷ではNetSkyウィルスが流行してますが、 最近発生した亜種のNetSky-Pあたりが昨日からブレーク中(笑)。
対策としては従来どおりのprocmail + 自作スクリプトで対応できて るんだけど、この方法の欠点は外に出ていくメールに対応できないこと。
procmailはMDA (Mail Delivery Agent)なので、各ユーザのメールスプール の直前で動作するため。
で、最悪の場合に備えて、outgoingなメール対策も考えておく必要が あるかな、というわけで、sendmailのMILTER (Mail Filtering API)を 調査中。
Milterって、専用のサイト ( http://www.milter.org/ )があったりするのだけど、 日本語の情報、あんまりないですね。あるのはAmavisとかSpamAssasin とかの既存のフィルタとの組合せのインストール解説がほとんど。
あんまり自分でフィルタ書いてる人っていないのかなぁ。
昨日このサイト見てて気がついたのが「最近のn件」のnが減っているということ。 ついこないだは12件だったのだが、今見ると7件。
どうもページ一覧からはずしているページもカウントしてしまってるらしい。
とりあえず、スクリプト見直してみます。
今、Dilloから書き込み中。
結構いいかも。
多少の制限(Javascriptが使えないとか)を気にしなければ、 メインのブラウザでもいけるかな。特にロースペックなマシンには お薦めです。
てなわけで、Packageをアップしてみました。
会社帰り、自分の車に乗ったら、フロントグラス一面に細かい埃のようなものが‥。
黄砂か、もうすぐ春ですねぇ。
Slashdot Japanへの書き込みのなかにPantra Boxっていう1CDを作ってる人の書き込みがあり、 開発サイトを見てみると、FireFoxをなんとか入れたとか書いてある。
そんなのがことから、そういやDilloという軽量なブラウザがあったなぁと思いだし、現況を調べてみた。
オリジナルでは日本語に対応していないようだが、日本語化は色々と行われているようで、ググッてみたなかでは、てきとーぺえじさんという方(?)のパッチが日本語化以外も色々と統合されているようで中々よさそうだ。
で、インストールしてみる。
おお〜軽い。
実行ファイルも400kBちょい、w3mとほぼ同じくらい。lftpより小さいなぁ。 もうちょい使ってみて不具合なければ、Package作りましょうかね。
なんだか最近PukiPlamoの動作がもっさりしているように感じるんだけど、気のせいかな？ LoadAvgの記録とか見る限りでは、そんなに負荷かかってるわけでもなさそうだし‥。
PlukiWikiって、全てのページデータを単一のディレクトリに置くので、極端にページ数が増えると動作が遅くなるようだけど、現状ではそのレベルには達してないと思う。
2/29の日記に書いたPukiWikiのメール送信プラグインをPukiWiki.orgに登録する。
登録前にはたと気が付いたのが、「Wikiクローンでメール送信フォームをユーザが自由に設置できちゃうと、誰もが匿名のメールを自由に送れちゃう」ということ。さすがにこれはまずいな、と。
で、仕様を制限;
「ページの凍結」というのは、あらかじめ決められたパスワードを入力してページの編集をできなくする仕組み。つまり、これによってメールフォームの設置は、実質Wikiサイト管理者のみしかできなくなる。
Wikiに限らず、セキュリティと利便性のトレードオフには毎度頭を悩まされます。
今度はNetsky-Dですか‥‥。
MyDoomから、一ヶ月ちょいしか経ってないんですけど‥。 しかも今回はこんな話もあって、もうなんだかなぁって感じですが。 まぁ、会社で管理してるメールサーバ以外、自分自身への関わりはまったくないんで、実質高みの見物に近いんですが :-)
しかし、こういうウィルスが流行るたびに思うのが、ウィルス対策製品って、なんかやたら複雑な仕組みで、しかもパターンファイルをその都度更新とか言ってるけど、ほんとにそこまで必要なのかな。 今までの経験から言うと、現在のWindows系OSに感染するメールウィルスを駆除したければ
だけでかなりの部分までOKではないかと思うのだが‥。
もちろんこれで100%OKというつもりはない。一番大きいのは誤検知の問題だろう。現状では上の方法だと、ファイルを自己解凍させるため、EXEの拡張子をもつ添付が送られて来て、そういうのが引っかかる可能性が大きい。
‥しかし、それにしても誤検知後にメールを復旧できるようにしておけばいいだけの話じゃないかなぁ？ どんなもんでしょ？
-- 加藤泰文 2004-03-05 (金) 15:05:06PukiWikiのメールフォームプラグイン書きを継続中。
サイト管理者が(ある程度)フォームの形式をカスタマイズできるようにする部分、 あとフォーム入力のサニタイジング部分を書いている。
最初はまじめにメールアドレスのチェックとかも考えてたんだけど、 調べてみると、
"My name is Kawamata."@foo.bar.jp みたいな書き方も規格上はOKなことがわかり、あえなく断念。 まぁ、文字種のチェックくらいにしといたほうが無難かな。
ついでにサイトを作成したときにPukiWikiに加えた改造も まとめてCVSのリポジトリにインポートして、以後はこっちで管理。
WikiCloneって改造が容易だから、こういうのってあちこちにあるんだろうなぁ、 と思ってみたり。
