トップ 最新 追記

kayakaya日記


Mar 22, 2009 (Sun)

# 僕もさくらインターネットでtDiaryをruby1.9.1-p0で動かす、その2

僕もさくらインターネットでtDiaryをruby1.9.1-p0で動かすから1日。大きな目立つエラーはないのだが、トラックバックが効いてないかもしれない。自分で自分宛にTrackback Pingを送ってみたが変化がない。エラーもなしに素通りしている感じがする。どうも設定が悪いのかもしれない(僕にとってtDiaryでのトラックバックの設定は面倒なのよ)。1.8.6系では正常にトラックバックの送受信はできていたはずなので、1.8.6系の環境を別途用意して、1.9系との切り分けられるようにしておけば良いかな。

ともかく、素通りはトラックバックを使う人には困るだろう。解決できないかとソースを眺めてみた。

。plugin/trackback/tb.rbのソースを見ると、

BEGIN { $defout.binmode }
$KCODE = 'n'

とある。$defoutは1.9では削除されてしまったので、$defoutを$stdoutに修正した。$KCODEも1.9から削除されたが、warningなので無視してくれるかもと思い、とりあえず放置する。

このtb.rbで試したところ、応答が返ってこなくなり、10秒後くらいに、こんなエラーが表示された。

500 Internal Server Error

when sending TrackBack Ping: execution expired   (TDiary::TDiaryTrackBackError)

(plugin/tb-send.rb):132:in `rescue in block in tb_send_trackback'
(plugin/tb-send.rb):119:in `block in tb_send_trackback'
(plugin/tb-send.rb):105:in `each'
(plugin/tb-send.rb):105:in `tb_send_trackback'
(plugin/tb-send.rb):58:in `block (2 levels) in load_plugin'

うーむ。タイムアウトしたみたい。別の箇所も修正しないとダメみたい。

ちょっとの修正で動作するなら、もうすでに修正されているよなぁとも思う。とにかく、トラックバック機能を無効にしてしのぐことにする。下手にトラックバックを受信できるようにしておくと、トラックバックを送るサイトにも迷惑をかけるので。


Mar 21, 2009 (Sat)

# 僕もさくらインターネットでtDiaryをruby1.9.1-p0で動かす

まちゅさんのところで、さくらインターネットでtDiaryをruby1.9.1-p0で動かすがあったので、僕もやってみた。先例があるので、あまり苦労しないn番目の人柱だけど(苦笑)。

今回は、真っ新なさくらレンタルサーバでRuby 1.9系 + tDiary 2.3.1系を動かした。諸事情でサーバをお引越しする必要があったので、これを機にruby1.9にしてみたのよ。tDiaryにはお世話になっているので人柱くらいはなっておきたかったし。

1.9導入の方法はまちゅさんと同じなのだが、ほんの少しだけtDiaryの配置構成が違う。僕のところは、同一サーバで複数のtDiaryを運営する方法みたいに、kayakaya.netでは複数のtDiaryを運用している。1.9対応の本質は変わらないだろうけど。

なお、引越し元のサーバでは、tDiary 2.3.1を使っていたので、日記データはUTF-8化されている。

Ruby 1.9.1のインストール

とくに厄介なことはないです。さくらインターネットではmake && make installで困らないはず。僕は$HOME/opt/に導入している。

$ wget ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-p0.tar.bz2
$ tar zxvf ruby-1.9.1-p0.tar.bz2
$ cd ruby-1.9.1-p0
$ ./configure --prefix=$HOME/opt
$ make && make install

バージョンを確認する。

$ $HOME/opt/bin/ruby -v
ruby 1.9.1p0 (2009-01-30 revision 21907) [i386-freebsd7.1]

うむよい。

tDiaryのインストール

tDiaryのインストール先は$HOME/local/share/tdiaryとする。SubversionのリポジトリからtDiaryの本体、contrib、プラグインとテーマを取得する。今回は1.9.1が安定して動くことが目的なので、tDiaryはtrunkを躊躇せず使う。

$ mkdir -p $HOME/local/share/
$ cd local/share
$ svn co https://tdiary.svn.sourceforge.net/svnroot/tdiary/trunk tdiary

themeはcore/themeにシンボリックリンクを張ってあげて、テーマを使えるようにする。

$ cd $HOME/local/share/tdiary/core/theme
$ cd -s ../../theme/* .

同一サーバで複数のtDiaryを運営する方法では、theme_url.rbのプラグインを作成して、プラグインのディレクトリに配置するとあるけれど、僕はその方法は取らなかった。僕のところでは、多くの人がtDiaryを使っているのではなく、僕個人が複数のtDiaryを動かしているだけなので、個別にthemeディレクトリを指定するのが手間でなかったりするだけ。

共通のtdiary.confは、同一サーバで複数のtDiaryを運営する方法と変わらない。共通のtdiary.confは$HOME/local/etc/tdiary.confに置いた。プラグインのパス自分の環境に合せて変えてあげることを忘れずに。僕の環境ではtDiaryのリポジトリに収録されてない野良プラグインはtdiary-stray/pluginに入れてある。

#
# ~/local/etc/tdairy.conf
# shared tdiary.conf
#
@data_path = "/home/kayakayaichthys/var/tdiary/#{@user_name}"
@smtp_host = 'localhost'
@author_name = "#{@user_name}"
@mail_header = "#{@user_name}"
@html_title = "#{@user_name}日記"

@header = <<HEADER
<%=navi%>
<h1>#{@user_name}diary</h1>
<%=calendar%>
HEADER

@footer = <<FOOTER
<%=calendar%>
<%=navi%>
FOOTER

@options['sp.path'] =  '/home/kayakayaichthys/local/share/tdiary/misc/plugin', '/home/kayakayaichthys/local/share/tdiary/plugin', '/home/kayakayaichthys/local/share/tdiary/contrib/plugin', '/home/kayakayaichthys/local/share/tdiary-stray/plugin'

@secure = false
load_cgi_conf

な感じ。@secureはfalseにしたのは、trueだとうまく動いてくれなかったから。個別の日記用tdiary.confでfalseにできるそうなのだがダメだったので、共通のtdiary.confでfalseにしてしまったの……。

個別の日記の配置

さて、ここからが肝要。

日記のURLはhttp://kayakaya.net/d/なので、サーバでの配置場所は$HOME/www/d/になるが、マルトドメインにしてあるので少し違う。$HOME/www/kayakayaをkayakaya.netにマッピングしてあるので、場所は$HOME/www/kayakaya/d/となる。

$ mkdir www/kayakaya/d
$ cd www/kayakaya/d
$ touch index.cgi
$ touch update.cgi
$ chmod +x index.cgi
$ chmod +x update.cgi

index.cgiとupdate.cgiを下記の通り編集する。拡張子はrbでも動くのだが、cgiの方がマルチドメイン環境では良いみたいなのでcgiにしている。

$ cat index.cgi
#!/home/kayakayaichthys/opt/bin/ruby
# -*- coding: utf-8; -*-
require '/home/kayakayaichthys/local/share/tdiary/core/index'
$ cat update.cgi
#!/home/kayakayaichthys/opt/bin/ruby
# -*- coding: utf-8; -*-
require '/home/kayakayaichthys/local/share/tdiary/core/update'

.htaccessはデフォルトのdot.htaccessと違う箇所だけ示す。html_anchor.rbプラグインを使っているので、その設定も書いてある。index.rbをindex.cgiに変更するのを忘れないこと(僕は忘れてハマりましたとも)。

DirectoryIndex index.cgi
RewriteEngine on
RewriteBase /d
RewriteRule ^([0-9\-]+)\.html$ index.cgi?date=$1

個別の日記用tdiary.confはこんな感じ。update.rbがupdate.cgiに変更しているので、@updateで明示的に指定してあげる。

@data_path = "/home/kayakayaichthys/var/tdiary/kayakaya/"
@user_name = 'kayakaya'
eval( File::readlines( '/home/kayakayaichthys/local/etc/tdiary.conf' ).join.untaint)
@style = 'Wiki'
@update = 'update.cgi'

テーマのディレクトリを作成することも忘れずに。

$ ln -s $HOME/local/share/tdiary/core/theme/ theme

個別の日記を設定する手順はこんな感じ。

キャッシュの削除

まちゅさんも書いている通り、Ruby 1.8系で動いていたtDiaryのキャッシュがあると、Ruby 1.9系ではうまく動かない。キャッシュを削除する。

$ rm -rf var/tdiary/kayakaya/cache/*
$ rm -rf var/tdiary/kayakaya/category/*

カテゴリインデックスの作成

キャッシュの削除で、カテゴリインデックスを消してしまったので再作成する。tDiaryの設定画面から「カテゴリ」->「カテゴリインデックスの作成 」にチェックして、「OK」を押す。まちゅさんはエラーが出たそうだが、僕は正常に作成された。日記データの違いかなぁ。

base_urlの罠(?)

これらの設定をした後で、システムのruby 1.8.6で動作確認してみる(shebangは/usr/loca/bin/rubyに変更した)。ruby 1.8.6で正常に動いてくれたので、tDiaryを複数運用するための設定は間違ってないようだと安心する。ここで、再びキャッシュを削除してから、shebangをコンパイルしたruby1.9.1に変更して試すと、こんなエラーが……。

can't convert nil into String (TypeError)

(plugin/00default.rb):341:in `[]='
(plugin/00default.rb):341:in `mobile_link_discovery'
(plugin/00default.rb):208:in `block (2 levels) in load_plugin'

実は、前に書いた個別日記用tdiary.confは現在運用中のもので、当初、1.9系で動かした時の記述ではない。先のconfにこの記述が書いていた。

def base_url
    'http://kayakaya.net/d/'
end

エラーはこのbase_urlの定義が原因だったみたい。00default.rbの該当の箇所を読むと、base_urlが関係しているぽいので個別日記用のtdiary.confからbase_urlの定義を消してみた。すると、ruby1.9.1でも正常に動く。1.8.6ではbase_urlの定義があってもエラーなしで動いた。

既知の問題でもなさそうなので、tdiary-develで質問してみたところ、個別の日記用tdiary.confではbase_urlは指定しなくても良い旨の回答をたださんから頂いたので、安心して削除して運用することに。

おしまい、これから

ruby1.9.1でtDiaryを動かしてから2日経過、マルチドメイン下に変更してから1日が経過したけれど、今のところ正常に動いている。何かエラーは出るかもしれないけれど、よほどのことがなければ、1.9で運用していくつもり。

本日のツッコミ(全2件) [ツッコミを入れる]

_ へいちゃん [先例があることはありがたい事ですよね。 僕も昔Hpサーバー立ち上げたときは、 (今思えばそんなに難しい事ではない) ..]

_ kayakaya [先例はありがたいですねー。そういえば大学の頃は研究室でサーバを公開するのが流行ってましたね。 さくらのエラーの件で..]


Mar 16, 2009 (Mon)

# 無線LANが不調なり、その弐

無線LANが不調なり、その壱の続き。

安定したかなーと思いきや3時間で20分以上寸断されたりしたので、むきー、とばかりに構成を替えてみた。無線親機をWZR2-G300NをGW-MF54G2に取っ替える。有線LANと無線LANのコンバータはWLI3-TX1-G54。結果は、2階の自室でもMacBookはスムーズに無線に繋がるし、有線LANからも複数の機器でインターネットに接続できる。相変わらず無線の電波強度は低いようだけど、求めている通信品質に問題はないので気にならない。

有線LANに繋いだMacBookからルータへの、とあるpingの状況はこんな感じ

4187 packets transmitted, 4179 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.263/18.331/4742.557/154.485 ms

あるべき姿ですかねー。

無線が不調だったのはWZR2-G300Nが安定していなかったのかしらん。真相が不明なのは気分悪い……。何とかしたいものだ。ちなみに、GW-MF54G2は別の用途で購入したのだけど、しばらく様子見で彼には今の場所で働いてもらうおう。その間に今後の構成を考えようかな。

本日のツッコミ(全2件) [ツッコミを入れる]

_ へいちゃん [無難に有線LANを2Fまで伸ばそう!]

_ kayakaya [本音は2Fまで有線を延伸したいのだけど、壁や天井に穴を空けられないので最後の手段かなと思ってます。]


Mar 15, 2009 (Sun)

# 無線LANが不調なり、その壱

3月9日くらいから自宅の無線LANが絶不調になった。2階にある自室の有線LANは、無線メディアコンバータ(WLI3-TX1-G54)経由で、1階にある無線ブロードバンドルータ(WZR2-G300N)に繋がっている。そのため、無線LAN区間が不調になると部屋の有線LANは孤立しちゃうのだ。ちなみに、無線LANが不調なのは2階の自室だけで、1階のルータを置いてある部屋ではMacBookのAirMacはすんなりとwifiに接続する。2階ではMacBookもwifiに繋がらないことが多いので困ったのですよ。wifiに接続できたところで品質が悪いのだね。

2階の電波状況が悪いのでしょうと調べてみたところ、周辺の家屋と思われるwifiをけっこう拾うのに、1階からの電波があまり届いていないことが判明。おまけにチャネルが重なっていた。チャネル設定は自動で放置したのだが、1階のルータ付近は周辺の電波を拾わないからチャネルの重複に気付かないみたい。まずは、周辺のアクセスポイントの重ならないよう手動でチャネルを変更。次に、無線LANコンバータを何とか試みた。場所を変えるとか、無線LANコンバータを手のひら無線LANルータ(GW-MF54G2)に変えたとか……。それで、ようやく比較的安定して接続できるようになったが、解決できていない重要なことが一つ。

  • 無線LANコンバータ経由では、ARP Replyを返すまでとても時間がかかる(こともある)。

2階の有線LANからも、1階の無線LANルータからも、コンバータの向うにpingが通らないことがある。Wiresharkで調べると、ARPの応答がなくだんまり。無線LANコンバータ自体に設定しているIPアドレスで問うてもだんまり。そうかと思うと40秒ほどたって、ARP Replyをまとめて返してくる(律儀なやつめ)。遅延しているとはいえ漏れなくARP Replyを返しているので、無線LANコンバータにはARP Requestはぜんぶ届いているみたいなのだ。キャッシュか何かが関係しているのかと勘繰ってみたりしているのだが、ダメな時は5分以上も繋がらないのでキャッシュだけの問題ではないだろう。無線LANコンバータ側の挙動が見えないのがもどかしい。くー。

有線LANに繋いだMacBookからルータへのとあるpingの状況はこんな感じ

272 packets transmitted, 33 packets received, 87% packet loss
round-trip min/avg/max/stddev = 26197.055/37614.816/44959.781/6437.864 ms

さすがにこんな状態はイヤです……。

初めてWiFiを管理したのは企業ネットワークだったもので、どちらかというと802.1Xの相性がね、みたいなトラブルが多かった(ARUBAとかCiscoで統一するから異機種混在は少ない)。今回はレイヤーが違うのだが、異機種同士の相性という意味では通じるとこもあるかな、と思ったりして。

本日のツッコミ(全2件) [ツッコミを入れる]

_ へいちゃん [確かにこんな状況イヤですね^^; 思い切って新しいモデム買ってみては?]

_ kayakaya [GW-MF54G2をもう1台買って、片方無線LANルータ、もう一方はコンバータにしようかな、とも考えていたり。300..]


Mar 13, 2009 (Fri)

# 「牛丼を変えたコメ」北海道「きらら397」の挑戦

「きらら397」の397の番号って何なの?と思っていたのだが、品種を育成するために管理する系統番号「上育397号」から取られたとか。上は北海道立上川農業試験場(上川農試)の略で、「きらら397」は上川農試で長い間かけて育成されたそうだ。

「きらら397」も育成の話もかなり興味深かったが、実はこの本で一番面白く読んだのが、コシヒカリ以前の品種改良の歴史だった。それも亀ノ尾の箇所がわくわくしたのだ。ちなみに、「きらら397」にはコシヒカリの血統(?)も入っていて、コシヒカリや「あきたこまち」など代表的な米は農林1号に辿り着く。その農林1号はというと、亀ノ尾という戦前の品種がベースだ。亀ノ尾といったら、夏子の酒で有名な亀ノ尾ですよ。この亀ノ尾は戦前はかなりの作付面積を誇っていたそうだ。耐冷性に優れ旨みもあると評判だったとか。とある阿部亀治という農民が冷水が直接注ぐ水田で見付けた稲穂が元だったらしい。当時から寒さに強いのは優先課題だったみたいだ(そりゃ冷害に強いことは飢えない条件だもんね。旨い以前だわな)。ちなみに、亀ノ尾の発祥は山形県の庄内だ。その後、亀ノ尾をベースにして、品種改良されてゆき陸羽132号、農林1号などが生れる。それらの品種改良の舞台は主に東北地方だった。

寒さへの耐性は東北で培われて、その成果で北海道でも米を作付できるようになった。おかげでたくさん収穫できるようになった。が、米が余るようになり、量から旨さへと転換しなけばいけなくなった。耐冷性の品種とコシヒカリの旨さの品種をかけあわせて「きらら397」が生れた。と書くとあっけないが、まぁ、かなり大変だったらしい。とにかく「きらら397」に至る道には亀ノ尾を初めとして歴代のコメと品種改良の努力が受け継がれているのだ。亀ノ尾の誕生が1897年、「きらら397」の品種登録は1990年、その間には93年の歳月がある。この辺りは本書でねちっこく書かれているので読んでほしい。

さてさて、たいていの人は想像つくだろうけど、本書によれば、吉野家など外食産業で好んで使われているのが「きらら397」らしい。牛丼として美味しく食べられるにはもっちりしたコシヒカリより固めの「きらら397」の方が向いている。コストの面もあるが、牛丼との相性によるところが大らしい。やや旨みを落した「きらら397」を吉野家向けに特別に作付してもらっているとか。この手の外食チェーンではブレンドなので100%「きらら397」にはならないが、それでも期待されている証だろう。そのうち北海道のお米が美食米の動向を左右するかもしれない。

蛇足になるが、コシヒカリは育成されたのは福井県だ。福井もコシの国だからね。けれども、今やコシヒカリといえば新潟でしょう。その亀ノ尾は山形県産だが、復活させたのは新潟県和島村の久須美酒造だったりする。米と酒は新潟がつくづく強いなぁと思う。次を狙うのは、どこの地方だろうか、北海道だったりする?、と興味は尽きない。

ともあれ、明日からも美味しく白米を食べられることは嬉しいことだ。感謝、感謝。

牛丼を変えたコメ—北海道「きらら397」の挑戦 (新潮新書) 牛丼を変えたコメ—北海道「きらら397」の挑戦 (新潮新書)
足立 紀尚
新潮社
¥ 714

Gyudon in Yoshinoya / 吉野家の牛丼


年間聖句(2010年)

あながたは皆、信仰により、キリスト・イエスに結ばれて神の子なのです。洗礼を受けてキリストに結ばれたあなたがたは皆、キリストを着ているからです。

新共同訳聖書ガラテヤの信徒への手紙3章26節

You are all sons of God through faith in Christ Jesus. for all or you who were baptized into Christ have clothed youselves with Christ.

Galatians 3:26-27 (New International Version)