コンピュータの最近のブログ記事

これからはクラウドだぜ!ということで、この気持が冷めないうちになにかをはじめようと、Google App Engine(GAE)のアカウントを取得した。言語はRuby(JRuby)を選択し、自分がふだん使っているFreeBSDマシンに開発環境を構築した。例によっていくつかトラブルがあったので、メモを残しておく。

インストール対象のOSはFreeBSD 7.2-RELEASE-p5。まずは、JavaのSDKとしてFreeBSD FoundationのJava配布サイトからdiablo-jdk-freebsd7.i386.1.6.0.07.02.tbzを取得してpkg_addコマンドでインストールする。そのままだと日本語が文字化けするので、これを解消するために以下のコマンドを実行する。

% cd /usr/local/diablo-jdk1.6.0/jre/lib/fonts/
%sudo ln -s /usr/local/lib/X11/fonts/TrueType fallback
%

JDKがらみでもうひとつ。このままGAE/JRuby開発環境を作って最後にアプリをGAEにデプロイしようとすると、(エラーメッセージを控えてない、ごめん)GAEのサーバとのSSLのコネクションができずにデプロイに失敗する。これを回避するための方法は、例えばDebianのca-certificates-javaパッケージなどを取得して、そのなかに含まれているcacertsファイルをdiablo-jdkのファイルと入れ換える。

% pwd
/tmp
% wget http://ftp2.jp.debian.org/debian/pool/main/c/ca-certificates-java/ca-certificates-java_20091021_all.deb
% ar x ca-certificates-java_20091021_all.deb
% tar xvf data.tar.gz
% cd /usr/local/diablo-jdk1.6.0/jre/lib/security/
% sudo cp /tmp/usr/share/ca-certificates-java/cacerts ./
%

次にrubyとgem。rubyは最新の1.9.1-p376で、gemも最新の1.3.5をインストールした。これ自体はノープロブレム。そのあと、gemを用いてgoogle-appengineパッケージをインストールするのだが、このときいっしょにインストールされるrubyzip-0.9.1が使用しているftoolsがruby-1.9.1ではdeprecatedだとのことで、処理が途中で失敗してしまう。いろいろ調べて、以下のパッチの要領でftoolsのところをfileutilsで書き換えることにより解決した。

% pwd
/usr/local/lib/ruby/gems/1.9.1/gems/rubyzip-0.9.1/lib/zip
% diff -u zip.rb.orig zip.rb
--- zip.rb.orig 2009-12-13 22:15:39.000000000 +0900
+++ zip.rb      2009-12-14 20:38:25.000000000 +0900
@@ -1,7 +1,7 @@
 require 'delegate'
 require 'singleton'
 require 'tempfile'
-require 'ftools'
+require 'fileutils'
 require 'stringio'
 require 'zlib'
 require 'zip/stdrubyext'
@@ -662,8 +662,8 @@
         # ignore setuid/setgid bits by default.  honor if @restore_ownership
         unix_perms_mask = 01777
         unix_perms_mask = 07777 if (@restore_ownership)
-        File::chmod(@unix_perms & unix_perms_mask, destPath) if (@restore_permissions && @unix_perms)
-        File::chown(@unix_uid, @unix_gid, destPath) if (@restore_ownership && @unix_uid && @unix_gid && Process::egid == 0)
+        FileUtils::chmod(@unix_perms & unix_perms_mask, destPath) if (@restore_permissions && @unix_perms)
+        FileUtils::chown(@unix_uid, @unix_gid, destPath) if (@restore_ownership && @unix_uid && @unix_gid && Process::egid == 0)
         # File::utimes()
         end
     end
@@ -1566,7 +1566,7 @@
       tmpFilename = tmpfile.path
       tmpfile.close
       if yield tmpFilename
-        File.move(tmpFilename, name)
+        File.rename(tmpFilename, name)
       end
     end
ino%

あとは手順どおりで、Sinatraを用いてRubyで書いたWebアプリケーションをGAEにデプロイできた。さてさて、これから先の最大の問題は、おれがRubyをほとんど知らんということだ。まあ、この先はじっくり勉強しながら進めることにしましょ。

先日に書いたRHELのインストールの話の続き。ググってみつけた、NICのチェックサムオフロードを無効にすればSSH通信（というかTCP通信）ができるようになるのではないかというやつを試してみたんだけど、結果から言うとこれはダメだった。VMwareでブリッジ接続したゲストOSとTCP通信ができないという情報はいくつか見つけることができたけど、どれも解決には至っておらず、これはもう無理かなと諦め、ひとまずstoneでホストOSのポート22をRHELにポートフォワーディングすることでお茶を濁しておくことにした。この現象、ゲストOSのイメージを別マシンに移したらそっちでは普通に動作したなんて話もあったので、やはりNICを含んだハードウェアに依存しているように思う。しかしこういケースがあるようだと、客先への提案として「VMwareで仮想化しましょう」とか気楽に言えないよね。ちょっと困ったな。

と、この話はここで終わるかと思われたんだけど、まだ続きがあった。その後、この現象はVMwareだけで発生する現象なのか他の仮想化ソフトでもおきるのか確認してみようと思い立ち、Virtual Boxをインストールしてみた。VMwareを動かしている計算機にVirtual Boxも入れちゃってもだいじょうぶか不安もあったんだけど、まあ、ダメならアンインストールすればいいやと、とりあえずやってみた。そうしたら、案の定不安は的中し、インストールプロセスは最後の最後でハングしやがった。インストーラの強制終了もWindowsのシャットダウンもできず、電源をバシッと切って再起動した。NICにはVirtual Boxのブリッジ接続用ドライバがインストールされているものの、ソフトウェア自体は「プログラムの追加と削除」からアンインストールすることもできず、Virtual Boxのインストールはやはり正常に完了していない状態だった。ちなみに、この状態ではVMware上のRHELとのSSH接続は相変わらずできない状態だった。んで、しばらくこの状態で動かしていたんだけど、Virtual Boxのブリッジ接続用ドライバが残ったままだったことを思い出して、これを削除して再起動した。そのあとなんとなしにRHELへのSSH接続を試してみたところ、なんとびっくり、すんなり繋がるではありませんか！ SSHといっしょに確認していてやはりダメだったFTPも普通に繋がる。もうなにがなんだかさっぱりわかりません...。ホントなら、環境をまた戻していってどこが原因だったのか確認したいんだけど、なにせ業務用の開発環境でまともに動いていることが大事だし、なにかの間違いで二度と接続できなくなっちゃったら困るので、しばらくはこのままでいくことにした。幸いにもうちの会社にはおれのと同一構成の計算機が他にもあるので、機会があればそちらで再現テストをしてみるつもりだ。

FreeBSDネタと違って、こちらは仕事での話。会社で使ってるWindows XPにVMware Server 1.0.10（バージョン2系列はあのWeb管理画面がなんか嫌い）を入れて、仮想OSとしてRed Hat Enterprise Linux 5をインストールした。仕事でRHELに触ることはよくあるけど、自分でインストールするのは初めてなんだよね。細かい手順は飛ばすとして、トラブったところだけメモを残しておく。

その1、仮想HDDを認識しない。VMwareの標準設定で仮想HDDを作成すると、SCSIアダプタとしてBus Logicが使用されるのだが、RHEL5では認識してくれず、「インストール対象のHDDがみつからない」というエラーになってしまう。解決策は、VMwareで仮想OSを構築するときに標準設定ではなくカスタム設定（だったかな？）を選択した上で、仮想HDDのSCSIアダプタとしてLSI Logicを選択すればよい。

その2、外部ホストから仮想OSであるRHELに対してSSH接続ができない。今回、RHELはブリッジ接続でネットワークにつないでいて、RHELから外部ホストに対しては正しく通信ができるんだけど、外部ホストからRHELに対してSSH接続することができない。ちなみに、ホストOSからRHELに対しては問題なくSSH接続ができる。また、外部ホストからの接続もRHELに到達はしているみたいで、/var/log/secureには"Did not receive identification string from UNKNOWN"というsshdのログが記録されている。これらの現象から、どうやら原因はRHELの設定ではなく、VMwareのブリッジ機能、またはWindows XPのネットワークドライバのあたりにあるのではないかと推測している。この問題、現在まだ解決できていないのだが、ついさきほどみつけた情報で、同様の現象がNICのチェックサムオフロードをオフにすることで解決したという記事があったので、これで解決すれば原因の箇所は予想通りということになる。こんど出社したときにこれを試してみるつもりだ。

11月末、ついにFreeBSD 8.0-RELEASEが出たので、さっそくNB100にインストールしてみた。んが、7.2で問題なく使用できていたEMOBILE D02HWがなんかおかしい。7.2では、umassは最初に認識された後にデタッチされて後は普通にu3gモデムとして使用できるのだが、8.0ではumassのエラーが延々と出力され続ける。モデムとして正常に機能するのかどうかは試してみなかった（これは失敗、確認しておけばよかった）ので不明だが、なんか嫌なので7.2に戻しちゃったよ。あと、7.2では無線LAN（ATHEROS AR5007EG）が使えなくて、これが8.0では使えるようになっていることも期待してたんだけど、これも変わり無し。う～ん、8.0が出たらいろいろ本気出そうと思ってただけに、ちょっと残念だなあ。

これで映画ができないかな。「私をスキーに連れてって」的なノリで。ローンチ直前のシステムに重大なバグが見つかり大ピンチ。修正するには膨大な量のコードを書き直さなきゃならない。誰もが絶望する状況の中、一人の男が「このキーボードでなら、いけると思う」とつぶやき、すさまじいスピードでコードを書き始める。かたずを飲んで見守る仲間たち。できあがったプログラムはフロッピーに格納して山を越えた先の客先に届けなければならない（なんでだ？）。移動の手段は当然スキーにGT-FOURだ。果たしてフロッピーは間に合うのか？ 悪いやつにつかまってる原田知世ちゃんの運命は如何に！？ ハラハラドキドキの2時間半。驚愕のエンディングはぜひ劇場でご覧ください！！ なんて感じでどう？

20年間がんばってきた自分へのご褒美に買ってしまった。全ハッカー憧れのキーボード、HHKBシリーズの最上級モデル、HHKB Professional JP PD-KB420Bだ。静電容量無接点方式の軽いキータッチは、少々雑にタイプしても打ち漏らすことがほとんどなく、ストレスなく文字入力ができる。会社ではなく家で使うために買ったんだけど、もうしばらく使ってみてあまりにも具合がよかったら、会社用にもう一個買っちゃおうかな。いや、会社の備品としてなんとか購入できないかな...。

「鉄道居酒屋LittleTGV」などという店ができてるのね...。名前からわかるとおり、LittleBSDの系列店らしい。しかし、BSDでググったときにFeeBSDやOpenBSDよりも前にLittleBSDが出てくるってのはどうなのよ?

「PDAIR レザーケース for NB100」。これほしい。でもちょっと高いな...。

まあ、エラーになるのはアプリの問題なんだろうけどね、実際は。あ、八達通（オクトパス）はMTRだけじゃなく、香港の公共交通期間のほとんど全てで使えます、念のため。

数日前にFreeBSD 7.2-RC1が出たので、NB100に入れていた7.1-p3を更新してみた。/usr/src/UPDATINGによれば、PCI-Expressに対応した新しいAtheros HALモジュールが導入されたとのことなので、以前の挫折の状況が改善されていないかと期待しつつ試してみた...のだが、どうやら状況は変わりなし。デバイスは認識されるがUPしようとするとinterrupt stormが発生するという状態。う〜む、残念。

あともうひとつ、以前はEMOBILE D02HWを使うためにパッチを当てていたのだが、7.2-RC1のソース(sys/dev/usb/u3g.c)を見ると、D02HWの中身であるHuawei E220に関する記述が追加されているのを発見。GENERICカーネルのままだとD02HWをつなげてもumassとして認識されてしまうので、以前と同様にumassを外したカーネルを作成してみることに。んで、今はカーネルを再構築中。さてさて、どうなることやら...。

（2009/04/23追記）

ダメでした(;;) ソースコードのコメントを見る限りは、umassとして認識した後にしばらくしてumodemに切り替わる作りのように思えるんだけど...。しかし、このままだと7.1にパッチを当てて使えていた（ただし、高負荷時にしばしばカーネルパニックが発生していた）よりも状況が後退しちゃったな。もう少しまじめに追いかけてみようかなあ。

（2009/04/23追記その2）

ごめん、u3g.cだけにu3g.koをloadしたらちゃんと(umodemじゃなくて)ucomとして認識されて/dev/cuaU0.0が生成され、無事に接続ができたよ。高負荷時にパニックが起きるかどうかは、しばらく使ってみてあらためて報告します。これで後は無線LANが使えるようになればなあ...。

最近ちょこちょことLudiaを試している。難しいことをやってるわけではなく、基本的な使い方を学んでいるレベルなんだけど。そんななかでちょっとハマったのが、PostgreSQLのバージョンによって検索時の演算子が変更されること。最初に構築した環境がPostgreSQL-8.1.3+Ludia-1.5.1+Senna-1.1.4だったんだけど、この環境で動いていたプログラムが、PostgreSQL-8.3.3で構築した環境では正しく動作しなくなった。具体的には、英単語の部分一致検索をするためにludia.sen_index_flags=31(NORMALIZE|SPLIT_ALPHA|SPLIT_DIGIT|SPLIT_SYMBOL|NGRAM)で構築したfulltextuインデックスを使って@@演算子による検索を行ったとき、PostgreSQL-8.1.3では意図したとおりに動作するのに8.3.3では部分一致がヒットしないという現象がおきた。原因は上に書いたとおり、Ludiaが使用する演算子が@@から%%に変更されたためなんだけど、これがわかりにくいのは、なんにせよ検索処理自体はそれっぽく機能してしまうってことにある。Ludiaの演算子が変更された理由は、PostgreSQL-8.3からtextsearchが標準機能に組み込まれて@@演算子がそちらで使われることになったからだと思う。つまり、PostgreSQL-8.3で意図した検索結果が得られなかったのは、Ludiaではなくtextsearchによる検索が動いていたからなわけだ。それに、後方互換性のためだと思うが、8.3以前のPostgreSQLとLudia-1.5.1を組み合わせたときに@@演算子が使えてしまうことも問題をややこしくしていると感じる。WWW上の情報、例えばThinkITの連載を見ても「@@演算子で検索を行う」と書かれていて、このへんの記事を見ながら最近のPostgreSQLを使ってLudiaを導入して、Ludiaで検索しているつもりが実はtextsearchを使っていた...なんて人は、けっこう出てくるんじゃないかな、とちょっと心配。そんなドジがおれだけならいいけど。これを調べるのにけっこう時間をとられちゃったんだよなあ。まあなんにせよ、ドキュメントをよく読めばわかることだから、なにかやるときにはちゃんと最新のドキュメントに目を通しましょう、ということかな。

以前に書いた、NB100上のFreeBSDでcsupしてmake buildworldしたときにソースファイルが壊れる現象について、もしかして交換したメモリが悪いのではないかと思っていたのだが、昨日ちょっと時間があったので、元のメモリに戻して同じことを試してみた。その結果、make buildworldは無事に終了した。う〜ん、これはやっぱりメモリの不良かなあ。さてどうしよ。とりあえず容量的には元の1GBでも困らないのでしばらくはこのまま使うとして、メモリは交換してもらうか買い換えるか。Windowsで再現可能な障害があれば話が早いんだけど。あとで保証の内容を確認してみよっと。

年が明けてFreeBSD 7.1-RELEASEも出たので、csupでソースツリーを更新してmake buildworldを実行してみた...のだが、なにか怪しい。makeがシンタックスエラーとかで失敗するんだよね。で、エラーの箇所を確認すると、プログラムのソースがあからさまにおかしい。ソースファイルを再度取得してdiffをとると、

% pwd
/usr/src/contrib/bind9/lib/isc/include/isc
% diff list.h.old list.h
51c51
<               if ((list).he`d != NULL) \
---
>               if ((list).head != NULL) \
% 

みたいなことになってる。これじゃコンパイルとおらないよね。え〜と、これはいったいどういうことなんでしょうか。なんでこんなことがおきるの？ なんかすごい根本的な部分で問題を抱えているような気がしてきたんですけど。

先日の「NB100のFreeBSDでEMOBILE D02HWを使用する」で、今になって気づいたこと、書き忘れていたことがあったので追記。ひとつめ、D02HWをNB100の左側面にあるUSBポートに挿すと正常に動作せず、"interrupt storm detected"のエラーが連発する。右側面の2箇所ならどちらでもだいじょうぶ。もうひとつ、これはD02HWに限らず、というかBIOSのデバイス管理に依存しているように思うんだけど、WindowsからFreeBSDに、またはFreeBSDからWindowsに切り替えるとき、OSの再起動だと周辺機器がうまく認識されず、電源を落としてのコールドブートが必要。いまのFreeBSD on NB100ではACPIがうまく機能していないんだけど、なんとなくこのへんが問題の根本な気がしてきたよ。

無線LANでの接続に失敗してちょっとへこんだが、だがしかし、ここで立ち止まっているわけにはいかない、前へ進み続けるのだ！ というわけで、今度はEMOBILE　D02HWでの接続に挑戦。実は、素の状態の7.1-RC1カーネルで接続できるかどうか試してなかったことに後になってから気づいたんだが、「FreeBSD7.0でemobile(D02HW)を使う」や「Inspiron 710m で FreeBSD - D02HW で ppp」などのサイトを見て「[usbdevs] [patch] teach usbdevs / ubsa(4) about Huawei E220 G3 Modem」のパッチにたどり着き、7.1-RC1のソースにHUAWEI E220の定義が書かれていなかったのでたぶん対応していないんだろうと判断し、パッチをあててカーネルを再構築してみた。ppp.confの内容は上の日本語のサイトを参考にして、というかほぼそのままコピらせてもらい、D02HWを接続してpppコマンドを実行したところ、見事に接続に成功。FTPで10MB程度のファイルをダウンロードしてみたところ、約120KB/secの速度が出ていた。まあじゅうぶんかな。

休日出勤の前に秋葉原による時間がとれたので、ドスパラでNB100用のメモリを購入する。モノは、Webで動作実績が確認できていたトランセンドのJM667QSU-2G。価格は2,480円なり。会社に着いてさっそく取り付け。WindowsでもFreeBSDでもちゃんと認識された。それにしてもカタログにはなんで最大1GBまでって書いてあるんだろうね。

2009/4/8追記。

検索サイトから「NB100　メモリ増設」のキーワードでこちらに来る方が比較的多いので追記しておくけど、ぼくの環境ではメモリ不良によるものと思われる障害が発生したため、いま現在は純正の1GBメモリに戻して使用している。運悪くハズレをひいたかな。まあ、皆様もメモリ交換は自己責任でどうぞ。

さてさて、無事にFreeBSD 7.1-RELEASE-RC1がインストールされたTOSHIBA NB100、次のステップとして無線LANでのネットワーク接続にチャレンジしてみた。NB100に搭載されている無線LANはAtherosのAR5007というやつ。オリジナルの7.1-RC1カーネルだと、起動時にath0: unable to attach hardware;などというメッセージが表示されて正常に認識されていない。「EeePC で FreeBSD の ath0。」など、いくつかのサイトを参考にしながら最新の状況を確認した上で、The MadWifi projectで開発されているmadwifi-hal-0.10.5.6-r3879-20081204.tar.gzを持ってきてこれを展開し、madwifi-hal-0.10.5.6-r3879-20081204/hal/ディレクトリ以下のファイル（サブディレクトリも）を/usr/src/sys/contrib/dev/ath/にコピーしてカーネルを再構築してみた。その結果、ath0は正しくattachされるようになった...のだが、ifconfig ath0 upしてもリンクアップしてくれない。そればかりか、interupt storm detected on irq10（irq11についても同様）というメッセージが延々と出力されてしまう状態。IRQ10と11を使っているUHCIを無効にしてみたりしたんだけど、interrupt stormは出なくなったが無線LANは接続できず。う～む、一筋縄ではいかないなあ。今回は残念ながらここでいったんあきらめることにした。

そうそう、今回の作業でカーネルを再構築してみたんだけど、所要時間は約40分だった。意外と速くない？

ははは、やりました、ついにインストールに成功しました。7.1-RELEASE-RC1のbootonly ISOイメージファイルを使ってインストール用USBメモリを作成し、これでACPIを無効にして起動したら、HDDもNICもちゃんと認識してくれて、無事にネットワークインストールが完了しました。はっはっは。Xも問題なく動いているしタッチパッドも認識している。基本的な機能には問題はなさそうだな。あとは無線LANとEMOBILEが動けば文句なし。例によってググってみたところ、たぶんなんとかなりそうな感じ。あ～なんか楽しくなってきたぞ。

NB100に搭載されているNICはRealtekのRTL8102E。ということでググって調べてみたところ、このNICは7.0-RELEASEではサポートされていないことが判明。ただ、RELENG_7_1のCVSソースを見ると#define RL_HWREV_8102E 0x34800000なんて記述があるので、いま出ている7.1-RELEASE-RC1なら認識してくれるんじゃないかな。さっそくにでも試したいけど、今日は客先作業で会社に戻らないのでUSBメモリの書き換えができないよ。あ～まだるっこしいなあもう...。