ただつらつらと日記が書かれていくようです。
久しぶりに自分の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
YAMAHAのRTXシリーズのルータの設定を眺めていたら、謎の表記を発見(適当に伏字)
ip filter XX reject * * tcp,udp netbios_ns-netbios_ssn *
この表記の「netbios_ns-netbios_ssn」部分って、本来ならポート指定なんだけど…と思って調べてみたら、ヤマハのサイトに答えらしきものを発見。ニーモニックってのは馴染みが無いんだけど、エイリアスみたいなものなかなぁ…と。「RTシリーズで使えるニーモニック表」によると、
netbios_ns = 137
netbios_ssn = 139
…ということらしい。というわけで、上記の設定は以下のような設定と同じ意味ってことだろう。
ip filter XX reject * * tcp,udp 137-139 *
まぁ、このニーモニック表がアタマに入っている人なら、こういうのは何でもないことなのかもしれないけれども(汗)一応、メモ。
最近、さくらインターネットでレンタルサーバを契約したユーザは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ドメインだったら、ゾーンファイルを編集することができるのかもしれない…が、未確認。
GoogleMapのサイトは問題なく地図が表示されているようだけど、API経由で地図を表示してるサイト(tabelogとか)は軒並み地図が灰色になってしまっているようだ。それは、Google Maps APIsのGoogle Codeのサイトも例外ではないみたいだ(スクリーンショット中のサンプルの地図も灰色になってる。)
あー、早く直らないかなぁ…。
追記：
Google Maps APIのフォーラムを眺めていると、Google社員のPamelaさんがこんなことを書き込んでいた。
We are releasing the fix now, and expect the fix to be rolled out everywhere within the next half hour.
このポストが19時3分頃だから、もうすぐ直りそうだ。
地図サービスを抑えておきたい人必携です。
*1：スクリーンショット中のサンプルの地図も灰色になってる。
Googleから、GoogleAnalyticsをケータイのアプリケーションへのアクセスカウントに使う方法とサンプルスクリプトが公開されて久しい。これまで、やや無理のある方法を使ってGoogleAnalyticsでケータイのアクセスをカウントしてた関係で、ちょっと試用しており、PVなどの数字自体はとりあえず出ているものの、どうも数字が妙なところがちらほら…。
例えば、というか、とにかく、auのケータイにおいてセッションを把握できていない。つまり、1PV=1セッションとして数えられている。そのおかげで、全セッションに対するauケータイのシェアがやたらと大きくなるし、平均PVとか直帰率とか他の数字も巻き込んでおかしくなってしまっているようだ。あー、どうしたことでしょう。
まぁ、画面の解像度とかFlashのサポート状況などは、結局、GoogleAnalytics側で端末に関するデータを持っていないと取れないんじゃないか(例えば、機種名から解像度の情報を探してくるみたいな)と思われるし、そんなに重要なパラメータでもない気がするので、とりあえず置いておいてもいいかという気がする。あと、ページタイトルもNotSetになってるけど、これもPC版がJavaScriptで取ってる項目だろうし、取れなくてもしゃーないか。
…で。
Google先生に聞いてみたところ、同じようなことで困ってらっしゃって、かつ、Google提供のソースへのパッチを載せられているBlogのエントリーを発見→no title
パッチの内容を拝見すると、Cookieがうまく取れていないってことで、キャリア毎の個体識別番号を元にセッションを認識してもらいましょうという方針らしい。あー、なるほど、確かにこれで対応できそうだー。感謝。
auセッション問題は何とかなりそうだけど、試しに作ってみたプロファイルには、Google提供のサンプルコードで動いてるケータイのアクセスカウントしか来ないにも関わらず、ユーザの「OS」の項目が、「not set」になっていたりするセッションが多少あるのはどうしたことでしょう。うーむ。で、「not set」以外の「OS」としては、「EZweb Device」と「NTT DoCoMo」と「J-Phone」があるんだけど、最後の「J-Phone」の数が少ないので、この「not set」ってSoftbankっぽいなぁと思ったりするんだけど…(汗)あー(遠い目)
関数の記述に注意が必要
値段以上の価値ありまくり 暴露しすぎでは・・・
久しぶりに、memcachedの公式サイトを訪れてみたら、なんだか珍獣がわらわらいた。
…おお、なんだ、この珍獣は。かわいいじゃないか(笑)
あー、はい、さっさとソースを落として、memcachedのバージョンアップしますので、お許しを(汗)
© 2024 ただのにっき。
Theme by Anders Noren — 上へ ↑