moodleにJava appletを置こうとしてFirefoxのバグにはまる

moodleのコース内にちょっとしたJava appletを置くことにした。ウェブページリソースを作り、appletのためのタグの書きかたをすっかり忘れたので他のサンプルをみようみまねで挿入し、目的のjarファイルをアップロードして表示させてみると、指定したエリアだけ確保するもののappletがスタートしない。

FreeBSDのFirefox 2では動く。WindowsのFirefox 3では動かない、IE7では動く。Javaのコントロールパネルからキャッシュを明示的に消さないと、IE7で動いてしまった後はFirefox 3でも動いてしまって、途中大混乱したが、Google Chromeでも動く、Safariでも動く、ともかくFirefox 3で動かない。

apacheのログによると、303、つまりSee otherで、ログインページに飛んでいる。コースを表示中だからログインは当然している。なのにログインページに飛ばされるということは、MoodleSessionのクッキーをちゃんと送っていないということしかない。ログのフォーマットを変更してこのクッキーを表示させてみたら、たしかにFirefox 3のみ送っていない。他のブラウザは同じ Java RE で動いているので、Firefox 3のバグに違いない。

というわけで、Bugzillaで検索して出てきたのが、Bug 441166。「サードパーティの Cookie も保存する」のチェックをはずしていると、appletがクッキーを送らないらしい。原因はまさにこれだった。基本的に一部の例外以外はFirefox終了時にクッキーを消す設定にしているが、Firefox 3の導入時に、そういえばサードパーティCookieは拒否することにした気がする。Firefox 2にはそんな設定がなかったから問題が起きなかったわけである。

いちおう解決というか、Firefox 3にがんばってもらわないと好みの設定ができないわけで、その意味で当面解決不能。

フレッツ・光プレミアムのインストールツールではまる

いろいろあってNTT西の光プレミアムを入れることになり、VDSLモデムとCTUとVoIPアダプタをごちゃごちゃつける工事がなんとか終わって、とりあえずひかり電話が開通してることを確認してもらった。プロバイダとかの設定はどうするのときいたら、とにかくCD-ROMつっこんでそれでやってねと言い残して、工事の人は去っていった。モデムのマニュアルもCTUのマニュアルもほんの薄っぺらいものしかなく、必要なものはすべてCD-ROM内っぽい。

無用なトラブルを避けるために言われたとおりにCD-ROMをさし、無線LANは念のため使わず、CTUとPCをケーブルで直接つなぐ。CD-ROMに入ってるインストールツールを動かし、スタートアップツールのインストールを開始すると、途中で、「IPv6がインストールされていません。IPv6をインストールする必要があります。インストールしますか？」という半強制的なダイアログが出て、キャンセルする理由もないのでそのままOKし、とりあえず完了。次にインターネット接続設定に進むと、デフォルトブラウザじゃなくIE7が起動され、「[2001:d70:3:1::3:3] に接続しています。」状態から進まない。何度か試すと、ようやくCTUのログインページが表示されて、さらにプロバイダのID/パスワードを入力するページが表示されて、設定完了。Yahooなど主要サイトには問題なく接続できることを確認し、あっさりと、めでたしめでたし。

いや、違った。CTUの細かい設定などはどうするのだろうと思い、スタートアップツールを動かして、「CTU設定」をクリックしてみると、IEが開いて接続中のまま固まる。しかもCPUを100%食っているようである。https://ctu.fletsnet.com/ を直接Firefoxで開こうとしても症状は同じ。

ふと思いついて、ローカルエリア接続のプロパティからMicrosoft TCP/IP version 6のチェックをはずしてみると、あっさりつながるようになった。別のPCで、最初からIPv6のインストールをキャンセルしても同様。まったく問題なし。IPv6をインストールするとそのPCでもだめ。XP SP3がIPv6に未対応なのかとも思ったが、これほど一般的な環境で問題が起きるなら、NTTだって最初からIPv6を入れさせたりしないだろうし、まったく手がかりなし。

で、2chに頼って、光プレミアムのCTU設定スレがあるのをみつけ、IPv6で検索したら、NOD32は未対応のくそソフトとか、3.0なら対応してるとか。まったく盲点だった。家中のPCにはNOD32 v2.7が入っている。どのPCでもだめなはずだ。最初のインストールツールで1回であれCTUにつながった方が奇跡的だ。DNSのAAAA検索がうまくいかなかったか何かなんだろうか。

ためしに3.0にバージョンアップしてみたら（ライセンスはそのまま動くらしい）、IPv6下でFirefox, IEともに無事に接続できるようになった。ようやくめでたしか。

ところが、ともちゃ氏によるNTT西日本 Ｂフレッツシリーズ及び光プレミアムの裏側は、Bフレッツがらみの濃い情報がたくさんあるが、IPv6が生きている状態だとなぜだか接続できない（たまたま？）。

geliで遊ぶための自分用メモ

FreeBSDでは、ezjail-adminを使えば、-c eli とすることで、簡単にgeliで暗号化したjailを作ることができるが、jailの数が増えるとどうも管理が面倒になった。キーファイルを使えばjailの数だけいちいちパスフレーズを打つこともなさそうだが、マウントポイントが多いし、なにかオーバーヘッドが大きそうな気もする。不意にクラッシュした後にそれぞれfsckするのもめんどくさい。なので、ディスクまるごとgeliで暗号化して、jailはその上に置くことにしたい。

それに、「失われた友人の400GBに捧ぐ - 暗号化GELI(8)メタデータ保存機能追加」（gihyo.jp）とか恐ろしげな記事があるし、もうちょっと geli を自在に扱えるようになっておきたい。

というわけで、geli で遊ぶための知識をいくつか。

geliでは、物理的なデバイスの最後の512バイトにメタデータを置いている。メタデータの中身はおよそ次のとおり。

• マジックナンバー'GEOM::ELI'
• 暗号方式
• パーティションサイズ、セクタサイズ
• 64バイトのソルト
• 192バイトのマスターキー×2個（0番と1番）
• MD5ハッシュ

ちゃんと調べてはいないが、パスフレーズと64バイトの乱数キーファイルとマスターキーの一方とソルトとセクタ番号を組み合わせると、セクタ暗号化の鍵が得られるっぽい。0番でも1番でも同じ鍵が得られるようにマスターキーを生成するのだろう。

geli コマンドはほとんどメタデータにのみ作用する。サブコマンドの主なものは次のとおり。

• geli init: メタデータの新規作成。ソルトの生成（以降変化しない）。パスフレーズ、キーファイル、ソルトにより0番のマスターキーを生成。
• geli dump: メタデータの表示。
• geli backup: メタデータのファイルへの保存。
• geli restore: 保存したメタデータの復元。
• geli setkey: 指定した番号のマスターキーの変更。パスフレーズ、キーファイル、ソルトにより生成される。
• geli delkey: 指定した番号のマスターキーの破壊。
• geli kill: メタデータの破壊。乱数で上書き。
• geli clear: メタデータの破壊。ゼロで上書き。

setkey, delkey, kill, clearで破壊しても、backupがとってあれば、restoreすることにより完全に元に戻せる。geli(8) にあるように、管理者用のメタデータを別の場所に保存してから、ユーザのマスターキーで上書きしてしまうという管理シナリオもありうる。

上のgihyo.jpの記事は、init時に自動的にメタデータを保存するようになったというもの。backupを用いて手動で保存すれば同じ（はず）。

オプションで geli init -a aalgo を用いると、データ完全性検証をするので、セクタごとにハッシュ分の領域が食われる。少なくともinitは相当遅そう。attachも？通常使用のパフォーマンスはどうなんだろう。そもそも、誰かがattach前にデータを壊したことを知りたいという用途はかなり少ないかも。

FreeBSDのjail内でdhcpdを動かす

今のところFreeBSD-7.0のjailではbpfが動かないが、net/isc-dhcp3-serverにはDHCP_SOCKETSオプションがあり、bpfを使わずに動作するバイナリがビルドできる。しかし、これをjail内で動かすだけで、dhcpサーバとして働くかというと、そうもいかなかった。

まず、jail内ではbroadcastパケットを受信できないようで、dhcpリクエストの中継サーバが外に必要らしい。jail(8), jail(2), ハンドブックを探したが、broadcast受信の制約は見かけなかった気がする。jailの制約はときどき変わったりするので、どこかにまとめてあればいいんだけど。

そこで次に、net/isc-dhcp3-relayをホスト側で動かしてみた。そうすると確かに、dhcpdのログにはリクエストの到着とレスポンス内容が記録されるが、そのレスポンスパケットが外に出ていっていない。jail内のdhcpdからlo0経由でホスト側に来たパケットをdhcrelayが見ていない感じである。dhcrelayに -i lo0 を指定するとエラーになるので、無理やりIFF_LOOPBACKをスキップしないようコードを修正してみたが、それもうまくいかなかった。

というわけで、dhcrelayを完全に別のホストに設置してみたところ、あっさりと双方向に中継されて、dhcpクライアントが動くようになった。つまり、同じホスト内でパケットを中継するということをdhcrelayが想定していないせいなので、うまくいじれば直せる問題だと思う。

とすると、他の実装では動く可能性があるということなので、試しに、net/dhcprelay と net/dhcprelya をホスト側で動かしてみたら、どちらも、*_ifaces に lo0 を追加指定するだけで、問題なく中継できてしまった。そこで最終的に、これらのうち、高負荷ルータ用と銘打っている dhcprelya を採用。

ちなみに、dhcpdには、ホスト側で起動してbpfを掴んだのちに、chrootやjailに入るというオプションもあるようだが、美しさというか整合性の都合で採用を見送った。

中継サーバがいらなくなるであろう、vimageの正式採用にとても期待。

追記（9/11）

dhcprelyaを動かしていたら、数秒に1回

wrong ether type -- packet ignore

と出ていた。わずらわしいだけだが、dhcprelayだと出ないようなので、こちらに採用変更。

javavmwrapperで特定のJavaVMを選択させる自分用メモ

わけあって手元のFreeBSDマシンに複数のJDKをインストールしたが、どのJavaVMを使うかどうやって指定すればいいか調べても、なかなかクリーンヒットしなかったのでメモ。javavmwrapperのスクリプトを読んではみたが、はじめは解読できなかった。

次のように環境変数を二つ指定することで、目的のJavaVMが選択できる。

JAVA_VENDOR=freebsd JAVA_VERSION=1.6 → java/diablo-jdk16
JAVA_VENDOR=freebsd JAVA_VERSION=1.5 → java/diablo-jdk15
JAVA_VENDOR=bsdjava JAVA_VERSION=1.6 → java/jdk16

JAVA_VENDOR にはblackdown, ibm, sunも指定しうる。空白をあけて複数指定すれば、適当なのが選ばれる。JDKとJREを同時に入れてたらどうなるかは不明。

JAVA_HOMEを指定しても選択できるが、openoffice.orgのビルド時に指定するなと言われる。ついでに、openoffice.orgのビルドでは、JAVA_VENDORなどを環境変数で指定しても上書きされるので、makeのオプションで指定する。

FreeBSD 6.3のSMPではOpenOffice.orgのビルドができない（もしくは不安定）

このところ、OOoのPORTREVISIONが上がったときの更新などでうまくportupgradeが終わらず、Ctrl-Cで止めてもidlcというよくわからないプロセスが残ってkill -9しないと死んでくれないなど、ビルドのトラブルが続いていた。かといって、まったくできないわけでもなく、何度か試してみると通ったりもする。規則性もよくわからなかったが、今回の更新で3-4回やってみても通らないので、何か報告がないか調べてみた。

すると、日本語ではパっとした情報はなかったが、freebsd-openofficeにidlc loops building openoffice.org-2 on FreeBSD 6.3-RELEASEとか、freebsd-smpにopenoffice build loops - seemingly only on SMP machinesとかいった投稿があり、SMPのスケジューリングがあやしそうな雰囲気。

そこで、/boot/loader.confに kern.smp.disabled="1" を加えて再起動し、ビルドしてみたら1回で通った。まさにSMPの問題らしい。OOoのビルド前後にいちいち再起動するのは面倒だなぁ。7.0とかULEとかで問題がなくなるのかどうかは、時間ができたら調べてみる。

ところで、ついでにccacheの効果を計ろうと、まずccache -Cしてからビルドしてみると、Core 2 Duo （当然Solo状態） E6600 で4時間半かかった。そして、そのまま2回目を行うと2時間10分ほど。ccacheそのもののオーバヘッドは測定できていないが、ほとんど半分にまで減っていることになる。PORTREVISIONがちょっと増えただけでビルドし直しというportsも多いわけで、今後はどのportsもccacheを使うようにしてみようかな。


追記 (8/26)

いろいろ試したので、まとめ。CPUはCore 2 Duo。スケジューラはデフォルト。
6.3/i386 + SMP → ×
6.3/i386 (UP) → ○
6.3/amd64 + SMP → ○
7.0/i386 + SMP → ○
7.0/amd64 + SMP → ○

ま、6系は6.4で最後らしいし、7に移行すればいいか。

FreeBSD 6.3でnvidia-driverがビルドできなくなってはまる

gettext祭りのついでに更新されてたnvidia-driverをビルドしようとして、warningしか出てないのに途中で止まっておかしいなとか思いながら、何かのはずみでpkg_deleteしてしまい、バカなことにそのことを忘れて再起動したものだから、Xが動かなくなってあせる。

ヘッダ内のプロトタイプが合わないせいでwarningが出るのに、CFLAGSに-Werrorがついてしまっているのが原因なのはすぐ判明。しかし、static inlineの定義を宣言に合わせて書き直すのは面倒なので、-Werrorを無効化したい。

-Werrorをつけてる箇所を探して、とりあえず/usr/share/mk/bsd.sys.mkにそれらしいのがあったので、応急で/etc/make.confにNO_WERROR=yesをつけてみたがダメ。

さらに調べると、/usr/src/sys/conf/kmod.mkでWERRORが定義されてなければWERROR=-WerrorにしてCFLAGSに加えている。これって、WERRORを無効化することを考えていないわけか？しかたないので、無害なところでWERROR=-Wallを定義してみたら、とりあえずビルドに成功。

次に、無条件には無効化したくないので、portconfを利用して、/usr/local/etc/ports.confに書いてみたが、portsのMakefileではなく、サブディレクトリにあるsrc/Makefileで有効にするには、ワイルドカードで指定しなければいけないようだ。

x11/nvidia-driver*: WERROR=-Wall

でしのぐ。

とかやっていたら、同じようなタイミングで、ports/124407が出ている。いずれちゃんと修正されるんだろう。-Werror無効化なんていうハックじゃなくて、warningが出ないようにしてくれればいいんだけど。

kochi-ttfonts更新でlinux-flashplugin7に漢字出ず

japanese/kochi-ttfontsが更新されたので、そのままportupgradeしたら、FirefoxのFlash Playerプラグインに漢字が出なくなった。例の/usr/local/lib/X11/fs/configはちゃんとハックしてあるし、どうしたことかと悩む。

ファイルアクセスの時刻を見てたら、Flashを動かすと、fonts.dirは読み込まれるのだが、kochi-gothic-subst.ttfが読まれた形跡がない。x11-fonts/cyberbit-ttfontsを入れてみると、こちらが表示されるが、字形が気に入らないので、これは避けたい。で、両者のfonts.dirに何か差があるのか眺めていたら、Cyberbitの方は、fonts.dirの左辺に書くファイル名にいっさい修飾がない。kochiの方はすべての行がTTCap拡張による修飾付きである。更新せずに放置しているFreeBSDの仮想環境と比べたら、そちらはkochiについても、修飾なしの行が含まれていた。

おそらく、libflashplayer.soはfonts.dirを自力で直接解析していて、TTCapの書式を理解せずに全体をファイル名とみなしてしまい、正しいファイルを開けなかったのだろう。なので、適当な行をfonts.dirに加えればうまくいくはず。ついでに、東風フォントじゃなくてIPAフォントにしてしまえるはず。というわけで、fonts.dirに以下の行を追加。

ipamp.ttf -kochi-mincho-dummy-dummy-dummy--0-0-0-0-p-0-dummy-0
ipagp.ttf -kochi-gothic-dummy-dummy-dummy--0-0-0-0-p-0-dummy-0

FoundryとFamilyしか見てないっぽいので、あとはダミーにしておいた。

以上で、Flash上でもIPAフォントがちゃんと表示されることを確認。これでja-kochi-ttfontsに依存するのは、ja-xpdfだけになった。こいつさえ修正できれば、kochiを消せる。いつかやろう。


追記（6/3）

ふたたびkochi-ttfontsが更新されて、fonts.dirをいじる必要がなくなった。というか、kochi-ttfontsを入れたり消したりすると、-kochi-の含まれる行がfonts.dirから勝手に削除されてしまうことがわかった。適当にディレクトリを作って、そこだけ見るようにfs/configをハックした方がいいのかもしれない。

ghostscript-gplで高速日本語表示

これまで機嫌よくghostscript-gnuを使っていたが、evinceを使ってみようとしたら、print/libspectreのビルドでWITH_GHOSTSCRIPT_GNUは設定するなと文句を言われ、しかたなくghostscript-gpl (8.62)に移行してみることにした。フォント設定はほっておいてもIPAフォントで日本語が表示されるようになっていたが、デフォルト設定では、以前のafpl版8.54と同じく、その日本語表示が非常に遅い。

オプションをよく見ると、FT_BRIDGEという設定が可能で、TrueTypeフォントのレンダリングにFreeTypeを使ってくれそうな気配である。うまくいけば、7.07くらいに高速に表示してくれるかもしれない。そこで、これを設定し、FAPIcidfmapをいじって、

/Ryumin-Light << /Path (/usr/local/share/ghostscript/fonts/Ryumin-Light.ttf) /CIDFontType 0 /FAPI /FreeType /CSI [(Japan1) 2] >> ;
/GothicBBB-Medium << /Path (/usr/local/share/ghostscript/fonts/GothicBBB-Medium.ttf) /CIDFontType 0 /FAPI /FreeType /CSI [(Japan1) 2] >> ;

としてみたが、日本語フォントを表示させるところでSegmentation faultを起こしてしまった。

gdbのバックトレースなんかで調べてみたところ、どうやら、FAPI_do_char()がcid_to_TT_charcode()を呼ぶところで、TT_cmapというパラメータをNULLにして渡しているのに、その中で呼ばれているTT_char_code_from_CID_no_subst()が何も考えずにarray_get()にTT_cmapを渡してしまっているのが原因っぽい。だからといって、array_get()を呼ばなくしてみると、日本語の文字がまったく表示されなくなって使いものにならない。いろいろ調べたところ、gsの古いcvsの記録から、最初にこのあたりのコードを加えたときにはTT_cmapがNULLの時の処理が含まれていたのに、あとからそのコードが消えていることがわかった。

なので、同じようにTT_cmapの判定コードを加えたところ、Segmentation faultを起こすこともなく、しかも以前よりちょっと遅いかな程度に高速に日本語を表示できるようになった。

ただ、どうも多量にWarningが出るので、まだどこか完全じゃないんだろう。


追記（5/29）

FreeTypeを使うと、縦書きが使えないことが判明。

デフォルトでは、article9.psみたいな縦書きPSファイルを表示させると、括弧とか句読点とかの約物に横書き用をそのまま使ってしまうという問題があるものの、まずまず見られる表示になる。しかし上の方式だと、縦のベースラインがぐちゃぐちゃになって（文字の左側を揃えている感じだけどそれでもおかしい）、しかも一部の文字が歯抜け状態になり、実用にならない。うまくいかないものだ。

東芝DynaBook SS S5のHDD換装

これまた長く使いまくっている私用のS5でも、かなり前から、R100の時と同じく、内蔵のMK2003GAHのキュルキュル音が出始めていた。交換そのものはどうということはないが、HDD上のリカバリ領域をうまくコピーするのに多大な労力が想像できて、躊躇していた。ところがついにCRCエラーが出始め、MK8007GAHに換装することを決意。

以前から、ノートPCの壊れたハードディスクを交換する(上)と(下)（浅田知広の温泉放牧中）やiPodのHDDをDynaBook SS に換装する（紅玉日記(2004-07-29)）により、S5でリカバリ領域を残してHDDを換装する方法が存在することは認識していたが、このためだけにTrue ImageやNorton Ghostを買うのもなんだかもったいないし、GPartedでなんとかやってみることにした。用意したのは、新しいHDDのほかに、100GBのUSB外付けドライブ、USBの純正CD-ROMドライブ、前に焼いたGParted LiveCD 0.3.4-11。

GPartedで起動して元のHDDを確認したところ、

/dev/hda1  ntfs  16.63GiB  boot
/dev/hda3  fat32  1.99GiB  hidden, lba

となっていた。そこで、とりあえずUSBドライブの後半を作業用に半分ほど空け、いろいろ試行錯誤する。以下はその抜粋。

まず、hda3だけUSBドライブの空き領域にコピー&ペーストし、HDDを交換して、新しいHDDの末尾に再度コピー&ペーストしてみたが、0を押して電源を入れても _ が出たままうんともすんとも言わなかった。

次に、hda1とhda3をそれぞれUSBドライブにコピー&ペーストして、それぞれ新しいHDDに同じサイズのままコピー&ペーストしたところ、Windowsは起動するが、0を押して電源を入れても無視してWindowsが起動してしまった。

次に、USBドライブの後半をext2でフォーマットして/dev/sda2をマウントしておき、hda全体をddでコピーしておいて（CRCエラーがあるのでconv=noerrorが必要）、新しいHDDにddで戻したところ、hda3のフォーマットがUnknownになってしまい（いったいなぜ？）、起動したところWindowsは起動途中でブルースクリーン、0押しリカバリはOSがみつからない風のメッセージが出た。（最初、このコピーをbzip2で圧縮して作成したが、bzcatが死ぬほど遅くて、圧縮などせずにddしてしまう方がはるかに速いことがわかった）

そして、MBRとかのパーティション外部のデータが重要そうだと気付き、最後にたどりついたのが、

1. USBドライブにext2パーティションを作りマウントしておく。
2. hda全体とhda3をddしてコピーをUSBドライブに保存しておく。
3. 新しいHDDに交換し、hda全体をddで戻す。
4. /dev/hda3をfat32でフォーマットし直す（たぶん不要。未検証）。
5. hda3をddで戻す。
6. パーティションエディタでhda3をHDD末尾に移動させ、hda1を後ろにいっぱいまで広げる。
7. 0を押して電源を入れ、リカバリ。
   

という手順。もっと簡便な手順もあるかもしれないが、とりあえずうまくいったので、手間をかけて探すのはやめる。力尽きた。

リカバリせずに元の環境を移したいなら、新しい方のhda1を一旦削除してGPartedの機能でコピー&ペーストした後、広げればいいのではないかと思う（けど当然未確認）。

ezjailで遊ぶための自分用メモ

jailを使ってサーバ群を構成し直そうと、ezjailで遊んでみた。グリーンITも簡単（か）。

1. FreeBSD 7.0 を入れる。/etc/rc.confでインタフェースのalias（例えば192.168.0.3としておく）を登録。
2. ホスト側のプロセスがjailのアドレスでlistenしないようにする。
   
• sshdのListenAddressをいじってアドレスを限定する。
• syslogdに-bをつけてアドレスを限定する。
• ntpdはそのまま。jailのアドレスでListenしても問題ない（はず）。
  
3. sysutils/ezjail を入れる。ezjail_enableを設定。
   
4. /usr/local/etc/ezjail.conf で、ezjail_jaildir をjail群用のでかいディスクに割り当てる（例えばTOPとしておく）。
• ちょっとしたWEBサーバやメールサーバなら1個あたり何百MBで十分。
5. ezjail-admin update -p
   
• ソースツリーをビルドし直し、portsnap fetchしてjail用のportsツリーもportsnap updateしてくれる。
• -Pならportsツリーのみ。jailが走っていても実行できる。
• -iをつけるとbuildworldせずにinstallworldのみ。
• 実行後はportsツリーも含めてTOP/basejailにインストールされる。basejailはjail内のbasejailにnullfsマウントされて、リンクされる。
• TOP/newjailもbasejailへのリンク+αとして作成される。これをコピーしてちょっとフレーバーを加えてjailになる。
6. フレーバーを作成。
• TOP/flavours/defaultを適当な名前（例えばwebとしておく）でコピー。
• web/etc/{master.passwd, resolv.conf, localtime, newsyslog.conf, ssh/sshd_config, ...} とか、web/root/.ssh/authorized_keyを用意しておく。
• web/etc/rc.confやらweb/usr/local/etc/sudoersやらを必要ならいじっておく。
  
• web/pkg/を作成し、pkg_addしてほしいパッケージを入れておく。
• create時に走らせたいスクリプトがあればweb/ezjail.flavourをいじる。（デフォルトの処理内容はpkgがあればその中をインストールすることだけ）
  
7. ezjail-admin create -i -s 1g -c eli -f web -r hoge hoge.example.com 192.168.0.3
   
• TOP/hoge.example.comだと長すぎてdfが見づらいのでrootを短い名前で設定。
  
• しばらく待ってgeliのパスフレーズを入力。暗号化しないなら-i -s 1g -c eliとかいらない。
• ntpdが*：123で待ってると文句を言われるが、たぶん影響ないので無視。
8. jailが動いてないときにjailのイメージをいじりたいときは、ezjail-admin config -i attach hoge.examle.comでできるが、attachがへたくそでdetachできないバグがある。すぐ直せる。
9. /usr/local/etc/rc.d/ezjail.sh start hoge.example.com か startcrypto で、パスフレーズを入力するとjail開始。
10. sshが設定できてるならそのままsshするとか、jlsして目的のJIDにjexec JID /bin/shするとか、あとは好きなように。
    

• 電源が落ちたりして正常に終了できなかったときは、startcryptoする前に ezjail-admin config -i fsck hoge.example.com するべきかも。
  

ezjailは関係ないけど、当面気になるjailの制約まとめ:

• domainnameが設定できない。ただし、ホストのdomainnameを参照することはできるので、同一ドメインでならjailでNIS（rpcbind, ypbind）を使うことは可能。ypservは不明。hostnameはjailごとにあるのに、NISなんてレガシーな技術はあんまりサポートしないという方向性か。
• マウントができないのでNFSクライアントは無理。NFSサーバは試す気なし。
• BPFがない。でも、net/isc-dhcp3-serverはsocket（）あたりを使って動かせるっぽい。
• localhostにbindできないので、setgidなsendmailを叩いてlocalhostで待ってるMTA（msp）を経由してメールを出すことができない。外部の指定したMTAに直接つなぎに行くか、rootにsetuidする必要がある。/etc/mail/README参照。

ともかく、
Happy jail life!

FreeBSDでISOイメージを焼く自分用メモ

ひさびさにFreeBSDでISOイメージを焼こうとしてすっかり忘れていたのでメモ。使わないと、オプションどころかコマンド名まですべて忘れて、manさえできない。

ATAPIのCD-R/RWドライブ（/dev/acd0）で焼くにはburncdを使う。

% burncd -f /dev/acd0 -s max data file.iso fixate

速いドライブなら600MBでも3分ほどで終わる。


追記 (8/26)

手元のPCを7.0に上げたあと、CD-Rを読み書きしようとすると、

acd0: TIMEOUT - READ_BIG retrying (1 retry left)

のようなエラーが出て、実用的な時間で終わらなくなってしまった。

ハードウェアが悪いのか7.0が対応していないのかよくわからなかったが、/boot/loader.conf に hw.ata.atapi_dma="0" を追加。7.0をCD-ROMからインストールする場合も同じように刺さるので、起動時のオプションでLoader Promptを出して、

set hw.ata.atapi_dma=0
boot

とする必要がある。

XfceとThunarでちゃんとアイコンを出すにはlibrsvg2が必要

普段のPCではXfceがなかなか快適になったが、VMware Player用のFreeBSDでXfce4を入れて動かすと、アイコンが全然かっこよくならない。メニューの設定から、インタフェースを選んで、アイコンテーマをGnomeにするとデスクトップはたしかに変わるが、Thunarのメインのペインが変わらなかったり、挙動がよくわからない。

で、しかたがないので、xfdesktopのソースにデバッグプリントを入れてみると、xfdesktop_file_utils_get_file_icon（）でxfce_themed_icon_load（）が失敗してxfdesktop_file_utils_get_fallback_icon（）を呼び、/usr/local/share/pixmaps/xfdesktop/xfdesktop-fallback-icon.pngを表示している雰囲気。

そこから、
→gtk_icon_theme_load_icon()
→gtk_icon_info_load_icon()
→icon_info_ensure_scale_and_pixbuf()
→load_svg_at_size()
→gdk_pixbuf_loader_new_with_type()
→gdk_pixbuf_loader_load_module()
→_gdk_pixbuf_get_named_module()
→_gdk_pixbuf_load_module()
→_gdk_pixbuf_load_module_unlocked()
と大追跡を行って、最後に g_module_error() が "Cannot open "/usr/local/lib/gtk-2.0/2.10.0/loaders/svg_loader.so" と出力しているのをつきとめた（たぶんもっと上のレベルでエラーメッセージを探した方が早かったかも）。

このファイルは、graphics/librsvg2 によってインストールされるもので、gimp がこれに依存しているせいで、PCの方にはちゃんと入っていたようである。xfce4-desktopとthunarもこれに依存するようになってないといけなかったわけである。

というわけで、解決。


追記（2/21）

事態はそう単純ではなくて、本当の問題はもっと深いところにあった。

最初からxfceしか入れていないマシンを作ったところ、librsvg2なんか入っていなくてもちゃんとアイコンが表示された。そのマシンで追跡したところ、gtk_icon_info_load_icon（） にはSVGではなくPNGファイルが指定されて呼ばれている。では、そもそもなんで呼ぶ側の gtk_icon_theme_load_icon() がSVGを指定したりPNGを指定したりするかが問題で、これを追いかけていたら /usr/local/etc/gtk-2.0/gdk-pixbuf.loaders というファイルに行きあたった。これに image/svg を開くためのモジュール /usr/local/lib/gtk-2.0/2.10.0/loaders/svg_loader.so が登録されているかどうかを調べて、あればアイコンの拡張子を svg に決めるらしい。ではこのファイルは誰が用意するのかというと、gtk20をインストールするときにモジュールの有無を調べて、svg_loader.soがあればそれを登録するようになっているっぽい。

つまり、たまたまXfceとかThunarとかのアプリケーションがひっかかっただけで、gtk20とlibrsvg2の関係に問題があった。しかし、gtk20がlibrsvg2に依存すればいいかというとそうではなくて、もともと逆向きの依存があるので、循環させるわけにいかない。librsvg2のインストール・アンインストール時にgdk-pixbuf.loadersの中身をいじるようなしかけを作るくらいしかないのかもしれない。この場合、将来別のフォーマットのモジュールが出てきたら、同じしかけを追加していくことになる。

で、話はそれだけではなくて、同じようにgtk20がインストール時に探して登録してしまうものに、IM関連がある。/usr/local/etc/gtk-2.0/gtk.immodules がそれで、SCIMのモジュールがあればここに追加されるようである。依存関係についてはlibrsvg2の場合とまったく同じことになっていて、本来は同じような対処をちゃんとやっておく必要がある。


追記（2/22）

と思ったら、librsvg2もscimも、インストール・アンインストール時にgdk-pixbuf-query-loadersとgtk-query-immodules-2.0を動かすことになっていて、ちゃんとpkg_deleteすればgdk-pixbuf.loadersが更新されている。

問題は、librsvg2をインストールした状態でgtk20のパッケージを作り、それだけを別のマシンにインストールしたことだった。gtk20のインストール時にも走らせればいいのかも。

FreeBSD 6.3でもFreeSBIEはNO_UNIONFS=YESが必要

FreeSBIEにはmfs+unionfsを使うことで/usrなどへの書込みも可能にするような機構が組み込まれているが、unionfsの不完全さから、デフォルトではNO_UNIONFS=YESとなっている。

これを解消することなどを目的に、FreeBSD unionfsの改善提案および修正状況として、unionfsの再実装と6.3へのバックポートも行われたらしいので、もしかして使えるんじゃないかと、NO_UNIONFSを消してみた。結果はあと一歩というところ。

/tmpのパーミッションや、/tmpや/varとのマウント順序、dhclientの実行時期などに問題があったので、conf/rc.d/unionfsを調整すると、これらはすぐに解決し、ベースのシステムは問題なく起動するまでになった。しかし、Xのデスクトップ環境を作ろうとしてみると、いろいろなアプリケーションがうまく起動できない状態になっていた。

相当な時間をかけていろいろいじって調べたところ、unionfs上でUNIXドメインのソケットにうまくconnectできていない（Connection refused）ことがわかった。kern/118346にも報告があった。

というわけで、unionfsの利用は、当面おあずけ。

この過程で、zshにはzmodloadというモジュールロード機能があって、zsh/net/socketというモジュールをロードすると、zsocketというコマンドが使えるようになり、zshだけでUNIXドメインソケットを張ることができることを発見。たしかに今回みたいなちょこっとテストには便利だけど、これだけの機能を日常的に使う人いるのか？

FreeSBIEでNO_COMPRESSEDFS=YESにするとsuid/sgidができない

VMwareの仮想ディスクイメージを複数ユーザで共有したかったが、read onlyなvmdkはどうも作れなさそうである。そこで、read onlyなLiveCDイメージを作り、これを共有することにした。

最初、sysutils/livecdを試してみたが、これはFreeBSD 4以前が前提っぽく断念。もう消してもいいんじゃないか？次に、sysutils/freesbieを試すと、こちらは設定もわかりやすく、素直にisoイメージを作ることができる。

FreeSBIEは、デフォルトではgeom_uzipを使って/usrを圧縮し、isoのサイズを小さくしている。しかし、速度を測ってみると、やはりNO_COMPRESSEDFS=YESにして圧縮をしない方が速いようで、起動時間が1割くらい短縮される。イメージを実際にCDやDVDに焼くわけではないので、サイズは重要ではなく、速い方を採用しようと考えた。

しかし、起動してしばらく使ってみると、sendmailが文句を言うようになり、よく調べてみると、/usr以下の各バイナリのsuid/sgidビットがすべて落ちてしまっていることがわかった。これは、iso9660のファイルシステムにそのような属性がないためで、当然の結果である。geom_uzipを使った場合は、ufsの圧縮イメージをマウントするので素のFreeSBIEでは大丈夫だったわけだ。/sbinにあるsuidバイナリはどうしているのか見てみると、/usr/sbinに移動してリンクされていた。conf/freesbie.confファイルでEXTRAにsuidを加えておくと、このリンクが作成される。

というわけで、現状では、ちゃんと動くLiveCDを作ろうとすると、NO_COMPRESSEDFSは利用できないことになる。圧縮なしのufsのイメージを置いて、それをマウントするようにすれば、このsuid/sgidの問題は解決するかと思う。いつかやろう。


追記（1/31）

やってみた。結論からいうと、効果がなかった。

scripts/clonefs.shでusr.uzipを作っているが、その前段階でusr.ufsというまさに欲しいものを作っていた。これを適当な名前で残すようにし、conf/rc.d/uzipと同じようなものも作って、NO_COMPRESSEDFS=YESでisoを作り、起動してみた。当然ながらsuidは確かに効いている。しかし、速度はuzip版より数%前後遅い感じになってしまった。

これは、ファイルシステムが二重になっているのが原因なのだろうか？uzipを伸長する時間よりも圧縮されていないデータを物理的に入出力する時間の方が効くということか。HDDが遅いマシンだからなおさらだろう。

なので、今後は圧縮版のみ採用。

ブログのレイアウトを微調整

アクセス解析で検索キーワードなどをながめていると、右のアーカイブ欄の記事タイトルやラベルにヒットしてしまうせいで、もっとジャストフィットする記事があるのにとか、そのキーワード群に該当するような記事は書いてないとか、無駄骨を折らせてしまっている例が散見される。

なので、ブログのアーカイブの欄から、ブログタイトルはすべて削除。ラベル一覧の欄も完全削除。むりやりGoogleにひっかけさせて期待しないページビューが増えても意味なし。

万一、全部読みたいなどという酔狂な方がいらっしゃっいましたら、アーカイブから年ごとあるいは月ごとに全部表示してください。

xfceで一般ユーザにシャットダウンをさせるための自分用メモ

そろそろモダンなウィンドウマネージャを本格的に使おうかと、xfceを試してみる。

Terminalの動いているワークスペースにページャーやキーで移るのに何かワンテンポ遅れる感じがする。ktermやxtermだと何ともないのに。

最近のウィンドウマネージャには、ユーザがPCのシャットダウンや再起動ができるようなメニュー項目があったりするが、どうも選択できなかったので調べてみると、sudoの設定が必要なようだ。xfceの場合、/usr/local/libexec/xfsm-shutdown-helper がsudoできなければならない。sudoersに

%mygroup ALL = NOPASSWD: /usr/local/libexec/xfsm-shutdown-helper

を追加。

参考サイトでは NOPASSWD: の : が抜けていたので、フィードバックしておく。

追記（2009/3/24）

最近、Xを7.4に上げ、haldを動かし、xfceも4.6に上げたあたりで、「再起動」や「電源を切る」を選択すると、

シャットダウンの実行ができません
org.freedesktop.hal.power-management.reboot no <--
(action, result)

のような表示が出て、ログアウトするしかできなくなっていた。

xfce4-sessionのコードを読むと、halが動いているときはそっちを使うっぽい。なので、/usr/local/etc/PolicyKit/PolicyKit.confに、

<match action="org.freedesktop.hal.power-management.*">
    <return result="yes"/>
</match>

というコードを挿入して解決。

この場合は、sudoもなくてもOK。

moodleを1.8.4に更新

moodleのセキュリティアラートが来て、loginas機能に権限昇格の脆弱性があるとのこと。
とりあえず1.8.4+に更新。ついでにNWikiを2.0 20080114版にアップグレード。

特に問題なく完了。

RealTekのデバイスはFreeBSD 6.3(RC2)なら問題なし

ちょうど去年の今ごろ導入したPC （FreeBSD 6.2）で、pkg_info -g が一部のパッケージで

pkg_info: (null)/libdata/ldconfig/gcc42 doesn't exist

みたいな変なエラーを出すようになり、+CONTENTSの@cwdしかない行の後がちゃんと読めてなさそうな雰囲気があったので、ここらで潮時と6.3（ただしRC2）を入れてみた。

ビルドとインストールは特に問題なく完了した。6.2ではモジュールを入れ直さないとALC883が動かなかったが、6.3ではsnd_hdaがサポートされるということで大丈夫だろうと期待。RTL8110SCももしかすると動くようになるかもと淡い期待をいだきながら再起動。

音は出た。問題なし。

そしてイーサネットの負荷試験をしてみたところ、これまでのところ問題なさそうで、

re0: watchdog timeout

は一度も出ない。

pkg_info -g もエラーなし。

めでたし。

DynaBook SS 3480でのGParted LiveCDの利用

使わずに何年もほったらかしておいたDynaBook SS 3480でちょっと遊ぼうと、起動してみたら、起動しなくなっていた。

HDDも酷使しつくした20GBのMK2016GAPだったし、ここらできっちり復活させようと、まずはHDDを120GBのMK1234GAXに換装。裏のネジをはずして、パームレストをはずして、ケーブルを慎重にはずすと、HDDには簡単にアクセスできた。34xx系列では80GBまでとかいう情報もあったが、問題なく認識して、リカバリもPC Cardタイプの純正CD-ROMドライブであっさりできた。

と思ったら、リカバリ後のWindows 2000が途中までしか起動しない。そのポイントも一定でない。メモリが怪しい雰囲気だったが、本体側64MBと増設128Mがあり、本体側だと絶望的だと思いながら増設RAMをはずしてみると、幸運にも問題なく起動することがわかった。

増設RAMはBuffaloのMS100-A128Mというもので、既に廃番。後継品のMS133-A128Mも販売終了。で、よくよく保証期間を見ると6年もあることがわかり、購入時期を逆算するともう過ぎているだろうななど考えつつ保証書を探すと、期限切れまであと2週間ほどということが判明。非常に幸運なことに、無償交換となった。

次の問題は、時計がまったく合わなくなったこと。時計用のバッテリーが死んでしまったためと考えられるので、チチブデンキあたりで買うしかないだろう。ちょっと遊ぶだけの目的には致命的な問題ではないので、とりあえず後回し。いつかやろう。

最後の問題は、リカバリCDが勝手に切るパーティションがCドライブ4GBだけであること。パーティションを分ける理由が特にないのと、Cが4GBではあまりにも使い勝手がよくないので、パーティションをまとめることにする。このためのツールとしては、GPartedが有名だったので、今後の練習も兼ねてLiveCDを使ってみることにした。最新の0.3.4-11のLiveCDを焼き、例の純正ドライブで起動してみると、

!!Invalid loop location: /gparted.dat

と言われて、起動しない。探すとGPartedのフォーラムでこの問題が出ていて、そこのアドバイスに従ってみると、どうやらPC CardのCD-ROMデバイスが起動したLinuxに見えていないという問題らしい。かといって、SS 3480はUSBのデバイスからは起動しないのでちょっと悩んだが、デバイスを認識してマウントする段階でLiveCDをUSBのCD-ROMドライブに入れ直せばいいと考えた。が、そのタイミングを計るのも面倒なので、もう1枚同じLiveCDを作ってしまうことにした。PCの左右にドライブを二つ並べてそれらのLiveCDを入れ、ようやく起動に成功。

GParted自体は、日本語モードにするとGUIの漢字が全部化けるので、英語モードを選ばないと何も操作できない。しかしGUIは使いやすく、ドキュメントなどは見ずにすぐにGUIでパーティションを変更できた。Windowsを再起動するとCHKDSKが走り始めて少しあせったが、ほどなく終了して起動し、目的を達成できた。