From nakano.hiroaki ＠ nttcom.co.jp Wed Jul 31 11:09:50 2013 From: nakano.hiroaki ＠ nttcom.co.jp (=?ISO-2022-JP?B?GyRCQ2ZMbiEhOShPLxsoQg==?=) Date: Wed, 31 Jul 2013 11:09:50 +0900 Subject: [Ultramonkey-l7-develop 988] Re: =?iso-2022-jp?b?VjMuMS4wGyRCO244Mz51NjcbKEI=?= In-Reply-To: <518C8147.60404@nttcom.co.jp> References: <5163CD5F.1060707@nttcom.co.jp> <516F8967.10908@nttcom.co.jp> <518B570F.9010809@nttcom.co.jp> <518C8147.60404@nttcom.co.jp> Message-ID: <51F871EE.7090000@nttcom.co.jp> 中野@幕張です。 これの対策忘れてました。 チケット切って、とりあえず"'を削除するルーチンを なくします。 でないと、URLモジュールで正規表現使えないので。 (2013/05/10 14:10), 中野　宏朗 wrote: > 中野@幕張です。 > > -Pや--forwarded-forなど、-つきのオプション部分は""で > くくっちゃいけないから、全部""でくくっちゃ駄目ですね。 > > URLモジュールのパターンマッチ文字列部分や--sorry-uriの > URL部分だけくくらないといけないけど、そういうの解釈 > させようとしたら、結局l7vsadmのオプション判定ルーチン > 並の処理をl7directordに載せないと無理ですね。 > > ・・・やっぱl7vsadmにオプションだけ渡したいなぁ。 > > l7directordでs/["']//gってやってる処理を無くせば、 > とりあえず正規表現を""でくくったままsystem関数に > 渡せますけど。 > > 余計、セキュリティホール拡大になりますが、 > まずはそれしかないのかな。 > > (2013/05/09 16:58), 中野　宏朗 wrote: >> 中野@幕張です。 >> >> v3.1.0-develでURLモジュールの試験をしようとしていて、 >> 以下の問題を発見しました。 >> あとでチケット発行します。 >> >> [事象] >> l7directord.cfのmoduleオプションで、特定の文字列後に >> 任意のコマンドを実行できる。 >> >> URLモジュールで正規表現を使おうとして、正規表現の「または」 >> にあたる「|」を使ったのですが、エラーになりました。 >> l7directord.logを見ると、そこには「コマンドが見つかりません」 >> という、見慣れない日本語のエラーメッセージが・・・(゜▽゜;) >> >> [原因] >> わかる人はすぐわかったと思いますが、l7directordでmodule >> オプションを「"」と「'」をご丁寧にも削除の上、system関数に >> 突っ込んでやがったせいです。 >> そのため、「|」を使うとそれがshellのパイプだと認識され、 >> 「|」以降の文字がコマンドとしてサブシェルで実行されます。 >> # "|rm -rf /"なんて書いたらどうなるか・・・((((;゜Д゜))) >> # ファーストサーバのこと、笑えませんorz >> >> [対処案] >> 「"」「'」を取り除いたオプション文字列に対して、改めて >> 「"」で全体をくくってしまおうと思っています。 >> それで問題の出るmoduleは無いとは思っていますが・・・ >> 自分も確認しますが、思い当たるところがあった人は報告 >> してくれるとありがたいです。 >> 本当はl7directordからプロセス間通信でオプション文字列だけ >> 渡すほうが安全ですが・・・かなり仕様の改造になるので、 >> とりあえずの対処です。 >> >> モジュール名チェックを以前削除しましたが、モジュール名も >> ヤバイと思うので、シェルに解釈されそうな文字を弾く処理を >> 追加したほうがいいかも。 >> >> >> # ・・・ユーザ設定の文字をそのままsystem関数に突っ込むのは >> # やめようよ(ノД｀) >> # root権限でしか実行できないコマンドだとしても、さ。 >> >> (2013/04/18 14:49), 中野　宏朗 wrote: >>> 中野@幕張です。 >>> >>> v3.1.0-develの負荷試験ですが、sessionlessモジュールで >>> non-SSL, SSL共にTPC-W負荷試験を終えました。 >>> >>> いくつかバグを叩きだしたので、報告します。 >>> 以下について、バグチケットを発行してもいいでしょうか。 >>> >>> 1) >>> l7vsdを起動したまま、VirutalServiceの追加と削除を >>> 繰り返すと、スレッド数が増えていく。 >>> >>> /etc/init.d/l7directordのstartとstopを繰り返すと、 >>> 1VSあたり2ずつスレッドが増え続けていきます。 >>> >>> 私が解析したところ、スレッドプールから取り出して >>> accept待ちをしているスレッドを終了させる処理が >>> 抜けていることが原因でした。 >>> 終了させる処理を追加したところ、直っています。 >>> >>> 2) >>> l7vsdを起動したまま、VirutalServiceの追加と削除を >>> 繰り返すと、たまにcoreを吐いて落ちる。 >>> >>> 再現方法は1と同様です。 >>> >>> 私が解析したところ、virtualservice_tcpのrunを >>> 終了する時、activeなセッションを停止させていますが、 >>> それをvirtualserviceのスレッド上という非同期な >>> コンテキストの上で行っているため、その次の >>> finalizeが先に実行されると、停止より先に >>> activeなセッションのclearでセッション情報が消滅し、 >>> 停止時にSIGSEGVが発行されます。 >>> >>> 停止をfinalizeの先頭にもってきて、clearと同一 >>> コンテキスト上で先に実行するようにしたら直りました。 >>> >>> 3) >>> TPC-W負荷試験で、SSLで、かつクラスタ切り替えを >>> 伴う時、切り替わって暫くしてcoreを出力。 >>> >>> SSL, sessionlessでクラスタ切り替わりをしたところ、 >>> 切り替わって1分後くらいにcoreを吐いて落ちました。 >>> 非常に発生確率が低いです。 >>> >>> 現在解析中ですが、SSL socketのresetを非同期 >>> スレッドで実行中に落ちています。 >>> resetをするとSSLソケットの場合はboost内から >>> SSL_freeが呼ばれ、その先のglibcのfreeで >>> Illigal pointerアクセスでabortされています。 >>> ポインタ値がずれるのは考えにくいことから、 >>> 非同期処理との兼ね合いで二重freeが >>> 行われていると思われます。 >>> >>> 以上です。 >>> >>> (2013/04/09 17:12), 中野　宏朗 wrote: >>>> 中野@幕張です。 >>>> >>>> v3.1.0ですが、現在負荷試験を実施中です。 >>>> >>>> 超基本の、sessionlessでHTTPによるTPC-W負荷試験で、 >>>> 以下の項目を消化しています。 >>>> >>>> ・Pacemakerで冗長化させた環境でのスイッチオーバ、スイッチバック >>>> ・Pacemaker, UltraMonkey-L7の各プロセスをkillしての >>>> フェイルオーバ、フェイルバック >>>> ・VIPを設定しているネットワークの切断によるフェイルオーバ、 >>>> フェイルバック >>>> ・リアルサーバの一つを切断、および復帰 >>>> >>>> 2つ目〜4つ目の項目は、30回繰り返す試験も実施しています。 >>>> 今のところ、問題は出ていません。 >>>> >>>> 上記項目以外で、ちょっと気になる事象が発生したので、 >>>> それについてチケット発行と対処パッチを後日投稿します。 >>>> >>> >> > -- 中野 宏朗 (NAKANO Hiroaki)