本 日 の h o g e

■ デス

最近メロデスが熱い。昔はデスメタルなんて嫌いだったのになぁ。うーむ、結構デスって中毒性高いかも。デスヴォイス(と書いてウガイ声と読む)に慣れると普通の曲が軽すぎて退屈になってくる。同じクラスの穴島君ばりにアームドフェノメノンしてしまいそうな予感。

まぁでも、音楽性のないものは聴けない耳だからメロデス以外のデスなんて聴けないんだろうけどね。

■ 懐かしのシリーズ

「あおによし」

中学校の教科書から。「あおによし 奈良の都は…」の歌のことについてのウンチクから、著者の小さい頃の記憶の話へとつながっていく。特に面白いわけでもなければつまらなすぎるわけでもない、すっげー中途半端な話。

■ TeX

こないだpLaTeX2eが使いたいなぁと書いたら、SourceForgeのBugTrackに日本語TeXが登録されてました。なんてタイミングの良い！

というわけで早速インストール。無事動いてます。includeのパスを少し変えないとconfigureで止まるのと、xdviがepsな図をインクルードしたdviファイルをうまく表示できないのが難だけど、まぁ気にはならん。さっさとdvipsしてgsで見れば良いだけのこと。印刷も素直に通ったし。

これでやっと完全にGentooに移行出来る。わーい。

■ 追記

某i氏がソレを冬の陣にて決行するかも知れないそうです。

みんながみんな目になろうとして結果巨大な目玉になったら、鬼太郎あたりに征伐されそうですな。関係ないけど、「スイミー」と聞くと、B'zの「スイマーよ！」という曲を思い出す。

■ [Gentoo] emacs-w3m

emacs-w3m は w3mmee でも動くし，DEPEND を virtual/w3m にすべきだと思うんだがどうか．

と Bugs にて進言したいのだが，Bugzilla の諸々の値 (Severity とか Component とか) をどうすれば良いのかさっぱりワカランので放置．

俺にはむしろ英語よりも Bugzilla のわかりにくさの方がネックだなぁ．慣れんとダメだ．

■ [Gentoo] むぅ

ebuild-uploader が w3mmee な emacs-w3m だと化ける．端末ならなんの問題もないんだけど…．フレームページと中身の文字コードが違うせいかと思って全部 UTF-8 にしてみたけどこれでもダメだった．

フレーム抜けるとちゃんと表示できるのになぁ．わからん．

俺がむかーし昔作ったヘタレ CGI はフレームでも普通に表示できたのになぁ…．あれは文字コードが euc-jp だから？

■ [小ネタ] 寿司まくら

やべえ，欲しいかも．

via AEIOU

■ [日記] namazu やめました

脆弱性云々の話が出てたし，割と tDiary のキャッシュ消してるからあまり効果がないし．

検索したい人は Google 辺りで

site:callisto.comlab.soft.iwate-pu.ac.jp ほげほげ

とかやって下さい．

■ [日記] 飯日記

• 19時頃：カツカレー

やはり寝起きにカツカレー大盛りは胃にもたれる……．

■ [日記] 飯日記

• 08時頃：サンドイッチ
• 12時頃：焼き魚定食
• 24時頃：牛筋うどん

■ [日記] んー

最近一日の半分以上がミーティングだ．個人作業が全く進まねぇ．

Binary 2.0 見たかったのにそれどころじゃなかった．

■ [Py][OpenFlow] Trema day #8 で発表してきた

あまりにも放置しすぎているので，たまには何か書こうか... ということで．

ひょんなことからお声かけ頂いて，先日 Trema day #8 で発表してきた． ネタは OpenFlow 環境での L2 traceroute について． 資料は slideshare に置いておいた ので興味のある方はどうぞ． コードも oftroute, oftgui に公開しているので，virtualenv でも作って

$ pip install git+https://github.com/atzm/oftroute.git
$ pip install git+https://github.com/atzm/oftgui.git

とか何とかやればインストールできると思います． コマンドとか使い方は簡単にドキュメントに書いてあるけど，基本的にはコントローラを起動して mininet とかを繋いでやれば動作を見るくらいはできる． Ryu アプリとして書いてあるので，ライブラリ的に (?) 扱って他の Ryu アプリと連携して動くこともできるはず．

L2 の traceroute と言えば IEEE 802.1ag とか Ethernet OAM とかまあそんなキーワードで語られることが多いというかそれがスタンダードなので当然なんだけども，さてそれがそのまま OpenFlow 環境下で使えるかというと，必ずしもそうとは限らない．

例えば IEEE 802.1ag では OAM フレームを Ethertype 0x8902 でぶん投げることによってその機能を果たすわけだけれども，OpenFlow Switch がそれをそのまま吸い上げてしまうようなことをすると，制御対象外ネットワークから入ってくる OAM フレームまで吸い上げてしまうことになるので，場合によっては好ましくないこともある．

また OpenFlow 環境では，普通の IEEE 802.1D 的な Learning Switch と違って，主に L2,3,4 のフィールドを使って転送経路を自由に設定できてしまうので，例えば ARP は経路 A を通るけど，IPv4 は経路 B を通る，というようなネットワークを組めてしまう． こうなると，特定のフレームが通る経路だけでなく，「どういうフレームだったら」どういう経路を通るのか，ということを確認する術が欲しくなる．

スライドにも書いてある通り，この手の話についてはいくつも論文が発表されているようで，今さら何か目新しいネタというわけでもなさそうなのだけれど，(公開されてるものだけだけど) 読んでみると頭の弱い自分にはどうにも難しすぎる... ということで，自分でも分かる/作れるくらいに簡素化/最適化したやり方をひねり出してみたのでした．

あと 1 つ注意点． 一応 traceroute 実行時にフレーム転送時間が出るようになってるけども，現状これはとても信用ならない値なので無視した方が良い． というのも，Ryu の (というか Ryu が内部で使ってる tinyrpc の?) WebSocket ライブラリの都合で，client が ack を返さないと server はそこで block してしまうらしい． 要するに，client (oft-traceroute コマンドや oftgui Web 画面) が server (oft-controller とか) に ack を返すまでの時間が，転送時間に乗ってきてしまっているということ． これはどうしたもんかなぁ... と思いつつ，今に至る...

何はともあれ，関係者の皆様，参加の皆様，お疲れ様でした & ありがとうございました．