[FrontPage] 更新履歴 - サイトマップ - "ZopeWithDaemonTools" 配下のコンテンツ - 過去を発掘 | [Snap.Shot]

to FrontPage ZopeWithDaemonTools

(Wed, 30 Apr 2003 06:17:19 GMT+9)

Zopeを(DJBの)daemontoolsと共に使う

ごめん、既にJZUG-MLへ投稿する気力がないのでアレなのだけど、ウェブ経由で 見てしまった ので。 わざわざ再登録して投稿するほど心が広くないので、適宜だれか拾って投げてくれ…

ハッキリ言ってdaemontoolsなんて使うのは自殺行為。 なぜかというと、プロセスが落ちてから、それが再起動するまでの間隔が、わずか一秒しかない。 これは、一時的な高負荷状態から回復するのを妨げるので、全くもってよろしくない(経験者は語る)。 configで変えられるのかとも思ったのだけど、そうじゃないみたい。つまりプロセス監視ツールとしては論外。

DJB系のツールは、どれもそれなりに軽いのでなんとかなるかもしれないけど、それでもDoS弱い 強くないって知ってた? マイナーだけど、SecurityFocusにも事例があったはずだ。 ましてや、重たいZopeで使うなんて、とんでもない。

堅牢なBSD系のOSでも回復を待つのは容易じゃないと思う。Linuxで電源を触れるのであれば、 素直に諦めて電源を入れ直すべき(ワタシはそうした)。Solarisは言うに及ばず、だ。

余談 : NT?2000?XP?だって、毎日リブートしてるでしょ?(以下略)

もとよりZopeが落ちないためには、祈るよりほかない(これはZopeやPythonを責めるのは筋違いだと ちょっとだけ思うが、でも落ちないことを確実に保証できない)。一方のPerlやRubyは、死ぬときは まず間違いなくプロセスごとフリーズする(socketまわりのタイムアウト処理をALARMに頼っている、 一部のクソプログラムだけかもしれないけど)ので、実装としてはPythonのほうがまだましだと思って いるけど、少なくともdaemontool経由では二次災害を引き起こす可能性大。

DoSからの回復力は落ちるかもしれないが、再起動間隔を空けることで、少なくとも同一ホストで 稼働しているサービスへの影響は免れる。つまり、二次災害を防げるのだ。 もちろん、そこまで心配しなくても守れる設計(Zopeの稼働条件を下げたり、別サービスが影響を受けないように したり)ができていれば尚良いのだけど、最近Zopeを使い始めたひとは、そこまで全く考えていないよね、たぶん。

さらに余談 : じゃぁJava系とかColdFusionとか思う?かたまらない自信があるなら採用しなさい。 少なくともワタシは、どちらも固まった事例を知っている。

訂正 2002-05-30 takano : …ということで、わしは独自スクリプトで監視していたのだけど、 これ実はz2.pyの-Zオプションを指定することで、Zope自身が監視プロセスつくってforkしてくれてたんだそうだ。 しらなかったよー、ばかー、まぬけー<自分

もちっと訂正 2002-05-30 takano : DJBがDoSに弱いというのは言いすぎなので「強くない」に訂正。 tcpserverでオモテを制限すれば、外からの攻撃にはそこそこ耐えるかも。 SecurityFocusにあったやつは、どうやると書いてあったんだっけなぁ。忘れてしまった。

2002-05-31 Moo : はじめまして。そのページの筆者です。自分はたまたま海外のサイトでこの方法を見つけ、 JZUG MLで希望があったので自分のサイトに書いてみたんですが… 削除した方がよろしいでしょうか?

6-2 takano : SecurityFocusの記事あったぞ。QMail RCPT DoS Vulnerability だそうだ。補足しとくと、DJBの言い分は「ユーザリソースを無尽蔵に与えるほうが悪い」とのことで、 qmailのバグではないと主張しているみたいだ。 ulimit -d 1024 とかやって、ヒープは1MBくらいにしとけと。 …つまり、アプリケーション利用者は、その消費メモリも予期しとくべきであるとのことである。 DJBマンセー (精一杯の皮肉を込めて)。

  HelpPage メールでコメント

© 2000-2013 Yukimasa TAKANO, all RIGHTs reserved.