最近の5件分。
どうも原因不明らしい。Debian Lenny 5.0.5 amd64で再現した。同じDellマシンでBroadcomのNICを積んでるのでハードウェアかドライバが怪しい気がするが詳細は不明。
なお、完全仮想化（HVM）だと問題が起こるのだが、準仮想化だと問題無いようである。
最終的には面倒になって投げ出したのだが、何かの役に立つかもしれないのでメモしておく
OpenVPN2.xでtapデバイスをブリッジして使う場合、仮想的にL2でVPN先に接続されていることになる。そのため原理的には、DHCPも接続先のネットワークにすでに存在するネイティブなDHCPサーバを利用できるのであるが、実際のところ面倒な問題がついて回る。そのためOpenVPNの標準はOpenVPN自体がDHCP的な機能を提供し、VPN経由で接続するクライアントには独自にIPを払い出している。今回はサーバ側にLinux（Centos5.5）、クライアント側にMacOS10.5のTunnelblickを利用した環境での手順となる。ネイティブDHCPを利用する場合、クライアントの環境が比較的重要になるのでほかの環境では異なる結果になる可能性がある。
まず、ネイティブDHCPを利用するために、OpenVPNサーバのDHCP機能をオフにする必要がある。bridge-server構文を利用している場合はコメントアウトし、以下の行を付け足す。
mode server
tls-server次に、念のためdhcpdをリスタートする。OpenVPNがbr0を作る前にdhcpdがスタートしてる場合、dhcpdがbr0でListenしないことがある。dhcpd側であらかじめ設定してあれば必要ないかもしれない。
クライアント側の設定ファイルは特に変更する必要がない。ただし、Mac OSXのTunnelblickをクライアントとして利用している場合、tapデバイスのDHCPが自動で有効にならないためTunnelblickの起動スクリプトに細工をする必要がある。以下のIssueが詳しい。
具体的には、/Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.shの先頭らへんに次の1行を追加する。
/usr/sbin/ipconfig set tap0 DHCPこれで自動的にDHCPが有効になり、ネイティブDHCPサーバからIPを取ってこれるようになる。down側のスクリプトにもipconfig top0 NONEを足した方がいいのかもしれないが、どうせすぐDevice自体が削除されるので必要性は薄いと思われる。
さて、単にVPNに接続するのであればこれで問題なくネイティブDHCPが利用できるのだが、パケットを全てVPN経由に流すためにredirect-gatewayを設定すると問題が発生する。
通常、クライアント側の設定ファイルにredirect-gateway def1と書いておけばOpenVPNが自動でルーティングテーブルを調整してくれるのだが、ネイティブDHCPを併用した場合、DHCPクライアントがさらにルーティングテーブルを上書きしてしまい、ルーティングが壊れてしまう。このため、何らかの手段でDHCPクライアントによるルーティングテーブルの編集を阻止しなければならない。私はこの時点で面倒になったので（そこまでしてネイティブDHCPを使わなければいけない理由もない）、諦めてしまった。
というわけで、redirect-gatewayを用いずに単にVPNに接続したいのであれば、ネイティブDHCPを利用するのは難しくない。しかし、デフォルトゲートウェイをリダイレクトしたい場合は、何かしらの手段でルーティングテーブルを上手く調整する必要があるため注意が必要である。
KeyRemap4MacBookにEmacsぽい操作をいくつか追加。
Terminal.appがC-/とC-'に対応してくれないので、Emacs側で適当に設定してそのキーを送るようにした。
<item>
<name>Option+W to Command+C</name>
<sysctl>option.emacsmode_OptionWCopy</sysctl>
<not>EMACS, TERMINAL, VIRTUALMACHINE, REMOTEDESKTOPCONNECTION, X11, ECLIPSE</not>
<autogen>--KeyToKey-- KeyCode::W, VK_OPTION, KeyCode::C, ModifierFlag::COMMAND_L</autogen>
</item>
<item>
<name>Control+/ to Command_Z</name>
<sysctl>option.emacsmode_controlSlash</sysctl>
<not>EMACS, TERMINAL, VIRTUALMACHINE, REMOTEDESKTOPCONNECTION, X11, ECLIPSE</not>
<autogen>--KeyToKey-- KeyCode::SLASH, VK_CONTROL, KeyCode::Z, ModifierFlag::COMMAND_L</autogen>
</item>
<item>
<name>Control+S to Command+F</name>
<sysctl>option.emacsmode_controlS</sysctl>
<not>EMACS, TERMINAL, VIRTUALMACHINE, REMOTEDESKTOPCONNECTION, X11, ECLIPSE</not>
<autogen>--KeyToKey-- KeyCode::S, VK_CONTROL, KeyCode::F, ModifierFlag::COMMAND_L</autogen>
</item>
<item>
<name>[Terminal] Control+/ to C-_ and Control+' to C-M-_</name>
<sysctl>option.emacsmode_controlSlashTerminal</sysctl>
<only>TERMINAL</only>
<autogen>--KeyToKey-- KeyCode::SLASH, VK_CONTROL, KeyCode::MINUS, ModifierFlag::CONTROL_L | ModifierFlag::SHIFT_L</autogen>
<autogen>--KeyToKey-- KeyCode::QUOTE, VK_CONTROL, KeyCode::MINUS, ModifierFlag::CONTROL_L | ModifierFlag::SHIFT_L | ModifierFlag::OPTION_L</autogen>
</item>
原因は不明だが、特定の環境でnsupdateがクラッシュする現象があるらしい。手元のCentOS5.5 （x86_64）だと、nsupdateでsendなどを行った際にmem.cに起因するエラーでプロセスがクラッシュする。
エラーメッセージは実際には以下の通りである。
mem.c:877: insist(ctx->stats[i].gets == 0u) failed.調べた範囲ではこれといった対応策はないようだ。報告自体があまり上がっていないようなので、特定の環境でしか起こらない問題なのかもしれない。nsupdateはdns-utilsとして提供されているが、再インストールなどでは解決しなかった。
現状では、bindの公式サイトから最新版のソースコードをダウンロードしてきて、自前でコンパイルするのが手っ取り早い解決策となる。コンパイル自体は./configureとmakeだけで済む。
data スキームは相対参照を認めていない。
これは間違っている。data: schemeを持つURIにおいてもFragmen IDは有効であると考えるのが正しい。Mike SmithがJulian Reschkenにも確認してくれたようなので間違いないと思われる。
RFC 3986の3.5. Fragmentには以下のように書かれている。
Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications.
つまり、スキームが何であろうと、基本的にFragment IDは利用可能でなければならない。
なお、少なくとも現時点では、W3CのHTML5バリデータ（Validator.nu）の動作が必ずしも正しいとは限らないので過信しないようにしていただきたい。何かおかしいと思ったときは、開発者に報告していただけると幸いである。#whatwgか#html-wgあたりで質問すると話が早いかもしれない。今回はたまたま目に入ったのでバグとして処理することができたが、開発者が気がつかないとせっかくテストしていただいた内容が無駄になってしまうかもしれない。