• Hoegaarden
• Velkopopovicky Kozel Kozel Medium 11°
• Duchesse de Bourgogne

久し振りに BELGO にて。

• BIERE LARUE

自由が丘 ダラートにて。

ぼくの自宅環境では DHCP サーバーが稼動しているので、ハブに PC をつなぐだけでインターネット環境に出られるようになっています。 これまでは既存の自宅 LAN に直接参加させていたのですが、セキュリティ上はあまり好ましくない状況です。 そこで今回、dhcp による IP アドレスのアサインと iptables によるフィルタリングを組み合わせることで、登録されていない PC は仮想的に分離された別の LAN に参加させるように設定します。

今回の設定では以下のような振る舞いを実現します。

基本アイディアはシンプルで、同一の Ethernet セグメントに異なる IP サブネットワークを重畳させることで仮想的な分離を実現します。 一方のサブネットワークは通常の LAN で、比較的自由に振舞うことのできる環境です。 LAN 内のサーバーが提供する各種サービスはすべて利用可能です。 もう一方のサブネットワークは制限された LAN で、インターネットに出ることのみに行動を制限します。 LAN 内のサービスは（DHCP / DNS など必須のもの以外は）利用できません。 互いのサブネットワーク間の IP による通信はすべて禁止とします。

同一の Ethernet に二つの IP サブネットワークが載っている状態は慣れないと直感的には理解しにくいかもしれませんが、Ethernet と TCP/IP のプロトコル・スタックはこういったことができるような設計になっています（詳細はここでは取り上げませんが、ARP が今回の構成のキモとなります）。 しかし、ある程度ネットワークの知識のある方なら思い当たるでしょうが、この構成にはいくらでも抜け穴があります。 制限された LAN の中でも、もう一方の LAN で使用している IP アドレスを覗き読むことが可能です。 IP アドレスがわかれば、DHCP に頼らずに直接 NIC にアドレスを指定でき、もう一方の LAN に入ってゆけます。 インターネット層よりも上での分離なので、これは仕方のないことです。 完全な分離を目指すのであれば他の方法を検討すべきでしょう。 ここではあくまでも、自宅 LAN へ参加する障壁を高くすることでリスクを少しでもおさえることを目的とします。

Linux Kernel 2.6 の機能を使用しますので、相応のディストリビューションを用意します。 その他に以下のツール / 機能も使用します。

IP alias

IP alias を使用すると、ひとつの NIC に複数の IP アドレスを割り当てることができます。Linux Kernel の機能で、ifconfig コマンドで設定することが可能です。

dhcpd

ネットワーク関連の設定を自動化するデーモンです。登録の有無を判断してクライアントPCを適切なサブネットワークに所属させるために使用します。

iptables

Linux の IP パケットフィルタリング・ルールの制御を行うコマンドです。各サブネットワークに適切なサービスのみを提供し、サブネットワーク間の通信を制御するために使用します。

これらを組み合わせることで、LAN の仮想的な分離を実現します。 Kernel コンパイルのコンフィギュレーションによっては iptables / IP alias が機能しないかもしれません。 その場合は insmod でモジュールを読み込むか、設定を変更して Linux Kernel の再構築を行ってください。

それぞれのコマンドについてのリファレンスをご紹介します。

• Setting up IP Aliasing on A Linux Machine Mini-HOWTO - JF
• Manpage of dhcpd-options - JM
• Manpage of IPTABLES - JM

iptables については、コマンドそのものよりも Linux の IP パケットフィルタリングについてきちんと理解しておくことが非常に重要です。 その目的には、以下のドキュメントは非常に役立ちます。 TCP/IP の基礎のお勉強にもなりますのでざっと目を通してください。。

• Iptables Tutorial 1.2.0
• Iptablesチュートリアル 1.2.0（Tatsuya Nonogaki 氏による日本語訳）

以降の説明では各ネットワークを以下のように想定します。

設定ファイル /etc/sysconfig/network-scripts/ifcfg-eth0:0 を以下の内容で作成します。 ifcfg-eth0 を雛形にすると良いでしょう。

DEVICE=eth0:0
BOOTPROTO=static
BROADCAST=172.16.200.255
IPADDR=172.16.200.254
NETMASK=255.255.255.0
NETWORK=172.16.200.0
ONBOOT=yes
TYPE=Ethernet

続いて eth0:0 を有効化します。

ifconfig などで 172.16.200.254 のアドレスを持つ NIC を確認してください。

多くの Linux で採用されている ISC の dhcpd は、設定ファイルにマッピング情報をもつことで、NIC の MAC アドレスから割り当てる IP アドレスを判断することが出来ます。 設定ファイルにマッピング情報が登録されていない PC （正確には NIC）は “unknown-clients” として扱われます。 この機能を利用すると、登録済みの PC と未登録の PC とで割り当てる IP アドレスを切り分けることが可能になります。 設定ファイルは /etc/dhcpd.conf となります。 まず、登録済み PC に対する設定を行いましょう。

pool {
  deny unknown-clients;

  range 172.16.100.1 172.16.100.253;
  option subnet-mask 255.255.255.0;
  option broadcast-address 172.16.100.255;
  option routers 172.16.100.254;
  option domain-name-servers 172.16.100.254;
  default-lease-time   86400;
  max-lease-time     2592000;

  host registered01 {
    hardware ethernet 00:11:22:33:44:55;
    fixed-address 172.16.100.1;
  }
}

1行目で未登録 PC への IP アドレス割り当てを拒否しています。 以降は 172.16.100.0/24 のサブネットワークの設定です。 最後に記述のある “host ～” の部分が PC の登録となります。 NIC の MAC アドレスと割り当てる IP アドレスの対が記述されていますね。

続いて、未登録 PC に対する設定です。

pool {
  allow unknown-clients;

  range 172.16.200.1 172.16.200.127;
  option subnet-mask 255.255.255.0;
  option broadcast-address 172.16.200.255;
  option routers 172.16.200.254;
  option domain-name-servers 172.16.200.254;
  default-lease-time   300 ;
  max-lease-time       300 ;
}

こちらは未登録 PC の接続を許可しています。 未登録のものはこちら側の pool から IP アドレスを割り当てられるので、172.16.200.0/24 を使用することになります。

以上の設定を含む dhcpd.conf 全体のサンプルは以下となります。

• dhcpd.conf

この設定により、登録済みの PC と未登録の PC は分離されたサブネットワークに所属することになります。

続いて、サブネットワークごとに提供サービスを切り分ける構成を iptables によるフィルタリングで実現します。 最初に各ネットワークに便宜上の名前をつけます。

繰り返しになりますが、iptables を利用する前に以下にざっと目を通しておいてください。 TCP/IP プロトコル・スイートの基本的な動作と、Linux の IP パケット・フィルタリングの動作原理を理解していないと iptables を使いこなすのは難しいでしょう。

• Iptables Tutorial 1.2.0
• Iptablesチュートリアル 1.2.0（Tatsuya Nonogaki 氏による日本語訳）

特に“Chapter 6. Traversing of tables and chains（日本語訳：テーブルとチェーンの道のり）”が重要です。 3つのテーブルと、それぞれのテーブルに属するビルトイン・チェーンの役割分担はしっかりと理解してください。 ipchains 時代を知る人が陥りがちなのが、転送パケットには INPUT / OUTPUT が適用されない点。 転送パケットは PREROUTING / FORWARD / POSTROUTING のみが適用され、INPUT / OUTPUT が適用されるのは当該 Linux Box 自身が発信元 / 送信先であるパケットのみです。 ipchains は転送パケットを INPUT => FORWARD => OUTPUT と処理していたため、これを想定すると iptables では痛い目を見ます。 ご注意ください。

これ以降、これら 3 つのテーブル、5 種類のビルトイン・チェーンに対して、ユーザー定義チェーンとルールを追加することで、様々なフィルタリングを実現します。

iptables を実行する際はスクリプトなどで一括設定を行いましょう。 実環境にて手作業でチクチクと設定変更を行うと、その過程で一時的にセキュリティが低下するタイミングが発生する恐れがあります。 さらに、スクリプト言えども0秒で設定が完了するわけではありません。 スクリプトの最初に以下の3行を入れておきましょう。

iptables -I INPUT -j DROP
iptables -I OUTPUT -j DROP
iptables -I FORWARD -j DROP

これは、パケットの出入りと転送全てを停止します。 そして最後に以下の3行で停止状態を解除します。

iptables -D INPUT -j DROP
iptables -D OUTPUT -j DROP
iptables -D FORWARD -j DROP

停止している間に届いたパケットはすべて破棄されます。 TCP であれば再送機能でリカバリされるはずですが、UDP などの場合の挙動はアプリケーション依存です。 ご注意ください。

一つの Linux Box は1セットの IP table を持ちます。 “NIC ごとに1セット”ではなく Linux Box につき1セットです。 つまり、GLOBAL から入ってくるパケットも KNOWN から入ってくるパケットもどちらも同一の INPUT チェーンで処理されます。 出てゆくパケットも同様です。 そこで、ルールの設定をシンプルにするために INPUT と OUTPUT の最初の時点で GLOBAL / KNOWN / UNKNOWN を別チェーンに振り分けてしまいます。

最初に、ユーザー定義チェーンを追加します。

iptables -N INPUT_GLOBAL
iptables -N INPUT_KNOWN
iptables -N INPUT_UNKNOWN
iptables -N OUTPUT_GLOBAL
iptables -N OUTPUT_KNOWN
iptables -N OUTPUT_UNKNOWN

続いて、INPUT 側のパケットを振り分けます。 ここで注意したいのですが、iptables は “eth0” と “eth0:0” を区別できません。 そこで、KNOWN と UNKNOWN の識別にはネットワーク・アドレスを使用します。

iptable -P INPUT DROP
iptable -A INPUT -i lo -j ACCEPT
iptable -A INPUT -i ppp0 -j INPUT_GLOBAL
iptable -A INPUT -s 172.16.100.0/24 -j INPUT_KNOWN
iptable -A INPUT -s 172.16.200.0/24 -j INPUT_UNKNOWN

OUTPUT についても同様です。

iptables -P OUTPUT DROP
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -o ppp0 -j OUTPUT_GLOBAL
iptables -A OUTPUT -d 172.16.100.0/24 -j OUTPUT_KNOWN
iptables -A OUTPUT -d 172.16.200.0/24 -j OUTPUT_UNKNOWN

これ以降、各ネットワーク・インタフェースを出入りするパケットは、それぞれ対応する INPUT_* チェーンと OUTPUT_* チェーンでフィルタリングします。

ネットワーク・インタフェースごとのフィルタリング・ルールを考えるにあたって、サービスの提供と利用の概念が重要になります。 提供しているサービスは新規通信の開始要求を受け入れなければなりませんが、利用しているだけのものはこちら主導で通信を開始するのみです。 つまり、INPUT_* については以下のようにフィルタリング処理をおこなう必要があります。

1. 提供サービスの incoming はすべて受け入れる
2. 通信開始要求はすべて落とす
3. 利用サービスの incoming はすべて受け入れる

2 で通信開始要求を落としているので、3 にたどり着くものはすべて自分が開始した通信の応答パケットです。 逆に OUTPUT_* は以下のように設定します。

1. 利用サービスの outgoing はすべて受け入れる
2. 通信開始要求はすべて落とす
3. 提供サービスの outgoing はすべて受け入れる

INPUT_* とは「利用 / 提供」が逆になっています。 このあたりは直感的には理解しにくいかもしれないので、具体的な通信開始時のパケットのやりとりを想像してみてください。

ここまで漠然と「通信開始要求」と書きましたが、TCP の SYN だけを指すわけではありません。 UDP や ICMP でもまとまりとして意味のある一連の通信が発生します。 その一連のパケットの一番最初のものを「通信開始要求」と呼んでいます。 iptable ではステートフル・パケット・フィルタリングが可能なので、通信開始要求に該当するパケットにマッチするルールを記述可能です。

例として、GLOBAL のネットワークに HTTP (tcp/80) / HTTPS (tcp/443) を提供し、DNS (udp/53) を利用する場合のフィルタリング・ルールを挙げます。

iptables -A INPUT_GLOBAL -p tcp --dport 80 -j ACCEPT
iptables -A INPUT_GLOBAL -p tcp --dport 443 -j ACCEPT
iptables -A INPUT_GLOBAL -m conntrack \
! --ctstate ESTABLISHED -j DROP
iptables -A INPUT_GLOBAL -p udp --dport 53 -j ACCEPT

iptables -A OUTPUT_GLOBAL -p udp --sport 53 -j ACCEPT
iptables -A OUTPUT_GLOBAL -m conntrack
! --ctstate ESTABLISHED -j DROP
iptables -A OUTPUT_GLOBAL -p tcp --sport 80 -j ACCEPT
iptables -A OUTPUT_GLOBAL -p tcp --sport 443 -j ACCEPT

FORWARD は以下のようなポリシーを設定します。

• TCP のみ許可し、UDP / ICMP は FORWARD しない
• KNOWN=>GLOBAL / UNKNOWN=>GLOBAL の通信は特に制限しない
• GLOBAL=>KNOWN / GLOBAL=>UNKNOWN の通信開始要求はすべて落とす
• KNOWN<=>UNKNOWN の通信はすべて落とす

以上をフィルタリング・ルールに翻訳すると以下のようになります。

iptables -A FORWARD ! -p tcp -j DROP
iptables -A FORWARD -s 172.16.100.0/24 -o ppp0 -j ACCEPT
iptables -A FORWARD -s 172.16.200.0/24 -o ppp0 -j ACCEPT
iptables -A FORWARD -d 172.16.100.0/24 -i ppp0 \
-m conntrack --ctstate ESTABLISHED -j ACCEPT
iptables -A FORWARD -d 172.16.200.0/24 -i ppp0 \
-m conntrack --ctstate ESTABLISHED -j ACCEPT
iptables -P FORWARD DROP

“-P”はデフォルト・ポリシーで、いずれにもマッチしなかった場合に適用されるターゲットを指定します。 ビルトイン・チェーンでのみ設定可能です。

今回の環境では、グローバル IP アドレスを持つのは ppp0 だけで、他はすべてプライベート・アドレスを使用しています。 これでは、Linux Box 以外はインターネットに出てゆかれないので、NAPT を適用します。 NAPT はひとつのグローバル IP アドレスを複数のマシンで共用するためのしくみで、TCP / UDP のポートごとに各マシンに割り当てることが出来ます。 Linux Kernel で実装される NAPT は “IP Masquerade” と呼ばれています。

IP Masuquerade の設定は nat テーブルの POSTROUTING チェーンにて行います。

iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -A POSTROUTING -s 172.16.100.0/24 \
-o ppp0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 172.16.200.0/24 \
-o ppp0 -j MASQUERADE

iptables ではターゲット “LOG” を利用することで syslog にログを残すことが出来ます。 特に多いのが、DROP するパケットをログに残しておきたいというニーズだと考えられます。 これを実現するためには「ログに記録して破棄」をおこなうユーザー定義チェーンを用意すると便利です。

iptables -N LOGGED_DROP
iptables -A LOGGED_DROP -j LOG
iptables -A LOGGED_DROP -j DROP

iptables で設定するルール・ベースのフィルタリング以外にも、Linux Kernel のパラメータも幾つか設定したほうが良いです。

ICMP echo のブロードキャストを無視します。 ブロードキャストの ICMP echo メッセージを許可すると、ネットワーク上で有効な IP アドレスを一覧される恐れがあります。

他のマシンが ICMP ブロードキャスト・メッセージに不正に反応した場合でも、その旨をログには残しません（デフォルトでは warning が出力される）。 これは直接セキュリティの向上には寄与しませんが、ログが読みやすくなります。

以下は NIC ごとに設定します。 どちらも、man-in-the-middle attack を防止するための設定です。

for i in /proc/sys/net/ipv4/conf/* ; do
  ## Ignore Source Routed Packet
  echo 0 > ${i}/accept_source_route
  ## Ignore ICMP Redirect
  echo 0 > ${i}/accept_redirects
done

その他の設定項目については以下などを参照ください。

• Linux Advanced Routing & Traffic Control HOWTO : Chapter 13. カーネルのネットワークパラメータ

Linux のディストリビューションや設定によっては、フォワードが無効になっている場合があります。 この場合は Linux Box がルーターとして動作することができません。 以下のように IP forwarding を有効にします。

以上のようなことを考慮しつつ、まとめられる部分は関数にしてくくりだしたりしました。 最終的に出来上がったスクリプトは以下のようになります。 （セキュリティ上、実環境で使っているものを少し改変してあります）

• reftables

今回は dhcp と組み合わせて未登録 PC を隔離するという特殊な設定でしたが、フィルタリングの基本的な考え方は再利用が可能な筈です。 特に上で紹介したチュートリアルを読んだ上で、それぞれの環境に合ったフィルタリング・ルールを考えてみてください。

• 早稲田大学と京都大学が「連携協力に関する基本協定」を締結
• 早稲田大学と連携協力に関する基本協定を締結

京都大学と早稲田大学の共同ブランドで開発をし、黄桜酒造株式会社が醸造を行ったビールです。 以前 KIRIN が古代ビールの復元プロジェクトを行いましたが、壁画からビールの製法を割り出したのが早稲田大学の吉村作治教授で、古代小麦を提供したのが京都大学だったというところが共同ブランドの発端のようですね。

黄桜酒造の直営店や両大学の学食 / 売店など、限られた場所でしか販売されていないものなのですが、ありがたいことに友人が入手してくれました。 感謝感謝！！

小麦ならではの豊かな泡立ちと白濁。 爽やかな酸味が、この蒸し暑い夕方に飲むのによく合います。 今回の “WHITE NILE” は残念ながら原料も製法も古代のものではなく、デュラム小麦を現代の製法で醸造したものです。 来年の夏に発売されるというエンマー小麦を使用したビールにも期待です。

一時期はやった、ステレオグラムを自分で作ることが出来ます。

• 3D Stereogram - flash-gear.com

やりすぎて酔った……。

さて、サッカーW杯予選、日本 vs ブラジルがそろそろ始まりそうです。 明日は仕事なのになぜかまだ起きているわけです。

ところで、この試合の舞台であるドルトムントですが、実はドイツで一番ビールの生産量が多い都市です。

• ドルトムント - Wikipedia

この都市の名前を冠したビア・スタイルもあります。

• ビアスタイル・ガイドライン カテゴリーD - 日本地ビール協会 (JCBA)

かのマイケル･ジャクソンによると、YEBISU はドルトムンダーにカテゴライズされるとか。 先ほどからテレビで「ドルトムント」「ドルトムント」と連呼されると、どうもビールが飲みたくなるわけです。 夜更かしだけならまだしも、ここでビールを飲んだら明日は休まなければならなくなるので必至で自制です。

さて、おとなしく試合を見るか。

• Nippon Craftbeer Festival 2006

まだ詳細は発表されていないようですが、時間と場所は確定っぽい。 「メーカー」ではなく「ブルワー」が主体となるそうです。

09/17 (Sun) 12:00-17:00。場所は “すみだリバーサイドホール”、 アサヒビール吾妻橋ビルの隣です。 おそらく前売入場券のみと思われます。

• The Beer & Pub - 雑誌大人組

The Beer & Pub の Vol.5 が先日 06/20 (Tue) に発売されました。 今号は新橋特集。 オーセンティックなバーから、提灯のぶら下がった立ち飲み屋まで幅広く取り上げられています。 あの「ビアライゼ」も紹介されています。 毎号「ここいきたい！」というお店がたくさんあるのだけれど、なかなか足を運べずにバックログばかりがたまってゆきます。 悔しい。

他にも記事は色々ありますが、やはり季節柄か夏に向けた企画が多いですね。 「夏はビールと野球でしょ！」とか（サッカーW杯の時期なのに！）、「夏は、爽やか小麦ビールで乾杯！！」とか。 後者は田村功氏の記事。 さすが、ビールの製法を踏まえた解説は素敵です。

さすがに5冊目ともなるとスポンサーもついてきたようで色のついた記事もあり、知名度もそこそこ上がったのか広告も増えています。 あまりそればっかりになっても嫌だけれど、安定した基盤が出来上がれば雑誌自体が長続きするだろうから良し。

山下書店 渋谷南口店にて購入。 このお店は24時間営業なので、仕事が遅くなっても買い物ができて便利です。 品揃えもなかなか。 The Beer & Pub なんてマニアックな雑誌を置いていることからもうかがえます。

Vol.6 は 09/20 発売予定。

• ニュースリリース - SUNTORY

ある意味定番。 SUNTORY の秋季限定発泡酒「秋生」です。 ロースと麦芽を謳っているのは昨年からなのでさほど目新しくはないですが、アルコール度数 6.5% はちょっと注目ですね。 ただ、なぜか “爽快な後味” を目指しているのは “秋” というキーワードを考えるとどうなんでしょうね。

08/22 (Tue) 発売予定。

• ニュースリリース - KIRIN
• 商品概要 - KIRIN

今年ももうこんな季節ですか。 KIRIN の定番、秋季限定ビール「秋味」が発表されました。 今年もやっぱり“麦芽1.3倍”を売り文句にしていますね。 昨年から副原料を排したのですが、今年はどうくるかな？ 楽しみです。

08/23 (Wed) 発売予定。

ここ何年か、ビア・フェスティバルとほぼ同時期に開催されていた「地ビールを楽しむ会」。 今年はなかなかアナウンスがないので心配していたのですが、先ほどチェックしたらこのような記述が。

• 全国地ビール醸造者協議会

あらー。 まだ未定ですか。 それなりに色々な人たち（特にブルワーの皆さん）が関係するイベントだけに、現時点で未定というのは少々危うい印象です。 今年はナシかな？ 残念。

• BECK'S

ドイツビール。 近所のコンビニで。 W杯関連？

Dell PowerEdge SC430 に CentOS4.3 をインストールしました。 その後、何度かインストールし直したりしていじくっていたのですが、そろそろ本格的にセットアップを開始しようかと思います。

このマシンの役目は、現在のルーター兼Firewall兼Webサーバー兼メールサーバー兼ネームサーバー etc マシンのリプレース。 直接インターネットに接続することになるので、パッケージの最新状況を常に把握しておくことは必須です。 yum - Yellowdog Updater Modified を使用して、ネットワーク越しに最新パッケージを取得することにします。

最初に、そのパッケージを本当に信頼してよいのかを確認するための PGP キーをインポートします。 yum は更新状況のチェック / 取得を行いますが、最終的なパッケージ管理は RPM が行います。 以下のように rpm に PGP キーを読み込ませましょう。

続いて、更新の確認を行います。

ズラリとパッケージの更新が一覧されたと思います。 以下のようにするとダウンロードして更新が適用されます。

このように、yum によりパッケージ更新の追跡 / 適用が可能になります。 他にも機能があり、ネットワーク越しにパッケージの追加も可能です。

このときに、いちいち Web に出て行くのも遅くて面倒です。 更新分は常に外にチェックしに行くのは仕方ありませんが、ベース・インストールイメージは既にダウンロードしてあるので（参照）、これを利用しないともったいない。 そこで、勝手に yum のレポジトリを立ててしまいます。 CentOS ディレクトリに加えて、headers ディレクトリと repodata ディレクトリも Disk1 からコピーして以下のような配置にします。

• /tmp
  • /CentOS
    • /4.3
      • /CentOS
        • /base
        • /RPMS
      • /headers
      • /repodata

これに http://example.com/CentOS でアクセスできるように Web サーバーを設定します。 最後に /etc/yum.repos.d/CentOS-Base.repo ファイルを以下のように変更します。

[base]
name=CentOS-$releasever - Base
baseurl=http://example.com/CentOS/4.3/
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-centos4
（省略）

以上で、base に関しては LAN 内だけで完結できるようになりました。 パッケージの追加 / 削除が早くて素敵です。 もちろん、更新があるものについてはきちんと最新版を持ってきてくれます。

最後に、パッケージ更新の有無を定期的にチェックするよう設定します。 yum をデーモンとして起動しておけば定期的に更新をチェックしに行き、更新の適用も行ってくれるのですが、サーバーマシンでそれもちょっと気持ち悪い。 更新の適用は手動で行いたいので、あくまでもチェックだけを行うスクリプトを作成します。

#!/bin/sh

ADMINMAIL=admin-mobile@example.com
SUBJECT="yum find updated package(s) at `hostname`"

# yum returns status code 0 when there is no updates
yum check-update > /dev/null 2>&1

if [ $? != 0 ]; then
  yum check-update | mail -s "${SUBJECT}" ${ADMINMAIL}
fi

これを crontab に設定しておけば、定期的に更新をチェックして、更新が存在する場合はメールを送信します。

• GUINNESS Foreign Extra

自宅にて。

Dell PowerEdge SC430 を購入したことにより、とうとう我が家にも GbE 対応機種が登場したことになります。 しかし、NIC だけが GbE に対応しても、hub やケーブルが対応していなければ意味がありません。 宝の持ち腐れ。 もったいない。 というわけで、これらを購入して LAN を GbE 化しました。

• HUB : corega CG-SW05GTV2B
• NIC : BUFFALO LGY-PCI-GT

LGY-PCI-GT は、メインマシン用。 残念ながらメインマシンは 32bit 33MHz の PCI v.2.2 にしか対応していません。 32bit 33MHz の理論上の帯域は 132MByte/sec となります。 GbE はバイト換算で 125MByte/sec。 数字は足りているように見えますが、諸々考えると心許ないですな。 でも 100BASE-TX よりは早くなるだろうということで、メインマシンも GbE 化します。

“GbE” と漠然と書いていますが、正確には 1000BASE-T なので Cat.5e のケーブルが必要となります。 しかし、生憎これまでは 100BASE-TX を使っていたので手持ちのケーブルはすべて Cat.5。 これも買い足さなければ。 というわけでお買い物へ。 現時点での主流は Cat.6 なのでわざわざ Cat.5e を探して買う必要もありません。 価格差もそれほどないのでここは素直に Cat.6 で。 それにしても、1000BASE-T 対応の NIC が2,000円を切ってるなんて驚き。

さて、勢いで購入したのは良いけれど果たしてどれだけネットワーク性能が向上したのかが気になるところです。 パフォーマンス測定を行ってみましょう。

今回はスループットを指標にします。 ネットワークのスループットを測定するツールは幾つかありますが、Windows でも Linux でも動くことが必要な条件なので ttcp を選択。

• ttcp

Windows 用は cygwin に含まれているのでそれをインストール。 Linux 用は上記サイトからソースを入手して gcc でコンパイル。

警告が出ますが、無視して大丈夫なようです。 コマンド一発のシンプルなツールですが、思いのほかいろいろな機能があります。 今回は TCP と UDP の場合をそれぞれ計測します。 まず片側で ttcp を -r オプション付きで起動し、続いてもう一方で -t オプション付きで起動します。以下は UDP の場合の例。TCP の場合は“-u”を除く。

今回はこれに加えてデータ量を指定する -l -n を使い、600,000,000byte の場合を計測しました。

ttcp を使うと理想的な状態でのネットワークの性能は判断できますが、もっと重要なのは普段の作業効率がどれだけ向上するかってこと。 プロトコルの特性やエンコーディングなどによるオーバーヘッド、ネットワーク以外のリソースによるボトルネックなど色々な要素が絡むので、実際の作業に近い環境で測定することにします。 帯域を多く使う作業で真っ先に思い浮かぶのがファイルのやりとり。 そこで、HTTP と SMB（Windows のファイル共有）も併せて測定しました。

計測には二台のPCを使用し、片側からもう一方へデータを送出します。 片側の NIC は常に BCM95751 に固定し、もう一方の NIC を替えて計測しました。 結果はこんな感じになりました。 単位は Mbps です。

HTTP と SMB は 630MB 強のファイルをやりとりしました。 HTTP の 408.204Mbps という数字は、このファイルをダウンロードするのに 13 秒程度で完了することを意味します。 CD-ROM 一枚分がほんの十数秒。 早いねー。 ttcp による計測だけではなく、HTTP や SMB もこれだけスループットが向上しているのであれば、 GbE を導入した価値は十分にあるといえます。

今朝、目覚ましがわりのテレビをつけたまま、会社に行く準備をしていたら、

「オオグロ マキが……」

おー、懐かしい名前。 そうそう、あそこの石山のパン屋の娘さんね。

と思ったら、何のことはない。 サッカーのニュースでした。

こっそり検索してみたら、本人も既に気付いてるのか～。 なんか今更で悔しい。

• 大黒摩季「大黒、巻、熱くなれ」 - nikkansports.com

• 目蒲線（現：目黒線）目黒駅付近～洗足駅付近間立体交差事業 ７月２日(日)、目黒線不動前駅～洗足駅間の約２．４㎞を地下化し、１６カ所の踏切を解消します ９月下旬（予定）に目黒線で急行運転を開始 (PDF)

ぼくが日頃通勤に使用している東急目黒線に、今年の九月から急行が導入されるようです。 また、不動前～洗足間の地下化も行われる模様。 うーん、どうもなー。

まず急行導入なのだけれど、

• 多少早く着くけれど大混雑の急行
• すいているけれど急行待ちにイライラする普通

という二極化が目に見えています。 通勤のための乗車時間が20分程度だったぼくには殆ど恩恵がなさそう。

地下化もどうも好きになれない。 景色が見えなくなるじゃないか。 まー、都市部を走る電車に車窓の風景を求めちゃいけなくて、沿線に与える影響（騒音 / 踏み切りによる渋滞）を優先しなければならないってことは十分承知。 でもなー。 通勤がつまらなくなること請け合い。

引越すか。

合格しました。

• テクニカルエンジニア（情報セキュリティ）試験(SV)

本日が合格発表でした。 いつの間にやら、点数も Web で照会できるように。 時代は進んでいた。

全受験者のスコア分布 (PDF) も参照できます。 なんと、午前問題は上位86名に食い込んでいる模様。 うーむ、昔取った杵柄。 ありがとう第一種、ありがとうネスペ。

もっと詳しい統計情報も発表されている。

• 情報処理技術者試験統計資料 平成18年度 春期試験 全試験区分版 (PDF)

この資料によると、平成18年春期の「テクニカルエンジニア（情報セキュリティ）」は合格率が6.8%、合格者数が1,227名。 思ったよりも狭き門だった様子です。

この統計情報とスコア分布を突き合わせて詳しく調べてみると合格ラインが見えてきます。 合格者数が1,227名に対し、午後II試験の600点～800点の採点対象人数合計が1,227名。 また、午後II試験の受験者総数2,305名に対し、午後I試験の600点～800点の採点対象人数合計が2,310名。 同じく、午後I試験の受験者総数は8,753名に対して午前試験の600点～800点の採点対象人数合計が8,903名。 多少の誤差はあるものの、600点が合格ラインと考えてほぼ間違いないでしょうね。

それ以外にも、この統計資料には面白いデータが色々と載っています。

たとえば「経験年数別一覧表」。 これは、申込み時のアンケートと突き合わせたものだと思うのだけれど、何の経験年数を訊かれたかは失念しました。 ただ、どの試験区分にも共通して言えるのが「経験年数が長いからといって合格率が高いわけではない」ということ。 「無記入」は除いて、だいたい3年から10年のあたりにピークがあります。 プロジェクトマネージャ試験などはまた違った傾向になるのではないかとは思いますが、春期については年の功が利きにくいようです。

「従業員数別一覧表」にも面白い傾向があって、真ん中がくぼんで両端があがるのが典型パターンです。 つまり、小さくても優秀な技術者を抱えている、もしくは大規模で優秀なエンジニアも一定数いる企業。 しかし、その間に挟まれた中規模では他よりも技術者が育たないんでしょうかね。 もしくは、中規模あたりの技術者のうち秀でた方々は資格試験を受ける暇なんてない、という仮説も浮かびます。 業務に必須ではないですし実務に直接役立つ資格ではないので、資格の箔が利かなければ受けるインセンティブは低いでしょうしね。

「在学中の学校等一覧表」は、傾向として捉えられる切り口は見つからないけれど所々興味深い箇所が。 小中学生でテクニカルエンジニア（システム監査）を受けてるスゴイやつがいたり（不合格）、情報系大学院に在席していながら何故か初級シスアド受けてみたり（就職対策とか？ いや、それも別にいいんだけどさ、なんかなー）。

「年齢別 応募者・合格者構成比（グラフ）」を見ると、試験区分ごとの年齢分布傾向が大づかみできて面白いです。 区分によってはシニア寄りの方々が多く受けていたりするし、基本情報や初級シスアドは20代前半より小さい側に極端に偏っているのも見て取れます。 区分の特徴が出ていて面白いですな。 併せて応募者と合格者の平均年齢も載っているのですが、驚いたことにひとつとして「合格者の平均年齢＞応募者の平均年齢」となっている区分がありません。 つまり、合格者の分布は応募者の分布よりも若い側に寄っているということです。 もっと身も蓋もない言い方をすると、若いほうが合格しやすい。 ぼくは今はどちらかというと “若い側” にいる（と思っている）のだけれど、この傾向は今から肝に銘じておこう。

というわけで、4つめの情報処理技術者合格を手にしました。 今後はこれをどう実務に落とし込むかだな。

PowerEdge SC430 を購入したので、久し振りに Linux をインストールしてみました。

これまでは Fedora Core を使っていたのだけれど、アップデートの早さに追従するのはなかなか骨が折れました。 そこで今回は、RHEL から派生した（一応）エンタープライズ向けのディストリビューションである CentOS を使ってみることにしました。

• www.centos.org

CentOS は "The Community ENTerprise Operationg System" から名付けられています。 中身はRedhat 社が公開しているソースコード (SRPM) からバイナリを構築したもので、差分は Redhat 社その他が権利を保有している部分（ロゴや商用パッケージ）の有無となります。 Fedora Core とは異なり、リリース・スケジュールは基本的に RHEL に準じるので安定したパッケージ・マネジメントが期待できます。 サーバーマシンであんなにボコボコとアップデートがかかるのは正直怖い。 あるアップデートが 2,3 日で上書きされたりするしね。

もちろん、Fedora Core の意義を否定するものではなくて、あくまでも「サーバー・マシンとして使うのなら」ということ。 もう一台の SC430 にインストールするにはやぶさかではない。 というかむしろ入れて遊びたい。 そのための二台目です。

毎度のことながら、インストールのために CD-ROM を焼くのが嫌いなのでネットワーク経由でインストールすることにします。 ところが！ CentOS 4.3 は FD からのインストーラ起動が行えません。 ブート・イメージだけで 6.0MB あります。 FD に入らない……。 確か Fedora Core 3 からは既に FD からのインストールは棄てられてたんだよな。 仕方がないので一枚 (Disk1) だけ CD-ROM を焼き、そこからブートしてネットワーク・インストールを行いました。

以下手順。

ここでの手順は、同一の LAN 内に充分なディスク・スペースを持った Linux サーバーが存在していることが前提です。 自前で Linux サーバーを用意できない場合はインターネット経由でどこかのサーバーからファイルを取得してください。 手順も一部変化しますのでご注意ください（“2～4枚目のCD-ROMは不要”など）。 もしかすると、NTFS の Windows 2000 に Apache をインストールした場合も HTTP 経由のインストールが可能かもしれません。

適当なミラーから CentOS 4.3 の ISO イメージを入手します。

• isoredirect.centos.org

PowerEdge SC430 は Intel Pentium D 搭載なので、アーキテクチャは x86_64 を選びます。 必要なイメージは全部で4つです。

• CentOS-4.3-x86_64-bin1of4.iso
• CentOS-4.3-x86_64-bin2of4.iso
• CentOS-4.3-x86_64-bin3of4.iso
• CentOS-4.3-x86_64-bin4of4.iso

適当な CD-R 書き込みソフトで一枚目 (CentOS-4.3-x86_64-bin1of4.iso) を焼いて起動ディスクを作成します。

既存のサーバー上で行う作業です。

4枚すべてのディスクの中身を、HTTP 経由でアクセスできるようにします。 まずは4つの ISO イメージに含まれる *.rpm ファイルを以下のディレクトリ構造に集約します。

• /tmp
  • /CentOS
    • /4.3
      • /CentOS
        • /base
        • /RPMS

 # mkdir -p /tmp/CentOS/4.3/CentOS
 # mkdir -p /tmp/CentOS/mount

 # mount -o loop -o ro CentOS-4.3-x86_64-bin1of4.iso \
 > /tmp/CentOS/mount
 # cp -r /tmp/CentOS/mount/CentOS/* \
 > /tmp/CentOS/4.3/CentOS/
 # umount /tmp/CentOS/mount

 # mount -o loop -o ro CentOS-4.3-x86_64-bin2of4.iso \
 > /tmp/CentOS/mount
 # cp -r /tmp/CentOS/mount/CentOS/RPM/* \
 > /tmp/CentOS/4.3/CentOS/RPM/
 # umount /tmp/CentOS/mount

 # mount -o loop -o ro CentOS-4.3-x86_64-bin3of4.iso \
 > /tmp/CentOS/mount
 # cp -r /tmp/CentOS/mount/CentOS/RPM/* \
 > /tmp/CentOS/4.3/CentOS/RPM/
 # umount /tmp/CentOS/mount

 # mount -o loop -o ro CentOS-4.3-x86_64-bin4of4.iso \
 > /tmp/CentOS/mount
 # cp -r /tmp/CentOS/mount/CentOS/RPM/* \
 > /tmp/CentOS/4.3/CentOS/RPM/
 # umount /tmp/CentOS/mount

続いて Apache の設定です。 httpd.conf に以下の行を追加し、"/CentOS" というパスでインストール・ファイルにアクセスできるように設定します。 インストーラでのポート番号の指定方法が怪しかったので、Well-known の80番を使用しました。

Alias /CentOS /tmp/CentOS

Apache を再起動しましょう。

 $ ./bin/apachectl restart

念のため、ブラウザからアクセスできることを確認しておくと安心です。

先ほど作成した起動CDを使用して、PowerEdge SC430 を起動します。 “boot:” というプロンプトが表示されたら、インストール・メソッドを指定できるように以下のとおり入力します。

“インストールに使用する言語” にはお好きなものを選択してください。 “キーボードの種類” ではお使いのものを。 （選択肢の例示で、ぼくが選んだものがある程度ばれてしまうわけですが）。

インストール方法の選択画面が表示されるので、“HTTP” を選択します。

NIC の設定です。 今回使用した環境では DHCP サーバーが立っているので「動的 IP 設定を使用する」を選択すれば自動的に NIC が設定されます。 そうでない環境では、有効な IP アドレス及びサブネット・マスクを指定しましょう。

インストール・メディアを取得する HTTP サーバーの指定です。 Web サイト名は IP アドレスでも構わないはずですが、Apache で Name based Virtual Host を使用している際は注意が必要です。 ディレクトリは “CentOS” ディレクトリのひとつ上を指定するので、今回は “/CentOS/4.3” と入力。

ここまでは昔懐かしのインタフェースですが、ここからはマウスも使えちゃうリッチなanaconda が立ち上がります。

以上の手順でネットワーク・インストールが行えます。 ここから先は一般的な Linux のインストール手順なのでエントリーを改めるか、割愛します。

• PowerEdge SC430 製品詳細
• オンライン広告限定ページ

Intel Pentium D 820 (2.8GHz / 2 core / 2x1MB L2 Cache / EM64T / 800MHz FSB) 搭載で29,980円（消費税込 / 送料込）という驚異的な低価格に惹かれてポチッとお買い上げ。 しかも「数量：2」。 だって、フェイルオーバーとかさせてみたいんだもの。

もう少し詳しいスペックは以下。

ちょっと気をつけたいのが対応メモリ。 この SC430 は ECC が必須です。 non-ECC のメモリは挿しても動作しないことが報告されています。 「ECC / non-ECC の混在がダメ」なのではなくて non-ECC がそもそもダメ。 メモリを増設する場合のコストが幾分高くなるのでこれは注意です。 とはいえ、これで30,000円切るんだもんな。 メイン・マシンとして使うには多少難ありだけれど、自宅サーバー / 開発機として使用するには充分。

ただ Dell のちょいとした難点は発送が遅いこと。 もう少し正確には「国際輸送」に時間がかかりすぎること。 荷物のステータスを Web から確認できるのだけれど、6/1にどこかの国を発った SC430 が日本に着いたのは 6/8 の夕方でした。 "Made in China" という文字がみえるので、日本海を渡るのに一週間もかかるってこと？

しっかし恐ろしいことに、同等スペックのものがたった二週間で22,980円まで下がっているんだよね。 何その値崩れ具合は。 ぼくの SC430 がぶらぶらと一週間も船旅を続けている間に何があったというのか。

• PIXUS - CANON

CANON PIXUS の、モナリザを使った CM。 印刷の精細さに驚くよりもまず、あの二つの絵に同時にフォーカスが合っていることに驚く。 やっぱり合成だよね？

先日、日本地ビール協会から届いた「I Love Beer 通信」にこんな記述がありました。

■■━━━━ ビアフェス2006in横浜 10月28日&29日
     　    　  ビアフェス2007in東京 6月16日&17日
　  　　　　　　 ビアフェス2007in大阪 8月上旬)━━■■

これまで横浜ではビア・フェスティバルは開催されていなかったんだけれど、今年は何かやるようです。 Oktoberfest ともまた時期が違うようですし、楽しみに待っておこう。

• REDBACK BEER

友人宅にて。

こないだ、友人がスピリチュアルな人の出演している番組を見て、

「霊とかは別にして、良いこと言ってると思うよ。あんたも見たほうがいいよ。」

なんて言ってきたもんだから、

「彼はね、自分が言っていることを演出する装置として“霊”というものを設定しているわけだよね。 あの類のやり口が響く層が一定数居ることを見込んで、その層に何かを伝えるのに効果的なやり方を彼なりに考えた結果が今の設定なんだろうね。 でも、かなりクセのある手段を選んでいるから、逆に全く響かない層があることも覚悟してると思うよ。 じゃないとむしろ頭悪い。 あの設定が万人に響くと思っているとしたらきっついね。 とにかく、ぼくは演出装置に “霊” を選んだという時点で胡散臭さと嫌悪感しか覚えないから、全く響かない層に属していると思うんだ。
だから『あんたも見たほうがいい』ってのは間違っているよ。」

なんてことを熱く語っていたら、

「だから嫌い」

といわれました。

• 水は答えを知っている - Hal Tasaki’s -<log p>

現在横浜では横浜フランス月間2006なるものを開催していて、フランスと関連するイベントが色々と催されているようです。 そのイベントのひとつにこんなものが。

• 「横浜フランス月間２００６」記念 みなとみらい線「日本大通り駅」博物館イベント 大佛次郎記念館歴史講座　地下のパリの歴史

以前なにかのテレビ番組でパリの地下道を目にしたのだけれど、確かにすごかった。 聴きに行きたいなー。 上記 Web ページによると申し込み期限は過ぎているのだけれど、どうも別ルートがありそうな雰囲気なんだよな。

講師の松井道昭氏はこんな著書があるようです。

• フランス第二帝政下のパリ都市改造

以前ヒトの眼の空間分解能について書いて、そのときは時間分解能についての記述は見つけられていませんでした。 先ほどふと思い立って検索してみたら、センサ関連の論文誌を発見しました。

• ヒトの触覚受容機構 ―力学･アナロジー･錯覚という視点から― 前野隆司氏 (PDF)

これは触覚について書かれたものなのですが、視覚についても軽く言及されていました。

ぼくが NTSC の周波数から導いた予想とそう違わないことは判りましたが、もう少し詳細を知りたいな。

• アサヒぐびなま。
• ニュースリリース

飲みました。 アサヒビールが 05/30 に発売した新ジャンルです。 確かに売り文句通り、飲みやすいことは飲みやすいですね。 非常に薄味で、新ジャンルにありがちだったへんなとげとげしいくさみも弱いです。 新ジャンルはこの路線が吉なのではないかな。 ただし、秋以降にどう売るかが大きなポイントになりそうですね。

さてさて、新ジャンルで出遅れているアサヒビールの起死回生の一打となるか。

• GSA

地底に潜り、スーパーカミオカンデを見学できるそうな。 行きたい！ カミオカンデへ至る神岡鉄道は今年一杯で廃線になるそうな。 こっちもまた興味深い。

実施は2006-07-15 と 2006-07-16 の両日。 申込みは往復はがきにて。 06/16 消印有効。

• サマーシュート＜生＞ サントリー
• 夏季限定発泡酒「サマーシュート〈生〉」新発売 - Suntory ニュースリリース

5/30 発売のサントリーの夏季限定発泡酒を遅れ馳せながら飲みました。

売り文句通り、炭酸は比較的高め。 味はかなりあっさりとしています。 冷やして一気に喉に流し込むのであれば、ありかもしれません。 口に留めちゃダメ。 チビチビ味わおうとすると、厳しいものがあります。 一杯目が勝負ですな。

• 東急ストア「創業５０周年記念企画」の開催について (PDF) - 東急ストアニュースリリース

東急ストアに寄ったら見慣れない缶ビールが。 東急ストア創業50周年限定醸造の「ジャーマンウィンド」というビールでした。 製造は SUNTORY。 SUNTORY のニュースリリースにはなかったから全く知りませんでした。 危うく逃すところだった。

非常にホップの効いたビール。 泡立ちもしっかりしているし、かなり華やかな香りのビールです。 そして、味ももちろんホッピーなんだけれど案外モルト風味も効いています。 おいしい。 偶然見つけてよかった。