[カブンサンな発芽?]
数値をながめてるうちに，
この植物種 (30 数種あるうちの一種) は
「神の手」によって過分散 (overdispersion)
が生じてしまってるんでは，
と思ったんで作図してみたんだが
……
まあ，
たしかにカブンサンぎみ，
ですな．
他の多くの植物種では
「いかにも二項分布」
とゆーかんぢで，
実験者は意外にも注意ぶかかったのかも，
とか
(厳密には分散チェックせんとわからんけど)．
植物生態の久保です．私の周囲の院生たちから聞いたことなのですが，生物圏 科学専攻メイリングリスト (ML) に休講案内が日に 2-3 通配信され，それら に関して 「必要もないのに全員にださないでほしい」 「どこかに掲示すればすむことを」 「重要でないメイルばかりが来ると，この ML にいざ重要な通知が流れたとき にみのがすかもしれない」 といった評判のようです．個々の講義に関するアナウンスについては，全員参 加の ML で配信する，という方法はやめたほうがよいのかもしれません． 御検討いただけないでしょうか．
make pdf してそれをどらふと置き場にアップロード．
共著者の小林さんにメイルを書いて，
見てもらうことに．
pdf()
より postscript()
による出力がいいね．
sendmail-8.12.10
なんぞが動いているんだよね．
こんなの qmail とかに置き換えてしまいたいんだけど，
その根性がない．
で，
その高速増殖炉的アブなさを発散してるメイルサーヴァーで
いくつか実験してみたところ，
dead.letter もどってくる
…… 設定ミスか?)
.forward
は可能
sendmail の動作を調べてるよな．
ということで，
よくわかってない事務局のためのアカウントを作るぐらいはできる．
というようなことを返信してみる．
administrator@ees.hokudai.ac.jp
などという偽アカウントからメイルが送られてくる．
学内でどんどん増殖してるにちがいない．
Received: from ees.hokudai.ac.jp (p1200-ipad64marunouchi.tokyo.ocn.ne.jp [219.165.8.200]) by iscan1.sys.hokudai.ac.jp (Postfix) with ESMTP id B27FF111B for <hogehoge@ees.hokudai.ac.jp>; Mon, 6 Jun 2005 12:54:18 +0900 (JST) From: administrator@ees.hokudai.ac.jp To: hogehoge@ees.hokudai.ac.jp Subject: Important Notification Date: Mon, 6 Jun 2005 12:49:15 +0900 Message-Id: <20050606035418.B27FF111B@iscan1.sys.hokudai.ac.jp> This is a multi-part message in MIME format. ------=_NextPart_000_0007_F1E25BF6.329D9FFD Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit The original message has been included as an attachment. ------=_NextPart_000_0007_F1E25BF6.329D9FFD Content-Type: application/octet-stream; name="INFO.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="INFO.zip" UEsDBAoAAAAAACcexjJtp7JPftAAAH7QAABSAAAASU5GTy5odG0gICAgICAgICAgICAgICAgICAg ...
PROC MIXED
使ってるよーな
……
これってホントに最尤推定やってんのか?
PROC GLIMMIX
なる procedure もあって
……
これも (えらく丁寧な)
document
読むと，
尤度のあつかいには苦闘しているよーで．
Majordomo
のパスワード設定まちがってる，
とのご指摘いただくし．
えーい，
やはり /var/lib/majordomo
以下の設定ファイルを直接かきかえるほうがすっきりしている．
named
& httpd & sendmail
のやや面倒なる設定の組みあわせにすぎない．
しかしながら，
ここでちょっとややこしいことをやると何もかもぼろぼろに壊れていく，
という点において「お手軽に危険」なのである．
httpd
である．
まあ，
Apache の設定方式は頑健だからなんだろう．
これは問題ナシ．
named)．
これは相当に気合いと注意力が必要である．
まず仮想サイトごとに「えいりあす」なるものがあちこち指定できるけれど，
これは名前衝突に無頓着だとめちゃくちゃなことになる
(おかげで昨日から数時間前まで新潟大会の web page
が閉鎖状態だった……いやはや)．
このあたり CNAME で実現してるんだけど，
TLAS 内の世界ではほとんど役にたたんのではなかろーか?
とりあえず CNAME 全廃した．
A (アドレス) レコードを複数ならべればよい．
んなことやっていいのか，
と思われるかもしれないけれど BIND ``バッタ''
本にも OK と書いてあるし，
RFC1912
``DNS の運用と設定においてよくある間違い''
でもむやみに CNAME 使うなと書いてある．
/etc/named/db.*
といったファイルを直接さっさと書き換えたくなるもんだが，
これは禁じ手である．
どうも TLAS は別のデータベイスでも持ってるらしく，
そういう「ぢか書き」設定は無視されるのである．
がまんして web interface で書き換えていくしかない．
sendmail)
& メイリングリスト (majordomo)．
絶望というほかない．
これは TLAS の「仮想サイト」のわけわからん部分の悪影響，
としか思えんところで．
「仮想サイト」のヘンなところとして
www だの mail
だのといったよけーな「ホスト名」が必要とされる
sendmail -f ... といった工夫が必要になる．
そしてこのあたりが数時間にわたって本日も私を苦しめたわけで
……
majordomo
はこのあたりがヒドくて，
resend
っていう標準的な配送用 Perl スクリプトをやめて
sequencer
なる別ものを使わねばならん，
とわかった
(Linuxexpert
など参考にしつつ)．
sequencer
なる Perl スクリプトはじつに劣悪なしろもので
……
この中味を解読し，
/etc/mail/aliases.majordomo
を書き換え
(書き換えたら /usr/bin/newaliases の実行が必要)．
たぶんもう使わんだろうけど，
オプションのつけかたの順番 (最初に -C)
決め打ちなところもあるので書いてみると
|/usr/lib/majordomo/mj-wrapper sequencer -C (設定ファイル) -l testML -N -h (ホスト名必要) -f (sender 設定) testML-listてなかんぢか．
sendmail
に食わせられるまともな mail header が生成できんかった
(resend だとなぜか問題なくとおる
……
単純に sendmail -f してるだけなんだが)．
上記の TLAS 的ユーザー管理のおかげである．
qmail + ezmlm
だったらすごく簡単なのに
……
いやいや，
アヤしげユーザー管理の TLAS 世界では
qmail さえもまともに動作せんかもしれんな．
proftpd
を起動．
TurboLinux Appliance Server はへっぽこすぎて，
当方が手動操作する必要あり，
ということなのかも．
このときに
/etc/init.d/proftpd start
はダメみたいで，
/etc/init.d/xinet.d restart
する必要あり，
か?
/etc/passwd
には含まれていないけれど，
ssh
などで login できるアカント，
とは?
foo)
htpasswd -c ~/.htpasswd foo
cd /var/tdiary sudo mkdir foo sudo chown foo.apache foo sudo chmod 775 foo
index.rb の代替の
index.cgi 設置
(chmod +x index.cgi の必要あり);
その内容は
#!/usr/bin/env ruby require '/usr/local/share/tdiary/index'
update.rb の設置;
その内容は
#!/usr/bin/env ruby require '/usr/local/share/tdiary/update'
plugin2 と
theme へのシンボリックリンク
ln -s /usr/local/share/tdiary/plugin2 . ln -s /usr/local/share/tdiary/theme .
mkdir images sudo chown foo.apache images sudo chmod 775 images
tdiary.conf
の設置;
その内容は
@user_name = 'foo' eval( File::readlines( "/etc/tdiary.conf" ).join.untaint )
makerss.rb
plugin を動かすので，
その出力先 index.rdf
を準備する
touch index.rdf sudo chown apache index.rdf
mkdir files sudo chown foo.apache files sudo chmod 775 files
``You've been living in a dream, Nerdo,
called grad school...
This...
is the real world!''
``Whoa...
sunlight...''
私などはこの dream 世界で Agent Smith の役割でも演じればよいのだろうか．
<strong>
つけて
……
はい，
そこは
</strong>
で閉じる，
ええ，
ええ，
閉じるときにはばかばかしいことですがそこに
/
つけなきゃならんのです」．
/usr/local/share/tdiary/misc/style/wiki/
内にある
wiki_style.rb
と
wiki_parser.rb
を
/usr/local/share/tdiary/tdiary/
にコピー
tdiary.conf
に @style = 'Wiki'
を追加
wiki_parser.rb
を改造して ''...''
で文字色を赤にできるようにする
(改造前は <em>...</em>
と変換されていた)．
Format: Wiki
が適用される
……
しかしこれまでのぶんはそうではない．
「サーヴァー内共用型」運用だと
/var/tdiary/(user 名)/2005/
とかにデータが蓄積されるわけだが，
このデータファイルが
TDIARY2.00.00 Date: 20050609 ... Format: tDiary (内容)になってしまっているためである．
Fromat: Wiki
としてみる
……
がこれは tDiary によってもとに戻される．
よくわからんのだけど
/var/tdiary/(user 名)/cache/
というあたりが影響してるよーな
……
/var/tdiary/(user 名)/
以下は
tdiary.conf
を残してすべていったん削除する，
という乱暴な解決策を試みてみる
……
うまくいった．
バックアップ内容を Wiki スタイルとやらで再入力してみる．
問題ナシですな．
