JANOG - /home/pochi/ChangeLog

■ Internet Week JANOG枠のBoF [JANOG]

やっぱり出席できず。むむぅ。
聞きたかったんだけどなあ。

■ 経路爆発が起こるとなぜ困るのか [computer][JANOG]

http://itpro.nikkeibp.co.jp/article/COLUMN/20061121/254222/

近藤さんのコラム。
つい最近20万経路を超えたわけなんだけど、
経路が溢れるとどうなるか、という話。

- 経路がルータのメモリの上限を超えてしまう
- メモリの上限を超えると、経路情報を受けとれなったり、
  ルータが再起動しちゃうことも。
- 経路フラップが発生

対策は

- ルータの切り替え
- 頑張ってアグリゲート

しかない。

IPv6 は、経路集約に配慮して設計、運用されてるんだけど、
マルチホームがあたりまえ、AS の数も増えまくり、
という現状を見ると IPv6 化されたとしても、
経路爆発は収まらないよなあ。
むしろ悪化する気も。

新ルーティングアーキテクチャが欲しい気も。
インターネットがここまで大きくなってくると、
アーキテクチャ再構築なんていう話は、
実際の実装がないと話にならないわけで、
そういうことができる立場にいるのは、
CISCO、Microsoft、Google、Intel ぐらいかのう。
そのへんで何かやってないのかしら？

■ MEDの落とし穴の相談 [JANOG]

九段下にて。

BGP では、ルータが

- local Preference
- AS Path
- Origin
- MED

これらを上から順番に比較していって、
経路を選択している。
(実際はもうちょっと階層はあるけどね)

ルータエンジニアのお仕事の一つは、
トラフィックをうまくさばくためにこれらの値をうまく調整する、
ということなんだけど、、、、

その調整パラメータの1つである MED は曲者だよねえ、
というお話。

■ 経路情報付きパケットでのルーティングの話 [JANOG][computer]

JANOGの宴会で、イーサネット駄目すぎ、捨てたい!、と言ってたら、
それを言ったら BGP だって、という話になった。

IP の世界では、遠くのノードと通信をしたいときには、
自分が持っている経路表を参照し、近くにあるルータに投げる。
そのパケットを受けとったルータも、それぞれが持っている
経路表を元に隣のルータに渡してやる。
それを繰り返して最終的な目的地までパケットが渡される。
ちゃんと届くためには、経路表がちゃんとしてなきゃいけなくて、
それを正しく保持するための仕組みがルーティングプロトコル。
インターネットにおいては BGP が主に使われている。

ところが、今の BGP には

- 経路情報が膨大になってきた。
  20万経路を超えて、ルータも処理するのが大変。
- ルータを適切に設定してないと、偽経路情報を流されたときに
  経路乗っとり等が発生する可能性がある
- トラフィックコントロールをちゃんとしたいけど、
  意図したようにパケットが流れてくれないことがある

というような問題がある。
そういう問題に対しては、今のところは、
仕様だよねえ、ある程度は我慢して、
でも現状でできる最善の努力をしよう、
というふうにオペレーションで対応をしている。
IRR で頑張ろう、フィルターをちゃんとしようよ、
MEDで頑張ろう、とかとか。


でも IETF や IRTF 等では、もっと根本的に BGP に代わる
ルーティングアルゴリズムも沢山検討されてて、
良さげなものも結構あるらしい。
たとえば、パケットに経路情報を持たせりゃ良いじゃん、
という提案とか。

具体的には、制御情報を除くと、IP パケットヘッダは

- 発信元
- 宛先

の2つの情報しか持ってないけど、これを拡張して

- 発信元
- 宛先
- 途中経路1,途中経路2,途中経路3,途中経路4,,,,

みたいに経路情報をパケットに持たす、という提案。

もし経路情報がパケットに含まれていれば、
ルータは、書いてある経路に従って、転送してやるだけ。
経路情報はエンド側で作ってやる。
経路情報を作る元ネタには、IRRみたいなものを拡張した
経路情報サービスを利用する。

経路情報がパケットが入ってなかったら、
今までどおりの通信を行なうだけ。
むしろほとんどの通信は、今までの方法のままで、
あくまでも、イレギュラーな経路で通信したい、という場合だけ、
経路情報付きパケットだけ、を使う、と。

そもそも経路情報が爆発的に増えたのは、
マルチホーム等のイレギュラーな経路を実現するための、
パンチングホールが主な原因なんだよね。
そういうわがままな人達のためのコストをインターネット全体で、
払うのはやっぱり不自然な気がする。
基本サービスとして、綺麗にアグリゲートされるツリー型の
経路を用意しておいて、今までどおりの通信をする。
でもイレギュラーな経路を使いたいユーザは、
それぞれが経路情報をパケットに付ける、というようにする。
わがままなユーザは、わがままの代償として、経路情報を付ける、
という、コストを負担することになる、と。

実装もわりとシンプルにできそうだし、ルータの負荷も軽そう。
届かない場合は、経路情報なしで再送すれば、済むだけ。
アプリケーション毎に経路を選ぶことができる。
経路情報サービスは、複数の会社がそれぞれに立ちあげることが可能で、
競争によってコストも削減できそう。
  
将来のモデルとしては、なかなか良いアイディアな気がするね。

ひょっとするとこういう考え方は、IP ではなく、
オーバレイネットワークみたいなものの上で最初に
実装されるのかもなあ。

勉強しなきゃ、とか思った。

■ JANOG 宴会 [JANOG][宴会]

新橋にて。
主に今井さんの話を聞いてた。

■ JANOG 19 Staff Meeting [JANOG]

汐留にて。
追加募集したスタッフも揃った。
大人数。

MT の使い方説明をしたり。

■ JANOG 19 プログラムミーティング 高速切替 [JANOG]

新橋にて。

SONET なんかだと、障害があったとき 50 ms 以内に
うまいこと対応できたりする。
でも、IP で構築された経路で同等のクオリティを実現するのは
かなり大変。
でも要望はあるので、、、という話。

BFD を使っていこう、という結論にできるかしら。

■ JANOG Web 整備 [JANOG]

テンプレートいじり等々。
MT は楽。

■ JANOG PC ミーティング [JANOG]

神保町にて。
発表者の顔合わせと、内容についてのプレゼン。
沖縄も面白いプログラムが沢山出てきそう。
わくわくするね。

■ JANOG ML へのアナウンス [JANOG]

ウェブがリニューアルされたよ、とアナウンス。
レジストが開始されたよ、とアナウンス。
みなさまお疲れさまでした。
って本番まではまだまだだけどな。

■ JANOG 19 ウェブリニューアル [JANOG]

だーやまさんが格好良いテンプレートを作ってくれたよ。
ということでリニューアル!

JANOG19 Meeting
http://www.janog.gr.jp/meeting/janog19/

■ JANOG 19 下見ツアー [JANOG]

大人数で沖縄へ!!!

でもでも仕事の都合で東京でお留守番。。。。
明日、職場の総会なの。。。。
かなしすぎ。。。。

■ JANOG19 キックオフ宴会 [JANOG][宴会]

歩道橋を乗りついで銀座の沖縄料理屋へ。
プロデューサーの喋り方等を勉強。

■ JANOG19 スタッフミーティング [JANOG]

汐留にて。
Skype で沖縄と大阪を繋いでみる。

LA が Wiki にパワポを上げているのを発見したので、
速攻で Pub のパワポ作成。どたばた。

まずは自己紹介。

次は分科会。
Pub は10人体制をもくろんでたけど5人しか集まらなかったので、
やりくりがちょと大変。
場合によっては再募集するかも。

最後に全体でもう一度打ち合わせ。

いろいろやること山積み。
がんばろー。

■ JANOGのプログラム公開 [JANOG]

公開したよ。

http://www.janog.gr.jp/meeting/janog19/2006/10/post_23.html

発表者やプログラム委員はまだ伏せてあります。
小出しにしていく予定。

■ JANOG プログラム面接 [JANOG]

金曜日に続いて2日目。夜だけ参加。大手町にて。

面接終了後にどのプログラムを採用するか検討検討。

■ JANOG プログラム面接 [JANOG]

夜だけ参加。大手町にて。
タイトルを決めるために変態とか猥褻とかを一生懸命検索。
BGPの話なんだけどね。

■ 電気通信事業法第七条の翻訳 [JANOG][computer]

http://ya.maya.st/d/200610a.html#s20061007_1

（基礎的電気通信役務の提供）
第七条　基礎的電気通信役務（国民生活に不可欠であるため
あまねく日本全国における提供が確保されるべきものとして
総務省令で定める電気通信役務をいう。以下同じ。）を
提供する電気通信事業者は、その適切、公平かつ安定的な
提供に努めなければならない。

これを今風に翻訳すると

（ユニバーサルサービスの提供）
第七条 NTT 東西は加入電話とか公衆電話とか110番とか
119番とかを日本全国格差なく不採算だろうが
なんだろうがやらなきゃダメ。

こうなる、と。
なるほど。

インターネットは総務省令で定められていないし、
義務を負うのも提供事業者として指定されている NTT 東西だけ。

NTT 東西って大変なんだねえ。

法律をやさしく翻訳するプロジェクトみたいなものって
あったら嬉しい気がするな。
wikipedia 財団でやらないかな、そういうの。
法律家も楽になると思うし、法律家不足の問題も
解消できると思うのだが。

でも税金使ってやるのはなんか違う気もする。

■ JANOG19 では聞いてみたいプログラムへの投票を募集しています [JANOG]

http://www.janog.gr.jp/meeting/janog19/vote/

JANOG19 では通常のプログラム公募とは別枠で、
こんなプログラムを聞いてみたい、という枠を作っています。
どんどん投票してくださいませ。

もし、バグがあったら教えてくださいませ。。。。

■ PHP + MySQL + PEAR + Smarty によるウェブアプリケーション作成 [computer][JANOG]

プログラムの投票用ページを作った。
プログラム書きって楽しいよなあ。

メモを吐き出し。

○ソフトウェアインストール
ソフトウェアは ports でインストールする。
そのほうがアップデートが楽だしね。

PHP は lang/php* から入れること。
CLI もインストールしないと PEAR がインストールできない。
www/mod_php* を入れてて、CLI が入ってないような時は、
一旦削除してから lang/php* を入れる、と。

Smarty のインストール

cd /usr/ports/www/smarty
make install

PEAR は必要なものを必要に応じて。

cd /usr/ports/devel/pear
make install

cd /usr/ports/security/pear-Auth
make install

cd /usr/ports/databases/pear-DB
make install

cd /usr/ports/devel/pear-HTML_Common
make install

cd /usr/ports/devel/pear-HTML_QuickForm
make install

PHP にライブラリの場所を教える

vi /usr/local/etc/php.ini
===
include_path = ".:/usr/local/share/pear:/usr/local/share/pear/PEAR:/usr/local/share/smarty"

○データベースを作成

mysqladmin --user=root create <データベース名>
mysql <データベース名> < <テーブル定義>

mysql --user=root mysql
---
grant all on <データベース名>.* to <ユーザ名>@localhost identified by "パスワード";
flush privileges;
exit

ネットワークごしにアクセスさせたい場合は以下も。

grant all on <データベース名>.* to <ユーザ名>@'172.16.0.0/255.255.255.0' identified by "パスワード";

実際にテーブルを作ったりするのは、MySQL Administrator の
ようなGUIツールを使うのが楽。

MySQL Administrator
http://www.mysql.com/products/tools/administrator/

文字コードは utf8 にしておくのが無難。
Table Engine も InnoDB で良いでしょ。

そうやって作ったテーブル定義は、

mysqldump -d データベース名

で吐き出しておく。


MySQL の本は手元に一冊ぐらい置いておいたほうが良い。
ある程度理解してて、具体的なコマンドをすぐに知りたい、
というのであれば、ウェブの方が便利かも。
検索できるし。
以下のサイトは便利だった。

MySQL クイックリファレンス
http://www.bitscope.co.jp/tep/MySQL/quickMySQL.html

MySQL について、中身とか、もっともっと詳しく知りたければ
以下の新刊でも買えー、と。

超・極める!MySQL


○PEAR のドキュメント
プログラムを作るにあたっていろいろドキュメントを探したけど、
結局は配布元のマニュアルが一番参考になった。
サンプルも充実してるので、ここだけで充分。

配布元サイト
http://pear.php.net/

配布元サイトのマニュアル
http://pear.php.net/manual/index.php


○Smarty のドキュメント
これも配布元のマニュアルが参考になる。

配布元サイト
http://smarty.php.net/
http://smarty.php.net/docs.php

日本語に翻訳してくれてる方もいて、時間短縮をするなら、
翻訳を読んでから本家にあたる、というのが良いかも。

Smarty マニュアルの日本語翻訳(リンク集にもなっている)
http://sky.freespace.jp/smarty/


○PHP のデバッグ
print_r が超便利。


○文字コード
UTF-8 にしとけば問題が少ない。
EUC とかで書いたものがあれば、nkf で変換しちゃう。

nkf -Ew --overwrite **/*

とかで一気に変換できる。
でも、変換をミスることがあるので、
バックアップは「絶対」取っておくこと。

せっかくなので、UTF-8 生活に切り換えるぜ、
と思ったら、以下のサイトとかを参考に。

いやなブログ: UTF-8 への移行計画
http://0xcc.net/blog/archives/000041.html


○セキュリティに配慮すべし
PHP は、何も考えずに書くと、ものすごく
セキュリティに甘く書けちゃう。

- 細心の注意をはらう
- ちゃんと勉強をする、
- ライブラリを活用する

というのが基本。
SQL インジェクションなんかを避けるためには、
外部由来の文字列には、PEAR の DB モジュールにある
quoteSmart を使って

$db = & DB :: connect( $dsn );
$user_id = $db->quoteSmart( $_POST["input_userid"] );
$pass = $db->quoteSmart( $_POST["input_password"]);

のように処理してやる、と。