仙石浩明の日記

仕事をやりかけのまま中断する。 たくさんの仕事がやりかけのまま溜まっていることになる。

やりかけのまま中断しているものは、いつでも再開できるように、

書きかけのメールなら、

メーラで開きっぱなしでいつでも送信できるように

書きかけの文書なら、

いつでも続きが書けるようにアプリケーションで開きっぱなしに

開発途中のプログラムなら、

いつでもデバッグできるようにデバッグ環境を立ち上げっぱなしに

アイディアを練るときは、

いつでも思いついたことをメモできるように書きかけのメモを身近に

チャットしようとして返事がないときは、

チャットウィンドウを開きっぱなしにしておく

WWW で調べものをするときは、

とりあえず検索して関係のありそうなページを開くだけ開いておく

効用1: 隙間時間を有効に活用できる

一つの仕事を一気に完了させようとしなければ、 とりあえず始めるだけ始めるということでよしとするなら、 隙間時間でも始めることはできる。 あるいは、やりかけの仕事を少しだけ進めることなら、 隙間時間でも活用できる。 また、待ちが多い仕事は多重化することによって、 同時に進行させることができる。

効用2: 心理面

一つの仕事を、ゼロから始めるのは敷居が高い。 やりかけている仕事の続き、ということだと敷居が低い。 一つの仕事を完了させようとすると、 細かいところまで神経を配る必要があって大変。 細部は後で考えればいいやと割り切れば気が楽。 逆に、ほとんど完成していて細部の仕上げだけの仕事は どんどん片付けられるので気分的に楽。

効用3: 同時に考えよう

無意識の思考の活用。 仕事をやりかけのまま寝かせておくと、 いい考えを思いつくことが多々ある。 書きかけの文章を寝かせておくと、 適切な言い回しを思いつくことが多々ある。

4/3追記: 同じような趣旨の日記を見つけた。
　結城浩の日記
　複数の仕事をすることについて
　勉強日記の書き方

バックボーンには導入が進むものの、 一般ユーザには一向に普及する兆しのない IPv6。 可能性があるとすれば、安価なブルータの普及が鍵だろうと思う。

ADSL や FTTH によって安価にインターネットへ常時接続できるようになり、 また一家に複数の PC を持つことが普通になってルータも普及してきた。 このルータに、IPv6 ブリッジ機能が標準で搭載されるようになれば、 IPv6 への移行は格段に容易になるに違いない。 つまりユーザが意識しなくても NAT の内側の LAN 上の PC で IPv6 が使えるようになる。

実際、NTT東日本のフレッツドットネット対応を謳って、 IPv6 ブリッジ機能を持つ安価なルータが多数販売されている。

IPv6対応(フレッツドットネット対応=IPv6ブリッジ機能付き) ルータ一覧

IPv6 が IP に比べて優れた点があるとは思わないが、 IP の「やり直し」という意味はあるだろう。 IP アドレスの割当問題しかり、 無防備な PC の氾濫しかり。

IP が提案された当時、現在のような普及状況は誰も予測していなかったわけで、 今、やり直すことができるのなら、もっと効率的なアドレス割当ができるだろう。

IP スタックが OS に標準搭載されるのが一般的になり始めた頃、 現在のようなウィルス蔓延の可能性を、 アプリケーション開発者の大半が意識できていなかったわけで、 今、やり直すことができるのなら、IP 通信を受付けることの危険性を 認識した上での開発ができるだろう。

OS って何だろう。

言うまでもなく OS といえば、 コンピュータのリソースを管理するものであり、 またハードウェアの仕様の差を吸収して、 異なるハードウェア上で同一のプログラムを 走らせることができるようにするソフトウェアである。

ただ、OS といっても、 ほとんどカーネルと呼んだほうがいいような場合もあるし、 ミドルウェアの機能をまで含んで、 アプリケーションの操作性を統一するようなものまである。 さらには Windows における Internet Explorer のように、 従来はアプリケーションと思われていたものまで OS としてしまう場合すらある。

わたしが初めて使った OS (と呼べるかどうかは微妙だが) は、 CP/M だった。自作 PC (今風に言う自作 PC ではなく、 回路の設計から半田付けまですべて自分で作る PC である。 CPUなどはもちろん LSI を使うが、 ほかは汎用 TTL でロジックをくみ上げているので、 今風に言うチップセットは存在しない) 用の BIOS を スクラッチから開発して、市販されていた CP/M を移植した。

低機能な OS をハードウェアレベルから くみ上げるところから始めたということもあって、 OS というとわたしはカーネルに近いレベルを想定してしまう。一方、

システム管理コラム集 実践してみてわかったことシリーズその1

などを読むと、 あらためて人によって OS という言葉から思い浮かべるものが 異なるものだと実感する。 私にとっては Linux の各ディストリビューションごとの差異など あまり気にしなかったりするのだが、 最近の人にとっては、ディストリビューションが違うと、 異なる OS ととらえることもあるのだろう。

ちなみに、私の自宅サーバは、 10年以上前にインストールした Slackware をベースにしている。 ベースにしているといっても、 カーネルや libc をはじめとして ほとんどすべてのプログラムをアップデートしているので、 元のディストリビューションの痕跡は皆無といっていい。 自作ディストリビューションと呼べるかもしれない。 これを私が管理する全ての Linux マシンにコピーして使っている。

会社 (KLab(株)) のサーバは、私の直轄のチームが管理していて、 こちらはさすがに自作ディストリビューションというわけにはいかず、Debian をベースにしているが、 コアの部分は KLab 独自の拡張を加えている。 つまり誰が作っても同じようになる部分は 既存のディストリビューションを使うことによって「手を抜き」、 コアの部分は独自に開発して運用コストを下げたり、 耐故障性能を向上させたり、パフォーマンスを改善したりしている。

昨日、「ガニメデの優しい巨人」の一節を引用したので、 帰宅してから思わず昔読んだ本を取り出して読み出してしまった。

「わたしは、偶然の一致というのを信じない」

という言葉を 44ページ目に発見。20年以上前に読んだ本なのだが、 当時何度も繰り返し読んだので、 いまでも細部の言い回しなどがどんどん思い起こされる。 原著で読んだこともあるのだが、 日本語訳をほとんどそらで語れるほどだったので、 英語で読んでもスラスラ読めた。ちなみに上記セリフは、原著では

“I don't believe in coincidences,”

となっている。英語だと言い回しのバリエーションがないのだろうか、 誰の発言でも全く同じセンテンスになってしまう。 ジェイムズ・P・ホーガンといえば、真っ先に思い出すのが次の一節:

太陽の連続的な高度低下に伴った大気による短波長の顕著な散乱は、六百五十ナノメートル以下の選択的伝達をもたらし、家畜化した羊類を飼う素朴な牧夫たちの心に非合理的な陶酔感の傾向を生み出す

原著では、

Pronounced atmospheric scattering of shorter wavelengths, resulting in selective transmission below 650 nanometers with progressively reducing solar elevation, produces a tendency toward irrational euphoria among primitive herders of domesticated ovines.

私が好きな SF の主人公のセリフに、こういうものがある:
「わたしは、偶然の一致というのを信じない」
ガニメデの優しい巨人
ジェイムズ・P・ホーガン (著)

ある事象の直後に、本来直接は関係ないはずの別の事象が起きたら、 両者の間に、なんらかの因果関係があるはず、と考えるのが、 「偶然の一致を信じない」人のとるべき態度であるし、 この考え方は、技術者や科学者にとっての鉄則だと思う。

同じ事象を観測していても、偶然の一致を見つけ出せるか、 それとも代わり映えしない観測データと思って見過ごすかが、 大きな分かれ目になりそうだ。

プログラムの動作ログも同じ。同じログを見ていても、 そこからどれだけの内容を汲み取れるかは、 技術者の資質に大きく依存すると思うし、 スキルアップを目指すなら、自分より優れている技術者が、 そのデータから何を引き出すことができて、 自分がどうしてそれを引き出すことができなかったのか、 詳細に省みるべきだろう。

epoll 対応によって高速化した stone の新バージョンのベンチマーク。

stone 2.3

stone 2.3 公式リリース版

stone 2.3a

現時点では CVS にのみ登録されている、次のバージョン:
$Id: stone.c,v 2.2.2.12 2006/03/26 07:30:20 hiroaki_sengoku Exp $

apache

stone なしで直接 httpd へアクセスして測定。

select 版に比べ、epoll 版は、転送速度で 100倍近い性能。 apache への直接アクセスに比べたオーバヘッドは、27% 程度。

# 追記: 性能向上の理由は epoll 化とは別のところにあったことが後日判明

測定条件:

senri% stone -rn localhost:80 2345 >& /dev/null
asao% ab -n 1000 -c 10 http://senri:2345/health
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.121.2.4 $> apache-2.0
Document Path:          /health
Document Length:        131 bytes
Concurrency Level:      10

req/sec

Requests per second [#/sec] (mean)

ms/req

Time per request [ms] (mean, across all concurrent requests)

KB/sec

Transfer rate [Kbytes/sec] received

stone (従来は select を使用) の epoll 対応の続き。

typedef struct _Pair {
　　int common;
　　struct _Pair *pair;
　　...
　　SOCKET sd;　　/* socket descriptor */
} Pair;

...

　struct epoll_event ev;
　ev.events = EPOLLONESHOT;
　ev.data.ptr = pair;
　epoll_ctl(ePollFd, EPOLL_CTL_ADD, pair->sd, &ev);

といった感じで、 ePollFd にソケットディスクリプタを Pair 構造体と一緒に登録する。 そして、epoll_wait でイベント発生を待つ。

　struct epoll_event evs[EVSMAX];
　...
　ret = epoll_wait(ePollFd, evs, EVSMAX, timeout);

配列 evs には、 発生したイベントが epoll_ctl で登録した構造体とともに 格納されるはずだが、

　common = *(int*)evs[i].data.ptr;

などと構造体のデータを取り出そうとすると、 Segmentation violation が発生することがある。 しかも、デバッグ環境では正常に動くのに、 GCD のゲートウェイ上の設定環境で動かすと、 数分程度で Segmentation violation が発生してしまう。

なぜ期待したデータが得られないのかと、 stone のソースコード全体を見直すことに... しかし問題は見つからず。 epoll の仕様に見落としている点があるのかと思って マニュアルを読み直したり、 挙句の果てに、 Linux のカーネルの epoll 周辺のソースコードをながめたりした。

ptr の値が期待したものと異なる場合があるのかと思って、 epoll_ctl で登録したポインタと、 epoll_wait で取り出したポインタの値を表示させてみると、 予想に反してポインタのアドレス自体は正常のようだ。

早朝、このような stone のデバッグをやっていたのだが、 出社の時間が迫っていたので、作業を中断して出かける。

意識した思考はとても遅い。 どのくらい遅いかというと、 言葉に出して思考の筋道を話すことができるくらいだから、 推論の 1ステップに数秒かかったりする。 しかも、脳の短期記憶は 7+α しか覚えられないと言われるから、 中間結果を覚えておく容量もとても小さい。 だから、紙に書き出したり、カードを使って考えたりする。 書いたりカードを並べ替えたりしなければならないので、 さらにスピードが遅くなる。

では、なぜ人は、 コンピュータ顔負けのスピードで思考できるかといえば、 無意識に膨大な推論を行えるからだろう。 よく「ひらめき」とか表現されるが、 要は無意識に行った推論の結果が意識にのぼるから、ひらめく。

同時に一つのことしか考えられない、というが これは意識した思考のこと。 意識は (多重人格者でもなければ ^^;) 一つしかないし、 一つの意識では、7+α の短期記憶しかないから 一つのことしか考えられない。

無意識の思考にはこのような制限はない。 いくつでも同時に思考を走らせ、 結果が得られたらそれを意識にのぼらせればよい。

私が初めて、同時に複数の思考が行われたのを意識したのは、 大学入試のときだった。 早稲田大学の数学の試験だったと記憶しているが、 設問を順に解いていったが、 ある設問を考えていく途中で、行き詰ってしまった。 あまり一つの設問に時間をかけすぎるのは得策でないので、 その設問は後回しにすることにして、次の設問に移った。

次の設問を解き終え、 さらにその次の設問を解いている時だっただろうか (なにぶん 20年以上昔の話なので詳細は覚えていない)、 突然、さきほど行き詰った設問の解き方が頭の中にひらめいた。 そのときは別の設問に集中していて、 少なくとも意識からは完全にその設問のことは忘れ去っていたにも かかわらず、である。

そのときの「ひらめき」の体験があまりに鮮明だったために、 今でも覚えているし、 どうやったら無意識の思考をより活性化させることができるか、 考えるようになった。 意識しなくても思考が続くように、 しかも有意な結果が導かれるようにしなければならないのだから、 そんなに容易ではないが、 日頃から深く考え続けているような事に関しては、 ひらめく頻度が高いように感じる。 おそらく無意識で考え続けているのだろう。

アイディアを次から次へとひらめく人は、 無意識の思考が多数同時に進行しているのだと思う。

VRRP のマルチキャスト (VRRP Advert) を取りこぼすのは、 NIC が悪いのかも、 と思って別NIC を使用するように変更してみたのだが、 相変わらずスタンバイが勝手にアクティブに昇格したがる。

アクティブ側から見ると

Mar 22 12:58:36 asao Keepalived_vrrp: VRRP_Instance(VI)
                     Received lower prio advert, forcing new election
Mar 22 12:58:36 asao Keepalived_vrrp: VRRP_Instance(VI)
                     Sending gratuitous ARPs on eth1 for 192.168.0.254

スタンバイ側から見ると

Mar 22 12:58:30 senri Keepalived_vrrp: VRRP_Instance(VI)
                      Transition to MASTER STATE
Mar 22 12:58:31 senri Keepalived_vrrp: VRRP_Instance(VI)
                      Entering MASTER STATE
Mar 22 12:58:31 senri Keepalived_vrrp: VRRP_Instance(VI)
                      setting protocol VIPs.
Mar 22 12:58:31 senri Keepalived_vrrp: VRRP_Instance(VI)
                      Sending gratuitous ARPs on eth1 for 192.168.0.254
Mar 22 12:58:31 senri Keepalived_vrrp:
                      Netlink reflector reports IP 192.168.0.254 added

Mar 22 12:58:36 senri Keepalived_vrrp: VRRP_Instance(VI)
                      Received higher prio advert
Mar 22 12:58:36 senri Keepalived_vrrp: VRRP_Instance(VI)
                      Entering BACKUP STATE
Mar 22 12:58:36 senri Keepalived_vrrp: VRRP_Instance(VI)
                      removing protocol VIPs.
Mar 22 12:58:36 senri Keepalived_vrrp:
                      Netlink reflector reports IP 192.168.0.254 removed

tcpdump で確認すると、 VRRP Advert パケットはスタンバイ側に届いているのだが、 keepalived がそれを読めないらしい。 勝手にアクティブになるくせに、 5秒程度で Received higher prio advert して おとなしくスタンバイに戻る。

アクティブになったときに、 (自分がゲートウェイになったつもりで) 本当のゲートウェイへのルーティングを削除してしまうと、 外部への通信が途絶してしまうので、 PPPoE が成功したときのみルーティングを変更するようにした。 これで、勝手にアクティブになったとしても PPPoE が失敗する限りは 実質的に何も変わらないようになった。

keepalived を単なる死活確認にしか使っていない (しかも死んでないのに死んだと誤判断することあり) わけで、 モッタイナイお化けがでそうだ (^^;)。

コバヤシマル テストという戦術シミュレーションがある。 Startrek 映画版 2作目の冒頭で登場する、 艦隊士官候補生のための試験であるが、 (敵の火力が圧倒的であるために) 勝つ方法がない。 そして、勝つことができたのは唯一、カークだけで、 勝てるようにシミュレーションプログラムを細工した、という話。

テストには解があることが多いが、 現実問題だと解があることのほうが稀で、 問題の中だけで考えていては解決不可能なことが多い。 もちろん問題を正面からとらえて解決策を考えることも重要であるが、 一歩視点を引いてみて、問題の枠組み自体を変更できないか、 考えてみることも重要。

問題の解決に集中しすぎると、 問題そのものについて考える余裕がなくなってしまう。 いま取り組んでいる問題は、 どのようなルールにしたがっているのか思いをめぐらせてみると、 そのルールを変えるにはどうしたらいいかが見えてくるかもしれない。

sshによるバックアップ回線の監視を仕掛けて一日、 タイムアウト(監視プログラムには 10秒のalarmを仕掛けている) エラーが発生。

なぜかと思って調べてみると、 同一IPアドレスからのsshアクセスが多い、 という理由でブロックされてしまっていた (^^;)。 ssh攻撃が多い昨今、GCDのサーバには、 次のようなフィルタが仕掛けてある:

iptables -N block_ssh 2>/dev/null || iptables -F block_ssh
iptables -N ssh 2>/dev/null || iptables -F ssh
iptables -A block_ssh -j LOG --log-prefix block_ssh: \
	-m recent --name block_ssh --set
iptables -A block_ssh -j DROP
iptables -A ssh -j REJECT -p tcp --syn \
	-m recent --update --seconds 600 --name block_ssh
iptables -A ssh -j block_ssh -p tcp --syn \
	-m recent --rcheck --seconds 60 --hitcount 5 --name syn_ssh
iptables -A ssh -p tcp --syn \
	-m recent --set --name syn_ssh
iptables -A ssh -j ACCEPT

# この設定は http://d.hatena.ne.jp/hirose31/20050920/1127208718
# を参考にさせて頂きました (_O_)

つまり 1分間に 5回以上、同じIPアドレスから ssh接続があると、 10分間ブロックする。 監視元IPアドレスが、いったんブロックされると、 毎分接続を試みるわけだから、ずっとブロックされたままになる。 あわてて、監視元IPアドレスをブロック対象からはずした:

iptables -I ssh -j ACCEPT -s 60.32.85.216/29

GCD は、bフレッツでインターネットに接続している。 普通に PPPoE しているほか、 フレッツ・ドット・ネットを使っているので、 ネイティブ IPv6 でも外部から (といっても、フレッツ・ドット・ネットを使っているサイト限定だが) 接続できるので、 PPPoE がこけた (設定変更をミスったときなど) ときでも リモートから復旧させることができる。

普通はこれで十分なのだが、さらに念のためということで、 フレッツADSL でもインターネットへ接続して バックアップ回線としている。 bフレッツ側が全滅しても、 ADSL経由でログインできるようにしてある (もちろん、それぞれ別系統のハブに接続してあるし、 ログイン先のサーバは複数ある)。

このバックアップ回線は滅多に使わないので、 いつのまにか不通になっていても気づかないかもしれない、 ということで、さくっと (設定込みで 30分くらい) 監視プログラムを仕掛けた。 単に bフレッツ→インターネット→フレッツADSL 経由で ssh ログインするだけのプログラムを cron で定期的に走らせるだけだが、 不通になっていることに気づかない、という事態は避けられるだろう。

技術者にとって一番重要なのは、「分からない」と言える能力。 太古の昔から、無知の知と呼ばれているもの。

なにが分かっていないか、分からなければ勉強のしようがない。 分かったつもりで済ませていては、いつになっても真の理解は不可能。

小学生のころ、私は答案に平気で「デタラメ」を書いていた。 デタラメを書いているという意識ではなく、 分かったつもりになって正しい答えを書いているつもりだった。 あまりに自由な発想でデタラメを書くので親が心配したほど。

ところが、中学生のころ、同級生にとても優秀な奴がいた。 彼は、一を聞けば十を理解した。 あまりに早く分かったというので、信じられずに 残りの九を説明しようとすると、先回りして答えられてしまった。

そんな彼が、「分からない」を連発する。 つまり分かった、と言うのも早いが、 分からない、と言うのもとても早かった。

そんな彼を見て、私は「分からない」と言えるのは カッコイイことなんだと思った。 なんとかして自分も、「分からない」と言えるようになりたい、 と思った。

自分が本当に理解しているのか、 それとも単に分かったつもりになっているだけなのか、 常に自省する習慣が身についたのは、 彼のおかげだと思う。

GCDの二台のゲートウェイのうちの片方 (senri.gcd.org) の 1000baseT NIC (eth0) が時々マルチキャストをとりこぼす。 二台のゲートウェイは、 VRRP で アクティブ・スタンバイ構成になっているのだが、 senri がスタンバイのときに、 もう片方 (asao.gcd.org) からの VRRP Advert をとりこぼしてしまい、 勝手に アクティブへ昇格しようとする。 一日〜数日に一度くらい、このとりこぼしは起きるようだ。 アクティブになっても、 OCN へ PPPoE しに行って失敗して (asao が PPPoE しているから) スタンバイへ戻るので、まあ実害はないのだが、 あまり気持ちのよいものではない。

eth0 で VRRP するのをやめて、 eth1 (100baseT NIC) で VRRP するようにしてみた。 eth1 は PPPoE (と、フレッツ・ドット・ネットのネイティブ IPv6) 専用で、 IPv4 アドレスは割り当てていないのだが、 マルチキャストなので VRRP Advert は受け取れるようだ。

keepalived.conf はこんな感じ:

vrrp_instance VI {
    state MASTER
    interface eth1
    garp_master_delay 10
    virtual_router_id 33
    priority 230
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass XXXX
    }
    virtual_ipaddress {
        192.168.0.254/24 dev eth1
    }
    preempt_delay 300
    notify "/etc/rc.d/vrrp_notify"
}

アクティブの時の asao:

asao.gcd.org:/ # ip addr show dev eth1
4: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
　　link/ether 00:a0:cc:xx:xx:xx brd ff:ff:ff:ff:ff:ff
　　inet 192.168.0.254/24 scope global eth1
　　inet6 2001:c90:1448:200a:2a0:ccff:fexx:xxxx/64 scope global dynamic
　　　　valid_lft 2591983sec preferred_lft 604783sec
　　inet6 fe80::2a0:ccff:fexx:xxxx/64 scope link
　　　　valid_lft forever preferred_lft forever

人は誰しもすぐ忘れるもの。 なにかやりたいことがあっても、すぐ忘れる。 せっかく空き時間があっても、そのときはやりたいことを忘れている。 そのくせ、やりたいことはあるんだけど、時間がない、などと言う。

ほんの一行、いや一単語だけでもメモに書いておけば、 たいていの場合、そのとき何を考えていたか、思い出せる。 その一単語を、空き時間ができたときに膨らませていけば、 チリも積もればなんとやらで、一つの成果となる。

この blog も、そんなメモのつもりで書いていきます。 で、空き時間をつかって内容を膨らませていき、 近日オープン予定の blog ページで公開する予定。

4/5追記: 仙石浩明CTO の日記をオープンしました。

セキュリティって、 分かっている人にとっては、 条件反射というか無意識のうちに意識してしまうというか、 あまりに自然な感覚だけに、 分かっていない人にどう説明するのがいいのか、とても難しい。

select(2) は、/usr/include/bits/typesizes.h に

#define __FD_SETSIZE 1024

などと書いてあって、 1024個以上の socket を扱えない。 poll(2) を使えばいいのだが、 Linux で使えれば十分という気もするので、 epoll(2) を使ってみることにする。 土曜の晩と、日曜の早朝をつかって一気にコーディング。

エラー処理など、細かい点はまだだが、とりあえず動いているようだ。 udp 中継は、格段に速くなる。 tcp 中継は、もともとセッションごとに thread 立てて 2socket だけで select していたので、オーバヘッドは大きくない。 epoll 化してもあまり速度は変わらない。

久しぶりの stone デバッグ。

SSL_accept に時間がかかり、 かつ SSL_accept に失敗するときのみ、 中継先への socket を閉じないというバグ。

localhost でテストをしている限り発覚しないし、 lsof などを使って閉じていない socket を見ない限り なかなか気づきにくい。

$Id: stone.c,v 2.2.1.8 2006/03/09 10:13:02 hiroaki_sengoku Exp $

まずは、テストから...

This is a test article, sorry.