2003-06-01
_ REFERER SPAM (13:49)
最近Referer SPAMがひどい。Referer SPAMってのは関係ない(リンクを張っているわけではない)ページのURLをRefererとして残していき、アクセス解析経由で新しい人がやってくることを狙ったもの。
だと思っていたんだけど、もう一つの意味もあることに気付いた。うちとかtDiaryみたいにRefererを公開しているサイトにRefererを残すことによって、「自動的に逆リンクが張られる」→「GoogleのPageRankがあがる」という効果もあるのか。それはむかつく話だな。
というわけで、Referer SPAMが来たら出来るだけまめに削除する方針にした。一番たちが悪いのは、ttp://www.downloadworx.com/およびここの「NETWORK SITES」「DOWNLOAD LAUNCH AREA」でリンクを張られているサイトたち。同じ系列で、同じスクリプトを使ってReferer SPAMをやっているのかな。ひとまずそこのリンクにあるサイトっぽい文字列を含むURLを遮断。かなり広い方向にアバウトにチェックしているんで、巻き込まれるサイトがあるかも。
同様の処理を入れたいけれども入力が面倒くさいという人は以下をどうぞ。 downloadworx cgifactory phplabs fallendomains openproxies asparea phpcrazy salesdex fontmage wwwkit hostedcron hostwars javascriptstation appletweb affiliatepayouts graphicmage ahtml marketingaces casinomage contentconcepts free-proxy script-central webmasterlynx うちにREFERERを残していったのは最初の5個かな。ほかにもあったかもしれないけど、最初の頃は見つけるたびに消していたんでよく覚えていない。
2004-06-01
_ 64.191.53.180でRNAlibwww-perl/5.69を回している人 (13:51)
ノーウェイトでblogmapのRSSをfetchして、1日117529ヒットってのは立派に攻撃レベルですよ。このアクセスだけで転送量も1G超えてますよ。もうdenyしたけど、これはいくらなんでもひどすぎ。
_ 今度はYahoo! Slurpか (13:51)
昨日の64.191.53.180からのアタック(http://mylog.ishinao.net/id/1227)はhttpdレベルで403返しただけじゃ負荷が収まらなかったんで、iptablesレベルでdenyしたらようやく収まった。
と思ったら、また気がついたら変にサイトが重い。で、見てみたら今度はYahoo! Slurpですか。blogmapのランキングでYahoo!が検索エンジンを変えたとかいうタイトルを目にした気がするけど、その関係かな。今日だけで5500アクセス以上来ているし、しかも複数のロボットが同時にアクセスしている関係上、集中同時アクセスなんかも発生している模様。
基本的に検索エンジンロボット系はできる限り弾かない方針なんだけど、こんなのがしばらく続くようだとちょっと我慢ならないなー。明日になってもアクセスが収まらないようだったら、66.196.90.11〜15あたりをまとめて弾くか。人が忙しいときにこういうことはせんでもらいたいのー。
2005-06-01
_ 広告ツール機能追加 (10:22)
昨日紹介した広告ツール機能強化版に、ランダム表示モードを追加しました。
- random - 1に指定すると、表示順序をランダムソートする。省略時は従来通りのソート順。
たとえば、
<script type="text/javascript" charset="euc-jp" src="http://1470.net/api/asin_cms.php?limit=5;random=1;mode=js;associate=your-associate-id"></script>
なんてやると、
なんて感じになります。要はblogmapのランキング入りしている中から適当に5個の商品を抽出して表示しているわけですね。もちろんwebsiteを指定してやれば、サイトで紹介した商品からランダムに選択させることもできます。
表示内容は一定期間キャッシングされますが、キャッシュが切れると自動的に更新(表示内容が差し変わる)されます。キャッシュ時間はサーバー負荷を見つつ適当に変更しています。
_ またDBがこけてました (10:55)
前とまったく同じコケ方をしてました。これはもしかしたらディスクかなー。やばいなー。もう一個ディスクを載せているんで、そのうちそっちのディスクにDB領域を移動するか。でもこけているのはOSが載っている方のディスクなんで、ディスクが死んだらOSが死ぬんだよなー。
データ自体はもう1台のサーバーにレプリケーションがあるんで、(レプリケーションタイムラグの分以外は)失われることはないんだけど、サーバー自体がこけるとバックエンドを動かせなくなるんで、できれば死なないで欲しいのう。さすがに代替サーバーを用意するコストはかけられないし。
_ はてな 各種wiki記法とはてなダイアリー記法の違いを一覧できるページ。yukiwiki, pukiwiki, wikimedia(wikipedia)などwikiの各記法、ならびにtDiaryのwiki記・・ (15:39)
おもだった(日本製)Wiki記法の対照表。tDiary WikiスタイルはHikiと同じ。
はてなダイアリー記法は、Wiki記法的部分はYukiWikiベースだろうけど、Wiki記法の延長として作られたものではなく、HTML中に補助的にWiki的な簡易表現を使えるようにしたもの、って感じ。
Wiki記法的な部分についても、はてな全体のサービスとの連動に特化した機能や、他のWikiにはあまりない(日記/blogサイト向けの)独自拡張が多いんで、他の記法とは比較しにくいと思う。対照表的に表現するとはみ出す部分が多すぎる。
って、初めてはてなで回答を書いてみようかと思ったけど、はてなで書くよりも自分のページに残しておきたいんで、こっちに書いてtrackbackを送ることにしよう。
2006-06-01
_ Zend_Search_HyperEstraier設計中 その2
いろいろいじり続けて、現在の構成は以下のような感じ。
- Zend_Search_HyperEstraier
- Zend_Search_HyperEstraier_Exception
- Zend_Search_HyperEstraier_SearchCondition
- Zend_Search_HyperEstraier_Document_Abstract
- Zend_Search_HyperEstraier_Document
- Zend_Search_HyperEstraier_DocumentList
- Zend_Search_HyperEstraier_Document_ListItem
- Zend_Search_HyperEstraier_SearchResult
- Zend_Search_HyperEstraier_Document_SearchResult
- Zend_Search_HyperEstraier_Node
- Zend_Search_HyperEstraier_Node_Api_Abstract
- Zend_Search_HyperEstraier_Node_Api_Client
- Zend_Search_HyperEstraier_Node_Api_Master
- Zend_Search_HyperEstraier_Node_Client_Interface
- Zend_Search_HyperEstraier_Node_Client
- Zend_Search_HyperEstraier_Node_Client_Distributed
- Zend_Search_HyperEstraier_Node_Client_Information
- Zend_Search_HyperEstraier_Node_Document
Zend FrameworkというかPEAR系の命名規則だと、継承関係の下位にあるクラスも、上位にあるクラス(抽象クラスやインターフェース)も、単にグルーピングされただけの関連クラスも、すべてごちゃごちゃにディレクトリの下側に来ちゃって、なんだかすっきりしないなー。やっぱりネームスペースを導入して、ディレクトリ構造=ネームスペースにしちゃって、関連クラスの命名規則はもっと自由に(Document_AbstractとかClient_Interfaceとかしなくて済むように)した方がいいなー。



_ てつや [Hyper EstraierをPHPから使用したくさまよって、ここにたどり着きました。P2Pからの利用でなく、コアA..]