dreamhound

最近の回線速度テスターはグラフィカルになって見栄えがよろしい。Speakeasy の Speed Test （下画面）が最近のお気に入り。あと、BroadbandReports.com の Speed Tests とか。こちらには 各国のスピードテストのリンクリスト もある。

先週辺りからこのブログにトラックバック Spam が送られるようになった。

利用しているブログシステムの Movabletype で「受け付けたトラックバックについて、事前に確認した後に公開する」と設定しているので、投稿者の思惑に反してトラックバックは１つとして公開されていない。このまま放置して今後の発展を見てみたいという思いもあるのだけど、連日３－４回のトラックバック Spam を受け取り続けるのも煩わしい。意図的なのか天然ボケなのかわからないけど、トラックバック Spam 元の IP アドレスが固定なので、Apache のアクセス制限を使ってその IP を排除しておく。

ブログと MT のルートディレクトリに .htaccess ファイルを作成。

order allow,deny
allow from all
#070414 - trackback spam
deny from IPアドレス

ちなみに、トラックバック元の IP アドレスはロシアの個人が所有するドメイン下。whois で検索すると実名と思しき情報が見つかるし、IP アドレスは固定だし、その IP アドレスにブラウザでアクセスすると Apache のデフォルトページが表示される。意図的じゃないとすれば、Spammer としてのセキュリティ意識に欠けるのではないかと思わないでもない。余計なお世話だろうが。

僕が制作＆管理を請け負っている小規模商用サイトには、問い合わせ受け付けのためにメールフォームを用意してあるのだけど、先日このメールフォームを使っておかしな内容が送られてきた。フォームでは複数行の文字列入力は許していないのにも関わらず、送られてきた内容には複数行の文字列が含まれている。具体的にはそれはメールヘッダで、見覚えの無いメールアドレスが１０個以上も羅列されていた。フォームを使わずに引数指定でスクリプトを直接叩いたに違いない。このメールフォームを Spam メール発信の踏み台として使えるかどうか、その脆弱性をチェックしたようである。

自分が管理するサイトが Spammer のターゲットにされたのでは、ウェブマスターとしてはたまったものではない。ホントにそんなことができるのか、早速自分で書いたスクリプトの見直してみた。Spammer になったつもりで、普段とは違う目線でスクリプトを精査したところ、あっさりと脆弱性が見つかってしまった。サイト制作者としては恥ずかしい限りではあるが、まあ実際に悪用される前に見つけることができたのが不幸中の幸いか。

このスクリプトは、フォームから渡ってきたデータを連結して sendmail へ引き渡している。データを渡すのには POST メソッドを使っているため、URL 末尾にデータを引数として指定してスクリプトを呼び出すことも可能だ。渡ってきたデータのチェックが甘いために、引数中に改行コードに続けて悪意のあるデータをしのばせることができるようになっていた。それがこのメールのセキュリティホールである。このセキュリティホールを使うと sendmail を自由自在に操ることが出来てしまう。

このスクリプトの叩き台は著名なフリー CGI サイトで配布されていたメールフォームだったように記憶している。となると、同じようなセキュリティホールを持つメールフォームは、ネット上にゴロゴロしているような気がするな。

ある事情で１年ほど前に解約した Cox Communications のCATV インターネットサービスを先日再契約した。屋内配線は通っているし、以前に買い取ったケーブルモデムもある。CATV 会社に電話してサービス開通してもらえばそれで済むかと思っていたら、手持ちのケーブルモデムの MAC アドレスを知らせろという。以前は自由にケーブルモデムを交換できたのだけど、MAC アドレスで端末を識別するようにシステムが変わったようだ。MAC アドレスを通知してその場でサービス開通となったのだけど、実際にパソコンを接続してみると接続が非常に不安定。著名サイトへ ping しても１０回に４回もタイムアウトになる。

集合住宅なので粗悪な屋内配線によるロスは考えにくい。だとすると原因はモデムか。以前は正常に動作していたのだけど故障したのだろうか。念のために Broadband Reports の掲示板を検索してみたところ、手持ちの Toshiba 製 PCX1100 と CATV プロバイダとの相性の悪さを報告する書き込みを発見。僕と同様に頻繁にパケットロスを起こしているらしい。このモデムは CATV 会社から直接購入した「公認モデム」のはずなんだけどな。

とりあえずモデムを交換して確かめてみるのが手っ取り早いと考えて、近所の BestBuy で Motorola 製 SB5101 というケーブルモデムを購入。Toshiba 製モデムと繋ぎ替えてみたところ、ブラウザの画面には「CATV ケーブル接続のサポートに電話してください」というページが強制表示される。MAC アドレスの登録変更が必要ということか。すぐ電話してモデムを交換した旨を伝えて、モデムのシリアル番号と MAC アドレスを通知したらその場で再開通。パケットロスも生じずに快適にインターネット接続できている模様。回線速度テスターで計ったら公称速度は出ているようだ。

トラブルの原因はケーブルモデムだったわけか。故障しているのか、それとも単に相性が悪いのか。そういえば、近所のショップでも以前は一押しで売られていた Toshiba 製ケーブルモデムは目にしなくなったな。何かあるのかもしれないと勘繰りたくもなってしまう。手元には余ったモデムが１つ。

知り合いからウェブマスタのメンテをしてくれないかと打診される。これまでは事務職の女性が兼務でウェブサイトの制作管理をしていたらしいが、長期育児休暇で出社しなくなり代理のスタッフも居ないとのこと。とりあえず現状のウェブサイトを眺めてみることにする。

ブラウザで表示してみて随分と重いなぁという印象。独自ドメインなので共用サーバの性能＆負荷の影響か。と思えば、リンクにカーソルを置いてみればブラウザのステータスバに表示される URL は web.mac.com というもの。あれ？と思ってページソースを表示してみたら、フレームのメインページだけが独自ドメインのサーバに置かれていて、フレームにインクルードされるページは web.mac.com に置かれている模様。iWeb + mac.com という環境でウェブサイトを制作運営したいという意図を尊重した上で独自ドメインを使うという苦肉の策か。

HTML は iWeb 1.1.2 で作られたらしいことが HTML ソース中の meta タグから読み取れる。iWeb が生成した HTML ファイルを見るのは初めてだけど、スタイルがあちこちに散りばめられていて美しくない。例えば、見た目あまり凝ったように見えない短い記事１つを表示するのに以下のような HTML が生成されている（見易さのための改行は僕が追加している）。

<div class="graphic_textbox_style_default" style="height: 518px; left: 134px;
  position: absolute; top: 87px; width: 566px; z-index: 1; " id="id5">
  <div>
    <div class="graphic_textbox_layout_style_default">
      <div class="paragraph Body" style="line-height: 20px; padding-top: 0pt; ">
      <a href="リンクURL" title="リンクURL" style="font-size: 13px; line-height: 18px; ">
      タイトル</a><span>副題</span></div>
      <div class="paragraph Body" style="line-height: 20px;
        font-size: 11px; line-height: 14px;">本文ここ</div>
      <div class="paragraph Body" style="line-height: 20px;
        text-decoration: none;"> </div>
      <div class="paragraph Body" style="line-height: 20px;
        text-decoration: none;"> </div>
      <div class="paragraph Body" style="line-height: 20px;
        text-decoration: none;"> </div>
    </div>
  </div>
</div>

あと、なぜかトップページはテキストがグラフィックス化されて貼り付けられていた。ネットを巡回してみると、iWeb ではテキストをグラフィックスできるみたいだな。なぜグラフィックス化したのか制作側の意図は不明。グラフィックス化されたテキストはたとえ IMG タグの ALT 属性にテキストを指定しておいても、ページ内容詐称防止のためにサーチエンジンで掲載されないケースがほとんどだろう。トップページの新着情報がサーチエンジンに載らないのは勿体無い。

iWeb を使ったとしても作り手が違えばもっと綺麗な HTML が生成できるのかなぁ。良く分からない。

僕が設置した MovableType が不調と友人から連絡あり、「ログオンできない」とのこと。試しにログオンしようとすると、ユーザ名とパスワードを入力して１分以上待たされた挙句に 500 番のエラーが出る。プロバイダは日本のロリポップ。何か悪さしたか？と友人に尋ねると、思い当たるのは「プロバイダの契約ディスク容量を慢性的に超過して使っていた」ことと「ここ数日１日千件を越える SPAM コメントがポストされていた」こと。どちらもブログシステムをダウンさえるに充分な要因と思われるが、ホントの原因は何なのか、まずは調べてみないとな。設置して２年ほど経つが、これまでトラブルフリーだったんだけど。

プロバイダ提供のブログサービスを使っていないのは、その前に使っていたプロバイダではブログサービスが無かったので、自前で MT をセットアップしてブログを立ち上げていたことの名残り。プロバイダのブログサービスにはインポート機能が用意されているけれど、画像やリンクのパスを手作業で修正する必要があるので移行のコストは大きい。それを嫌がって現プロバイダでも MT をセットアップしたというわけ。データベースは全プロバイダでは MySQL だったが現プロバイダでは SQLite を使用。良く調べれば現プロバイダでも MySQL サーバが使えたのだけど、移行時間を短くしたかったので SQLite の利用を決めた。

FTP 接続してサーバー上のファイル一覧を眺めると、異様に肥大化しているデータベースファイルが目に留まる。SQLite は１ファイルのみで構成される手軽で高性能なデータベース。ブログのエントリ数は２５０に達していないにも関わらず、ファイルサイズは 100MB 近くもある。このところスパムコメントを数多く受けていたというが、それで 100MB にもなるだろうか。テキスト情報だけで 100MB とは半端な量じゃない。何が起こったのだろうか。

不具合の症状は MT にログオンしようとすると 500 番のエラーが出ること。考えられる原因はスクリプト、データベース、ホストの３つか。切り分けているだけで時間が掛かりそうなので、まずはデータベースが破損しているか調べるために、MT が正常に動作している他サーバーへデータベースをコピーしてアクセスしてみる。すると問題なくデータベースにアクセスできて、過去エントリは正常に一覧された。予想外に表示に時間が掛かるのはデータベースが肥大化しているせいか。でもまあデータベースは破損していないことは確認できた。

今度は問題のサーバーの MT を削除して、ローカルのバックアップをリストアしてみる。データベースは空のまま。すると MT は無事に起動できてセットアップ画面が表示される。スクリプトに問題があったのかなぁと思いつつ、もはや不具合が解決された気持ちになってデータベースをリストアしてみると、なんと再び 500 番のエラーが発生するようになる。契約ディスク容量を超過しているので、他ファイルを消して空き容量を増やしてから試してみるが状況は変わらず。このホスト上でこのデータベースと MT の組み合わせに限って問題が発生しているように思える。不可思議なトラブルだな。

明確な解決方法は見出せないまま、やっぱりデータベースのファイルが肥大化していることは気になる。MT には SQLite のデータベースをメンテするためのユーティリティは付属していない。myPhpAdmin のようなツールがあればデータベースの内部状態を見ることができるのだけと。別ホストの MT ではこのデータベースは開けるので、そこでデータを一旦テキスト形式でエクスポートし、それを目的ホストの初期状態の MT でインポートしてみることにする。エクスポートしたテキスト形式データは約1MB、それをインポートした SQLite のデータベースファイルは約 2MB になった。これまで 100MB 近くあったデータベースファイルは何だったのだろう。理由はわからないがデータベースが非常に不健康な状態であったことは間違いないだろう。

MT を入れなおし、データベースを新規作成し、過去エントリを一旦テキスト形式に直して再インポートという手順を経て、ブログシステムはヘルシーな状態に復帰。調査して試行錯誤している時間を含めたら、ほぼ１日仕事になってしまった。SPAM コメントを受け始めた時点でなんらかの対処をしていれば、早い時期にトラブルは食い止めることができたに違いない。管理者不在で MT を使うことにはリスクがあるなと実感。友人にはプロバイダが提供するブログサービスを使うことを検討するように伝えておく。あー疲れた。

コーヒーが美味いか安いか、値段が安いか高いか、まあそういう議論は棚上げして、出先でその店舗を用意に見つけることができるコーヒーチェインは恐らく Starbucks だろう。Starbucks の各店舗では T-Mobile Hotspot の Wi-Fi サービスが提供されていて（2008年春から AT&T のサービスへ移行したが、T-Mobile Hotspot カスタマは従来どおり使える）、実は僕は友人がほとんど使わないけど契約しているというアカウントを好意で使わせてもらっていたので、出先でパソコン仕事をするために非常に重宝していた。だけどその友人もケータイ電話を T-Mobile から AT&T へ移行することを決めたとのことで、僕の Starbucks の Wi-Fi 利用ももはやこれまでか。だって普通にサービス加入したら１ヶ月 $29.99（T-Mobile の電話サービスと併用加入だと $19.99）、毎日使うならともかく、実際は週に数時間しか使わないものなぁ。

さてどうしたものかとネット巡回していたら、OLPC プロジェクトの Wiki に T-Mobile Hotspot の名前 を発見。OLPC（One Laptop per Child）とは 100 ドルのノートパソコンを製造して途上国の子供たちに提供しようというプロジェクト。メディアで取り上げられることが多いので大まかな内容は僕も知っていたけど、そのプロジェクトに T-Mobile が協賛して OLPC XO（このプロジェクトで製造されたノートパソコン）を１台購入するともう１台が途上国に寄付され、かつ、T-Mobile Hotspot の１年間の使用権がオマケで付いてくるらしい。

すぐに eBay へ移動して T-Mobile Hotspot OLPC で出品を検索すると、このオマケを転売している出品が即座に見つかる。件数はあまり多くなく５件ほど。アメリカ国内はもとより、「オマケで貰ったけどカナダ在住だから使えね～」とか「ドイツ在住だからやっぱり使えね～」といったアメリカ国外からの出品もある。暫らくウォッチすると、大体 50 ドル前後で落札されている模様。普通に契約したら月額 $30 x 12ヶ月 = $360 の出費だから、僕にとっては激安と言っても過言じゃない。$60 ほどで即決可の出品があったので、買いはぐれる前に購入させてもらった。PayPal で決済すると出品者から PIN コードがメールされてきて、オンラインでアカウント開設したらその日から１年間 Hotspot が使えるとのこと。早速サインアップして実際に Starbucks で試したら問題なく使えた。超お得な買い物だったな。

これで僕の Hotspot 接続も１年間は繋がったなぁ。１年後にも何か出物があったらいいんだけど。

ブログ形式のウェブサイトが多い昨今、RSSリーダー利用者は多いに違いない。僕も類に漏れず、goo リーダー（アプリ版） というRSSリーダーソフトを利用している。

ネット上でソフト比較や評価記事を散々読み漁った挙句にこのソフトに決めたのだけど、まあ基本的な機能は好み通りであるものの、使い勝手に難を感じることが多くて不満が蓄積。具体的には「Windows ソフトにも関わらず、Windows ソフトの慣習に従っていない部分が多い」ということ。例えばダイアログボックス上のボタンの配置１つを見ても、Windows のユーザインターフェースガイドラインでは[OK]ボタンが左で[キャンセル]ボタンが右と規定されているにも関わらず、goo リーダーでのボタン配置は反対。ショートカット割り当てやツールバーの体裁も一般的な Windows ソフトと違った部分が多いように思える。何か思い入れがあってそうしているのなら尊重もするが、単に細かい配慮が成されていないだけのような。

そうは言っても、なかなか代わりになるソフトも見つからず、goo リーダーをずっと使い続けてきたのだけど、やっと重い腰を上げて RSS リーダーの乗り換えを検討。RSS リーダーが出始めた頃に当時の著名なソフトは一通り試した経験があるのだけど、その中でも RSS Bandit がバージョンアップを重ねて最近の評価はかなり高い様子。早速最新版をダウンロードして試用開始。.NET を使っているようだけど、起動してしまえば重さはほとんど感じない。表示スタイルも僕の好みだ。というわけで、goo リーダーからの乗り換えを決断し、RSS Bandit が当面の僕の常用 RSS リーダーとなった。goo リーダーはもっと細かい部分を作りこめば更に良いソフトになると思うんだけどな、勿体無いなぁと思う。

ちょっとした合間に YouTube で動画を見ることが多いけど、出先や公共施設では YouTube へのアクセスが制限されていることがある。暇つぶしの動画閲覧なら我慢するのだけど、セミナーや時事ネタなど予ねてから観ようと思っていた動画が見えれないのは痛い。そういうときのために動画をダウンロードして観れるように環境を整えておこう。

YouTube の動画は Flash Movie（FLV形式）であることは知られている。YouTube の動画をダウンロードするサービスを提供しているサイトはいろいろあるが、例えば手軽なところで「ohaYouTube - おはようチューブ」を使ってみる。使い方は至って簡単で、YouTube で閲覧中の動画をダウンロードしたければ、ブラウザが示す URL に oha の３文字を挿入してエンターキーを押すだけ。動画ダウンロードの頻度が高い人は専用ダウンロードソフトなどを使いたいかもしれないが、僕のように稀にしかダウンロードしない人ならばコレで充分。動画したファイルは拡張子 flv を付けてリネームしておく。

ダウンロードした FLV ファイルを表示する方法にもいろいろあるが、ファイル種類ごとに異なるビューアを用意するのは煩雑だ。閲覧頻度が高い動画形式は同じビューアで表示できるに越したことは無い。僕の場合、特に好みのビューアは無いけれど、まあ標準的という意味では Windows Media Player に馴染みがある。というわけで、FLV を処理するコーデックをインストールすることで、Windows Media Player で FLV の閲覧を可能にしてみたい。

フリーウェアで人気が高いコーデックパックの１つに Combined Community Codec Pack（CCCP）がある。様々な形式に対応したコーデックとビューアが含まれており、僕が必要とする FLV 形式用のコーデックも含まれている模様。これをインストールしておけば著名な動画形式のほとんどは問題なく再生可能になりそうな感じ。公式サイトからダウンロードしたらすぐインストール。設定は全てデフォルトのままにしておく。

インストールが完了すると設定ダイアログが表示される。とりあえず設定も全てデフォルトのままにしておく。後で困ったことがあれば設定を変更すれば良いだろう。

設定が終われば準備は完了。Windows Media Player を起動して、ダウンロードした FLV 形式の動画をドロップ。動画は問題なく表示された。ありがたや。