2ch特化型サーバ・ロケーション構築作戦 Part21

雪だるま作戦のスレを待ち続けるスレ Part9
http://aa5.2ch.net/test/read.cgi/nanmin/1148041416/601-602

これの話について。

まず、これを実現するためには、携帯の場合 jig さんや ibis さんのように
固有情報を送っていただくか、AIR-EDGE / PHS の場合、リモート IP アドレスの
情報を送ってもらうことが必須条件になります。つまり、jig さんや ibis さんと
同じことになるわけです。

もちろん技術的には、特に難しいことはありません。
讃岐君のことですから、携帯の固有情報をきちんと送る方法で実装しようと
思ったんだと思います。

で、通常の場合は、たぶんこれで問題ないでしょう。
しかし、何かあった時が問題になります(例えば犯罪予告とか訴訟ネタとか)。

この場合２ちゃんねるからみるとたぶん、書き込みログを警察や裁判所等の
要求に応じて公開するだけで、あとは当事者間でやってください、
ということになることでしょう。

つまりこの場合２ちゃんねるは「讃岐君が中身をみているサーバから
所定の書き込みがあった」ということまでしか、責任を持つことが出来ないことになります。

(続く)

で、讃岐君はきっと「固有情報を送っているじゃん。その固有情報の人が悪いんだよ」
と言うことになるでしょう。

でも、その固有情報が２ちゃんねるから見た場合、
本当に携帯側から送られてきたものそのままかどうかについては、
全く保証できません。

つまり、ここは讃岐君がきちんと責任を担保しなければならないことになります。

担保する、というのは、例えば仮に警察等から照会があった場合には
必要に応じてアクセスログを提出したり公開したりする必要が生じるし、
場合によっては裁判にも行かなきゃいけないかもしれないし、
あるいはもし必要になれば、必要に応じて各携帯キャリアに問い合わせたりして、
本当にその固有番号が捏造ではないことをきちんと証明する必要が生じたりする
可能性がある、等々、といったことです。

だらだらと書きましたが、つまり、２ちゃんねるから見た場合、

「s2ch.netからの書き込みは、すべて讃岐君の責任になります」

ということが、最大にして唯一のポイント、ということになるわけです。

もちろん讃岐君が「s2ch.net 経由でどのような内容が２ちゃんねるに書き込まれても、
私が全責任を負います」ということであれば、話は別です。

以上、root ★ としての個人的な意見。

(まだ続く)

で、「banana637 を又貸ししているいちお友達」としては、
ちょっとさすがに、そこまでの責任を讃岐君にかぶせちゃうのは、
とてもとても、気が進まなかったりします。

もしどこか違うところのサーバを借りてでもやりたい、ということであれば、
私はあえてそれを止めはしませんが、
自分が又貸しているサーバ上ではちょっと、、、って感じです。

で、ibis さんや jig さんは、事業として同様のサービスをされているので、
たぶんきっと、こういった体制や対策はきちんと考慮されていると思いますし、
ノウハウも数多く持たれているでしょう。
責任主体(会社)への連絡先等も明確ですし。


…といったわけで、オトナって、なんかムズカシイんですよ。きっと。

以上、ごめんなさいです。
でも、これからもがんがってくださいな、と。

讃岐さんに責任負わせた方が遊ばなくていいのでは？と思う。

お友達感覚かぁ。

s2chからの書き込みの犯罪予告はそれがs2chからのものであるか証明してまた讃岐さんに渡す作業が必要になるならば
2chのサービスの一つとしてその部分を讃岐さんが主導して行っているとしてroot▲氏の介入を許す必要があるのか。

ふむふむ。

>>643
わたしゃたんなる、おせっかいやきで。

例えば仮に、
管理人と讃岐君が(公式p2みたいな形で)アライアンス組むとかすれば、
その時はたんたんとやるだけです。はい。

技術的にはこのブラウザとか、どうやってるのかなとか。
↓
FOMA90x専用2chブラウザ 「W2Ch」 part3
http://hobby7.2ch.net/test/read.cgi/chakumelo/1146696612/

書き込みのたびにアプリ終了して書き込みするですよ。

>>645
なるほど、iMona (でしたっけ)とかと同じですか。

そうです。ドコモのは全部そんな感じです。

iMonaと基本的に変わらないかと。

読み込み･キャッシュ
書き込みフォームは中間鯖

主な中間鯖を必要とする理由は
1、パケ代節約
→定額制の導入により解消可
2、自作アプリは接続可能な鯖が3つ程度に限られている。
→例外的にvodafoneは制限無し
→FLASHは処理が遅く使い物にならない。

アプリから書き込み出来る物は接続可能な鯖にあらかじめ組み込んで特定の鯖だけだが書き込み出来るようにしたもののはず(^^;

当方C言語習得中なのですがコロンやらセミコロンつけすぎたり忘れたり複合演算子の順番間違えたりとまだまだどシロウトでプログラミングにビギナーズラックはないのだなぁとしみじみしてみたりと、ちらうらになってすいませんでした。

あちこち混乱してそうなので、ここに。

news20b、syslog 的には何のログも残ってないなぁ。
突然電源をバチンてされた感じ。

でも、ハングアップの時もそうなるから、わかんないなぁ。
リブート要請出したんでしたっけ。

瞬間的な電気トラブル？
電気工事で電圧が瞬間的に下がったとか。
変圧器機の切り替えによる瞬断とかな気がしますね。

しゅんだんなら、2時間とか止まらないと思うんですよね。
で、2時間ぐらいで(何もせずに)復旧したというのも解せないし。

というか、これから2週間ぐらいは天狗がたくさんいるので、
どのようなことも、正直起こりうるわけで。

あ、だったらみんな落ちるか。

ハードが悪いかもと私の勝手な憶測をしているとスレ汚しになるので撤退します。

あ、実はLANケーブルが二時間抜けていただけ。

>>653
サーバ自体は、リブートかかっているです。
ケーブルが抜けた旨のログもなしで。

【実況】　live23+24　Part19【新体制始動】
http://qb5.2ch.net/test/read.cgi/operate/1148046382/436

read.cgi だけ詰まったということか。

Apache status log を見る限り、httpd は売り切れになってないので、
影響はないはず、、、ですが、何かあったのかもしんないですね。

一度バックエンドをわざと止めて、実験してみる必要がありそう。

Benchmarking mpsafevfs with parallel tarball extraction
http://lists.freebsd.org/pipermail/freebsd-smp/2005-May/000792.html

> Kernel was built without INVARIANTS and other debugging options,
> without ADAPTIVE_GIANT (which causes about a 200% performance penalty
> on system time in my testing, and has marginal impact on real or user
> time)

options ADAPTIVE_GIANT # Giant mutex is adaptive.

は、ないほうがいいのかしら。

だいちくんの記事。32プロセッサか。
http://journal.mycom.co.jp/news/2006/05/22/014.html

例の貸し出しに応募してみる手もあるのかな。

>>657
これですね。前に質雑スレで振ったけど、反応がなかったのがむなしかった・・・・(涙)
http://jp.sun.com/promotions/trybuy/

>>638
ぶひー

>>659
http://aas.u.la/

次のステップへと。

aas.u.la

アース裏？

あーすら？あしゅら？

【amour】AASで携帯からも長編AAを楽しもう―Ascii Art Scope Part2
http://qb5.2ch.net/test/read.cgi/operate/1116860602/

>>655 snow.2ch.net あたりで NFS や reverse proxy も localhost 上でやってみるとか．

# ついでに，autopurge の ENOENT でないエラーの正体も突き止めたいところですが......

>>664
># ついでに，autopurge の ENOENT でないエラー(ry

これは，とりあえず単に "print" の一語だけ入れてもらえれば...... sage 復帰 CGI で
    bbsd($bbs, 'autopurge', 'hoge');
のようにやってる部分で
    print bbsd($bbs, 'autopurge', 'hoge');
にするだけでも，何が起こってるかわかるだろうと．

>>664-665
別途やってみるですか。

blackgoat4.2ch.net の panic:
そろそろ、6.1R にする時期か。

Dump header from device /dev/da0s1b
Architecture: i386
Architecture Version: 2
Dump Length: 2146500608B (2047 MB)
Blocksize: 512
Dumptime: Wed May 24 06:19:03 2006
Hostname: tiger512.maido3.com
Magic: FreeBSD Kernel Dump
Version String: FreeBSD 6.0-RELEASE-p4 #0: Tue May 16 02:33:11 PDT 2006
[email protected]:/var/src/sys/i386/compile/I386_TIGER_60_BLACKGOAT_NOPREEMPTION
Panic String: page fault
Dump Parity: 543720299
Bounds: 5
Dump Status: good

【365Main】 回線増速(ニュー速とかお引越しのご案内)
http://qb5.2ch.net/test/read.cgi/operate/1147078648/869

＊全サーバ＊、default gateway の変更が必要と。

206.223.146.xx ->2
206.223.147.xx ->2
206.223.148.xx ->2
206.223.149.xx ->2
206.223.150.xx ->2
206.223.151.xx ->2
206.223.152.xx ->2
206.223.153.xx -> 3 * this is the only one that is .3
206.223.154.xx -> 2
206.223.157.xx -> 2

なので、

・153 村だけ *.3
・他の村は *.2

に変更と。(ちなみに今は全部 *.1)

banana637 と tiger2526 で実験。

route コマンドに change があるから、リブートしなくても変えられそうね。
ほっ。

(tiger2526 の例)

% vi /etc/rc.conf

以下のように変更
#defaultrouter="206.223.157.1"
↓
defaultrouter="206.223.157.2"

% route change -net default 206.223.157.2

さて、ということで変更対象サーバが全部とわかったので、
root 権限ありサーバについては、こちらでたんたんと洗い出しをやっていこうと。

＜戦略＞

1) XO にないサーバは、移動日に変更を仕込む。
次にサーバがリブートしたら、設定が変わるようにする。

2) 既に XO にあるサーバは、ここでリストアップし、
たんたんと作業をすすめていく。

ということで、root 権限ありサーバのうち、既に XO にある(はずの)サーバのリスト:

cobra2244
cobra2245
cobra2247

banana307
banana402
banana403
banana404
banana405
banana406
banana2848

tiger503
tiger504
tiger507
tiger509
tiger510
tiger511
tiger512
tiger2507〜2512
tiger2513
tiger2514
tiger2522
tiger2523〜2525

stiger100〜stiger105 (未確認だが、いずれにせよ変更必要)

>>670 のリストを一部修正。

cobra2244
cobra2245
cobra2247

banana402
banana403
banana404
banana405
banana406
banana2848 ここまで済

tiger503
tiger504
tiger507
tiger510
tiger511
tiger512
tiger2507〜2512
tiger2513
tiger2514
tiger2522
tiger2523〜2525

2ｃｈの動作報告はここで。 パート19
http://qb5.2ch.net/test/read.cgi/operate/1140600013/888

>>672 の残りも作業完了。

>>669 のこれを、忘れないこと。

> 1) XO にないサーバは、移動日に変更を仕込む。
> 次にサーバがリブートしたら、設定が変わるようにする。

おつかれさまです

´∀｀）つ旦~~

検索していて、このスレに行き当たりました。

キャッシュ型負荷分散システム開発スレッド
http://pc8.2ch.net/test/read.cgi/unix/998908154/

このスレで Perler さんが開発されていた mirror.pl の最終版って、
どなたか、お持ちではないですかね。

# 上からちょっと拾い読みしてみましたが、いろんな意味で参考になるスレでした。

>>675
なんどかakiさん方が書き込んでいますね。
P2のakiさんかな？

ひっそりと 5.5R。
http://www.freebsd.org/releases/5.5R/announce.html

5系はこれで打ち止め。
ようやく通常の開発体制になるのかな。

(X-1)R はメンテナンスだけして、
(X)R を release & stable で開発して、
(X+1)R を -CURRENT でがんがると。

2.2.10ﾏﾀﾞｰ

【365Main】 回線増速(ニュー速とかお引越しのご案内) Part2
http://qb5.2ch.net/test/read.cgi/operate/1148497454/192-196

通信速度が十分出ないサーバがあったらしいとのこと。
(ifconfig 的には問題なくても、パフォーマンスが出なかったらしい)

ネットワーク機器の設定修正で直ったらしいですが、
100Mbps 接続の機器については、私のほうでもチェックを依頼されました。
ということでこれは別途。

これってもう設定しちゃってますか？

=========================================================================
http://qb5.2ch.net/test/read.cgi/operate/1121886018/841

841 名前：root▲ ★[sage] 投稿日：2006/02/13(月) 17:47:18 ID:???0 ?#
(略)
ということは、/etc/make.conf に、

# added by mumumu, for Apahce 2.2 -- 2006/2/13
USE_APACHE=common22

を追加でいいのかな。
=========================================================================


どうもこれはユーザーが設定するべきものではないみたいです
=========================================================================
http://pc8.2ch.net/test/read.cgi/unix/1140542841/589

589 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2006/03/15(水) 12:35:54
>584
うむ。
USE_* は、ports に依存関係を指定するための変数で、apache で言えば
USE_APACHE は、ports が Makefile 内で Apache のバージョンいくつが
必要かを明示するための変数であって、外から与えるものじゃない。

ports の要求に対してユーザが特定の apache を提示するには >576 のように
APACHE_PORT でどの apache ports を使用するかを教えてやるのが正しい。
しかも、>575 の common* って指定は、apache 本体の Makefile で指定する
値であって、mod_* などで指定するものではない。

ttp://lists.freebsd.org/mailman/htdig/freebsd-ports/2005-November/027182.html
=========================================================================

mod_○○とかのMakefile見ると、確かにそんな感じですし

>>680
あれこれ不具合が出て、既にやめているです。
報告がなくてごめん。

サーバダウン(鯖落ち）情報　part103
http://qb5.2ch.net/test/read.cgi/operate/1147529669/810

comic6 がうーむな状況らしい。
別途、対応で。

>>682 mogera が図らずもウィルスによるカキコをブロックしてる形なんですかね．
しかしそれが DoS になってしまうのは......バーボンがうまく効いてない？

>>683
きっとウイルスのコードが、そういうつくりなんでしょう。
つまり、異常終了すると無限ループになっちゃうとか。

>>684 バーボンは効いて httpd の段階で Deny できてるんですかね？
それなら仕方ない，っていうかそれに対処するとなると ipf レベルでって話になっちゃいますが．

>>685
たぶんね、まずは mod_authz_iplist あたりだと思うんですよ。

bbs.cgi再開発プロジェクト7
http://qb5.2ch.net/test/read.cgi/operate/1130918407/706

別途対応で。

CGI.pmって重くないですか？

書き込みバーボン(レス)は BBS を使ってるから、書き込みが成功しないと
読み込みバーボンまでDenyにならないといううわさがあるんですが、あれって改選したんですかね

△読み込みバーボンまで
○読み込みバーボンが発動するまで

>>688
comic6 と tmp6 は、両方とも今回の件で
ウイルスがバグってループになったっぽい気がしますね。
bbs.cgi 叩かれまくりか。

新しい環境でも書けているウイルスは存在するのかしら。

アンカーミスりました。>>688

>>688 については、CGI..pm は bbs.cgi の他の部分で既にロードして
使っていたりして。

>>691
>bbs.cgi 叩かれまくりか。

ってことは >>689 のように httpd 段階で Deny されてないってことですか．
まずはバーボン改良ですかね．

http://sabo2.kakiko.com/pageview/hourdata.cgi?date=20060527&server=comic6.2ch.net
を見ると、htmlが激しく叩かれているように見えますが、何か関係ありですか？

>>694
あまり関係ないっぽいです。

パソコンで人間ができてプログラムが出来ないようなこと
例えば連想とかを書き込みに入れられたらウイルスによる書き込み減るかも

>>696
それをいうなら画像でできた文字を入力するほうがいいだろ？

>>696-697
書き込み時Captcha（画像）認証制導入議論スレ
http://qb5.2ch.net/test/read.cgi/operate/1144071322/

SDｇｓｄｆ

とりあえず現在無限ループになってるのは，書き込めた“フリ”だけすればお引き取り願えるかな......
まぁどっちにしろ DoS 対策はしなきゃならんでしょうけど．

live23b = cobra2244 ダウンの件
疑うべきは、

電源問題
FreeBSD 6.1R + amd64 固有の問題 (news20b, live23b で起きている気がする)

あたりか。

フロントの Apache status を見ると、
フロントの httpd のコネクションが完全に詰まることは、避けられている模様。

フロントにログインして確認してみると、
F22, offlaw.cgi が刺さった状態になっている。
バックを NFS で参照している部分。

NFS の I/O 待ちになったものが、正しくタイムアウトしない様子。
df すると、刺さってしまうみたい。

read.cgi は、

例えば適当に、
http://live23.2ch.net/test/read.cgi/livecx/1111111111/

と入れると、詰まってしまう模様。

つまり、read.cgi 的にはうまく ProxyTimeout が働いていないっぽい。

http://live23.2ch.net/livecx/a/b/c/ とかは、すぐに 503 エラーになる模様。

GET /livecx/index.html HTTP/1.1
Host: live23.2ch.net

は、すぐにエラーがかえってくる。

つまり、ダウンを検出して「ダウンな状態」を
キャッシュしているように見える。

GET /バックにフォワードされる呪文 HTTP/1.1
Host: live23.2ch.net

もすぐに 503 になるので、>>705 と同じように検出はしている。

GET /test/read.cgi/livecx/1111111111/ HTTP/1.1
Host: live23.2ch.net

は、止まったままになる。（ううむ）

read.cgi は，ライブな dat が存在しないと過去ログ調べるのでは？
（つまり NFS でマウントされてるところ）

で，問題はその NFS なわけですが...... soft mount でも retrans とか timeout とか
そのあたり要調整ってことですかね．

>>708
なるほど、まさにそれですね。< NFS mount を調べる

read.cgi は、確かにそういうコードになっているです。
つまり、原因は同じか。

NFS の設定は、まだまだ調整が必要な予感。

ということで、>>701-709 のまとめとしては、

ProxyTimeout は、うまく動いているらしい。
で、いったんタイムアウトの状態になると、フロントは状況をある程度覚えるらしい。

Apache status を見ると、dat 直読み系はうまくタイムアウトしているので、
503 エラーになっている。(観測結果)

で、「覚える」までの間、たぶんぐぐぐと詰まるので、
一時的にフロントの httpd が満員になり、それで雪だるま全体が繋がりにくく
なったと考えられる。(これは推測)

「覚えた」あとは速攻でタイムアウトするので、現状では httpd の開きスロットは
ある程度確保されている。(観測結果)

NFS 系は、状況がまったく変わっていない。
つまり /etc/fstab に soft を追加しただけでは、何も変わらない。

別途他の調整を実行する必要ありということで。

ということで、ひととおりチェックしたいところは調べたので、
liveb1 の dat バックアップを固めて、
あとはたんたんとリブート要請へと。

>>712 done.

で、ここまでのチラシの裏リストの棚卸:

とりあえず >>600 あたりから。

・>>601-602

・>>615 kris の資料も置かれた模様。>>656 とかも参考に。

・>>618 の変更が 6.1R cobraダウンの原因っていう感じでもないみたい。
(ex14 は問題ないし)

・>>629-630 は問題なさげなのかな。

・バックエンドが落ちても、NFS が刺さらないようにする
>>633-635 あたり。fstab に書かずに直接 mount_nfs で試してみるか。

・Apache 的に SetEnv し、cgi でそれを参照する

・復帰の呪文の問題 (>>665)

・引越しに伴う default gateway の変更 (*.1 => *.2、153村は *.3)(>>667-668)
手順は >>669 だが、ping が通るなら先回りも。

・live23b/news20b がたまに落ちる(だまる)
>>649 でも落ちている(news20b)。しかも自分でリブートしたっぽい (>>650-652)
で、今日は live23b。

・>>679 の速度チェック
概ね問題なしという噂もありますが、一応。

・>>682 comic6 の問題(ウイルスのbbs.cgiへのDoSによる負荷)

続き

・>>687 クッキー問題
use CGI あたりで、ごにょごにょ。

以上、とりあえず。

【365Main】 回線増速(ニュー速とかお引越しのご案内) Part2
http://qb5.2ch.net/test/read.cgi/operate/1148497454/458

やっぱ、i386 と amd64 が活発なようですね。

最近では、big endian でも問題ないことや、
CPU が多くても(例えば14CPUとか)スケールすることの検証などに、
sparc64 も活用されているようです。

>>682
BBQじゃなくて自動バーボンみたいのがいるんですかねー。
判定方法が難しそうですがー。

スピードとか間隔とかだと、幾らでもかいくぐれますからねー。
1時間に1回でもウイルス作者にとってはいいですからねー。
感染パソコンを何十台も作ればいいわけですからー。

>>716
バーボンって、自動なんでは。

判定が難しいには同意で。

>>700 にあるようなことをするには、
さて、どうすればいいのかなと。

重い重い重い重い重い重い重い×36＠運用情報
http://qb5.2ch.net/test/read.cgi/operate/1147544326/282

に、ウイルスの内部コードっぽいのが貼られてますが、
これだと、さて。

ううむ。

だんだん、フロントの httpd の空きコネクション数に余裕がなくなってきた。
刺さっている read.cgi が増えていっているせいか。

kill -KILL で殺しても死なない可能性ありか。ううむ。

>719
フロント２台ブレーメンメーターエラーになってるのはそういうことだったんですか。。。

httpd のリスタート自体はできた。
でも、微妙に変ですね。

このままだと、live22x や news20 にも影響が出ちゃうから、
cobra2244 のリブート入れない限り、
そのうちおじさんもニュー速で遊べなくなるってことか。ううむ。

>>721 は live22x1 に対して実施。

>721-722
ありゃりゃ
ｘ1ブレーメンメーター復帰は確認しましたがまた挙動不審になるのも時間の問題
って事ですか。。。。


※liveスレで早めに実＋への誘導は入れておきました。

httpd の子プロセスが刺さったまま残ってしまったですね。

他のフロントに対する設定変更は、cobra2244 のリブートが入るまでは、
なしということで。

…つまり、NFS の設定の見直しが急務ってことですね。

・タイムアウトするようにする

ってことで。

しかし、soft を指定しているのにハングアップするというのは、
しかもずっと刺さってしまうというのは、ちと納得できないですね。

# さっき間違って入れた df コマンドが、まだ刺さっているので。

で、今は UDP で mount しているわけですが、
TCP で mount するということも、試してみる意味はあるのかもですね。

ただ、TCP で mount していると、
NFS サーバのリブート入れた時に、connection reset by peer とかになるような気も
しないでもないかも。

6.0R では TCP mount はいまいちらしいけど。
http://lists.freebsd.org/pipermail/freebsd-current/2005-July/052582.html

…今は動くはずと。
http://lists.freebsd.org/pipermail/freebsd-current/2005-July/052584.html

live23リブート入ったようですが閲覧できないようです。

>730
データの差し戻しお願いします〜＞rootさん

>>731 done.

ということで、NFS の設定詰めのため、
またいろいろやってみるということで。

【実況】　live23+24　Part19【新体制始動】
http://qb5.2ch.net/test/read.cgi/operate/1148046382/790

790 名前：root▲ ★[] 投稿日：2006/05/29(月) 04:08:02 ID:???0 ?#
で、今回みたいな事態にならないように
(live23b のダウンが live22x や news20b にも影響してしまう)
近日中に、設定変更確認 & 試行のため、
一時的にわざと落としたりするかもです。

その場合には、事前に連絡を入れるということで。

live22x3 異常発生ですね。

うまくプロセスが死なない。
まだ落ちていると思っているのかな。

live22x4 も、同じ異常発生。

両サーバとも、NFS の復活を認識しません。
リブートもだめの模様。

これは、NFS に虫がいるっぽいですね。

live22x3 live22x4 フロントから外しておきます。
あとは通常のリブート要請コースで。

live22x1 x2 x5 は正常でした。

うーむですなぁ、

Cobra だと駄目なんですか?

>>734
> live22x3 live22x4 フロントから外しておきます。

done.

そういえば、

・自動でへくったフロントが切り離されるようにする

というのもあるなぁ。< 棚卸

>>735
どうも、現状ではそうなのかもですね。

設定で回避できるかもしれない可能性は、ありますけど。

一つあった問題(kbdmuxは入っているとおかしくなる)は、
はずすことで回避できました。

6.0R (ex14)ではこの問題は起こっていないので、
6.1R の問題なのかなと。

へくったフロント、うまくリブートできたようです。

reboot -q -n でリブートしてみた。

フロントを5台体制に戻しました。

・NFS しくらないようにする
・6.1R/amd64 の設定でハングアップを回避できないか調べてみる

あたりですかね。まずは。

http://www.freebsd.org/releases/6.1R/todo.html

UFS deadlocks on amd64
Needs testing Tor Egge Seen by Kris Kennaway. This problem seems MI.

これ、かなぁ。

うーむ。

これは >>499 でも指摘したかな。

http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2006-03/msg00678.html

rootちゃんがんばって！
応援してるよ！大好き

>>718
続きいるです？

>>745
あるとうれしいかもしんないです。

しかし、わたし的にはウイルスコードそのものよりも、
どうやったら無限ループじゃなくてとりあえずお引取り願えるかのほうが、
興味ありますね。

denyした方が早いような

>747
爆撃しているＰＣの数が尋常じゃないので無理かと
例の呪文を追加するタイプの登場も時間の問題なので新クッキー仕様と併せて
考えていかなければならない課題でしょうねぇ


※現状も負荷が高めなので爆撃は減っていないようです。
　無限ループに入る前にバーボン送りにしちゃうってのもあまりスマートじゃない
　しなぁ。。。
（フラグをつけてＢＢＱ焼きにするデータにはなりそうですが）

deny するよりも、graceful にお引取り願うほうが負荷が低いし。

if body.match(/(書き込み確認)|(2ch_X:check)/)
@board.cookie = head['set-cookie']
retry

elsif body.match(/お茶でも/)
@board.set_tmp_wait(60*5)
return false

elsif body.match(/もうずっと書けませんよ/)
@board.set_tmp_wait(60*65)
return false

elsif body.match(/には書き込めません/)
@over_size = true
@board.wait
@board.set_tmp_wait 0
return false

elsif body.match(/(\d+) sec たたないと書けません/)
@board.set_wait($1.to_i)
sleep($1.to_i + 1)
retry

elsif body.match(/ブラウザ変ですよん-2/)
TwoChannel::set_user_agent
retry

elsif body.match(/連続投稿ですか？？/)
@board.set_tmp_wait(60)
return false

elsif body.match(/連続投稿ですか？/)
return false

elsif body.match(/ブラウザを立ち上げなおしてみてください/)
@board.time_count += 1
retry

elsif body.match(/名前が長すぎます/)
name.chop!
retry

elsif body.match(/Rock/i)
return false

elsif body.match(/規制中/)
retry

elsif body.match(/バーボンハウス/)
raise 'babon'

else
print body if $DEBUG
raise 'Undefined Error'

end

書き込みの終了ページをクッキーきちんと渡してくれないのに見せれてみるとどうなるんだろう。

クッキー渡してくれたレスだけ反映する形でやるしかないかも。

> 対策
ここに書いちゃっていいかな？

>>752
なんか、まずそうですかね。< 対策

書いてしまったらまた亜種が出るだけか。
でもどうせ出るという噂もあるし。

>>753
出るのが遅れるだけでもずいぶんと違います。

言葉足らずだからもう少し。

つまりは自力で書き換えられるような人でも
対応がすぐ出来る人と出来ない人がいる。

すぐ対応できる人は、書かなくても自力で規制を突破するだろうけど、
書かれることで突破の敷居が低くなって、より多くの亜種が出回る
かも知れないってことで。

挙動が違うものが複数でてくると、あとでの対策も
面倒になります。

ひろゆきがソースを公開しないことはどうのこうのとか言ってた過去ログがあったね

>>750 だとすると、「書き込み確認」という文字列を
別のものに変更しない限り、お引取りいただけないということかしら。

>>757
でも「書き込み確認」で書き込めたかを判定する2chブラウザも多いような…

>>758
で、ここを変えるとまたいろんなことが起こると。

でもそれも、２ちゃんねるっぽいとも言えるのかな。 < いろんなこと

現状の爆撃対策だけなら、同人板を移転させて、「もうずっと書けませんよ」を延々と吐くだけの物をbbs.cgiの代わりに
設置するというのは？

>>760
移転させても、download のやつみたいに
bbsmenu/bbstable を読んで追尾するんじゃないかなと。

>>761
board = TwoChannel::Board.new('comic6', 'doujin')

ハードコードされてて、自動追尾はしてないと思う

>>762
download のやつとはとりあえず違うと。

be mail を撃ってみた

>>763
ぐぐるコードは残ってたり、使われてないけど

>>764
お返事を打ちました。
実験開始してみてますが、びんごみたい。

うーん
なんかまたnews20つまり気味だなぁ

ピンクの小粒ちょうだい

つ●

>>766
うーむ。

様子見てみます。

白インゲンで。

特に問題ないですね。

ちなみに PIE から一部 ISP への経路が、
一部おかしくなっていた時間があった模様。

そっか、それは失礼。

NidaってViewよりももっさりなのかなぁ

はなもげらぷろきしいれなよ

>>771
ちょっともっさり目だと思ったんで、
私は View に戻してしまいました。

View も既に対応版になっているです。

ただ、もし 64bit (amd64) で発生する虫がいるとすると、
爆弾をかかえているようなものなので、
しばらくは、常にどきどきしますね。

それでもだめならコーラック

viewに戻した、
快調だ

なんだよｗ
朝顔の種とかいってやろうとおもったのにｗ

あれ？

>>762
http://aas.u.la/c.cgi/-/operate/1145114275/762

Nidaからのアクセスは全て弾くようにしたらよくね？

style厨うざ

View厨うざ

>>780-782
池沼

ところで ex14 って、どういうシチュエーションで落ちたのかしら。
ping もかからなくなったのかな、、、。

>>784
pingはかかった
sshは繋がった
Apacheだけがしんでいたっぽい

>>785
なるほど、先日来と同じ症状ですね。
それになると、ログインもできなくなるんだよなぁ。

カーネルパニックしてリブート入った模様。 < news19
amd64 だと、FreeBSD 6.1R は微妙な挙動があるのかも。

cat info.5
Dump header from device /dev/da0s1b
Architecture: amd64
Architecture Version: 2
Dump Length: 4226842624B (4031 MB)
Blocksize: 512
Dumptime: Sun Jun 4 13:08:30 2006
Hostname: cobra2247.maido3.com
Magic: FreeBSD Kernel Dump
Version String: FreeBSD 6.1-RELEASE #0: Tue May 9 01:41:03 PDT 2006
[email protected]:/var/src/sys/amd64/compile/AMD64_COBRA_61_NOKBDMUX_NOPREEMPTION
Panic String: spin lock held too long
Dump Parity: 3586994136
Bounds: 5
Dump Status: good

>>787
kgdb の結果:

(no debugging symbols found)...Attempt to extract a component of a value that is not a structure pointer.
(kgdb) where
#0 0xffffffff802696ad in doadump ()
#1 0xffffffff802696d4 in doadump ()
#2 0x0000000000000004 in ?? ()
#3 0xffffffff80269ce7 in boot ()
#4 0xffffffff805fadc0 in enumerators ()
#5 0xffffffff80458267 in __func__.0 ()
#6 0x000000000000002f in ?? ()
#7 0x000000003ab59a70 in ?? ()
#8 0x0000000000000004 in ?? ()
#9 0xffffff00cf854720 in ?? ()
#10 0x0000000000000104 in ?? ()
#11 0x0000000000000000 in ?? ()
Previous frame identical to this frame (corrupt stack?)

あまり参考にならないかも。

kernel Panicですか。
うーん。。

終わりなきバグとの戦い

終わり無き自分との戦い

あんまり虫虫ゆっていると、
「ちゃんと send-pr してくんないと、直せるものも直せません」って、
FreeBSD の中のエロい人に怒られそうなようかんだなぁ。

しなきゃなぁと思ってはいるんだけど。

そこで、「黙れ小僧！お前に(ry」と言い返すのですよ。

Solarisはダメですか
商用利用も無料になったんですが

いくら無料になったって。ｿﾗﾘｽの鯖管出来る人がいないなら無意味。

Solaris = SunOSに詳しい人はいるので、鯖管やってくれるかどうかの問題かとｗ

Solaris10 は Solaris8/9 までのノウハウとは全く別のものが要求されますよ

Solaris10 なんかより FreeBSD のがぜんぜんいいと思うけど・・・

次ぎ乗り換えるときとか、大きな問題解決が必要になったときに選択肢になるんじゃない？

問題があったとき2chでバグバグいってるだけなら、どのOSを利用しても
最終的には一緒かと。

というわけで、rootさんにはsend-prおねがいしたいです。

Solaris(i386)は、ちょっとした高負荷をかけたとたん死亡したことがあるなぁ。
Linux(FC i386)とFreeBSDでは、まだLinuxのほうが耐えてくれたけど。
PenDでLinux(x86-64)でたったら不明なメモリーリークでフリーズ。

Solarisは重杉で使い物になからなかったなぁ。

OSから2ch仕様で作ればいいんじゃね？

略称・OS/2でどうか。

>>801
バージョンが明確じゃないと、なんとも。

FreeBSDだって、5.2.1Rと6.1Rとでは、安定性も性能も全く違うです。

>>800
がんがります、、、。

send-pr しても >>788 みたいのだと、よくわからない気もしますが。
kernel.debug は作ってないですか?

>>805
作ってないです。

#makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols

パフォーマンスが（りゃ という話はあるけど、
news20b あたりは余裕しゃくしゃくだから、
やってみるとよさげかしら。

どの OS を使うかは技術的問題以外に政治的問題ってのもあるでしょうしね．
ホスティング会社側のこともあるし，2ch 側だけで決められるものではないでしょうし．

んで，確かに Solaris 10 では 9 までとは様相の異なる部分も少なからずあって，
例えば SMF とか．まぁ慣れの問題でしょうけど．ただ，ZFS なんかはメリットありそうですね．
過去ログの膨張による HDD 圧迫も問題になってますが，compression=on にすると
容量節約できそうですし．個人的には Express (Nevada) ですでに使ってますが，
/usr なんかも普通なら 3GB ぐらい食うところが 2GB ぐらいで済んでますし，
テキストデータの dat なら圧縮も結構効くでしょうしね．
もっとも，ライブな dat まで圧縮すると CPU 的にはきつくなるでしょうけど，
そのあたりはマウントポイント単位で設定可能ですし，それに CPU に余力があるなら
I/O データ量の削減により速度向上も図れるようですし．

bbs.cgi再開発プロジェクト7
http://qb5.2ch.net/test/read.cgi/operate/1130918407/980

www2 のファイルを置いてある Directory のところににこれ入れてみたけど、
なんかうまくいかないっぽい。

同じ ETag: になるべきなんですよね、たぶん。

mtimeが微妙に異なるんですかね

>>809
rsync でやってはいますが、、、。
これから外出なので、あとで試してみるです。

HEAD /snow/index.js HTTP/1.0
Host: www2.2ch.net


www2f1→411963-664-c5aa2540
www2f2→2c0fb1-664-c5aa2540
www2f3→23f603-664-c5aa2540
www2f4→4006a2-664-c5aa2540
www2f5→41cf89-664-c5aa2540

Last-Modified(つまりmtime)は秒単位では全部同じでしたね。

手元のApache2.2で試しましたが、
FileETag -INode
だとinodeが含まれますね。
FileETag Size MTime
だと含まれないみたいです。

http://httpd.apache.org/docs/2.2/mod/core.html#fileetag
>デフォルト:FileETag INode MTime Size
>　　　　:
>INode, MTime, Size キーワードには + や - を前に付けて
>指定することもできます。この場合は、より広い範囲から継承された
>デフォルトの設定に変更を加えるようになります。そのような接頭辞の
>無いキーワードを指定すると、即座に継承した設定を無効にします。

ってなってるのにナゼだ......と思ってソース見てみたら，
内部的にはデフォルトが ETAG_UNSET (!= ETAG_ALL) なんですね．
で，ETag 生成時に ETAG_UNSET -> ETAG_BACKWORD (== ETAG_ALL) として扱ってると．
なんかドキュメントの書き方このままだと......って感じですが，
それはともかく >>812 のようにするか，あるいは

    FileETag All -INode

のようにするか，で i-node が外れますね．

>>812-813
なんと、、、。

あとで、やってみるです。

VIPPERどうにかなりませんか。

○●【ex14】VIP運用情報104●○
http://qb5.2ch.net/test/read.cgi/operate/1149683567/

BG3 はカーネルパニックか。
最近、BG3/BG4 は負荷試験状態かも。

>816
カーネルパニックですか・・・
そろそろ6.1Rにして凌ぐことも検討しないといけない時期かもしれませんね
（一時凌ぎにしかならないけどやらないよりマシだし）

道頓堀川の奴はちゃんと供養されたのかね

キャッシュファイルを /md に，とか．

>>818
浚っても発見されなかったそうだよ＞サンダース

>>819
6.1R にしたら、って感じですかね。

/md をすごい勢いでアクセスすると、何か起こるという噂も、
ありやなしや。

ううむ、

FileETag Size MTime

だとうまくいって、

FileETag All -INode

だと、うまくいきませんでした。

謎が多いですが、うまくいく方でやるということで、、、。

>>822 乙です．ホント FileETag 周辺の内部処理は謎が多いですが......

そういえば、どうでもいい話、mod_expiresなんかでExpiresヘッダとかCache-Controlヘッダを
送ってやると、IEとかGeckoなんかはその期限が来るまで一切リクエストを送らなくなるっぽい。
304を返すだけのリクエストが減るかも。DNSのTTLみたいな延滞が許されるならありかなーとか。

>>824
なるほど。

逆に TTL みたいな形にできる、ということですか。

DNSのキャッシュみたいに期限が切れてなければキャッシュから、切れてたら
更新されてるか問い合わせるみたいな動作になるらしい。

んで、ブラウザの方にキャッシュの更新の仕方の設定があって、GeckoもIEも
どちらも毎回更新を確認するような設定が存在するんだけど、
GeckoのMozilla 1.7.13では文字通り毎回更新のリクエストを発するようになるが、
IE 6.0 SP1は毎回更新の設定でも、なぜか期限付きのページは期限までは
キャッシュの方を優先して使うっぽい。

以下の DNS 登録をお願いします。

(新規追加)
+ex15.2ch.net:206.223.150.42

>>827
done

Header set Cache-Control max-age=600

で10分間とか．www2 のスタティックコンテンツとかならいいかもですね．
dat とかの板のデータに使うと雪だるまの mod_cache 問題と同様に
BG への影響が問題になるかも知れませんが（u.la が稼働して BG が
不要になればその問題も解消しますが）．

mod_expiresなら修正時刻基準にもアクセス時刻基準にも出来るので
Cache-Controlのmax-ageとかExpiresの日付を動的に変更してくれますよん。

ex14 の memories への収容作業、完了しました。

DNS サーバの設定変更をお願いします。

(現在)
+ex14.2ch.net:206.223.151.225

(変更後)
+ex14.2ch.net:206.223.151.230

>>831
done

確認しました。>>832

これで、今回の移転作業は終了かと。
oyster901 のハードウェア手当てについては、雪だるまスレあたりでわいわいと。

はいー

お疲れ様でし

ど疲れさーん。。

http://qb5.2ch.net/test/read.cgi/operate/1149952652/34
live23b -> 当面は保守的に 32-bit カーネル
news20b -> デバッグシンボル付き 64-bit カーネルで様子見

とか......

とりあえず、live23bの鯖落ちの原因は、logを見ないと分かりませんから
まずは状況を把握してから、考えてもいいかも。。

>>838
ログが残らないんですよね。いきなりガッと止まってしまって
強制リブート入れるのって。

前に FreeBSD 5.2.1R (例のgame6とかがちゃんと動かなかった時)にも
ちょっと調べたんですが、
カーネルデバッガ機能ありのカーネル作って、
リモートコンソールから強制的にカーネルデバッガに落とすとかいう
操作が必要になるです。

また、試行錯誤する日々か。
あるいは、最新の stable に上げてみるとか。

>>839
そういうことですか。。
うーむ。。

ひょっとすると，NFS の soft mount での timeout はデフォルトでは infinite になってて，
-s オプション指定しても -x とかも併せて指定しないと無意味になってるとか......

>>841
ありえますね。

あとは、フロントの自動切り離しと自動再接続か。
うーむ、まだまだすることが多いなと。

で、/etc/fstab に書くパターンでは -x とかは指定できない気がするので、
/md の mount と同じで、mount のためのスクリプトを別に書く必要がありそうですね。
これはそんなに難しくなさそうだけど。

FreeBSD/amd64 なバックエンドは2台あるので、
1台をとりあえず現在の stable にしてみる方向で。

うーむ。
make -j 4 buildworld で死ぬとは。

というかたぶん、負荷は関係ないっぽいですね。
踏むか踏まないかというか。

%uname -a
FreeBSD cobra2244.maido3.com 6.1-STABLE FreeBSD 6.1-STABLE #1: Sat Jun 10 20:14:59 PDT 2006 [email protected]:/var/src/sys/amd64/compile/AMD64_COBRA_61_NOKBDMUX_NOPREEMPTION amd64

live23b カーネル更新。

これで live23b がしばらくハングしなければ、news20b も同じのに更新の方向で。

6.1R (news20b)
-mpt0: MPI Version=1.2.9.0
-mpt0: Unhandled Event Notify Frame. Event 0xa.

6.1-STABLE (live23b)
+mpt0: MPI Version=1.2.12.0
+mpt0: Capabilities: ( RAID-1E RAID-1 SAFTE )
+mpt0: 0 Active Volumes (1 Max)
+mpt0: 0 Hidden Drive Members (6 Max)

SCSI コントローラのドライバが更新されているですね。

>>847

うーん、でも、
私の記憶に間違いがなければ、この更新って 6.0R で入ったもののような気が
しないでもなかったり。

…いや、>>847 はかんちがいっぽいですね。

SCSI コントローラ側のバージョンだった。
もう1回比較してみるか。

dmesg 的には変化ない模様。< 6.1R と 6.1-STABLE

とりあえず新カーネルで make -j4 buildworld 完走。

一度、リブート入れる予定。

ユーザランドも 6.1-STABLE にした。< live23b (cobra2244)

NFS の設定の詰めは、急務ということで。

mount_nfs -R 1 -D 1 -x 1 -s -a 4 -b -i -o ro,nosuid live22:/path /path

こうかな。

>>853 timeout は秒なのか別の単位なのかはわかりませんが，秒だとすればそんなところですかね．
まぁとりあえずじっk(ryで．

フロント5台の NFS を、>>853 の設定に全面的に変更した。

つうか，秒ってより回数ですね＜-R, -x

マウント時に -R 回リトライして，その後の NFS リクエストでは -x 回再送信すると．
で，再送信の間隔はデフォルトでは自動決定されるらしい（けれどもデフォルト値は不明）．

まだ read.cgi へのアクセスが固まる（NFS が刺さる）みたいですね......

>　　　　 mount retries the request up to the count specified in the
>　　　　 retry=n option. (Note that the default value　for　retry
>　　　　 differs between mount and automount. See the description
>　　　　 of retry, above.) Once the file system is mounted,　each
>　　　　 NFS request made in the kernel waits timeo=n tenths of a
>　　　　 second for a response.　 If　no　response　arrives,　the
>　　　　 time-out　 is　 multiplied　by　2　and　the　request　is
>　　　　 retransmitted. When the number　of　retransmissions　has
>　　　　 reached　the number specified in the retrans=n option, a
>　　　　 file system mounted with　the　soft　option　returns　an
>　　　　 error　on　the request; one mounted with the hard option
>　　　　 prints a warning message and continues to retry the request.

↑は Solaris での解説ですが

>　　 mount_nfs [-23NPTUbcdiLls] [-D deadthresh] [-I readdirsize] [-R retrycnt]
>　　　　　　　 [-a maxreadahead] [-g maxgroups] [-o options] [-r readsize]
>　　　　　　　 [-t timeout] [-w writesize] [-x retrans] rhost:path node

という FreeBSD のオプションを当てはめると↓でいいのかなぁ......

retry=n -> -R retrycnt
timeo=n -> -t timeout
retrans=n -> -x retrans

うーむ、

原因切り分けのため、
SMP やめて、single CPU モードにしてみる予定。< live23b/news20b

http://qb5.2ch.net/test/read.cgi/operate/1149989815/221
1 CPU で 64-bit と，SMP で 32-bit と，どっちがいいか......

フロント 強制リブート中。

いったん NFS はずします。

>>859
32bit にするのは、OS の再インストールとか
各種設定しなおしとか、ちと面倒かなと。

それよりは、原因究明したいですね。
将来を考えた場合。

tiger507 上がってこない。

NFS が影響を受けて止まっていて(フロントのF22がささっていた)、
強制リブートで上がってこなくなった。

例の KVM との相性(tiger5xx はリブート時にたまに止まることがある)、
による影響か。

負荷で落ちてるんじゃないってのがなぁ。

5.2.1R の時の悪夢再びか。

NFS は，どこかで localhost 上でマウントしてじっk(ryするとか．

>>864
家の環境でやってみようかなと。

amd64 問題は、手元に amd64 なサーバが1台もないので、
ちと、苦しいですね。

リブートしたら、作業の運びで。

…しかし Google してもヒットする事例がないっぽい、というのも、
5.2.1R の時とよく似ている、とは言えるんだが。

今度は i386 では問題ない、というのも、どうも。

優先度の高い、解決すべき問題は2つ:

1) NFS の設定を詰める

これは、テスト環境を自宅に確保する方向で。

2) FreeBSD 6.1R/amd64 の不安定動作(突然のハングアップ)の原因究明と解消

最新のstableにするも効果なし。
まずは SMP をやめてみる方向で。

>>868
うちのFreeBSD＋amd64は特に不安定になること無いですよ。
負荷のかかり方が違うからなんともいえませんが。。。

1台自宅に確保して、 FreeBSD 6.1R を入れた。

CPU: Intel Pentium III (754.71-MHz 686-class CPU)

これで、自宅に環境作れそうなので、NFS の試験と詰めを急ぎ実施予定。

>>869
構成を教えてもらえると、助かります。

motherboard
CPU
OS Version
memory
HDD

特に、
・dual CPUかどうか
・ディスクがSCSIかどうか

あたり。

>>871
motherboard：Gigabyte　GA-7A8DW
CPU ：　Optron240　×　2
OS Version FreeBSD 6.1R-p1 （SMP）
memory ：　512　×　4
HDD ：　SCSI　HITACHI　HUS157336EL3600（U320、15000rpm、3.6G）　×　2

です。

いい鯖だなぁ

なんかありますかねぇ......
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=6129+0+archive/2006/freebsd-amd64/20060521.freebsd-amd64

>>872
なるほどです。

SCSI controller は、、、。

>>875
SCSIはadaptecの39320を使っています

>>876
ahd ですか。

つまり、cobra のと違うっすね。(mpt)

>>877
そうですね。

/usr/src/sys/nfsclient/nfs_socket.c

うわーん、この#if 0 〜 #endif はなんだよぉ。

if (nmp->nm_tprintf_initial_delay != 0 &&
(rep->r_rexmit > 2 || (rep->r_flags & R_RESENDERR)) &&
rep->r_lastmsg + nmp->nm_tprintf_delay < now.tv_sec) {
rep->r_lastmsg = now.tv_sec;
nfs_down(rep, nmp, rep->r_td, "not responding",
0, NFSSTA_TIMEO);
#if 0
if (!(nmp->nm_state & NFSSTA_MOUNTED)) {
/* we're not yet completely mounted and */
/* we can't complete an RPC, so we fail */
nfsstats.rpctimeouts++;
nfs_softterm(rep);
continue;
}
#endif
}

nfs_socket.c って、current と stable/release でかなり手が入っているのね。

HEAD は 1.141 で、RELENG_6 や RELENG_6_1 は 1.125.2.9 とか言っているし、
>>879 にあった不可解な #if 0 〜 #endif は、なくなっている。

NFS まわりの、ソースの diff (RELENG_6 と CURRENT)を眺め中。>>880

mutex 系の lock/unlock とかが恐ろしく変わっていますね。
NFS 部分だけ、そのまま current のを持ってくるというわけにはいかない予感。

で、これだけ mutex 系のところで手が入っているということは、
NFS 部分に amd64/SMP だとおかしくなるバグがいる可能性も、考えられるなと。

…これだと、現状では、

1) 過去ログは offlaw.cgi や ２ちゃんねるプロバイダ用プログラム、
公式 p2 用プログラムを一式バックエンドに proxy で転送することにして、
まずは妥協する。(= 削除の呪文と同じ取り扱いにする)

ことにして、

2) バックエンド側の NFS の設定をやめて、SMP 設定のままでまずは動かしてみる(amd64も)

ことにし、

3) 次に、SMP を切る等の別のアクションを起こす方向で考える(amd64)

で、いくことにしようかと。

ちなみに自宅での NFS の実験ですが、
いろいろ試行錯誤しているものの、いまだ not responding から
そのまま異常終了してくれる状況になるには至らず。

で、そうなると、read.cgi での過去ログの検出を
直接ファイルを検索することで実現しているので、
ここの部分を、なんとか解決する必要があると。

(つまり read.cgi では「datがない」になってしまう)

で、以前はここを、

過去ログを全フロントに転送する

ことで乗り切っていました。

しかしこれは、過去ログが溜まってくるとシステムのコストが加速度的に上がってしまい、
だめだということが既に判明している

と。

さて、どうするのがいいのか。

>>884 はもちろん、フロントの数がスケールしない、
という意味でも、筋が悪いと。

と言うことは雪だるま特化型のread.cgiを考えないといけないんですね
まずは直接検索から間接検索に切り替える方向とか

>>886
既に read.cgi はフロントで動いているわけです。
特化型というか、過去ログ部分もきちんと雪だるま対応したバージョンってことですね。

雪だるまサーバの過去ログ部分の現状:

・offlaw.cgi 経由での入手: 可能。offlaw.cgi はバックエンドで動作(設定変更した)
・２ちゃんねるプロバイダでの入手: 可能なはず(未確認)。プログラムはバックエンドで動作(同上)
・公式 p2 / モリタポ利用での入手: 同上

・read.cgi での表示: 「dat が存在しません」になってしまう(実際には存在している)

なお、live23b は現在設定変更中。
変更でき次第、上記になる予定。

live23b / news20b 工事完了のはず。>>888

NFSについて:

フロントからの NFS は全面的にオフの状態。
ex15 もオフにする設定は入れたので、次はオフの状態で立ち上がる予定。

>888-889
まだ「datが存在しません。」になります。
反映されてないのかなぁ？

>>891
んーと、落ち着いて >>888 を再度、読んでいただけると。

>892
了解しました。
それで正解なんですね

live23落ちた

>>894
ううむ、、、。

リブート要請出します。
single CPU modeへの以降手配を。

誤爆スマソ

cobra2244 は上がったら、

1) 6.1R に戻す
2) single CPU mode への移行

のてはずで。

cobra2244 は、立ち上がってこない状態になった模様。

-stable にして、カーネルを 6.1R に戻したのが悪かったのかも。

514 名前：root▲ ★[] 投稿日：2006/06/11(日) 20:55:44 ID:???0 ?#
live23b は、立ち上がらない状態になった模様。

数度リブートしてもらいましたが、立ち上がらないです。
リモート KVM が使えるようになるまで、復旧作業ができない状態。

ううむ、、、。

いつもおつかれさまだお。
（　^ω^）つt■ 　コーヒーどーぞだお

で、現在の状態で http://live23.2ch.net/livetbs/ とかをアクセスすると、
結構な時間、待つ模様。

httpd のスロットが、ふさがってくるかも。

そうか、一度 503 になれば大丈夫なのかな。>>901

そういう仕様か、、、。< mod_proxy

…見ていると、live23b は起きようとして
たまに ping かかる状態になっていますね(それでまた落ちてしまう)。

これが、>>902 の原因かも。

現状:

・tiger507 = ex15: ダウンしたまま。
現地に状況調査 & 確認依頼中

・cobra2244 = live23b: たまにping通るものの、ssh通るまでに至らず、
再度落ちる。

現地に状況確認 & 状況確認中。
KVM 経由でのシングルユーザオペレーションが必要な予感。

・上記2台にリモートアクセスするための remote KVM へのアクセスが支障中。

現地に状況確認 & 復旧依頼中。

いやああああああああああああ

rootｻｿ お疲れ様です。

live23b これからの展開:

・>>897 を実施
・安定するなら、それで運用
・力(処理能力)が足りないようなら、涙を飲んで 6.0R に戻し、dual CPU へ

あたりかと。

stable 版を使うのは、特に amd64 ではリスクが大きいと。

6.0-Rにすると、Apacheのバグがでるんじゃないの？

>>908
出る可能性ありますね。

あと、ex14 で起こっていたような、
ping かかるけれども他のサービスが全部死ぬ、
というパターンになることがありえます。

(6.1R/amd64 の場合、ping もかからなくなるのが違う)

1) offlaw.cgi のための転送はやめる
2) その上で offlaw.cgi をどうするか考える。
3) read.cgi をどうするか考える。

な手順かと、

まずは転送&同期を止めましょう。

>>910
それ(過去ログのための転送&同期)は、NFS にした時点で既に全廃しているです。

>>884- 以下あたりは解決しているということ?

>>910
転送&同期？
offlaw.cgiはすでにバックエンドで動作してるけど

んで
それは事の原因じゃないということ?

>>911
when ?

今、同期とっているのは、

・板名/SETTING.TXT (更新されてなければ取り直さない)
・板名/kakolog.html (同上)
・キャップデータ等

になります。

>>912 は、NFS にする以前の設定です。

で、ちょっと前に NFS の設定に変えた。
この時点で転送&同期を全廃したわけです。(>>911 >>915)

現在、>>910 の状態になっていると理解しています。

…とここまで書いてわかった。

>>910 は、 offlaw.cgi のリクエストをバックエンドに転送するのも、やめるべし、
と言っていますか。

今の設定のまとめ。上のほうにもあるけど。

1) 過去ログのデータはバックエンドにある。フロントへのデータ同期はしていない。
2) バックエンドにある過去ログデータの NFS での共有は、今日やめた。
3) フロントで受け付けた offlaw.cgi のリクエストは、バックエンドにフォワードされ、
バックエンドで offlaw.cgi が実行され、フロント経由で結果が戻る。
4) フロントで動く read.cgi は dat 落ちしたデータについては「dat が存在しません」エラーになる。

>>916
言ってマース。

付け焼刃はやめよう作戦。
多数の選択肢を用意して検討し一番良いと思われるのを
少々(時間的、人的)コストはかかってもやろうよ作戦。

それまでは offlaw.cgi は動かない read.cgi もいまいち
もいたし方がないかと、

付け焼刃にしてから多数の選択肢を用意して検討し一番良いと思われるの
やっても問題はないでしょ

>>918
そういうことですか。
把握しました。

とりあえず＊今は＊、過去ログは致し方がないということにすると。

決してそうは思いません
最悪手

>>919

>>919 もありかもですが、このへんは、
判断のしどころなのかなと。

>>920

よろしくです。

さすがに十数人不眠不休で実況サーバのおもりをすることの意義を見出せません
かといって動かしたいのは山々で、

不安定要素は全部排除。
最小限の機能だけ動かす。

>>922
絶対無いです。

offlaw.cgi @live22
offlaw.cgi @live23b
offlaw.cgi @news20b

止めてきます。

>>923
納得したです。

offlaw.cgi をはじめとする過去ログ関連の転送、
止める作業に入ります。

offlaw.cgi @live23b　はサーバが落ちていたりするのかな?

offlaw.cgi @live22
offlaw.cgi @news20b
は止めました。

offlaw.cgiが不安要素だなんて初耳。
おじちゃんあんまり最近の動き理解してないんでしょ。
「過去ログ」って言葉を不安定要素と決め付けてるように見えるぜ。

理解していないのはあ・ん・た。

有無を言わせません。
指令です。

>>925
フロントからの offlaw.cgi の転送を止めました。

live23b = cobra2244 は、現在サーバダウン中です。

この場合のとるべき戦略は、
「引けるとこまで引く」です。

つまり　雪だるまサーバを止める。

しかし・・・
あとは自分で考えてちょ
いちいち説明してなんかいられません。

>>927

ちなみに、

cobra2244
tiger507
はリブート挑戦していますけど上がりません。

cobra2244 は作業中に、私がへまをしていまいちな設定になっている可能性が
一番大きいです。ごめんなさい。
リモートオペレーションが必要な状況と思われます。

tiger507 は他のフロントと同じ通常のリブートプロセスで
上がらなくなりました。原因はまだ解っていないです。>>931

Sean がフェラーリを飛ばして向かっているところかと、
他の人@PIE では手にあまっている状況。

offlaw.cgi がどうなってるか知らんけど
●もってても永久に過去ログが読めないってのはやめてね。

よくわかんないなあ
とりあえず向こうのスレで討論会らしいので移動しますね

>>933
了解です。
# フェラーリ。

ex15 ってジンギスカンが自動で組み込まれない?

ん?
違うのか、、、

ちょっとごにょごにょ

私は cobra2244 のほうの作業します。

ex15 は現在、上がっている状態(で、dat がない状態)
と認識。

public_html/news4vip/ が私から&cgiから見えない予感。

cgi@tiger507　から news4vip が見えない。

SSHでログインしたとき ls で news4vip は見える。
しかし cd で入れない。状況。

FTPも同様。

owner だかなんだかが違うんでないかい? >>939

>>941
確認します。

ちなみに http で 403 です

rootﾀﾝ頑張ってね(´・ω・`)

作業完了のはず。< ex15

他のフロントよりも、メモリディスクを拡張しました。
dat も流し込んだので、あとはピロリさんのほうで作業できると思います。

ksk

何があったら呼んでくださいです。

cobra2244 の作業していますので。

はーい

復帰しました。 < news4vip

ex15 は、復帰かければもとに戻るはず。

1150042408.dat<>復活！！！！ (67)
1150042493.dat<>【しょこたんうざい】中川翔子反対同盟 (1)
1150042492.dat<>RPGツクール再生 (1)
1150042491.dat<>うらっしゃあああああああああああああああああああああ (1)
1150042432.dat<>(ﾟдﾟ)ん？ (4)
1150042480.dat<>まだ復活しないのか……… (3)
1150042440.dat<>復活？ (5)
1150042488.dat<>家出をしようと思う (1)
1150042469.dat<>ﾆｺﾆｺ（´＾ω＾｀）ﾆｺﾆｺ (3)
1150042486.dat<>スクエニ垂れ流し　〜 気に入らないDJは叩こうぜ 〜 (1)
1150042485.dat<>復ッ活ッ (1)
1150042460.dat<>ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!  (3)
1150042484.dat<>VIP復活記念大喜利 (1)
1150042483.dat<>V　I　P 始　ま　っ　た　な (1)
1150042482.dat<>自治スレッド (1)
1150042446.dat<>やほおおおお (2)
1150042479.dat<>　　　　ド　　ラ　　ゴ　　ン　　圧　　縮　　　 (1)
1150042478.dat<>　　　　　　　　　 (1)
1150042465.dat<>ばーか (3)
1150042477.dat<>おい！！！最速1000目指すぞｗｗｗｗｗｗｗｗ (1)
1150042429.dat<>ああああああああああああ (3)
1150042476.dat<>俺の空 (1)
1150042448.dat<>　　　　　　ド　ル　ビ　ー　サ　ラ　ウ　ド　ン (2)
1150042434.dat<>F1世界選手権第8戦イギリスグランプリ　 (2)
1150042467.dat<>なんもねーーーーーーーーｗｗｗｗｗｗｗｗ (1)
1150042463.dat<>ＦＦ語ろうぜ (1)
1150042458.dat<>きたおきたよ！！！１ (1)
1150042436.dat<>一番乗りｗ (2)

http://ex15.2ch.net/news4vip/subject.txt

200 OK

>950
VIP復帰してきます〜

確認しました。>>949

ex15 は ok かな?

過去ログは......やはり過去ログ専用バックエンドを作ってそっちに分離ですかね．
で，そっちは手堅い設定にしておくと．過去ログにパフォーマンスはさほど必要ではないでしょうし．

>954
復帰確認しました。

んじゃ
ex15 は完了。

cobra2244 リモートコンソールつかめました。
作業入っています。

cobra2244 では、stable 版の mountd (NFS関連コマンド)を実行すると、
そこでカーネルパニックを起こしていることが判明。

カーネル・ユーザランドとも、6.1R の状態に戻すことに成功しました。

これから、NFS なしの状態に移行する作業します。

さきほどは mount (NFSのためのコマンド)でパニックしていました。
やはり NFS 周りは、FreeBSD では鬼門のようです。

サーバ部分から NFS を完全になしの状態にして、切り分けを実施。

news20b / live22 も NFS なしの状態に移行するため、
一度ずつ、リブート入れます。やる前には別途連絡予定。

>>960 の mount は、mountd ですね。

雪だるまフロント・バックとも、NFS の設定を消しました。
さようなら。FreeBSD ではもう二度と会うことはないでしょう。> NFS

…ということで、今日の復旧作業はほぼ終了という認識。

>>962 にああ書いたけど、しいてあげるなら、
NAS で使って、1台だけから mount するぐらいが「最大限の譲歩」ですかね。

少なくとも、複数サーバでファイルを共有する手段としては、
もう 2ch では金輪際、使うことはないかと。

さようなら、

ということで 実況関連板&なゅー速で
read.cgiの挙動がおかしかったり、●が使えない状況です。

次はこれをなんとかするということで、

>>運営のみなさん
今週末は、お疲れ様でした。

現状の整理:

・NFS の設定は雪だるまから永久追放
・i386 アーキテクチャは、6.1-RC2 以上にすることでほぼ安定に動作
・amd64 アーキテクチャは、安定動作の確認まだとれず => 原因究明中
・過去ログ倉庫の参照機能が現在動作していない >>964

>>962
> さようなら。FreeBSD ではもう二度と会うことはないでしょう。> NFS
何使ってるんすか？

amd64 はフロント&バック
それぞれ一台ずつ投入されているんでしたっけ?

明日がやべぇ・・・大丈夫なのだろうか？

ちと覚悟はしておけ、

>>968
フロント: i386 5台(新tiger3台、旧tiger2台)
バック: i386 1台(live22)、amd64 2台(news20b, live23b)

そういえばフロントのtigerも64bit試せますね

>>971
フロントのうち旧tiger1台は、現在 ex15 として臨時稼動中。

確かに新 tiger には、
その気になれば、amd64 と同じ 64bit OS を入れられます。(>>972 のとおり)

現状フロントは安定していると思うので、何もしない。
ということで、

旧ex14(cobra2247?) が帰ってきたら、現ex15(tiger507)をフロントに戻して
フロント五台体制。

バック amd64 が安定しないようならバックは全部tigerにするとかがあるかもということで、
今のところ様子見かな、

>>975
了解です。そんなところですね。

現 ex14 = oyster901 ですね。
cobra2247 は news20b になりました。

oyster901だった、、

そういえば oyster901 に付いているHDDはもう処分してもいい状態でしたっけ?
月曜日に新しいHD発注かかるんで到着と同時に付けてもいいか?
という質問なんです。

>>977
memories への収容は完了しているです。

ということで、装着OKと。

りょうかいですー

ということで、73G HDD のレイアウトはこれで。

・単純に、/home と /var を大きくする
・他は従来の cobra 仕様と同一

da0 (73G)

/dev/da0s1a 256M /
/dev/da0s1d 4G /tmp
/dev/da0s1e 4G /usr
/dev/da0s1f 残り全部 /var

da1 (73G)

/dev/da1s1d 全部 /home

OS は、迷うところですが、
まずは今の oyster901 と同じ、FreeBSD 6.0R/amd64 でいこうかなと。

あ、スワップエリアを忘れました。修正版。

da0 (73G)

/dev/da0s1a 256M /
/dev/da0s1b 4G swap
/dev/da0s1d 4G /tmp
/dev/da0s1e 4G /usr
/dev/da0s1f 残り全部 /var

da1 (73G)

/dev/da1s1d 全部 /home

;live23b 確認します。

なんか、原因が別にあるような気もする。
あまりにも落ちすぎ。

また実況が・・・・

ひたすら落ちた時間のログ分析する鹿

CPU 0 が 51℃ で、CPU 1 が 49℃ みたい。
これは、どうなんだろう。

>986
2度くらいなら測定誤差かと

まずは、single CPU のカーネルに換えます。

>>987
いや、高いとか低いとか。

電気代ケチってエアコン消してないか？

>>986
PCなら誤差の範囲だと思うけど鯖の場合はﾜｶﾝﾈ

single user で起動中。

5.4R は安定していたんだよなぁ。< ex12 / ex13
もう1年以上、リブートなし。

そう考えると、新しい機能を減らす方向かな。

mpsafevfs を殺そう。< live23b

%sysctl -a | grep mpsafe
debug.mpsafevfs: 0
debug.mpsafenet: 1
debug.mpsafevm: 1

原因の切り分けが必要ですね。

確かに「ハングアップ癖」はあったけど、ここまでではなかったような。
今度はもうさすがに伝家の宝刀「single CPU mode」だなと。

それでもだめなら、さすがにハードウェア方面を疑うしかないかなと。

個人的には、i-RAM とかは
ジンギスカンII にするのの代替(dat 部分だけ)というかんじに思うですね。

通常の動的なファイルは、通常ジンギスカンで特に問題ないので、
ライブな dat を置く場所、ぐらいですか。

HDD よりは高速だけど、メインメモリには劣ると。
というか SunOS さんも書いていますが、たぶんこれは「高速な HDD」ぐらいのしろものかなと。

>>996 は誤爆ですね。

次スレ、立ててきます。

2ch特化型サーバ・ロケーション構築作戦 Part22
http://qb5.2ch.net/test/read.cgi/operate/1150052911/

ぬわわわ

1,000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。