Zope とプロダクト

Zopeやプロダクトに関する話しはここに書きましょう。 なお当ボードは Zope.org とは一切関係ありません。

83  owa  2005/12/23 00:25 id: mJs8kxp1Zus  prob: 11.9%

buildbot なんてのも
http://buildbot.zope.org/

82  owa  2005/12/02 20:34 id: mJs8kxp1Zus  prob: 4.1%

Zope と python のバージョンによるテスト結果がまとめられてました。
http://mail.zope.org/pipermail/zope-dev/2005-December/025958...
Zope-2_6-branch Python-2.1.3
Zope-2_6-branch Python-2.3.5
Zope-2_7-branch Python-2.3.5 ※ 正規 Vine-3.2 は Python-2.3.4+α
Zope-2_7-branch Python-2.4.2
Zope-2_8-branch Python-2.3.5 ※ うちの公開鯖 (Vine-3.2 ベース)
Zope-2_8-branch Python-2.4.2 ※ メインマシン (VineSeed)
Zope-2_9-branch Python-2.4.2
Zope-trunk Python-2.4.2
すべて OK とのこと。あくまでテストを通ったと云うだけ。それだけです...

81  owa  2005/04/23 00:18 id: 6ZRXqH8xKo.  prob: 0.0%

>>80 たぶん PNG のデータが悪い
元のモノクロ画像が一個だけやや不良。各種ツールで表示は出来るけど、ヘッダの一部が若干壊れてました。
web 表示の段階でも IE だけが表示できないと云う状態。ヘッダを直したら IE
でも OK でした。

モノクロ階調、RGB(インデクス)、RGB(24bits), RGBA(32bits) を RGBA に統一しようかと考慮中。
もしファイルサイズ等を追求するのであれば、インデクス付きが有利だけど、パレット管理が大変です。
良いツールでもあれば別ですが。

80  owa  2005/04/20 22:57 id: mJs8kxp1Zus  prob: 0.0%

PIL-1.1.5 に入れ換えたら (IE でも) 将棋盤がきれいに表示された。
bKGD chunk ブロックを追加したせいでもある。
http://owa.as.wakwak.ne.jp/zope/coreblog/127
http://owa.as.wakwak.ne.jp/zope/coreblog/129

ただし「棋譜を入力してみよう」ページの盤面が (IE では) 表示できなくなった (-.-;)
http://owa.as.wakwak.ne.jp/zope/shogi/Games/Editor/
でも Firefox では OK。なんで? たぶん PNG のデータが悪いのであろう。しばし勘弁。

79  owa  2005/03/27 23:51 id: mJs8kxp1Zus  prob: 0.8%

# しばらく見られなかった sukima.ddo.jp サイトが復活してました。
# http://sukima.ddo.jp/Plone/WhatsNew
# 覗くと ContinuationBasePack-0.3.tar.gz などと云うファイルが置いてあります。
(また見られなくなったので、コメントアウト;;)

78  owa  2004/12/29 23:48 id: mJs8kxp1Zus  prob: 3.5%

ZShogi-0.1.tgz を http://zope.org/Members/owa/ZShogi に投げてみましたが、一般ユーザでアクセスできません;; 一応 state は publish になってるようですが。プロダクトが認可されるまで時間がかかるのだろうか? 明日まで待ってみよう。

追記: ファイルが一個 private のままでした;; publish に変更してもらったらアクセス可能になったようです。(2004/12/30 15:00)

77  owa  2004/12/11 22:49 id: mJs8kxp1Zus  prob: 0.0%

Zope 関連で一個のセキュリティ問題に複数の投稿があります。
http://mail.zope.org/pipermail/zope-dev/2004-December/024087...
http://zope.org/Members/ajung/security_advisory
http://www.freeml.com/message/zope-memo@freeml.com/0000798
http://coreblog.org/ats/513
こう云うの好きです。とても心強い雰囲気ですね^^
(ちなみに明日は仕事で虫取り、でも嬉し。私は少し変人かも;;)

Debian や Vine でもセキュリティ情報を流してるけど、素人にも分かり易く解説してくれるとありがたいと思う。高度な知識が必要なので僕には無理だけど、解説が必要な人は多いと思う。要望が多ければ、誰か出てくるんじゃないかと期待したり。

76  owa  2004/11/03 23:34 id: mJs8kxp1Zus  prob: 0.0%

>>75 インタプリターってそういうものなの
実行時にデータ型や許容範囲のチェックするので、その時に例外を投げます。C/C++
のように、実行した結果たまたま起きる低レベルの例外が起きてるわけではないので、比較的安全かなと思ってるのですが。

>>ただ時々落ちたようになる問題が解決しているのかどうか解らないので
カウンタが 0 にリセットされた場合の ip 文字列とか保存して置けば、少なくとも切り分けにはなるような気がします。あまり手間をかけたくないけど、原因は見付けたい;;

75  kiyo  2004/11/03 22:56 id: SqALsodDuX2  prob: 0.0%

>>74 sample.com, ****.com, aaa.bbb.ccc.ddd 
そうなんですねぇ。rfind 了解しました。
例文まで載せて頂いて時間使わせたです（忙しいのにすみません）

>>python インタプリタが検出しますので。。。
インタプリターってそういうものなのでしょうか？
例えば見えない所でエラーのダイアログ表示して止まってるとかないですよね。
あ、また変な事書いたですが無視して下さい。

# 家は FSCounter を古いバージョン（1.3.2?）に戻して実験中です。
# ただ時々落ちたようになる問題が解決しているのかどうか解らないので、あまり当てにならないかも知れない。
# Wikiのバージョンが0.99だったし、postgresqlの古いバージョンを別ＰＣから読み書きしていたのはナイショです。 

74  owa  2004/11/03 21:19 id: mJs8kxp1Zus  prob: 0.0%

>>73
幾つか宿題が溜ってました、まず最初にごめんなさい;;
1. ignore_ip メソッドの例外処理パッチが 1.4.0 版では落ちていました。ガーン...ごめん
m(.".)m
2. HTTP_X_FORWARDED_FOR の処理
1.4.0 では組み込まれていて、increment メソッドの方は問題無いと思います。で問題の
ignore_ip メソッドの方の ip を数値変換する箇所ですが、クライアント側が proxy
の場合 (家鯖では) 下記のようなタイプを捕獲してます。

AAA.BBB.CCC.DDD, aaa.bbb.ccc.ddd
unknown, aaa.bbb.ccc.ddd
sample.com, ****.com, aaa.bbb.ccc.ddd

なので URL を取り出すには string.find(s, ',') メソッドでは無く、少なくとも rfind
の方が良いと思います。ただ、ignore_ip メソッドは既知の ip を排除するためにあります。ip を抽出することにとらわれず、既存コード中で split('.') 処理をしてるので、split 結果の数を 4 以下に限定する方が良いか
もしれません。その上で例外が起きたら対処するというのが私の今の思い付きです。

3. ignore_ip メソッドの中の例外処理の件ですが
rAdrInt=(int(rAdrSplit[0])<<24)
もし rAdrSplit[0] が数字と思えない文字列なら例外を発生します。これは try,
except で囲わないといけません (シフト演算の前に int() で起きます)。 ただこれは
python インタプリタが検出しますので python 内で解決してると思います。例えば
C/C++ などの場合は、より低次元で例外が発生するのでその後は保証されるか不確実
(コンパイラによる) かもしれません。python の場合は一応信用して良い気がします。

4. ファイルロック処理
一般的にマルチスレッドプログラムでは共有ファイルへの書き込みはロックすべきだと思います。ただ FSCounter の場合にあてはまるかどうかは定かではありません。云われてみれば、少しこだわり過ぎたかと思ってます。次のようなプログラム "mi
o.py" を作ってみました。close 関数はわざと外してます。

#!/usr/bin/env python
f = open('tmp', 'wb')
f.write('abc')

これをトレース付きで実行してみます (出力の最後だけ載せます)
$ strace ./mio.py
...
...
open("tmp", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40020000
rt_sigaction(SIGINT, NULL, {0x4002ddf0, [], SA_RESTORER, 0x400c3908}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0
write(3, "abc", 3)                      = 3
close(3)                                = 0
munmap(0x40020000, 4096)                = 0
exit_group(0)                           = ?

問題は write(3, "abc", 3) のシステムコールだけなので、例えマルチスレッド環境で実行しても書き込みがおかしくなることは無い気がします。(mmap2 とか rt_sigaction が何をやってるのか知りませんので、間違って
るかもしれません)

5. Vine 3.1
たかがカウンタと思っていたのが *あだ* になりました。一時ツリーから削除してもらおうと思ってたのも事実です。(kiyo さんに言われて再認識しました) 救いは Vine 3.0 からは Vine-Plus もメンテナンス対象になったので不
具合があれば堂々と修正できるようになったことです (でも、まだ半メンテナンス制が発足したわけではありません)。 今回の件は、なるべく早く修正しますので、その上でまたしばらくは様子を見ようと思います。

# 今もってゼロクリア問題が解決したと言い切れて無いので、どこかで嘘を云ってる可能性ありですが・・・