|
|
最初、ランドラッシュで話題になっているので、とりあえず押さえるだけ押さえておこうかなと思い、チェック。実は、その前に、bgp.moe がすでに始まっていて、おおお?というのがきっかけ。
伊波さんが熱いラブレターを書いたら、ファウンダーズプログラム に当選してしまったとか。なるほど。
んで、
http://get.moe/へアクセスして、tomocha.moe を検索すると、Unavailable となる。
ちなみに、whois では Not found のようだ。
$ whois -h whois.nic.moe tomocha.moe
Not found: tomocha.moe
>>>> Whois database was last updated on: 2014-06-30T07:52:38Z <<<<
Interlink Co., Ltd., (?Interlink?) the Registry Operator for .MOE, has collected this
information for the WHOIS database through an ICANN-Accredited Registrar. This information
is provided to you for informational purposes only and is designed to assist persons in
determining contents of a domain name registration record in the .MOE registry database.
Interlink makes this information available to you "as is" and does not guarantee its
accuracy. By submitting a WHOIS query, you agree that you will use this data only for
lawful purposes and that, under no circumstances will you use this data: (1) to allow,
enable, or otherwise support the transmission of mass unsolicited, commercial advertising
or solicitations via direct mail, electronic mail, or by telephone; (2) in contravention
of any applicable data and privacy protection acts; or (3) to enable high volume, automated,
electronic processes that apply to the registry (or its systems). Compilation, repackaging,
dissemination, or other use of the WHOIS database in its entirety, or of a substantial
portion thereof, is not allowed without Interlink?s prior written permission.
Interlink reserves the right to modify or change these conditions at any time without
prior or subsequent notification of any kind. By executing this query, in any manner
whatsoever, you agree to abide by these terms.
NOTE: FAILURE TO LOCATE A RECORD IN THE WHOIS DATABASE IS NOT INDICATIVE OF THE AVAILABILITY
OF A DOMAIN NAME.
んで、Twitter に、
tomocha.moe のドメインが既にとれないっていうのはどういうこと。まだ、ランドラッシュだよね。だれかが押さえたって事?それとも、インターリンク社が取れないように拒否しているとか、そういうのあるの?
@tomocha0 - 2014,06,30 15:08
と書いたところ、
@moedomainの中の人より、コメント。
@tomocha0 世界のDNSを管理している団体、ICANNのルールにより、tomocha.moe はブロックされています。(DNS名前衝突ブロックリスト対象です) 簡単にブログにて説明を書きました。
http://bit.ly/1qqmmJW
@moedomain - 2014,06,30 19:06
なぜブロックされているか説明がきちんとなく、最初Twitterでのやりとりは、
TLD(Top-level Domain)の名前衝突的(Name Collision) な内容で、具体的に
SLD(Second-level domain) の説明に関してはありませんでした。最初参考にと出てきた資料は、
名前衝突(Name Collision)の問題と日本での取り組みについてのご紹介 - JPNICであり、TLD の名前衝突でした。
ブログによると、
DNS名前衝突ブロックリスト
DNS名前衝突ブロックリストは、新gTLDレジストリが導入当初にブロックすることを義務付けられているドメイン名の一覧です。.moeの名前衝突ブロックリストには約38,000件が(そうです、3万8,000件も!)掲載されています。このリストに載っているドメイン名のほとんどは意味をなさない文字の羅列ですので、実際に登録したいと思う人はあまりいないと思われます。しかしこのリストにはそれ以外に、「anime.moe」や「otaku.moe」などみんなが欲しいドメイン名も含まれてしまっています。.moeドメインを開始するにあたり、こうしたドメイン名をブロックリストに入れることが条件となりました。DNS名前衝突ブロックリストに掲載されているドメイン名はICANNが2006年から2013年にかけて行ったリサーチに基づいて作成され、残念ながら新gTLDレジストリが掲載されているドメイン名に関して変更を行うことはできません。ICANNにより、すべての新gTLDレジストリはリストに掲載されているドメイン名の登録をブロックすることが課せられております。
.moeのDNS名前衝突ブロックリスト(CSVファイル)は公開されておりますのでご自身で確認いただけます。.moeのDNS名前衝突ブロックリスト(CSVファイル)は公開されておりますのでご自身で確認いただけます。
https://www.icann.org/sites/default/files/tlds/moe/moe-apd-list-12nov13-en.csv
話しを聞いていると、TLDの名前衝突ではなく、SLDの名前衝突のようで、どういう経緯で、どのようにして、SLDの名前衝突のリストを作られたか、ということになります。また、このリストは「誰が」作成したか、というのも気になりました。仮に、事業者が作成して、ICANNに提出した場合、意図的・作為的にブロックリストを入れることが出来るのではないかと思ったのです。
Togetterのまとめにも有りますが、
@OrangeMorishitaさんからのコメントによると、
「SLDにおけるブロックリスト」って、実際にルートサーバーに来ていた問い合わせの内容から作ったんじゃなかったけか。
ICANNの依頼を受け調査したInterisle社がまとめた結果はこちら(PDF)。ここにどうやって作ったか書いてあるはず。// Name Collision in the DNS
https://www.icann.org/en/system/files/files/name-collision-02aug13-en.pdf
「SLDにおけるブロックリストをどうやって作ったか」を*私が*わかってないので、現時点ではなんとも言えないです。
というコメントがありました。
まあ、鋭い内容としては、
ていうかオレオレ TLD に気がついてるなら TLD そのものを認可すんなよ
@muranet - 2014,06,30 22:41
というのは有りつつも…。
要はまとめると、インターリンク社のブログのコメントにも有りますが、
ということでした。なぜ、こういう事になったかというと、2003〜2004 年頃、IRCチャンネルである「#うにっくす:*.jp」などでやっていた、オレオレTLDで遊んでいた経緯ではないかということ。これにより、ルートサーバーに対する問い合わせクエリが飛んだことにより、ブロックリストに入ったのではないかという事です。
あるというのが解りました。ここに、tomocha.moe 及び、 damedame.moe というのがずばり有ります。おそらく、クローラーなどが踏んだことにより、ルートサーバーに問い合わせが発生し、ブロックの対象になったのではないかと想像しています。
リストの作成方法については、
moe TLDのブログのコメントにわかりやすく記載して下さっています。
リストの作成方法
ある文字列をブロックすべきかどうかは、クエリの有無を調査することにより判断されました。これは、DITLで得られるルートサーバーのログサンプルで確認できます。調査のインプットとして用いられたのは、以下です:
1)ルートサーバーに送信されたDNS問い合せのサンプル(DITLより)および補足として
2) Internal Name)証明書の発行に関する認証局の情報(例:非委任名のTLS/SSL証明書)。
調査方法の詳細は、調査報告のセクション3.4に記述されています。
ということで、結論として、2003年頃から、moe TLD というのをやって遊んでいたのが大きく影響しているようでした。インターリンクの方々、その他情報を提供して下さった方々、以前のmoe TLD(not interlink) の中の方々、ご迷惑をおかけしました。でもね、これが古き良きインターネットなのよ!10年越しで現実になって問題がでるなんて、誰が当時想像をしたのだろうか...
一言言っておくと、インターリンク社はくじ運が悪かったのか、ねらったのか解りませんが…。いや、2003年頃からオレオレmoeTLDで遊んでいたのにもかかわらず申請を出したと言うことで、ぶつかってこられた?まあ、どっちにしろ、不本意なスレになってしまったようですorz
ちなみに、問題になりそうな、
名前衝突の発生しそうなTLD(home, corp)はハイリスクと認定し、ブロックされるそうです。また、新gTLDが新しく申請されれば、同様に、ルートサーバーにたくさんの問い合わせを行えば、そのSLDは名前の衝突と言うことで、取得不可のようにすることも出来そうですね。セキュリティー的にはどうかというのはありそうですが。
★ 関連リンク:
★ 関連リンク(ニュース記事):
京都府警のパトカーが2月、兵庫県内の中国自動車道で緊急走行中に時速45キロ速度超過をし、145キロで走行したとして、兵庫県警が運転していた20代の男性巡査長を道交法違反の疑いで書類送検していたことが28日、分かった。巡査長は不起訴となった。
京都府警は、この巡査長を所属長訓戒とし、同乗していた40代の男性巡査部長も本部長注意とした。府警は「緊急走行中のパトカーが摘発されるのは珍しい」と話している。
道交法では、パトカーなどには通常の制限速度より速い緊急時最高速度が定められている。中国自動車道の一般車の指定速度は80キロだったが、緊急時最高速度は100キロ。凶悪犯などを追跡する際には例外的に超過が認められていた。
京都府警は当て逃げの事故の通報を受け、現場に急行していたが、兵庫県警は「現場に早く到着しなければならない緊急性があるなら、他府県警と連携すればよく、速度超過の正当性はない」と判断した。
兵庫県警によると、2月2日午後2時50分頃、京都府警のパトカーが当て逃げ事故の通報者が待っていた兵庫県西宮市内の中国道西宮名塩サービスエリアに向かって緊急走行中、速度違反自動監視装置に超過が記録された。
スポーツ報知 6月29日(日)6時3分配信
これって、すなわち、GPSとドライブレコーダーセットで後ろを撮影し、捕まった場合、一緒に提出すれば、パトカーも取り締まれるってことですよね。確か、警察はドライブレコーダーによる録画はいやがると聞きました。一緒に違反がばれたり、悪質な取り締まりが証明されてしまうからって。ありましたなぁ。あとは、実際にそれだけ超過しているかどうかも併せて証明出来るケースは有りますが。
*
[食] マクドナルド ジャパンバカー。ちがった。ジャパンガーガー。あれ?ジャパンバーガー。書きにくい
*
[食] 7月2日オープン 麺屋 求 @東京 西小山
*
[食] 行きつけのとんかつ屋さん
行きつけのとんかつやさんがあって、お店は非公開。
ランチタイムは700円でいただけるお店で、超うんまい。ご飯やキャベツのおかわりとかは無いけど、その辺の下手なチェーン点より断然おいしい。pばあちゃん一人で切り盛りしているので、細々とやっているみたいなのですが、昼間からお酒を飲む常連さんばかりで、まったりした時間が流れるお店。
ニートなので、昼真っから井戸端会議。良いですね。お酒も一緒に飲むのも吉。いやー。誰にも教えれないね、このお店。
てことで、うらやましがれー(えへ
てことで、ご馳走様でした。
*
[Neta] 中央線で寝るおっさん
6月半ばの出来事。随分前だけど。
中央線の22時頃の電車の中で寝るおっさん。
激しいったら、ありゃしない!
その後、三鷹駅で駅員さんを呼ばれ、大丈夫ですか?と声かけたら、あんた、よっぱらってるん?といわれ、つまみ出されていました。
そのときのリアルの写真ですが、ひどいですね。
あとは、駅員さんのチェックもしっかりしていて、電車の中に忘れ物や落とし物がないか入念に確認して放りだされていましたw
*
[TV][Neta][Network] We're BACK Baby の画面にnmapの結果が… 27/tcp は smtp?
テレビを見ていて、間に入っていたコマ。これ、吹いたww
ここまではいいんだけど、この次のショット。一瞬だけど、これはwww
# nmap -Pn -p -sT 192.168.1.2 192.168.1.37
これをみると、21/tcp(ftp), 23/tcp(telnet), 27/tcp(smtp), 80/tcp(http), 111/tcp(sunrpc), 117/tcp ...
え?え?え?え?え?
27/tcp(smtp) ?????
番組の作り込みで失敗したのか、25/tcp じゃなくなっているところに吹いたwww
因みに、
service-names-port-numbers [IANA]でwell known port は管理[
RFC1700]されており、27/tcp は、nsw-fe[National Software Works (old DARPA project) User System Front End - RFC739] で割り当てられているそうです。といっても、私はそんな時代はしらないので、よく分かりませんが(笑)
んで、この番組、ぐぐってもでてこないんですよね。。。見てみたい。。
*
[食] 最近のごはん。
うわー。木箱入りなんていただいちゃったよ…。限定酒。
もったいなくて、なかなかあけれないじゃないの。下さった方、是非こちらで一緒に呑みましょう。
走行中不思議な車を見つけたので、激写してしまった。
後ろに付けているこれはなんだろう?そして、ナンバーが見えにくいから追加のナンバーまでついているようだ。
*
[食][遊び] NAIST IPLAB OB/OG 集まりのあつまり
*
[食][Life] AEONへ就職活動の為にスーツを買いに行った
*
[遊び][旅] 会津、猪苗代、蔵王、仙台の旅。
幼稚園から一緒だった幼なじみと一緒に仙台へ。
小学校の頃の友達が、結婚して仙台に居るので、旅して遊びに行こう!って事で仙台まで。
因みに行ったのは2月23日〜2月25日という東京で大雪があった翌週。最初高速道路とか飛行機とか色々な物が封鎖されないよね?という心配もしながら、無事に晴れてくれた。だって、この週も大雪という予報が出てたからねぇ。
基本今回は無計画。行きたい場所場所と宿だけを決めて、それ以外ノープラン。
私が行きたい!といったのは、
会津の大内宿の雪景色と、蔵王の雪景色。後は無計画でお蕎麦が食べたい!って事だけ決めて旅に出た。基本的に車で行くので、友達は「
車中泊でいいよー。宿取らなくても」って事だったけど、大雪の可能性もあり、気温がどうなるか不明なので、宿だけは取ろう、素泊まりで!ってことで、二人で7000円ほどのワシントンホテルへ。夜はラウンジ、バーが使用できて、そのお値段。お得。こんな大雪の交通が乱れていると予報のでているときにねらい打ちする馬鹿は早々いまい。
★ 2月23日 1日目 会津・大内宿・会津若松:
まずは、大内宿の雪景色を見たいということで、朝6時出発で、10時頃到着予定で移動開始。
すき家で朝ご飯のたまご掛けご飯を頼もうとしたら、ストライキでパワーアップ閉店中なのか、やっていない。
まあ、がっつりお蕎麦たべればいいやってことで、そのまま、会津に向かってGo!Go!
朝の出発をのんびりとしすぎたのか、少し予定より遅くなったが、白河インターを降りた後、会津方面へ向かう途中(289号線)の格子道路の格子山を直ぐに抜けたところの
休憩スペースで休憩。景色がとてもきれいだったので写真撮影。
このあたりも雪深くて、長靴が埋もれてしまうぐらい。
またーりとして、そのまま、
道の駅しもごうで休憩。んじゃ、大内宿に向かいますか。
お目当ての、雪景色!! ちょ、ちょ、ちょー素敵!
別アングルで
なんか、撮影されてた!!
んで、下に降りようとしたら、かやぶきにハシゴが掛かってる。
どうやら、雪を下ろしているようです。頑張れ、おじちゃん。
雪はサラサラ。
さて、ローアングルです。晴れてきたんでお空がとてもきれいな青色。ほんと、きれい。
山形屋。
ここのせんべいおいしいんだよね。
おせんべいずらり。
梅の味を買ったらハズレで悲惨。酸っぱくて、鰹梅風で、塩分によるしょっぱくて。
アンパンマン恐い。
大内宿町並み展示館
なんかね、雪でここまで作りますかw
テンション上がる〜↑↑
早々、会津といえば会津塗りと赤ベコ。赤ベコかったよ。
金太郎そば 山本屋を通ったとき、焼き団子の良い臭いが素晴らしくてついつい…。
ほれ、だんご。
さあ、いただきまーす!
近くに、美人専用。
以前は鎌倉というか、こんなんじゃなかったはず!!
以前はこれ!
さて、次行きましょう。次は、
プチギャラリー。
なんか、わんちゃんがいる!! しかも座布団!
しかも座布団の上にちゃんと座って愛想良くこっち見てくれる!
おしりもぷりっぷり!
座布団があるところにしか座らないようで、とても温厚な性格で人が好きだとか。
飼い主さんのそばに居るようで、売り子さんです。その後、女子達がたくさん集まってきていました。モテモテやね。うらやましい!
さて、ご飯ですね、メインのお蕎麦へ行きましょう。
会津は白ネギで食べる高遠そばですね。
今回も
三澤屋。のんびりしていたためか、昼ご飯になってしまいました。
干してます干してます。藁葺きの色素が落ちて茶色の水になってますね。雪解けです。
中にはいると囲炉裏があったりします。
一緒に居た人は、鮎とお蕎麦を頼んでました。
私は定番のお蕎麦。
向かいに座ったのが、バスのガイドさんと運転手さんで、会話が超面白かったです。だって、葱食べちゃうという話しから色々とぶっ飛んでいて…。全部。
因みにお漬物。
なんの漬物か聞いたけど、書いているときには既に忘れたw
んで、大内宿を出て、会津市内にでも向かいますか。
大内宿から山の方へ走り、トンネルの手前の写真。雪景色と車がきれいだったので、撮影。
あ、一緒に映ってるのは幼なじみです(^^)
実は、12月にこのあたりで走行練習してるんですよね。でも、その空き地が雪で無くなってしまっていました…。
大内宿のあとは、完全無計画で、宿に着ければ良いわけで、道中は全て無計画の行き当たりばったりです。ということで、思いつきで、
会津・鶴ヶ城。
まずは、私は切る!切るのだっ!
んで、お城の中を見学。城の中は撮影禁止なのが多いので、そのまま別館天守閣博物館の写真。
通路の部分ですね。
天守閣見学チケットを買うときに、茶室麟閣見学も出来るのを購入したので、茶室麟閣からのお城。
こちらは公園からのお城。
いくつかのショットを撮影してみました。雪がきれいです。
んで、終わってお堀。
さて、宿に着いて、荷物を下ろして晩ご飯でも食べに行きましょうか。
今回、宿から歩いて、
あいづ桐屋にいこうと思っていたのだが、お休み(定休日ではない)、もう一つの候補でホテルの人から聞いていた
居酒屋(のみくい處作蔵 中央店)さんへ行くことに。
なるべく会津のものを食べたいね、ってことで、お店の人にお勧めを聞きながら頂きました。
ポテトサラダと日本酒
もつ煮込み
なすの揚げ出し
だし巻き玉子
つくね
よもぎこんやく(?) 甘い味噌がのってます。
最後に頼んだものが一番ハズレで、じゃがいものなにかがケチャップとチーズがつらくて、食べきれませんでした。馬刺しはちょっと宗教的事情により、今回は無しなので、他の物ですね。店員さんは元気と愛想が良くてよかったのですが、対応はいまいち。忙しくてごたごたしているのが原因ですね。
その後、ホテルに戻ってラウンジで、一人でSoftwareDesignの現行の締めきりに追われて、原稿を書いて、まずは初稿を投げて寝ることにしました。とはいっても、翌日の予定もなーんもノープランですが(笑
★ 2月24日 2日目 会津若松・猪苗代・蔵王:
朝10時頃ホテルをチェックアウトして、観光ガイドをみながら、行きたいところだけまずはあげよう!そっちの方向に向かうよ!ってことで、
しぶき氷に行きたい!ということで、まずはそちら方面へ。カーナビなどにも入っていないし、GoogleMapsにもはいっていないので、どうやっていくのか正直苦労しました。
会津若松から、猪苗代方面へ抜けるのにあえて交通量が少ないと思われる峠を選択し、楽しい道を選択。一緒に居た人がひたすら運転を楽しんで居ました。
一緒に居た人は、車の免許を取ったのは北海道なので、雪に慣れた物です。楽しくハンドルを握ってました。(MTじゃないと駄目な人で、私のモデルの一つ前のインプレッサを載っています)。奈良ではなかなか雪降らないしねぇ…。
道中、
ガラス館等もあり立ち寄ろうとしたのですが、まずは氷が溶ける前に渋き氷へ向かうことに。
そしたら、どうやら行き過ぎていたようで、金田バイパスの大きな川を渡ったところにある
パーキングに停め、雪景色を堪能。
すがすがしくて景色がきれい!!
新雪できれいなところがあったのであほな写真をぱしゃり。
女二人旅は楽しくて仕方ないね!
さて、場所も見つけたことだし、しぶき氷へ向かいましょう。
駐車場を見つけたので停めましたが、ほんと、一晩でこんなに汚くなるなんてw
しぶき氷の入り口です。実は結構遠い。
猪苗代湖まで到着!とおもったら、まだ半分。写真を撮る私が撮影されていましたw
これはまだ、沼というか川です。が、薄い氷と雪で覆われていますね。直ぐに割れてしまううすっぺらいものです。
湖に到着!!
気温が上がってしまったのか、溶けはじめていて余り良い景色は無いそうです。
がここまで来たんだから堪能してやるぅ!
といっても、せいぜいこの程度。
氷一杯。
さて、次は蔵王に向かいましょう。
猪苗代ICから高速に乗り、磐越自動車道へ。そこから、郡山ジャンクションから、東北道に乗り向かいます。
途中出来れば、会津・猪苗代のおいしいと言われている塩ラーメンを頂きたかったのですが、移動道中には無く、断念。裏磐梯を抜けて、土湯バイパスを抜ければあったのですが、時間も押しかけていて、ガラス館も諦めてしまったぐらいなので、そのまま高速を使って移動。
以前訪問したときにとてもおいしかった
宮城の蔵王BOOへ。
最初に豚さんがお迎え。
外観。
なんか凝ってるねー。
店内に入り、メニューを改めてみて、ZAO BOOバーガー。
注文したときには既におそし。ざおう牛バーガーにしなかったことを後悔。
それでも十分おいしいけどね!
次に、近くに
蔵王牧場があるよね、牧場アイスやチーズが食べたい、見学も出来るみたいねと行き当たりばったりで、道路標識を見て突発移動。これも、無計画の旅の醍醐味。
蔵王牧場到着。
構内地図というか、案内板。冬季は色々なところがやってないみたいね。
じゃ、チーズでも…。
観光バスでおばちゃん達のツアーが来たので、混じり、ツアーバス向けに大量に出された試食用のチーズとクラッカーを散々頂き、お好みのチーズを購入。元々試食用のチーズは有るんだけど、これほども大量に出してもらえるなんてなんて太っ腹。
ほんと、
蔵王チーズうんまい!私は、全部頂いたけどガーリックは邪道、トマト&バジルは不思議な感じ。最終的には、クリームチーズとラ フランスを悩んだ挙げ句両方お買い上げ。
本当は、蔵王のお釜にも連れて行きたかったんだけど時間がなかったということと、そもそも冬季はヤって無さそうなので、そのまま宮城県仙台市を通過し、
一の坊の温泉へ行きました。ここ、前回にいって、本当に良かったんです。ちょっとお高いデスが。
日帰り入浴は21時までなのですが、ラウンジやスイーツなどのサービスもあって、のんびり出来ます。
とっても落ち着いた感じ。んでもって、本日はずっと助手席専門で、原稿を書いておりました。無事最終版を投げ終わり、仙台へ向かいました。夜になったので運転は私が代わり、仙台へ下道でびゅーん。良い感じで楽しかったのですが、車の不調が非常に気になり困りました。
機械式LSDを入れたのは先週の大雪。んでもって、慣らしで300kmほどでオイル交換をしてねといわれたのですが、1週間で300kmも走ることが出来ずせいぜい100km程度。そのまま仙台にいっちゃったので、リアがガリガリいってるんです。デフロックがものすごい。ここまで道中で600kmほど。
取りあえず急なハンドルを切らないようにとか、ロックされないように気をつけながら走行してましたが、翌日更にひどくなってました…。
★ 2月25日 仙台またーり:
夜更かしでおしゃべり、私は途中で体力が尽きて寝てしまいましたが、一緒に居た人はとても仲の良い友達同士なので明るくなるまでおしゃべりしていたようです。音楽のこととかいろんな事で盛り上がってね。私は途中で力尽きて寝てしまったようで、気付いたらお昼前。
お昼ご飯どうしよっかーってことで、一度行ってみたかったんだという喫茶店
ほの香へ。素敵な庭があっていいなぁ。
ここでランチを頂きました。すんごくヘルシーなカレーで大盛。
とてもきれいな盛りつけで感激。奥様ランチ気分!!
珈琲もおいしい。さすが珈琲専門店。
ああ、幸せ。
その後、翌日ライブがあるからということで、仙台に居る悪友を拾って、東京へ。悪友は実家(首都圏)に帰るため、首都圏近郊の電車に置き捨てて、片道分の高速バス相当分だけ頂き、お別れ。
一緒に居た人曰く、なんか、夫婦みたいと言われてしまったのは秘密。でもね、色々と盛り上がり、無事に帰り着きました。車のリアLSDがとても酷いことになっているので、週末にディーラーへ持って行ってオイル交換と点検です。でもね、ラリー車だったら、これぐらいの普通よ…といわれたけどね。いやいや、普通のノーマルの車で良いですからってことで…。オイル交換したら静かになりました。
と、長い旅は終わりです。一緒にいた人も翌日都内を観光して奈良に帰ったみたいです!
目黒駅の駅前にあるケータイショップの張り紙。
翌日台風が予想されており、事前の素晴らしい対応だとおもう。
内容は、「台風8号の接近により、各種交通機関に遅れや運行中止の可能性があります。その為、当店の開店時間が遅れる可能性がございます。」分かり切ったことだけど、ちゃんと書いているところがサービス業だという自覚がきちんとあって素晴らしいですね。
*
[食] ぱっぷハウス
帰り、知人が新しいコペンが納車されたということで、助手席に(笑)
下のトルクがすんごいってことで、軽にのってるという感じが無く結構快適。
15kmほどしか走行していない状態からの助手席だったのだが、ブレーキの利きが悪くて恐い。これは、まだ、まっさらのブレーキだからだろう。てことで、慣らしに付き合うよ!ってことで、ちょこっとドライブ。くくく。
んで、道中三鷹にある餃子。一圓へ駆け込み。
餃子定食S(日替わり一品付き)
餃子はやはり大きい!
うん、おいしかったー。これで、600円ちょっとだったかな。
*
[Drive] 鹿のおしりが可愛い!
ちょっとお出かけしたら、鹿に遭遇。まあ、鹿との遭遇は決して珍しいわけではないんだけど、おしりがぷりっぷりで可愛かったので幸せな遭遇だったかもしれない。親子だね!
*
[食] 野菜たくさん...
ちょうどスーパーでホットスナックを見つけたので、衝動買い。2種類の新発売っぽい(?)
てことで、パッケージ。
裏面
辛沢 しげき って、、、、ベタすぎ。
てことで、いただいてみると、普通。えっと、コイケヤの
カラムーチョのパクリですか?というぐらいそっくりだった。厚切りは、カルビーらしさの厚切りではあったけど、普通の方は、まんま、コイケヤ カラムーチョではないか。とおもうぐらいそっくり。
6月29日の朝。
CTF for Girlsへいこうとしていた日。朝から、大量のアラートが上がってなんだこりゃ、とおもい原因を調べていたところ、RAID1で構成しているディスクが2本ほぼ同時期に死んでいたことが判明。
どのサーバかというと、先日
5月9日に書いた、NEC Express 5800/R120b-1 の構成につっこんだ、
TOSHIBA MQ01ABD100H 1TB (5400rpm, 8GB SSD-SLC)の構成。まずは、RAIDの状態を確認すべく、チェックをしてみると次の通り...
VMware の環境に、lsi から提供している、MegaCLI をインストールしているので、コマンドをたたいて状況を取得してみます。
# /opt/lsi/MegaCLI/MegaCli -LDinfo -Lall -aALL
Virtual Drive: 1 (Target Id: 1)
Name :
RAID Level : Primary-1, Secondary-0, RAID Level Qualifier-0
Size : 931.0 GB
Sector Size : 512
Mirror Data : 931.0 GB
State : Offline
Strip Size : 64 KB
Number Of Drives : 2
Span Depth : 1
Default Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Current Cache Policy: WriteThrough, ReadAheadNone, Direct, Write Cache OK if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy : Enabled
Preserved Cache Data: Yes
Encryption Type : None
Bad Blocks Exist: No
Is VD Cached: No
# /opt/lsi/MegaCLI/MegaCli -PDList -aALL
Enclosure Device ID: 252
Slot Number: 4
Enclosure position: N/A
Device Id: 4
WWN:
Sequence Number: 2
Media Error Count: 0
Other Error Count: 0
Predictive Failure Count: 0
Last Predictive Failure Event Seq Number: 0
PD Type: SATA
Raw Size: 0 KB [0x0 Sectors]
Non Coerced Size: 0 KB [0x0 Sectors]
Coerced Size: 0 KB [0x0 Sectors]
Sector Size: 0
Firmware state: Unconfigured(bad)
Device Firmware Level: 1M
Shield Counter: 0
Successful diagnostics completion on : N/A
SAS Address(0): 0x4433221104000000
Connected Port Number: 5(path0)
Inquiry Data: ATA TOSHIBA MQ01ABD11M 931TC4YVT
FDE Capable: Not Capable
FDE Enable: Disable
Secured: Unsecured
Locked: Unlocked
Needs EKM Attention: No
Foreign State: None
Device Speed: Unknown
Link Speed: Unknown
Media Type: Hard Disk Device
Drive: Not Supported
Drive Temperature : N/A
PI Eligibility: No
Drive is formatted for PI information: No
PI: No PI
Port-0 :
Port status: Active
Port's Linkspeed: Unknown
Drive has flagged a S.M.A.R.T alert : No
Enclosure Device ID: 252
Slot Number: 5
Enclosure position: N/A
Device Id: 5
WWN:
Sequence Number: 2
Media Error Count: 0
Other Error Count: 0
Predictive Failure Count: 0
Last Predictive Failure Event Seq Number: 0
PD Type: SATA
Raw Size: 0 KB [0x0 Sectors]
Non Coerced Size: 0 KB [0x0 Sectors]
Coerced Size: 0 KB [0x0 Sectors]
Sector Size: 0
Firmware state: Unconfigured(bad)
Device Firmware Level: 1M
Shield Counter: 0
Successful diagnostics completion on : N/A
SAS Address(0): 0x4433221105000000
Connected Port Number: 4(path0)
Inquiry Data: ATA TOSHIBA MQ01ABD11M 931TC4YUT
FDE Capable: Not Capable
FDE Enable: Disable
Secured: Unsecured
Locked: Unlocked
Needs EKM Attention: No
Foreign State: None
Device Speed: Unknown
Link Speed: Unknown
Media Type: Hard Disk Device
Drive: Not Supported
Drive Temperature : N/A
PI Eligibility: No
Drive is formatted for PI information: No
PI: No PI
Port-0 :
Port status: Active
Port's Linkspeed: Unknown
Drive has flagged a S.M.A.R.T alert : No
様子を見ると、エンクロージャーの4本目と5本目が死んでいるのが判り、それにより、論理ボリュームがOffilineになっています。ここは、vmwareの健全ステータスから確認出来るのと同じですね。
ということで、ダメになっているディスクをオフラインにしようとしてもダメ。受け付けない。
/opt/lsi/MegaCLI/MegaCli -PDOffline -PhysDrv [252:5] -a3
User specified controller is not present.
Failed to get CpController object.
Exit Code: 0x01
ボリュームからディスクを切り離そうとしてもダメ。
# /opt/lsi/MegaCLI/MegaCli -PDOffline -PhysDrv [252:5] -a3
User specified controller is not present.
Failed to get CpController object.
Exit Code: 0x01
どうしようもなくて、お手上げになってしまったので、別の物理ドライブ、論理ドライブ(RAID1+0)のボリューム上のゲストマシンをサスペンドして、再起動して、MegaRAIDのBIOSからどのように見えるか確認してみたら次のような感じ。因みに、この時点で、六本木、GREEの中で作業。
完全に認識していない。後に、この状態で、MegaCli をつかって情報を取得しようとしてもなにもとれませんでした。一応、ディスクのハードウェア情報は見れましたが…。というわけで、そんなボリュームは無いといわれ、仕方なく諦めて、別の物理ドライブ、論理ドライブで動いているゲストを復活させました。今回死亡したディスク上にいたVMは、生活用のLinuxの /home と、リプレースのため、2月より構築を始めていた、tomocha.net のサーバです。tomocha.net は構築、検証、並行運用の為、データのバックアップは一切有りません。とはいっても、システムはまだ移行していないので、失ったデータは有りませんが、労力は全て失いました。とはいえ、構築の段階で構築手順書みたいな物は作っていたので、改めてその手順書に基づき再構築を行えば良いのですが…。
ということで、どうしようもないので、問題の発生した2本のディスクを抜いて貰い、宅急便で送ってもらいました。因みに、イベントを追いかけたとき、最初に1本目がダメになったのは、6/28 夜で、2本目が逝ったのは、6/29 朝の6時頃。時間差にして8時間ほどです。そりゃ、どうしようもないわ…。
んで、東京へ送ってもらうのと同時に、諦めて、RAID6(SAS 300GB * 6)の鉄板の構成にすることに…。んで、ディスクの発注を行ったら、佐川急便で送ってこられ、受け取りに逝くことに。。。
まずは、受け取りに逝くためには、車で出かける必要があり営業所へ。えっと、往復30km有るんですが…。あの対応の悪い佐川なので非常に参ります。
電話でねぇし…。カスだ。営業所に着くと、連絡ってくれました? ときかれて、連絡しようとして何度電話しても出なかったのお前らだろ…だったら、繋がる番号を教えろといったら、教えれませんとか。クソが。
無事に受け取れたので、帰りのナビ。
無事受け取り、届いた交換用の純正SASディスクはこんな感じで合計8本。
問題のあったSATA SSHDのディスクはこんな感じ。
取りあえず、データのサルベージは置いておいて、ディスクに問題がないか、一旦データを書いて、チェック。
4本ずつ同時にチェックをしていきます。
さて、問題の起きたディスクのサルベージでもしましょうか…。
赤色の左下のケーブルは、MegaRAIDのHBA、青色のケーブルは、LSI LogicのRAID0,1,10,1E対応の普通のHBAです。後者の板は設定しなければJBOD用でつかえ、且つ、SASディスクも使えることから非常にデータサルベージなどには重宝します。
問題の出たディスクのS.M.A.R.Tを見てみます。
# smartctl -a /dev/sdb
smartctl 5.40 2010-07-12 r3124 [i686-pc-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION ===
Device Model: TOSHIBA MQ01ABD100H
Serial Number: XXXXXX
Firmware Version: AUF01M
User Capacity: 1,000,204,886,016 bytes
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 8
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Fri Jul 4 22:21:51 2014 JST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 100 100 050 Pre-fail Always - 0
2 Throughput_Performance 0x0005 100 100 050 Pre-fail Offline - 0
3 Spin_Up_Time 0x0027 100 100 001 Pre-fail Always - 2572
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 12
5 Reallocated_Sector_Ct 0x0033 100 100 050 Pre-fail Always - 0
7 Seek_Error_Rate 0x000b 100 100 050 Pre-fail Always - 0
8 Seek_Time_Performance 0x0005 100 100 050 Pre-fail Offline - 0
9 Power_On_Hours 0x0032 098 098 000 Old_age Always - 1195
10 Spin_Retry_Count 0x0033 100 100 030 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 11
191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0
192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 1
193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 5664
194 Temperature_Celsius 0x0022 100 100 000 Old_age Always - 30 (Lifetime Min/Max 15/33)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 253 000 Old_age Always - 0
220 Disk_Shift 0x0002 100 100 000 Old_age Always - 0
222 Loaded_Hours 0x0032 100 100 000 Old_age Always - 64
223 Load_Retry_Count 0x0032 100 100 000 Old_age Always - 0
224 Load_Friction 0x0022 100 100 000 Old_age Always - 0
226 Load-in_Time 0x0026 100 100 000 Old_age Always - 263
240 Head_Flying_Hours 0x0001 100 100 001 Pre-fail Offline - 0
SMART Error Log Version: 1
ATA Error Count: 16 (device log contains only the most recent five errors)
CR = Command Register [HEX]
FR = Features Register [HEX]
SC = Sector Count Register [HEX]
SN = Sector Number Register [HEX]
CL = Cylinder Low Register [HEX]
CH = Cylinder High Register [HEX]
DH = Device/Head Register [HEX]
DC = Device Command Register [HEX]
ER = Error register [HEX]
ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.
Error 16 occurred at disk power-on lifetime: 1194 hours (49 days + 18 hours)
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
50 50 01 01 00 00 00
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
ff ff ff ff ff ff ff 0c 00:00:37.134 [VENDOR SPECIFIC]
aa aa aa aa aa aa aa ff 00:00:36.479 [RESERVED]
ec 00 00 00 00 00 a0 00 00:00:31.472 IDENTIFY DEVICE
ff ff ff ff ff ff ff 0c 00:00:31.427 [VENDOR SPECIFIC]
aa aa aa aa aa aa aa ff 00:00:30.686 [RESERVED]
因みに中身がサルベージ出来るか、確認してみたところ次のような感じで全くディスクにアクセスが出来ません。
# dd if=/dev/sdb conv-sync,noerror bs=512k
dd: reading `/dev/sdb': Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.33083 s, 0.0 kB/s
dd: reading `/dev/sdb': Input/output error
0+1 records in
1+0 records out
524288 bytes (524 kB) copied, 0.577474 s, 908 kB/s
dd: reading `/dev/sdb': Input/output error
0+2 records in
2+0 records out
1048576 bytes (1.0 MB) copied, 0.820808 s, 1.3 MB/s
dd: reading `/dev/sdb': Input/output error
0+3 records in
3+0 records out
1572864 bytes (1.6 MB) copied, 2.26415 s, 695 kB/s
0+4 records in
3+0 records out
^C1572864 bytes (1.6 MB) copied, 3.00568 s, 523 kB/s
中身を拝むことも出来ないので、どうしようもなく。ハードウェア的に読み書きが禁止されている状態ですね。代わりに、同型番の正常なHDDを持ってきて、コントローラを交換してみましたが、結果同じです。S.M.A.R.T の統計データはコントローラ毎にもっているようですが、ディスクのエラー状態はディスク上に記録されているようで、S.M.A.R.T でみた、エラーの内容はコントローラを置きかえても同じデータが参照出来ました。因みに、読み取りは同じく出来ませんでした。
更に調べていると、ディスクの書き込みを禁止しているのを解除出来るかなと思い、HDAT2を試みてみましたが、結局ダメ。こんな感じ。
正常なディスク。型番は違うけど…。
DCO frozen になってる…。
DCO area が disable, DCO frozen になっており、何も出来ず。
正常な同型番のHDD。
DCOサイズが、1TBになっている。
この辺のロックをとけたらなんとかなりそうなんだけど、やり方判らず。断念orz
*
[Internet][遊び] [Day0] JANOG34 移動
*
[Internet] [Day1] JANOG34 本会議1日目
*
[Internet] [Day2] JANOG34 本会議2日目(最終日)
*
[食] [Day3] うどん麺打ち体験
*
[遊び] 高松から六甲山、そして、ラーメン。
*
[Life] 免許更新と車検。
ちょうど昨日は誕生日。ハタチになりました(うふ)
今年、5年ぶりの免許更新なので、免許センターへ朝一で行ってきました。
平日だというのにかなり混雑。朝の9時までにいったのに、既に混雑。みんな車で来るので駐車場も結構うまっています。まあ、完全車社会だから仕方ないですけどね。
無事、免許更新が終わったので、8月に車検を迎えるインプレッサちゃんの車検。購入して、ディーラーの点検後、9ヶ月。9ヶ月で1.5万キロですよ、1.5万キロ。ペースはええええ。
ホリデー車検をしたかったのですが、あなたのケースは、ハードコンディションなので、ホリデー車検はダメですよとか色々と言われてしまい、いくつか探したところ、シマダオート 郡山店がホリデー車検をやってくれると言うこと、購入後、こまめにオイル交換などしているし、ちょうど2ヶ月ほど前に、デフオイル(ミッション・リアデフオイル共に)、エンジンオイルなど、ほぼオイル交換をしていると言うこと、また定期的に点検を受けているので、車検だけ通して。とお願いしたらおっけーでした。指摘されたのは、ブレーキオイルだけ。そりゃ、まだ交換してないからね。もうすこしこっちはガンバリマスよっと。んで、お値段は法定費用を除き、1.5万円。お安い。
その間代車を借りて、ドライブ。ていうか、車検してもらいに車を持っていくだけで、往復50kmですよ、50km。まあ、田舎だから仕方ないんですけど。
借りた代車は平成8年製の3ATのワゴンRでターボ無し。ちゃっちいのなんの。
こんな車で高速道路や名阪酷道は正直走りたくないなぁとおもったのは秘密です。
アクセル全開でも、100km/hはしんどい。正直80でも結構苦しそう。
80km/h で4800rpm程度、100km/h で、5800-6000rpm 程度でしょう。
しかも全然パワー無いし、エアコン付けると踏んでも走らない。うーん。正直恐い車でした。
しかも、ハンドル放すと、バランス崩れているのかだんだん流されていくし…。基本、Lと2を旨く使ってレッドゾーンギリギリまでまわしてシフトアップしていく乗り方ですね。ああ、軽自動車ってこんなに貧弱だっけと思いながら、乗り回しました。
てことで、時間も掛かるようなので一旦家に帰り、荷物整理。こんな感じです。
ワゴンRは結構高さがあって箱なので、よく荷物のりますねー。
まあ、ほんと、広くていいっすな。
荷物を持って、ディーラへ行って、荷物を載せ替え、そのまま、東京へ移動です。
なぜならば、就職活動のため面接があるからなのです。
帰りの走行中、橿原警察署の近くで不思議な車を見かけました。
試験車ってなにー?
*
[食] FamilyMart おにぎりのパッケージ不良があったけど、全てスルーしてしまった件について
*
[食] ハバネロバーガー
*
[食] 松屋 プレミアム牛めし
*
[旅][遊び] バーベキュー @静岡県清水市(興津川上流)
*
[食] ワッパーJr. 半額
今年1月にもワッパーJr 半額というのをやっていて、4個買った覚えがあり、3個でギブアップした経緯があるので、今回は3個にしました。
ということで、半年ぶりですね。
4個はさすがにギブアップする感じの様子だったので、3個で正解かなー。
ちなみにおきまりのAllHeavyでつ。
サーバをリプレースのため、環境を再構築。既存の環境からデータ及び環境を保つため、FreeBSD10で再構築していた。今回、pkg でずいぶん楽になったと言うことで、pkg install でいけるからとても楽。んでもって、既存の環境から、各種設定ファイルを持ってきたりして、なるべく同じ構成になるよう行っていた。んで。home などをごそっともっていったので、環境が日本語となっていた。という前提の上、proftpd をインストールし、設定し、動作確認を行おうとしたときに日本語のメッセージww
$ telnet 192.168.0.23 21
Trying 192.168.0.23...
Connected to 192.168.0.23.
Escape character is '^]'.
220 ProFTPD 1.3.5 Server (bsd) [::ffff:192.168.0.23]
500 不正なコマンド: もっと創造的になろうと努めなさい
500 不正なコマンド: もっと創造的になろうと努めなさい
quit
221 さようなら.
Connection closed by foreign host.
調べていると、原因はこれ。
nobody 4423 0.0 0.1 45312 6088 - Ss 4:23午後 0:00.01 VENDOR=amd SSH_CLIENT=192.168.0.8 50872 22
LOGNAME=tomo PAGER=lv OSTYPE=FreeBSD MACHTYPE=x86_64 MAIL=/var/mail/tomo
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/root/bin
HOST=bsdsrv15 PWD=/usr/local/etc _=/usr/local/etc/rc.d/proftpd GROUP=wheel TERM=screen SSH_TTY=/dev/pts/1
HOME=/root USER=tomo SSH_CONNECTION=192.168.0.8 50872 192.168.0.23 22 HOSTTYPE=FreeBSD SHELL=/bin/csh
LC_ALL=ja_JP.eucJP RC_PID=4406 BLOCKSIZE=K SHLVL=3 proftpd: (accepting connections) (proftpd)
上記の最後の方にある、「
LC_ALL=ja_JP.eucJP」が悪さをしていたようだ。手で起動したから、環境変数をそのまま引きずったんだろう。
てことで、
# unset LC_ALL
とやって、再起動若しくは、service コマンドを使えば、そういう環境変数の影響は受けないようだ。
そのためにあるコマンドなので、CentOSと同様、service コマンドを使うのが無難のようだ。
nobody 4695 0.0 0.1 40924 5740 - Ss 4:49午後 0:00.00 PATH=/sbin:/bin:/usr/sbin:/usr/bin PWD=/
HOME=/ RC_PID=4674 proftpd: (accepting connections) (proftpd)
$ telnet 192.168.0.23 21
Trying 192.168.0.23...
Connected to 192.168.0.23.
Escape character is '^]'.
220 ProFTPD 1.3.5 Server (bsd) [::ffff:192.168.0.23]
500 Invalid command: try being more creative
500 Invalid command: try being more creative
quit
221 Goodbye.
Connection closed by foreign host.
にしても、こんな翻訳したやつは誰だw。
「もっと創造的になろうと努めなさい」。
tomocha.net のサーバをやっとしました。7年ぶりです。
結構色々とあって大変だったのですが、心機一転、FreeBSD10-RELEASEになりました。
元々、FreeBSD6から運用をし始め、アップデートなどを行っていたのですが、最近portsが大幅に替わり、さらに、FreeBSD9.2 から、パッケージシステム(pkg)が採用されるなど、大きく変化がありました。また、ディスク容量が足りないといった事などもあり、これを機に物理的にリプレース。
今回の環境は、NEC Express 5800/R120b-1 MEM 24GB SAS 300GB *6 RAID6 BBU有りの構成へとなり、大幅にアップグレード。早いです。モノは、
2014年5月9日 NEC Express5800/R120b-1ネタで書いていたところ。実を言うと、リプレースに当たり、東京にある生活環境兼検証・開発環境であるHP ProLiant DL360 G6 の環境で2月頃より構築開始し、本番投入機であるNEC Express5800/R120b-1が4月末に納品されました。5月に新サーバの仮想環境の構築し、奈良に設置。この時、146GBのSAS HDD が結構手元に在庫があったということ、146GB *6 RAID6 の構成では、ディスク容量が足りないと言うことで、146GB *4 で RAID1+0、そしてデータ領域として、
TOSHIBA MQ01ABD100H 1TB (5400rpm, 8GB SSD-SLC)を使用して、RAID1の構成にしました。稼働し始めて、東京の開発環境から、VMイメージをVPN経由で転送し、本番稼働に向けて最終調整などを行いつつ、本番切換を使用とした矢先、サーバ構築後、1ヶ月半でTOSHIBAのSSHDが死ぬという事態に。データが復元出来なくなりました。あきらめて、SAS 300GB の玉を8本調達し、RAID6 + BBU調達という事に。大きな痛い出費です(涙)
でシステムを改めて再構築した後、再度 tomocha.net の再構築をして、やっと本番切換が出来るようになりました。ここはOSのインストールから環境構築まで手順書を作っていたので比較的短時間で完成。今回は物理から仮想へ再構築した環境への切換なので、リモート対応でも、比較的楽です。
切替メンテナンスの流れはこんな感じ。
まず、前提条件として、
- 旧サーバは、シリアルコンソールサーバに接続されている(iLOやILOMといったBMCでも構わない)
- 物理リンクは2本
- スイッチは管理機能が有るL2スイッチ
- 新サーバはVMware上に構築
といった構成。
VMware上の新サーバは本番のIPを付与し、VMの設定でNICを切断(リンクダウン状態)にしておきます。
*1
上記とは別に、管理用の追加NICを用意し、データの転送や環境構築を行います。
Webサーバに関しては、hostsファイルを書き換え、一通り問題がないか確認、そのほかのサービスにも異常がないか、telnetなどで直接たたき動作確認を行い、最後に切換をします。
さて、いよいよ切換直前。新サーバで一通り環境構築が完了し、ネットワークの設定ファイルで管理用のネットワークの設定を削除し、ルーティングテーブルなどを本番構成にあわせて修正し再起動します。この段階ではまだネットワークに接続されていないため、ntpなど、そういった起動時に外部との通信を行うサービスが有ると、タイムアウトするまで待つのが確認されますがこの場合は無視。すべてのサービスが無事起動することを確認します。これで準備完了です。念のため、手動で管理用のIPアドレスを付与(ifconfig em2 192.0.2.100/24 など)を行い、最後にデータの同期を行います。ここはrsyncを使っています。無事に必要なデータの同期がとれたら、いよいよ切換。旧本番サーバは、シャットダウンするのではなく、接続されているスイッチのポートをシャットダウンすることにより切り離します。なぜ、このようにするかというと、新サーバで異常があった祭、すぐに元の環境に切り戻しが出来るように行っています。てことで、スイッチに投入するconfigを準備しておきます。スイッチにconfigを投入し、旧本番系の切り離しが出来たら、新サーバのVMware側の切断していたNICを接続し、サーバの再起動を行います。これで、再起動により正しく起動することを保証しています。まあ、ntpとかは手で走らせて、追加したIPアドレスなどは後で手で消してもいいんですけどね。再起動することにより、GARPを投げる事を期待し、新しいMacAddressを学習させるためでも有ります。単なるつないだだけだと学習しないケースも有りますし、GARPを手で投げる方法でもいいですが、作業を増やして確認項目を増やすより、再起動の方がシンプルという考えで行っています。
ということで、停止時間1分未満で、無事に切換が完了。ぱちぱちぱちぱち。
ちなみに旧サーバは、先ほど少し書いていますが、次のような構成。
- HP ML115 G1
- DualCoreOpteron
- DDR2 ECC 6GB
- HDDはHP純正 FB080C4080 7200RPM 80GB *2 (RAID1, Onboard RAID)
ということで、このサーバを構築しリリースしたのは、2007.11.04でFreeBSD6.2-RELEASEでした。当時、導入をした後、1週間もしない間にリブートするという問題で、システムボードの初期不良を引いてしまいました。症状としては、リブートを繰り返したり、コンソールリダイレクションを行っているが、BMCに切り替えたり出来るので、その反応すら無くなり、物理的に電源のON/OFFを繰り返さないといけないという状態ということから、
システムボードの故障だと判断し、オンサイトを呼ました。当時私は静岡にいてたので、奈良の方エンジニアを呼び、作業させるという対応。最初入館方法についてしつこく聞かれたので、だから、個人の家なのでチャイムを鳴らして入ってください。いっても、携帯の持ち込みは大丈夫でしょうか?といった、データセンターを前提としたマニュアルでのヒアリングで、ちょっとなー。と思ったのが懐かしいです。
私が管理するサーバや機器は基本的にはシリアルコンソールサーバ(Avocent Cyclades ACS 48ポート)へ接続をしてあります
*2
。
その上で、BIOSリダイレクションを行っているので、リモートからどういった確認をしているかなど、リモートからでもよく様子がわかります。システムボードを更新した後、RAIDの構成をしようとしたときに、ディスクの内容を飛ばしかけていたので即座に電話をかけて、それ、RAID飛びますよ、もう一回手順を確認して作業し直してくださいといったのが懐かしいです。そして手順を確認したら、すみません、間違えていましたと言われました。どうやら、オンボードRAIDを使ったケースの経験は無く、SmartArrayなどを使ったケースしか経験が無かったようです。最初構築するときにRAIDの復旧方法を確認するのは、基本なので…。コントローラを交換した場合の移植テストも一応やってますので、助かりました。
こういった訳ありスタートの箱でしたが、その後非常に快適に稼働をし続け、今では7年近く。ディスクについても非常によくがんばってくれて、結構高負荷なサーバだったのにもかかわらずノートラブル。本当によく頑張ってくれました。これで、しばらくしたら引退ですね。
参考にS.M.A.R.Tはこんな感じ。
# smartctl -a /dev/ad4
=== START OF INFORMATION SECTION ===
Device Model: FB080C4080
Serial Number: 5RWXXXXXXX
Firmware Version: HPF0
User Capacity: 80,026,361,856 bytes
ATA Version is: 7
ATA Standard is: ATA/ATAPI-7 T13 1532D revision 4a
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 100 253 006 Pre-fail Always - 0
3 Spin_Up_Time 0x0002 098 097 000 Old_age Always - 0
4 Start_Stop_Count 0x0033 100 100 020 Pre-fail Always - 50
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 088 060 030 Pre-fail Always - 802185935
9 Power_On_Hours 0x0032 033 033 000 Old_age Always - 59004
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0033 100 100 020 Pre-fail Always - 51
184 End-to-End_Error 0x0032 100 253 000 Old_age Always - 0
187 Reported_Uncorrect 0x003a 100 100 000 Old_age Always - 0
189 High_Fly_Writes 0x0022 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x001a 061 053 000 Old_age Always - 39 (Min/Max 17/47)
194 Temperature_Celsius 0x0000 039 047 000 Old_age Offline - 39 (0 16 0 0)
195 Hardware_ECC_Recovered 0x0032 069 064 000 Old_age Always - 72963425
197 Current_Pending_Sector 0x0000 100 100 000 Old_age Offline - 0
198 Offline_Uncorrectable 0x0000 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0000 200 200 000 Old_age Offline - 0
SMART Error Log Version: 1
No Errors Logged
# smartctl -a /dev/ad6
=== START OF INFORMATION SECTION ===
Device Model: FB080C4080
Serial Number: 5RWXXXXXXX
Firmware Version: HPF0
User Capacity: 80,026,361,856 bytes
ATA Version is: 7
ATA Standard is: ATA/ATAPI-7 T13 1532D revision 4a
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 100 253 006 Pre-fail Always - 0
3 Spin_Up_Time 0x0002 098 097 000 Old_age Always - 0
4 Start_Stop_Count 0x0033 100 100 020 Pre-fail Always - 45
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 088 060 030 Pre-fail Always - 785718509
9 Power_On_Hours 0x0032 033 033 000 Old_age Always - 59009
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
12 Power_Cycle_Count 0x0033 100 100 020 Pre-fail Always - 46
184 End-to-End_Error 0x0032 100 253 000 Old_age Always - 0
187 Reported_Uncorrect 0x003a 100 100 000 Old_age Always - 0
189 High_Fly_Writes 0x0022 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x001a 060 053 000 Old_age Always - 40 (Min/Max 19/47)
194 Temperature_Celsius 0x0000 040 047 000 Old_age Offline - 40 (0 17 0 0)
195 Hardware_ECC_Recovered 0x0032 072 063 000 Old_age Always - 205190877
197 Current_Pending_Sector 0x0000 100 100 000 Old_age Offline - 0
198 Offline_Uncorrectable 0x0000 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0000 200 200 000 Old_age Offline - 0
SMART Error Log Version: 1
No Errors Logged
時間にすると、こんな感じ。
9 Power_On_Hours 0x0032 033 033 000 Old_age Always - 59004
9 Power_On_Hours 0x0032 033 033 000 Old_age Always - 59009
おおよそ、59000時間。
計算するとこんな感じですかね。
# expr 59000 / 24
2458
# expr 2458 / 30
81
約81ヶ月。すなわち、6年と9ヶ月。不良セクタも0、代替セクタも0というすばらしい長寿命。今時こういうディスクは本当に少ないですね。80GB時代は本当に良かったです。あ、SATA HDDの話しね。
*1:
暫定の仮VLANに足をおろしておくでも構いません。
本番と同じIPにする必要があるかというと、IPベースのVHOSTが存在するためです。
*2:
iLOやiLOMといった専用ポートなどが有る場合はネットワークに収容してます
*
[Comp][Other] iPhone4S の内部フラッシュディスクの性能
すでに壊れて起動しなくなった、iPhone4S 64GBモデルがあり、脱獄し、root をとり、sshd を上げたりとUnix端末的な使い方をしていた。そのときに、ディスクベンチマークを行ったので、記録として貼り付けておく。
,iPhone4S-docomo:~ root# uname -a
Darwin iPhone4S-docomo 13.0.0 Darwin Kernel Version 13.0.0: Sun Dec 16 19:58:44 PST 2012;
root:xnu-2107.7.55~11/RELEASE_ARM_S5L8940X iPhone4,1 arm N94AP Darwin
iPhone4S-docomo:~ root# dd if=/dev/zero of=/private/var/testfile bs=512k count=1024
1024+0 records in
1024+0 records out
536870912 bytes (537 MB) copied, 15.3093 s, 35.1 MB/s
iPhone4S-docomo:~ root# dd if=/dev/zero of=/private/var/testfile bs=512k count=1024
1024+0 records in
1024+0 records out
536870912 bytes (537 MB) copied, 15.2894 s, 35.1 MB/s
iPhone4S-docomo:~ root# iostat 1
disk0 cpu load average
KB/t tps MB/s us sy id 1m 5m 15m
0.00 0 0.00 5 0 95 0.09 0.38 0.37
0.00 0 0.00 8 0 92 0.08 0.38 0.36
2048.00 19 37.89 17 0 83 0.08 0.38 0.36
459.09 79 35.33 25 0 75 0.08 0.38 0.36
1398.81 27 36.80 18 0 82 0.08 0.38 0.36
1934.44 18 33.90 17 0 83 0.08 0.38 0.36
1843.60 20 35.90 14 0 86 0.08 0.37 0.36
685.33 18 12.01 12 0 88 0.08 0.37 0.36
1843.80 20 35.90 16 0 84 0.08 0.37 0.36
1769.27 22 37.89 18 0 82 0.08 0.37 0.36
1945.80 20 37.91 18 0 82 0.08 0.37 0.36
1832.84 19 33.90 15 0 85 0.07 0.36 0.36
1877.67 12 21.93 13 0 87 0.07 0.36 0.36
1676.55 22 35.90 17 0 83 0.07 0.36 0.36
disk0 cpu load average
KB/t tps MB/s us sy id 1m 5m 15m
1476.80 25 35.80 17 0 83 0.07 0.36 0.36
1940.42 19 35.91 18 0 82 0.07 0.36 0.36
1843.60 20 35.90 12 0 88 0.15 0.37 0.36
550.13 15 8.03 4 0 96 0.15 0.37 0.36
0.00 0 0.00 5 0 95 0.15 0.37 0.36
0.00 0 0.00 2 0 98 0.15 0.37 0.36
0.00 0 0.00 4 0 96 0.15 0.37 0.36
性能は、昔のIDEのHDD並みというか、USB3.0並と言ったところだろうか。書き込みテストしかしていないが、その程度と思っていただければよい。結果、無線LANで11nの環境が有れば、無線の帯域はフルに使用し、データ転送は可能なレベルであることは解った。
こういうのってさ、IPカメラとか、プリンタとか、そういったデバイスは一度設置すると、動作しなくなるとか、設定変更するまで放置される傾向にあるし、設定変更のタイミングですら放置するのが世の中の大半なので、ゴロゴロとのぞき見し放題のカメラが世の中に放出されたってことになるよね。ニヤニヤ。楽しそうな世の中になりそうだ。どうやら影響を受ける機種は津後の通り。
- TS-WLCAM ファームウェアバージョン 1.06 およびそれ以前
- TS-WLCAM/V ファームウェアバージョン 1.06 およびそれ以前
- TS-WPTCAM ファームウェアバージョン 1.08 およびそれ以前
- TS-PTCAM ファームウェアバージョン 1.08 およびそれ以前
- TS-PTCAM/POE ファームウェアバージョン 1.08 およびそれ以前
- TS-WLC2 ファームウェアバージョン 1.02 およびそれ以前
最近のこの手のって、ファームウェアの自動更新って有効になってるんだっけ?とおもって、マニュアルをみたら、自動更新が出荷時設定になっているようなので、一応大丈夫ってことかな。LANで使用している場合はまあ 、そこまでたいした害はなさそうだし。
ま、余り気にする必要は無かったって事で。楽しいネタがあるかなぁとおもったが、期待はずれ。残念。
病院と次の仕事が決まったので就職に関する書類をやりとりするために目黒方面へ。
久々のランチ。ちょっとしたセレブ気分が味わえて素敵ですね♪
メイン。
ああ、おいしかったー
*
[Life] 入社手続き&契約書類やりとり
契約書類のやりとりをきちんとすませました。というのも、以前は超ひどくて、入社前に提示があった額面に対してOK(月41.1万)をだして、入社ということにしました。そのために静岡の会社を退職していたのですが、東京の家が決まり、引っ越ししている最中で、入社予定日の5日前に、条件変更(25.1万)されました。ちなみに正式な書面として、代表印のある採用通知書です。ただ、了承は口頭ベースだったので、正式に契約書を交わして、その金額でやるというのをやっていませんでした。
当初承諾した採用通知
変更された採用通知
入社誓約書には、額面が入っていないこと、入社時でいいですよってことでしたので、書面上でのやりとりは無しです。
しかも、ごねたとしても借金を作り、引っ越し費用を借りて、東京に出てきて、すべて破談すると、借金だけが残ります。なので、仕方なく了承せざる得ない状況でした。ちなみに、毎月60時間残業すれば、とりあえずは同じ金額になるよと言われ、渋々了承せざる得ない状況でした。最初の頃は、事業立ち上げでやりたかったことを普通では出来ない経験をさせてもらえたので、その間は辛抱して、自分の技術を磨くことに専念し、落ち着いたら転職をしようとずっと考えていたってことですかね。ま、事実上終わったわけですが。給料については色々ともめましたが最終的にはいくつか改善されましたが、当時の借金が多くて結構つらかったですよ。引っ越しに100万程かかっているわけで…。ちなみに、引っ越し費用を見積もり取ると520万円でしたので、自前で2トン車借りたり、ワゴンを借りたりして自前で引っ越ししました。手伝ってくれた人に感謝。借金返済には丸々3年かかりました。アルバイトや副業(請負)やアフィリエイトなどで何とかしないとまわりませんし、家賃も12万です。家の更新費も東京ではかかると言われ(大阪や静岡の時は、更新費とあっても、実際に払ったこと無い。)、それも支払ったりしていましたから…。
アフィリエイトだけで100万を超える収益を作ることが出来ました。借金返済の大半はこれで何とかしました。やっぱり、でかい…。
さすがに、一部上場の会社ではそういう変なのはないとおもっていたが、見事に引いてしまったので、今回の転職では、非常に慎重になってました。
そういうわけで、今回は過去にあった二の舞を踏まないようにするため、入社に関する契約関係の書類は事前にお互いの捺印を持って事前に済ませるため、次の会社(目黒)へ事情を説明し、すべて事前にすませました。ということで、入社予定日は9月からです。
んで、契約書をすませた後、次の会社の同僚になるひとと一緒にご飯を食べに行きました。
これで、やっと、普通の人になれるといいなぁ。
*
[遊び] 尾瀬岩鞍
尾瀬岩鞍スキー場は冬の顔。夏などは、どうなっている勝手言うと、ゆり園になっているらしく、
尾瀬岩鞍ゆり園マップというのがあった。よーく見ていると、
岩藏リゾートホテル、
レストラン オクタがあり、これ、どうみても、
尾瀬岩鞍スキー場のゲレンデだよなぁと思ってしまった。
比較してみるとこういう感じ。
ゲレンデマップでいうコースの3番と4番あたり。あそこがゆり園になるのねと。てことは、冬場は百合園の場所を踏みつけているのね。ということで、少し複雑な気分でした(^^;
先日から 2ch.net がみれないなぁとおもっていて、調査をしてみたところ、206.223.154.230 [www.2ch.net] に繋がらないだけではなく、名前解決も出来ていなかった。他の環境では、名前解決も出来るし、アクセスも出来る。ちなみに私の生活環境は、さくらのVPSの上と自宅のVMware上のWindows環境だ。基本的には、ssh -D が大好きな環境ということを前提だ。んで、引ける別環境から調べてみると、2ch.net の 権威NSサーバは次の通り。
;; QUESTION SECTION:
;2ch.net. IN NS
;; ANSWER SECTION:
2ch.net. 163 IN NS ns2.nttec.com.
2ch.net. 163 IN NS ns1.nttec.com.
;; ADDITIONAL SECTION:
ns1.nttec.com. 98648 IN A 206.223.144.254
ns2.nttec.com. 21 IN A 206.223.146.254
上記二つに対して、そもそも到達性がない。純粋に、さくらのVPSで使っている 210.224.163.4 及び 210.224.163.3 から到達性が無く、名前解決が出来ていないかだけなのかなとおもったら、手元のVPSからも到達性がなかった。ちなみにいくつかさくらのVPSを保有しているが、次のネットワークから到達性がなかった。
- 153.121.32.0/19 旧株式会社クラスト
- 219.94.128.0/17
- 59.106.0.0/16
- 182.48.0.0/18
- 210.224.160.0/19
この4つのブロック以外の次のものについては未確認(環境がないので)。
- 61.211.224.0/20
- 103.10.112.0/22
- 103.250.200.0/22
- 112.78.112.0/20
- 112.78.192.0/19
- 133.242.0.0/16 旧株式会社建築システム
- 153.121.64.0/19 旧株式会社クラスト
- 157.17.128.0/17 旧麗澤大学麗澤大学
- 160.27.0.0/16 旧株式会社管理工学研究所
- 202.181.96.0/20
- 202.222.16.0/20
- 210.188.192.0/19
- 210.188.224.0/19
- 210.229.64.0/21
- 49.212.0.0/16
そのほかの環境で正常に到達性が有る場合は、次のようになる。
$ traceroute ns1.nttec.com
-----
13 * ae1-80g.cr1.sfo1.us.nlayer.net (69.22.143.169) 136.972 ms 147.673 ms
14 cent-dmarc.gt-t.net (98.124.130.206) 136.475 ms 126.539 ms 140.623 ms
15 nttec-demarc.cr02.centaurico.com (208.74.65.6) 137.670 ms 137.892 ms 141.295 ms
16 ns1.nttec.com (206.223.144.254) 138.313 ms 127.277 ms 120.655 ms
$ traceroute ns2.nttec.com
-----
13 ae1-80g.cr1.sfo1.us.nlayer.net (69.22.143.169) 162.633 ms 135.416 ms 134.846 ms
14 cent-dmarc.gt-t.net (98.124.130.206) 131.001 ms 123.646 ms 130.766 ms
15 nttec-demarc.cr02.centaurico.com (208.74.65.10) 137.945 ms 140.936 ms 130.759 ms
16 206.223.146.254 (206.223.146.254) 129.526 ms 134.333 ms 137.221 ms
$ traceroute www.2ch.net
-----
13 ae1-80g.cr1.sfo1.us.nlayer.net (69.22.143.169) 152.578 ms * 139.815 ms
14 cent-dmarc.gt-t.net (98.124.130.206) 129.471 ms 126.804 ms 134.731 ms
15 nttec-demarc.cr02.centaurico.com (208.74.65.10) 142.490 ms 134.795 ms 130.499 ms
16 206.223.154.230 (206.223.154.230) 136.718 ms 132.965 ms 133.436 ms
さくらのネットワークから試すと次のようになる。
$ traceroute 206.223.144.254
-----
13 ae1-80g.cr1.sfo1.us.nlayer.net (69.22.143.169) 116.715 ms 115.961 ms 116.165 ms
14 cent-dmarc.gt-t.net (98.124.130.206) 125.603 ms 125.567 ms 125.525 ms
15 * * *
$ traceroute 206.223.146.254
-----
13 ae1-80g.cr1.sfo1.us.nlayer.net (69.22.143.169) 112.592 ms 112.575 ms 110.053 ms
14 cent-dmarc.gt-t.net (98.124.130.206) 119.783 ms 125.586 ms 126.700 ms
15 * * *
$ traceroute 206.223.154.230
-----
13 ae1-80g.cr1.sfo1.us.nlayer.net (69.22.143.169) 115.959 ms 117.026 ms 112.617 ms
14 cent-dmarc.gt-t.net (98.124.130.206) 122.428 ms 119.754 ms 119.862 ms
15 * * *
さらに気になったので調べてみたところ、N.T. Technology (AS32335) の他のネットワークに繋がるかチェックしてみたところ、次のような結果が得られた。
まずは、AS32335 から広告されている経路(prefix)一覧は次の通り。
今回は、
さくらのLooking Glassが使用せず、それ以外の一つである
Public Route Servers @WideProjectを使用する。
route-views.wide.routeviews.org> show ip bgp regexp _32335$
BGP table version is 0, local router ID is 202.249.2.166
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 67.219.0.0/20 202.249.2.169 0 2497 4436 19214 32335 i
* 202.249.2.86 0 7500 2497 4436 19214 32335 i
*> 204.63.0.0/20 202.249.2.169 0 2497 4436 19214 32335 i
* 202.249.2.86 0 7500 2497 4436 19214 32335 i
*> 206.223.144.0/20 202.249.2.169 0 2497 4436 19214 32335 i
* 202.249.2.86 0 7500 2497 4436 19214 32335 i
*> 207.29.224.0/20 202.249.2.169 0 2497 4436 19214 32335 i
* 202.249.2.86 0 7500 2497 4436 19214 32335 i
*> 207.29.240.0/20 202.249.2.169 0 2497 4436 19214 32335 i
* 202.249.2.86 0 7500 2497 4436 19214 32335 i
上記のPrefix が広報されていると言うことなので、さくらのネットワークから、下記のネットワークに到達性があるか確認してみる。先ずは正常に応答する、さくらのネットワーク以外の結果のケース。
$ ping -c 2 67.219.0.1
PING 67.219.0.1 (67.219.0.1) 56(84) bytes of data.
64 bytes from 67.219.0.1: icmp_req=1 ttl=238 time=130 ms
64 bytes from 67.219.0.1: icmp_req=2 ttl=239 time=130 ms
$ ping -c 2 204.63.0.2
PING 204.63.0.2 (204.63.0.2) 56(84) bytes of data.
64 bytes from 204.63.0.2: icmp_req=1 ttl=239 time=112 ms
64 bytes from 204.63.0.2: icmp_req=2 ttl=239 time=119 ms
$ ping -c 2 206.223.144.2
PING 206.223.144.2 (206.223.144.2) 56(84) bytes of data.
64 bytes from 206.223.144.2: icmp_req=1 ttl=238 time=127 ms
64 bytes from 206.223.144.2: icmp_req=2 ttl=239 time=123 ms
$ ping -c 2 207.29.224.2
PING 207.29.224.2 (207.29.224.2) 56(84) bytes of data.
64 bytes from 207.29.224.2: icmp_req=1 ttl=240 time=132 ms
64 bytes from 207.29.224.2: icmp_req=2 ttl=240 time=122 ms
$ ping -c 2 207.29.240.2
PING 207.29.240.2 (207.29.240.2) 56(84) bytes of data.
64 bytes from 207.29.240.2: icmp_req=1 ttl=240 time=123 ms
64 bytes from 207.29.240.2: icmp_req=2 ttl=240 time=123 ms
さくらのネットワークから
$ ping -c 2 67.219.0.1
PING 67.219.0.1 (67.219.0.1): 56 data bytes
--- 67.219.0.1 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
$ ping -c 2 204.63.0.2
PING 204.63.0.2 (204.63.0.2): 56 data bytes
--- 204.63.0.2 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
$ ping -c 2 206.223.144.2
PING 206.223.144.2 (206.223.144.2): 56 data bytes
--- 206.223.144.2 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
$ ping -c 2 207.29.224.2
PING 207.29.224.2 (207.29.224.2): 56 data bytes
--- 207.29.224.2 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
$ ping -c 2 207.29.240.2
PING 207.29.240.2 (207.29.240.2): 56 data bytes
--- 207.29.240.2 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
さらに、調査をしてみたところ、ルータやL3のPoint-to-Point なダイナミックルーティングに使用するネットワークは、/30 であると思われることから、208.74.65.6(nttec-demarc.cr02.centaurico.com) 及び、その対向ルータ(208.74.65.5)と、208.74.65.10(nttec-demarc.cr02.centaurico.com)及びその対向ルータ(208.74.65.9)に対して、ping応答があるか確認してみた。
先ずは正常なパターン。
$ ping -c 2 208.74.65.6 # N.T. Technology 側
PING 208.74.65.6 (208.74.65.6) 56(84) bytes of data.
64 bytes from 208.74.65.6: icmp_req=1 ttl=239 time=132 ms
64 bytes from 208.74.65.6: icmp_req=2 ttl=240 time=125 ms
$ ping -c 2 208.74.65.5 # 上位キャリア側
PING 208.74.65.5 (208.74.65.5) 56(84) bytes of data.
64 bytes from 208.74.65.5: icmp_req=1 ttl=240 time=117 ms
64 bytes from 208.74.65.5: icmp_req=2 ttl=240 time=159 ms
$ ping -c 2 208.74.65.10 # N.T. Technology 側
PING 208.74.65.10 (208.74.65.10) 56(84) bytes of data.
64 bytes from 208.74.65.10: icmp_req=1 ttl=240 time=128 ms
64 bytes from 208.74.65.10: icmp_req=2 ttl=240 time=118 ms
$ ping -c 2 208.74.65.9 # 上位キャリア側
PING 208.74.65.9 (208.74.65.9) 56(84) bytes of data.
64 bytes from 208.74.65.9: icmp_req=1 ttl=240 time=117 ms
64 bytes from 208.74.65.9: icmp_req=2 ttl=240 time=123 ms
さて、さくらのネットワークから。
$ ping -c 2 208.74.65.6
PING 208.74.65.6 (208.74.65.6): 56 data bytes
--- 208.74.65.6 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
$ ping -c 2 208.74.65.5
PING 208.74.65.5 (208.74.65.5): 56 data bytes
64 bytes from 208.74.65.5: icmp_seq=0 ttl=245 time=124.915 ms
64 bytes from 208.74.65.5: icmp_seq=1 ttl=245 time=124.883 ms
$ ping -c 2 208.74.65.10
PING 208.74.65.10 (208.74.65.10): 56 data bytes
--- 208.74.65.10 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
$ ping -c 2 208.74.65.9
PING 208.74.65.9 (208.74.65.9): 56 data bytes
64 bytes from 208.74.65.9: icmp_seq=0 ttl=245 time=115.100 ms
64 bytes from 208.74.65.9: icmp_seq=1 ttl=245 time=115.097 ms
ということで、N.T. Technology, Inc. の入り口のルータで止められていると思われる。純粋にそのルータはBGPルータ(AS32335)と思われることから、さくらのAS(AS9370/AS9371)からの経路をFilterしているのではないかと思う。ルータで、パケットフィルタをするとは考えにくいし…。それによって、さくらからの経路を知らないので、パケットがルータ内で破棄され、繋がらないのではないかと。ということで、2ch及び、N.T. Technology 宛の通信はすべて受けとらねーよという意志ですか、ええ、私みたいなユーザもアクセスするなって事ですか。しょんぼり。見たいときは、BiglobeのSIMからみますよ、えぇ。ほんとにね。若しくはどっかの箱に入って、w3mでみますともさ。
ちなみに、もしBGP 経路情報を元にやっているのであれば、さくらのネットワーク(コロケーションもしくはハウジングの大口顧客である、エクスサーバの環境からアクセスできるか気になるところ。
事の発端はおそらく、ひろゆき(2ch.sc)との間の派閥の問題ではないか。次のまとめが参考になるかもしれない。
この件で、さくら関係者というのはいまいちわからない。なぜならば、レンタルサーバではSSHの開放をしているし、自由にプログラムのコンパイルも可能だ。また、VPSなども、ユーザーで自由にコントロールをすることが出来る。むろん、さくらの内部の人が正規ユーザとしてサーバを借りてやっている可能性はあるとしても特権を乱用することは、まず無いだろう。そこまで愚かではないと思われる。また、さくらのネットワーク上にあるサーバ以外からもいくつか確認されていることから、内部の人が特権を利用しているとは考えにくい。
Diary for 21 day(s)