分割メールが・・・

メーラーは、ずっと前からThunderbirdなんだけど、こいつはOutlookBecky!から送られてくる分割メールに対応していない。

まあ、Mozillaさんも
http://www.mozilla-japan.org/kb/solution/3059
な感じで結構つれない。
分割メール自身、RFCにもmessage/partialは規定されてますし、こんなにつれない対応しなくてもよいんでは?
とも思う、しかしながらアドインで対応って事なのかもって事で、ちょっくらやってみるかと思ったもののメンドクサイw
と思ったら、やっぱり世の中には頼りになる人がいっぱいいる。

http://www.c-a-m.co.jp/download/join.html

ありがとさんです。
使わしていただきます。

試しにBecky!な連れに分割メールを送ってもらった。
「元のメッセージからメッセージヘッダを補完する」は必須かも。

とりあえず、JOIN完了

はやりの「合体」って事で
ガッタイ

Berkeley DBが、お亡くなりに

SubversionTracで、プロジェクト管理しているのですが、今日ひとしきりソースをいじった後で、コミットしようとしたらエラーが出るではありませんか・・・

恐る恐る、Tracを見てみると

Oops…
Trac detected an internal error:

なんてこったい、そのうちでくわすだろうと思っていたが、とうとう私のところにもやってきたではないですが・・・
しかもこの忙しいときに・・・

バックアップでダンプを取っているシェルの実行ログを見てみると

svn: Berkeley DB error while opening environment for filesystem /var/svn/repos/db:
DB_RUNRECOVERY: Fatal error, run database recovery
svn: bdb: PANIC: fatal region error detected; run recovery

なんだか、リカバリーをせんといかんようだ、リカバリしてみる。

# db_recover -c -h /var/svn/repos/db
# 

ん?終わったのかい?

Tracをのぞいてみる。
おおぉ!!見れるジャン、直ったのかしら?
で他のページを見ようとする。

Oops…
Trac detected an internal error:

おっとっと、なんてこったい、そういうこったい。
だめだったい!!


何度もやってみたけど、リカバリをすると、そのあとの1度目だけはアクセスが大丈夫、2回目以降は駄目になるくさい

これは、一筋縄ではいかないのだろうか・・・

めんどくさそうなので、ダンプから戻しますか・・・(よかった、バックアップを世代で取るようにしていて・・・)

# service httpd stop
# svnadmin create /var/svn/repos
# svnadmin load /var/svn/repos < backup.dmp
<<< オリジナルのリビジョン xxx に基づき、新しいトランザクションを開始しました

------- リビジョン xxx をコミットしました >>>

# chown -R apache.apache /var/svn/repos
# service httpd start
# 

ようし、バックアップを戻したぞっと

Tracをのぞいてみる。
直ったいw


P.S.
今回は助かった、でもあまり使わないリポジトリが壊れた場合、今のバックアップ方法じゃ世代がなくなることに気付く!!
朝昼晩の3回ダンプを取って、かつ過去3世代を残すようにしている。
これについては、また今度考えるとしよう。いまはそれどころでないくらいやることが溜まっている^^;

VMware Player動かん

やっぱりVMネタでごめん

VM PlayerでRubyの環境を用意してたんだけど、最近Version 2.01が出てたのでアップデートしたらなんてことはないエラーが出て動かない!!
「致命的なアプリケーション エラーです:文字列のエンコード中にエラーが発生しました。(class cui:error)。」ってな感じです。

ちょっと、ググって見たところ既に解決なさっている人がいるではありませんか!!
http://d.hatena.ne.jp/satospo/20070930/1191115431
すばらしい、そしてありがたい

きっと、起動画面で何かが起きているんだろうとVMXファイルをダブルクリックすることでゲストを起動していたが、やっぱりこれはめんどくさかった・・・
これで心置きなく起動できます。

ちなみに、私もジミーさんがコメントに書かれていたの方法を使おうと思います。

C:\Documents and Settings\[username]\Application Data\VMware\featuredvm.ini
のdescriptionをdescription = ""に変更して保存後、ファイルを読み込み専用にしておきました。

めでたしめでたし

で、featuredvm.iniってなにぞ?
見た感じ、下に出ている広告の名称・説明・URLっぽいよね。

VMware Serverのネットワークがおかしいじゃん

ブログを1ヶ月以上ほったらかしです。
趣味を実行する暇がない。。。もちろんRalsなんていじってない。
最近は、もっぱら組込みのLinuxです。タイトルを変えんといかんかもしれんです。

なので、やっぱりRailsと関係ないネタを書きますw

自社のLANで動かしているサーバーなんだけど、VMware Serverを使って、LinuxやらWindowsサーバーやらを動かしています。
客先に導入するたびに別々に保守用のサーバーを作っていた昔と比べると非常に便利、何もないときはずっとHDDの中で寝てくれます。
なので場所もとりません。さらにVMware Serverは無償!!すごくうれしいのだけれども、頭を悩ますことが起こっていた。

まれにネットワークが動かない!!
これが発生した時は、起動しているゲストのネットワークは全滅です。

発生するのは、ホストのサーバーを起動してすぐの時だけ、一度でもゲストネットワークがうまく動くようになるとホストが動いている間にこの現象が発生することはありません。

で、どんな感じで使っていたかというと
VMware Server上にいくつものゲストを登録して、ホストが起動するとゲストを自動で起動するように設定したいた。
何日かに1度は、ネットワークが動かないことがあった。最初は、サーバーを再起動したりしてたんだけど、だんだん再起動では改善しなくなってきていた。
なんで?って感じでした。

はじめは、ネットワークカードが悪いのかな?とか考えた。
ちなみにVMware Serverが起動しているハードは

model : HP ProLiant ML150 G3
memoy : 2G
hdd : Raid 5 500G
os : Windows 2003 server

その他: Active Directoryの構成+ローカルのDNSとして動いてます

で、いろいろ探っていたら発生するパターンの中に重大な真実があった。
(っていうほどのものでもないけど。。。)

ズバリ!!起動一発目のゲストがLinuxだった場合に発生orz
(なるほど、最近Linuxサーバーが増えてきたから、発生頻度が多くなってきたんだ。。。)
しかも、この法則に気付いてからは100%発生させることができる。
VM上にLinux立ち上げるだけだもんw)

ならばということで、自動起動に順番を付けて回避することにした。

手順は以下のとおり、
https://{VMサーバーのアドレス}:8333/vmware/en/にアクセスして、
Optionタブの「Virtual Machine Startup and Shutdown...」の項目でSpecified Orderの1番目にWindows系のOSを起動するように設定する。

で、1番目に設定したOSを「Status Monitor」タブで選択して(名前の部分をクリック)ポップアップを開く。
そいつのOptionタブの「System Startup Options」にてAt System Startupにチェック
Continue Starting Other Virtual Machines Afterを 5 minutes (これは適当w)に設定、when VMware Tools startsのチェックを外しておく。

これで、まずサーバーを起動したらWindow系のOSが起動後、5分たってからLinux等が起動することになり上記現象を回避することができます。

これでこの問題は解決なんだけど。。。

他にも解決できない問題が・・・
VMware Server Consoleでサーバーとつないだとき、このクライアントソフトを落とすとサーバー上のゲストがお亡くなりになることがあるんだけどどうしてかしら?
なぞは、まだ残る。。。

まあ、Server Console使わなきゃいいから、今はそっとしてますorz

そっとね

VirtualHost+mod_proxyで、LAN内のホストを外部へ公開する

目標

ザックリ書くと今はこんな感じです。

 インターネット
    │
 ┌──┴──┐
 │ ルーター │
 └──┬──┘
    ├──────┬─────┬──・・・
┌───┴───┐┌─┴─┐ ┌─┴─┐
│ WEBサーバー  ││ SVN  │ │  PC  │
└───────┘└───┘ └───┘

このSVNのホスト(実態はPCと同じパソコンだったりするわけ)でソース管理していたプログラムを他人にも手伝ってもらって楽したい
ということで、インターネットに放り出す(手伝ってもらえるかは、また別の話^^;)

なので、インターネット経由でSVNが見れるとOKって事
もちろん、今までどおりWEBサーバーは見れたままで

httpd.confを編集

# vi /etc/httpd/conf/httpd.conf
(下のほうにあるNameVirtualHost *:80のコメントを外す)
-#NameVirtualHost *:80
+ NameVirtualHost *:80

virtualhostの設定を追加

# vi /etc/httpd/conf.d/virtual.conf

<VirtualHost *:80>
    ServerName svn.<私のドメイン名>
    <IfModule mod_proxy.c>
        ProxyRequests Off
        ProxyPreserveHost On
        ProxyPass / http://<SVNのIP>/svn/
        ProxyPassReverse / http://<SVNのIP>/svn/
    </IfModule>
</VirtualHost>

<私のドメイン名>には、環境にあったものを設定してください。

で、再読み込みしてアクセスしてみる

# service httpd reload

svn.<私のドメイン名>にアクセス
OK
www.<私のドメイン名>にアクセス
って、svnと同じものが・・・
NGって、orz


もう一度Apacheドキュメントを読んでいたら

メインホストはなくなります

既にあるウェブサーバにバーチャルホストを追加する場合、 既存のウェブサーバに対しても ブロックを作らなければなりません。このバーチャルホストの ServerName と DocumentRoot は、グローバルな ServerName と DocumentRoot と同じものにします。また、このバーチャルホストを設定ファイルの中で 先頭に置いて、デフォルトホストとして動作するようにします。

なるほど
って事で、 NameVirtualHost *:80を生かしたhttpd.confに最低限の設定を追加

#vi /etc/httpd/conf/httpd.conf
(最終行に追加)
<VirtualHost *:80>
   ServerName www.<私のドメイン名>
   DocumentRoot /home/www/html/
</VirtualHost>

で、再度設定反映

# service httpd reload

svn.<私のドメイン名>にアクセス
OK
www.<私のドメイン名>にアクセス
OK
って事で、完了!!だと思ったのだけど、apacheのドキュメントに書かれている

このバーチャルホストを設定ファイルの中で 先頭に置いて、デフォルトホストとして動作するようにします

の一文が非常に気になる。
この設定のままだと、virtual.confの方が先に読めれている。というのは、「Include conf.d/*.conf」が存在するのはLoadModuleの直ぐ下、なのに、Virtualhostの設定はhttpd.confの最後なので、

<VirtualHost *:80>
    ServerName svn.<私のドメイン名>
    <IfModule mod_proxy.c>
        ProxyRequests Off
        ProxyPreserveHost On
        ProxyPass / http://<SVNのIP>/svn/
        ProxyPassReverse / http://<SVNのIP>/svn/
    </IfModule>
</VirtualHost>

の設定は、virtual.confを作るのではなく、httpd.confの一番最後に

<VirtualHost *:80>
   ServerName www.<私のドメイン名>
   DocumentRoot /home/www/html/
</VirtualHost>

<VirtualHost *:80>
    ServerName svn.<私のドメイン名>
    <IfModule mod_proxy.c>
        ProxyRequests Off
        ProxyPreserveHost On
        ProxyPass / http://<SVNのIP>/svn/
        ProxyPassReverse / http://<SVNのIP>/svn/
    </IfModule>
</VirtualHost>

このように書いておくほうが良いようです
でないと、ディフォルトはproxy側になっちゃってるのでどれにもマッチしない条件を記載するにはそちらに記載する必要が出てしまう。
しかも、VirtualHost増えたらどれが先頭だか分からなくなるよね(conf.d/*.confの読み込み順を意識すればわかるかもだけど・・・)、VirtualHostの設定に関しては、httpd.confに書いておくのが無難、という結論でよろしい?

認証をWEBサーバー側で行う

proxyで飛んでいるわけだから、Proxy側で認証すればよいんだけどアクセスの制限をWEBサーバー側でやりたい
別々にいろいろ設定するのは面倒だからねw

Apacheのドキュメント読んでたら数行追加で簡単に実現できた

<VirtualHost *:80>
   ServerName svn.<私のドメイン名>
   <IfModule mod_proxy.c>
      ProxyRequests Off
      ProxyPreserveHost On
      
      <Proxy *>
         AuthName "Access Password"
         AuthUserFile /var/www/.htpasswd
         AuthType Basic
         Require valid-user
      </Proxy>
      
      ProxyPass / http://<SVNのIP>/svn/
      ProxyPassReverse / http://<SVNのIP>/svn/
   </IfModule>
</VirtualHost>


まあ、こんな感じ、もちろんパスワードファイルを作っておかなくてはいけないので、

# htpasswd -c /var/www/.htpasswd <アクセスユーザーID>
New password: <パスワード>
Re-type new password: <パスワード>

って感じでよろしく

Tracのリストア

サーバーが逝った時のことを想定して、TRACのリストアをテスト

VMのイメージは、この前作ったCentOS 4.5を使用、カーネルインストールまで終わっている環境のバックアップを取ってます。これを使います。(Rubyのテスト用に作ったんだけどね・・・)
VM等でテストすると、ここら辺がお手軽でよいです(^o^)/

DAG(rpmforge)をインストール

追加のパッケージをyumでインストールできるので便利、特に後でインストールする「ClearSilver」がインストールできるようになるので、ここでインストールする。
最新パッケージは、ここで確認

# wget http://dag.wieers.com/rpm/packages/rpmforge-release/rpmforge-release-0.3.4-1.el4.rf.i386.rpm
# rpm -ivh rpmforge-release-0.3.4-1.el4.rf.i386.rpm

終わったら、アップデートしておく

# yum update

apachesubversionをインストール

# yum install httpd subversion mod_dav_svn mod_ssl

起動と起動設定

# service httpd start
httpd を起動中:                                            [  OK  ]
# chkconfig httpd on
# chkconfig --list httpd
httpd           0:off   1:off   2:on    3:on    4:on    5:on    6:off

subversionのリストア

リポジトリの作成

/var/svnの下にプロジェクト名毎にリポジトリを作るとする。
リポジトリの中でプロジェクト分けたほうがよいのかな?)

# mkdir /var/svn
# cd /var/svn
# svnadmin create /var/svn/<プロジェクト名>
# svnadmin load /var/svn/<プロジェクト名> < dumpfile
<<< オリジナルのリビジョン *** に基づき、新しいトランザクションを開始しました

------- リビジョン *** をコミットしました >>>

Apacheから操作できるようにオーナーを変更しておく

# chown -R apache.apache /var/svn/<プロジェクト名>
Subversionの再設定

リポジトリへデータの取り込みはできたものの、これでは外のパソコンから参照できない。
で、設定をしてやる

/etc/httpd/conf.d/subversion.confを編集

#vi /etc/httpd/conf.d/subversion.conf
<Location /repos/<プロジェクト名>>
   DAV svn
   SVNPath /var/svn/<プロジェクト名>
   
   <LimitExcept GET PROPFIND OPTIONS REPORT>
      AuthType Basic
      AuthName "Authorization Realm"
      AuthUserFile /var/svn/.passwd
      Require valid-user
   </LimitExcept>
</Location>

Basic認証用のパスワードファイルを作成する。

# htpasswd -c /var/svn/.passwd <登録するユーザー名>
New passwd: <パスワードを入力>
Re-Type new password: <パスワードを入力>
Adding password for user <登録するユーザー名>

htpasswdの-cはクリエートのオプションなので、次からは.passwdファイルが既にあるならいらない

Apacheを再起動させる

# service httpd restart
httpd を停止中:                                            [  OK  ]
httpd を起動中:                                            [  OK  ]


ためしにアクセスしてみる
http://<サーバーのIP>/repos/<プロジェクト名>

Revision ***: /

* branches/
* tags/
* trunk/

こんなのが表示されるはず。

これでバージョン管理システムはOK,次はTrac

TRACの再インストール

まずは、Tracを再インストール

Trac必要なもの

こんなところ、

日本語版無くても良いのなら(# yum install tracでよい)

pythonをインストール

pythonと日本語コーデック、Python/XMLをインストール
最新版の確認は、以下を確認
JapaneseCodecs : http://www.python.jp/pub/JapaneseCodecs/

# cd
# yum install mod_python python-devel clearsilver python-clearsilver
........
# wget http://ftp.python.jp/pub/JapaneseCodecs/JapaneseCodecs-1.4.11.tar.gz
# tar xvfz JapaneseCodecs-1.4.11.tar.gz
# cd JapaneseCodecs-1.4.11
# python setup.py install

# wget http://jaist.dl.sourceforge.net/sourceforge/pyxml/PyXML-0.8.4.tar.gz
# tar xvfz PyXML-0.8.4.tar.gz
# cd PyXML-0.8.4
# python setup.py install

trac日本語版のインストール

日本語版を用意してくださっているインアタクトさんに感謝しつつインストール

# wget http://www.i-act.co.jp/project/products/downloads/trac-0.10.4-ja-1.zip
# unzip trac-0.10.4-ja-1.zip
# cd trac-0.10.4-ja-1.zip
# python setup.py install

Tracのリストア

バックアップしていたデータをリストア

# service httpd stop
# cp -Rf <バックアップデータ>/* /var/www/trac/project
# vi /var/www/trac/hoge/conf/trac.ini
repository_dir=<この値を新しいSubversionのリポジトリに変更>
# trac-admin /var/www/trac/project resync
Resyncing repository history...
** revisions cached. Done.
# service httpd start

Apacheの設定

Tracmod_python用の設定は、/etc/httpd/conf.d/python.confに追加

<Location /projects>
   SetHandler mod_python
   PythonHandler trac.web.modpython_frontend
   PythonOption TracEnvParentDir /var/www/trac
   PythonOption TracUriRoot /projects
</Location>

<LocationMatch "/[^/]+/login">
   AuthType Basic
   AuthName "Trac"
   AuthUserFile /var/svn/.passwd
   Require valid-user
#   SSLRequireSSL
</LocationMatch>

SSLは使ってないのでコメントしてますorz

って感じ。

Tracのバックアップ

RubyともRailとも関係ないことばかりですが、いままで稼動していたTracのバックアップを考えておかないとね

バックアップをする

Subversionリポジトリをバックアップ

svnadmin dump /var/svn/project > project.dmp

Tracのバックアップ

# trac-admin /var/www/trac/project hotcopy <バックアップ先>

簡単なシェルを作って定期的にバックアップ

# mkdir /backup
# vi /backup/backup.sh			#<= backup.sh 作成
#!/usr/bin

backuppath=/backup/`date +%Y%m%d`

mkdir backuppath
svnadmin dump /var/svn/project > ${backuppath}/project.dmp
trac-admin /var/www/trac/project hotcopy ${backuppath}

tar zcf backuppath

exit 0

こんな感じのを作っておいて、cronで定期実行させる
(本当は、ハードが壊れたら元も子もないので、別のパソコンへデータを移動させるほうが良いでしょう)

# crontab-e
00 13 * * * /backup/backup.sh

:wq

で、毎日13:00に定期的にbackup.shが実行されることになる