2009/4/1ジョークRFC

今年のは以下2つ

  • RFC 5513 IANA Considerations for Three Letter Acronyms
  • RFC 5514 IPv6 over Social Networks

だよ。
タイトル和訳すると

  • RFC 5513 IANAによる3文字略語についての検討
  • RFC 5514 SNSIPv6

だね。ソーシャルネットワークよりSNSのほうがピンとくるよね。

Abstractだけ翻訳してみたよ。

RFC 5513 IANA Considerations for Three Letter Acronyms

IANAによる3文字略語について検討

> Abstract

概要

Three Letter Acronyms (TLAs) are commonly used to identify components
of networks or protocols as designed or specified within the IETF.  A
common concern is that one acronym may have multiple expansions.
While this may not have been an issue in the past, network
convergence means that protocols that did not previously operate
together are now found in close proximity.  This results in
contention for acronyms, and confusion in interpretation.  Such
confusion has the potential to degrade the performance of the
Internet as misunderstandings lead to misconfiguration or other
operating errors.

Given the growing use of TLAs and the relatively small number
available, this document specifies a Badly Construed Proposal (BCP) for the
management of a registry of TLAs within the IETF, and the procedures
for the allocation of new TLAs from the registry.  This memo provides
information for the Internet community.

3文字略語(以下TLA)は、ネットワークコンポーネントプロトコルを識別するためにIETFにて設計または指定されているような呼び名で日常的に使われている。
当然のことだが、これら略語は複数の意味持つ可能性がある。これまではあまり問題とはならなかった事だが、ネットワークの収束によってこれまで同時に使われることがなかった2つのプロトコルが、ごく間近なところで使われるようになっている。これは結果として、略語のにおける係争や、誤解による混乱を生んでしまう。
このような混乱は、プロトコルの誤解が設定ミスやオペレーションエラーを引き起こすため、インターネットの利便性を損なう可能性を秘めている。

TLAの使用が増え続けているのに対して、利用可能な文字は少ない。このドキュメントはIETFにおけるTLAの登録管理のため、バッドな着想を与えるプロポーザル(BCP)および、新しいTLAの登録手順を示す。

      • -

誤解を避けるために3文字略語を登録管理しようって言いながらバリバリかぶっとるやないかーい!っていうRFCだね。
3文字略語 Three Letter Acronym=TLA は、IPアドレス屋さんはTop Level Aggragationだと思うかもしれないね。でも普通の人にわかるわけがないね。ちなみに3文字略語という意味でのTLAは通信業界ではまぁまぁ使われているみたいだよ。
バッドな着想を与えるプロポーザル Bad Contrued Proposal=BCPはちょっと無理な翻訳をしたけれど、ふつうは Business Continuous Plan だよね。
(ProposalをProtocolって読んでた。一部修正した。)

本文は読んでないけど、予約語の定義がおかしくて

VPN: Very possibly no use (どう考えても使わないだろ、常識的に考えて)
TCP: Totally bad proposal (全般にわたってダメな提案)
NBG: This document (つまりこのドキュメントだ)

なんだか投げやりな印象を受けた。NBGは、no bloody goodで、「まっったくダメ」という意味だ。

RFC 5514 IPv6 over Social Networks

SNSIPv6

Abstract

There is a lack of IPv6 utilization in early 2009; this is partly
linked to the fact that the number of IPv6 nodes is rather low.  This
document proposes to vastly increase the number of IPv6 hosts by
transforming all Social Networking platforms into IPv6 networks.
This will immediately add millions of IPv6 hosts to the existing IPv6
Internet.  This document includes sections on addressing and
transport of IPv6 over a Social Network.  A working prototype has
been developed.

2009年始めにおいては、IPv6は有用性に欠けているところがある。
これは、IPv6接続ノード数が依然として少ない事と関係がある。このドキュメントは、全てのソーシャルネットワーキングプラットフォームをIPv6ネットワークに移行することで、IPv6接続ホストを圧倒的に増やすための提案をする。

これは数百万のIPv6ホストをすぐに既存のIPv6インターネットに接続することとなる。このドキュメントは、SNSでのIPv6アドレス管理と転送についてのセクションを含んでいる。活動の基礎となるプロトタイプを開発した。

      • -

これは本当につまらないRFCだった。出オチも良いところだ。
IPv6は流行らないけど、SNSは超流行ってるからユーザ全員IPv6にすれば良いじゃーん、って思ったんだって。はぁ、そうですか。

VirtualBoxとVMWare

昨日までVMWare Server 2.0を使っていた。今日からVirtualBox 2.0 を使っている。

VMWareはタダだし、本当に良くできたソフトウェアだ。1.x→2.0でUIをブラウザに載せてくれちゃったのには辟易したが、それにしても良くできたソフトウェア。便利。そして速い。快適。ほとんど完璧と言えるソフトウェアだ。

ある一点をのぞいては。

そのある一点とは、ショートカットキー。最悪だ!強烈なのだ!

Ctrl+Rはブラウザのリロードだったり、emacsの↑向き検索だったり、まぁよく使うんだ。俺は。
だけど、VMの中の窓に送るつもりのCtrl+Rの入力が、不意打ちのようにVMの窓そのものがアクティブになっていて、VMの窓に届くことがある。そのとき、VMは強制リセットなのだ!
VMの中で動かしてるブラウザでリロードしようとしたら、VMもろとも強制リセット。
一昨日3回目のCtrl+R事故が起きたことで、VMWareを捨てる決心がついた。作業中のもの全てをCtrl+Rでリセットしてしまう環境なんて使ってられない。

話はそれて、Ctrl+Rを無効化するようなソフトウェアを使えば良いという意見があるかもしれないが、それは受け入れない。俺はそういう危険なショートカットを平然と用意するソフトウェアの設計に呆れたのだ。回避すれば良いというわけじゃない。

そしてVirtualBoxを使っているわけだが…。

VirtualBoxのよい点

  • HostKey

VM操作に使うキーを指定できる。たとえば再起動したくなったら、HostKey + Rなど。HostKeyは右側のCtrlがデフォルト。まーまず使わないキーだよね。俺はHHKを使っていてCtrlなんてひとつしかないので、右側のALTキーを割り当てた。絶対に押さないキーなので操作が安心。

β版を試す気になった。普通に動いた。わー、って思った。最新のOSに対応をする心意気が良い、という意味で。

別にVMwareのクライアントソフトウェアで良いといえば良いんだが、クライアントにアプリケーションをインストールする必要がなく、標準のリモート接続クライアントが使える意義は非常に大きい。

  • 64bit対応

Windows7の64bit版は動かなかったが。64bit対応ってうれしい。

VirtualBoxの悪い点

  • おせぇ。とにかくおせぇ

特にグラフィック描画とネットワーク。CPU使用率が異様に高い。

VMWareより環境としてはよくなったと思うんだが、速度だけはいかんとも。おかげでホストOS(Linux)の操作が増えた。Windowsじゃなきゃ出来ないことだけVMでやるようにシフトしつつある。

kakasiとText::Kakasiを入れる話

新年一発目はかかしの話。kakasiです。

日本語のわかち書きをやるツールとしてとてもメジャーなんだけど、本当は漢字かな混じり文をひらがなやローマ字に変換するためのツールだったりする。辞書構造がとてもとてもシンプルなので、使い勝手が非常に良い。

さて、一般にはわかち書き用途に使われることが多いが、今回は漢字かな混じり文をひらがなに変換するために使いたい。Perlから叩く。

kakasiを入れて、Text::Kakasiを入れて、とさくさく作業したらエラーが出た。記録してないが、PerlスクリプトからText::Kakasiをロードしたところで kakasi_getopt_argvなんてsymbolは知らん!みたいなエラー。ライブラリのリンクに失敗していやがるらしい。でもmakeのログにはエラーなんてない。

書いてたら長くなったから答えから書く。

libkakasi.soを/usr/local/lib以外にインストールしている場合には、Text::Kakasiコンパイルは気を付けないといけないよ!make testって大事だよ!

以下詳細。

俺はライブラリ類を/usr/local/libにいれない場合が多い。

$ ls -l /usr/local
(省略)
lrwxrwxrwx   1 root  root    12  1月  5 14:12 kakasi -> kakasi-2.3.4
drwxr-sr-x   6 root  root  4096  1月  5 14:12 kakasi-2.3.4
(省略)

ライブラリのバージョンアップと、問題発生時のバージョンダウンがシンプルに制御できるからだ。

さてkakasiもこんな風にいれたので、Text::Kakasiのインストールを↓みたいにした。

$ perl Makefile.PL \
> INC=-I/usr/local/kakasi/include \
> LIBS=-L/usr/local/kakasi/lib
$ make
$ make test
(ここでエラー)

Makefile.PLを読むと、これ以上ないほどシンプルなもの。12行しかない。行間には「パスを変えたきゃ勝手に書き換えろ」と書いてあるんだ。

$ diff -u Makefile.PL.original Makefile.PL
--- Makefile.PL.original        2003-05-26 19:42:27.000000000 +0900
+++ Makefile.PL 2009-01-06 12:57:03.000000000 +0900
@@ -6,7 +6,8 @@
 WriteMakefile(
              'NAME' => 'Text::Kakasi',
              'VERSION_FROM' => 'Kakasi.pm',
-             'INC' => '-I/usr/local/include',
-             'LIBS' => ['-L/usr/local/lib -lkakasi'],
+             'INC' => '-I/usr/local/kakasi/include',
+             'LIBS' => ['-L/usr/local/kakasi/lib -lkakasi'],
              'DEFINE' => '-DWAKATIGAKI',
 );

INCとLIBSを書き換えた。できた。使えた。よかった。

思えば、Makefileがかけない奴のためにconfigureがあったりMakeMakerがあるわけで、そのMakeMakerの元ネタがうまくかけない奴のためにオプション充実なMakefile.PLがあったり、という期待は間違いだと言えるよね。うわっほい。

PCの電源ってさ

ウチのサーバの電源についてるファンが壊れて回らなくなったんですよ。そんで、開けっ放しで稼動させたままファン買いに行って取り付けたんですね。
さて、もともとついていたファンは+と−の2ピンなんだけど買ってきたファンは3ピン。刺しても回らないでやんの。+と−はあってるはずなんだけど回らない。基盤のほうがイったかな?とか思ったけどそれは気にしないことにして、HDDとかに繋ぎそうなコネクタから取り出すケーブルが付属してたから、それを使うことにした。
ウチのサーバは、10年近く前のCompaqのスリムめなデスクトップPCだったりするんだけど、そういうパソコンなだけあって中で使う電源のコネクタが足りなかったりする。だから、1本の電源を二股に分離するケーブルを使って、CD-ROMドライブとHDDにつないでた。もういっこのHDDは普通に1本の電源を入れてる。
二股に分けてるところから、さらにファンの電源を取ろうとしたのがマズかった。今思えばバカそのもの。
1本の電源ケーブルに、CD-ROMドライブ・HDD・ファンを繋いだのだ。
とりあえずファンも回ったし起動〜とやったら、HDDが見えているのにアクセスできない!
最初はHDDが壊れたと思った。
でもわりとすぐに、電圧足りてない?って気づいて、二股になんて分けてないコネクタを使ってファンを繋げたところ快調。
最初からそうすればいいのにね。バカな俺。

教訓:電力供給って大事

x86 Solaris 10 で OpenSSL 0.9.8 が Core dumped

相当まいった。
/usr/sfw/libにも/usr/local/libにも存在する状況で、/path/to/some/other/dir/openssl にまた別なバージョンを、しかもLD無視してリンクするように(rpathだよ)小細工するようなOpenSSLを作ってたから、本当に気づくのが遅かった。
悪いのは俺じゃなかった。

さて、OpenSSL 0.9.8以降を、x86 Solaris 10でコンパイルすると、出来上がったバイナリは以下のようになる。

# /path/to/openssl/bin/openssl
Segmentation Fault (core dumped)

こうなる原因が俺かと思ったらそうじゃなくて、OpenSSLのソースに同梱されている PROBLEMS ファイルに書いてあった。

- There is a subtle Solaris x86-specific gcc run-time environment bug, which
  "falls between" OpenSSL [0.9.8 and later], Solaris ld and GCC. The bug
  manifests itself as Segmentation Fault upon early application start-up.
  The problem can be worked around by patching the environment according to
  http://www.openssl.org/~appro/values.c.

以下俺訳(無保証。正しくは原文を。)
--------
Solaris x86gccランタイム環境に微妙なバグがあってOpenSSLの0.9.8以降とSolarisのldとgccの間でおこる。アプリケーションの起動時にセグメンテーションフォルトになっちゃうんだよね。↓のパッチでなおるよ。ワークアラウンドだぜ。
http://www.openssl.org/~appro/values.c
--------
んで、このパッチ?にしてはCファイルじゃん?あれれ?
中身を見たら

# This is Solaris x86 specific GCC run-time environment patch, which
# makes it possible to reliably deploy .init snippets. Trouble is that
# Solaris linker erroneously pads .init segment with zeros [instead of
# nops], which is bound to SEGV early upon program start-up. This bug
# was recognized by GCC team [it is mentioned in source code], but
# workaround apparently and obviously erroneously slipped away in some
# newer GCC release. This patch compensates for this mishap by dropping
# modified values-X*.o into GCC installation tree. Object modules in
# question are normally provided by Sun and linked prior crtbegin.o.
# Modified versions are additionally crafted with custom .init segment,
# which does some magic:-)

こんなコメントが書いてある。
また俺訳。
--------
これはSolaris x86版のGCCランタイム環境向けパッチだよ。たぶんちゃんとした . init の断片の配布版。 (.initって何?俺は知らん)。Solarisのリンカが nops じゃなくてゼロで . init セグメントに追加するもんだから、プログラムの起動時にSEGV(俺注: Segmentation Violationな)が出ちゃうんだよ。GCCチームも知ってる話(ソースに書いてあるんだよね)なんだけど、ワークアラウンドが新しいGCCのリリースからさらっと漏れてんだよ!
だから、このパッチはGCCのインストールツリーにvalues-X*.oがないことで起きるおかしな話を補間します。このあたりのオブジェクトモジュールは普通Sunから提供されて、crtbegin.oにリンクするんだよね。この修正版は追加でカスタムな . initセグメントを作りこむよ。これって魔法?
--------

というわけで、長くなったのでここまで。続きはあとで書く。

      • -

というわけで、あとでの今日は9/22なんだけど、面倒だからこのエントリはここまで!!!

# ksh -f values.c gcc

こんだけやってコンパイルしたら終了だからさ。64bitで動かしてたら

# ksh -f values.c gcc -m64

これもな。以上!!

gdを完全に/usrから離れて作る

できねええええええ

詳細はまた今度。

      • -

さて、また今度の今日は9/22。結果から言うと、できた。

でもMakefile修正が必要。

仕事でやる話だから、だいたい誰にでも(やってる内容が理解出来る範囲で)出来るようにしておきたいという意図と、バージョンアップ後にもなるべく同じ手順で出来るように、という意図から configure オプションやらせいぜいCFLAGS,LDFLAGSの指定で事足りるように、と思っていたんだけど、やっぱり手でMakefileを修正しないと出来なかった。

今回gdを作る目的は、Perlスクリプトから use GD; などとやって使わせる目的。

site_perlの下にがんがんモジュールを突っ込んで行くのもいいけど、モジュール間の依存関係をちゃんと気にして突っ込むのはちょっと無理。

だから、Perlプログラマに使いたいライブラリを選ばせることにした。プログラマは、次のような手順で使いたいライブラリを選ぶ。

#!/path/to/perl
use lib qw(/mylib/v1.0);

use GD;
use hoge;

こういう書き方をさせると、/mylib/v1.0を凍結させることが出来る。新しいモジュールがいれたくなったら、/mylib/v1.1でも作れば良い。それが使いたいプログラムは、use lib qw(/mylib/v1.1); とやれば良い。依存するライブラリもそこに入れてしまえば良い。

Perlみたいなプログラムはできるだけポータブルじゃなきゃいけない。プログラムを書くほうは本当に意識をしないらしいが、Perlモジュールのアーキテクチャ依存やバージョン依存は本当に悩ましいものなのだ。最新のモジュールが少し前のPerlでは使えないなんてことはザラにあるのだ。

さて、/mylib/v1.0はNFSサーバに置いてしまおうかと思っている。サーバは何台もあるから、ファイルを配布するのは面倒だ。

・あるx86 Solaris10 64bitサーバでは
/mylib/v1.0 -> /path/to/nfs/mylib/v1.0/Solaris10_i386_64
・とある x86_64 Linux 2.6 サーバでは
/mylib/v1.0 -> /path/to/nfs/mylib/v1.0/Linux_2.6_x86_64

などとやっておけば、アーキテクチャ依存も回避できないかね?

さて、gdというかGDを/usr以下のライブラリに極力依存せずに作りたいのは上記のような理由による。/mylibの下にPerlのバージョン番号だっていれちゃうぞ。俺ライブラリバージョンは1.0から始めよう。依存するライブラリ(↓には書いてないけどlibzだって同様だ)も全て/mylibに入れてしまおう。

以下手順。 x86 Solaris 10でやったログを加工したもの。いろんなアーキテクチャでこの作業をやって、ちょっとづつ手順が違って本当にやっかいだったが、詳しくは書かない。意図を組んで勝手にやんなさい。

libiconv

/configure \
  --prefix=/mylib/5.8.8/1.0/local
make
make install

freetype

GNUMAKE=/usr/sfw/bin/gmake \
CFLAGS="-I/mylib/5.8.8/1.0/local/include" \
LDFLAGS="-L/mylib/5.8.8/1.0/local/lib -R/mylib/5.8.8/1.0/local/lib"
./configure \
  --prefix=/mylib/5.8.8/1.0/local
gmake
gmake install

libpng

このライブラリは本当にアーキテクチャ依存がヒドイ。まさにnightmareだ。(gdのconfigureスクリプトのコメントにそう書いてある。俺もそう思う。)

cp scripts/makefile.solaris-x86 ./makefile
vi makefile
makefileを以下の通り書き換える。
--- scripts/makefile.solaris-x86        Thu Aug 21 19:54:14 2008
+++ makefile    Sat Sep  6 10:51:06 2008
@@ -28,7 +28,7 @@
 RM_F=/bin/rm -f

 # Where make install puts libpng.a, libpng12.so*, and png.h
-prefix=/usr/local
+prefix=/mylib/5.8.8/1.0/local
 exec_prefix=$(prefix)

 # Where the zlib library and include files are located
@@ -37,8 +37,8 @@
 #ZLIBLIB=../zlib
 #ZLIBINC=../zlib

-ZLIBLIB=/usr/local/lib
-ZLIBINC=/usr/local/include
+ZLIBLIB=/mylib/5.8.8/1.0/local/lib
+ZLIBINC=/mylib/5.8.8/1.0/local/include

 WARNMORE=-Wwrite-strings -Wpointer-arith -Wshadow \
        -Wmissing-declarations -Wtraditional -Wcast-align \
@@ -95,7 +95,7 @@
        ( cat scripts/libpng-config-head.in; \
        echo prefix=\"$(prefix)\"; \
        echo I_opts=\"-I$(INCPATH)/$(LIBNAME)\"; \
-       echo cppflags=\""; \
+       echo cppflags=\"\"; \
        echo L_opts=\"-L$(LIBPATH)\"; \
        echo R_opts=\"-R$(LIBPATH)\"; \
        echo libs=\"-lpng12 -lz -lm\"; \

make
make install

makefile.solaris-x86 のcppflagsのところは配布ソースのバグ。\足りないんだよね。

libjpeg

./configure \
  --prefix=/mylib/5.8.8/1.0/local \
  --without-x \
  --enable-shared \
  --enable-static
make
make install

Linuxの場合はmake前に以下のおまじないが必要。jpegライブラリ同梱のautoconfが古いから?らしい。

ln -s `which libtool` libtool

libgd

やっとlibgdだ。

export CFLAGS="-I/mylib/5.8.8/1.0/local/include" \
       LDFLAGS="-L/mylib/5.8.8/1.0/local/lib \
                -R/mylib/5.8.8/1.0/local/lib" \
       CPPFLAGS="-DLIBICONV_PLUG -DJISX0208" \
       LIBPNG12_CONFIG=/mylib/5.8.8/1.0/local/bin/libpng12-config \
       LIBPNG_CONFIG=/mylib/5.8.8/1.0/local/bin/libpng-config

makeを叩くと、中でもう一度configureを実行するので、exportしてやる必要があった。

 ./configure \
  --prefix=/mylib/5.8.8/1.0/local \
  --without-x \
  --with-libiconv-prefix=/mylib/5.8.8/1.0/local \
  --with-png=/mylib/5.8.8/1.0/local \
  --with-freetype=/mylib/5.8.8/1.0/local \
  --with-jpeg=/mylib/5.8.8/1.0/local
 make
 make install
 unset CFLAGS LDFLAGS CPPFLAGS LIBPNG12_CONFIG LIBPNG_CONFIG

GD

ライブラリのリンクパス関連の問題ですげぇ面倒。もしかしたらアーキテクチャによって(LinuxとかHP-UXとか)は同じようにならないので、特に注意のこと。

PATH=$PATH":/mylib/5.8.8/1.0/local/bin" \
perl Makefile.PL \
 PREFIX=/mylib/5.8.8/1.0 \
 LIB=/mylib/5.8.8/1.0/lib \
  -options "JPEG,FT,PNG,GIF" \
  -lib_gd_path /mylib/5.8.8/1.0/local/lib \
  -lib_ft_path /mylib/5.8.8/1.0/local/lib \
  -lib_png_path /mylib/5.8.8/1.0/local/lib \
  -lib_jpeg_path /mylib/5.8.8/1.0/local/lib \
  -lib_zlib_path /mylib/5.8.8/1.0/local/lib

ここで出来るMakefileを以下のとおり編集する。

  # --- MakeMaker dynamic_lib section:
  
  # This section creates the dynamically loadable $(INST_DYNAMIC)
  # from $(OBJECT) and possibly $(MYEXTLIB).
  ARMAYBE = :
- OTHERLDFLAGS =
+ OTHERLDFLAGS = -R/mylib/5.8.8/1.0/local/lib
  INST_DYNAMIC_DEP =
  INST_DYNAMIC_FIX =

これをやらないと、実行時のライブラリ探索パスがOS標準になってしまうので、use GDしてもlibgdが見付かりません、っていうことになってしまう。

あとは以下のとおり。

make
ake install

そんなオプションはない、っていうエラーメッセージが出てしまうが、実害はないようだ。(ヘッダのincludeもライブラリのlinkも大丈夫)。

Apacheログを眺める話

長い事放置したなぁ。

さて、Apacheのログフォーマットをいじるよ。

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D %v %I %O %X" combined_DvIOX

最近のお気に入りはコレ。logioモジュールが必要。
ほんとは %D %X %v %I %O だよなー、って思ったけど一度これでスタートしちゃった所があるので、これでやってます。
http://httpd.apache.org/docs/2.2/ja/mod/mod_log_config.html
いろいろ出せるんだよねー。実は%{Foobar}oはかなりアツイ。

さてさて、%Dの応答にかかった時間(マイクロ秒)を出したので、せっかくだからログをtailしながら見たいじゃん、って思って速攻で書いたのが↓のフィルタ

$ cat /path/to/aplfilter
#!/usr/bin/perl

my ($host, undef, $user, $date, $time, $method, $req_uri, $httpver, $status, $byte, $referer, $ua, $D, $v, $I, $O, $ret);
while (<>) {
        ($host, undef, $user, $date, $time, $method, $req_uri, $httpver, $status, $byte, $referer, $ua, $D, $v, $I, $O, $ret) = ($_ =~ m|^(.*) (.*) (.*) \[([^:]+):(.*) \+[0-9]+\] "(.*) (.*) HTTP/(.*)\" (.*) (.*) \"(.*)\" \"(.*)\" ([0-9]+) (.*) ([0-9]+) ([0-9]+) (.*)|);
        print "$host\t$time\t$D\t$method\t$req_uri\n";
}

一行が長いのはご愛嬌。↓こうやって使うよ。

$ tail -f /path/to/access_log | /path/to/aplfilter

出したい中身が変えたくなったらaplfilterを書き換える。出力フォーマットをオプション化?その場で使うだけのクソスクリプトにそんなことしないよ。えへ。