ホーム » 2006 » 7月

月別アーカイブ: 7月 2006

2006年7月
« 6月   8月 »
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

最近の投稿(電子情報)

アーカイブ

カテゴリー

電話番号非公開の電話連絡網

電話番号非公開の電話連絡網

緊急連絡の手段として、こういうのもできたらしい。 でも私自身、保育園やら学校行事で役員とかにつかまって、 他の保護者とそれなりに電話番号をお互いに知ってるから、 『そこまでして電話番号隠したいかぁ?』 というのが本音。
そこまで他人を信用できない世界もいやだなぁ….

転送系の電話って相手も混乱するって…

でもこういう転送系のサービスだと、 同じクラスの保護者とはいえ想定外の人から電話がかかってくる訳だし、 一瞬、『こぃつ誰だっけ?』状態になり、相手も混乱するだろうな。

安全講習AEDの使い方

教員むけ安全講習にてAEDの使い方の説明を、 赤十字病院の看護師さんよりうける。 熱中症や加呼吸の話もあった。 後半では、人工呼吸の練習用人形+練習用 AED 装置を使った実習を、 運動系クラブの代表の学生さんたちと一緒に受けました。

Debian GNU/Linux 4.0 が 12月に

Debian GNU/Linux 4.0 が 12月に

プロジェクト名 testing(etch) にて開発が進んでいた Debian の最新ディストリビューションが 12月に出るそうだ。stable(sarge) は思ったより短命だったか… AMD64サポート,Kernel-2.6.17,gcc-4.1,X.org 等が目新しいらしい。
# updateが面倒と感じるのは、年をとったのかぁ…

とはいいつつ、自宅サーバは unstable(sid) も含めて入れているけど、 サーバ系のソフトでは大きい変化は無いから、移行もスムーズに終るかな…

利用者確認要求への応答時間

平均応答時間は 41.8 分(7/18の豪雨警報の場合)

2006-07-21-emc-alive.GIF

利用者確認要求への返答までの時間を日毎に平均値を求めてみた。 応答までの平均時間は、7/18:41.8分(豪雨警報),7/16:46.3分(防災訓練)であった。 事前の連絡や豪雨の最中であったため、平均応答時間は短く45分程度であるが、 それ以外では100分を越えている。特に7/4に不審者出没で応答の多かった事例では、 143分を要している。これから緊急連絡が届くことを意識していれば、早い時点で 内容を確認するが、通常時では内容確認までに遅れがあることがわかる。

常に携帯を利用している人はレスポンスが早い

2006-07-21-emc-alive2.GIF

次に応答時間までの時間でヒストグラムを作成した。 これから、2分以内で応答する人は、全体の25%〜30%を占め、 常に携帯を持ち「携帯の情報アクセスに慣れた人」と思われる。 連絡を期待している豪雨警報の事例と、不意討ちになる不審者警報の事例を比べると、 128分以内に応答した分布の形状は似ている。 不審者情報では、予想をしない通報で、 気づくのが遅れる人が 25% 程度を占めている。

しかし応答までが遅れる人の中には、 企業内の携帯電話の持ち込み禁止であったり、 業務時間中で携帯電話の操作を控えているために、 応答が遅れる場合も多い。 7/4(水)の不審者情報は第一報が 9時頃、 7/18(火)の豪雨警報の発信ピークは 17時頃である点、 応答までのヒストグラム形状がほぼ同様である点を考えると、 企業内への携帯電話の持ち込み禁止などの事情が大きいと思われる。

豪雨警報の連絡の観察

昨夜の豪雨警報がどのように伝わったかをメールの送信履歴で追いかけてみた。

2006-07-18-emc-career.GIF

グラフの内容

このグラフは、上半分がキャリア別に送信した単位時間(5分)毎のメール送信件数と、 下半分が緊急連絡の送信の件数 (市や学校が発信した回数) 。

遅配の発生状況

キャリア別の送信件数と、緊急連絡の送信件数のピークはほぼ一致しており、 大きな配信遅延は少ないと思われる。 メールの発送待ちのメール件数を観察したグラフ(下記)では、 16:30〜21:00 までの間、ある程度発送待ちが溜っている。 この時間帯では、緊急連絡の発信数の山と,DoCoMo,au 宛の送信メール数の山が 時間帯で一致しているのに対し vodafone 宛の送信メール数は、17:30〜19:00 まで 一定数で分布している。このことから vodafone 宛では、配送遅延が発生していたと 思われる。 この状況は、 2006/06/06 の不審者情報の連絡状況 での遅配の状況とも一致する。

2006-07-18-emc-queue.GIF

防災本部からの配信とのずれ

最初のグラフ中の赤線は、防災本部からの発信があった時間である。 この時間と発信数のピークをみると、連絡の1時間ほどの間に、各学校の判断で 保護者に連絡が行われていると思われる。 (ただし防災本部からの連絡とは別に各学校の独自判断での情報発信も含まれる)

Skype って学校の Firewall + ルータ越えられるのね…

Skype って学校の Firewall + ルータ越えられるのね…

あまり必要性を感じてはいないけど、 Skype を使う機会があった。 うちの高専では、頭の悪い NAT を使っているのもあって、Skype 通話って できないと思っていた。しかし、試してみると意外にも通話(echo123相手だが…)ができた。 よくもまあ、 色々な技を使って コネクションを張るもんだ…

といっても学生さんの多くいる時期だと、NAT の対応テーブル溢れや大域あふれが 発生するだろうから、通話できなくなるかもしれないが…

ENIAC などの画像

ENIAC などの画像

XEmacs で utf-8

Ajax 関係のプログラムでは、処理の都合上 UTF-8 にした方がよさそう。 しかし XEmacs では、set-file-coding-system で UTF-8 が使えない。 追加で mule-ucs が必要みたい。

# apt-get install mule-ucs

ファイルと相対PATH,絶対PATH

相対PATH,絶対PATHを理解してもらうために、Windows のコマンドプロンプトで、 長い PATH を短く表現する…といった趣旨を交えながら、意味を説明する。 これに加え、親ディレクトリ=「..」、現在ディレクトリ=「.」などを 説明

テスト前までに授業回数が減ってきたので、残り時間も少なく夏休みをまたぐ という状態ではあるが、C言語での fopen などを簡単に説明。 この中で binary モード、text モードの必要性を説明する。

メールが受信できなくなる

先週末から「メールが受信できない」という連絡を受ける。 どうも、特定のメールが入っていると以後のデータが読めなくなるみたい。 ほかの先生から『ファイルサイズが800byte近辺で、 To: が怪しい本体無しのメールがあると読めないらしい』との情報から、 「読めない」という先生の了解を得て、怪しい生データを探す。

以下がその実例。

Return-Path:
Delivered-To: *******@ei.fukui-nct.ac.jp
Received: (qmail 2175 invoked from network); 9 Jul 2006 05:45:52 +0900
Received: from unknown (HELO secgw.ip.fukui-nct.ac.jp) (10.10.21.55)
by maisy.ei.fukui-nct.ac.jp with SMTP; 9 Jul 2006 05:45:52 +0900
Received: from (10.10.21.52) by secgw.ip.fukui-nct.ac.jp via smtp
id .... Sat, 08 Jul 2006 20:45:51 +0000
Received: from cm-85-152-141-5.telecable.es
(cm-85-152-141-5.telecable.es [85.152.141.5])
by sv2.ip.fukui-nct.ac.jp (Postfix) with SMTP
id BE2854008; Sun,  9 Jul 2006 05:45:47 +0900 (JST)
Received: (qmail 8[5
Message-Id: <20060708204547.BE2854008@sv2.ip.fukui-nct.ac.jp>
Date: Sun,  9 Jul 2006 05:45:47 +0900 (JST)
From: cpzu22tyi@unlimited.net
To: undisclosed-recipients:;

ひとまず、"To: undisclosed-recipients:;" が含まれるファイルで、 サイズの小さい物が怪しい。 実際、このファイルを消すとメールが読めるし、Maildir に書き戻すと、 メール読み込み処理が途中で止まってしまう。

ということで、緊急対処だけど、以下の処理を実施:

無闇に消すと、重要メールだと迷惑かけるし、管理者権限つかいますと、 伝えてあっても、あまり関係ないメールを見られるのは嫌がられそう。 必要最低限の方法で、暫定の対処を行う。

# cd ~hoge/Maildir
# find . -type f -size -1000c
-exec egrep -q "To: undisclosed-recipients:;" {} \;
-exec cat {} \;
-ok   rm {} \;

新手の迷惑メールか?

学校のメインサーバでも同様のトラブルが出ている様子だし、 他の先生の情報では、thunderbird , AL-Mail , Outlook Express などでも、 『読めない』症状がでるらしい。 私自身は、受信後に spamassassin あたりが除外してくれているのか、 症状が発生していない。 新手の迷惑メールとも思うが、Web で同様の被害報告は、見付からない。
# うーん、謎….