ただつらつらと日記が書かれていくようです。
Slashdot Japanの「Subversion は Apache Subversion へ」って記事によると、バージョン管理ソフトのSubversionがいつの間にか、Apacheのトッププロジェクトになってたそうだ。なので、Subversionが「Apache Subversion」という名前になるらしく。へぇー。
まぁ、改めて見てみると、apache.orgなんぞ見てみると、WebサーバのApacheを始めとしてすごーく数多いプロジェクト(サブプロジェクトまで数えるとすごいことになりそうだ)を抱えてるわけで、私もいろいろとApacheのプロジェクトの成果物で楽してるクチではあるな。でも、これだけのプロジェクトが全てアクティブだとすると、それはそれで凄まじいことなんだろうけど、実態はどうなんだろうということが気になった。
あー、そういえば、使ってるSubversionのバージョンが古いまま放置されてる件、どうにかしないと(汗)
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を起動してみたけれど、なんとなくうまく認識してるっぽい。後ほど、ちょっと使ってみる予定。
@ITで、こんな記事を見つけた。「米F5ネットワークス、2月中にBIG-IPのソフトウェア版を発表へ」
最近、ハードウェアベンダーもソフトウェアベンダーも「クラウド」一辺倒になっていて、これはこれでおもしろいなぁと思って眺めていたけれど、一方で、ファイヤーウォールとかロードバランサのようなアプライアンス系のベンダーがどうするのかなと思って眺めていた。
…というのも、仮想化されたクラウドの世界には、彼らのケバケバしい色(…そんなイメージだけど、偏見だろうか…)のアプライアンスを持ち込めないわけで、なんにもしなければ、このままクラウドブームに乗り遅れることになるのに…と思っていたら、ロードバランサ等の大手のF5ネットワークスは、仮想化されたマシンで動く「ソフトウェア版のBIG-IP」をリリースして、クラウドブームに乗っかる気らしい。
まぁ、クラウドの中で仮想マシンをスケールアウトしていくアーキテクチャになると、BIG-IPみたいな、既存のアプライアンスが果たしている役割を担う何かが必要とされているのも確かなんだけろうな。でも、仮に、(アプライアンスが持っているらしい)ハードウェアの特殊性と優位性を取り除いて、仮想マシン上で動くソフトウェアとして、そのデキ(性能や堅牢性など)をオープンソースなソフトと競った場合に、プロプライエタリなアプリケーションにどれだけ優位性があるのか、ちょっと気になるところではあるな…と。
西日本シティ銀行で勘定系がダウンしたらしい。しかも、待機系に切り替わったけれど、その待機系もダウンというかなり悲惨な状況だったらしい(汗)ダウンと復旧かぁ…ACT-SBY系のクラスタだと、こういう状態になるのが一番イヤだなぁ…(遠い目)
上記の記事より。
2010年1月29日に西日本シティ銀行で発生したシステム障害は、約6時間後の午後5時15分に全面復旧した。11時35分に本番系の勘定系システムがダウンした直後、いったんは待機系のシステムに切り替わった。だがその後、待機系もダウンした。時間帯によっては取り引きができた顧客もいたもようで、ダウンと復旧を繰り返す不安定な状態が続いていたとみられる。
で、この辺の古いニュースを見ると、どうやら、NTTデータ製のシステムが日立製のメインフレーム上で動作している…んだろうか。
こういうニュースを聞く度に、メインフレームのウリって、確か、信頼性っていうか、とにもかくにも落ちませんってところじゃないのかなぁと思うんだけど、意外にあっさり落ちてるんじゃん…みたいな印象を持ってしまう。しかも、システムに何ら変更を加えていない状態で、いきなりダウンが発生するというのは、なんとなーく、メインフレーム神話を崩壊させてくれるなぁと(笑)
久しぶりに自分のBlogを眺めてみたら、サイドバーに貼りつけてある、TwitterのFlashガジェットが真っ黒になってた。まぁたTwitterが落ちてやがるぜ…とニヤニヤしてたら、どうやら、Flashガジェットに脆弱性が見つかったらしく提供中止中らしい。
no titleより
We’ve been notified about a vulnerability in our Flash widget and out of an abundance of caution we’ve disabled access as we assess the situation. Please note that the javascript widgets are unaffected and are a good alternative for those of you who had been using the Flash version.
…というわけで、JavaScript版なら大丈夫なんだけど、Flash版の復旧を待ってみるかと。
アンチウィルスソフトにKasperskyを使ってる人から、Adsenseを貼ってるサイトで「Trojan.JS.Redirector.ar」ってのを検出したんだけど…と申告があって、慌ててGoogle先生に聞いてみたら、「Trojan.JS.Redirector.arはカスペルスキーの誤検知のようです。」とのエントリーを発見。おー、なるほど。こういうエントリーはありがたい。まぁ、誤検出ということなら、とりあえず、様子見ということで。パターンファイルの更新を待とうかと。
…ってことは、KasperskyをインストールしてるPCを使ってる人は、違うWebを見る度にアラートが上がってるんだろうなぁ…と遠い目。
追記 その1：
GoogleAdsenseのフォーラムにも、この件の書き込みがあった。
一連の書き込みの中に
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へのアップグレードも簡単に終了した。
最近、全文検索エンジンがあった方がいいような気がして、SennaをMySQLに組み込んだTritonnを、いじくってみた。
ちょっと使った感じでは、とにかく、インデックスを作る時間がかなり必要になりそう。で、そのインデックスを作っている間、ディスクアクセスがごりごり走る関係で、マシンが重ーくなるわけで、それって本番環境でインデックスを作ったりしたら、どうなるんだろうと思う。(ま、普通に考えれば、レスポンスタイムが悪化しますわな)
ま、それを回避するために、他のマシンで全文検索エンジン用のインデックスファイルを作って、そのファイルをTritonnが動くサーバにアップロードするって技もあるにはあるんだろうけれど、インデックスファイルをアップロードする前にMySQL(Tritonn)はやっぱり落としておきたいような気がする(うっかり、アップロード中のインデックスファイルを見ちゃったMySQLはどうなるんだろう…とか思うと)ので、そうなると、例えば、2インスタンス立てて、1つでインデックス切り替えやりつつ、もう1つのインスタンスで運用して、終わったら切り替えるみたいな運用が考えられるけれど、MySQLを2インスタンスってのがこれまた面倒な気がする。こういう運用なら、サーバ2台立てて、ロードバランシングする運用になるんだろうか。
…うーむ。
ふと、Apache Jakartaプロジェクトに全文検索エンジン「Lucene」ってのがあることがわかったので、Luceneを試用してみることにしよう。別に、全文検索エンジンと新アプリケーションの間は、SQLでインターフェイスしなきゃいけないアーキテクチャでもなさそうだし(加えて、Luceneは上司が嫌いなJavaだけど)アプリケーション間のインターフェイスをHTTP+JSONにでもしておけば、問題もないだろうし。
全文検索エンジンには、インデックス作成(の時間と負荷)と、インデックス入れ替えの問題(ま、止めてもいんだろうけど)はやっぱり付いて回りそうだなぁ。この辺がシームレスにできればいいんだけども。
追記：
そういえば、Hadoopを使ってLuceneのインデックス作成を分散処理することができれば、なかなか愉快なことになると思うけど、どうなんだろうか。調べてみよう。
近々、買おうと思っていたら、第2版がでたらしいではないか。どうやら、前版では、MySQL4+MyISAMを前提にしていたけれど、第2版では、MySQL5+InnoDBを前提にした内容に書き換えられているらしい。まぁ、WebアプリだとMyISAMも登場する機会は少なくなさそうだけど、値段が値段だけど、買っといて損はないか…。
最近、仕事でさくらインターネットのレンタルサーバのビジネスプロを使っている。
で、このサービスを検討している時には、このサービスはビジネス仕様をウリにしてるので、属性型JPドメイン(ま、co.jpドメインですな)をさくらインターネットに管理してもらって、さくらインターネットのビジネスプロを使おうと思っていたが、ちょっとイヤな予感がして問い合わせてみて、どうもそういう使い方ができないことがわかった(汗)
というのも、さくらインターネットで属性型JPドメインを預かってくれるのは確かなんだけど、ゾーンファイルの編集が不可という残念な仕様。結局は、さくらインターネットが決めている、いくつかのAレコード(wwwとかftpとかmailとか)とMXレコードがゾーンファイルに書かれて、それでなんとか使えというサービス仕様だった。例えば、社外向けにblogサーバでも立てようとして、blog.xxxxxxxxx.co.jpとか使おうとすると、それはできませんということだ。で、どうにかならないかとサポートに聞いてみたら、他社のDNSサーバを使って、そこのゾーンファイルにさくらインターネットのサーバのIPアドレスを書く使い方を提案されてしまう始末。あぁ、無理なのね(涙)
まぁ、さくらインターネットのDNSサービスでは、ゾーンファイルの編集とか一切できませんというのなら、納得もできるし、そもそも期待もしないんだけど、属性型JPドメインはゾーン編集不可で、gTLDドメインとか(汎用JPドメインは可だったかも)はゾーンファイル編集し放題だから、なんとなく、なんとかならないものかなぁと思ってしまう。
加えて、さくらインターネットは、ユーザにSSHを解放しちゃうくらいの自由度がウリだったりする側面もあるわけだし、ビジネス仕様なレンタルサーバなわけだし、属性型JPドメインのDNSはなんとかならないもんだろうか。
追記：
ふと思ったのは、今回、さくらインターネットのドメイン管理サービスで預かってもらおうとしたドメインは、他社で取得したモノで、それをさくらインターネットに移管しようとしたので、もし、最初から新規でさくらインターネットで取得した属性型JPドメインだったら、ゾーンファイルを編集することができるのかもしれない…が、未確認。
© 2025 ただのにっき。
Theme by Anders Noren — 上へ ↑