直接お金になる仕事ではないのですが、ここしばらく、某所の BBS を開発するため、 Perl をいじっております。正直、 .NET や JavaScript 、ケータイアプリの開発なんてことばかりやっておりますと、たまにいじる Perl が楽しくて楽しくて、ついついこっちばかりやってしまう、という日々がしばらく続いております。いかんですな。

で、こちらの開発がとりあえずキリの良いところまで進んだので、一旦お蔵入りにしようと思うのですが (といっても年単位で寝かせるわけではないですが)、その前にこれに関連する技術的なメモをしたためておこうかと思うのであります。

作っているのは、さくらの共有レンタルサーバーサービス上で動作する CGI なのですが、レンタルサーバの性質上、 CPAN から最新のモジュールを引っ張ってくることが出来るので、割とモダンチックなスタイルで開発できるのが強みだったりします。

ただ、レンタルサーバ上で動作確認する場合、 500 エラーになってもエラーログをすぐには参照できないので (さくらにメールで問い合わせすることは可能らしいですが…)、弊社サーバー上にも設置し、動作確認するようにしました。

弊社サーバーはさくらの VPS を利用しており、 CentOS5 で動いています。基本的にはソフトウェアの導入は yum から行っているのですが、その場合、 DBD::mysql を始めとした多くの CPAN モジュールが、かなり古いバージョンで導入されることになります。特に、 DBD::mysql は 3.0007 と極めて古く、Unicode を扱うのに必要不可欠な接続時オプション mysql_enable_utf8 が使えないといった弊害がありました。他にも、 DateTime がタイムゾーンを理解できないなど、いろいろと弊害があったため、 CPAN から最新版をインストールしようかと試みたのですが、そのままではほとんどのモジュールについてコンパイルが通らないなど、cpan コマンドからではインストールが出来ませんでした。

CPAN 自体を最新版に

まず、cpan コマンドとして動作する Bundle::CPAN モジュール自体が古いので、それを最新にしてしまいましょう。

$ sudo cpan -i Bundle::CPAN

さらに、導入済みのモジュールを最新版に一括して更新してしまいましょう。こちらは cpan コマンドからではうまくいかなかったので、 perl から。

$ sudo perl -MCPAN -e 'CPAN::Shell->install(CPAN::Shell->r)'

DBD::mysql のインストールには MySQL 自体のソースが必要

ここまでやっても、DBD::mysql のインストールはやっぱり失敗していて、古いバージョンのままです。

$ perl -MDBD::mysql -e 'print "$DBD::mysql::VERSION\n"'
3.0007
$

結論から言うと、DBD::mysql を make する際に、MySQL 自体のヘッダファイルを参照しており、単に yum から MySQL だけを入れた状態ではこのヘッダファイルが導入されていないために、コンパイルに失敗してしまいます。そこで、 MySQL の開発用リソースを導入するパッケージ mysql-devel を事前に入れておく必要があります。

$ sudo yum install mysql-devel
$ sudo cpan -i DBD::mysql

これで、最新の DBD::mysql のインストールが成功するはずです。

と、いっても、現状何かサービスを展開しているわけでも無し、本ブログもこれまで通りそのまま閲覧できますので、「だから何?」とか言われちゃうと困ってしまうわけですが…。

今回の移転作業に於きましては、すべての作業内容を逐次メモに取り、その内容を公開しております。弊社のように、既に他社の専用サーバや VPS を用いてサーバーを構築しているものの、とっても安価でよさげなさくらの VPS に移行したいなぁなどとお考えの方々に、少しでも参考になれば幸いです。

• さくらの VPS セットアップメモ

ファイル構成を検討する

が、その前に、今後もこのサーバーを開発用途に使い続けていくことを考え、使い始めからファイル構成には気を遣ってみようと思い、以下のような方針を出してみました。

• すべての開発関連ファイルは /var/Developer の配下に配置する。
• オリジナルの開発物と、外部から委託された案件とで全体を二分する。
• その中で、プロジェクト毎にディレクトリを設ける。
• プロジェクトのディレクトリ毎に、単独の svn リポジトリと trac リポジトリを設ける。

これを例示すると、以下のようなファイル構成となります。

/var/Developer/
  original/    # オリジナル用
    foo/    # プロジェクト foo
      svn/    # foo の svn リポジトリ
      trac/    # foo の trac リポジトリ
      .htdigest    # 内緒のプロジェクトの場合、 Trac にログオンするためのダイジェスト認証ファイル
    bar/    # プロジェクト bar
      svn/
      trac/
    baz/    # プロジェクト baz
    # ...
  trust/    # 外部から委託された案件用
    hoge/    # プロジェクト hoge
      svn/
      trac/
      .htdigest    # 委託案件は他人にみられちゃまずいので絶対必須
    fuga/    # プロジェクト fuga
    # ...

Trac の導入

それでは Trac を導入しましょう。今回、以下のサイトを参考に、 Trac の導入を行いました。感謝!!

• CentOS & Trac | Hanada.Org
• Trac インストールに挑戦 – メモチョウ

基本的には前者のサイトを参考にしました。後者は python-genshi が yum からは install できなかった点について参考にさせていただきました。

やったことについては概ね以下の通りです。

1. SELinux はそもそも使っていません。 iptables は使っていますが、 yum のポートはフィルタしていないのでここも設定不要でした。
2. Subversion 用 WebDAV モジュールはインストールだけしましたが、秘匿する案件については利用予定はないので、Apache 側の設定まではしませんでした。
3. 今回は外部委託の案件なので、この案件のファイルにアクセスできる権限のためのグループを設けました。

   % sudo groupadd hoge
   % sudo vim /etc/group # グループにユーザーを追加する
   

4. Subversion リポジトリを構築します。だいたい以下のような感じです。

   % su -
   % mkdir -p /var/Developer/trust/hoge/svn
   % cd /var/Developer/trust/hoge/svn
   % chown murachi.hoge .
   % chmod g+w .
   % chmod g+s .    # 配下のファイルのデフォルトグループ権限が統一される
   % exit    # root のままリポジトリ作ると import 時に問題が起こるので…
   % svnadmin create /var/Developer/trust/hoge/svn

   そして手元の環境から、既に作り始めているファイルをディレクトリごと import します。 Linux 環境、あるいは Cygwin などを利用しているならば、以下の通り。

   % svn import /path/to/hoge svn+ssh://murachi@onaka.harapeko.jp/var/Developer/trust/hoge/svn/trunk/hoge

   trunk/hoge がインポート先パスに追加されているのは、メイントランクのプロジェクト名にファイルを突っ込みたいから。 TortoiseSVN を使うのであれば、インポートするフォルダを選択して、上記と同様の URI を指定してあげれば ok 。別の場所に同様の URI でチェックアウトできることも確認しておきましょう。

5. Trac をインストールします。先ほどのサイトを参照して、 yum のリポジトリ追加を行ってからインストールを試みます。が、python-genshi が無いよ、と怒られてしまいますので、これだけは rpm パッケージを拾ってきて手動でインストールする必要があります。

   % sudo yum install python-setuptools    # python-genshi のインストールに必要でした。
   # 事前にディレクトリを参照して最新版のファイル名を確認しておきましょう。。。
   % wget http://packages.sw.be/python-genshi/python-genshi-0.5.1-2.el5.rf.i386.rpm
   % sudo rpm -i python-genshi-0.5.1-2.el5.rf.i386.rpm
   % sudo yum install trac

   ここでインストールされる Trac は英語版なので、これは一旦削除し、代わりに日本語版の Trac をインストールします。

   % sudo yum remove trac
   # これも事前に最新版のファイルの URI を確認しておきましょう。。。
   % wget http://www.i-act.co.jp/project/products/downloads/Trac-0.11.2.1.ja1.zip
   % unzip Trac-0.11.2.1.ja1.zip
   % cd trac-0.11.2.1.ja1
   % sudo python setup.py install

6. trac リポジトリを構築します。
   普通に作ろうとすると DBMS に SQLite を使用するようになるのですが、今回は MySQL を使いたかったので、こちらのサイトを参考に、データベースの構築から行います。ちなみに、 MySQL は既にインストールされていて、使える状態になっているものとします。

   % mysql -u root -p
   mysql> create database trac_hoge;
   mysql> grant all privileges on trac_hoge.* to trac_hoge@localhost identified by 'password';
   mysql> use trac_hoge;
   mysql> alter database default character set utf8 collate utf8_general_ci;
   mysql> quit
   % su -
   % mkdir /var/Developer/trust/hoge/trac
   % cd /var/Developer/trust/hoge/trac
   % chown murachi.apache .    # apache から扱えるように。
   % chmod g+w .
   % chmod g+s .
   % exit
   % trac-admin /var/Developer/trust/hoge/trac/hoge initenv

   そして、database connection string について聞かれたら、以下のように入力します。

   mysql://trac_hoge:password@localhost/trac_hoge

7. Apache に設定を追加します。弊社の環境ではヴァーチャルホスト設定によってサブドメインを追加しているので、そのディレクティブ内に設定を記述します。今回は秘匿する必要があり、 SSL を介して用いたいので、 /etc/httpd/conf.d/ssl.conf の中に設定を記述します。

   その前に、ダイジェスト認証を用いたいので、まずはダイジェスト認証用のユーザー定義ファイルを作成します。

   % htdigest -c /var/Developer/trust/hoge/.htdigest realm murachi

   設定の記述内容は、概ね以下の通りです。

   <VertualHost>
   
   # ...
   
   # trac location
   <Location /trust/hoge/trac>
       SetHandler mod_python
       PythonDebug On
       PythonHandler trac.web.modpython_frontend
       PythonOption TracEnvParentDir /var/Developer/trust/hoge/trac
       PythonOption TracUriRoot /trust/hoge/trac
   </Location>
   
   <Location /trust/hoge>
       AuthType Digest
       AuthName realm
       AuthUserFile "/var/Developer/trust/hoge/.htdigest"
       Require valid-user
   </Location>
   
   </VirtualHost>

   Digest 認証の場合、 AuthName は realm でなければなりません。もっとも、 SSL で通信路自体が暗号化されているので、 Basic 認証でも問題なかったかも知れませんが…。

   それから、Digest 認証で AuthUserFile ステートメントを用いるのは Apache 2.2 以降で、 2.0 以前の場合は AuthDigestFile ステートメントを使用します。

8. 設定が文法上問題ないことを確認してから、 Apache を再起動します。

   % sudo /etc/init.d/httpd configtest
   % sudo /etc/init.d/httpd restart

URI がいまいち…

以上ですべての準備が整いました。ブラウザから、 https://developer.harapeko.jp/trust/hoge/trac に接続してみます。すると、以下のようなページが表示されました。

えっと…。どうやらここには Trac そのものではなく、 Trac のリポジトリを設定したプロジェクトの一覧が配置される模様。

で、表示されているリンクをクリックすると Trac のトップページに遷移するのですが…

URI の中にプロジェクト名が 2つ重なって出てきてしまう。これは何ともイタダケナイ。

構成を再検討

そんなわけで、ファイルの構成を再検討中です。とりあえず、反省点としては以下の通りでしょうか。

• svn リポジトリと trac リポジトリは、やっぱり完全に分けた方がよさそう。そもそも、svn リポジトリは unix ユーザーで権限を制御しているのに対して、 trac は Web の認証で権限を制御するので、あんまり一緒に管理するメリットはない気がしてきた。
• trac リポジトリはオリジナル用と外注用の 2つに分けた上でプロジェクト毎に作成し、DB もプロジェクト毎に別個に作成する。アクセス制限はプロジェクトごとにロケーション別で設定可能だが、外注用についてはプロジェクト一覧ページには自分以外は入れないように制限する必要がある (オリジナルも同様に制限するかも…)。
• svn リポジトリはプロジェクトごとに別個に作成する。公開している Trac から svn リポジトリを覗いてみたら外注で開発しているソースが見えちゃったでござるの巻、なんてことがあってはならない。

構成例としては以下のような感じでしょうか…。

/var/Developer/
  svn/
    original/
      foo/
      bar/
      baz/
      # ...
    trust/
      hoge/
      fuga/
      # ...
  trac/
    original/    # オリジナル用の TracEnvParentDir になる
      foo/
        .htdigest    # 認証用のユーザー定義ファイルはリポジトリの中に置いてしまう
      bar/
      baz/
      # ...
    trust/
      hoge/
        .htdigest
      fuga/
        .htdigest
      # ...

という感じで軽くメモを書くだけのつもりが長々と書いてしまいました。これからまた設定です。おなか空いた…。