学長選挙の選挙人は以下の２４名。意向調査がどのように反映されるかは彼らの気持ち次第。意向調査をどの程度反映されるかの明文規定がないから、ちまたの噂の教員１に対してほかの職員0.1とか言う比は意味がない。投票用紙が色分けされているから、以下の選挙人には区別して提示されるんだろうな。意向調査の結果も公示されるんだろうな。
基本規則第MM条第M項第P号(経営協議会の学外委員の中から経営協議会で選出された者10人)
M株式会社名誉顧問 xxxxx
T大学長 xxxxx
Y特任上席研究員 xxxxx
K特別顧問 xxxxx
A会社最高顧問 xxxxx
I学園理事長・学園長 xxxxx
S大学長 xxxxx
Kセンター理事 xxxxx
J研究所顧問 xxxxx
M理事長 xxxxx
基本規則第MM条第M項第M号(学長及び理事を除く教育研究評議員の中から教育研究評議会で選出された者10人)
T長 xxxxx
C長 xxxxx
T長 xxxxx
J長 xxxxx
E長 xxxxx
N長 xxxxx
S長 xxxxx
Q長 xxxxx
L長 xxxxx
G長 xxxxx
基本規則第M条第N項(学長選考会議の定めにより加える学長又は理事。委員総数の3分の1以下)
理事 xxxxx
理事 xxxxx
理事 xxxxx
理事 xxxxx

現学長の任期は今年度いっぱい。再任はない。法人化して最初かな。で、大学当局は選出方法からはじまって、あたふたとしている。半年前に選挙を実施する規則だからだ。間に合わなかった。で特例をつくって、急遽、意向調査を実施中。一般教職員に投票権はないのだ。だから意向は調査しますが、その通りとは限りませんよ、ということになる。教員と他の職員（事務員、看護師、技術職員）の票の重さがちがう。が、どのくらいちがうのか、よくわからん。大学のページにでているのか？大学の公式ページはどこになにがあるのかわからないという、ひどいページだ。検索かけても一発で出てきたことがない。
立候補したのは４人。候補者の主張は印刷物で配布されたが、ほとんどの候補者は別途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な豪雨だからだ。午後は収まっているだろうな。茨城県庁は独自の警戒警報のページがあるわけではないことが分かった。すべて、警戒警報などは、どっか国の機関のページへのリンクだけだ。リンク先ページでいいから茨城県だけに特化したページにすべきだ。