今年の夏は猛暑が続き、通勤はめげちゃって車になることが多かった。歩いて来ると、汗だらけになっちゃうからだ。帰宅のときはすぐシャワーを浴びるからいいけど、大学に来るときはそうはいかない。
10月になってようやく徒歩通勤も快適になってきたので始めた。まだ汗はでるけどね。通勤路は松見公園近くの繁華街というか飲屋街なのだ。
朝7時頃、向こうからいやに派手なおねーちゃんが朝帰りで歩いてくる。飲食店に勤務しているおねーさん、おばさんはこの時間滅多に外にでていることがない。珍しいなと思っているうちにだんだん近づいてきた。
決して管理人が近づいていったのではない。こっちの歩く方向に向かって相手が来たのだ。
すれちがいのとき、相手が挨拶したので、管理人も「おはよう」と挨拶した。
おかまでした。朝帰りなのでひげがうっすらと…
縄張りの狭間
事務からクレームが。会計入力が遅くて、うまく行かない、なんとかしてくれということだ。8F秘書、6F秘書、1F秘書。複数の場所から同時かどうかわからないがクレームがきて、会計ソフトを管理している中央部署へクレームを付けた。しかし中央のソフト管理者はプログラムの問題ではない、ローカルな問題だから、そっちで解決しろとの返事。事務員が現場でみたらしいけどよくわからない。
基盤室に回ってきた。基盤室職員は会計ソフトの問題だったら、関係していないからと対応を拒否。
で、結局は事務は管理人である私にメールを送ってなんとかしてちょうだい。
それぞれが維持管理している縄張りの狭間に落ち込んだユーザはどうしていいかわからない。
で、管理人は、複数の場所で生じているが、大多数では問題がないから、中央のソフトやサーバの問題とは考えにくい、とするとローカルな問題だから、こっちで解決するしかないと判断した。まずは現場へ。
6Fの1台のパソコンは、タイムアウトして、入力した結果がデータベースにうまく反映しないようだ。理由は不明。もうちょっと調べる必要がある。とりあえず他の場所の様子を見に行かないと、一カ所では判断できない。
8Fでは3台(人)のパソコンが今日午前中から遅くなって使い物にならないという。同じハブの下にあるパソコンだ。ハブかハブと上流とのケーブルの不具合だろう。ケーブルを見たら

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

スチール机の引き出しと足の間にはさまっている(紫のケーブル)。取り出すと何回も引き出しを出し入れしているのでケーブルがへたっている。これが原因では?完全に切れてくれればいいんだけど、中途半端にケーブルが押しつぶされていると接続できそうでできなかったりするんだよね。
ケーブル交換で解決。使っているパソコンも6年前のだからボスにいって新しいものに交換してもらえ、また室内配線がでたらめだから、ボスに言って配線工事してもらえ といっておしまい。
1Fは不在なので調査できず。6Fも秘書のほうがタイムアップなので翌日以降だ。
ユーザは会計ソフトしか主に使わないので、会計ソフトがおかしいと思うんだよね。だからクレームの付け方が間違えだったんだよね。上手にクレームをつけると解決するんだけど、ユーザはただ「できない」「おそい」というだけだから、現場にいかないとわからないことが多いのさ。基盤室も腰が重いのでだめなんだよね。教育しているんだけど、なかなか変わらない。サービス業なんだよね。
事務も自分のできる範疇でないと、管理人に投げてくる。管理人のような、ケツの軽い人だったらいいけど、もうすぐ管理人も代わるんだよね。どうなるだろな。
ま、今回は縄張りの狭間というよりユーザの無知に由来することかもしれないけどね。
セミナーのブログ
生理セミナーのページはWordpress によるブログだ。3.0.1 に更新した。
1)プラグインを停止
2)従来の/blog を名前をblog~ に変更してバックアップ
3)Wordpress の最新版をダウンロードし解凍してblog と名前を変えてアップロード
4)wp-content directory をblog~ からコピーしblog 内のwp-dontent directory と入れ替える。
5)blog directory のowner をseminar に変更 (#chown -R blog)
4)blog~ 内のwp-config.php のパーミッションを777に代え、コピーしてアップッロードしたblogにペースト。owner を www に変更し、パーミッションを604に変更。
6)wp-content directory をblog~ からコピーしblog 内のwp-dontent directory と入れ替える。
これで問題なく動作することを確認。
7)Theme がEasy All だったのを、各投稿の頭に以前の投稿のタイトルが出現し、投稿のタイトルが論文タイトルで、長過ぎて、重いので表示しないようにするためdefault に変更。
8)ヘッダーの絵が無味乾燥であるし、これまでのヘッダーの絵を生かしたいので、theme のimage directory 内にあるkubrickheader.jpg をダウンロードしPhotoshop で従来の絵を加工して張りつけアップロード。加工は、オリジナルの絵は多分イラストレータで作ったと思われるが、そのオリジナルがどっかいっちゃったので、Easy All の該当する絵をダウンロードし背景を除き、カットしgif ファイルで保存しkubricheader.jpg に貼付けた。背景を除いたのは、従来は背景が白だったのが、今度は色がついているからなのだ。
9)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
だって。なんてことだ、常識外だろうが。これを解決するのにえらいてまどった。
最終的には解決したのだが、なかなか解決できず、しかし使わないといけない状況で、なんとか新しいメーリスを、古いメーリスの登録者から作った。それでとりあえず運用してもらうことにした。
このメーリスには、もはや関係のない者が、自分で脱会してないし、削除の依頼も来てないからそのままになっていたから、この際整理するのもいいかと思ったからだ。登録者は30名くらいだからな。
解決方法は、多分こんな風にすればいいのだと思う。解決したのだが、いろいろなことをやったのでどれが正しいのかわからなくなってしまったのだ。
usr/share/mailman で
# ./bin/unshunt
を実施する。配信できなかったメールはshunt というdirectory に保存されているらしい。あちこちいじったから、どこにこのdirectory があったのかわからなくなった。 上記のコマンドを実施する前にshunt directory を捨てるなんてことも実施したからだ。
/var/mailman/lists/[メーリングリスト名] のdigest.mbox を捨てる。こいつが要では?
2度とないように
/usr/share/mailman/mailman にある mm_cfg.py に
SCRUBBER_DONT_USE_ATTACHMENT_FILENAME = True
と1行記述する というのがいいらしいが実施していない。というのもdigest.mbox を消して同じ長たらしいファイル名のファイルを添付して送信したらできちゃったからだ。つまり再現性がなかったのだ。
ちなみに
脂肪率計
投稿者のアイコン追加
このブログのtheme はnitrous を使っている。
Add Local Avatar というプラグインを導入し、投稿者やコメントした者のアイコンを表示できるようにした。
Add Local Avatar をダウンロードしFTPでPlugins に放り込み、activate する。
Users にAvatar という項目ができるからこのページを開き、
If allowed, use this directory for user avatar uploads, e.g. /avatars.Must have write access and is relative to /Library/WebServer/Documents.Or, use legacy (v7.3 and lower) $_SERVER['DOCUMENT_ROOT'] method |
とする。legacy method にチェックを入れる。root 権限で/Library/WebServer/Documents にavatars というdirectory を作成しパーミッションを777とする。
これでAdd Local Avatar が利用可能になる。
タイトルの横に投稿者のアイコンを表示させためには;
home.php の10行目
<h1><a href=”<?php the_permalink() ?>” rel=”bookmark”><?php the_title(); ?></a></h1>
スーパーで豆腐を…
今日、ひるめし時、スーパーで豆腐をどうやって売っているのか知らないという、おめでたい方とおしゃべりした。信じられる?誰だと思う?しょっちゅう見る人だけど、某本センセではないよ。惑星と恒星の区別ができなかった宇宙人ともちがう。
子供のときは、豆腐屋のおじさんが売りにきて、鍋を持っていくとその鍋にいれてくれていたそうな。そりゃ一時代前はそうだったよね。それ以降豆腐を買ったことがないんだって。だからスーパーで豆腐をどのようにして売っているのかわからないんだって。
あー、また一人宇宙人を発見したのだ。Men in Black のような一瞬にして宇宙人を見たという記憶をなくす道具ないだろうか。宇宙人がこんなにたくさんいるということを信じたくないからな。
Plugins も
Page が真っ白
このブログは、バージョンアップ(2.6 -> 3.0.1)したら、一部の絵が表示されない、page が真っ白となってしまった。
一部の絵は、絵のファイルそのものは残っているので、再度設定したら問題なくなった。
Page が真っ白というのは、themes をEasyAll から変更したら見えるようになった。他のTheme を探すことにする。とりあえずはClassic 1.5 だ。
今は、nitrous てのをつかっている。logo が何だ知らない車の写真なので削除してfavicon.ico が真っ黒な四角なのでmike のfavicon.ico に置き換えた。
タイトルバーが真っ黒なんだけどこれが1枚の絵ではないようで、面倒だからこのままにしておく。
事務のネットなのに…
ベトナム学生対象のサマースクールの最終日。面倒を見た学生3名も発表する。そのとき基盤室から電話。ネットがつながらない。部署の技術職員が対応したけど治らない。
非常に奇妙な現象であった。
3Fラウンジの3台のパソコンが接続できない。事務系のネットワークだ。ほかの部屋の事務系は問題ない。真っ先に疑うべきはこの3台のパソコンが接続されているハブだ。ここまでは、部署の技術職員でもわかる。だからハブを交換してみたようだ。でも、だめ。そこで管理者が呼ばれたわけだ。
調べたのはハブのリンクランプとその点滅状況だ。事務系のネットでいつもどのくらいの頻度で点滅しているのかわからないが、やや点滅頻度が高い。ということはパケットが流れているのだ。しかし接続できない。ハブあるいはその周りが依然として疑わしい。ハブのUp Linkケーブルを直接PCを接続しても、だめである。ということで、パケットが流れているからUp Linkケーブルや、このケーブルのささっているフロアスイッチのポートがおかしいということはないだろうが、念のためチェックしてみた。
ハブの上流のケーブルを探し、成端箱までたどるが、成端箱内のフロアスイッチのLEDの点滅も特におかしくない。リンクランプも問題なく、ハブ側でケーブルの抜き差ししてみると正常に消灯・点灯する。
次の手段は別のパソコンを接続してみることであるが、問題は接続のパラメータがわからないことである。それをどこの部署にきいたらいいいのかもわからないし、聞き出すのも面倒なので、考えてみた。
他はどうかを再度確認してみた。すると、同じハブの下にある別の部屋のパソコンは正常に動作していることが判明した。
つまり、同一のハブにぶら下がっているパソコンに、正常に接続できるパソコンとできない複数のパソコンがあり、できないパソコンが異常になったのが同時である、ということだ。同時に3台のパソコンが接続できなくなったということはパソコン側の問題ではない。
系のネットであれば、接続に必要なパラメータ等を把握しているので問題の解決に時間がかからないが、事務は固定のグローバルIP address を割り当てており、別途持参したノートを簡単に接続できない。
接続できないパソコンのDNSとかGatewayをみて、それらのアドレスを持参したノートにそのまま入力し、たぶん使ってないだろうとおもわれるIP Address を入力して接続してみた。だめである。
で、事情を聞いたら、朝一番は問題なかった。接続できているパソコンの利用者にきいたら午前中、接続ができなかったり遅くなったりしたとのことだ。
ふむ。これはなにか上流で障害があったようだ。しかし、そんな連絡は来ていないようだ。
パソコンに設定してあるGatewayのIP Adress に ping を飛ばした。帰ってくる。つまり、ハブやケーブルは正常なのだ。DNSにも飛ばした。が、こっちは帰ってこない。Ping を途中で止めている可能性があるので、こっちは正常か異常かすぐには判定できない。
事務系ネットワークを管理している部署を調べ電話した。
午前中、primary DNSがこけたとのことだ。へ?それで午前中接続が遅くなったのは分かる。まだ故障のままだという。だったらsecondary DNSは?ときいたら、こっちは正常なので、接続は問題ないはず とのことだ。ふむ。そうだろうな。でなければ全滅だからな。念のためprimary と secondary のDNSの IP Adrress を聞いてみた。Primary は合っている。Secondary が違う。ええええ?誰だ設定したのは。パソコンに設定してあった IP Address を伝えたら、「そんなアドレスはここ数年使ったことがない」とのことだ。
Primary DNSがこけても、Secondary DNSがいきていれば見かけ状正常に動作するので、障害のアナウンスなんかしないんだろうな。それがSecondary DNS の役目だから当然だけど。おかげでこちらは時間をとられたぞ。
正しい secondary DNS の IP Address を入力して問題は解決。
事務系のパソコンの設定は事務の会計がやっているのに違いないから、大学中央ではなくLocal のつまり医学の会計にきいたら、問題のパソコンは派遣職員が使っているので会計が設定したのではない とのたまわった。なんてことだ。派遣社員だろうが正規職員だろうが事務が管理するんだろうが。くそ。
聞いたらパソコン納入業者が設定したらしい。業者だってパメータを事務から聞いたにちがいない。聞かないと設定できないからな。事務がでたらめを教えたにちがいない。
あーあ。これで1時間以上かかったぞ。おかげでベトナム学生の発表が聞けなかったではないか。幸いにも、管理者が面倒を見た学生の発表は後ろに回してくれたので、間に合ったが。
教訓:わからないネットについては手を出すな。
といっても苦情がくるんだよな。ユーザはなんだかわかってないからな。無碍に断ったら評判は悪くなるし….

