Server Archive

Seasarプロジェクトでも利用しているJIRA のライセンスを去年の10月に自分用に購入しました。JIRAを開発しているAtlassian社が10ユーザまで利用できるGet Started for $10というライセンスを始めたので思わず買いました。JIRA 4.0になって、JIRA 3.x以前にあったエディションの違いが無くなり、$10でEnterpriseエディションが使えるというのは破格です。JIRA 3.xまではLDAPサポートにEnterprise以上が必要でとても買える金額では無かったため嬉しいです。また、このライセンスの購入費用は全額 Room to Read に寄付されるプログラムになっています。

日本円で購入したい場合は、Atlassian社のOfficial Atlassian Partnerである リックソフト株式会社 が1,050 円で販売されています。

• Bug Tracking, Issue Tracking & Project Management Software – JIRA (Atlassian社)
• アトラシアン(Atlassian)製品の価格と購入（オンライン販売） (リックソフト株式会社)

そんなわけで、だいぶ前置置きが長くなりましたが、自分用にJIRAの環境を作りました。購入当初JIRA 4.0には 新しく導入されたガジェットの仕組みがSSL環境で上手く動かない問題 があったので、使い始めたのはこの問題がJIRA側で解決した4.0.1からです。

ただ、まだ問題があって、Seasarプロジェクトで利用していた3.xのインストール手順でwarファイルを作成し、Tomcatにデプロイするとエラーがでて上手く起動しないのです。いろいろ試してみると自分で追加していたPluginを全部外すと起動しました。そんなことをつぶやいていたらリックソフトのohnukiさんがコンタクトをくださっていろいろやりとりした結果、原因が判明しました。

原因は、JIRA 4.0からOSGiを使用した新しいPlugin機構(Version 2)がサポートされ、JIRA 3.xの時とPluginの配置の仕方が変わっていたことでした。これに気付かず、JIRA 3.xの導入の仕方で入れていたので上手くPluginがロードされなかったようです。一応、互換性のため、古いPluginの配置方法(Version 1)も使えるようですが、Tomcat 5.5.28では動作するものの、Tomcat 6.0.20では動作せず、それでエラーが出ていました。

• 参考: Managing JIRA’s Plugins
  • Version 1: atlassian-jira/WEB-INF/lib/ 以下に配置
  • Version 2: jira.home/plugins/installed-plugins/ 以下に配置
    • jira.home はJIRA 4.0から導入されたホームディレクトリ指定

というわけで、無事やっとPluginも使えるようになりました。ohnukiさんありがとうございました！

Pluginが使えるようになったので、SeasarプロジェクトのJIRAも近日アップグレードのテストをし、アナウンスを出した後に現在の3.13.5から4.0.1に更新したいと思います。

以下、何かの参考までにVersion 1 + Tomcat 6.0.20で起動した時の例外全文を記載しておきます。

tDiaryからWordPressに乗り換え、これから書いていくのに標準のエディタで書くのがどうしても面倒だったので、一番慣れ親しんでいるFreeStyle Wikiの記法で書けるPlugin、WP FreeStyle Wikiを作りました。作ったといってもかなりの強引なことをしていてFreeStyle Wikiを丸ごと中で持っており、そこへ外部コマンドで投げてレンダリングしているだけです。

これは、大晦日の31日にWordPress Pluginをなんとなく見ていたところ、makotokwさん(ありがとうございます！)が作られているPukiWiki for WordPressというPluginを見つけて、ソースを見てみたらPukiWikiを丸ごと中に持っていてそんな手があったかと、そのまま勢いで年が明ける前にFreeStyle Wiki用に改造したものです。

以下に置いてありますので使いたい方がいましたらご自由にお使いください。ライセンスは中に持っているFreeStyle Wikiと同じGPLです。

• [2010-01-01]: WP FreeStyle Wiki 0.1
  • 最初のリリース、FreeStyle Wiki 3.6.3内蔵、そのうち中身を整理してPlugin Directoryに登録するかもしれません
• [2010-01-01]: WP FreeStyle Wiki 0.1.1 リリース
  • Kenichi Maehashiさんからいただいたパッチを適用しました

記法サンプル

以下、記法のサンプルです。 [fswiki] と [/fswiki] で囲んだ部分がFreeStyle Wikiで処理されます。

• 要約: activateCmosToken 0xXXXX でDellのサーバマシンのBIOS設定は変えられます (但し、サポート外)

既に CentOS 5.x をインストール済みの Dell PowerEdge 830 サーバで、OS上でメモリがなぜか256MBしか認識されていませんでした。何か壊れてるのかと思い、既にインストールしてあったDell提供のサーバ管理ソフトウェア OpenManage でハードウェア情報を確認してみると、1GBのメモリが2枚認識されており、合計2GBと表示されていました。

そこで調べてみるとDellのサーバマシンのBIOSには、巨大なメモリが見えるとインストールが失敗するようなOSインストール用に OS Install Mode という設定があり、これが Enable になっているとメモリが256MBしか見えないようにハード的に制約を加えるようです。

というわけで、BIOSの設定を変えれば良いことが判りました。でも、このサーバは遠隔地に置いてあって、現地に行くのがちょっと大変です。こういう時にリモートKVMが使える別売りのDell Remote Access Controller(DRAC)が入っていれば、BIOS画面を直に見ながら簡単に設定できるのですが、残念ながらこのマシンにはDRACは入っていませんでした。というわけで、Linux上からBIOSの設定を変えられないのかなと調べたら変えられました。方法としては次の2つあります。

1. OpenManage 上のBIOS設定で変更
2. smbios に含まれるコマンドで変更

1は、WEB UIから設定する方法ですが、設定できる項目に限りがありました。基本的な項目以外は設定できないと思って良いでしょう。今回設定を変えたかった OS Install Mode も設定できませんでした。以下に、PowerEdge 830 で設定可能な項目と設定されていた値を記しておきます。

• 一般
  • Num Lock: オン
  • Diskette: 自動
  • NIC: PXE で有効
  • USB: BIOS サポートありで有効
  • IDE: 自動
  • Boot Sequence: デバイスリスト
  • Speaker: オン
  • CPU Logical Processor (HyperThreading): 有効
  • AC Power Recovery Mode: 最終
  • Embedded SATA Controller: ATA
  • SATA Port 0: 自動
  • SATA Port 1: 自動
  • SATA Port 2: オフ
  • SATA Port 3: オフ
  • IDE Primary Drive 0: 自動
  • IDE Primary Drive 1: オフ
  • Demand-Based Power Management: 無効
• シリアル通信
  • Serial Port 1: 不明
  • Console Redirection After Boot: 有効
  • Console Redirection: シリアルポート 1
  • Console Redirection Failsafe BAUD Rate: 19200

OpenManage はyumで簡単にインストールできるので、上記で設定した項目があれば、OpenManage で設定するのが良いと思います。

• 参考: Dell OMSA 6.1 Linux repository

2は、コマンドラインから設定する方法です。smbios と libsmbios は、OpenManage を入れると一緒にインストールされるDellのサーバマシンのBIOSにアクセスするためのユーティリティ群です。

• Command-line tools summary
• libsmbios – Trac

こちらはおそらくDellのサーバマシンに用意されているBIOSの設定項目すべてを設定できるのだと思います。ただし、BIOSの設定を変える activateCmosToken というコマンドは Unsupported Binaries に分類されています。従って、この記事を読んで設定したらBIOSが壊れてマシンが起動しなくなることもあるかもしれません。そうなっても自分で責任とれる方以外は絶対に行わない方が良いでしょう。

というわけで、設定の仕方です。設定を行うのはactivateCmosToken コマンドを使います。基本構文は次のとおりです。

# /usr/sbin/activateCmosToken 0x"Token Value"

Token Valueというのは、BIOS設定の項目とというる値に対してユニークに割り振られている値になります。Token Valueの一覧は以下にあります。先頭の項目がToken Valueになります。

• Token Value List

見てみれば判りますが、よくあるBIOS設定項目、最新の技術に関する設定項目、そして、Dell独自の設定項目があります。

現在の値を確認するには、isCmosTokenActive コマンドを使います。activateCmosToken 同様、引数に 0x"Token Value" を取ればいいだけです。出力の BITFIELD が 1 の場合、それが有効になっているという意味です。

では具体的に OS Install Mode を設定を変え、設定が変わっているか確認します。Token Value List より、OS Install Mode のとりうる値は Enable と Disable の2つで、それぞれに 0x008a と 0x008b の Token Value が割り当てられています。片方の Token Value に対して activateCmosToken を実行すると、もう片方の Token Value の BITFIELD が無効を示す 0 に自動的に変わります。

• Limit System Memory (OS Install Mode) を無効化する方法

# /usr/sbin/activateCmosToken 0x008b
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008b  Location 0x55 AND(fe) OR(0)  BITFIELD: 1
# /usr/sbin/isCmosTokenActive 0x008a
Running...
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008a  Location 0x55 AND(fe) OR(1)  BITFIELD: 0
# /usr/sbin/isCmosTokenActive 0x008b
Running...
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008b  Location 0x55 AND(fe) OR(0)  BITFIELD: 1

• Limit System Memory (OS Install Mode) 有効化する方法

# /usr/sbin/activateCmosToken 0x008a
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008a  Location 0x55 AND(fe) OR(1)  BITFIELD: 1
# /usr/sbin/isCmosTokenActive 0x008a
Running...
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008a  Location 0x55 AND(fe) OR(1)  BITFIELD: 1
# /usr/sbin/isCmosTokenActive 0x008b
Running...
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008b  Location 0x55 AND(fe) OR(0)  BITFIELD: 0

以上です。設定はマシンを再起動すると反映されます。

実際に上記の OS Install Mode を無効化する方法で実際に設定しました。その結果、次のように正常にメモリ2GB認識されるようになりました。

• 設定前

# free
             total       used       free     shared    buffers     cached
Mem:        252164     232364      19800          0       9264     129620
-/+ buffers/cache:      93480     158684
Swap:      2097144        236    2096908

• 設定後

# free
             total       used       free     shared    buffers     cached
Mem:       2059368     220968    1838400          0      10396     134724
-/+ buffers/cache:      75848    1983520
Swap:      2097144          0    2097144

無事、サーバのある現地に行くことなく、BIOS設定を変えることができました。遠隔地にあるサーバマシンのBIOS設定をどうしてもリモートで変えたい場合は、試してみると良いかもしれません。ただし、サポート外の方法ですので、BIOSが壊れて起動しなくなるかもしれないことは覚えておいてくださいね！

最近XenとKVMのHVM環境を比較して試していますが、これまで1台のマシン環境を毎回壊して作り直していました。これが毎回面倒なため、現在、他の用途だったマシンを2台潰して再構築しています。

仮想化環境をテストするのに、PVM環境をテストするなら適当な仮想化環境上(例: VMwareの上でXen PVM環境)で問題ないものの、HVM環境をテストするにはVT対応のCPUが載った実機が必要になるので面倒です。最近のCPUでないとVT対応していないし、VMをたくさん動かすにはメモリもたくさん必要で、そこらへんに余ってる古いマシンで試せず困りものです。

最終的にあと2台用意してXenとKVMを2ノードづつ計4台の環境にしたいものの残り2台をどうしようかな。

• DRBD 8.3.x + Heartbeat 2.1.4 を使用する場合、この修正が必要です。
• DRBD 8.2.x + Heartbeat 2.1.4 を使用する場合、この修正は不要です。

DRBD 8.3.x にアップデートしたら、HeartbeatでCRMのDRBDリソースが上手く動かなくなりました。以下のようなエラー。

lrmd[11950]: 2009/09/03_14:15:12 info: rsc:drbd1:0: start
crmd[11953]: 2009/09/03_14:15:12 info: do_lrm_rsc_op:
 Performing op=drbd1:1_start_0 key=xx:4:0:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
crmd[11953]: 2009/09/03_14:15:12 info: do_lrm_rsc_op:
 Performing op=drbd1:0_start_0 key=xx:4:0:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
lrmd[11950]: 2009/09/03_14:15:12 info: RA output: (drbd1:0:start:stdout) 1:
 Failure: (124) Device is attached to a disk (use detach first)
 Command 'drbdsetup 1 disk /dev/VolGroup01/DRBD1 /dev/VolGroup01/DRBD1 internal
  --set-defaults --create-device' terminated with exit code 10
drbd[12636]:    2009/09/03_14:15:12 ERROR: drbd1 start: not in Secondary mode after start.
crmd[11953]: 2009/09/03_14:15:12 info: process_lrm_event:
 LRM operation drbd1:0_start_0 (call=16, rc=1) complete

原因はDRBDリソースが drbdadm state コマンドを使っているせいです。8.3からは drbdadm role コマンドを使うのが正しいそうです。以下、drbdadmコマンドの実行例です。

# drbdadm state drbd1
drbdadm state' is deprecated, use 'drbdadm role' instead.
Primary/Secondary

1行目の警告が邪魔してHeartbeatが上手く動かないようです。しょうがないので手動でDRBDリソース /usr/lib/ocf/resource.d/heartbeat/drbd を修正しましょう。以下、修正後のdiffです。

# diff /usr/lib/ocf/resource.d/heartbeat/drbd.default /usr/lib/ocf/resource.d/heartbeat/drbd
235c235
<       DRBD_STATE=$(do_drbdadm state $RESOURCE)
---
>       DRBD_STATE=$(do_drbdadm role $RESOURCE)

これで上手く起動するようになります。たぶん、Heartbeat 2.1.5 がリリースされれば修正されたものがインストールされます。

• Linux-HA Dev: resources/OCF/drbd@3317a881ba21

ちなみに Heartbeat 2.1.3 の Master/Slaveリソースはバグってて、1個のMaster/Slaveリソースでフェイルオーバが始まると他のすべてのMaster/Slaveリソースも一旦ダウンしてしまうので使わない方が良いです。

後輩から教えて貰いました。CentOS 4 と CentOS 5 のDRBDパッケージにDRBD 8.3系が加わるようです。来週リリースされるらしいので準備しておきましょう。

• DRBD packages in CentOS 4 and CentOS 5 to be updated

今までCentOS 5では、DRBD 8.0系と8.2系があって、それぞれdrbd-8.0.x, kmod-drbd-8.0.xとdrbd82-8.2.x, kmod-drbd82-8.2.xというパッケージがありましたが、これにdrbd83-8.3.x, kmod-drbd83-8.3.xが加わるようです。

パッケージ名が違うので勝手に入ることはないと思いますが既に使っている方は把握しておいた方が良いでしょう。既に使っていて8.3系に更新する場合は、上記のブログではセカンダリノードから更新していく手順が書かれています。

手元の環境はたすき掛けにしているので、結果的に一気にやることになりますね。

[追記] 9/2にリリースされました。

1.5.x系か1.6.x系にあげることも考えましたが今回はとりあえずパッチで済ませました。パッチは以下のどっちでもOK。1箇所だけ中身違う箇所があるけどやってることは一緒でした。

• [RHSA-2009:1203-01] Important: subversion security update のSRPMの中の subversion-1.4.2-CVE-2009-2411.patch
• Patch to 1.4.x branch for CVE-2009-2411 の添付ファイルのパッチ

Atlassianのサポートの方から64-bit JVMは推奨していないと教えていただき、32-bitに変えてみたところ、多少重い時は相変わらずあるものの全くアクセス不能になることはなくなりました。

ポインタとして示していただいたFishEyeのSystem Requirements にも下記のように急激にメモリを消費するってちゃんと明記されていました。

We strongly recommend the use of a 32-bit JDK/JRE rather than a 64-bit JDK/JRE. 64-bit JDK/JREs will consume the available RAM more rapidly, and this may result in poor performance.

他のインストール方法や管理、パフォーマンスチューニングのドキュメントは読んでたけど、肝心のSystem Requirementsはスルーしてました。。

32-bit JVMに変えたのでVMのパラメータも変更しました。

FISHEYE_OPTS="-Xms512m -Xmx2048m -XX:NewSize=256m -XX:MaxNewSize=256m \
-XX:PermSize=128m -XX:MaxPermSize=128m"

• FishEyeが重い
• FishEyeが重い (2)

どうやらSVNへのアクセス中にSVNKitの例外が発生すると、その後ひどいことになるらしい。

FishEyeのソースは見れないのでAtlassianにサポートをお願いしてみました。

2009-08-04追記: とりあえず解決しました。

• FishEyeが重い
• FishEyeが重い (2)
• FishEyeが重い (とりあえず解決)

ソースコードブラウザをFishEye & Crucibleへ移行したら重すぎて全然表示出来ていませんでした。富豪的にメモリを割り当てて、VMのパラメータを変えてみました。

FISHEYE_OPTS="-Xms1024M -Xmx3072M -XX:NewSize=768M -XX:MaxNewSize=768M \
-XX:PermSize=128M -XX:MaxPermSize=256M -XX:+UseConcMarkSweepGC"

でもまだ重いです。また、変えるかもしれません。iowaitしているわけでも、load averageが高いわけでもなく、ただただJavaのオブジェクト生成が大量にありGCが掛かって遅いように見えます。

2009-08-04追記: とりあえず解決しました。

• FishEyeが重い
• FishEyeが重い (2)
• FishEyeが重い (とりあえず解決)