投稿者: 管理人 (30ページ目 (40ページ中))

ある日、電話が使えなくなった。

とりあえず、PBXは生きてそうだし、電話機もなんとなく電源が入ってるっぽい。で、ひかり電話なので、PBXの先をあさってみると、ONUとVoIPゲートウェイがいて、とりあえずランプは付いているので、電源は入っているという状況。どちらの機器も一目で壊れている状況ではなく…ということで、困った挙句にNTTの故障担当に電話して、電話越しにONUのランプを確認している時に、どうやら上流の機器と接続していない状況っぽいことが判明した。で、その一方で、ひかり電話のCAがダウンしているという状況もないので、NTTの局舎とオフィスの間の光ファイバー回線になにか障害が起こっていそうということが判明したので、担当者を派遣してもらえることになった。

で。

しばらくしてNTTの担当者がやってきて、ONUの上流にある光ファイバーを調べてもらった。光ファイバーに検査機器みたいなのを接続してみたところ(きっと、光ファイバーに可視光を流す機械だったんだろうな)、以下のような状況になっていた。

さらに、ズームするとこんな感じ。

…おっと光ファイバーから光が漏れてる(汗)

というわけで、ビルのMDFで光ファイバーがどうにかなったという状況でも、電線で光ファイバーが…という状況でもなく、結局は、オフィスの2重床の下側で光ファイバーが断線していたという、なんともシビれるオチだった。NTTの人に光ファイバーを局所的に交換してもらったところ、ONUの消えていたランプが点灯して、ほどなくしてひかり電話が復旧。めでたしめでたし。

でも、光ファイバーが折れて光が通らなくなるという状況(しかも、二重床の下側で！)の原因がなんなのかはついぞ判明しなかった。オフィスの配置をいじったときに二重床をいじったけれども、それで光ファイバーに余計な力がかかるというのもなんとなく解せない。

Vyattaというオープンソースなソフトウェアがある(開発はVyatta INC.)このVyattaはDebianベースのソフトで、x86サーバをCiscoのルータと競えるくらいのスペックに変えてしまう、ルータソフトウェア。で、Vyatta INC自体は、サポートが必要なら、サブクリプションを買ってくださいというRedHatに似たビジネスモデルで会社を営んでいる(あと、Vyattaをインストールしたアプライアンスも売ってるみたい)

で、ちょいとこのVyattaを使ってルータでも作ってみるかということでいろいろと企んでいたが、そもそもハードウェアどうするかというところで、適当なマシンを組み立てたけれど、前回の反省から、ちょっとNICには気を使おうと思っていた。

ま、こういうケアが意外と功を奏するものだ(…とはいえ、ややこしいことにはなっている)

まず、安NICを回避しようと思ったら、とりあえず、IntelのNICですよねーということ(発想は単純)で、最初は「Gigabit CT Desktop Adapter」(EXPI9301CT…で、コントローラはIntel 82574L)でも買おうかと思っていたんだけど、これが動作するためには「e1000e」ってドライバが必要…と。

だけど、今回のVyattaのターゲットバージョンは「Vyatta Community Edition 5」にしたけれど、このバージョンのベースになっているDebianのカーネルは2.6.26。で、この2.6.26には「e1000e」が入っていないとのこと。あー。

まぁ、ドライバを導入すりゃいいんだけど、どっちかというとルータにドライバ導入とかやりたくないような…。で、一方、従来のギガビットイーサネット用のe1000ドライバは持っているけれど、既にe1000で動作するIntel製NICが売ってなさげ(汗)ま、サーバ向けNICにあるけど、ちと高い。

というわけで、調べに調べてみた結果、HPのサーバ向けNICが古いコントローラを搭載しているらしいということに気がついた。それは、HPのNC110Tってやつ。しかも、9,000円。Intelのサーバ向けNICより、少し安い。これに使われているコントローラが「82572GI」って代物で、「Intel PRO/1000 PT Server Adapter」あたりに搭載されているコントローラ。このサーバ向けのPRO/1000PTは、Vyattaもサポートしているっぽいので、まぁ、なんとかなるだろうということで(汗)

新しく構築したマシンに挿してVyattaを起動してみたけれど、なんとなくうまく認識してるっぽい。後ほど、ちょっと使ってみる予定。

アンチウィルスソフトにKasperskyを使ってる人から、Adsenseを貼ってるサイトで「Trojan.JS.Redirector.ar」ってのを検出したんだけど…と申告があって、慌ててGoogle先生に聞いてみたら、「Trojan.JS.Redirector.arはカスペルスキーの誤検知のようです。」とのエントリーを発見。おー、なるほど。こういうエントリーはありがたい。まぁ、誤検出ということなら、とりあえず、様子見ということで。パターンファイルの更新を待とうかと。

…ってことは、KasperskyをインストールしてるPCを使ってる人は、違うWebを見る度にアラートが上がってるんだろうなぁ…と遠い目。

追記　その1：

GoogleAdsenseのフォーラムにも、この件の書き込みがあった。

Google Groups

一連の書き込みの中に

I recieved an email from kaspersky that it is an false detection and will be fixed in the next update..

ってことが書いてあったけど、…どうなんでしょうなぁ。

追記　その2：

さっき、このエントリーを眺めてたら、サイドバーに貼ってあるAdsenseにウィルスバスターの広告が出てた。偶然だろうけど、トレンドマイクロにとっては絶妙な感じだなぁ…と(汗)

追記　その3：

カスペルスキーの国内代理店(…?)のジャストシステムが、この件に関してWebページを公開してた。

JustSystems | Kaspersky製品についてによると、

本日2010年1月25日 15:00頃より、Kasperskyをご利用いただいているお客様がニュースサイトなどの記事を参照した際、トロイの木馬「Trojan.JS.Redirector.ar」を検知する場合があることを確認しております。

お客様にはご迷惑をおかけいたしまして誠に申し訳ございませんが、Kasperskyが誤って検知しているものです。

…とのこと。

追記　その4：

上記のジャストシステムのWebページに以下のような内容が追記されているのを発見。

2010年01月25日（月） 23時以降、修正された定義データベースを順次配信予定です。

…というわけで、カスペルスキーをお使いの皆様は手動でパターンファイルを更新すると、Adsenseを見かけて「Trojan.JS.Redirector.ar」を検出するということがなくなるんじゃないでしょうか…と。

あと、kaspersky.comに(ようやく?)この件が出てた。あちらでも、false detection(誤検出)であることを認めているようですな。

False positive detections by Kaspersky Lab products on some Google web pagesより

Such detections of the virus Trojan.JS.Redirector.ar on some Google web pages are false positives.

でも、日本の代理店(?)のジャストシステムのサイトでは改修版のパターンファイルを配信する時間までアナウンスしている一方で、本家では「Kaspersky Lab specialists are working on the issue.」ってざっくりしたアナウンスのままってのも、ちょっとなんだか不思議な感じがしないでもないなぁ。こういうのって本家の方が早いんじゃないのかな、だってパターンファイルとかって本家でつくってるんだろうし(…あ、本家ってもしかしてロシアか…)

追記　その5：

kaspersky.comのフォーラムを眺めてたら、なんとなく妙な感じになってた。

この辺で、Kasperskyの中の人っぽい人が

It’ s already fixed.

Update your databases.

って、書き込んでて、この指示に従って更新したとおぼしき人が返信で

I’ve just updated and I’m still getting the error, this is ruddy stupid.

と返信。そしたら、再び中の人が

K-Lab will fix this problem soon ….

…って、書き込んだってことは、一発目のfixは失敗したんだろうか…。あー。って、「It’ s already fixed.」って書き込んだ人、「Kaspersky fan」って書いてるから、Kasperskyの中の人じゃないじゃん。orz

最近、さくらインターネットでレンタルサーバを契約したユーザはMySQL5.1が使えるようになっているのだが、さくらインターネットのMySQLサーバ群にMySQL5.1が導入される前にMySQLのDBを持っていたユーザはMySQL4を使っている…と。

で、私は、さくらインターネットのレンタルサーバにWordPressをインストールして使っているわけだけど、今度のバージョン(Ver.2.9)から、要求されるMySQL4のバージョンが少し上がってしまったらしく、私が使っていたMySQLサーバではWordPressの要求を満たせなくなった…つまり、バージョンアップできなくなってしまった。

…というわけで、勢いに任せてMySQLのバージョンをアップすることに決定。基本的にさくらインターネットのレンタルサーバでは、使えるMySQLのDBの数が決まっているので、MySQL4のDBを返却(ま、結局は削除)して、MySQL5.1のサーバを借りることになる。基本的には、MyPHPAdminを使って、MySQL4のダンプをとって、MySQL4のDBを削除、でもって、改めて、MySQL5.1のDBを作成して、ダンプしたデータを戻すという作業が必要。まぁ、さくらインターネットのレンタルサーバのコントロールパネルとMyPHPAdminがあれば、片付く作業ではあるけれど、面倒くさい。

で、とりあえずやってみたところ、MySQL4のダンプデータが一部、おかしくなっていたのを、DBを削除した後に発見(UTF-8のデータなんだけど、ダンプして取得したファイルをテキストエディタで見てみたら文字化けが発生みたいな…)したので、この作業をやる人は、ダンプデータに文字化けが発生してないことを確認してから、DBを消すのがいいんじゃないかと(とはいえ、壊れていたのは、古いMovabileTypeで使っていて、放置していたテーブルなので実害はなかったんだけども…)

一応、コントロールパネルからMySQL4のDBを消して、再度、コントロールパネルからのDBの管理画面に行くとパスワードを入力するだけで、MySQL5.1のDBが確保できる。しかし、MySQLのサーバ名が変更されるので、あとは、WordPressの設定ファイル(wp-config.php)に書いてあるMySQLサーバの名前を変更すれば、元通り、WordPressが動くようになったし、WordPress2.9.1へのアップグレードも簡単に終了した。