webcomponentsjs (WebComponents v1 polyfills) についての備忘録
とてつもなく久々の投稿ですが、ここのところ人柱コード書いていてところどころハマリポイントが見つかったりしているので、悩める人々の光になる可能性が0.0001%でもあればと思いメモ。
HTML5で好きなタグ名でカスタム要素を定義できる、CustomElementsで遊んでいます。
ShadowDOMなどと組み合わされるので、実装の瑣末なものを隠蔽したりして、よりセマンティックなウェブページを構成できます。
loaderをカスタムしたりしています
GitHub - misttechnologies/webcomponentsjs: A suite of polyfills supporting the HTML Web Components specs
以下、ハマったポイント
1. ShadyDOM / ShadyCSSを使う場合は`ShadyCSS.prepareTemplate()`メソッドでtemplateをゴニョゴニョしてあげないといけない
IEとFirefoxに該当。
nativeのshadowDOM tree内のcssセレクタをエミュレートするために、cssスコーピングのためのクラスをshadowRootノードに, :hostセレクタなどをhostのタグ名に変換する必要がある.
if (ShadyCSS) { ShadyCSS.prepareTemplate(template, "hoge-element"); }
てなノリで。
2. あるCustomElementのShadowDOMの中で別のCustomElementを使う場合(IE たぶん11以下 限定)
外側クラスを先に`customElements.define()`してupgradeElementさせ、そのあとに内側クラスを`customElements.define()`してupgradeElementさせないといけない。
少なくともIE11で、これに気づかないと動かない。他のChrome, Firefoxなどのモダンな奴らは大丈夫。
これは、内側で使われているCustomElementの定義を先にした上で、外側のShadowDOMをtemplateを使って構築しようとすると、template内のdocumentFragmentがぶっ壊れるから。外側templateのDOMパース中に不意に内側customElementがupgradeされることが想定されていないらしい。
3. あと、polyfillのロード完了タイミング制御が割と難しい。
WebComponentsReadyなるCustomEventも飛んでくるが、あんまりアテにならない。
OpenBlocks AX3にVyatta 6.4をインストールする
OpenBlocksはARMプロセッサを使っており, 一般的なi386, x86_64アーキテクチャ用のビルドだとそのまま使うことはできません. そこでarmelアーキテクチャ用に自分でビルドし直す必要性があります.
そこで, OBDNマガジン: OpenBlocks AX3でVyattaを動かす(ビルド編)を見ながらvyatta入りkernelをビルドしようとしたのですが, kernelに当てるunionfs.diffがリンク切れになってたりと、結局ビルドできませんでした。
よーく探すと Vyatta CORE for OpenBlocks AX3 にビルド済みのisoが置いてあったので結局これを使うことに. OBDNマガジン: OpenBlocks AX3でVyattaを動かす(起動編) を参考にしながらこのisoを使ってOpenBlocksにVyattaを導入することに成功しました.
具体的には, ODBNマガジンの起動編「 ◆OpenBlocks AX3でVyattaをlive起動」以降の手順を踏めば良いはずです.
PFでNAT64 - OpenBSD 5.1
NAT64とは、DNS64と組み合わせることにより、IPv6 onlyネットワークからもIPv4のサービスにアクセスできるようにする機能のこと。これをサーバ上で実現する方法としては、
がある。今回はPF (OpenBSD 5.1)を使った。
以下、上記それぞれについて少々。
linuxnat64
linuxnat64はちょっと前までsourceforgeから利用可能だったみたいですが、今はなくなってしまいました。探してみたところ、簡単には見つからないみたいです。私は、知り合いからソースコードを貰いました。少なくとも、Ubuntu 10.04.3 x64では動くみたいです。
Ecdysis (linux)
Ecdysis: open-source nat64から利用可能です。ただ、ネット上や知人からの情報だと、linuxではうまく動かない(tcp seqがずれたり、chksumがおかしかったりpayloadが壊れたり)という噂を聴いたので不安になりました。
実際にインストールしてみたところだと、はじめはping6は通るけど、wgetが時々失敗するという現象に遭遇しました。しばらくすると安定して動き始めたのですが、不具合の原因はいまいちわかっていません。うまく動くこともあるようです。
Ecdysis (pf patch for OpenBSD 4.6)
すでにkernel patch済なisoがEcdysis: open-source nat64の最下にあります。これは導入しやすそうな気がしますが、試していません。
Tayga
これはstatelessなNAT64で、今回の要件にマッチしていないので使いませんでした。stateless NATというのは、変換前のIPアドレスと変換後のIPアドレスが1対1対応するとかなんだかそういう感じだったと思います。
NAT64の設定
OpenBSD 5.1のセットアップ
インストーラisoはOpenBSD: Mirrorsから辿ると落とせます。私は、http://ftp.jaist.ac.jp/pub/OpenBSD/5.1/amd64/のinstall51.isoを使いました。
OpenBSD FAQ: Installation Guideこのへんでも見るといいです。インストーラの指示に従うだけですが、Ubuntuしかインストールしたことない人にとってはちょっと難しいかもしれません。
この辺はもしかすると少しはわかりやすいかもしれない。OpenBSDのインストール方法詳細メモ(1) - 情報科学屋さんを目指す人のメモ(FC2ブログ版)
NICの設定
用意すべきは
です。これらが確保できたら、 /etc/hostname.
# vi /etc/hostname.em0
inet 192.0.43.10 255.255.240.0 inet6 2001:500:88:200::10 64 !route add -net default 192.0.43.1 !route add -inet6 default 2001:500:88:200::1
192.0.43.10はNAT64をするマシンのIPv4アドレス
2001:500:88:200::10はそのIPv6アドレス
192.0.43.1はNAT64マシンがいるセグメントのdefault gateway
2001:500:88:200::1もdefault gateway
意味を考えて、適宜自分の環境にあわせて読み替えてください。
/etc/hostname.
# /etc/netstart
で設定を反映。
pfの設定
デフォルトでは/etc/pf.confが設定ファイルです。
# vi /etc/pf.conf
これに以下のような行を追加してください。
# nat64 pass in quick inet6 to 2001:500:88:200::10 pass in quick inet to 192.0.43.10 pass in inet af-to inet6 from 2001:500:88:200::10 to 2001:500:88:ff64::/96 pass in inet af-to inet6 from 2001:500:88:200::10 pass in inet6 af-to inet from 192.0.43.10 to 0.0.0.0/0 pass in inet6 af-to inet from 192.0.43.10
ただし、これをやると他のインターフェースにも影響を与えるかもしれないので、
set skip on em1
でルール適用除外したり、af-toルールの適用条件に on em0 加えるなどして調整してください。
各行の意味は、
- 64変換すべきではない、自分(NAT64マシン)宛のパケットは自分の方に受理してあとの64変換ルールを適用しない
- 同上
- 2001:500:88:200::10に設定されたインターフェースに2001:500:88:ff64::/96宛のパケットが届いたら、宛先アドレスの下位32ビットからIPv4アドレスを取り出し、そのIPv4アドレス宛てのパケットへと変換する(NAT64の動作)
- ようわからん
- 192.0.43.10に設定されたインターフェースに届いたパケットの送信元IPv4アドレスを2001:500:88:ff64::の下位32ビットに埋め込み、IPv6パケットにに変換する(NAT64の動作)。
- ようわからん。
ちなみに、2001:500:88:ff64::/96はNAT64の変換用プレフィックス
こんな感じで動いています。af-toっていうのが肝心ですね。私にはよくわかっていない部分もあります。
気になる人は、OpenBSD manual pagesでも見てください。
2013/02/24 追記
現在検証したところ, pf.confはもっとシンプルに書けるようです。
# vi /etc/hostname.em0
inet6 2001:0DB8:100::2 64
# vi /etc/hostname.em1
inet 192.0.2.2 255.255.255.240
# vi /etc/pf.conf
pass in quick inet to 192.0.2.2 pass in quick inet6 to 2001:0DB8:100::2 pass in inet6 from any to 2001:0DB8:64::/96 af-to inet from 192.0.2.64/28 to 0.0.0.0/0
この例では, nat64マシンの
- 実IPv4アドレスが192.0.2.2/28
- 実IPv6アドレスが2001:0DB8:100::2/64
- nat64変換先IPv4アドレスプールが192.0.2.64/28
- nat64変換元IPv6プレフィックスが2001:0DB8:64::/96
という条件下でnat64トランスレーションを行なっています。
/etc/pf.confの各行の意味は,
- 実IPv4アドレス宛のパケットには変換ルールを適用せずにnat64マシンが受け取る
- 実IPv6アドレス宛のパケットには変換ルールを適用せずにnat64マシンが受け取る
- 送信元IPv6アドレスが任意で, 送信先IPv6アドレスが2001:0DB8:64::/96 (変換元プレフィックス) のIPv6パケットは, 宛先IPv6アドレスの下位32bitに埋め込まれた本来の(designated)宛先IPv4アドレスを取り出し, 宛先IPv4アドレスを抽出したIPv4アドレスに, 送信元アドレスを192.0.2.16/28 (変換先アドレスプール)のいずれかのアドレスに変換して転送する
と言ったところです。pfのnat64はステートフルなので, inet6 (IPv6) -> inet (IPv4)の変換ルールを書いておけば, NATテーブルを参照することで戻り(inet -> inet6)の変換も行えることから, 特にinet -> inet6の変換ルールを明記する必要性はありません。
あとはルーターには2001:0DB8:64::/96のnext-hopを2001:0DB8:100::2とする経路を書いておけば, nat64が使えるはずです。
追記ここまで
設定が書けたら、
# pfctl -Fa -f /etc/pf.conf
でルール適用。基本的にはこれで完成です。
実際にこのNAT64を使うためには、
- DNS64を建て
- DHCPv6にDNS64の設定を入れ
- ルーターで2001:500:88:ff64::/96プレフィックスのNext hopをNAT64機(2001:500:88:200::10)へ向ける
といったことが必要になるはずですね。他にも必要な作業が抜けているかもしれないですけど、気づいた方はご指摘ください。
ここ最近便利だと思ったもの
Visitors
まぁ、Google Analyticsとかでもアクセス解析はできるんですけど、ローカルでちょちょっと解析したい時に。
Ubuntuなら
sudo aptitude install visitors
でインストールできて、
visitors -A -m 30 access.log -o html > report.html
で生成したファイルをブラウザに放り込むだけ。1時間あたりのアクセスとかがさくっと出せていいです。
ここに書いてありました。
iPhoneのホームボタンが効かなくなったときに...
- 電源ボタンを長押しして、電源を切るスライドを表示させる
- ホームボタンを「いつもの強さで」長押しし続ける
- スライドが消えたら、完了
恐らく、この2の操作でホームボタン押下の強度キャリブレーションを行っているようです。
ここに書いてありました
openx - 広告配信システム
これをサーバーにインストールすると、広告配信ができます。なんかちょっと複雑なので説明するのはめんどくさい。
ここに書いてありました
他にもいろいろ便利だと思ったものはありますが、またの機会に。
ネットワーク性能監視ツールを作ってみるか
昨日から寮内でのInternetブラウジングがちょっと遅いらしい。
原因はまだ分かっていないが、とりあえず定量的にネットワークの各種性能を計測して可視化するツールは必要だろうという。
そこで、何かあるならそういうツールをインストールするか、無ければツールを自分で作ろうと思う。
必要な監視項目は
・turn around time
・bandwidth
・dns lookup time
寮内(同セグ)を含む、いくつかのリモートホストに対して、上記項目を計測し、グラフ化することが要件だろうと思う。
で、たまにチェックして極端に数値が落ちていれば、更に細かい調査をしてパフォーマンス改善をしようと思う。作ったらまた書きます。
もしや、Xymonとかでできるかな?