事務からクレームが。会計入力が遅くて、うまく行かない、なんとかしてくれということだ。８F秘書、６F秘書、１F秘書。複数の場所から同時かどうかわからないがクレームがきて、会計ソフトを管理している中央部署へクレームを付けた。しかし中央のソフト管理者はプログラムの問題ではない、ローカルな問題だから、そっちで解決しろとの返事。事務員が現場でみたらしいけどよくわからない。
基盤室に回ってきた。基盤室職員は会計ソフトの問題だったら、関係していないからと対応を拒否。
で、結局は事務は管理人である私にメールを送ってなんとかしてちょうだい。
それぞれが維持管理している縄張りの狭間に落ち込んだユーザはどうしていいかわからない。
で、管理人は、複数の場所で生じているが、大多数では問題がないから、中央のソフトやサーバの問題とは考えにくい、とするとローカルな問題だから、こっちで解決するしかないと判断した。まずは現場へ。
６Fの１台のパソコンは、タイムアウトして、入力した結果がデータベースにうまく反映しないようだ。理由は不明。もうちょっと調べる必要がある。とりあえず他の場所の様子を見に行かないと、一カ所では判断できない。
８Fでは３台（人）のパソコンが今日午前中から遅くなって使い物にならないという。同じハブの下にあるパソコンだ。ハブかハブと上流とのケーブルの不具合だろう。ケーブルを見たら

天井に近いLANコンセントに接続されたケーブルが天井にテープでとりつけてあり、ハブが床近くに設置してある。ケーブルを追うと……むむむ。

スチール机の引き出しと足の間にはさまっている（紫のケーブル）。取り出すと何回も引き出しを出し入れしているのでケーブルがへたっている。これが原因では？完全に切れてくれればいいんだけど、中途半端にケーブルが押しつぶされていると接続できそうでできなかったりするんだよね。
ケーブル交換で解決。使っているパソコンも６年前のだからボスにいって新しいものに交換してもらえ、また室内配線がでたらめだから、ボスに言って配線工事してもらえ　といっておしまい。
１Fは不在なので調査できず。６Fも秘書のほうがタイムアップなので翌日以降だ。
ユーザは会計ソフトしか主に使わないので、会計ソフトがおかしいと思うんだよね。だからクレームの付け方が間違えだったんだよね。上手にクレームをつけると解決するんだけど、ユーザはただ「できない」「おそい」というだけだから、現場にいかないとわからないことが多いのさ。基盤室も腰が重いのでだめなんだよね。教育しているんだけど、なかなか変わらない。サービス業なんだよね。
事務も自分のできる範疇でないと、管理人に投げてくる。管理人のような、ケツの軽い人だったらいいけど、もうすぐ管理人も代わるんだよね。どうなるだろな。
ま、今回は縄張りの狭間というよりユーザの無知に由来することかもしれないけどね。

生理セミナーのページはWordpress によるブログだ。3.0.1 に更新した。
１）プラグインを停止
２）従来の/blog を名前をblog~ に変更してバックアップ
３）Wordpress の最新版をダウンロードし解凍してblog と名前を変えてアップロード
４）wp-content directory をblog~ からコピーしblog 内のwp-dontent directory と入れ替える。
５）blog directory のowner をseminar に変更 (#chown -R blog)
４）blog~ 内のwp-config.php のパーミッションを777に代え、コピーしてアップッロードしたblogにペースト。owner を www に変更し、パーミッションを604に変更。
６）wp-content directory をblog~ からコピーしblog 内のwp-dontent directory と入れ替える。
これで問題なく動作することを確認。
７）Theme がEasy All だったのを、各投稿の頭に以前の投稿のタイトルが出現し、投稿のタイトルが論文タイトルで、長過ぎて、重いので表示しないようにするためdefault に変更。
８）ヘッダーの絵が無味乾燥であるし、これまでのヘッダーの絵を生かしたいので、theme のimage directory 内にあるkubrickheader.jpg をダウンロードしPhotoshop で従来の絵を加工して張りつけアップロード。加工は、オリジナルの絵は多分イラストレータで作ったと思われるが、そのオリジナルがどっかいっちゃったので、Easy All の該当する絵をダウンロードし背景を除き、カットしgif ファイルで保存しkubricheader.jpg に貼付けた。背景を除いたのは、従来は背景が白だったのが、今度は色がついているからなのだ。
９）akismet も古いから最新バージョンをダウンロードしアップロード。Activate した。

あるとき突然メーリングリストが止まった。いくつかあるメーリスの一つだ。止まったというクレームがきて、ほかのメーリスをためしたら問題がない。
OSXサーバ10.4 で mailman を使っている。
ログを見ると
Sep 09 19:29:50 2010 (514) Uncaught runner exception: [Errno 63] File name too long: ‘/private/var/mailman/archives/private/physiologyml/attachments/20100907/2c2bbc24/iso-2022-jpBRWZmZWN0cyBvZiBVbmlsYXRlcmFsIE1vdG9yIENvcnRleCBMZXNpb24giso-2022-jpBb24gSXBzaWxlc2lvbmFsIEhhbmQbJEIhRxsoQnMgUmVhY2ggYW5kIEdyiso-2022-jpBYXNwIFBlcmZvcm1hbmNlIGluIE1vbmtleXMgUmVsYXRpb25zaGlwIFdpiso-2022-jpBdGggUmVjb3ZlcnkgaW4gdGhlIENvbnRyYWxlc2lvbmFsIEhhbmQucGRm.pdf’
Sep 09 19:29:50 2010 (514) Traceback (most recent call last):
File “/usr/share/mailman/Mailman/Queue/Runner.py”, line 111, in _oneloop
self._onefile(msg, msgdata)
File “/usr/share/mailman/Mailman/Queue/Runner.py”, line 167, in _onefile
keepqueued = self._dispose(mlist, msg, msgdata)
File “/usr/share/mailman/Mailman/Queue/IncomingRunner.py”, line 130, in _dispose
more = self._dopipeline(mlist, msg, msgdata, pipeline)
File “/usr/share/mailman/Mailman/Queue/IncomingRunner.py”, line 153, in _dopipeline
sys.modules[modname].process(mlist, msg, msgdata)
File “/usr/share/mailman/Mailman/Handlers/ToDigest.py”, line 91, in process
send_digests(mlist, mboxfp)
File “/usr/share/mailman/Mailman/Handlers/ToDigest.py”, line 132, in send_digests
send_i18n_digests(mlist, mboxfp)
File “/usr/share/mailman/Mailman/Handlers/ToDigest.py”, line 306, in send_i18n_digests
msg = scrubber(mlist, msg)
File “/usr/share/mailman/Mailman/Handlers/Scrubber.py”, line 265, in process
url = save_attachment(mlist, part, dir)
File “/usr/share/mailman/Mailman/Handlers/Scrubber.py”, line 445, in save_attachment
fp = open(path, ‘w’)
IOError: [Errno 63] File name too long: ‘/private/var/mailman/archives/private/physiologyml/attachments/20100907/2c2bbc24/iso-2022-jpBRWZmZWN0cyBvZiBVbmlsYXRlcmFsIE1vdG9yIENvcnRleCBMZXNpb24giso-2022-jpBb24gSXBzaWxlc2lvbmFsIEhhbmQbJEIhRxsoQnMgUmVhY2ggYW5kIEdyiso-2022-jpBYXNwIFBlcmZvcm1hbmNlIGluIE1vbmtleXMgUmVsYXRpb25zaGlwIFdpiso-2022-jpBdGggUmVjb3ZlcnkgaW4gdGhlIENvbnRyYWxlc2lvbmFsIEhhbmQucGRm.pdf’
Sep 09 19:29:50 2010 (514) SHUNTING: 1284028118.276547+09c3101c3ca9dda630d35a87bdfc5463eecae202

どうやら、やたら長い名前の添付ファイルを送ったらしい。聞いたら

Effects of Unilateral Motor Cortex Lesion on Ipsilesional Hand’s Reach and
Grasp Performance in Monkeys Relationship With Recovery in the Contralesiona
l Hand.pdf

だって。なんてことだ、常識外だろうが。これを解決するのにえらいてまどった。
最終的には解決したのだが、なかなか解決できず、しかし使わないといけない状況で、なんとか新しいメーリスを、古いメーリスの登録者から作った。それでとりあえず運用してもらうことにした。
このメーリスには、もはや関係のない者が、自分で脱会してないし、削除の依頼も来てないからそのままになっていたから、この際整理するのもいいかと思ったからだ。登録者は３０名くらいだからな。
解決方法は、多分こんな風にすればいいのだと思う。解決したのだが、いろいろなことをやったのでどれが正しいのかわからなくなってしまったのだ。
usr/share/mailman で
# ./bin/unshunt
を実施する。配信できなかったメールはshunt というdirectory に保存されているらしい。あちこちいじったから、どこにこのdirectory があったのかわからなくなった。 上記のコマンドを実施する前にshunt directory を捨てるなんてことも実施したからだ。
/var/mailman/lists/[メーリングリスト名] のdigest.mbox を捨てる。こいつが要では？
２度とないように
/usr/share/mailman/mailman にある mm_cfg.py  に
SCRUBBER_DONT_USE_ATTACHMENT_FILENAME = True
と１行記述する　というのがいいらしいが実施していない。というのもdigest.mbox を消して同じ長たらしいファイル名のファイルを添付して送信したらできちゃったからだ。つまり再現性がなかったのだ。
ちなみに

いままで持っていた体重計＋脂肪率計というのは、ちゃんと動作するのを確信してゴミ箱から拾ったものだ。これは、毎日のように来る「タバ子」が、ほっちーとわめくのであげたのである。デブになったと思っていて、ー多分そうだろ–体重管理をしたいらしい。
そこで、今度は自前のものを買うことにした。アマゾンだ。即日納品されるようだ。帰ったらとどいているかもしれない。なんやら、いっぱい測定できるらしいが、体重計らしからぬ形態なので買ってみた。

めったに測定しないんだけどね。風呂場にあってもいいだろうということだ。