定期アップデートのお知らせ。

• apache-2.0.63_3→apache-2.2.14_5
• bind94-9.4.3.4→bind96-9.6.1.2
• cyrus-imapd-2.2.13p1→cyrus-imapd-2.3.16
• perl-5.8.9_3→perl-5.10.1
• php5-5.2.11_1→php5-5.2.12
• ucd-snmp-4.2.7.1→net-snmp-5.4.2.1_6

いつの間にかucd-snmpがdeprecatedになっていました。

メジャーどころは、ほぼ最新版に上げてあります。
来年はFreeBSD 7.x→8.xの更新が大仕事じゃないかと思っています。

今年の更新はこれが最後。
来年もよろしくお願いいたします。

定期アップデートのお知らせ。

• openssh-portable-5.0.p1,1→5.1.p1,1
• openssl-0.9.8j_1→0.9.8k

今回もこれだけ。

定期アップデートのお知らせ。

• bind 9.4.3-P1→9.4.3-P2
• namazu 2.0.18 → 2.0.19

ネタがないので、それだけ。

同じ記事を別の場所にも書きましたが、 箱ファイルでおなじみの KING JIM の pomera がアツい。

これは「電子メモ」というもので、言ってみれば文章を書く機能だけを 持った携帯端末と言えます。
通信機能とかはないので、データをパソコンに送るにはUSBでつなぐか、 micro-SDを挿してやりとりする方法があります。
画面は広めだし、単四電池2本で20時間以上持つので十分。
予備電力が単四電池というのもうれしいですね。
折りたたみ式のキーボードで、広げるとフルサイズになる。

広げたところ

たたんでいるところ

たたんだところ


タッチ感はなかなか良好。
ちなみにFEPはATOKのようです。

うーん、これがSKKだったら…
あと、英語キーボードだったら…

今日のabuse BOTことYetiとBaiduspider。
22日のdailyが

+3924 @1 block in log quick from 61.247.192.0/18 to any group 50
+1884 @2 block in log quick from 119.63.192.0/21 to any group 50

で、23日のdailyが

+10710 @1 block in log quick from 61.247.192.0/18 to any group 50
+4003 @2 block in log quick from 119.63.192.0/21 to any group 50

です。

• Yeti：6786回
• Baidu：2119回

昨日よりも確実に悪化しています。
これってabuse@〜に送ると本当に対処してくれるんだろうか？

先日ブロックしたYetiとBaiduspiderですが、 ブロックした後も一向に減る気配がありません。
ちなみに21日のdailyによると

+531 @1 block in log quick from 61.247.192.0/18 to any group 50
+229 @2 block in log quick from 119.63.192.0/21 to any group 50

で、22日のdailyによると

+3924 @1 block in log quick from 61.247.192.0/18 to any group 50
+1884 @2 block in log quick from 119.63.192.0/21 to any group 50

となっています。
つまり、Yetiの方が3393回なので単純に25秒に1回のアクセスがある計算になります。
それはやりすぎじゃないのか…
そして、Baiduの方が995回なので、こちらは52秒に1回。

どっちもひどいな…

Seagate製のHDDが起動できなくなる可能性があるらしい。

Seagate社、自社製HDDの不具合を認める [slashdot.jp]
Seagate製HDDの一部でアクセス不能になる不具合 [ITmedia]

最近、というよりは2008年に製造されたモデルがあぶない。
実はSATAだけだろうと高くくくっていたのですが、 ATAも含まれているので注意しましょう。
ちなみに、わたしが先日買ったのはHGST製ですのでセーフ。
やっぱりSeagateを避けてよかった…

ちなみに過去にはMacbook搭載のSeagate製HDDにも トラブルがありました 。
HDDは最近のパソコンでは生命線なので、トラブルが出ると恐いですね。
業務用であれば大抵RAIDになっているので、まだ安心できる *1 んですが。

---

ちょっと前の記事ですが、備忘録としてメモ。

Appleと別れたPowerPCの次なるパートナー探し
世界で最も多く出荷されたRISCプロセッサMIPSのサバイバル戦略

なるほど。

HyperNikkiSystem にもRSS feedする機能ってあったんですね。
生のRSSは こちら から取得できます。

Safariを使っていると、RSS feedがあるサイトを表示していると URLバーのところの末尾に RSS と表示されます。
これってどうやって認識しているのかなーと調べてみました。
linkタグに記述することで表現しているらしい。
詳細は こちら がいいかも。
ようはlinkタグは、現在のページと関連する別ページへのリンクを 示すタグで、その「alternate」としてMIMEタイプrss+xmlなものへの hrefを貼るという仕組みです。

<link rel="alternate" type="application/rss+xml" title="RSS" href="./rss.cgi">

という感じです

MRTG を見ていただくと分かりますが、急激に負荷が高くなってmrtgが死んでしまいました。
それでも、OSが落ちなかったのはすごい。
httpdも子プロセスは死にまくりましたが、親だけは残っていました。

いろいろログを調べてみたら、やはり検索BOTの多重アクセスが原因らしい。
特にこのサイトは、ここのhnsを始め、wikiやらtDiaryやらで動的に生成するページが多く、 それらを全部検索BOTにcrawlされると大変なことになります。

ということで、お行儀の悪い次の検索エンジンをipfではじくことにしました。

• Yeti/1.0 (NHN Corp.; http://help.naver.com/robots/)
• Baiduspider+(+http://help.baidu.jp/system/05.html)

ちなみに、それぞれのアクセス元は

• Yeti/1.0：61.247.222.53

  % whois 61.247.222.53
  (snip)
  inetnum:      61.247.192.0 - 61.247.223.255
  netname:      NHN-NET-KR
  descr:        NHN
  country:      KR
  admin-c:      TS411-KR
  tech-c:       TS411-KR
  status:       ALLOCATED PORTABLE
  mnt-by:       MNT-KRNIC-AP
  remarks:      This information has been partially mirrored by APNIC from
  remarks:      KRNIC. To obtain more specific information, please use the
  remarks:      KRNIC whois server at whois.krnic.net.
  changed:      hostmaster%nic.or.kr
  source:       KRNIC
  

  ということで、61.247.192/18でまるっとBAN。
  
  
• Baiduspider+：119.63.194.120

  % whois 119.63.194.120
  (snip)
  inetnum:      119.63.192.0 - 119.63.199.255
  netname:      BAIDUJP-CIDR-BLK-JP
  descr:        Baidu, Inc.
  remarks:      Email address for spam or abuse complaints : sunruifeng%baidu.com
  country:      JP
  admin-c:      RS2845JP
  tech-c:       RS2845JP
  remarks:      This information has been partially mirrored by APNIC from
  remarks:      JPNIC. To obtain more specific information, please use the
  remarks:      JPNIC WHOIS Gateway at
  remarks:      http://www.nic.ad.jp/en/db/whois/en-gateway.html or
  remarks:      whois.nic.ad.jp for WHOIS client. (The WHOIS client
  remarks:      defaults to Japanese output, use the /e switch for English
  remarks:      output)
  changed:      apnic-ftp%nic.ad.jp 20080122
  source:       JPNIC
  

  って、Baiduって日本のアドレスブロックから来てたのか…
  そりゃ防げませんって。
  まとめて 119.63.192.0/21 でBAN。

これで少しはマシになるかな？

仕事でWindows 7 betaと関わることがあったので、 ものは試しとMacbookのVMware Fusionに入れてみました。（笑）

入手は簡単。
Windowsメッセンジャーのアカウントがあれば、 ここ からダウンロードできます。
インストールイメージが約2.5GBと大きいので注意しましょう。
それから、ダウンロードはどうもIEでないとダメな様子。
Safariではできませんでした…
あと、途中でインストールキーが表示されますので、忘れずにメモりましょう。

VMware Fusionにインストールするのであれば、ISOを焼く必要もないので 結構簡単です。
とりあえず、VMのテンプレートとしてはVistaを選んでおくといいでしょう。

インストールはだいたい2時間もあれば終わりそう。


Windowsといえば、無駄にグラフィカルでうざい起動画面ですが… Windows 7はさらにひどいことになっています。（笑）
VMwareなので、起動するときにすごい勢いでファンが周ります。


で、インストール直後のシステムのプロパティ。
あちらこちらでレビューされているように、結構軽いです。
会社で使っているVistaや、同じくVMwareに入れているWindows Server 2008よりも ずっと快適かもしれない。


そして、デフォルトのブラウザはInternet Explorer 8になっています。

ちなみにブラウザ名は

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2;
 .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729;
 Media Center PC 6.0)

だそうな。

最後に、IE8 on Windows 7 on VMware Fusion on MacOS X 10.5 で、ニコニコ動画。（笑）


今はまだXPで十分ですが、Windows 7 が出たらVistaを飛び越えてアップデートする 価値があるかもしれませんね。

FreeBSD の perl5.8 ports が 5.8.9 にアップデートされました。
これにともない、このサーバのperlも入れ替えました。

perlを入れ替えると困ることは、perl Modulesを入れ直しになることです。
アップデートする前の5.8.8は/usr/local/lib/perl5/5.8.8配下にありますが、 アップデート後の5.8.9では/usr/local/lib/perl5/5.8.9に変わります。
これに合わせて、いくつかのモジュールは配置場所が変わってしまうのです。

入れ直し面倒くさいなぁ、と思っていたら /usr/ports/UPDATING に次の文が。

20090113:
  AFFECTS: users of lang/perl5.8
  AUTHOR: skv%FreeBSD.org

  lang/perl5.8 has been updated to 5.8.9. You should update everything
  depending on perl. The easiest way to do that is to use
  perl-after-upgrade script supplied with lang/perl5.8. Please see
  its manual page for details.

perl-after-upgrateというものが用意されているらしい。
以下のようにrootで実行すると、何が行われるか見られます。

# perl-after-upgrade

で、その結果に問題がなければ

# perl-after-upgrade -f

で反映されます。

これはラクチンだ。

ここのサイトの トップページ に SSI で上部にアクセスカウンタが埋め込まれているのに お気付きでしょうか？

このアクセスカウンタは、遠い昔、おそらく2000年あたりに 私がフルスクラッチでPerlで書いたものがベースになっています。
当時、イメージを出力するレンタルアクセスカウンタが主流 *1 でしたが、 私は w3m といったテキストブラウザがメインだったので、 イメージではなく、テキストでアクセス数が知りたくてこういうものを 作ったのです。
そのソースを久し振りにメンテナンスしてみました。

いやー、当時と今では書き方がずいぶんと変わったので、 久し振りに見るときたないものですね。（笑）
ちなみに、このカウンタは単純にアクセス数だけをカウントしているのではありません。
同一IPからの短時間（1時間以内）のアクセスはカウントアップしないように しているので、総アクセス数だけでなく、IPアドレスごとの直近アクセス日時を 同時に記録しています。
このデータの保持に Berkeley DB を用いています。
ちょっとデータの中を見たくて、Perlで展開しようとしましたが… 単純にDB中のデータを %hash 展開したら

pid 41859 (perl5.8.8), uid 1001: exited on signal 11 (core dumped)

メモリ不足で落ちました…ってどれだけデータが入っているんですか。

どうやら、問題なのは

foreach my $key (keys %{$href}) {
(snip)

連想配列内のキーをforeachで取り出しているところのようでした。
foreach では keys 関数によって array を生成するので、 キー数が多いととんでもないほどメモリを使うそうです。
こういうときは

while (my ($key, $val) = each %{$href}) {
(snip)

each を使うといいらしい。

確かに3万件近くデータがあるので、そりゃ落ちますわね…

Berkeley DBでも3万件ものDBを保持できることにびっくり。
そして、この数年間でそんなにも異なるIPアドレスからアクセスされていた という積み重ねにもびっくり。

ちなみに、このカウンタは画像出力にも対応しています。
以下、その例です。

スタンダードタイプ


ちょっとおしゃれタイプ


漢数字タイプ（笑） *2

---