「FAST ESP Document Retriever」が酷い

最近、「FAST ESP Document Retriever」というクローラ?がすさまじい勢いで自宅サーバにサクセスしている。

正確にUser-Agentを書くと、


FAST ESP Document Retriever/CVS HEAD 2008-01-02 20:19:11 UTC

である。

このクローラ、baiduより酷く、すさまじい勢いでクロールしていくのです。

上記クローラの正体は不明。

ちなみにこのクローラ、GETやPOSTではなく、HEADメソッドでアクセスしてくるので、それほど負荷にはならないものの、httpdプロセスは立ち上がってしまうわけで。。。。

“「FAST ESP Document Retriever」が酷い” の続きを読む

行儀の悪い海外クローラをアクセス拒否設定する

前々から思っていたのだが、海外の検索エンジンのクローラーは行儀が悪いのが多い!

というのも、自宅サーバのApacheのアクセスログを[tail -f access_log]で見ていると、baiduとかyetiとかが、サーバーの負荷とか考えてないだろ!というくらいにアクセスしてくる!

  • baidu (中国)
  • Yeti/Naver (韓国)
  • など

しかも、これらの検索クローラーは、robots.txtが意味をなさない場合が多い。

それにこれらの海外クローラはアクセスしてきても、それらをインデックスしているページから飛んできてもほとんど意味がない。。。言語違うし・・

百害あって一利なし!!

ということで、Apacheでアクセスそのものを拒否ることにした。

Apacheの設定は以下の通り。

“行儀の悪い海外クローラをアクセス拒否設定する” の続きを読む

[Linux] yumのリポジトリURLを別ファイルにまとめる

なんか最近、サーバ(Fedora Core)のyumが異様に遅いので、ちょっとリポジトリの設定を見直してみた。

とりあえず、yum-fastestmirrorプラグインは入れてあるのだが・・・・

ちなみにyum-fastestmirrorプラグインとは、早いリポジトリを自動的に選択してくれるというもの。

インストールは下記のとおり。

# yum install yum-fastestmirror

で、次の表示が出ればOK。

# yum check-update
Loading "fastestmirror" plugin

で、話は戻るが、yumのリポジトリの設定は、/etc/yum.repos.d/の中に入っている3つのファイルに設定する。

fedora-core.repo、fedora-updates.repo、fedora-extras.repoの3つに設定する。

通常は以下のような記述が書いてあるはずです(fedora-core.repo)

“[Linux] yumのリポジトリURLを別ファイルにまとめる” の続きを読む

/lost+foundの中身って消していいの?

/homeディレクトリに「lost+found」というディレクトリがある。

/homeディレクトリをバックアップしようと思ったら、ものすごい大量のファイルがあった。しかも、/homeの中身とほとんど一緒。

 で、「lost+found」ディレクトリってそもそもなんなの?って調べてみた。

 どうも、ディスクに障害があり、その際にバックアップ?としてこのディレクトリの中にファイルが生成されるようだ。(なんかそんな感じ)

 で、なぜ、/homeの中身がそのまま入っていたのかというと、先日/homeとして使用しているハードディスクが物理的におかしくなり交換したことを思い出した。
 おそらく時に/homeのファイルが大量にlost+foundの中に入ってしまったのであろう。。。

 

“/lost+foundの中身って消していいの?” の続きを読む

サーバーのハードディスクがお亡くなりに。。。

このブログを運営しているのは、自宅サーバーなのですが、そのサーバーのデータ用ハードディスクがお亡くなりになった。。。(ToT)

数日前から、このサーバーへのアクセスが非常に重くなっていたのです。

WEBページの表示が遅いだけでなく、メールの送受信も遅くなっていました。

で、MRTGを見たら、確かにWEBのセッション数は減っている。しかし、それほどサーバーが重くなるほどの負荷はかかっていないし、アクセスログを見てもそんな感じでもない。コンソールからtopコマンドでシステムの負荷をモニターしていたが、全然負荷がかかっていない。

で、何が原因かわからないまま、数日が過ぎ、ふと、/var/log/messageのログをみたら。。。

Σ(゚□゚*)ナニーッ!!

以下のようなログメッセージが延々と出続けている。

May 21 05:21:30 sv1 kernel: ide: failed opcode was: unknown
May 21 05:21:30  sv1 kernel: end_request: I/O error, dev hdd, sector 173408911
May 21 05:21:34  sv1 kernel: hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error }
May  21 05:21:34 sv1 kernel: hdd: dma_intr: error=0x40 { UncorrectableError },  LBAsect=173408911, high=10, low=5636751, sector=173408911

あわてて、ネットで「DriveReady SeekComplete Error」を検索してみると。。。。

“サーバーのハードディスクがお亡くなりに。。。” の続きを読む

どなたかお助けを(^^;) (・・・not a valid MySQL-Link・・・・)

うちのセカンダリーサーバーで、試しにFedora 5 から Fedora 7まで段階的にアップグレードしたのですが、MovableTypeのダイナミックパブリッシングでエラーが出てほとほと困っています。

MTの管理画面は操作できるのですが、ダイナミックパブリッシングにしたら、ページをプレビュー出来ず、Apacheのエラーに以下のような内容が出てきます。

“どなたかお助けを(^^;) (・・・not a valid MySQL-Link・・・・)” の続きを読む

Rescue CDで起動しなくなったFedoraのgrub.conf、fstabを修正する方法

このエントリーは、自宅サーバーのOSを、fedora core 6(以下FC6) から fedora 7(以下FC7)へアップグレードしたときに陥ってしまった時の対処の仕方です。(またの名を備忘録)

FC6からFC7へyumを使ってアップグレードするときには、ファイルシステムのマウントポイントが変更されてしまう、というのをよく聞きます。具体的には「hd*」だったディスクが「sd*」になってしまうという。

参考URL

結局の所、うちの環境では?、hdの記述をsdに変更しなくても良かったのですが、FC6からFC7へアップグレードというページを検索しているとほとんどがその問題にぶち当たっているので、私も事前にgrub.confの内容の中で「hd」の箇所を「sd」に書き換えたのですが逆に起動しなくなってしまいました(^^;)
ということで、起動しなくなったLinuxをRescue CDディスクを使って、grub.confファイルの再編集をするやり方です。

“Rescue CDで起動しなくなったFedoraのgrub.conf、fstabを修正する方法” の続きを読む