2003/1/22 ルータ
新しく入れてみたルータがダメダメ。firmの更新に期待しよう。
というわけで、しばらくは前のルータで運用。
あぁ、日立のGR2000-1Bとか欲しいなあ。
高くて手が出ないけど。
2002/12/17 aliases
なぜだぁ。aliasesは変更した後に、流行通り/etc/mailでmake aliasesしたはずなのに。
しかしまあ転送されてなかったんだから、きっと間違ってたんだろうな。
御迷惑をお掛けしたユーザの皆様には、ほんとにごめんなさい。
ところで、ストレージ障害の件で少しだけRAID5に心がひかれました。
でも、きっと僕が買えるのはDiskの状態が監視できないとか、そうゆうなんちゃってRAIDになるだろうから、やっぱり壊れたのが分かるのはRAID的な復旧ができなくなってからだったりするんだろうな。
さらに安物を買っちゃうだろうから、そもそもRAIDカードの不具合とかで悩まされそうな予感。
てなわけで、あきらめて生Diskで組む事にしました。
2002/12/15 ストレージ
実は、先日からサーバで特定のファイルを読もうとすると、ストレージがhard errorを起こすようになってました。
運良くサービスには影響しない部分だったので換えのストレージだけ用意して運用を続けてましたが、一昨日この絡みでsshdがvm_faultでcore dumpしてしまい、コンソールをとってなかったので事実上remoteからの制御手段が無くなってしまいました。
何とかremoteから制御しようとatackまがいの手法をいろいろ試しましたが、こまめなパッチ当て等の真面目な運用がたたって、脆弱性が無いんです。
あきらめて入れ換え用のストレージ用意。システム部分は気持良く新しくインストール。設定ファイルはバックアップから吸い上げ。
最後にサーバを止めてストレージを入れ換え、ユーザのデータを新しいストレージにコピー。幸いエラーは無かった模様。
最後に細かい設定をごにょごにょして完成。
入れ換え用のストレージを準備するときに適切なマシンが無くて、ちょっと大変でした。
2002/07/09 wwwサーバ
心からごめんなさい。ifconfigはいつからあんな仕様になったんだ?
いや、ifconfigというかkernelか。。。むぅ
しかも作業中に寝てしまって(ごめんなさいごめんなさいごめんなさい)障害が長引いたなんて普通書けません。
まあしかし、これで以前のサーバに比べてCPUクロック比で16倍の高速マッシーンになりました。
cgi等で体感できる程度には速くなってるはずですし、以前と違って多少の無茶はできるかと思われ。
回線速度に負けることもないはず。
2002/06/13 またISP変更
そろそろ別なASに住んでみたかったので、今度はKDDIに契約してみました。
でもAS2516じゃなくてAS4732なPAアドレス。残念。
これでwww.freak.ne.jpは帯域的には有り余る状態になりました。
少々のデータ転送ではびくともしません。
でも今度はマシンスペックが問題になってくるなあ。
回線速度よりホストのインタフェースの方が遅いなんて、大っぴらには言えないよねえ。
2002/03/20 hostname
某氏にはづかしいからそのホスト名止めろと言われて、素直に変更。
2002/02/21 MTV2000
夕方にふと欲しくなって、秋葉原へレッツゴー。
流石に予約無しでの購入はつらいかと思われましたが、何店舗かうろうろしてたら店頭陳列用に開封済のものが一個だけ残っていたので、すかさずそれを購入。
早速会社でMTV1000と比較してみました。基本的なソフトウェアはMTV1000と一緒。
すぐに気が付くのは、やはりMTV2000のゴースト低減機能でしょう。
ゴーストの酷いチャンネルを見ても、結構な精度でゴーストが消えてました。
それから、同じアンテナからの信号をMTV1000とMTV2000のそれぞれのチューナーに入れて並べて見ると、なんだかMTV2000の方が綺麗で見やすい。ふむ。
しばらく遊んでみることにします。
2001/12/25 ADSLとPPPoEのMTU
既に多くのサイトで語り尽くされているであろうネタ。
世の中にはICMPを有無を言わさず落しているタコな組織が多いようですが、ほんとにTCP/IPを理解してその設定してるんでしょうか。
ほんとにICMP要らないの？
最低でも、PMTUを使うかICMPを落すかのどちらかを選んで欲しいもんです。
おかげでパケットが大きくなる方向によっては通信が成立しなくて困ったもんです。
それにしてもunreach等の有用な情報をわざわざ落してしまう人の気が知れない…。
2001/7/6 壊れもの
暑くなったせいか、ただ古くなったためかサーバ類がよく故障する。
こないだは自分が住んでるホストの電源ファンが死んで、熱暴走でやられた。
IPv6のtunnnelもそのホストで受けていたので復旧まで少し不自由した。
今日はwwwサーバのDISKがやられた。復旧できたから良かったけど。
さて、次は何が壊れるかな。
2001/7/2 ADSL
自宅にADSL回線を引いてみた。
回線としてeAccessとNTTのFLET'S ADSLという選択肢があったので、ひとまず両方引いてみる。
自宅がNTT局に比較的近いためか、どちらの回線でも下り方向で1Mbps程度の帯域は普通に利用できるようだ。
てなことがあって、試しにwwwサーバをADSL回線側に移してみました。
これでしばらく様子を見てみることにしましょう。
2001/4/16 JPドメイン
Freak.jp取れたので、設定してみた。www.freak.jpとか。
ユーザの方々のページも同じようにne無しで見られるようにしちゃいました。
2000/11/27 日本語ドメイン
たぶん流行らないと思う。
なんせ日本語は入力するのがめんどくさい。
2000/8/10 雷のこと
最近雷が激しくて、時々電源が瞬停しているようです。
UPSを買う金などあるわけもなく、rebootするにまかせているんですが、古い機器は瞬停などものともせず、何事も無かったように動き続けてます。
消費電力の問題か電源の作りの問題か分からないけど、おかげで古いマシンほど安定して稼働してます。
2000/4/17 DNSサービス
きっかけは、友人がCATVで接続しているマシンにホスト名をつけてみたこと。
これが意外に面白くて夢がひろがったので、さくっと作り込んでみました。
対象はダイヤルアップユーザとかですかね。
CATVユーザの方は、サーバ(外部からアクセスされるサービス)を禁止している場合があるのできちんと約款を読んでから利用してください。
2000/2/23 ヘッドハンティング
昨年末ぐらいから、ヘッドハンティング会社のエージェントさんに声をかけられてます。
もっぱら外資系の会社に人材を紹介しているらしく、エージェントさんもアメリカ人なのでコミュニケーションは全部英語なんです。
システムとしては、オイラに合いそうな外資系の会社をメールで紹介してくれます。
基本的にはメールに簡単な企業紹介とURLが書かれててWEBを見ろということなんだけど、いくつかコメントも書かれています。
「SALARY - up to %10m plus pre-IPO stock」って書かれても、最初はなんの事か分からなかったです。
で、オイラがその会社に興味を持ったら、そこの会社の人とのミーティングをアレンジしてくれるらしい。
毎回丁重に断ってるんだけど、週休3日で給料1000万とか言われたら、思わず心が動いちゃいますね。
不思議なのは彼らエージェントさんはどこで収入を得ているのかという事。
ヘッドハンティングが成功した暁にはどっかから手数料みたいなのをもらうんでしょうかねぇ。
2000/1/29 DNSキャッシュのたたき落とし
こないだ、DNSで遊んでた時に気が付いたんだけど、あるバージョンのBINDに変なDNS queryを出すと、そのレコードに対するキャッシュ期間が激減してました。
いくつかの DNSで試してみたんだけど、確かに23HぐらいTTLがあったキャッシュが数分で消されてしまいました。
ウーム、謎。
もう少し、詳しく調べてみることにします。
2000/1/10 テレビ
友人がわが家に遊びに来て、テレビをつけて一言。
「映りが悪すぎる。」
ガサゴソ調べて、さらに一言。
「UHFとVHFのアンテナが逆にささってるよ。」
OH!テレビなんてほとんど見ないので気にしてませんでした。
そもそも兄の嫁が高校生時代に使っていた物なのでかなり古い。
てっきりこんなもんだと思ってたら、大間違いでした。
今さらながらにテレビの映像ってきれいだなぁ…。
以前はテレビがなくてラジオだけがありました。
NHKの集金の人が来た時に「ラジオしかないんですけどいくらですか？」って聞いたら、「受信料は必要ありません」って言われて悲しい思いをしたのも今では良い思い出。
さぁ、これで受信料を払える条件は整った。
後は集金の人を待つばかり。
2000/1/1 引っ越しとTTL
サーバを複数台用意できないような貧乏なネットワークが引っ越そうと考えると、DNSのキャッシュが大きな問題になります。
Mailは複数の MXを書いておけば配送されてくるメールをロストすることはない(一部の、MXをちゃんと見ないタコな実装はそもそも無視;-))ので安心ですが、コンテンツサーバに対する Aレコードはきっちり TTLが効いてくるので大変です。
まあ、どうせ移転元から移転先にサーバを移動させるので、この移転時間に対して十分短い TTLであればほとんど問題にならないはずです。
ところが、TTLを間違って86400(1日)にしてると、影響があとまで響きまくり。
DNSのキャッシュは、まずいと思ったときにはすでに後の祭りなので、気をつけましょう。
そうそう、探していた 2EDのフロッピーディスクが手に入りました。
これでようやく 3Comのルータが駆動できるぜぇ。
1999/11/23 引っ越しと回線
ご迷惑お掛けしております。
なんでこんなに手間取っているかというと、引っ越し先では今利用しているサービスが受けられないのが大きな原因です。
事前にもうちょっと確認しとくんでしたねぇ…。
しょうがないので、現在の契約を解約して他社のサービスを申し込むことになりました。
この新規申し込みに多少手間取ったため、開通日がみるみる延びてしまい、引っ越ししてからしばらくたたないと回線が開通しないことになってしまいました。
ごめんなさい。
ときに、本日サーバ群を除いた生活道具一式を、先に引っ越し先に持っていきました。
運び出しから、引っ越し先への運び込までで 1時間30分。
荷物が少ないので簡単でした。
とはいっても、東京に出てきたときの引っ越し荷物が段ボール5箱(内4箱はパソコン)だった事を考えると、着実に荷物は増えています。
そろそろ要らないものを人に譲ろうかな。
1999/10/3 そういえば新規申し込みのこと
進んでません。ごめんなさい。
こんなところを読んでいるような人は、既にユーザの方か知り合いぐらいでしょうから、ここで謝ってもしょうがないですかね。
メーリングリストサーバの立ち上げとかやりたいことはいっぱいあるんですが、なにせ生活に余裕が無い。
金とか時間とか(笑)
むぅ。何とか実現できるように頑張ります。
そういえば、shellサーバを立ち上げると言っといてそのままになってるな。これも何とかしないと。
1999/10/2 DNSとキャッシュと
アクセスを高速化するため／無駄なトラフィックを減らすためにキャッシュという技術があります。
直感的に分かる通り、キャッシュと変化する情報ってのは仲が悪いです。
そして、インターネットは常に変化し続けているのでキャッシュ問題は日常茶飯事です。
専用線接続でプロバイダの移行時に問題になるのが DNS情報の書き換えです。
丁寧にやろうとすると、移行元、移行先のプロバイダ、DNSの管理者という３者の連携が必要です。
この辺を理解しないで適当にやろうとすると、数日間メールが届かない等悲惨な状況となります。
私が実験したところ、TTL=1dayで、NSレコードの切り替えから概ね数日で９割程度が新しいサーバを参照するようになりました。
なお良く分からないのが、１ヶ月経っても古いサーバに参照にくるパケットがあったことです。
結論としては、腐ったキャッシュ機構を備えた DNSサーバがあるので DNS情報の書き換えには十分注意しましょうということです。
キャッシュ問題は一元管理されていないインターネットでは面白いテーマだと思います。
1999/8/20 Internet Explorer 5.0なこと
Internet Explorer5.0は 指定のページにアクセスすると、そこにある favicon.ico というファイルを読み込もうとします。
そのディレクトリに無かったら、さらに上のディレクトリを探しに行くようです。
favicon.icoが見つかると、そのページを「お気に入り」に追加したときに使用される ICONになります。
というわけで、こっそり ICONを置いてみました。
わはは、お手製です。絵心は無いので勘弁してください。
しかも手元に Internet Explorer 5.0が無いので、自分ではまだ試していません。
邪魔だったら消すので言ってください。
1999/7/28 障害と対応と
昨日発生した障害は、実はほぼリアルタイムに検出していました。
会社にいたので、なんとかリモートから復旧させようとしたんですが、予備系のラインまで死んでいて、リモートでは手の打ちようがありませんでした。
そんな日に限って仕事が遅くまでつまっていて、帰ってきたのは29日の朝4時前。
てなわけで、障害発生から復旧まで時間がかかってしまった言い訳です。
ごめんなさい。
1999/7/28 Looking Glass
世の中には経路を確認するための Looking Glassというサービスが存在します。
もっぱら有志のボランティアで運用されています。
Freak.ne.jpでも IPv6ベースの Looking Glassもどきをつくりました。
MEGANEKKO(obsolute 2002/03/20,now query.freak available)です。
leafサイトだし、試せることも少ないんだけどね。。。
1999/7/17 新しい回線 その２
てなわけで、新しい回線の方に WEBサーバを移設しました。
一部のサイトで DNSのキャッシュが古いまま保持されていて、通信障害発生。
ユーザのみなさんごめんなさい。
言ってもらえれば、いくらでも謝ります。
それにしても、次に引っ越すときは大変だなぁ…。
1999/7/5 IPv6と kernelと
今日、ふと思い付いた。
「逆引きが変なのは、IPv6の socketに無理矢理 IPv4をのせてるから…？」
早速 kernelを再構築、再起動。
netstatで確認すると、予定通り tcp6でのみ LISTENになっている。
ドキドキしながら IPv4用の daemonを立ち上げてみる。
すなおに立ち上がる。
ログをとりながら動作確認。
逆引きも完璧。動作も良好。
教訓 「無理矢理はいけません。」
1999/7/1 新しい回線 その１
わはは。
もう一本インターネットへの接続回線を手配しました。
来月にはつながるでしょう。
これで給料の手取りがほとんどインターネット接続に消えていきます。
なんと、普通にごはんを食べたらもう赤字。
ガス、水道、電気に電話も気をつけとかないとすぐに赤字。
恐ろしいですね〜。何考えてんでしょうかねぇ。
1999/6/12 マルチホーム接続しているプロバイダのお話
よくプロバイダの広告とかで
「****に 100M、XXXXに 45Mで接続！！」
とか書いてあるけど、ホントに制御してそれぞれの回線を使い分けられてるのかな？
マルチホーム接続を実現する解はいろいろあるけど、ほとんどの大手プロバイダが使っている方法に BGP4を使って動的に経路制御する方法があります。
BGP4による経路制御では通信時の「行き」と「帰り」の経路を制御を行う方法が異なります。
「行き」の経路を制御するには、BGP4によって得られた経路情報をそのまま運用するか、経路情報に手を加えて制御することになります。
「帰り」の経路を制御するには、自分が広報する経路の一部を prependするなどして制御することになります。
大味な設定をすると、回線の使い分けも大味になるので、トラフィックの傾向を見ながら細やかに設定してやる必要があります。
でも、細やかな設定ってのはめんどくさい上に、下手な設定だとルータの負荷が上がって不安定になります。
この辺をうまく設定できているかが問題になるんですが、大丈夫ですかねぇ…。
1999/6/8 IPv6なネットワーク その３
sendmail6では配送できない宛先発見。
とりあえず、嘘臭い設定変更で急場をしのぐ。
その後、順調に見える。
根本的な解決のためには sendmailの sourceを見ないといけないらしい。
全然関係ないけど、最近ようやくいろいろな広告メイルが来るようになった。
ただ、良く見てみると送信元のサーバが一緒。
どっかのだれかが、Webを自動で検索するか何かして、名前とメイルアドレス、Webページのタイトルなどをデータベース化している模様。
おかげで文中には必ずといっていいほど、「あなたのページを拝見してメールを送信しています。」みたいな文章が織り込まれている。
まぁ、そうなんだけどねぇ…。
まじめに読ませるには、もう一工夫必要といったところか。
1999/5/26 IPv6なネットワーク その２
ついに sendmail6で運用開始。
なぜか、IPv4からのアクセスでの逆引き認証がおかしい。
…そのうち直すことにしよう。
たぶん sendmail.cf をちゃんと書かないといけないんだろうなぁ。
mail.freak.ne.jpの IPv6アドレスは 3ffe:507:105:1::30。
nslookup -q=aaaa mail.freak.ne.jp
などとするとこのアドレスが見えます。
もちろん、逆引きだって見える。
nslookup -q=ptr 3ffe:507:105:1::30
要は 0.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.5.0.1.0.7.0.5.0.e.f.f.3.ip6.int.
信じられないぐらい設定がめんどくさいです。
1999/5/18 IPv6なネットワーク その１
Freak.ne.jpのサーバ群を IPv6 reachableにする計画を実行中です。
トンネルやルータの設定や、ネームサーバのまわりは大分片付きました。
いまはメイルサーバでつまづいてます。
HTTPも FTPも SSHも POP3も IPv6を聞いてくれるのに、SMTPだけうまくいかん。
どうも、環境変数の受け渡しの辺りが怪しい模様。
こうなったら、qmailをやめて、sendmailも試してみようかな〜。
1999/4/7 わいせつ画像ってなんかひっかかるんだよねぇ。その2
わいせつ、わいせつって連呼してるとわいせつな人間になってしまうのだろうか。
とまあ、そんなことは置いといて、わいせつ関連で心配事の一つに netnewsがあります。
だってほら、世界規模で膨大な量のいわゆるわいせつな画像が流れてるでしょ。
あれにプロバイダの注意義務とかついたらプロバイダがやってる netnewsの運用って崩壊するよね。
有名どころのプロバイダでそろそろ 1日当り 30GBぐらいの流量になっているんじゃないでしょうか。
そんなのチェックできないし、いっそのこと止めちゃった方が楽という話になりそうで恐いです。
1999/3/27 わいせつ画像ってなんかひっかかるんだよねぇ。
画像を見れば(おそらく)わいせつなんだろうなぁってのは分かるんですが、なんかひっかかるんですよ。
だって、わいせつな画像ファイルって所詮ただのビット列でしょ。
それを言い出したらビデオテープも所詮、磁気のならびなんていう話になるのかな。
ところが、ビデオと違うのは再生(展開、デコード、表示等なんでもよい)のために使用するものもビット列に過ぎず、各種プログラムとして多種多様に存在すること。
あるビット列をどう解釈するかは、使用するプログラムによって違ってる。
さらにはあるビット列を取り込むことによって、プログラム自体が自らを書き換えつつ何かを実行することも可能ですよね。
するとだ、ビット列の変換によっては警視庁の Webにリンクしてある画像をわいせつ画像として表示するプログラムもありえますね。
う〜ん、まだすごく詭弁だな。
1999/3/17 ログログ
アクセスログなどは適当にとって保存してます。
ユーザの人にはほとんど見せることはないけど、CGIのデバッグ情報とかなんか困ったことがあったら該当部分を切り出して渡すこともあります。
そこはそれ、趣味でやってるサイトなので融通がききます。
何かあったら相談してみてやってください。
1999/3/15 ORBSからRELAYチェックがきてた。
ようやく、こんな辺境のサイトまでチェックがまわってきたみたい。
今回は 3パターンぐらい試しているみたいだけど、メールサーバにちろっと小細工を仕込んでやったら、ほらもう引っ掛からない。
う〜ん、ORBSダメダメ。
ニュージーランドでは、いつまで続くのかな？
1999/3/12 最近の流行りは不正アクセスの規制らしい。
すごくくだらないことだけど、特定の人に対して「あなたにはこのサイトに対する HTTPアクセスを許可していない」と言い張れば、その人がアクセスしてきたらそれは不正アクセスなのだろうか。
なんせ、そのリソース(Webページね)にアクセスしても良いという許可を与えることができるのはそのリソースの管理者でしょ？
不正アクセスの要件を満たすためにパスワード認証が必要なら、特定の人が使いそうな IPネットワークからのアクセスのみ、認証システムが答えるようにしておくとか。
アクセスしたければ事前に許可を求めるようにとか言っといて、メールが来たら当然のように SPAM扱いして苦情を出す。
。。。サイバーパトロールの人とかやってきたら聞いてみたいんだけどなぁ。
どんなもんでしょ。
1999/3/10 フラグメントした怪しいTCPパケットが飛んできてる。
遊ばれてるなぁ。
1999/2/5 逆引きとDNSと
そういや、アクセス解析とかでアクセス元を調査する手法って、アドレスを逆引きして得られたホスト名の正当性ってちゃんと評価するようになってるんだろうか。
逆引きで引けるホスト名なんて当然のようにどうとでも名付けれるから、そのホスト名を単純に信じて記録してたら、資料としてはちょっと信頼度が落ちるよね。
まぁ２重に引いてやれば、少なくともそのドメインを管理する組織と関係があるのかどうかは分かるけど、なんか物足りない。
1999/2/5 自粛に自粛
ふと考えると、**********を**********に****たパケットを適当なホストの**********なポートに投げると、すげぇいやなことができるんじゃないかな。(一部自粛)
つまり、*****というレベルではなくて、**********しまう。(さらに自粛)
今のところ、これに対する対策って無いような気がする。
というか、対策なんてできないのでほぼ 100%成功しちゃうアタックだよなぁ。
ホストを選べば威力絶大。
しかもアタック元もばれないし。。。う〜む、やられたらやだなぁ。