Redmine 1.0.5 + JRuby + Tomcat6 デプロイ

最近、主にローカル Wiki として活躍してくれている Redmine が 1.0.5 にアップデートされましたので追従してみます。 セキュリティーフィックスも含まれるとのことです。

1.0.5 より i18n で必須 gem が追加になっていますので、JRuby + Tomcat デプロイ時は設定が1つ変わりますのでメモがてら。 🙂

Redmine 1.0.5 bug/security fix リリース | Redmine.JP

12月23日(日本時間)、Redmine 1.0.5がリリースされました。

Redmine 1.0.4に対して11個の修正・3個の脆弱性対策が行われています。

Redmine 1.0.5には脆弱性の修正も含まれているため、Redmineオフィシャルサイトでは全てのRedmineユーザーに対して最新版へのアップグレードを呼びかけています。

gem 追加について。

インストール・アップグレード時の注意

Redmine 1.0.5より、Rubyの国際化ライブラリi18nのバージョン0.4.2が実行時に必要です。インストール・アップグレードに先立ちサーバ上で以下のコマンドを実行してi18n 0.4.2をインストールしてください。

gem install i18n -v=0.4.2

というわけで、 JRuby で動かしている場合は、

$ sudo jruby -S gem install i18n –v=0.4.2

こういう感じで gem を追加です。

でもって、warble の config に依存 i18n を追加します。

# config を redmine 用に修正(一番したに追加)
sudo vi config/warble.rb 
config.dirs = %w(app config lib log vendor tmp lang)
config.gems << "activerecord-jdbcpostgresql-adapter" 
config.gems << "i18n" 
config.gem_dependencies = true
config.webxml.rails.env = 'production'
config.gems["rack"] = "1.0.1" 

これで、 sudo jruby -S warble でできた war を Tomcat とかにデプロイすれば動作するハズです。 🙂

redmine20 

参考、リンク。

hiromasa.another » Blog Archive » Redmine を Tomcat6 にデプロイ

hiromasa.another :o)» Blog Archive » 年末のデータバックアップ

 

がってん、がってん。

年末のデータバックアップ

いつの間にか 12月ということで、部屋の掃除もせずにデータのお掃除を(笑)。

ちょっと放っておくと HDD はなんだかよく分からないファイルであふれるものですが、こちらの整理とバックアップを少々。 今回はバックアップ用に Dropbox を使ってみました。

ぼくは普段使いの PC についてはほとんどデータを入れていなくて、いつ壊しても良いようになっています。 というか、OS 入れ替えをよくやる、というか入れ替えが好きなのでその準備が常にされているというのが真相です(笑)

というわけでそれ用に別にローカルサーバがたっていて、以下のデータが保管されています。

  • 通常ファイル用 samba
  • IMAP でつなげる Maildir
  • ソースコードをコミットする Subversion
  • そのプロジェクトの資料とかを管理する用に Redmine

ちゃんとまじめに上記に登録しておけば使っている PC はいつでもフォーマットできる状態という感じです。 メールとかはサーバ側でとっているのでそっとしておけばいいですが、ソースの Subversion 登録を最近サボっていたのでまずはここから。

サボライズ。(←懐かしい)

登録後のリポジトリをお見せしたいところですが、あぶない水着もあるのでちょっと控えておきましょう。 🙂

あとデータと言えば、ここコアサバ。 ブログのデータ。 こいつは rsync で持ってきています。

一応ローカルサーバは RAID1 になっていますが、バックアップという意味の断面はありませんのでどうしようか思案して、Dropbox に転送してみることにしました。

ワークステーションの PC に Dropbox を入れて、監視ディレクトリに各サーバからバックアップデータを rsync するシェルを作成。

[tegaki]とりゃ![/tegaki]

oosouji01

めでたく世界のどこかにバックアップされました。 これで札幌に何かあっても安心です(笑)

ローカルサーバ の Subversion、Redmine Postgres、Redmine File、コアサバの MySQL、アップロードファイルが対象になっています。

Dropbox は LAN 内にクライアントをみつけると、そちらに LAN Sync するのでさらに複数の HDD に複製がつくられます。 何か Dropbox 本来の使い方と違う気もしますが、良いことにしましょう。 🙂

いまはカレントしかやっていないですが、履歴をもたせてもいいかもですね。 バックアップタイミングはシェルを手動で起動した時点ということになります。 簡単な運用でバックアップとれるので気に入っています。

さて履歴といえば(全然バックアップと関係ないですが)、なにかプログラム書いたときに Redmine の Wiki にメモをちょっととっていたりするのですが、これがなかなか役に立ちます。 何かつくっても数ヶ月もすると忘れるので。。 心のバックアップ。。

oosouji02

というわけで、今後も活躍してもらおうと Redmine のバージョンアップも実施。 1系の正式版 1.0.1 を入れていましたが、先月末で 1.0.4 まで上がっているようです。

oosouji03

以下、アップデートメモ。 JRuby 化して Tomcat で動かしています。

cd /opt
# 新しいバージョンの tar.gz 落として展開
sudo wget http://rubyforge.org/frs/download.php/73457/redmine-1.0.4.tar.gz
sudo tar zxvf redmine-1.0.4.tar.gz
rm *.tar.gz
cd redmine-1.0.4
# 前のバージョンの config をコピー
sudo cp ../redmine-1.0.1/config/database.yml ./config/
# 秘密鍵作成(config/initializers/session_store.rb)
sudo jruby -S rake generate_session_store
# DB マイグレーション
sudo jruby -S rake db:migrate RAILS_ENV="production" 
# warble の config 作成
sudo jruby -S warble config
# config を redmine 用に修正(一番したに追加)
sudo vi config/warble.rb 
config.dirs = %w(app config lib log vendor tmp lang)
config.gems << "activerecord-jdbcpostgresql-adapter" 
config.gem_dependencies = true
config.webxml.rails.env = 'production'
config.gems["rack"] = "1.0.1" 
# war ファイル作成
sudo jruby -S warble
# tomcat 停止
sudo /etc/init.d/tomcat6 stop
# 今のバージョンの war を一応退避
sudo cp -p /home/apache/redmine/redmine.war /home/apache/redmine/redmine-1.0.1.war
# war を新バージョンに差し替え
sudo cp -p /opt/redmine-1.0.4/redmine-1.0.4.war /home/apache/redmine/redmine.war
# tomcat からアプリ削除
sudo rm -Rf /opt/tomcat6/webapps/redmine/
# tomcat 起動(自動デプロイ)
sudo /etc/init.d/tomcat6 start
# 静的ファイル格納ディレクトリにシンボリックリンク貼り直す
sudo ln -s /home/apache/redmine/files/ /opt/tomcat6/webapps/redmine/WEB-INF/files

でした。

Redmine、Subversion やレンサバ rsync についてもし興味があれば以下をみてみてください。 🙂

hiromasa.another :o)» Blog Archive » Redmine を Tomcat6 にデプロイ

なにか利点があるかって話ですが、1パッケージにして JavaVM で動作させておけば、OS にのっている Ruby 実行環境に依存しなくて済むのがいいところ。 gem のバージョン依存とか考えなくていいし、Servlet の実行環境さえあればどこにでも乗せられるのでなかなか便利かもしれません。

hiromasa.another :o)» Blog Archive » Subversion サーバ を CentOS 5.5 で。

Subversion サーバは昔も家にたてていたのですが、ローカルサーバを Atom 機にしてからまだインストールしていなかったので CentOS 5.5 上に改めて構築してみました。

hiromasa.another :o)» Blog Archive » WordPress のファイルバックアップ

WordPress のブログデータの構成要素は、MySQL のデータと画像などのサイトにアップロードファイルとなりますが、ここは後者のファイルのバックアップお話。 MySQL のバックアップについては以前かいた以下の記事が参考になるかもしれません。

Aptana Studio と DB 開発統合

Aptana Studio の Subversion 統合に続きまして、今度は DB 開発系を Aptana に統合してみます。 諸般の事情でスクリーンショットは Eclipse for PHP Developer になっていますが、Aptana でも同様です。 🙂

ここでは、DB Viewer プラグインを設定しています。 これで SQL 開発やデータの閲覧を Eclipse 上から統一操作でできるようになります。

Download – DBViewer Plugin for Eclipse 開発プロジェクト – SourceForge.JP

DBViewer Plugin is an Eclipse Plugin as a Database Front end .
It connects with various Databases by way of JDBC Driver,
The function to assume not DB manager (DBA) but developer (Developer) is offered.

インストールは簡単で上記サイトから、 zigen.plugin.db_1.2.2.v20101009.jar など最新版の .jar を取得して、Aptana もしくは PDT の plugins ディレクトリディレクトリに格納して、Eclipse を再起動してください。

また、DB に接続するときに各データベース用の JDBC ドライバが必要になります。 ここでは、WordPress をサンプルにしていますので MySQL 用ということで下記からダウンロードします。

MySQL :: Download Connector/J

MySQL Connector/J is the official JDBC driver for MySQL.

.zip ファイルの中に .jar がありますので、それを分かりやすい位置に配置しておきます。 その他のファイルはここでは不要です。

準備ができたら Eclipse 起動で、DB Viewer のパースペクティブが作成されていますので、前回の SVN のパースペクティブ選択と同じように、右上の Other から選択します。

aptana21

でもって、接続先データベースを新規追加します。(ローカル環境で MySQL が立ち上がっているものとします。)

まずは JDBC ドライバの登録から。 先ほどの Connector/J の .jar をファイルの追加から指定して、適当なデータベース定義名を入力して Finish。

aptana22

次にデータベースの接続先を設定します。 ローカル環境ならホスト 127.0.0.1 でデータベース名を接続文字列で、またユーザ名とパスワードを指定します。

テスト接続でつながったらおめでとうございます。 🙂

aptana23

スキーマ選択します。 見たいデータベースだけ設定しておくと便利でしょう。

aptana24

これで設定完了です。

まずは DB ツリービューからぴこぴこすれば内容の閲覧ができることが分かります。 また表示からデータのパッチも可能です。

SQL 開発を行う場合は、SQL 実行ビューで SQL の記述が可能です。 テーブル名などのオートコンプリートや SQL 整形がききますので非常に便利です。

aptana25

ツリーの方からカラム名をとってきて SELECT つくってくれたりもできますね。 🙂

aptana26

プラグインをつくるときなど DB 直接アクセスしたりすることもありますが、そんなときのために環境を統合しておくと便利かと思います。 また最近ではカスタム投稿などの動作確認で (wp_)posts の内容がみたいこともありますのでそんな時にも。

WordPress を動かしながらテーブルを覗いていると、あ、カスタム系って post_type とか taxonomy に任意の文字列をいれれるようになったってことなのね、みたいな発見もあると思います。 🙂