仙石浩明の日記

2006年

2006年6月17日

stone 2.3b リリース

stone 2.3b をリリースした。 現時点ではスナップショット扱いであるが、 重大なバグが発見されない限り、 このバージョンを stone 2.3 に代えて正式リリースとする予定。 stone 2.3a からの変更点は以下の通り。

doReadWrite select ループを抜けるバグを修正

stone.c 2.2.2.6 で doReadWrite から doReadWritePair を分離したときに作りこんでしまったバグを修正。

このバグにより、意図せず doReadWrite select ループを抜けてしまい、 パフォーマンスが大幅に低下するケースがあった。 詳しくは SSL_Pending を参照。

アーカイブから stone.1 と stone.1.ja を削除

stone 2.3 と stone 2.3b との仕様の差分を、 マニュアル stone.1 および stone.1.ja に反映できていないので、 とりあえず削除。

現時点での stone の正式マニュアルは、 パッケージ同梱の README.txt および README.en.txt である。

変数名の変更など

関数の仮引数と同じ変数名のローカル変数を使っていた。 stone.c 2.2.2.23 で修正。

Filed under: stone 開発日記 — hiroaki_sengoku @ 22:02
2006年6月14日

負けることを恐れるあまり、勝つことに価値を見いだせなくなってしまった人たち hatena_b

『他の人に勝つ』ということに価値を見いださない人たち」に頂いたコメントから発展して、 /.j 方面でいろいろなコメントを頂いた。 いろんな考え方の人たちと議論することによって 考えが深まるので大変ありがたいことだ。 曰く:

この方は競争に勝つために勝てる分野を選んで それを好きになるという習慣を自分の中に構築して行った結果、 それがあまりにも固定化された「大前提」になってしまって、 そこに至るまでの「自分がなにをしたいのか」について ちゃんと考えることを止めてしまっているのではないかと思います。

どうやら昨今の事件によって「勝つ」という言葉の持つ負のイメージが 大きくなってしまっているようだ。 なにごとにも光と影の面がある。 勝つ人がいれば当然負ける人がいる。 負ける人のことに焦点をあてれば、 勝つことに価値が見いだせなくなるのは当然のことだろう。

では、「勝つ」という代わりに「人より『上手く』やる」と言い換えたらどうだろう? 例えば、「私は普通の人より効率的なコーディングができる」。 私よりコーディングの効率が劣る人は「負け組」だろうか?

もちろん違う。 単にコーディングに向いていないだけなのだ。 自身の適性を早く把握して、 自分に向いていることを見つけ出し、 それを好きになって取り組めば、 おそらくその分野では私より「上手く」やることができるようになるだろう。

「勝ち組」は一割以下だという。 ほとんどの人は「負け組」になってしまうから、 そもそも「勝ち負け」にこだわるのはよくないと、 まるで小学校の徒競走みたいなことを言う人がいる。

しかし、なぜ負けた人がその分野にこだわる必要があるのか? ある分野で負けても、他の分野で見返してやればいいではないか。 みんながそれぞれ自分に一番向いていることをすれば、 「勝ち組」の割合はずっとずっと増えるだろう。

これこそ、それぞれの人の多様な能力を伸ばすことをめざす 「ゆとり教育」の目標であったはずだ。 ところが現状は皆が自身の個性を無視して同じようなことを目指す。

徒競走でビリの子が出るのが問題なのではなく、 みんなを運動会に等しく駆り出すことが問題なのである。 勝ち負けをはっきりさせなければ誰が運動能力に優れ、 誰が向いていないのか曖昧になってしまう。

受験戦争が問題なのではなく、 大学で学ぶ意欲も能力もない子まで大学へ進学させようとするのが問題なのである。 大学で学ぶ意欲も能力もない子でも、 受験テクニックを無理矢理覚え込ませればテストの点は上がるかもしれないが、 そういった子たちが大学に入って何をするというのだろう。

お金儲けが問題なのではなく、 自身の適性を無視し、自分がやりたいことを見失って、 向いていない仕事を嫌々やっていることが問題なのである。 「プログラマ 35歳 定年説」に書いたように、 できるだけ早い段階で勝ち負けをはっきりさせ、 自分に向いていることを見つけるべきなのである。

Filed under: 技術者の成長 — hiroaki_sengoku @ 08:11
2006年6月13日

ロングテール戦略が格差社会を生む: 究極の搾取

仮説: ロングテール戦略が格差社会を生む の検証の一回目 (全七回を予定)。

究極の搾取

剰余価値が生まれて以来、 持つ者が持たざる者を 搾取する、 という構図は変わらない。

産業革命の時代、資産とは生産諸手段だった。

情報革命の今日、資産とは知能である。

頭のよい者が儲け、頭がよくない者は自覚のないままに搾取されている。 搾取と言っても、一人一人の額は微々たるものだから、気付かないのだろう。 たまに、「ボロ儲け」した奴はけしからん、と一部の金持ちが槍玉にあげられるが、 本当の金持ちは目立たないようにしているものだ。 一人一人に対する搾取は極めて少額でも、 情報技術の力によって集めれば莫大な額になる。

かつて「搾取」が持っていた暗いイメージはもはやない。 産業革命時代の搾取と違って、 今日の搾取には悲惨さは微塵もない。 かつての搾取はその悲惨さによって下層階級を固定していたが、 今日の搾取にはその力はない。 したがって産業革命時代と異なり、 今日は搾取それ自体が格差社会を生んでいるわけではない。

その一方で、富を集積する力は従来と変わらず圧倒的である。 しかも、産業革命時代の機械と比べると、 今日のコンピュータおよびネットワークは、 費用対効果が極めて高い。

圧倒的な効率で富を集積する力を持ち、 しかも負の側面をほとんど持たない。
まさに究極の搾取と呼ぶにふさわしいだろう。

Filed under: 自己啓発 — hiroaki_sengoku @ 07:47
2006年6月11日

TCP/IP を使った DNS 問合わせ

DNS問合わせというと、 ネームサーバの UDP/IP の 53番ポートへ問合わせるのが一般的であり、 TCP/IP の 53番ポートはゾーン転送のみに使われることが多い。 しかし RFC (RFC1035 および RFC2136) 上は TCP も、UDP と同様、 通常の問合わせにも利用することができることになっているし、 多くのネームサーバでそのような実装になっている。

手近なネームサーバが利用できない環境 (某ホテルの無線LAN 環境など ;) で、 やむを得ず遠方のネームサーバを利用する際などに、 TCP を使って問合わせをすると、 ポートフォワードすることもできて便利である。

拙著「ネーム・サーバ (前編)」に書いたようにネームサーバには二種類あって、 ここで言うネームサーバは、 「/etc/resolv.conf に登録できるネーム・サーバー」のことである。 つまり、リゾルバから問い合わせがあると, 他のネーム・サーバーに問い合わせて結果を返してくれるタイプである。 一般にはキャッシュ ネーム サーバと呼ばれることが多いようだ。
ちなみにネームサーバには他に、 「答えを知っている問い合わせに対しては答えてくれるけれど, 知らない場合は,どこどこへ聞けと冷たく言い放つタイプ」がある。
また、キャッシュ ネーム サーバの一形態として、 他のキャッシュ ネーム サーバへ問合わせを転送する フォワード専用型キャッシュネームサーバもある。

広く普及しているネームサーバ実装の一つである djbdns には、 UDP 問合わせに失敗したり、 あるいは 512バイト以上の問合わせを行なう際は、 TCP にて問合わせを行なう機能があるが、 最初から TCP しか使わない (キャッシュ) ネームサーバがあると便利だろう。 すなわち、 遠方のネームサーバへ TCP で問合わせを転送する、 フォワード専用型サーバである。

フォワード専用型 キャッシュ ┌→ルート (root) ネームサーバ
リゾルバ──→キャッシュネームサーバ──→ ネームサーバ─┼→ネームサーバ
UDP TCP  ├→ネームサーバ
 └→

といった感じで TCP専用サーバを用いる。 この TCP専用サーバの作り方は簡単で、 djbdns の場合ならば次のようなパッチをあてるだけである。

dns_transmit.c で定義されている dns_transmit_start() 関数の末尾部分で、
    if (len + 16 > 512) return firsttcp(d);
    return firstudp(d);
となっている部分を、
    /* if (len + 16 > 512) */ return firsttcp(d);
    return firstudp(d);
で置き換える。

このようなパッチをあてた dnscache プログラムを、 環境変数 FORWARDONLY をセットした状態で呼び出せば、 「servers/@」に指定したキャッシュネームサーバへ TCP で問合わせを転送する、 フォワード専用型キャッシュネームサーバになる。

Filed under: システム構築・運用 — hiroaki_sengoku @ 08:59
2006年6月8日

ロングテール戦略が格差社会を生む

ふと思いついた仮説: ロングテール戦略が格差社会を生む を検証していこうと思う。

凡人が万馬券ばかり買って競馬場を去る社会」 「格差」 「過ぎたる機会は及ばざるがごとしか」など、
格差社会」というテーマが最近ホットであるようだ。 これらのブログを読んでいて違和感を感じた。
別の視点から「格差」を論ずることができるような気がしている。

論拠は次の 7 つ。

  1. 究極の搾取
  2. 必要は発明の母
  3. 機会均等
  4. 最も貴重な資産
  5. 習慣
  6. ラットレース
  7. 仮想下層社会

これだけで私が何が言いたいか分かってしまった人もいるかもしれないが (^^;)、 今後一つずつ掘り下げてみる予定。 ご意見を頂ければ、より突っ込んだ議論ができるかもしれない。

Filed under: 自己啓発 — hiroaki_sengoku @ 08:44
2006年6月6日

ライブドア ブログのXHTML文法チェック

ふと思い立って、このブログ(livedoor Blog)の XHTML文法チェックを行ってみた。 予想通り、山のような文法エラーが見つかった。(^^;)

片っ端から修正し、ほとんどは駆逐できたのだが、 ユーザ設定できない以下の部分についてはどうにもならない。

修正不可能な文法エラー

ユーザ設定できない部分なので修正できない。

HTMLテンプレートでアイコンのURLを示す変数の値が異常

次のようなHTMLが生成されてしまう:

<div class="powered">
<a href="http://blog.livedoor.com/">
<img src="http://img.blog.livedoor.com/img/usr/cmn/blog_pro.gif
"
width="117" height="28" border="0" alt="livedoor Blog(ブログ)"
title="livedoor Blog(ブログ)" />
</a>
</div>

なぜか、blog_pro.gif のURL の直後に改行コードが入っている。
これは、HTMLテンプレートでは「<$LDBlogLogo$>」となっている部分。

outfooterの部分

HTMLテンプレートで生成した HTML に、 システムが自動的に追加する outfooter に次のような部分がある:

<script type="text/javascript" src="http://parts.blog.livedoor.jp/js/c.js">
</script>
<script language="JavaScript">blog_counter('hiroaki_sengoku')
</script>
<script type="text/javascript" src="http://blog10.analyzer.livedoor.jp/x.js?pid=39952">
</script>
<noscript>
<img src="http://blog10.analyzer.livedoor.jp/img/a.gif?pid=39952">
</noscript>

なぜか二番目の JavaScript だけ 「language="JavaScript"」という属性になっている。 一番目、三番目と同様「type="text/javascript"」にすべきだと思う。

また、img タグが閉じていないのと、alt属性がない。

以上は、HTMLテンプレートで設定可能な範囲外であるので、 対処できない。

修正可能ではあるものの望ましくない文法エラー

上記の問題点のほか、回避手段があるとはいえ、 以下の点も問題だろう。

「ブログ検索」プラグイン

プラグインとして「ブログ検索」を使用すると、 以下のような HTML を生成してしまう:

<form action="http://sf.livedoor.com/search" method="GET" style="padding:0;margin:0px;">
<input type="HIDDEN" name="q" value="allinblog:http://sengoku.blog.klab.org/">
<input type="TEXT" name="q" class="sf">
<input type="SUBMIT" value="検索" class="sfbtn">
</form>

inputタグが閉じていない。 また、「method="GET"」は「method="get"」のほうがよいだろう。

「ブログ検索」プラグインを使わず、 「フリーエリア」プラグインを使って 正しい XHTML を書けば対処可能ではあるが...

改行をそのまま反映

「投稿フォームの設定」で「改行をそのまま反映」を選択すると、 行末に「<br>」が挿入される。 「<br />」でないと XHTML 的には文法エラーになってしまう。

Filed under: その他 — hiroaki_sengoku @ 19:22
2006年6月5日

アイディアを出す人、その実現を技術で支える人、作ったものを売る人 hatena_b

タイトルで言いたいことを言い尽くしてしまっている (^^;) のですが、 技術をウリにする会社は、 その立ち上げメンバに三種類の人種が含まれていることが必須なのだと思います。 すなわち、

  1. 湯水のように新しい事業アイディアを思いつくアイディアマン
  2. アイディアを実際の製品として実現する技術者
  3. 完成した製品を売る戦略を立案し実行するマーケッタ

会社の立ち上げというと、 ともすると同じような人種が集まりがちです。 例えば、 技術出身者ばかりで立ち上げた会社や、 その逆にアイディアマンばかりで立ち上げた会社です。 前者は技術出身だけど営業のことをある程度知っている人が営業担当になり、 後者は技術者ではないけれど仲間内では技術に詳しいと一目置かれる人が 技術担当になったりします。

しかしいくら人当たりが良くても技術者は技術者ですから、 どうしても製品への思い入れが強くなってしまい、 肝心の売るための戦略がおろそかになって 場当たり的な営業になってしまいます。 また、ある程度会社の規模が大きくなってくると、 営業チームを作って組織的な営業が必要となりますが、 セールスパーソン一人一人の心を理解している人でなければ リーダシップをとることは難しそうです。 私自身は技術者ですから、 優秀なセールスパーソンは無条件に尊敬するものの、 どうすれば営業チームを育て、機能させていくことができるのか、 (いろいろ営業ハウツー本を読んで勉強したりはしているのですが ^^;) 根本的なところは理解の範囲外にあるような気がしています。

同様に、技術者でない人が技術者チームを率いようとしても、 技術者一人一人の技術力の差がどこにあるのか、 きちんと理解することは難しいでしょう。 たまたま優秀な技術者が運良く入社してきたとしても、 その人の真の実力を理解して評価することができなければ、 早晩その人はもっと評価される場、 あるいはもっと自身を磨ける場を求めて去ってしまうはずです。 優秀な技術者にとって一番の屈辱は、 レベルの低い技術者と同列に扱われることなのですから。 自分は技術者に対する尊敬の念を持っているから技術者がついてくる、 なんて言う人にかぎって、 ピンもキリもいっしょくたに「尊敬」したりするので、 余計にタチが悪かったりするものです。

Filed under: 元CTO の日記,技術と経営 — hiroaki_sengoku @ 08:06
2006年6月4日

Wチューナ&ビデオキャプチャ カード GV-MVP/RX2W を使って Linux でテレビ録画

Linuxでテレビ録画を行なう方法は、多くの Web ページで紹介されているが、 ビデオキャプチャ カードによっては、 Linux カーネルのバージョンが変わると一筋縄にはいかなかったりするので、 現時点での Linux カーネル安定版の最新バージョン 2.6.16.19 で、 I-O DATA 製 ハードウェア MPEG-2 エンコーダ搭載TVキャプチャボード GV-MVP/RX2Wを使う方法をメモ (2.6.24.4 で使う方法)。

まず、 LinuxTVプロジェクトから V4L ドライバの最新版を取得する。 Mercurial (a fast, lightweight Source Control Management system) が インストール済であれば、

hg clone http://linuxtv.org/hg/v4l-dvb

を実行する。Mercurial が無い場合は、 MASTER v4l-dvb development repository から最新版を選んで「tree」をクリックし、 「gz」ないし「bz2」をクリックして tar ball をダウンロード。

そのまま make install してインストールしてもよいが、 make release VER=2.6.16.19 などと実行して、 現在使っているカーネルとは別のカーネルへインストールすることもできるし、 make menuconfig を実行して インストールするモジュールを選択してもよい。

私は、以下のモジュールのみ make した:

Multimedia devices  --->
  Video Capture Adapters  --->
    V4L USB devices  --->
      Hauppauge WinTV-PVR USB2 support

# Hauppauge 以外でも tveeprom.ko を用いるドライバであれば何でもよい

次に、ぱ研「LinuxでITVC16-STVLP」の ページに登録されている 0.6_svn3233-paken060421.tar.gz をダウンロード。 これをそのまま make すると version_check でひっかかるので、 Makefile の一行目を、

all clean install: version_check

となっているのを

all clean install:

に変更して make install する。 make KVER=2.6.16.19 install などと実行して、 現在使っているカーネルとは別のカーネルへインストールすることもできる。

/etc/modprobe.conf に以下の行を追加:

alias char-major-81 videodev
alias char-major-81-0 ivtv
alias char-major-81-1 ivtv
options ivtv ntsc=j tuner=46,46

チューナの video standard の設定を変更すると、 正しい選局ができなくなるようなので、 チャンネルを設定するプログラム等で video standard の設定を行なわないようにしておく必要がありそう。

私は録画 perl スクリプトを 自作して使っている (Video::ivtv & Video::Frequencies が必要)。

senri:/home/sengoku % tv -h
Unknown option: h
Usage: tv <opt>
opt:   -x               ; xine
       -X               ; mplayer YUV
       -u               ; ptune-ui
       -P <port>        ; TV server (http)
       -U <host>:<port> ;           (udp)
       -c <channel>     ; change channel
       -f <freq>        ; chage frequency
       -l               ; input from S-Video
       -r <sec>         ; mpeg to stdout
       -o <file>        ;      to file
       -t <time>        ; record at <time>
       -j               ; start at 0 sec
       -0               ; use video0
       -1               ; use video1
       -v               ; verbose

このスクリプトは予約録画 (-t オプション) もサポートしている他、 tv -P 1234 などと実行すると、 TVサーバとして利用することもできる。 つまり LAN 内の任意のマシンで、 VLC media playerを使って http://senri:1234/?c=1 などとチャンネル指定付で tv サーバへ接続し、 TVを視聴できる。

(ビデオキャプチャ・カード GV-MVP/RX2W を使って Linux 2.6.24.4 でテレビ録画)

Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 12:45
2006年6月2日

SSL_pending

SSL_pending をマニュアルで調べると、

SSL_pending - obtain number of readable bytes buffered in an SSL object

SSL_pending() returns the number of bytes which are available inside ssl for immediate read.

と書いてある。つまり OpenSSL ライブラリ内に受信可能データがある場合、 そのデータバイト数を返す関数である。

なぜこんな関数が必要かというと、 データを送信しようとして SSL_write を呼び出したときも、 TCP/IP レベルでは送信だけでなく、受信も行なわれるからだ。 SSL のような暗号通信の場合、 送信は「垂れ流し」では済まず、ハンドシェークを行なう必要があるからだが、 この時、受信しようと思っていなかったデータ、 つまり通信相手が送信したデータまで読み込んでしまう場合がある。

すると、SSL_write を呼んでいるのに、 OpenSSL の受信バッファに、意図せずデータが溜まってしまう。 こうなってしまうと、select(2) や epoll(2) では検知できない。 select(2) や epoll(2) は、 I/O レベルでの受信データの有無を調べるシステムコールであり、 それより上のレベルである OpenSSL ライブラリの受信バッファのことは 関知しないからだ。

stone では、SSL_write で全てのデータを送り終わったとき、 SSL_pending を呼び出して受信すべきデータがないか確認している。 これを行なっているのが、 中継元/中継先との送受信を行なう stone の中核関数 doReadWritePair である。

select 版 stone の場合、 doReadWritePair を呼び出すのは doReadWrite である。 この関数は、 中継元/中継先との通信を行なうソケットディスクリプタのみを監視する select ループである。 epoll 版と異なり、select 版では、 select で監視するソケットの数が増えるとパフォーマンスが落ちるので、 送受信が継続しているときはメインの select ループとは別のスレッドを作成して、 パフォーマンスの低下を回避している。 送受信が途絶える (0.1 秒以上送受信が行なわれない) と、 この doReadWrite select ループを抜け、スレッドを終了して、 メイン select ループでソケットを監視する状態に戻る。

stone 2.3a (正確に言うと、stone.c 2.2.2.6 ~ 2.2.2.23) では、 SSL_pending で受信すべきデータを検知したとき、 SSL_read を行なってデータを受信した直後に、 この doReadWrite select ループを抜けてしまっていた。 本来なら、データを受信したのだから 直ちにそれを中継するために送信しなければならないのであるが、 ループを抜けてしまったために、いったんスレッドを終了し、 メイン select ループで送信可能か確認し、 再びスレッドを生成して doReadWrite select ループに入る、 という無駄が生じてしまっていた。

したがって、SSL_pending でデータが検知されることが多発するような場合は、 転送速度が著しく遅くなる。 例えば、stone の受信バッファを意図的に小さくすることによって OpenSSL 内のバッファに受信データが残りやすくして SSL 通信を受信してみる:

-X 512
-z key=key.pem
-z cert=cert.pem
localhost:22 localhost:12346/ssl --

「-X 512」オプションによって、受信バッファのサイズを 512 バイト (デフォルトは 2048 バイト) にしている。 12346番ポートで SSL 接続を受付け、 それを復号した上で、22番ポートへ中継する設定である。 続いて、

localhost:12346/ssl localhost:12347 --

という設定で stone を走らせて、12347番ポートで受付けた接続を、 SSL で暗号化した上で 12346番ポートへ転送するようにする。 上記二つの stone を実行することによって、 12347番ポートへ接続すると、 後者の stone によっていったん SSL で暗号化された上で、 前者の stone で復号されて 22番ポートへつながる。 つまり 12347番ポートで ssh 通信が行なえる。

前者の stone として stone 2.3a select 版を使うと、 ssh 転送が異様に遅くなる。

% scp -P 12347 /boot/linuz-2.6.16.18 localhost:/tmp/
...
linuz-2.6.16.18   100% 1211KB  11.3KB/s  01:47

延々 2 分近くかかってしまうが、 最新の stone.c 2.2.2.25 を使って select 版を作ると、 1 秒以内に転送が終わる。 また、stone 2.3a select 版であっても「-X 512」オプションを指定しなければ、 SSL_pending でデータが検知されるケースがほとんどなくなるので、 1 秒以内に転送が終わる。 なお、stone 2.3a epoll 版には、doReadWrite ループがなく、 全てメインループで処理を行なうので、 このような問題はない。

Filed under: stone 開発日記 — hiroaki_sengoku @ 18:51
2006年5月29日

ウォッチドッグ タイマ hatena_b

一週間ほど休暇で自宅を留守にしていたら、 運悪くちょうど半ばあたりで自宅の Linux サーバ (二台ある GCD ゲートウェイのうちの片方) がハングしてしまった。 きっかけは毎晩ハードディスの内容をバックアップするために動かしている rsync だったので、 メモリ不足 ? かなにかの原因でカーネルのバグを引き当ててしまったのか?

安定版でないカーネルを使っていて再びハングする危険もあるので、 早急にバージョンアップが必要なのだが、 その前に新しいカーネルで GV-MVP/RX2W を動かせるようにしないと... (^^;)
# ぱ研を参考にさせてもらっています (_O_)

GCD のゲートウェイは VRRP で二重化してあるので、 片方がハングしても問題無いのではあるが、 手動リセットするまでハングしっぱなしというのでは、 留守の期間が長いと二台ともハングする可能性を否定できない。
# UUCP スプールなど二重化されていないものもあるので、 全く問題が無いというわけでもない

そこでハングしてもなるべく自動的に復帰できるように ウォッチドッグ タイマ (Watchdog Timer) を仕掛けることにした。 つまり一定期間内にタイマがリセットされなければ、 ハングしたと見なして問答無用でカーネルを落とす仕掛けである。

ソフトウェアにどんなトラブルが起きても確実に再起動を行なわせるには、 ハードウェアで物理的にリセット スイッチを押すハードウェアを用いるのが 一番であるが、まずはお手軽にソフトウェア版を利用してみることにした。 ソフトウェアによるウォッチドッグ タイマの場合、 カーネル パニックが起きると当然機能しなくなるわけだから、 パニック時は自動的に再起動するように設定しておく必要がある。 rc.local 等で、

echo 60 > /proc/sys/kernel/panic
echo 1 > /proc/sys/kernel/panic_on_oops

を行なっておけば、パニック時は 60秒で再起動するようになる。

次に、ソフトウェア版ウォッチドッグ モジュール (softdog) をインストールする。 softdog.ko を /lib/modules/current 以下に置き、 /etc/modprobe.conf に以下の行を追加するだけ。

alias char-major-10-130 softdog
options softdog soft_margin=3600

ウォッチドッグ タイマというと、 普通は 60秒くらいに設定しておくものだとは思うが、 自宅サーバの場合、一時間くらいハング状態が続いてもそんなに困らない ;) のと、 あまりタイマの間隔が短すぎると、不用意に再起動してしまう恐れもあるので、 3600秒 (一時間) に設定している。 つまり一時間以内にタイマをリセットしないと、自動再起動が行なわれる。

後は適当な方法で、 /dev/watchdog に適当な文字 (ただし「V」を除く) を書込むだけである。 例えば、定期的に実行される sh スクリプトに、

echo "@" > /dev/watchdog

という行を追加しておくだけでよい。

Linux カーネルのドキュメント: linux/Documentation/watchdog/watchdog.txt には、

#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>

int main(int argc, const char *argv[])
{
        int fd=open("/dev/watchdog",O_WRONLY);
        if(fd==-1)
        {
                perror("watchdog");
                exit(1);
        }
        while(1)
        {
                write(fd,"\0",1);
                fsync(fd);
                sleep(10);
        }
}

というサンプルが載っているが、タイマをリセットするプログラムを 動かしっぱなしにする方法だと、 ハングの仕方によってはこのプログラムが動き続ける (つまり自動再起動が行なわれない) 危険がある。 私の自宅サーバの場合は、たとえカーネルが生きていても、 リモートから ssh ログイン出来ない状態なら使い物にならないわけで、 外部から ssh ログイン出来る場合のみタイマのリセットが行なわれるようにした。 つまり、外部から

ssh server "echo @ > /dev/watchdog"

に相当することを定期的に (一時間以内の間隔で) 行なえばよい。 この場合、/dev/watchdog に文字を出力する都度、 /dev/watchdog をクローズすることになり、

SoftDog: Unexpected close, not stopping watchdog!

というメッセージが syslog に出力されるので、 果たしてきちんとタイマのリセットが行なわれているのか不安になるが、 softdog モジュールのソースを見ると、 このメッセージが出力される場合は常に 「softdog_keepalive()」呼び出しが行なわれているので問題ない。

Filed under: システム構築・運用 — hiroaki_sengoku @ 07:51
2006年5月22日

ストックが増える積み重ねと、増えない積み重ね

成長する秘訣は、 今の仕事を捨てて自分を変えること」に トラックバックを頂いた。 曰く:

ものの考え方にはストック…積み重ねにより大きな利益を得るっていうのもあって、 ストック、フローのどちらをよしとするかはケースバイケースなのでしょうが、 今の時代はフロー的なことが求められるのですかね。
...
ただ、エンジニア稼業というのはスキルの蓄積が実績として重要視される ストックな生き方を要求されることも多いかな。

蓄積には、ストックが増える積み重ねと、 増えない積み重ねがあるような気がしている。 ストックが増えるのであれば蓄積は重要だが、 ストックが増えなくなってきた仕事は捨てることも検討すべきだと思う。

そうでないと、 「これだけいろいろ経験を積んでスキルも蓄えたのだから、 当然評価されてしかるべきだ」という思考停止状態に陥ってしまう。 事実、面接で長大な職務経歴書を提示して、 一つ一つ説明して下さるかたがいらっしゃるが、 そんなものよりたった一つの深い経験の方が重要なこともあるのだ。

「ストック、フローのどちらをよしとするか」という話にしてしまうと、 当然重要なのはストックで、フローはそのオマケに過ぎない、 ということになってしまうが、 そういう問題ではない気がする。 ストックが大事なのは「エンジニア稼業」に限らず、 どんな職種でも同じなのではなかろうか。

Filed under: 技術者の成長 — hiroaki_sengoku @ 11:06
2006年5月19日

VPN-Warp relayagent フリー ダウンロード hatena_b

VPN-Warp relayagent を、この日記の読者のみなさま限定で公開します。
下記リンクからダウンロードできます。

上記パッケージは、VPN-Warp を読者のみなさまに評価して頂くことを 目的としておりますので、 使用した結果の影響につきましては責任を負いかねます。 以下の入門編、応用編をよくお読みの上、 万一の事態を想定したご利用をお願いします。

...とは言っても、もちろん (^^;)、 内容については万全を期して作成しております。 なにかお気付きの点がありましたら遠慮無くご指摘下さい。

  • 入門編 (1) VPN-Warp の特長: ふつうの SSL VPN と比べて
  • 入門編 (2) VPN-Warp の特長: ssh のポートフォワードと比べて
  • 入門編 (3) stone & relayagent の設定方法
  • 入門編 (4) stone の代わりに OpenSSL の s_client を使ってみる
  • 入門編 (5) stone の代わりに普通の WWW ブラウザを使ってみる
  • 入門編 (6) WWW ブラウザを使う場合の注意点
  • 応用編 (1) VPN-Warp 試用ライセンス提供開始のお知らせ
  • 応用編 (2) 盗まれたノートPC を外部から操作する方法

VPN-Warp を利用する際に必要となる SSL 証明書に関しては、 上記「応用編 (1) VPN-Warp 試用ライセンス提供開始のお知らせ」を参照願います。

Filed under: システム構築・運用 — hiroaki_sengoku @ 07:17
2006年5月18日

休暇でサンフランシスコへ行きます

明日から休暇です。 ここ 10年ほど、年2回のペースで、休暇をとって海外に行っています。 この 10年間の間に(株)ケイ・ラボラトリー (当時の社名) の設立があったり、 その他もろもろ超忙しい時期もあったのですが、 この年2回の休暇だけは欠かさず続けられています。 周囲の方々の理解があればこそと、感謝しております (_O_)。

今回はサンフランシスコに行きます。 ちょうど 6年前、ケイ・ラボラトリー設立直前に、 JavaOne に行くためにサンフランシスコへ行ったので、 それ以来のサンフランシスコです。 当時書いた日経Linux の連載の注釈から引用:

おまけに,この原稿の締め切り直前に海外出張の予定が入っています。 これは飛行機の中で書けっていうことでしょうか。 幸い,ビジネス・クラスなので, (その気になれば)原稿の1本や2本,余裕で書けることでしょう... と思っていたら飛行機がやたらに揺れて, 原稿を書いていると酔いそうになったので, 早々にノートPCの電源を切って寝てしまいました。

今回は休暇なので JavaOne のことは全く念頭になかったのですが、 ナニゲなくJavaOne のページを 見ると、今年は 5/16 ~ 5/19 なのですね。 明日 5/19 出発すると、到着するのは (日付変更線を越えるので前日になるから) 5/19 の朝になり、JavaOne を見に行けてしまうようです (もちろん行きませんが ^^;)。

Filed under: その他 — hiroaki_sengoku @ 08:32
2006年5月17日

断片的な知識と体系的な知識

CTO日記に書いた 「断片的な知識と体系的な知識」を、沢山の方々に読んで頂けた。

この季節、新卒(見込み)の学生さんを数多く面接してきたのですが、 新卒の段階で既に とてつもなく大きな差がついていることに改めて驚かされました。
今後大きく成長する可能性が感じられる人と、 早くも既に成長の限界が見えてしまっていて、 可能性がほとんど感じられない人、という点では、 もう既に逆転不可能とさえ思えるような大差がついてしまっています。
可能性が感じられる人、というのはつまり、 自分が何をしたいか明確に分かっていて、 かつその分野の体系的な知識を身につけている人たちです。 現時点ではそんなに多くを習得しているわけではないにせよ、 体系全体を理解していますから、自分がどこまで知っていて、 未知の領域がどのくらいあるか、感覚でつかんでいます。

じゃ、オマエは学生の時どうだったんだ、という声が聞こえてきそうなので、 私の学生生活を振り返ってみる。 コンピュータの分野が好きだと思ったのは中学一年の時で、 体系的な知識を学んだのは大学の専門課程に進んでからである。

- o -

私が初めてコンピュータに触れたのは、中学一年生の終わり頃である。 「マイコン部」なるものがあって、 3台のCommodore PET 2001を 20人以上の部員で使っていた。 しかも「部活動」は週一回 50分ほどだったと記憶しているので、 PET 2001 に触れるのは、二週間に一度、25分だけ、 しかも二人で一台を使う形だった。 最初のうちは BASIC を使って簡単なゲームなどを書いていたが、 6502 のインストラクションセットをどこからか見つけてきて (どこで見つけたのだろう? 当時はその手の資料を中学生が見つけることは、かなり難しかったはず)、 ハンドアセンブルしたコードを BASIC の poke 文でメモリに書いて 実行させて遊んだりした。

初めて BASIC の入門書を読んだとき、 将来プログラミングを仕事にできたらどんなにいいだろう、 と思ったのを今でもはっきり覚えている。 今からは想像もつかないが、 1978年当時の中学生にとって、 一人一台マイコン (当時の呼び方 ;) を占有できるなんてことは、 とうていかなわない夢だった。

高校になってようやく MZ-80K2E を購入した。 日経Linuxに執筆した連載の枕から引用:

私が最初に購入したコンピュータは, シャープのMZ-80Kシリーズの最後の機種K2Eでした。 RAMは32Kバイト,CPUはZilog Z-80 2MHzで, BASICインタプリタをROMではなく, カセット・テープから読み込む方式であるため, BASIC以外の言語への対応が容易という, 当時としては画期的なパソコンでした。 BASICライクなアセンブラBASE-80を使って, ゲームやモニターを作っていたことを思い出します。 その後,CP/Mを移植するためにBIOSを記述する際にも, BASE-80を使いました。

高校時代は、マイコンのハードウェアに興味を持ち、 MZ-80K2Eのプリント基板の配線を目で追って回路図を起こし、 それをもとに Programmable Character Generator や Z80 DMA を追加するなどの改造を行なった。 また、 コンピュータ以外の分野では、 物理や哲学に興味を持ち、 1年に百冊以上読む、という目標を立てて 手当たり次第に読書したこともある。

コンピュータにのめり込んだ高校時代だったため、 大学に進むとき、物理, 数学, 哲学などの道に進むことも (一瞬 ;) 考えたのであるが、 コンピュータを学んだといっても所詮は独学に過ぎず、 まだまだ学ぶことがあるはずと思い直し、情報工学科に入学した。

1回生のときは、Z-80 を使ったコンピュータの手作りに熱中した。 ユニバーサル基板を何枚か使って、 それぞれ CPU ボード、I/O ボード、DRAM ボード、などを順に作り、 MZ-80K2E をキャラクタ端末にして CP/M を走らせた。 2回生のとき、ソフトウェアハウスでアルバイトするようになり、 MacVJE などを開発した。 私にとって初めての、 まとまった量のプログラミング (C 言語で 5万行くらい) 体験だった。

このあたりまではあくまで独学であり、 断片的な知識の寄せ集めである。 もっとも、現在のようなインターネットなどなかったから、 全て (数少ない) 専門書を読みあさって仕入れた知識であり、 Web ページで得られる知識よりは、マシだったかもしれない。 当時のコンピュータ関係の専門書は、 大型書店 (大阪梅田の紀伊國屋や旭屋など) にしかなく、 それも数えるほどしかなかった代わり、 ほとんどがマトモな本だった。

3回生になって初めて情報処理の基礎を学んだ。 今まで経験則で回路図を設計していたのが、 カルノー図を使うとシステマチックに最適な回路を設計できる、 ということを学んで感動し、 独学の限界を思い知った。 なにせ、それまではコンピュータの設計というと 数週間かけて行なうものだと思っていたのに、 教科書で説明されている方法だと数時間しかかからないのだ。 私が初めて大海を垣間見た瞬間かもしれない。 そのとき読んだ教科書がこれ:

Switching and Finite Automata Theory
Zvi Kohavi
McGraw-Hill Education ; ISBN: 0070993874 ; (1979/03/01)

ボロボロになるまで読んだ (まあ、もともと製本が粗末というのもあるが ;)。

Filed under: 技術者の成長 — hiroaki_sengoku @ 13:55
2006年5月17日

無料セミナ: 内部統制を巡る国内外の動向と IT 統制に係るクリティカルサクセスファクター

この日記を読んで頂いているみなさまにとっても、 個人情報漏洩対策や内部統制の整備は切実な問題だと思うので、 弊社 (KLabセキュリティ) 主催のセミナのご紹介を... 無料ですので、関心のある方は参加されてはいかがでしょうか (定員 40名なので、〆切られちゃったらごめんなさい)。

# 業務連絡。その1
# こーいうセミナを開催するなら私にも教えておいてください > マーケ本部

内部統制を巡る国内外の動向と IT 統制に係るクリティカルサクセスファクター
日時: 2006 年 5 月 30 日 (火) 13:30 ~ 16:10
会場: 株式会社アズジェント 1F ソリューションショールーム
東京都中央区日本橋小網町19-7 (最寄り駅/地図)

# 「クリティカルサクセスファクター」って何?という質問は私にしないで...(^^;)

以下、 申し込みページより引用:

個人情報保護法が 2005 年 4 月に施行され、個人情報に限らず、 重要な「情報」に対する資産価値としての認識が高まる一方、 情報漏えいや様々な企業の不祥事が頻発しています。 そうした中、2006 年 5 月には、新会社法が施行され、 また、2008 年に導入が予定される [日本版 SOX 法] など、 企業の内部統制の強化が要請されています。 業務が IT に大きく依存している現在においては、 内部統制の目的を達成するために、 IT 統制が不可欠な要素となります。 内部統制、IT 統制に求められているのは、 「アクセス制御」「暗号化」「ログ管理・分析」等の技術的対策のみならず、 業務リスクを睨んだ業務システムの設計や「監査」に対応するための仕組みです。

本セミナーでは、内部統制強化の動向や情報セキュリティ、 コンプライアンスなどの対策に必要なリスク管理を紹介します。

また、セキュリティポリシー遵守のための従業員への「牽制・抑止」効果と、 各部門への「指導・警告」、 および企業努力として監査の記録を残し、 経営層、Public に進捗をレポートできるツールとして 「個人情報スキャナー P-Pointer」のご紹介と、 導入事例をご紹介します。

Filed under: 技術と経営 — hiroaki_sengoku @ 06:26
« Newer PostsOlder Posts »