仙石浩明の日記

2006年12月8日

ソフトウェア産業の究極の振興策 hatena_b

IPA (情報処理推進機構) のかたとお話しした。 優秀なソフトウェア技術者の成果をビジネスにつなげるための支援をするには、 どうしたらいいかヒアリングしたいとのこと。

ああ、この人もソフトウェアをモノと誤解している人なんだ。

ソフトウェア以外の分野、 たとえばバイオや新素材などでは 優れた発明・発見がビジネスに直結する。 真に有効なモノ (例えば新薬や新素材) の真に有効な製造方法が発明されれば、 あとは製造工場を建設するのに必要なカネがあればよい。 だから、資金援助を行なうことが即、その産業の振興につながる。

しかしながらソフトウェアはモノではない。 ソフトウェアには特殊な製造方法などなにもない。 あるソフトウェアを作るのに特殊な「知的財産」が必要、 などということはないのである。

確かに、ソフトウェアの分野にも一応「発明」と称するのものがあるが、 その「発明」が公開されなければ製造できないソフトウェアが果たしてあるだろうか? 「ソフトウェア特許」を認めるべきか否かについては様々な議論があるが、 ソフトウェアを他の分野と同列に扱うことはできない、 ということだけは確かであろう。

では、ソフトウェア産業の振興には何が必要なのか? なぜ日本のソフトウェア業界には (例えば Google のような) 破壊的なイノベーションが生まれないのか?

簡単である、ソフトウェアを作る優秀な技術者が足らないからである。 だから振興策も簡単で、 技術者をビジネスの現場に引き合わせればよい

と言ったら、IPA でも 未踏ソフトウェア創造事業で発掘した人材を、 ソフトウェアの販売会社と引き合わせている、 という答が返ってきた。

そんなことを言っているのではない!

未踏事業で開発したソフトウェアを販売会社に紹介すれば、 確かに興味を持つ会社は出てくるだろう。 実際に販売してくれるところも出てくるかも知れない。 でもそんなことをして高々数千本ソフトウェアを売ったところで何になる? せいぜい (すごくうまくいったとしても) 数憶円の売上にしかならないだろうし、 数千本といえど売れば開発者はサポートに忙殺されてしまう。 せっかく発掘した貴重な人材の使い道としては、 あまりにモッタイナイ使い方ではないか。

優秀な技術者をソフトウェア販売会社に引き合わせたって意味はない。
優秀な技術者を「ビジネスの現場」に引き合わせなければならない。
つまり、優秀な技術者がその能力を存分に発揮し、 その能力に見合う報酬を喜んで支払う「事業家」に引き合わせなければならない。

日本のソフトウェア産業がアメリカに負けっぱなしなのは、 優秀な技術者が日本にいないからだろうか?

否!!

優秀な技術者と、優秀な事業家が、出会っていないだけである。 日本にも、勢いのある IT ベンチャーは数多い。 ところがそうしたベンチャーに入社しようと思う優秀な技術者がどれだけいるのか? ほとんど全ての IT ベンチャーは優秀な技術者を渇望している。 その一方で、大企業の研究所には優秀な技術者がゴロゴロしている。 私は日立製作所の研究所に 8年間勤めたので痛感しているのだが、 私よりよっぽど優秀な人が、特に活躍するわけでもなくゴロゴロしている。 つまり凡人でもできるような仕事をして、 凡人と同レベルの給料をもらって満足しているのである。

もちろんお金が全てではないし、 優秀な人はすべからくその能力をフルに発揮して活躍しなければならない、 というものでもない。 自らの能力を披露することなく静かに暮すのも一つの生き方であろう。

しかし、優秀な技術者の大半が、大企業の奥底で眠っているのだとしたら...?
そして日本のソフトウェア産業を振興させたいと思うのなら...?
それなら有効な振興策は一つしかない。 唯一にして最も効果的な究極の振興策、それは...

大企業の一つをつぶして、死蔵していた優秀な人材を放出させることである。

Filed under: 技術と経営 — hiroaki_sengoku @ 13:18
2006年12月5日

チープ教育: 「無意味にポジティブ」のススメ hatena_b

KLab 社内には、社内専用の IRC サーバがあります。 IRC (Internet Relay Chat) つまり、 ネットワークリアルタイム会議システムです。 普通の IRC はインターネットに接続できれば、 誰でも使えるのですが、 KLab 社内 IRC は、KLab のイントラネットに接続できる人しか使えません (VPNワープを使って社外からもアクセスできます)。 だから社外秘な内容も流せますし、 社内ミーティングを IRC で済ませてしまうこともよくあります。

社内 IRC が真価を発揮するのは、 コンテンツ提供用の WWW サーバ システム (DSAS) の メンテナンス作業の時など、 多くの人がリアルタイムに状況 (メンテナンス作業の進捗状況) を 共有したいときです。 メンテナンス作業は、 コンテンツ提供サービスに悪影響を与えていないか確認しつつ 慎重に進める必要があるのですが、 それには実作業を行なう人と、 その作業をチェックする人、 そしてコンテンツ提供に悪影響が及んでいないか監視する人など、 沢山の人が進捗状況をリアルタイムに把握する必要があります。

関係者が全員同じフロアにいれば、 大声をあげるだけでも進行状況の「雰囲気」を共有できるでしょうが、 KLab の場合は東京、大阪、福岡のオフィスの他、 SOHO 形態で働いている人もいますし、 DSAS メンテナンスの場合はデータセンタ (東京二ヶ所と九州一ヶ所) にいる人とも 連係しなければなりません。 遠隔地の人と手軽に「雰囲気」を共有する手段として、 社内 IRC はとても便利です。

あまりに便利なので、 技術者の大半が常時 IRC サーバに「常駐」しているのですが、 こうなってくると計画的な作業の連絡用だけでなく、 技術者全員の横のつながりというか、 部署を超えて技術者同士が連係できる共有空間の役割を果たすようになります。 例えば昨晩も...

18:28 (sengoku`) チープ教育 http://cn.ce-lab.net/ja/toshi/archives/2006/08/post_75.html
18:29 (sengoku`) ↑これ、かなり本質をついてる気がするのですが、皆さんはどう思いますか?
18:30 (sengoku`) 私がはじめて出会った PC (当時の呼称はマイコン) は、とてもチープだったんで、自分で作ろう、という気が起きたけど、今の PC 見て、作ってみよう、と思う人はいないよねぇ..

チープ教育」を読んで、 ぜひみんなに紹介したいと思ったので、 とりあえず社内 IRC に投げてみたわけです。 ほどなく隣の部署の人から反応がありました。

18:34 (koura-h) 細部の作り込みに入ってしまうのって、それはそれで楽しいときもありますけど、苦痛になってしまうことも多いっす。。。
18:35 (koura-h) 制作環境における「チープさ」って、ありがたいと思うす。

続いて、協力会社の人からも...

18:39 (ktaka) ある意味、何でもそうだと
18:39 (ktaka) 思います。
18:40 (ktaka) 自動車でも、
18:40 (ktaka) 楽天のような商売でも
18:41 (ktaka) 物理学者が生物学に入っていって、DNAとかの研究が盛んになり始めた衣
18:41 (ktaka) 頃も
18:42 (ktaka) ショックレイがフェアチャイルド社(?)を始め、Intelができた頃も
18:42 (sengoku`) あはは
18:42 (ktaka) みんな始めは、
18:42 (ktaka) ある意味、やればできそうという感覚があったんでしょうね
18:43 (sengoku`) ですよね~
18:43 (sengoku`) 「へぼくても許される感」って重要ですね~

反応してない人も、この会話の流れを見てはいるわけで、 技術者同士、考え方を共有することはとても重要なことだと思います。 もちろん社内には情報共有の方法としてメーリングリストも多数あるのですが、 なんでも気楽に書込めるという敷居の低さで、 IRC のほうが勝っていると思います。

18:43 (uchikawa-) itronのコードでも弄ってみますか(秋月のボードで自力で動かすというのはやったことあります)
18:43 (sengoku`) 逆に言うと、へぼが許されないような雰囲気のとき、どうやって「無意味なポジティブさ」を学ぶか意識しないと、ってことですね。
18:44 (sengoku`) まあ、遠慮せずにどんどんやれ、ってことなんですけど、
18:44 (ktaka) 私は、そもそも、参入しないと言うのもありかな、と思っています
18:44 (sengoku`) なかなかポジティブになったことの無い人にそれをやれ、ってのは難しいのかもしれませんね。
18:45 (sengoku`) もちろん、参入しない、という選択肢があるときはそれでもいいんですが、
18:45 (ktaka) 高度に専門家されたことを大きな組織でやるよりも、
18:45 (sengoku`) コンピュータ技術者、って道を選択してしまった人に、いまさら他の道を探せ、ってのも酷でしょうから... ;-)
18:46 (ktaka) 一時代を築く可能性がある、チープなものに出会えれば。。。
18:46 (ktaka) でも
18:46 (ktaka) 一口にコンピューター技術者といっても、いろいろあって
18:47 (ktaka) 昔は、ボードの設計からできそう、だったのが、
18:48 (sengoku`) (いまでも、ちゃちな PC ならボードから設計できるんですけどね、実は)
18:48 (ktaka) 今は、Youtube見たいなの作れそう、っていうのがあるとおもいますので
18:49 (ktaka) おお、すごいですね~
18:49 (sengoku`) ようは、ポジティブになれるかどうかが、勝負を分けることになるんじゃないかと...
18:49 (ktaka) チープなフェーズにある、面白そうなものって言うのは、いろんなところにあるんではないかと
18:49 (sengoku`) まあ、そういう話は、
18:50 (katsumiD) ( つhttp://journal.mycom.co.jp/column/architecture/037/
18:50 (sengoku`) プログラマを目指すのに適した時代、適していない時代 https://www.gcd.org/blog/2006/07/83/ ってことに
18:50 (sengoku`) 続くのかな。
18:50 (katsumiD) ちなみに,
18:51 (katsumiD) 今だと CPU を作ろうと思った場合,FPGA とかで作れますが
18:51 (katsumiD) そういうことをしようと思った場合のハードルが,昔に比べて下がっている,と言うのもあるように思いますです
18:52 (ktaka) 確かにそうだと思います>適していない時代
18:52 (sengoku`) いや、あるんですが、ようはそれを自分でやろうという気持ちを起こせるかどうか、ってことだと思います。
18:52 (ktaka) 確かにそうだと思います>CPUを作るハードル
18:52 (sengoku`) 技術的な障壁は確実に下がってるんですが、心理的な障壁は、逆にあがってるかも知れませんねぇ
18:53 (katsumiD) なるほど

若干、会話が錯綜気味で読みにくくなってしまっていますが、 それが逆に、 考えがまとまっていなくてもとりあえず書いてしまえ、 という気楽さにつながっているのでしょう。 メールだと、論旨をはっきりさせて書かねば、という気持ちになりますから、 思ったことをそのままぶつけられる IRC のような場も必要だと思います。

ちなみに、会話に参加している 5人のうち、 4人は声の届く範囲にいたりする (^^;) のですが、 ひざ突き合わせて話そうとすると仕事を中断して集まらなければなりませんし、 大声を出すと会話に興味がない人に迷惑ですし、 URL を伝えるときなどは声よりチャットの方がむしろ便利ですし、 また、IRC だとログが残るので後で参照することもできます。

なお、「プログラマを目指すのに適した時代、適していない時代」に言及したのですが、 どちらかというと「ロングテール戦略が格差社会を生む: 必要は発明の母」のほうが話の流れに近かったかも知れません。 要は、不足感がないと何かをやろうという気力が出てこない、 ということが言いたかったわけです。

18:53 (uchikawa-) 昔だったら「自分で作ったほうが世の中にあるものよりいいものになる」だったですからね
18:54 (sengoku`) 世の中にもっといいものがある、からといって遠慮する必要はないんですけどねぇ、ほんとうは。
18:54 (katsumiD) でも,実は心理障壁を乗り越える人はいつの時代だって乗り越えるし,乗り越えない人はいつだって乗り越えない,というのも,
18:54 (katsumiD) http://www.chiaki.cc/Timpy/index.htm
18:54 (katsumiD) こういうサイトを見ていると思ったりもします
18:54 (katsumiD) (こういうのを見ると,むしょうに自分でも何かをしたくなり出します(^^
18:55 (sengoku`) ぜひぜひ
18:55 (katsumiD) ちなみに,今の時代だと,2足歩行ロボットとか,結構盛り上がってますよね
18:56 (katsumiD) ちょっと前は,2足歩行どころか,普通のロボットでも作る機運ってのは無かったですが
18:56 (ktaka) 私的には、やっぱり、WEBやネットワークがチープなフェーズにあるのではないかと思います
18:57 (katsumiD) 色んな製作記事とかキットが出始めたこととかもあって,アマチュアの人が一杯やってらっしゃいますね
18:57 (sengoku`) まあ、どんな分野でもいいんで、ぜひチャレンジして~と。

収拾がつかなくなってきたんで、ちょっと投げやりになっています > 私 (^^;)

18:57 (katsumiD) (^^
18:57 (ktaka) なるほど
18:57 (ktaka) >ロボット
18:57 (ktaka) 二足歩行のおもちゃ変えますもんね
18:57 (ktaka) 買えますもんね
18:58 (sengoku`) Web が普及して一番困ったことは、誰もが批評家になっちゃって、自分ではやろうとしなくなったことなのではないかと...
18:58 (ktaka) そうなんですか
18:59 (ktaka) 何でも自分でやる技術者の世界に、批評家が入り込んできたという意味ですか?
18:59 (sengoku`) なんでも web 見れば載ってるんで、
19:00 (sengoku`) 自分でやらずに、自分でやってるような気分になっちゃう
19:00 (sengoku`) 見るのとやるのとでは大違いなのに、たいてーの人は見るだけで満足しちゃうんじゃないかと...

うっかり「批評家」と言ってしまって意図が通じにくくなってしまいましたが、 誤解されてもすぐ補足説明できるのが IRC のいいところですね。 「自分で実行しないで他者の行為をあれこれ言う者」という意味で使ったのですが、 「批評家」ではなく「評論家」と表現すべきでした。

19:01 (katsumiD) あぁ,それはあるかもですねぇ・・・
19:01 (katsumiD) 変な事をしてる人は一杯いて,それをいろいろ満てるだけでお腹いっぱいになってるとか・・・
19:02 (sengoku`) そういう傾向はあるんじゃないかなぁ~
19:02 (sengoku`) すでにやってる人がいるから、わざわざ自分でやらなくても、って
19:03 (sengoku`) 思っちゃうんじゃないかなぁ
19:03 (sengoku`) やってみれば、新しい発見があるかもしれないのにね。
19:04 (koura-h) それは分かりますね>わざわざ自分で~
19:05 (koura-h) 何かしりごみするっていうのか、既に誰か手を付けてると後から追いかける意欲が薄れるというか。

ようやく思った通りの結論にたどり着きました (^^)。

19:08 (koura-h) 例えばCPANなんかで、「これ自分で作ったんだけど登録してみよー」とか思っても大抵既に誰かがのっけてたりして、そういうのに何個か当たってしまうとそのしりごみの気持ちが強まってしまうっすね。。。
19:11 (ktaka) なるほど
19:12 (ktaka) >CPAN
19:12 (koura-h) (って打ってたら仙石さんが帰られていったorz

あはは。

Filed under: 元CTO の日記,技術と経営,技術者の成長 — hiroaki_sengoku @ 09:00
2006年11月30日

迷惑メール送信者とのイタチごっこを終わらせるために (2) hatena_b

DNS逆引きできないメールサーバからのメールを拒否するサイトが増えはじめ、 その弊害を指摘する声が上がっているようだ。

reject_unknown_clientは迷惑メール対策としておすすめではない」から引用:

迷惑メール対策として reject_unknown_client を紹介しているページは 多数みつかるのだが、 その弊害の大きさにまで言及しているページはほとんどないことがわかる。 これはあまりよくない傾向だ。そこで、ある程度説明をまとめておくことにする。

逆に言うと、弊害をきちんと理解していれば、 DNS逆引きの結果を迷惑メール判定に用いることは受信側の判断だろう。 DNS逆引きができないホストからメールを送らざるを得ないサイトにとっては 釈然としないところもあるとは思うが、 受け取らない権利があるのもインターネットである。
DNS逆引き設定の無いメールサーバからのメールをspam扱い」から引用:

うーん、自宅は固定IPアドレスにしているので、 追加で月額1050円也を払えば逆引きぐらい設定してもらえるのだが、 きっかけがどうにも癪だなぁ。
元はといえばSPAMMERが悪いのだけれど、 拒否するサーバ側もちょっと乱暴な気がする。
...
悪貨が良貨を駆逐してはいかんよなぁ。
SPAM地獄に陥っているmail Server管理者の気持ちはわかるんだけど...。

「癪だなぁ」という気持ちはとてもよく理解できるのであるが、 「悪貨が良貨を駆逐」というのは...? 「悪貨」は SPAMMER を指すとして、 「良貨」は何を指すのだろう? 逆引きできないメールサーバって「良貨」なのだろうか? 他者と通信するホストは、 基本的には DNS 逆引きできたほうがいいと思うのだが...

性善説が通用した牧歌的なインターネットの黎明期ならいざ知らず、 通信相手はまず疑ってかからなければ手痛い目に会うのが (それがいいことかどうかはさておき) 現代のインターネットである。 通信相手の素性は可能な限り収拾しておきたいし、 できれば ssh や SSL認証のような認証を行なって、 通信相手が間違いなく意図した通りの相手であることを確認したい。

しかし残念ながらメール配送は、いまだ認証無しの通信が大多数を占める。 通信は相手あってのものだし、 特にメールは不特定多数からの通信を受付けなくては機能しない。 一方的に、 「認証無しの接続は受付けません」と主張したところで得るものはあまり無い。 だから完全な認証は棚上げせざるを得ないが、 不十分であっても通信相手の素性が分かる方法は総動員したいところだ。 そして、素性を調べる手段として DNS逆引きは、ある程度の合理性を持つ。
逆引き判定」から引用:

spam をたくさん送ってくる中国韓国あたりは そもそも逆引きを設定する習慣があまりないようで、 このチェックによってこれらの国からの spam を多数撃墜できるのは事実である。 しかしそれは逆引きを設定する習慣がない国と spam を送ってくる国がたまたま重なっているだけにすぎない。 spam を送ってくるホストはとうぜんまともな管理はされていないだろうが、 まともに管理されているホストに逆引きがないというのもふつうに存在する (何をもってまともとするかの定義も曖昧だが)。

「まともに管理されているホストに逆引きがないというのもふつうに存在する」 のは事実だと思うが、 「まともに管理している」ということを通信相手に伝える努力は すべきではないだろうか? 通信はお互いの協力があって初めて成り立つものであるから、 spammer と区別してもらうための努力もせずに、 spammer と一緒にするなと叫んでいるだけでは解決にならない。 もちろん、spammer と区別してもらう方法が DNS逆引きの設定だけであると 主張するつもりはない。 送信側と受信側、双方にとって最も合理的な判別法を選択していくべきであろう。

もし、逆引きを設定することは、 送信側にとってコストがかかる (例えば「追加で月額1050円也を払う」) ので採用したくない、 とお考えのかたがいたら、 そもそもなぜ迷惑メールが蔓延しているのか考えてみて頂きたい。

つまり、迷惑メールは際限無く増大しているのに、 なぜダイレクトメール (つまり宣伝目的で送られる郵便物) はそれほど増えないのか。 言うまでもなく郵便物は送信するのにコストがかかるからだ。 送信側と受信側のコスト負担がアンバランスだったことこそが、 迷惑メールがここまで社会問題化した最大の理由である。 送信側に応分の負担を求めること、 すなわち送信側に身の潔白 (つまり、まともに管理しているということ) を証明する コストを支払わせることこそが根本的な解決策となるのだと思う。

Filed under: システム構築・運用 — hiroaki_sengoku @ 07:24
2006年11月29日

stone 2.3c のバグ (select 版の make 方法)

stone 2.3c epoll 版 (つまり -DUSE_EPOLL をつけてコンパイル) において、 proxy 機能にバグを見つけた。 stone を http proxy として使用して、 同じセッション内で異なるホスト (IP アドレスが異なる) へ アクセスすると接続できずにタイムアウトする。 ブラウザで「再読み込み」操作を行なえば、 ブラウザが新規セッションを張るので接続できるようになる。

stone.c 2.2.4.7 にて修正済み。 同一セッションにて異なるホストへ接続しようとしたとき、 stone は旧ソケットをクローズして新しいソケットをオープンするのだが、 このとき EPOLL_CTL_ADD するのを忘れていた。 select 版では新ソケットで FD_SET するので問題はない。

なお、epoll 版は Linux カーネルおよび glibc にて epoll がサポートされていることが必要。 現在使われている Linux ディストリビューションの大半 (?) は、 いまだ EPOLLONESHOT をサポートしていないので、 epoll 版を make することはできず、 次のようなエラーになる:

% make linux-ssl
make TARGET=linux ssl_stone LIBS="-ldl"
make[1]: Entering directory `stone'
make FLAGS="-DUSE_POP -DUSE_SSL -I/usr/local/ssl/include " LIBS="-ldl -L/usr/local/ssl/lib -lssl -lcrypto" linux
make[2]: Entering directory `stone'
make FLAGS="-Wall -DCPP='\"/usr/bin/cpp -traditional\"' -DPTHREAD -DUNIX_DAEMON -DPRCTL -DSO_ORIGINAL_DST=80 -DUSE_EPOLL -DUSE_POP -DUSE_SSL -I/usr/local/ssl/include " LIBS="-lpthread -ldl -L/usr/local/ssl/lib -lssl -lcrypto" stone
make[3]: Entering directory `stone'
cc  -Wall -DCPP='"/usr/bin/cpp -traditional"' -DPTHREAD -DUNIX_DAEMON -DPRCTL -DSO_ORIGINAL_DST=80 -DUSE_EPOLL -DUSE_POP -DUSE_SSL -I/usr/local/ssl/include  -o stone stone.c -lpthread -ldl -L/usr/local/ssl/lib -lssl -lcrypto
stone.c: In function `healthCheck':
stone.c:1687: error: `EPOLLONESHOT' undeclared (first use in this function)
stone.c:1687: error: (Each undeclared identifier is reported only once
stone.c:1687: error: for each function it appears in.)
stone.c: In function `asyncConn':
stone.c:3517: error: `EPOLLONESHOT' undeclared (first use in this function)
stone.c: In function `getident':
stone.c:3703: error: `EPOLLONESHOT' undeclared (first use in this function)
stone.c: In function `proxyCommon':
stone.c:5054: error: `EPOLLONESHOT' undeclared (first use in this function)
stone.c: In function `proto2fdset':
stone.c:5699: error: `EPOLLONESHOT' undeclared (first use in this function)
stone.c: In function `doAcceptConnect':
stone.c:6277: error: `EPOLLONESHOT' undeclared (first use in this function)
stone.c: In function `asyncClose':
stone.c:6350: error: `EPOLLONESHOT' undeclared (first use in this function)
make[3]: *** [stone] Error 1
make[3]: Leaving directory `stone'
make[2]: *** [linux] Error 2
make[2]: Leaving directory `stone'
make[1]: *** [ssl_stone] Error 2
make[1]: Leaving directory `stone'
make: *** [linux-ssl] Error 2

このようなエラーが出る場合は、 Makefile にて 「-DUSE_EPOLL」 を削除して make することにより、 select 版を作成できる。

% diff -u Makefile.org Makefile
--- Makefile.org        Tue Nov 28 13:52:54 2006
+++ Makefile        Tue Nov 28 13:52:09 2006
@@ -95,7 +95,7 @@
         $(MAKE) FLAGS="-DNT_SERVICE $(FLAGS) $(POP_FLAGS) $(SSL_FLAGS)" LIBS="$(LIBS) $(SSL_LIBS) $(SVC_LIBS) -ladvapi32 -luser32 -lgdi32 -lshell32 -lkernel32" $(TARGET)
 
 linux:
-        $(MAKE) FLAGS="-Wall -DCPP='\"/usr/bin/cpp -traditional\"' -DPTHREAD -DUNIX_DAEMON -DPRCTL -DSO_ORIGINAL_DST=80 -DUSE_EPOLL $(FLAGS)" LIBS="-lpthread $(LIBS)" stone
+        $(MAKE) FLAGS="-Wall -DCPP='\"/usr/bin/cpp -traditional\"' -DPTHREAD -DUNIX_DAEMON -DPRCTL -DSO_ORIGINAL_DST=80 $(FLAGS)" LIBS="-lpthread $(LIBS)" stone
 
 linux-pop:
         $(MAKE) TARGET=linux pop_stone

このようなパッチを Makefile にあてた後、make すればよい。

% make linux-ssl
make TARGET=linux ssl_stone LIBS="-ldl"
make[1]: Entering directory `stone'
make FLAGS="-DUSE_POP -DUSE_SSL -I/usr/local/ssl/include " LIBS="-ldl -L/usr/local/ssl/lib -lssl -lcrypto" linux
make[2]: Entering directory `stone'
make FLAGS="-Wall -DCPP='\"/usr/bin/cpp -traditional\"' -DPTHREAD -DUNIX_DAEMON -DPRCTL -DSO_ORIGINAL_DST=80 -DUSE_POP -DUSE_SSL -I/usr/local/ssl/include " LIBS="-lpthread -ldl -L/usr/local/ssl/lib -lssl -lcrypto" stone
make[3]: Entering directory `stone'
cc  -Wall -DCPP='"/usr/bin/cpp -traditional"' -DPTHREAD -DUNIX_DAEMON -DPRCTL -DSO_ORIGINAL_DST=80 -DUSE_POP -DUSE_SSL -I/usr/local/ssl/include  -o stone stone.c -lpthread -ldl -L/usr/local/ssl/lib -lssl -lcrypto
make[3]: Leaving directory `stone'
make[2]: Leaving directory `stone'
make[1]: Leaving directory `stone'
Filed under: stone 開発日記 — hiroaki_sengoku @ 06:37
2006年11月27日

作ること と 売ること (未踏集会 ESPer2006 秋の陣) hatena_b

先週末、 未踏ソフトウェア創造事業の集会 ESPer2006 秋の陣 でプレゼンしました。 KLab(株)の黎明期に、いかに未踏事業の支援が助けになったか、 そして 5 人でスタートした KLab が 160人を超える会社に発展した過程を紹介しつつ、 私がそこから学んだことなどをお話ししました。 これからベンチャーを立ち上げよう、 そして発展させようとしている技術者の方々の参考になれば幸いです。

使ったスライドを公開します。 25分の持ち時間なので、スライド 21ページくらいは話せるかなと思っていたら、 調子に乗って喋りすぎ、大幅に時間を超過してしまいました。 ゴメンナサイ。 後半かなり早口になってしまい、一番言いたかった 「技術者の地位を向上させるには、 技術者以外の視点にも立ってみて、 技術者自身が視野を広げていかなければならない」 という主旨が、果たしてどこまで伝えられたかちょっと不安に思っています。

私のプレゼン手法は OHP (OverHead Projector) 時代に身につけたもので 1ページあたり 1分以上話すのが普通なのでした。 もう少し内容を絞り込めばよかったと反省しております (これでも、イイタイコトを大幅に削って 流れを単純化したつもりだったのですが... ^^;)。 でも、私の 21ページというのはかなり少ない方で、 多い人だと 100ページを超えていましたね (25分間なのに!)。 OHP 時代は、1ページ数秒しか見せないなんてことはありえなかったわけで、 いろいろなプレゼン手法があるものだと、とても参考になりました。

また懇親会や二次会 (残念ながら三次会は終電が気になってしまって参加できませんでしたが) で、沢山の方々とお話しすることができて とても有意義な時間をすごすことができました。 このような場を準備運営してくださった事務局の方々に感謝します。 ありがとうございました & お疲れ様でした。

スライドを PDF 化したものと、 FlashPaper を使って Flash 化したもの ↓ を公開します。

More...
Filed under: 元CTO の日記,技術と経営 — hiroaki_sengoku @ 08:48
2006年11月14日

未踏ソフトウェア創造事業の集会 ESPer2006 秋の陣 でプレゼンします

ご存じの方も多いと思いますが、 情報処理推進機構(IPA)が実施している個人支援事業に、 未踏ソフトウェア創造事業 (Exploratory Software Project) があります。 私自身、第一回め(2000年)に 「携帯電話用アプレット開発ツール」を採択いただき、 超優秀な学生さん二人と共に、 Java と文法レベルで互換のコンパイラ&VM (Virtual Machine) を開発しました。 テーマ概要から引用:

携帯電話上で走らせるJavaプログラムは, サイズが小さいことが第一の条件である. しかし,Javaは元々 PCなど比較的リソース制限が緩いコンピュータ上で走らせることを想定していたため, 小さいプログラムを書くには特殊なテクニックが必要となる. つまり,一般のプログラマには敷居が高すぎ, このままでは携帯電話のJavaコンテンツの発展を阻害する恐れがある.

そこで,携帯電話上で動作するプログラムを開発するための コンパイラなどの開発を提案する. このコンパイラが生成するプログラムは, 同機能を持つ携帯電話上の通常のJavaプログラムの 1/10以下のサイズ (目標値) であり, 現状の携帯電話網においても無理なくダウンロードすることができる.

携帯電話がどんどん高機能化し、 当時のPC よりよほどパワフルになってしまった現在から見ると、 遠い昔の話のようです(^^;)。 採択・支援いただいた PM (プロジェクトマネージャ) の指摘:

現地ヒアリングのときに聞いた携帯電話上のJavaリソース制限の 技術的あるいは政策的な厳しさ (例えば,一つのiアプリのコードは10Kバイト以下に抑えないといけない) は, マウスイヤーの今日どれくらいの期間意味をもつのだろうか. このプロジェクトはこういったことに若干振り回されてしまったような印象もあるが, 得られたKamiyaシリーズの技術自体は, 携帯電話のモデルチェンジ周期より長い生命をもつであろう. 特にダイナミックリンクが要らないという見切りは 典型的なアプリケーションに対してある程度の汎用性があると思われる.

は、実に的確でした。 携帯電話があっという間に高機能化してしまって 成果物の製品化は実現しなかったのですが、 KLab株式会社 (当時の社名は、株式会社ケイ・ラボラトリー) の 創業期に技術会社としての基礎をどう築くか模索していた私にとって、 この開発プロジェクトは大きな意味を持ちました。

そんなわけで、KLab株式会社の黎明期に、 いかに未踏事業の支援が助けになったか、 機会あれば発表したいと思っていたところ、 「未踏」集会 ESPer2006 秋の陣 で 何かプレゼンしないか、とお誘い頂き、 一も二もなく引き受けました。

ESPer2006 秋の陣

日時 2006年11月25日(土)
   13:00開場、13:20開始、18:00頃まで
   その後 懇親会を行いますので、是非ご参加ください
会場 神戸国際会議場 国際会議室

定員 最大240名まで

プログラム・企画と登壇者
    IPAより、事業の紹介等
    PM談議(仮称)
    仙石 浩明氏
    尾藤 正人氏
    平林 幹雄氏
    森 悠紀氏
    油井 誠氏

2000年8月に 5人でスタートしたベンチャーが、 160人を超える会社 (2006年11月現在) に成長した、 その発展秘話(?) を、 未踏事業に採択された一技術者 (つまり私) の視点からお話ししたいと思います。 経営者の視点で書かれた会社発展物語はあまたあれど、 技術者の視点というのは、そんなに多くはないと思います (ってまだどんな話にまとめようか、まとめきっていませんが... 25日までに間に合うかな ^^;)。 自身の技術を起業につなげたい、 それも、十数人の規模ではなく、 100人あるいはそれを超える規模を目指したい、 と思っている方々の参考になれば幸いです。

会場にはまだ余裕があるようですから、 興味あるかたは 予約申込み の上、 ご参集下さい。 懇親会もあるようですから、読者の皆様とお会いするのを楽しみにしております。

Filed under: 技術と経営 — hiroaki_sengoku @ 07:20
2006年11月11日

ADSLモデム Aterm WD735GV の WAN 側 IP アドレスを取得する方法

ケータイのキャリアを WILLCOM に変えたついでに、 自宅のバックアップ回線も WILLCOM に変更した (メインの回線は Bフレッツ)。 マルチパック割引につられた (^^;) ため。 ケータイとの抱き合わせ割引でなくても フレッツより安い らしい。 普段はほとんど使わない (死活確認パケットを飛ばすだけ) バックアップ回線なので、 1円でも安いほうが助かる。

そして MNP が巷を賑わす昨今、なぜ MNP 対象外の WILLCOM かというと、 W-ZERO3[es] が 使いたかったから (^.^) であるが、 eメールの送受信と PHSへの通話が全て 定額料金に含まれるというのもうれしい。 おかげで一ヶ月の電話代が半額になった。

ウィルコムADSLサービスは、 アッカ・ネットワークスの ADSL サービスを使っていて、 アッカでは市販モデムを利用できるサービスは行なっていないという。 つまりアッカが(ウィルコムユーザ向けに) レンタルするモデムを使えということ。 それまで使っていたモデム (買い取り) が無駄になってしまうし、 このレンタルモデムはモデムといいつつルータ機能まで含んでいるので、 バックアップ回線として使いにくい機器だと困るなぁと躊躇したのも事実だが、 月額費用が 2000円ほど安くなる (モデムが買い取り可能ならもっと安くなるのに...) という誘惑には勝てず、乗り換えてしまった。

私が何のためにバックアップ回線を契約しているかというと、 メイン回線が落ちたときにも、 外部から自宅のサーバへログイン可能とするためである。 だから IP アドレスが固定割当てでないのであればダイナミックDNS などの 仕掛けを併用して、 外部からアクセスする際の IP アドレスが常に調べられなければならない。 反面、内部から外部へのアクセス (つまりいわゆる一般的なインターネットの利用法) には全くといっていいほど使用しないわけで、 普通の ADSLサービスの利用方法とは大きく異なる。 レンタルルータ込みのサービスだと、 提供側が想定する「標準的な」利用方法を「押し付けられる」リスクがあるわけで、 なるべくなら利用したくない、という思いがあった。 まあ、後述するようにそれは杞憂だったのであるが。

届いたレンタルモデム WARPSTAR Aterm WD735GV をいろいろいじっていると、 PPPoE パケットをスルーして、 ルータ機能を使わないことも可能であることがわかり一安心。 PPPoE の認証のとき必要となるログインID とパスワードも、 レンタルモデムから無事読み出すことができた。 というわけでしばらく (数日ほど) モデムとしてのみ使っていたのであるが、 レンタルモデムにルータ機能がついているのなら それを使いたくなるのが技術者のサガだろう。

ただし、外部からログイン可能、という条件だけは譲れない。 バックアップ回線としての唯一の存在意義だからだ。 それまで使っていたルータは、ダイナミックDNS サービスに対応していたので、 gcd.iobb.net を DNS で引けばルータの WAN 側の IP アドレスを 取得することができた。 今回のレンタルモデムには、少なくともマニュアルには、 WAN 側の IP アドレスを取得する方法は書かれていないし、 「クイック設定Web」インタフェースを見ても WAN 側の IP アドレスを取得できるページは見当たらない (「通信情報ログ」以外は)。

もちろん、このレンタルモデムを経由して外部にアクセスすれば、 WAN 側の IP アドレスが送信元アドレスとなるパケットが飛ぶので、 それをもとにダイナミックDNS に登録してくれるサービスがあれば いいのであるが、 そういったダイナミックDNS サービスを見つけるより、 WAN 側の IP アドレスを取得する方法を見つけるほうが早かった。

さてどうしたものか、と思って ダイナミックDNSサービス iobb.net のプロトコルを調べるためにダンプしておいた Aterm WD735GV との通信内容を眺めていると、 Aterm WD735GV が送信したマルチキャスト パケットを見つけた:

17:13:16.645897 IP (tos 0x0, ttl   4, id 2784, offset 0, flags [DF], length: 298) 192.168.1.251.1900 > 239.255.255.250.1900: [udp sum ok] UDP, length: 270
        0x0000:  4500 012a 0ae0 4000 0411 b845 c0a8 01fb  E..*..@....E....
        0x0010:  efff fffa 076c 076c 0116 484b 4e4f 5449  .....l.l..HKNOTI
        0x0020:  4659 202a 2048 5454 502f 312e 310d 0a48  FY.*.HTTP/1.1..H
        0x0030:  4f53 543a 2032 3339 2e32 3535 2e32 3535  OST:.239.255.255
        0x0040:  2e32 3530 3a31 3930 300d 0a4e 543a 2075  .250:1900..NT:.u
        0x0050:  706e 703a 726f 6f74 6465 7669 6365 0d0a  pnp:rootdevice..
        0x0060:  4e54 533a 2073 7364 703a 616c 6976 650d  NTS:.ssdp:alive.
        0x0070:  0a55 534e 3a20 7575 6964 3aXX XXXX XXXX  .USN:.uuid:XXXXX
        0x0080:  XXXX XXXX XXXX XXXX XXXX XXXX 3a3a 7570  XXXXXXXXXXXX::up
        0x0090:  6e70 3a72 6f6f 7464 6576 6963 650d 0a43  np:rootdevice..C
        0x00a0:  4143 4845 2d43 4f4e 5452 4f4c 3a20 6d61  ACHE-CONTROL:.ma
        0x00b0:  782d 6167 653d 3132 300d 0a4c 6f63 6174  x-age=120..Locat
        0x00c0:  696f 6e3a 2068 7474 703a 2f2f 3139 322e  ion:.http://192.
        0x00d0:  3136 382e 312e 3235 313a 3238 3639 2f75  168.1.251:2869/u
        0x00e0:  706e 702f 726f 6f74 6465 7669 6365 2e78  pnp/rootdevice.x
        0x00f0:  6d6c 0d0a 5345 5256 4552 3a20 4947 442d  ml..SERVER:.IGD-
        0x0100:  4854 5450 2f31 2e31 2055 506e 502f 312e  HTTP/1.1.UPnP/1.
        0x0110:  3020 5550 6e50 2d44 6576 6963 652d 486f  0.UPnP-Device-Ho
        0x0120:  7374 2f31 2e30 0d0a 0d0a                 st/1.0....

こんな、家庭用の安物ルータ (しかもモデムと称している) でさえ UPnP (Universal Plug and Play) をサポートしているような時代になったとは... シリアルケーブルでつないだ端末でルータ設定をしていたころが懐かしい... という感慨はサテオキ、 まずは 読みやすいように整形してみる (Universally Unique Identifier の部分は伏せ字)。

NOTIFY * HTTP/1.1
HOST: 239.255.255.250:1900
NT: upnp:rootdevice
NTS: ssdp:alive
USN: uuid:XXXXXXXXXXXXXXXXX::upnp:rootdevice
CACHE-CONTROL: max-age=120
Location: http://192.168.1.251:2869/upnp/rootdevice.xml
SERVER: IGD-HTTP/1.1 UPnP/1.0 UPnP-Device-Host/1.0

機器の詳細は、http://192.168.1.251:2869/upnp/rootdevice.xml を見よ、 と言っているのでアクセスしてみると、 レスポンス中に次のような記載がある:

<service>
<serviceType>urn:schemas-upnp-org:service:WANPPPConnection:1</serviceType>
<serviceId>urn:upnp-org:serviceId:WANPPPConn1</serviceId>
<controlURL>/upnp/control/WANPPPConn1</controlURL>
<eventSubURL>/upnp/event/WANPPPConn1</eventSubURL>
<SCPDURL>/upnp/WANPPPConn1.xml</SCPDURL>
</service>

実は UPnP を使うのはこれが初めてだったりする (^^;) のだが、 WANPPPConn1 という名称からしておそらくこれが「接続先1」を意味するのだろう。 サービスの詳細は、SCPDURL に書いてある URL を見ればよいのだろうと、 http://192.168.1.251:2869/upnp/WANPPPConn1.xml にアクセスしてみると、 GetExternalIPAddress というメソッドがあることが分かる:

 <action>
  <name>GetExternalIPAddress</name>
  <argumentList>
   <argument>
    <name>NewExternalIPAddress</name>
    <direction>out</direction>
    <relatedStateVariable>ExternalIPAddress</relatedStateVariable>
   </argument>
  </argumentList>
 </action>

試しに呼び出してみる:

#!/usr/bin/perl
use SOAP::Lite;
my $soap = SOAP::Lite
    ->ns('urn:schemas-upnp-org:service:WANPPPConnection:1')
    ->proxy('http://192.168.1.251:2869/upnp/control/WANPPPConn1');
my $som = $soap->GetExternalIPAddress();
my $ip = $som->valueof('//GetExternalIPAddressResponse/NewExternalIPAddress');
print "$ip\n";

するとあっさり Aterm WD735GV の WAN 側 IP アドレスを取得できてしまった。

use SOAP::Lite;」の部分を、 「use SOAP::Lite +trace => debug;」に変更すると、 http リクエストとレスポンスの内容を見ることができる。 これを真似して http リクエストを手で打ってみる (やはり、どんなプロトコルでも一度は手で打ってみないと... ^^;) と、こんな感じ:

% telnet 192.168.1.251 2869
Trying 192.168.1.251...
Connected to 192.168.1.251.
Escape character is '^]'.
POST /upnp/control/WANPPPConn1 HTTP/1.1
Host: 192.168.1.251:2869
Accept: text/xml
Accept: multipart/*
Accept: application/soap
Content-Length: 503
Content-Type: text/xml; charset=utf-8
SOAPAction: "urn:schemas-upnp-org:service:WANPPPConnection:1#GetExternalIPAddress"

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
 xmlns:namesp1="urn:schemas-upnp-org:service:WANPPPConnection:1"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
 <namesp1:GetExternalIPAddress xsi:nil="true" />
</soap:Body>
</soap:Envelope>

HTTP/1.1 200 OK
CONTENT-LENGTH: 423
CONTENT-TYPE: text/xml; charset="utf-8"
SERVER: IGD-HTTP/1.1 UPnP/1.0 UPnP-Device-Host/1.0
EXT:

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
        <SOAP-ENV:Body>
                <m:GetExternalIPAddressResponse xmlns:m="urn:schemas-upnp-org:service:WANPPPConnection:1">
                        <NewExternalIPAddress>222.147.27.89</NewExternalIPAddress>
                </m:GetExternalIPAddressResponse>
        </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

たかがルータの IP アドレスを取得するために、 これだけ沢山のデータをやり取りするのもどうかと思うが...

Filed under: システム構築・運用,ハードウェアの認識と制御 — hiroaki_sengoku @ 08:23
2006年11月4日

ダイナミックDNSサービス iobb.net

ダイナミックDNS というと RFC 2136 で定められている 「Dynamic Updates in the Domain Name System (DNS UPDATE)」がまず思い浮かぶ。 自宅のバックアップ回線 (ADSL) 用として使っている無線LANルータ WN-G54/R2 は、 「アイ・オーが提供する無料ダイナミックDNSサービス iobb.net 対応」と 書いてあるので、 てっきり DNS UPDATE 方式なのだと思っていた。

ADSL 回線を、NTT東日本の フレッツ・ADSL から、 ウィルコムADSLサービス に切り替える (バックアップ回線なのでコスト最優先) にあたって、 以前使っていた ADSL モデムはアッカ回線に適合しないようなので、 素直にウィルコムのレンタルモデムを使うことにした。 ところが、このレンタルモデム「Aterm WD735GV」には、 ルータ機能もついている。

ウィルコム曰く、 「ウィルコムADSLサービスのレンタルモデムは、 あらかじめお客さまのログインIDとパスワード等が設定されています」、 ということだそうで、 ログインIDとパスワードは教えてもらえない。 教えてもらわないことにはレンタルモデム以外のルータを使えないのだが、 サポートに電話して教えてもらうのも面倒だったので、 このレンタルモデムの「クイック設定Web」の「接続先設定」画面にて、 ログインIDとパスワードを変更せずに「設定」ボタンを押してみたら、 パスワードが平文で POST されたので、 リクエストボディを観察するだけでパスワードを知ることができた。

レンタルモデム WD735GV の「PPPoEブリッジ」機能を使えば、 WD735GV を単なる ADSL モデムとして使うこともできるし、 実際まずは ADSL モデムだけ入れ替えて ルータは元の WN-G54/R2 のまま使っているのだが、 ADSL モデムにルータ機能があるのなら それを使いたくなるのが人情というものであろう。 機器の数を減らせばそれだけ故障する確率も減らすことができる。

しかし、PPPoE 接続を WD735GV に行なわせると、 WN-G54/R2 のダイナミックDNS 機能が利用できなくなってしまう。 iobb.net 以外のダイナミックDNSサービスに乗り換えれば済む話なのであるが、 せっかく iobb.net に対応した機器を使っているのに iobb.net を使わないのは モッタイナイと思ってしまったので、 とりあえず iobb.net に対して RFC 2136 で定められている DNS UPDATE パケットを 飛ばしてみた... が何の反応もない。

無闇矢鱈にテストパケットを飛ばしていては怒られそう (^^;) なので、 ADSLモデム (つまり Aterm WD735GV) と無線LANルータ (WN-G54/R2) との間に Linux ブリッジをはさんで iobb.net への通信 (つまり PPPoE セッション) を tcpdump でダンプしてみた。 すると...

# brctl addbr br0
# brctl addif br0 eth0
# brctl addif br0 eth2
# ifconfig br0 up
# ifconfig eth0 up
# ifconfig eth2 up
# tcpdump -i br0 -s 1500 -vvv -X
tcpdump: WARNING: br0: no IPv4 address assigned
tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size 1500 bytes
        ...
17:13:20.954864 PPPoE  [ses 0x1e10] IP (tos 0x0, ttl 150, id 2, offset 0, flags [none], length: 228) 60.38.65.147.31602 > XXX.XXX.XXX.XXX.http: . [tcp sum ok] 1:189(188) ack 1 win 5656
        0x0000:  1100 1e10 00e6 0021 4500 00e4 0002 0000  .......!E.......
        0x0010:  9606 b91e 3c26 4193 XXXX XXXX 7b72 0050  ....<&A.XXXX{r.P
        0x0020:  0361 fb73 903f 4510 5010 1618 0ce3 0000  .a.s.?E.P.......
        0x0030:  4745 5420 2f63 6769 2d62 696e 2fXX XXXX  GET./cgi-bin/XXX
        0x0040:  XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX  XXXXXXXXXXXXXXXX
        0x0050:  XXXX XXXX 2e63 6769 3f68 6f73 743d 6763  XXXX.cgi?host=gc
        0x0060:  642e 696f 6262 2e6e 6574 266d 7969 703d  d.iobb.net&myip=
        0x0070:  3630 2e33 382e 3635 2e31 3437 2048 5454  60.38.65.147.HTT
        0x0080:  502f 312e 300d 0a48 6f73 743a 20XX XXXX  P/1.0..Host:.XXX
        0x0090:  XXXX XX2e 696f 6262 2e6e 6574 0d0a 5573  XXX.iobb.net..Us
        0x00a0:  6572 2d41 6765 6e74 3a20 574e 4735 3452  er-Agent:.WNG54R
        0x00b0:  322f 312e 320d 0a41 7574 686f 7269 7a61  2/1.2..Authoriza
        0x00c0:  7469 6f6e 3a20 4261 7369 6320 XXXX XXXX  tion:.Basic.XXXX
        0x00d0:  XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX  XXXXXXXXXXXXXXXX
        0x00e0:  XXXX XXXX XXXX XXXX 0d0a 0d0a            XXXXXXXX....

何のことはない、IP アドレスを登録するための Web ページを アクセスしているだけだった。 登録するホスト名と IP アドレスを、 それぞれ「host=」「myip=」パラメータで CGI へ渡し、 認証は Basic 認証を使っている (上記ダンプ中、URL の一部および認証文字列は伏せ字にした)。

したがって curl コマンドなどを使って、 ダイナミックDNSサービスに ホスト名と IP アドレスを登録することができる。

curl --interface eth0:1 --user-agent 'WNG54R2/1.2' --user 'XXXXXXXXXXXX:XXXXXXXX' 'http://XXXXXX.iobb.net/cgi-bin/XXXXXXXXXXXXXXXXXXXXXXX.cgi?host=gcd.iobb.net&myip=60.38.65.147'
Filed under: システム構築・運用 — hiroaki_sengoku @ 07:25
2006年11月1日

TheBus Monthly Pass

休暇を取ってハワイ (オアフ島) へ行ってきた。

オアフ島の主要公共交通機関である路線バス 「TheBus」についてメモ。

旅行者が TheBus を利用するときに便利なのが、

  • 4 日間 乗り放題の 4日間パス (4 - Day Pass) $20.00 と、
  • 特定の月 乗り放題のマンスリー・パス (Monthly Pass) $40.00

ちなみに一回の乗車は $2.00 なので、観光などでオアフ島に来ていて、 バスに一日何度も乗る、という場合はいずれかの Pass を買うのがお勧め。

単純に考えると、9日間以上滞在するなら、4 - Day Pass よりは、 Monthly Pass のほうが安くつきそうであるが、 注意すべき点が二つほどある。

Monthly Pass は月初から月末までの期間固定

「Monthly」だから一ヶ月 乗り放題、と思ってはいけない。 旅行期間が月をまたいでいると、 一ヶ月以内の旅行 (例えば 10/25 ~ 11/5) であっても、 二ヶ月分の Monthly Pass (10月分と 11月分) が必要になってしまう。 私は昨年、Halloween を見ようと 10月末をはさんだ旅行計画を立ててしまい、 4 - Day Pass を二枚買って、しかも Pass が使えない日ができてしまった。

月末が近いと来月分の Monthly Pass しか売っていない

昨年の失敗で学習して、今年の旅行は 10月におさまる日程にしたのだが、 10/20 に Ala Moana Center の Satellite City Hall で 10月分の Monthly Pass を買おうとしたら、 11月分の Monthly Pass しかないと言われてしまった。 Monthly Pass は、Satellite City Hall の他、 7-Eleven や Star Market などの店でも買えるが、 いずれも下旬に入ると来月分の Pass しか購入できない。 ただし一ヶ所だけ例外があって、 TheBus Pass Office でなら月末であっても当月の Monthly Pass を購入できる。 もちろん、月末残り 8 日を切れば 4 - Day Pass を選ぶべきなので、 TheBus Pass Office へ行ってでも Monthly Pass を買うべきなのは、 中旬以降の数日間に限られる。

TheBus Pass Office へは、Route A CityExpress! のバスが便利。 Ala Moana Center からなら、Keeaumoku St. を Kapiolani Blvd まで歩いて Kapiolani Blvd 沿いにあるバス停 (Kapiolani Blvd / Keeaumoku) から Route A CityExpress! のバスに乗ればよい。 時刻表を見ると、 15分に一本くらいの割合で運行している。 TheBus Pass Office がある Kalihi Transit Center (路線図中の E) へは 30 分ほどで着く。

Kalihi Transit Center でバスを降りると、 目の前に「BUS PASS / LOST AND FOUND」と書かれた建物:

TheBus Pass Office

があるので、迷いようがない。今月分の Monthly Pass が欲しいというと、 「月末までしか使えないけど値段は $40.00 のままだぞ」と念押しをされたが、 無事 10月分の Monthly Pass を購入することができた。

Filed under: Hawaii — hiroaki_sengoku @ 06:41
2006年10月16日

迷惑メール送信者とのイタチごっこを終わらせるために (1) hatena_b

迷惑メール (UCE, UBE, スパム メールなどとも呼ばれる) が沢山届いて困る、 というのはメールアドレスを公開している人にとって共通の悩みのタネであるはず。 SpamAssasin などの メールフィルタを使っている、というかたも多いだろう。

しかしながら、メールの内容を見て迷惑メールか否かを判断するフィルタでは、 迷惑メール送信者とのイタチごっこは避けられない。 送信者は迷惑メールと判断されないよう、 どんどん内容を巧妙に変化させていくからだ。 例えばフィルタリングアルゴリズムとしてよく使われる ベイジアン フィルタ(Bayesian Filter) は、 ワード サラダ (Word Salad) を食わされることによって精度が落ちてしまう。

したがって 迷惑メール送信者とのイタチごっこに終止符を打つには、 迷惑メール送信者が変更できない情報にのみ依存した 迷惑メール判定方法を用いるしかない。

迷惑メール送信者が変更できない情報とは、つまり 送信元 IP アドレスである。 そんなものはプロバイダ (ISP, Internet Service Provider) を 変更すれば変えられる、 と言われればその通りなのであるが、 単に別のアドレスに変えられるというだけであって、 望み通りのアドレスに変更できるわけではない。

例えば私が使っているメールサーバの IP アドレスは 60.32.85.220 であるが、 送信元 IP アドレスとしてこのアドレスを使える人は特定少数の人のみであり、 この IP アドレスから迷惑メールが送信されるような事態は、 まず起きないと言えるし、 万一「特定少数」のうちの誰かが迷惑メールを送るようなことがあれば、 直ちに止めさせることができる。

この IP アドレスからは迷惑メールを送信させない、というポリシーでもって 運用されている IP アドレスは数多い。 きちんと運用されているサイトの多くが同様のポリシーで運用されていることだろう。 だからそのような、「きちんと管理された」IP アドレスから送信された メールのみ受付け、 迷惑メールの送信元となる可能性がある IP アドレスからのメールを拒否すればよい。

つまり IP25B (Inbound Port 25 Blocking) である。 既に IP25B を実施しているプロバイダ もあるようであるが、 インターネットにおける通信は end-to-end を基本にすべきであって、 通信インフラを提供する側であるプロバイダが、 他のプロバイダと連係して IP25B を実施することについては違和感を覚えなくもない。

もちろん沢山ある IP アドレスの全てについて、 きちんと管理されているか否かを調べ上げることは困難であるが、 迷惑メールを送ってくる IP アドレスというのは実はそんなに多くはない。 私のサイト宛に迷惑メールを送ってきた IP アドレスを、 私は数年間にわたって記録しているが、 大多数は、ダイアルアップと思しき IP アドレスであり、 しかも、いくつかの国に集中している。

ここでいう「ダイアルアップ IP アドレス」とは、 個人ユーザがプロバイダと契約してインターネットに接続するときに、 プロバイダから割当てられる IP アドレスを指す。 「ダイアル」して接続する場合だけでなく、ADSL 等による接続も含む。 多くの場合、接続が切れるたびに異なる IP アドレスが割当てられるが、 固定的な IP アドレスが割当てられている場合もある。

このような IP アドレスは、 逆引きしても、「P061198164231.ppp.prin.ne.jp」といったような プロバイダ名しか分からないような「匿名」ホスト名しか得られないか、 あるいはそもそも逆引きが設定されていないケースが大半である。 ちなみに「P061198164231.ppp.prin.ne.jp」というホスト名は、 数字の部分を三桁づつ区切ると「061」「198」「164」「231」になり、 このホスト名に対応する IP アドレス「61.198.164.231」から 規則的に名付けられたホスト名であることが分かる。

多くのプロバイダにおいて、 「ダイアルアップ IP アドレス」には、 このような規則的に命名されたホスト名がつけられているようだ。 逆に言うと、 逆引きして規則的なホスト名が得られたときに、 その IP アドレスを「ダイアルアップ IP アドレス」と見なすことは、 ある程度の合理性を持つ。

「規則的なホスト名」=「ダイアルアップ」という認識が広まるにつれ、 ダイアルアップ以外の IP アドレスには、 規則的でないホスト名をつける風潮が強まるだろう。 実際、 私が知っているあるデータセンタは、顧客が使用する IP アドレスに、 規則的ではないホスト名をつけるよう推奨している。

したがって、メールの送信元 IP アドレスを逆引きしたときに、 規則的なホスト名が得られたら、 そのメールは高い確率で迷惑メールと予測できる。 他の迷惑メール判別方法と組合わせ、 送信元が規則的なホスト名であることを必須条件とすれば、 排除するメールを迷惑メールのみに限定する (つまり false positive の可能性をほぼゼロにする) ことが可能となる。

一方、逆引きしたとき規則的でないホスト名が得られたら、 そのメールは十中八九、マトモなメールである。 仮に迷惑メールだったのなら、 ホスト名を元にその管理主体がどんな組織であるかある程度想像つくだろうから、 迷惑メール対策が期待できそうなら連絡すればよいし、 その組織からのメールを受け取る必要がなければ、 以後受け取りを拒否すればよい。

したがって問題となるのは逆引きができない場合である。 逆引きを設定していないような管理不十分なサイトからのメールは受け取らない、 と言ってしまえるのなら楽なのであるが、 残念ながら逆引きを設定していないサイトは数多い。 その全てからのメールを拒否してしまうと、 必要なメールまで失いかねない。

そこで役に立つのが自前のブラックリスト/ホワイトリストである。 今まで受け取ったメールを集計して、 迷惑メールしか送ってこない送信元 IP アドレスはブラックリストに載せ、 必要なメールを送ってくる送信元 IP アドレスはホワイトリストに載せる。 そして、ブラックリストに載っている IP アドレスから送られてきたメールは 「ダイアルアップ IP アドレス」に準じる扱いにし、 ホワイトリストに載っている IP アドレスから送られてきたメールは、 迷惑メール判定をスキップして無条件に受け取るようにする。

今まで受け取ったメールを全て保存していれば、 ブラックリスト/ホワイトリストを作るのは容易だろう。 が、マトモなメールならいざ知らず、 迷惑メールまでも全て保存している人は稀かも知れない。 迷惑メールを受け取ったら、 内容を保存するかどうかはともかく、 送信元 IP アドレスだけは記録するようにしておきたい。

とりあえずお手軽にブラックリストを使って、 逆引きできない送信元 IP アドレスを分別してみたいというかたのために、 私が個人的に使用しているブラックリストを公開する。 送信元 IP アドレスが A.B.C.D であるとき、 D.C.B.A.rbl.gcd.org の TXT レコードが引けたなら、 その IP アドレスはブラックリストに載っている。 例えば IP アドレス 127.0.0.2 がブラックリストに載っているか調べるには、

% host -t txt 2.0.0.127.rbl.gcd.org
2.0.0.127.rbl.gcd.org text "Listed 127.0.0.2"

などと DNS 問合わせを行なえばよい。 "Listed 127.0.0.2" などの結果が返ってくれば ブラックリストに載っていることを意味し、 NXDOMAIN つまりレコードが存在しないという結果が返ってくれば ブラックリストに載っていないことを意味する。 私はこのブラックリストを利用した迷惑メール判別フィルタを用いることによって、 私のメールボックスに届く迷惑メールのほとんど全てを排除できている。

前述したように、 このブラックリストはあくまで送信元 IP アドレスが逆引きできないときに限り 利用することを想定している。 逆引き可能な IP アドレスに対してこのブラックリストを利用した場合に 得られる結果は無意味であるので注意して欲しい。 また、もちろん利用は at your own risk でお願いしたい。 このブラックリストに対するご意見は歓迎するが、 このブラックリストを利用したことによって、 あるいは利用できないことによって発生するいかなる損害に対しても 私は責任を負わない。 この条件に同意して頂けるかたにのみ、 このブラックリストの利用を許諾する。

Filed under: システム構築・運用 — hiroaki_sengoku @ 06:48
2006年10月6日

SED 教室

久しぶりに sed の話題を見かけたので、 思わずトラックバックしてみます。

アキバ系!文京区本郷四畳半社長」曰く

最近はSEDとかみんな使わないのかなあ 便利なのに
...
Rubyスクリプトさえ書きたくないときにはSedです。
Sedの過激な使い方については 往年の名著「MS-DOSを256倍使うための本 vol.2」が めっぽう面白い
これこそハックだよなあ

手前ミソながら、sed の過激な使い方にかけては、 SED 教室 も そこそこいい線行っているんじゃないかと自負しておりますが、 いかがでしょうか?

例えば、 SED 教室 第十一回 「正規表現、再論」 で紹介している、 sed で「uniq -c」コマンドを実現するスクリプト:

x
1s/.*/    /
H
y/ 0123456789/11234567890/
G
s/.*\([^0]0*\)\n.*\n\(.*\)[^9]9*$/\2\1/
x
s/\n.*//
$!N
/^\(.*\)\n\1$/!{
  x
  G
  s/\n/  /
  P
  s/.*/    /
  x
}
D

なんてのは、ぱっと見では何をやってるんだか、 まるで分からないこと請け合い ;-)

Filed under: プログラミングと開発環境 — hiroaki_sengoku @ 11:38
2006年10月5日

グループウェア・サーバを社内に置こう! hatena_b

何をいまさら、という声が聞こえてきそうですが、 社内からの情報漏洩が問題となっている今だからこそ、 あらためて社内情報を扱うサーバを、 社内LAN に置くことの重要性を訴えたいと思います。

もともと、グループウェアといえば社内のサーバに置くのが当たり前だったのですが、 いろいろな情報がグループウェアに蓄積されるにつれ、 社内からだけでなく、社外にいるときもグループウェアにアクセスしたい、 というニーズが高まってきました。

グループウェアを社外からも利用するには、 サーバをどこに置くかで分類すると、 次の 3 通りの方法があります。

  1. 社内LAN に置く
    ファイアウォールに穴をあけて社内のサーバへアクセスできるようにするか、 あるいは VPN などの方法で社内からのアクセスを社内へ導く方法です。 正規のアクセス以外の、招かざる客を確実に排除できなければなりません。
  2. DMZ 上に置く
    社外からもアクセスできる非武装地帯 (DMZ) にサーバを置く方法です。 ファイアウォールで守られない場所に置くのですから、 サーバは自分自身を守ることができなければなりません。
  3. 社外に置く
    他社が提供するグループウェアASP サービスを利用する方法です。 情報管理を他人任せにできるので一番手間がかかりませんが、 万一情報漏洩が起きたときに誰が責任をどうやって取るのか、 契約等ではっきり決めておかないとトラブルの種となるでしょう。

いずれも一長一短があるので、いちがいにどれがいいとは言えませんが、 それぞれどのようなリスクがあるかきちんと把握した上で利用することが重要ですね。

手軽さだけで言えば、もちろん 方法3 が一番簡単なのですが、 手軽なだけにリスク管理が出来ていない人が利用すると、 情報のダダ漏れが起きます。

【警告】Googleカレンダーで情報流出? から引用:

無防備な人が多いには驚きます。 Googleカレンダーで、 まるでソーシャルブックマークみたいに公開設定をしている人が何人もいます。 実に詳細な仕事のスケジュールが公の場にさらされており

ということも実際に起きているようです。

じゃ、公開設定しなければ安心か、というとそうとも言えません。 別に ASP サービスを提供している会社を信用しないわけではないのですが、 サーバに情報をため込めば、サーバの運用管理を行なう過程で、 どうしたってその情報が漏れるリスクはあります。 万一漏れたときに ASP サービス提供会社がどう責任をとってくれるのか、 確認しておきたいところです。

他人任せにするのは、どうも気持ち悪い、という場合は 方法1 あるいは 方法2 を選択することになります。 方法2 は、ASP サービス提供会社が行なっているのと同等のことを 自社で行なうイメージですね。 自社で運用するので、情報漏洩が起きたときの責任の所在ははっきりしていて いいのですが、 どうやって外部からの攻撃を防ぐかが問題となります。

インターネット上でサーバを安全に運用することが困難だからこそ、 各種 ASP サービスが提供されているわけで、 きちんとしたサーバ運用管理体制を整えずに運用したりすると、 あらゆる攻撃を受けて侵入されてしまうかも知れません。 また、サーバそのものは運用できていても、 グループウェアの側に脆弱性があって、漏洩事故が起きてしまうケースもあります。 そもそも、きちんとサーバを運用できるだけの体制を整えられるのなら、 ASP サービスの提供側になったほうがよさそうです。

と、いうわけで結論は、方法1 の「グループウェア・サーバを社内に置こう!」です。 この方法のいいところは、社内で使っているグループウェア・サーバを、 変更なしにそのまま使えるという点で、 気をつけなければならないのは、正規のアクセス以外の不正侵入を どうやって確実に排除するか、という点です。

社内で使っているグループウェア・サーバをそのまま使うわけですから、 何らかの脆弱性があることを前提としなければなりません。 脆弱性がないなら DMZ に出しておけるわけで、 社内に置く最大のメリットは、多少の脆弱性は許容できるという点にあります。 だから、 正規ユーザ以外からのアクセスは決して、 社内サーバに到達できないようにしなければなりません。

では、どうやって不正アクセスを排除すればいいのでしょうか? ファイアウォールに穴を開ける方法にせよ、 VPN を使う方法にせよ、 何らかの「入口」を設置して、 そこで正規アクセスと不正アクセスを選別することになりますが、 この「入口」を適切に運用管理することは結構大変です。 不正アクセスを試みる人は、なんとかこの「入口」をだまして 通ろうとするわけで、 「入口」をきちんと運用管理する体制を整えなければなりません。

あれ? 結局これでは 方法2 と同じですね?

そこで、「VPNワープ」です (我田引水... ^^;)。 VPNワープは、この「入口」を提供する ASP サービスなんです。 グループウェア・サーバ自体は社内に置いて情報漏洩のリスクを抑えつつ (方法1 の長所)、 「入口」の運用管理だけ他社 (つまり KLab) 任せにして手軽さも確保する (方法3 の長所)、 方法1 と 方法3 のいいとこどりの「入口ASP」、それが VPNワープです。

今月末まで無料スタートキャンペーン中ですので、 ぜひこの「入口ASP」をお試し下さい。 BIGLOBE会員のかたは、「エージェント」と「SSL証明書」を ダウンロードするだけで利用できますし、 BIGLOBE会員でないかたも、 初期費用・月額費用が無料の 「コンテンツ」コースに入会すれば、 すぐ VPNワープをお試し頂くことが可能です。

Filed under: システム構築・運用 — hiroaki_sengoku @ 13:56
2006年10月2日

2000年、ケータイJAVA がベンチャーと技術者を結び付けた

技術をウリにする会社は、その立ち上げメンバに三種類の人種が含まれていることが必須なのだと思います」と以前書いたのですが、 「人種」が異なる人が出会う事って、 実はかなり稀な現象なのではないかという気がしています。

先日、某大学へ遊びに行く機会があったのですが、 日頃ベンチャーの中ではあまり感じることがなかった 「人種の近さ」のようなシンパシーを 感じてしまいました。 そういえば、私の大学時代の友人には、 大学に残って学究の道を進み、 教授や助教授にまで上り詰めた人が少なくありません。 大学に残らず大企業の研究所などに就職した人もいるのですが、 いつのまにか ;-) 大学に戻っていたりします。

彼らの大半は、私なんぞよりはるかに頭がよく、 その能力をベンチャー発展のために使ってもらえたら、 日本のベンチャーはもっと活気付くのにと、 つい思ってしまうのですが、 彼らの興味がベンチャーに向くことが稀なのだから仕方ありません。

つまり、大学志向の人とベンチャーを興そうという人とでは、 興味の対象が異なるのです。 日本の大学でインターネットの研究が盛んだったのは '80年代の終わりごろです。 インターネット黎明期と呼ばれる頃ですね。 日本を代表するような大企業の研究所では、 当時からインターネットに注目していましたが、 ビジネス的にはまだ海のものとも山のものとも分からず、 ましてこれから起業しようとする人たちが興味を持つような 代物ではありませんでした。

1992年ごろにインターネットの商用利用がはじまりましたが、 インターネットでベンチャーを興してみようと思う人たちが現れたのは、 1994年ころからです。翌年 1995年はインターネット元年と呼ばれていますね。 ところが大学では、 1992年ころまでにインターネットは すっかり日常生活の一部となってしまっていました。 いまさらインターネットで何をするんだ、と思ってしまっていた人も 多かったのではないでしょうか。 今となっては先見の明の無さを恥じるばかりですが、 私自身 1992年ごろには、インターネットにはもはや技術的に新しいことは 何も残ってはいないと思っていました。

ところが、みなさんもご存じの通り、ベンチャーにとってインターネットは '90年代終わりになってからが本番で、 2000年のネットバブル崩壊をものともせず、 数多くのベンチャーが果敢に挑戦を続けています。

学問的に盛り上がってしばらくして下火になる頃から、 それがビジネスの種になりベンチャーが盛り上がる、 こういう順番になるのは当たり前と言えば当たり前すぎるのですが、 こうした時間のずれが、 学問の世界の人たちと ベンチャーの世界の人たちが 出会う機会を減らしているのでしょう。

そんな中、2001年に始まったケータイJAVA は、 学問志向の人とベンチャー志向の人が同時に関心を寄せた、 数少ない例外の一つだったのではないでしょうか。 当時私はベンチャーに対しては何の興味もなかったのですが、 ケータイでユーザプログラムを動かすことができれば、 何か面白そうなことができそうだと思っていました。 一方この年は、iモードの成功が誰の目にも明確になった年で、 ケータイJAVA は iモードの可能性をさらに広げてくれるものとして、 多くのベンチャーが大変な関心を寄せました。

そうして、ベンチャー志向の人と、大学志向の人との出会いが数多く生まれました。 あれから 6年たった今、 こうした出会いを産み出す共通の関心事には何があるでしょうか?

Filed under: 元CTO の日記,技術と経営 — hiroaki_sengoku @ 07:38
2006年9月27日

ssh-agent を screen の中から使う方法 hatena_b

GNU screenバグ報告を行なう ついでに screen-devel ML に参加したら、 次のようなメールが ML に流れてきた:

There is a much simpler solution
http://www.2701.org/archive/200406150000.html

The key is that SSH_AGENT need not point to a socket, it can point to a symbolic link to a socket.

なるほど~

ssh-agent と通信するための UNIX ドメイン ソケット を指す (パス名固定の) シンボリック リンクを作るようにしておけば、 環境変数 SSH_AUTH_SOCK には、そのシンボリック リンクのパス名を 設定しておけば済むので screen の中で ssh を使うとき便利、 というわけである。 つまり、

senri:/home/sengoku % ssh asao
Last login: Sun Sep 10 08:24:20 2006 from senri.flets.gcd.org
Linux 2.6.16.28.

asao:/home/sengoku % echo $SSH_AUTH_SOCK
/tmp/ssh-chKJY25976/agent.25976
asao:/home/sengoku % screen -r

senri で ssh-agent を走らせておいて、 asao へ ssh でログインするさいに、 ForwardAgent を有効にしておくと、 上の実行例のように、SSH_AUTH_SOCK に UNIX ドメイン ソケットの パス名が設定され、このソケットを介して senri の ssh-agent と通信ができる。

ところが、前回のログイン時に使っていた screen を reattach すると、 screen の中では、SSH_AUTH_SOCK の値は、 前回のログイン時のパス名のままである:

asao:/home/sengoku % echo $SSH_AUTH_SOCK
/tmp/ssh-ptnuvb3346/agent.3346

ForwardAgent はログアウトと共に終了するので、 screen の中の SSH_AUTH_SOCK の値は、 ログインするごとに設定し直す必要がある。 これはとてもメンドクサイ。

ログインし直すたびに SSH_AUTH_SOCK の値が変化するから、 このような問題が起きるわけで、 SSH_AUTH_SOCK の値が常に同じなら、 reattach した screen の中でも同じ SSH_AUTH_SOCK の値を使い続けることができる。

すなわち、 SSH_AUTH_SOCK が直接 UNIX ドメイン ソケットを指し示すのではなく、 UNIX ドメイン ソケットを指し示すシンボリック リンクを作成しておいて、 SSH_AUTH_SOCK にはこのシンボリック リンクのパス名を設定しておけばよい。

さっそく ~/.cshrc に次の行を追加した:

set agent = "$HOME/tmp/ssh-agent-$USER"
if ($?SSH_AUTH_SOCK) then
        if (! -S $SSH_AUTH_SOCK) unsetenv SSH_AUTH_SOCK
endif
if ($?SSH_AUTH_SOCK) then
        if ($SSH_AUTH_SOCK =~ /tmp/*/agent.[0-9]*) then
                ln -snf "$SSH_AUTH_SOCK" $agent && setenv SSH_AUTH_SOCK $agent
        endif
else if (-S $agent) then
        setenv SSH_AUTH_SOCK $agent
else
        echo "no ssh-agent"
endif
unset agent

私は、かれこれ 20年近く csh をログイン シェルとして使い続けてきているので、 ~/.cshrc なのだが、今となっては (極めて?) 少数派だろう。 bash など、sh 系をログイン シェルとして使っている場合は、 ~/.profile などに

agent="$HOME/tmp/ssh-agent-$USER"
if [ -S "$SSH_AUTH_SOCK" ]; then
        case $SSH_AUTH_SOCK in
        /tmp/*/agent.[0-9]*)
                ln -snf "$SSH_AUTH_SOCK" $agent && export SSH_AUTH_SOCK=$agent
        esac
elif [ -S $agent ]; then
        export SSH_AUTH_SOCK=$agent
else
        echo "no ssh-agent"
fi

などと書いておけばよいだろう。

Filed under: プログラミングと開発環境 — hiroaki_sengoku @ 07:56
2006年9月23日

設定10分、月額525円の「VPNワープ」を BIGLOBE と共同で提供開始 hatena_b

昨日、NECビッグローブ株式会社と 共同で、BIGLOBE法人会員および個人会員向けに 「VPNワープ」の提供を 開始しました。 これまで VPN-Warp 入門編 6回、応用編 3回を書き綴ってきましたが、 「VPNワープ」サービス 開始により、 より多くの方に手軽に VPN-Warp を使って頂けるようになったと思います。

なお BIGLOBE会員でないかたも 初期費用・月額費用が無料の 「コンテンツ」コースに入会すれば、 VPNワープをご利用頂くことが可能です。

「設定10分ですぐ使える SSL VPN」を目指して、 「VPNワープ」で提供するリレー・エージェントは、 relayagent フリーダウンロード で公開しているものより、 さらに簡単な「簡易インストール方式」を採用しています。 10分で設定できるかは、もちろん個人差があるとは思いますが (^^;)、

  1. VPNワープのページの 管理者メニューの「購入」を選ぶ
    (現在、無料スタートキャンペーン実施中につき、10月末まで無料)
    指示にしたがって進んでいくと、 証明書 relay,4000017.pfx (数字の部分はユーザごとに異なります) が ダウンロードできるので、これをダブルクリックしてインポートする
  2. 「リレー・エージェント」インストール用プログラムをダウンロード
    このプログラム VPN-Warp_RelayAgent_Setup_Biglobe.exe をダブルクリックすると 「VPN ワープ relay エージェント(Biglobe版)」ウィザードが開くので、 以下のように、ウィザードの指示に従って必要項目を入力していく
    • イントラネットの Web サーバをアクセスするときの URL のサーバ名部分 (例えばトップページのURLが「http://intra/index.html」であれば「intra」) を入力
    • 証明書ストア内の証明書の一覧が表示されるので、 その中から 1. でインポートした証明書 (上述の例では relay,4000017) を 選択する
    • Windows にログオンするときのパスワードを入力 (リレー・エージェントが証明書ストアにアクセスする際、 ユーザ権限で Windows にログオンする必要があるため)
    • 「インストール」ボタンを押すと、インストールが行なわれ、 「relay エージェントサービスを開始しますか?」という 問合わせが表示されるので「はい」を押す

これだけで、証明書をインポートずみの PC であれば、ブラウザから
「https://biglobe.klab.org/」へアクセスするだけで
イントラネットの Web サーバにアクセスすることができるようになります。

「VPNワープ」で提供するリレー・エージェントも、 本ブログ上で公開している relay agent も、 相互に互換性がありますので、 「VPN ワープ」にて本ブログ上で公開している relay agent を使うことも可能です。 ただしこの場合、BIGLOBE への問い合わせはご遠慮下さい。 本 VPN-Warp ブログで公開している relay agent は、 本ブログの読者のかた限定で公開しているものであり、 この relay agent を使った際に生じた問題等は、 本ブログに対するコメント等で問い合わせて頂きたいと思います。

  • 入門編 (1) VPN-Warp の特長: ふつうの SSL VPN と比べて
  • 入門編 (2) VPN-Warp の特長: ssh のポートフォワードと比べて
  • 入門編 (3) stone & relayagent の設定方法
  • 入門編 (4) stone の代わりに OpenSSL の s_client を使ってみる
  • 入門編 (5) stone の代わりに普通の WWW ブラウザを使ってみる
  • 入門編 (6) WWW ブラウザを使う場合の注意点
Filed under: システム構築・運用 — hiroaki_sengoku @ 08:46
« Newer PostsOlder Posts »