2ch特化型サーバ・ロケーション構築作戦 Part27
■ このスレッドは過去ログ倉庫に格納されています
2ch特化型サーバ・ロケーション構築作戦のスレッドです。
・2ちゃんねるのサーバロケーション、PIEに関する関連作業・調整事項
・DNS登録・変更関連の各種作業や調整事項
・2ちゃんねるのサーバで採用しているOS、FreeBSDに関する情報・調整事項
・各種作戦・プロジェクトとの連携、プロジェクト間の連携
等を取り扱います。
前スレ:
2ch特化型サーバ・ロケーション構築作戦 Part26
http://qb5.2ch.net/test/read.cgi/operate/1183341095/ >>66
> ログインできなかったので、ログインしてパスワードを変更し、httpd を起動した」
もちろんですが、ここは、
強制的にシャットダウンして、システムコンソールからシングルユーザモードで作業した、
のだと推測します。 http://pie.bbspink.com/test/read.cgi/erobbs/1198689181/218-n
このくだりからですか?
これって、レンタルしているかどうか関係なく
サーバ管理者として一番やっちゃあいかんことなのでは・・・ ここに第一報が書かれてるんだが、「何故」入る必要があったのかサッパリわからん
引き渡されてから随分と立ってると思うんだが・・・
■サーバが落ちた!
http://sakura02.bbspink.com/test/read.cgi/pinknanmin/1199308425/32-33 >>66 の返事が中の人から来ました。
> root 権限ありサーバについては引渡し後は顧客に無断でのシャットダウン、
> ログイン、設定変更作業は行われないと認識しておりましたが、
> その状況は変化したのでしょうか。
この認識に変化はなく、それにもかかわらず無断で
該当サーバのシャットダウン・ログイン・設定変更が行われたことについて、
深くお詫びする旨の内容でした。
で、tiger2514 でなぜこのような状況が発生したかについては、
早急に確認し、改めてご連絡いただけるとのことでした。
本業多忙中につき、とりあえず。 詫びは当然として
信頼を取り戻すのは大変だわな
怖くてピンクじゃ鳥も使えんわ 2度ある事は…
>909 名前:root▲▲ ★[] 投稿日:2007/04/27(金) 13:09:35 ID:???0
>とりあえずの緊急対応収容。
>いろいろ調べ中。
>
>まだ調査途中ですが、
>明らかに、PIEの人が勝手にネットワークの設定を変えてますね。
>しかも、サーバの内部設定のことを無視して、単にネットワークの設定だけを変えた。
>
>で、206.223.150.96 のアドレスを持つサーバが2台になって、
>雪だるまシステムが全面的に落ちたと。
>
>詳細は別途調べますが、、
>少なくともroot権限つきで貸しているのサーバの設定を
>勝手に変えないでほしいなと。
>
>…って、例のhobby7事件の時にもきつく言ったような。
http://qb5.2ch.net/test/read.cgi/operate/1175626823/909 やあ(´・ω・`)
tiger2514はhttpdをコメントアウトしておきます、そして、私はあなたが動いていると思います
現在banana3000への若干のもの、Weは根本のパスワードを変えなければなりませんでした
それを入ります。我々は、仕事がされているということを知りませんでした。貧困をあなたにしてください
上へhttpdな?
http://honyaku.yahoofs.jp/url_result?ctw_=sT,eCR-EJ,bT,hT,uaHR0cDovL3FiNS4yY2gubmV0L3Rlc3QvcmVhZC5jZ2kvb3BlcmF0ZS8xMTMyMDY5MTM3LzQ5Nw==,qlang=ja|for=0|sp=-5|fs=100%|fb=0|fi=0|fc=FF0000|db=T|eid=CR-EJ,k59c06c123ae091782270e6b072a9eb36,t20080119045416, 訴訟で釘刺しといた方がいいんじゃないの
謝れば何してもいいと思ってるかしらんし いくら2ちゃんねるとはいえ、顧客だしね。それも、Big-Serverにとっては大変重要な。
別スレにも書いたけど、サーバの電源の切り方の話とか設定ミスの話とかそういうのも前からあったよね。
データセンターとして、それこそ緊急時を除いてはそんなことはしたらいかんよねえ。
ほかのアメリカのデータセンターはこんなことさすがにやってないでしょ・・・。 ジムとむむむ双方の意思疎通に問題があるようにしか見えない。
http://pie.bbspink.com/test/read.cgi/erobbs/1198689181/621
むむむはPIEが勝手なことをしたと怒るが
ジムは、顧客がhttpdを落として何かする場合
前もってチケット(?)に記入しなければならないと言っている。
普通、契約する時にその辺の取り決めがあるはずだけど。 仮にその取り決めがあったとして
それ忘れたら顧客の承諾無しにpass変更してログインしちゃうの?
恐ろしい所だな 普通は警告のメールとか出すもんだろ?
いきなり実力行使は無いな。 httpd固まらせれば合法的にログイン出来ちゃうのか http://www.maido3.com/server/tora/
にあるとおり、ユーザーへの告知前にでもログインは可能なことにはなっている。
ただ、それが今回必要なことだったのかというとむむむ氏の書き込みから見て、そうとは思えないな。
まあ、こういうのがあってから思ったんだけど、Big-Serverの規約ってやっぱ問題あるよねえ。
法律に触れなければ何をやってもいいっていう規約はたしかに自由度があるように見えてたけど、
「責任」とか「権限」とかその手のものについて触れられてないのはさすがに規約としてまずいなあと。 よく分からんのだが、85ってFOXの会社だよね。
やっぱりそこと契約してるのかね?
前FOXが2ちゃんとは契約がないのに訴えられたとか言ってたのは何なの
ひろゆきはNT.Tceを相手に鯖レンタル契約をしてるのですよ
ゼロ相手の契約はないのよ
質問・雑談スレ269=莱^用情報板
http://qb5.2ch.net/test/read.cgi/operate/1199187475/447
447 名前: ◆MUMUMUhnYI 投稿日:2008/01/11(金) 17:49:29 ID:9SuTuMdG0 ?PLT(82008)
私の認識はこんな感じ。
PIE … データセンター、NTTecに場所、電気、ネットワーク等を貸している会社
NTTec … BIG-server.comブランドの所有者、●の販売元
2ちゃんねるがサーバを借りている会社
ゼロ(Maido3.com) … 日本におけるBIG-server.comブランドのサーバ開発・販売・顧客サポート
日本における●のサポート業務
今回のはroot権限付きサーバなのにってことが大きいんで内科医? あ、スペル間違えたNT.Tecねw
んでもって
PIEの社長=デビット氏
NT.Tecの社長=ジム氏
ゼロの社長=中尾氏=FOX >>87
それはこの前からいわれてたね。
それに、この前ゼロ相手に某氏が訴訟おこしたときも、2chとゼロが関係ないことを示す記事を捜してほしいというようなスレをこの板にたててたね。
ゼロの位置が難しいんだよね。直接、N.T.Tecと契約結んでるわりに「maido3.com標準セッティング」だとか、
それこそ、毒男氏の日記といいゼロが入ってる部分があまりにも多い。
位置がはっきりしないからこんな混乱をまねくんじゃないのかな。そういう意味で規約は
さっき誰かがいったように意思疎通が微妙なのも原因の一つ。
アメリカの86server.comのサイトには規約さえ見当たらない(おれが見つけ切れてないだけならごめんなさい)
それでおいて、「勝手に入られた」とかいわれても説得力がないんじゃないの。
そして、むむむさんが問い合わせてるとこがゼロなんでしょ?
そんなふうに関係がごちゃごちゃになってるからこんなことになるんじゃないのかな。
スレ違いだからこれ以上は自重する。 ×そういう意味で規約は
○そういう意味で規約は必要なわけで。 >>64 の作業について、別途メールでもお願いを出しました。 ttp://www.freebsd.org/releases/6.3R/announce.html
ほぼ1年ぶりなんですねえ。 >>89
きつねちんを見かけたら
今度は中尾ちんと呼べということか >>90
ドメインmaido3.comの保有者はN.T.Tecですよ。
なので、maido3.com標準セッティングはN.T.Tec標準セッティングと見るべきでは? そのへんは曖昧なままにしておきたいんだろうな・・・ >>96
> ゼロ(Maido3.com) … 日本におけるBIG-server.comブランドのサーバ開発・販売・顧客サポート
BIG-server.comってアメリカでの業務実績もあるんでしょ?
maido3.comは日本国内サポ専用会社で
maido3.com標準セッティングでよくね?
N.T.Tec標準セッティングの日本専用ブランド名がmaido3.com標準ってことで
すかいらーくグループなのに
バーミヤンオリジナルドレッシングみたいな Apache HTTP Server 2.0.63, 2.2.8 Released
2chで特に関係ありそうなのは…
http://www.apache.org/dist/httpd/CHANGES_2.2.8
*) core: Change etag generation to produce identical results on
32-bit and 64-bit platforms. PR 40064. [Joe Orton]
→雪だるまのフロントで32bitと64bitを混在させる時にうれしい
ちなみに2.0系にはこの修正は反映されてない
*) mod_proxy_http: Correctly parse all Connection headers in proxy.
PR 43509 [Nick Kew]
*) proxy: Fix persistent backend connections.
PR 43472 [Ruediger Pluem]
→フロントのapacheとsquidの間でパフォーマンスが上がったかも?
*) mod_charset_lite: Don't crash when the request has no associated
filename. [Jeff Trawick]
→read.html関係でmod_charset_lite使ってたのは過去の話でしたっけ?
セキュリティ関係の修正はどれも2chには関係ないと思う。 >>49
http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_cpu.c
MFC 1.28,1.29: reject cpufreq changes before sched_bind() is usable and remove duplicated levels.
これで直ったのかな??
>>100
それ、RELENG_7_0 にも入ったみたいですね。
あとで、試してみるです。 >>98
すかいらーくグループなのに
バーミヤンオリジナルドレッシング
わかりやすくてワロタw 携帯→2ch運用情報スレッド56
http://qb5.2ch.net/test/read.cgi/operate/1199041603/855
■ サーバリフレッシュ工事 連絡・作業スレッド10
http://qb5.2ch.net/test/read.cgi/operate/1199792685/53
新しいOSに持っていったら、これを直さないとだめと。
#
# http://qb3.2ch.net/test/read.cgi/operate/1083526243/287
# kawasemi treatment
#
# DST (PDT)
# Jan-Mar
1 7 * 1-3 * prog_name > /dev/null 2>&1
# Apr
1 7 * 4 * [ "`/bin/date +\%Z`" = "PST" ] && prog_name > /dev/null 2>&1
1 8 * 4 * [ "`/bin/date +\%Z`" = "PDT" ] && prog_name > /dev/null 2>&1
# May-Sep
1 8 * 5-9 * prog_name > /dev/null 2>&1
# Oct
1 7 * 10 * [ "`/bin/date +\%Z`" = "PST" ] && prog_name > /dev/null 2>&1
1 8 * 10 * [ "`/bin/date +\%Z`" = "PDT" ] && prog_name > /dev/null 2>&1
# Nov-Dec
1 7 * 11-12 * prog_name > /dev/null 2>&1 >>100-101
入れて、make -j 8 buildworld buildkernel してみました。
頻度はとても減りましたが、出るみたい。
上記では一度だけ出ました。
calcru: runtime went backwards from 2152662958 usec to 969510611 usec for pid 809 (make) 負荷がかかってなくても出るのね。しかも同時にどばっと。
Jan 21 22:51:46 <0.2> oyster901 kernel: calcru: runtime went backwards from 2290 usec to 140 usec for pid 789 (getty)
Jan 21 22:51:46 <0.2> oyster901 kernel: calcru: runtime went backwards from 2573 usec to 157 usec for pid 788 (getty)
Jan 21 22:51:46 <0.2> oyster901 kernel: calcru: runtime went backwards from 2225 usec to 136 usec for pid 787 (getty)
Jan 21 22:51:46 <0.2> oyster901 kernel: calcru: runtime went backwards from 2337 usec to 143 usec for pid 786 (getty)
Jan 21 22:51:46 <0.2> oyster901 kernel: calcru: runtime went backwards from 2245 usec to 137 usec for pid 785 (getty)
Jan 21 22:51:46 <0.2> oyster901 kernel: calcru: runtime went backwards from 2197 usec to 134 usec for pid 784 (getty)
Jan 21 22:51:46 <0.2> oyster901 kernel: calcru: runtime went backwards from 2607 usec to 159 usec for pid 783 (getty)
Jan 21 22:51:46 <0.2> oyster901 kernel: calcru: runtime went backwards from 2716 usec to 166 usec for pid 782 (getty)
Jan 21 22:51:46 <0.2> oyster901 kernel: calcru: runtime went backwards from 1834 usec to 112 usec for pid 732 (md0)
Jan 21 22:51:46 <0.2> oyster901 kernel: calcru: runtime went backwards from 1773 usec to 1253 usec for pid 715 (sendmail)
Jan 21 22:51:46 <0.2> oyster901 kernel: calcru: runtime went backwards from 29547 usec to 26744 usec for pid 711 (sendmail)
Jan 21 22:51:46 <0.2> oyster901 kernel: calcru: runtime went backwards from 4739 usec to 1251 usec for pid 691 (cvsupd)
...(中略)
Jan 21 22:51:46 <0.2> oyster901 kernel: calcru: runtime went backwards from 85286 usec to 40421 usec for pid 2 (g_event)
Jan 21 22:51:46 <0.2> oyster901 kernel: calcru: runtime went backwards from 11208 usec to 6797 usec for pid 1 (init)
Jan 21 22:51:46 <0.2> oyster901 kernel: calcru: runtime went backwards from 1086 usec to 66 usec for pid 0 (swapper) >>106
biosが負荷に応じてCPUクロックを勝手に変更するのが原因とかどっかに書いてあったです。 tiger505,tiger506できたー(^_^;)
root ★さんにroot情報送信済みー >>108
ありがとうございます。と思いきや、
newsplus.jp のメールサーバが不調なようです。(´・ω・`)
今日自宅に帰ったところで直します。
その後受け取り確認をします。 >>108
受け取りました。基本部分問題なさげです。
動作テスト & 構築作業に入ります。 「毎時クリアされるキャッシュ」を持った何者かが動いているような
なんだろーか
毎時そのクリア後大量のアクセスがあるように転送量を見ていると思う。
これが最近のあちこちサーバがあふれている原因のような、 ヲチられてるぽいwwwwwwwwwwwwwwwwww >>111
他国とかからのF5アタックじゃなくて? ホボンには引っかかっていないのか?
たとえば hobby11/etc7 のグラフ
綺麗なカーブにならないで毎時のところでがくっとするんだよなぁ
http://traffic.maido3.com/YPAr/sK1I/bI0q/ 焦らせやがってwwwwwwwwwwwwwwwww
自分でトラップバグ書き込んでるだろう >114
Googleさんとかサーチエンジン系じゃないかと思われ >>114
鋭いですね、、、。
music8/tv11/dso/snow
http://traffic.maido3.com/6Aep/W03T/tuJ2/
ログを精査すると、わかるものがあるかもしれないと。
# 今、ネットワーク的につらいところにいるので、
# 本格調査は夜遅くになるかなと。 >>116
サーチエンジン系は毎時なんて概念がないのが今までだったけど、
そんな挙動をするやつができたのか?
>>117
まぁ じっくりですねぇ また百度かよ
大人しくしましたってのは、お得意のデマなんか? 百度臭いな
俺の所はrobots.txtとUAで弾いてたけど
今度は国内の鯖からUA偽装して来てる なんか言われてるぞw
http://pc11.2ch.net/test/read.cgi/jisaku/1199651376/676
676 :Socket774:2008/01/23(水) 17:24:40 ID:T2rVklg1
>>672
最適化自己ビルドした2chって激遅ですね。海外鯖を考慮しても、表示までに5800msとかありえない。 .dat を取得するときって今はどんな仕組みになっているんですかね?
httpd が単にdatを返すだけ?
anydat.so関係が動いていて云々?
もしそうだとしたらそのオーバーヘッドとかはどんな塩梅?
といろいろ知りたい年頃になっています。
66.249.70.152 @ music8
って何?
アクセス数で2位以下の3倍ぐらいあるんだけど。 Googlebot か、、、。
なんか、read.cgi 叩かれまくり。 最近のGooglebotはBaidu並みになってきたね
半年前まではずっと大人しかったのに p2062-ipad514marunouchi.tokyo.ocn.ne.jp >>131
どもです。ふむ。
read.cgi 叩きまくり。こっちはIEといってくるみたい。 目的がわからん。
何でDATじゃなくてread.cgi? 今 music8 が異常に重いのは、
60.39.129.62
がむちゃくちゃやってくる、
ってかんじですね。
66.249.70.152
も多いけど、その倍ぐらいの密度があるかんじ。 リロードバーボンでバイバイできないのかな
Googleは仕方ないとして こんだけやれば、リロードバーボン効くと思うんですけどね、、、。
効きが悪い、とか、そんなことはないのかな。 ウイルス焼き(deny)も出来ますけどねー。
けど元が何か判らないと焼いても駄目かなー。 >>139
今分析フェーズですね。
もう少し観察します。ログはちゃんととられているので。
と言っても明日も早いんで早寝の予感。 この前pinkでdat400個を1分以内で落としてもバーボン効かなかった >>138
2ch利用者側から見ると、リロードバーボンはもうずいぶん前から全く動いてないですよ 直さなきゃなぁ
しかし・・・
どこのなんと言うプログラムなのかすっかり忘れた。
まず発掘隊を派遣セネガル >>147 です。
ちと、他のプログラムと位置が違ったようかん。
次オンラインになるのは深夜の予定。 各サーバは F22 と同じリスト共有してキックしてますが、
キックしてるほうからみる限り、動いているように見えるです。
それぞれのサーバからの、
なんというか伝達系(?)が、しくっているのかも。 s2ch@xrea鯖から試してみたけどリロードバーボンかかってるみたい そう 伝達系が・・・問題あったみたい、
他の防御システム(UA?)ではじかれていて伝わっていない。
改修せねば、
>>147
どもども そんな感じた゜った ほうほう、排水管が詰まった感じさね。
Rock等もうまく流れるようになるとイイな。
>151 いえいえ、どーも。 あとは00分毎(?)にやってくる「変なの」を待つのか。 (^_^;)つ210.135.99.2 (fo002.razil.jp) これもブラジル関係と思われ(^_^;)つ210.135.99.23 (my2.search.tower.jp) 1 げっ そんなにあるのか、、、
210.135.99 でスルーするか、 210.135.97
もスルーで(^_^;)
210.135.97.1 http://find01.razil.jp
とかが詰まってる 210.135.98にもrazilが山ほど(^_^;)
えーっと
210.135.96
210.135.97
210.135.98
210.135.99
210.135.100
は通してOKだと思う(^_^;) ■ このスレッドは過去ログ倉庫に格納されています