現学長の任期は今年度いっぱい。再任はない。法人化して最初かな。で、大学当局は選出方法からはじまって、あたふたとしている。半年前に選挙を実施する規則だからだ。間に合わなかった。で特例をつくって、急遽、意向調査を実施中。一般教職員に投票権はないのだ。だから意向は調査しますが、その通りとは限りませんよ、ということになる。教員と他の職員（事務員、看護師、技術職員）の票の重さがちがう。が、どのくらいちがうのか、よくわからん。大学のページにでているのか？大学の公式ページはどこになにがあるのかわからないという、ひどいページだ。検索かけても一発で出てきたことがない。
立候補したのは４人。候補者の主張は印刷物で配布されたが、ほとんどの候補者は別途Webページがある。政治的信条を掲げるので、大学内のサーバ、つまりxxxxx.ac.jp をドメインとしたサーバは使わないほうがいいと、どの候補者も判断したらしく、民間プロバイダのサーバに掲載している。が、肝心の医学から立候補した山田病院長は準備不足でなにもない。あらかじめわかっていれば、余裕を持って作成できたのに、大学当局がページのURLを公開した時点で気がついた。９日の午前だ。であわてて管理者のところに相談がきた。なんにもないのに作れというわけだ。選挙活動だから命令ではない。午後３時までに、なにがなんでも午後５時まで。リンクを張っているページの管理者が帰宅する前に作れというわけだ。
そんな。いまから民間プロバイダを選択して、申し込んで．．．なんてやってられない。民間プロバイダのサーバは容量制限だってあるし、ただのは広告付きだ。そんなとこはだめだ。広告なし、容量制限その他制限なしなんてとこは知らない、探す時間もない。というわけで、管理者の自宅のサーバに作ることにした。ほかに、思いつかない。これだったら全く自由だからな。
問題はリモートでﾕｰｻﾞを加えたことがないことだ。自宅サブネット内ならリモートでできるようにしたけど、外部からやったことはない。あたりまえだ。ﾕｰｻﾞなんか少ないし、こんなに急ぐことはないし、週末にメンテナンスするだけだからな。できないことはないが、すべてコマンドラインで実施することになる。サーバはMacOSXサーバだからFreeBSDベースでコマンドラインからできないわけがないが、OSX特有のﾕｰｻﾞのHome Directory 構成を作るのは大変だ。だから、一旦、自宅へもどってユーザを加えた。URLに～を付けないとか、一応Blogとかを用意しておいて（３０分）大学に戻ってコマンドラインから操作だ。
３時までというのに、コンテンツがこない。昼飯を取って待っていたら、コンテンツがきた。でその作って欲しいという人と（この人が脇から何だかんだと言わないともう少し早くできたけど）一緒に、とりあえずのページを作ったのが午後４時。至急連絡してリンク先を変更してもらう依頼をメールしたけど、向こうはのんびりしていて、翌日判明したけど午後９時に書き換えたそうな。
履歴とか政策のページはｐｄｆしかないので、しかもそのｐｄｆはテキスト化していないので、文字列が抽出できず、元原稿がないからページがつくれない。ｐｄｆを貼り付けるとAcrobatが起動するのに時間がかかって、見るのがいやになるから、同じ内容のｈｔｍｌにしないとだめだ。というわけで翌日もこれに時間がとられた。カウンターも作った。敵のカウントは３００を超えているから、立ち遅れた当方としては、見てくれをよくするため、再訪問の制限時間を１分にしちゃった。４００をこえたら、あとで１５分くらいにする。
しかし、ドメインがseigi だぜ。なんせ遊びで作ったサーバだからな。mのテストを兼ねた実験機だからしょうがない。ひょんなことから役にたった。ページの寿命は１ヶ月だけどね。
http://example.com/suzuki/
だ。何回もアクセスしてカウントをあげてちょうだい。

教員評価のための教員の業績データベースをKJシステムといって６年前に設置され教員評価の資料として働いている。そもそも大学全体で教員評価を行うためのプロトタイプとして副学長の名前で設置されたもので、現在大学中央の企画室が維持管理している。このシステムが動き始めてから１年遅れて大学は、これまで印刷物であった研究者総覧をデータベース化するためにTを立ち上げた。したがって教員は２つのデータベースに登録しないといけないという二重構造になっている。なぜ大学当局は２つも立ち上げたのかはわからない。というか、だいたいあいつのせいだと予想がつく。既にあるシステムを改変してつくるより、新しいシステムを作った方が楽だからだ。全教員の評価に使うという前提で、S学部が試行として先駆けて教員評価を実施しているのに対して大学当局はなにもご褒美をくれない。おくればせながら、昨年度大学当局は全教員に対して評価を実施したが、失敗であった。ある部局はほとんどの教授の評価はSというAより上の評価になってしまった。准教授以下の評価は水準レベルであるBが最頻値なのに、教授だけがSが最頻値なのだ。よわいものいじめ。あきらかに教員評価に対する反発である。
大学本部企画室がこの教員システムを持て余してきた。そこで系のなのだから系で維持してほしいといってきた。学系長と事前の相談はなかったが、拒否してしまった。筋が通らないからだ。SSL証明書の期限があと２年だからあと２年以内になんとかしたいらしい。Tと合体し、新規に教員評価のためのデータベースとすべきだと突っぱねた。企画室も困っているだろうけど、知ったこっちゃない。教員情報システムを全学に広げるという前提で系が努力したんだからね。別のシステムに移行するのは、現在のデータをそのまま移すという事が前提なら賛成するともいっておいた。
企画室がちらっと漏らしちゃったんだけど、サーバはなんと８年前の代物らしい。６年でも化石だと言ったのに８年とは！！あと２年もつのかな？

刑法の犯罪が生じ、被疑者に逮捕状や捜査令状が出たとき、警察当局は証拠を集めるため、家宅捜査して、パソコンを含めあらゆる書類を根こそぎ持っていく。それらのうちどれが犯罪に結びつくかどうかを解析するのは、捜査員がやるんだからどうでもいい。家宅捜査のとき大騒ぎになるだけだ。
問題は、現在の日本人でメールを使っていない者は、高齢者と幼児を除いてほとんどいないことにある。メール等のサーバからダウンロードしたファイルは被疑者のパソコンを解析すればいいが、被疑者は、もしやばいことをしているとの認識があれば、さっさとそのようなメールファイルは削除するであろう。しかし、誰もがが知っているように受信メールはサーバに残っているのだ。捜査当局は被疑者が使っているからといって、無関係な多数の人間が利用しているサーバを差し押さえることは、さすがにやらない。ということは、その被疑者のメールを提出せよと警察から照会があるわけだ。拒否したら、強制捜査でサーバを持っていかれちゃう。照会に応ずるのは、今回の場合、組織上最上位の長だ。だからといってその長がサーバにアクセスして該当者のメールを収集するわけではない。最上位の長はサーバの管理者に、組織上の流れに従って、次の長−次の長と経由して命ずるわけだ。
しかたない、平のサーバ運用管理者が該当するメールアカウントに残っているファイルをこつこつ集めるわけだ。なぜこつこつかというと、その被疑者がもっていたと思われるアカウントのパスワードを変更しちゃって、端末のメールソフトに新しいアカウントを作成して受信すれば一発だが、そんなことはできない。あくまでも被疑者のものだからだ。
サーバのadmin としてファイルを覗くしかない。医学のサーバはFTPできるdirectory が限定されている。その場所がわからない。技術管理者のOちゃんしかわからない。Oちゃんに連絡しても返事がない。
しょうがない。コピペを繰り替えすしかない。というわけで延々とメールの本文をコピペした。幸いなことに、比較的新しく作成したアカウントなのでスパムがほとんどない。これが管理者のメールアカウントだったら大変だ。８０％がスパム、総メール数１００通／日を越える。
でやりましたよ。丸１日かけて。直属の上司に報告するわけだ。分厚い印刷出力を分類して渡しましたよ。これはメーリングリスト、これは不特定多数宛のメール、これはグループの連絡メール、これは個人宛と。そうでもないと上司は判断できないでしょ。
サーバの運用にあたっては、個人情報の開示が本人以外からあったら、該当する組織の長が指示した場合に限り、その長に開示するという規則がある（私が作ったのだ）。そうでもないと、末端のサーバ技術管理者がかわいそうでしょ。万が一、属する親分から、「だれそれのメールをモニタしろ」なんて圧力がかかったとき抵抗できないじゃん。ちゃんとプロテクトしてあげないと。
というわけで、分類までやって、提示したのに、「内容は見ない。そのまま上に持ち上げる」だって。
どて（こけました）。
やっぱし、長なんだから一応は見るべきだよな。これが政治犯だったら大学当局は場合によっては被疑者を保護する立場になるだろうが。大学の教授が逮捕されたんだぜ！！
というわけで、これを読んだmのユーザ諸君！　くれぐれも、やばい　ことはやらないように。管理者に余計な負担がかかる。また m にあるメールは管理者がその気になったら読めるということも認識してください。これはmに限ったことではないけどね。でも、管理者がこれをやったら犯罪ですからな。やらないよ。

返信が Reply-to でなくて From に書いてあるアドレスになっちゃうことを調べていて、Thunderbird の設定Editor があることに気がついた。
mailnews.reply_header_authorwrote　は　%s さんは書きました　から %s wrote に
mailnews.reply_header_ondate は (%s) から　On %s　に
書き換えてみた。前者は　返信メールの引用が　xxx　wrote になる。後者はなんの変化もないぞ。日付と時間が入る筈なのに。どっかにあるんだろ、日付と時間を入れる設定が。
で肝心の Reply-to と From の件はどこだかわからん。このeditorで設定できるのかどうかもわからん。
mail.identity.default.reply_on_top は引用文の前に空の行を作って、そこにカーソルが位置することらしい。
デフォルトが 0 なので 1 にしておいた。これで、返信　ボタンを押して作成されるメールのカーソルが一番上の空行の先頭に位置される。

Mac の Thunderbird 2.0.0.16(20080707)で返信ボタンをクリックすると、自動的に入力される宛先は、Reply-To: に書かれていても、 From: に記入された方が選択されてしまう。これは誤りだ。Reply-Toが優先されなければならない。Reply-To を無視するのは、管理人のだけだろうか？壊れちゃったのだろうか？バグ？バグである筈がない。こんな簡単なことだからだ。
/Users/[ユーザ名]/Library/Thunderbird を一応保存して、新規にダウンロードしてみたが変わりはない。.app だけしか交換しなかったからだろうか？しかし、どっちを使うなんていう設定はあるわけがないと思うし、そんなのがどのファイルにあるのかもわからん。バグかとも思うが、検索してもひっかからない。
From と Reply-To が違うメールなんてめったにないし、あってもメーリングリストだし、使い分ける方は２つのメールアドレスにきたメールを同一メールソフトで見ているにちがないか、一つにまとめていると思うし．．．で、放置。

以前書いたレーザー・ポインターの続き。

工作室で、単４バッテリーのアダプターを作らせた。

これがオリジナルのセット

こっちがアダプターを加えたセット

単４の充電式電池を使えるように、お尻の部分を長くするアダプターが金色に光っているやつだ。真鍮棒から削りだした。新品なのでまだ金色だが、すぐ黒ずんでくるだろう。黒いメッキとかをすればいいが、メッキ代が本体と同じくらいの値段になっちゃうらしいので、このままだ。ウレタン塗料とかで塗ればいいだろう。単５電池の径が単４より大きいのでオリジナルの筒の中に単４電池をいれると中でぐらつく。白い筒はぐらつきを防ぐためのスペーサーでプラスチックの筒だ。

Google が出したブラウザだ。Ｆｉｒｅｆｏｘより早い、快適だ。Skin が青なので、デスクトップの海のいろとまぎらわしい。だれかスキンを変えるプラグインをつくるだろう。
どうやって、ブックマークするのかわからん。わかった。
ホームページへのアイコンがない。追加できた。
快適かもね。はやくMac版ができないかな。

DNSのキャッシュにphising siteなどの悪いことをするサイトへのip address を注入することができる。かなり以前からこのような事実はわかっていたが、この５月くらいから問題視されるようになった。
DNSの役目は、クライアントが、たとえば m にアクセスしたいという要求を出すとDNSがそのip address は123.123.123.123ですよと答えるのだ。これをDomain Name Service（ ＤＮＳ）といいこれを実施するのがDNSサーバというわけだ。実際の通信の宛先はすべて ip addressで行われるので、つまりパケットではip addressだけが住所として有効なので、ip addressを直接書き込まない限りDNS がないと通信ができない。
DNS サーバはドメインネームとip addressの対応表が必要だが、世の中にあるすべてのip addressを記録するわけにはいかない。量が多すぎるし、しょっちゅう変化するからである。そこでＤＮＳサーバは自分のとこに記録がないと上位のＤＮＳサーバに問い合わせる。そこにないと、さらに上位のＤＮＳサーバに問い合わせる。というわけで、最上位のＤＮＳサーバは全世界に１３台しかなく、そのうちの１台は日本にあるらしい。どこにあるかは秘密である。ここがテロで襲われるとネットワークは使い物にならなくなっちゃうからだ。
ユーザはまず最下位のDNSサーバを使うわけだが、ここにそんなに多くの対応表があるわけではない。しかし、このサーバに対する要求は同じことが多いので、サーバは問い合わせのあったドメインネームとそのip address を記録しておけば、上位のサーバに問い合わせる必要がないから早く反応ができて好都合である。そこで、問い合わせのあったものについては保存しておく。これがキャッシュに保存するという意味である。
キャッシュの保存されるときのＩＤは順番に付けられる。そこで、悪いやつは、この順番にということを利用して、順番をひとつずつ繰り上げるようにしてDNSサーバに本来とは異なるip addressを注入していく。DNSが上位のDNSに問い合わせた答えを返事しているように装うと注入できる。DNSはudpだからだ。そうするとDNSが参照するのはID番号なのでどっかでユーザが要求したのと同じIDとなり、思うとおりのip addressに誘導できてしまう。IDとポート番号が同じだと注入に成功するのだ。IDの数もポート番号も有限なので確率の問題だ。
これを防ぐためには、
１）キャッシュの容量を減らすとすぐ息詰まっちゃうので、ヒットする可能性が低くなる
２）IDの割り付けをランダムにする
３）問い合わせに対する答えを保持しないで、上位に必ず問い合わせる（キャシュをなしにする）
というわけで２）の対策をとることにする。生理のDNSはルータ、RT57i だ。ようやくYAMAHAはアップデータを出したのでこれにアップデートし、言われたとおりにフィルタを設定した。これでいいのだろうか？

これって、丸投げだから上位のDNSがちゃんとしているかどうかの問題になる。で上位のDNSはkだ。
テストしてみると
123.123.123.123 (xxxxxxx.ac.jp) appears to have GREAT source port randomness and GREAT transaction ID randomness.
と問題はないようだ。

昨日の午後から、今朝にかけて、大雨と雷が続いている。寒冷前線の通過に伴うものだが、移動速度が遅い、雨と雷の雲が南北に３本くらいできているのだが、普通は東に移動するものだが、どちらかというと北へ移動するものだから、いつまでたっても雲が続くことになる。
で午前３時過ぎ、停電だ。何分続いたかは分からんが、k もm もt もUPSのおかげで問題なかったと信じているけど．．．８月２９日午前１時から６時までのアメダスの画像だ。

午前１時、午前２時、午前３時

午前４時、午前５時、午前６時
国土交通省のページの河川の水位から。
土浦市を流れる桜川が氾濫寸前。土浦市田土部の桜橋の水位の推移だ。

何やら赤とか赤点線とか黒線があるがこれらは 水防団待機水位、はん濫注意水位、避難判断水位、はん濫危険水位 、計画高水位だそうで、水色の線が実際の水位の推移だ。
午前７時現在5.49m で氾濫危水位5.20m を越えている。台風とちがって、この水位が続くわけではない。きわめてlocalな豪雨だからだ。午後は収まっているだろうな。茨城県庁は独自の警戒警報のページがあるわけではないことが分かった。すべて、警戒警報などは、どっか国の機関のページへのリンクだけだ。リンク先ページでいいから茨城県だけに特化したページにすべきだ。

医学学系棟のトイレが、X棟の様に照明が人の存在で自動的に点灯するようになったところがある。オフィスの方である。今朝、雑誌を持って読みながら用をたしていたら、まだ済んでいないのに照明が消えて真っ暗になってしまった。
人が居るか居ないかは人が発する赤外線を感知するセンサーで行う。ところが赤外線センサーは、その性質から変化分しか感受しない。つまり人が動かない／赤外線の量が変わらないとだめなのだ。そこで静的な対象のときは、あえてシャッターを設けオンーオフして感知する。呼気ガスの二酸化炭素モニターは赤外線の発生源とセンサーの間にセルを置き、そのセル内に呼気ガスを通す。二酸化炭素は赤外線を吸収するので、センサーに当たる赤外線の量が違うことにより二酸化炭素の濃度を検知するのだ。しかしセンサーは動的な変化しか感知できないので、セルとセンサーの間に遮蔽する板を定期的に置き（モーターで羽を回転させ、この羽が赤外線を遮断する）赤外線の量が周期的に変化するようにして、そのピーク値を読むことによって二酸化炭素濃度を測定するのだ。
しかしトイレでは、必ず人は動くのでこのような機構は必要ない。が、座って用を足すときはあまり人は動かない。だから人が居ないとなって照明が消えてしまったのだ。
この仕組みを知っているので、真っ暗なトイレの個室で体を動かしたり、手を振ったりしたのだが、だめだった。原因はセンサーの指向性にあった。センサーが個室には向いていなかったのだ。知らない人が見たら滑稽だな。もっとも知らない人がいたら照明は消えないけどね。
で、なんとか個室から出て、再度照明を点灯させ、センサーの向きを変えて指向性が個室もカバーできるようにした。その結果は試していない。今日は用が済んだからだ。なにやってんだろうね。