分割メールが・・・
メーラーは、ずっと前からThunderbirdなんだけど、こいつはOutlookやBecky!から送られてくる分割メールに対応していない。
まあ、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が、お亡くなりに
Subversion+Tracで、プロジェクト管理しているのですが、今日ひとしきりソースをいじった後で、コミットしようとしたらエラーが出るではありませんか・・・
恐る恐る、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
メインホストはなくなります
既にあるウェブサーバにバーチャルホストを追加する場合、 既存のウェブサーバに対しても
ブロックを作らなければなりません。このバーチャルホストの 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
apacheとsubversionをインストール
# 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
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の設定
Tracのmod_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が実行されることになる