今後リンク切れが発生しにくくするためと、多くの項目が一つのページに集中することにより検索サイトを使った検索結果が適切で無くなることを防止するために、「自宅通信網の運用日誌」の構造を変更しました。
月ごとに分離していますので、お手数ですが最新月以外は当該月のリンクを使って閲覧してください。
通常レベルのアップデートが公開された。
今回も素直にアップデートに挑戦。さすがに今回はHTTPアップデートできた。
随分バージョンの上がったファームウエアのアップデートに気がついた。
BUFFALO DVM-RXG18FBに使っている PIONEER DVD-RW DVR-112D に大規模な不良が発生したもよう。
見事に当たっているよう。
FreeBSDのキュリティアップデートの連絡。素直にアップデート。
cd /usr/src make update make -j5 buildworld make -j5 buildkernel KERNCONF=ETTCWEB0 make installworld make installkernel KERNCONF=ETTCWEB0 reboot
今回はOpenSSLの更新のよう。そのほかにも大分アップデートがたまっていたのでちょうど良いところではあった。
昨日のFreeBSDのキュリティアップデートの連絡に基づくアップデートで自宅内プロキシサーバが不安定に。ほとんど同じ構成の自宅公開サーバ方は異常なし。
自宅内プロキシサーバでは最後まで make buildworldが完了せず途中でリブートしてしまう。make buildkernelにしても途中でリブート。本日のcvsupのアップデートを見るととACPI関係がアップデートしていたようなので、ブート時にACPI止めて、-jオプションを無くしてカーネルコンパイルし直したところやっとうまくいった。この後システム全体を作り直したところ安定した。
自宅内プロキシサーバと自宅内プロキシサーバはほぼ同じなのにこの差は何だったのか？BIOSの作りだろうか？
自宅公開サーバの方は異常はなかった物のEthernetのemもアップデートしていたのでこちらもアップデートした。
TipsのDVD-RAMを使ったバックアップの運用例の中でハノイの塔シーケンスをシャノンシーケンスと間違えていたのを校正。恥ずかしい。
今日は定例のWindows Updateの日なので素直に実施。ついでにデフラグなども実施した。
yetibot@nave.comというスパイダ、以前にも来ていたが今回も過激なアクセス。
61.247.217.39 [11/Oct/2007:21:59:56 +0900] "GET /robots.txt HTTP/1.1" 200 35 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follow it)" 61.247.217.36 [11/Oct/2007:22:14:23 +0900] "GET /robots.txt HTTP/1.1" 200 35 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follow it)" 61.247.217.35 [11/Oct/2007:22:16:21 +0900] "GET /robots.txt HTTP/1.1" 200 35 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follow it)" 61.247.217.33 [11/Oct/2007:22:16:24 +0900] "GET /robots.txt HTTP/1.1" 200 35 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follow it)" 61.247.217.37 [11/Oct/2007:22:16:32 +0900] "GET /robots.txt HTTP/1.1" 200 35 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follow it)" 61.247.217.34 [11/Oct/2007:22:17:52 +0900] "GET /robots.txt HTTP/1.1" 200 35 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follow it)" 61.247.217.39 [11/Oct/2007:22:17:55 +0900] "GET /robots.txt HTTP/1.1" 200 35 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follow it)" 61.247.217.38 [11/Oct/2007:22:20:34 +0900] "GET /robots.txt HTTP/1.1" 200 35 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follow it)" 61.247.217.35 [11/Oct/2007:22:20:44 +0900] "GET /robots.txt HTTP/1.1" 200 35 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follow it)"
アドレスが違うとはいえ、一度にアクセスに来なくとも良いと思う。robots.txtで拒否を表明しあるが、許可するととんでもないアクセスされそう。こんな悪いイメージを振りまくのは、けして得策ではないと思うのだけど。
この頃、search.yahoo.co.jpからの参照が増えている。このサイトのかなり初期からYahoo! Slurpが隅々までそこそこの頻度でクロールしていったが、長い間インデックス化されなかった。登録方針がどうもかなり慎重のように思える。
それに比べるとGoogle botは緩急を付けてアクセスしてくる。更新頻度が高いページについてはかなり高い頻度でアクセスしてきて速く登録される。旧自宅通信網の運用日誌に至っては前日のページがインデックス化されることがあった。頻度の少ない物はクロール頻度が下がるだけでなくクロール後にインデックス化されるのも遅いように思う。１ヶ月程度かかるのは良くある印象。遅いだけでなく更新頻度の低いページが連続更新したときは、更新が落ち着くのを待ってからインデックス化しているように思えるときもある。なかなか工夫してあるように思うが、どうもクロール漏れがYahoo! Slurpよりも多いように思う。
遅いが網羅性の高いYahoo!と速いが漏れのあるGoogleと言うように思える。確かに出てくる結果が違うとは思っていたが、運用してみて分かるが大きな違いや誤解、気づかなかった点がたくさんある。
メインPC用のUPSにSNMPカードを追加して、SNMPによる監視を昨日（2007/10/13 Sat）から開始。MRTGによる情報収集を始めているので近日公開予定。
NVIDIA Quadro NVS 440 のドライバソフト類のアップデート。
今回は、細かな刻み。終了時の障害が直っていると良いなあ。
残念ながら終了時の障害は直っていなかった。残念。
録画用PCのM/BのBIOSが本当に約2年半ぶりにアップデートしているのに昨日気づいた。
アップデートをすぐにしようとしてみたが、AntiVirusソフトに阻まれたりして結構手間がかかり本日は断念。
自宅内Proxy用にSquid ログレポートジェネレータのSARGを試してみる。インストール簡単で日本語対応。なかなか興味深いレポートがでる。変なプログラムが変な物をダウンロードしたら一目瞭然。ただ、人がダウンロードしても内容が一目瞭然なので、これの解析結果は公開しずらいなあ。
本日18時台に飛び抜けてアクセスがあったので、ログを見てみると少し妙なアクセスが。
???.??.??.??? - - [19/Oct/2007:18:25:41 +0900] "GET / HTTP/1.0" 200 4521 "-" "Mozilla/4.0(compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)" ???.??.??.??? - - [19/Oct/2007:18:25:44 +0900] "GET / HTTP/1.0" 200 4521 "-" "Mozilla/4.0(compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)" ???.??.??.??? - - [19/Oct/2007:18:25:47 +0900] "GET /history.html HTTP/1.0" 200 9921 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)" ???.??.??.??? - - [19/Oct/2007:18:25:50 +0900] "GET /pc/HDDs.html HTTP/1.0" 200 29404 "-""Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)" ???.??.??.??? - - [19/Oct/2007:18:25:54 +0900] "GET /log/200710.html HTTP/1.0" 200 8734 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)"
延々と続く。クローラは名乗っていないけれど、画像をアクセスしていかない上にアクセス間隔にメリハリが無く平坦で人の手によるアクセスの気配でない。アドレスの管理上は中国のDNSになっているけれど・・・・。クローラかな？？？
先に断念した録画用PCのM/BのBIOSをアップデート。
ちゃんと準備すれば書き換えはあっさり出来る。録画用なので、休止状態から時間に立ち上がるか、終了時に再度休止状態になるかのチェックの方が手間がかかる。
当公開サーバの主要アプリケーション Apatche のアップデート。
前回の様に間が開かないように小刻みにアップデート。
大きくなりすぎていたdnsfile.txtを名前を変えて作り直し。自動的に不必要部分のトリムがかかるようにしなくちゃなあ。
ネットワークの遅延状況の測定に使わせていただいている大阪大学の公開FTPが07:55:22に停止を検出して継続中。
全く前兆無く08時前から停止したので、定期点検かとも思ったが深夜も継続しているので障害と思える。休日の障害は大変。今回もボランティアベースで負荷の高いサーバ提供の苦労がしのばれる。
今日も反応がない上、FreeBSDのサーバー群から外れていたので、Pingの対象を大阪大学から変更を決断。20:40から大阪に本社があって自社バックボーンを持つさくらインターネット株式会社のリングサーバであるring.sakura.ad.jpを測定させていただくことにする。ただこれに変えると、大阪にサーバがあるとは限らないところが難点。
大学は公共のftpサーバのような貢献が難しくなっているのかなあ。
利用しているHDDの概略へのアクセスが急増したので確認したら、Googleにインデックスに大幅変更後のページが登録されていた。変更しても長い間7月終わりの登録のままで変化がなかったが、突然10月20日版が登録されていた。この辺登録方針に謎が多いなあ。
利用しているHDDの概略に掲載されている、HDS725050KLA360は、購入時もヨドバシカメラ梅田でE7K500で購入したし、Hitachi Global Storage TechnologiesのページでもHDS725050KLA360はDeskstar E7K500と明記されている。
しかし、Googleなどで検索するとHDS725050KLA360は、あちらこちらの販売サイトで7K500として登録されている。価格コムでさえHDS725050KLA360のHGSTへのリンクは、Deskstar 7K500のページにリンクされている。Deskstar 7K500のページにはパラレルATAのHDS725050KLAT80だけでSATAに機種はない。HDS725050KLA360は、7K500のSATAとして出荷された時期があるんだろうか。
これほど他のサイトが間違いで掲載していると、こちらが間違えて掲載しているようだ。なぜこんなに間違いが蔓延して、訂正されないのだろう。違う物を販売したら偽装販売とまでは言わずとも問題になりそうな物なのに。製造メーカと私の掲載内容は少数派。多数派が明らかに間違いと認識できる工業製品では珍しい例。いや変な状態だなぁ。
当公開Webサーバと自宅内プロキシサーバのFreeBSDをUpdate。
昨日寝ようと思ってメインのPCと自宅内プロキシサーバをシャットダウンしたところ、自宅内プロキシサーバがシャットダウンしなかった。ほぼ同じ構成の公開Webサーバと比べるとどうも不安定。ACPI系がFreeBSDからうまくコントロールできないときがあるように思う。
様子を見るためにメインPCを立ち上げ直したときに、UPSの動作との絡みで電源が落ちてしまったので、RAID1の再チェックの時間を利用してACPIに手が入っていたFreeBSDをアップデートすることにする。当公開Webサーバの方は環境ごと、自宅内プロキシサーバの方はカーネルのみをアップデートした。
朝、ニュース(NHK)を見ていたら、一太郎の深刻な脆弱性について放送していた。JVNに10月25日に掲載されている。バッファオーバーフローの脆弱性。26日に見ていたのに以前の物と思いこんでいた。迂闊。
出かける前にささっとアップデートした。
28日深夜のアップデートしたとこだが、当公開Webサーバと自宅内プロキシサーバの両方とも環境ごとアップデートしてそろえる事にした。
この作業の前に、前回の状態を確認したところいつの間にかFreeBSDが6.3-PRERELEASEになっているのに気がついた。もうすぐでるんだなあ。
10月最終日なので当公開Webサーバと自宅内プロキシサーバを環境ごと作り直したので、Level0 dump(フルバックアップ)。
公開Webサーバはいつも通りdvdramへバックアップ、自宅内プロキシサーバの方は、USB接続のCentury TERABda0:
USB接続のCentury TERABOX_IIIへバックアップがやたらに遅い。表示を確かめたら、1MB/sで接続していることになっている。
da0: <Century TERABOX_III-A 0100> Fixed Direct Access SCSI-2 device da0: 1.000MB/s transfers
dmesgで良く確認すると、EHCIがイネーブルになっていない。旧プロキシでディスイネーブルにしたまま継承してしまっていた。カーネルを作り直して再挑戦。