A Day In The Boy's Life -175ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

□ 初めに

この記事は、2007年6月に公開した記事を一部編集したものです。
当初、Trac0.10をベースにした内容でしたが、0.11のバージョンがでたので、それにも対応できるように編集しました。
各見出しの最後にバージョン番号を記載しているものは、そのバージョンをインストールする際にする作業です。
(便宜上、「0.10」または「0.11」と表示しています)
特に記載の無いものは、Trac0.10及びTrac0.11で共通の作業となります。

Tracは、簡単に言えばバグトラッキングシステム(BTS)用の管理ツールです。

バグトラッキングシステムと言うと、システム開発や運用に特化したシステムのように聞こえますが実際は、プロジェクト管理ツールと言ったイメージの方が近いかもしれません。


バージョン管理用のソフトウェアである、subversionを利用する辺りからもソース管理などに特化したシステムかと思っていたのですが、どちらかと言うとこっちがおまけのような扱いです。

wikiなどを利用した情報共有と進捗管理がメインのシステムと言えると思います。


今回は、そのTracのインストール編です。

Trac活用編は、最後の関連記事を参照してください。


※ 実際にやってみて、Tracのインストールは結構面倒に感じたので、All-In-One-TracTrac月 などを導入対象として検討しても良いかもしれません。


今回、私のほうで構築した環境はRedHatES4上であり、それに依存した記述がありますので参考にする際は、適宜自分の環境に置き換えてください。

また、導入対象のTracのバージョンは、「0.10.4」または「0.11.1」です。


1. Trac導入前の事前準備



Tracの動作に必要な、各種ソフトウェアを準備します。

Tracでは、下記のソフトウェアが必要です。


・ Python (バージョン2.3以降)

・ Subversion (バージョン1.0以降。 ※ 1.2.3もしくは1.3.1以降推奨)

・ ClearSilver (バージョン0.9.3以降) ※ [Trac0.10]を使用する場合

・ Genshi (バージョン0.5以降) ※ [Trac0.11]を使用する場合

・ PostgreSQL ※ Tracバージョン0.9以上で対応。また、PostgreSQL以外にもSQLiteが選択可能

・ PyPgSQL   ※ DBにPostgreSQLを選択した場合のみ

・ Webサーバー(今回はApacheを利用。インストール方法は割愛します。)



1.1 Subversionインストール


手元にあるRedHatES4には、Subversionが入っていなかったので取り合えず、up2date経由でインストール。


# up2date -i subversion


これで、subversion-1.1.4-2がインストールされました。


※ up2dateについては「up2dateによるRPMパッケージの更新管理 」も参照してみてください。



1.2a ClearSilverインストール [Trac0.10]


ClearSilver は、PythonやRubyで利用可能なテンプレートエンジンです。

ソースからインストールしましたが、RPMパッケージ もある模様。


インストールしたClearSilverは、バージョン0.10.4です。


$ ./configure --with-python
$ make
$ su -
# make install

1.2b Genshiインストール [Trac0.11]


バージョン0.11からはテンプレートエンジンがGenshiへと切り替わっています。

Genshiのインストールですが、Trac0.11をインストールする際にまとめてインストールしてくれるため、作業をする必要はありません。

ただ、この手順で進むとTracが上手くインストールできないという現象を何回か確認しています。(詳細は「Tracの使い方 - Trac0.10からTrac0.11へのバージョンアップ - 」の番外編を参照)


Genshiを手動でインストールするためには、下記の手順で行えます。


まず、setuptools をインストールします。

setuptoolsのインストールには、そのブートストラップモジュールである「ez_setup.py 」から行うか、ソース(またはRPM) から行えます。


# python ez_setup.py

# python setup.py install

続いて、Genshiを下記のオプションつきでインストールします。


# easy_install --always-unzip Genshi==0.5



1.3 mod_pythonインストール


別に無くてもいいみたいですが、Tracを軽快に動かしたいのであればインストールしておいた方が無難のようです。

こちらは、RPMパッケージがあったので、up2date経由でそれをインストール。

バージョンは、mod_python-3.1.3です。


# up2date -i mod_python


1.4 PyPgSQLインストール


PyPgSQL は、PythonからPostgreSQLへ接続する為のモジュールです。

RPMパッケージは無いようなので、ソースからインストール。


# /usr/bin/python setup.py build
# /usr/bin/python setup.py install


2. Trac導入に必要な環境設定


Tracをインストールする前に、Tracで必要な環境を整えておく必要があります。



2.1 DB作成


DBでPostgreSQLを使用するため、事前にPostgreSQLにTrac用のDBを構築しておきます。

下記では、Trac用のDBである「trac」と、Tracから接続されるPostgreSQL用のユーザー「trac_user」を作成しています。


$ su - postgres
$ createdb tracdb
CREATE DATABASE
$ createuser trac_user
Shall the new role be a superuser? (y/n) y
CREATE ROLE

ユーザー作成後は、接続ユーザー(trac_user)のパスワードを設定しておきましょう。


$ psql tracdb
tracdb=# alter user trac_user password 'trac_user';
ALTER ROLE


2.2 Subversionのリポジトリ作成


初めてSubversionを利用する場合は、予めリポジトリ(ソースの情報や履歴などを格納するディレクトリ)用のディレクトリを作成します。


$ mkdir /home/svn


次に上記ディレクトリ内に、リポジトリを作成


$ svnadmin create /home/svn/project1

「project1」がリポジトリになりますが、これはTracのプロジェクト名(後述)とイコールにしておきます。

作成できたら、念のためにテストしてSubversionが正しく動作するか確認しておいた方が良いでしょう。


$ svn checkout file:///home/svn/project1

「file://」の後に、リポジトリの絶対パスを指定します。

成功すれば「リビジョン 0 をチェックアウトしました。」というメッセージがでます。


最後に、上記のリポジトリに対してWebサーバーの実行ユーザーから書き込み権限を与えておく必要があります。

例えば、


# chown -R hoge:apache /home/svn
# chmod -R 770 /home/svn

などとしておきましょう。



3. Tracインストール


Tracは、公式HP にあるものを利用しても良いですが、国際化がなされておらず全部メニューが英語なのでインタアクト株式会社が提供している日本語版 のものを利用しました。


インストールは、Trac-jaを展開してsetup.pyを「install」オプションで実行するだけです。


# /usr/bin/python setup.py install


成功すれば、「Thank you for choosing Trac 0.10.4. Enjoy your stay!」というメッセージが表示されます。

エラーが出た場合は、後述のエラー対処方法を見てください。



4. Tracの環境設定


Tracのインストールが完了するとお次は、Tracの環境設定です。

Tracの各種環境を設定するには、Tracの管理用コマンドであるtrac-adminで行います。

trac-adminコマンドで、Tracに新規プロジェクトを登録します。

Tracのプロジェクトとは、管理単位を表します。

ですので、複数のプロジェクトを構築する事も可能です。


※ 複数のプロジェクトを作りたい場合は「Tracの使い方 - プロジェクトの追加・削除 - 」を参照


まず、初めにTrac用のプロジェクトを格納するディレクトリを作ります。


$ mkdir /home/trac/

次に、上記のディレクトリ内にTracのプロジェクトを登録(ディレクトリの作成や各種ライブラリの展開)を行います。


$ trac-admin /home/trac/project1 initenv

project1がTrac上のプロジェクト用のディレクトリになります。

initenvの際は、プロジェクト用のディレクトリを指定しなければTracを利用できません。


trac-adminコマンドをinitenvオプション付きで実行すると、下記のようにプロジェクト作成時の各種情報の入力を求められます。


Creating a new Trac environment at /home/trac/project1

Trac will first ask a few questions about your environment
in order to initalize and prepare the project database.

Please enter the name of your project.
This name will be used in page titles and descriptions.

Project Name [My Project]> project1    ← Trac上のプロジェクト名を入力(何でも良い)

Please specify the connection string for the database to use.
By default, a local SQLite database is created in the environment
directory. It is also possible to use an already existing
PostgreSQL database (check the Trac documentation for the exact
connection string syntax).

Database connection string [sqlite:db/trac.db]> postgres://trac_user:trac_user@localhost:5432/tracdb
↑ Tracで利用するDBの接続情報(DBの種類、接続ユーザー/パスワード、ホスト名、DB名)を入力

Please specify the type of version control system,
By default, it will be svn.
If you don't want to use Trac with version control integration,
choose the default here and don't specify a repository directory.
in the next question.

Repository type [svn]>  ← バージョン管理システムの種類。svnなのでそのままEnter

Please specify the absolute path to the version control
repository, or leave it blank to use Trac without a repository.
You can also set the repository location later.

Path to repository [/path/to/repos]> /home/svn/project1
↑ svnのリポジトリパス。プロジェクト用のディレクトリまで指定する。

Please enter location of Trac page templates.
Default is the location of the site-wide templates installed with Trac.

Templates directory [/usr/share/trac/templates]>
↑ Trac用のテンプレートを保管するディレクトリパス。基本デフォルトで問題ない。

成功すれば、最後に「Congratulations!」というメッセージが表示されプロジェクト作成完了。

エラーが出た場合は、後述のエラー対処方法を見てください。

DB情報を入力する際は、DBの種類によって記述が異なります。

PostgreSQLに接続する際には、上記で入力したように


postgres://{ユーザー名}:{パスワード}@{ホスト名}:{ポート番号(任意)}/{DB名}

を入力します。



5. Apache環境設定


最後にApacheの環境設定を加えます。

Apacheの設定ファイルである、httpd.confを開き、下記を追加。


ScriptAlias /trac /usr/share/trac/cgi-bin/trac.cgi
<Location "/trac">
SetHandler mod_python
PythonHandler trac.web.modpython_frontend
PythonOption TracUriRoot "/trac"
PythonOption TracEnvParentDir /home/trac
</Location>

※ Trac0.11環境では、上記の設定にある「ScriptAlias」の1行は不要です。(trac.cgiは存在しません)

Tracの動かし方は、「スタンドアロン 」「CGI 」「FastCGI 」「mod_python 」の4種類あり、それぞれ設定方法が異なります。

上記の設定は、mod_pythonを利用する方法になります。

ScriptAliasの箇所では、「http://hogehoge.com/trac 」とアクセスすると、trac.cgiが呼び出されるように設定。

また、「TracEnvParentDir」では、Tracのプロジェクト格納用ディレクトリを指定します。


httpd.confの編集はさらに続き、ログイン方法を定義しておきます。

ログインは、Trac左上にある「Login」メニューから行えます。

この設定をしておかないと、Loginメニューをクリックした際にTracのエラーが表示されます。(後述)


Tracログイン


<LocationMatch "/trac/[^/]+/login">
AuthType Basic
AuthName "Trac"
AuthUserFile /home/trac/.htpasswd
Require valid-user
</LocationMatch>

Tracのログイン方法 は、Digest認証かBasic認証のどちらかが利用可能です。

上記は、Basic認証をさせる場合に記述です。

上記セット後には、ユーザー名とパスワードが書かれた.htpasswdファイルを作り、上記のAuthUserFileの場所に配置しておきます。


※ もしユーザー管理をTracのTracの管理コンソールから行いたい場合は、Account Manager プラグインを使うことで

  実現できます。詳しくは下記を参照。


参考: [Trac] Account Manager プラグインの使い方


プロジェクトごとにログインできるユーザーを変更したい場合は、プロジェクト用ディレクトリ(/home/trac/project1など)以下に.htpasswdファイルを配置すればよいでしょう。

また、.htaccessファイル等を作って配置しておけばプロジェクトが増えてもhttpd.confファイルを編集しなくて済みます。


httpd.conf編集後は、Apache再起動します。


$ /etc/init.d/httpd restart

これで、「http://hogehoge.com/trac 」にアクセスしてみると「プロジェクト一覧」と書かれた味気ないページが出てきますが、プロジェクト名のリンクを辿るとTracの画面が表示されます。



TracTop



Tracインストール時のエラー対処法


私の環境で「3. Tracインストール」、「4.Trac環境設定」作業中に出たエラーとその対処方法のログです。



- エラーメッセージその1


Failed to create environment. No module named pyPgSQL

pyPgSQLがインストールされていなかった場合にでたエラーです。

1.4に従ってpyPgSQLをインストールすれば解消されました。



- エラーメッセージその2


Failed to create environment. libpq.so.5: cannot open shared object file: No such file or directory 

PostgreSQL用のライブラリである、libpqが見つからないと言うエラーです。

実際にfindコマンドで検索してみたら


/usr/local/pgsql/lib/libpq.so.5.0


に、ファイルが存在したので「/usr/local/lib」辺りにシンボリックリンクを作成する事に。


# ln -s /usr/local/pgsql/lib/libpq.so.5.0 libpq.so.5

続いて、「/usr/local/lib」のパスを、ld.so.confに追記


# vi /etc/ld.so.conf


追記後は、ldconfigコマンドを実行して共有ライブラリに登録。

これで、インストール再開。



- エラーメッセージその3


TracError: /home/hogehoge/svn does not appear to be a Subversion repository.

「4.環境設定」時に指定したSubversionのリポジトリパスが悪い場合に出ます。

trac-adminコマンドをinitenvオプション付きで再実行するか、Tracの環境設定ファイル(trac.ini)を編集します。

trac.iniファイルは、Tracのプロジェクトディレクトリ(/home/trac/project1/conf)内にあります。

その中の、「repository_dir」の項目を編集します。

リポジトリのパスは、「2.2 Subversionのリポジトリ作成」で「svnadmin create」したパスを指定します。



- エラーメッセージその4


SubversionException: ('Berkeley DB error while opening environment for filesystem /home/svn/project1/db:\nPermission denied', 160029)

svnのリポジトリ用ディレクトリに対して書込みなどの権限がない場合に出るエラーです。

「2.2 Subversionのリポジトリ作成」にあるように、適切な権限を設定しておけば回避できます。



- エラーメッセージその5


Internal Error
Authentication information not available. Please refer to the installation documentation .

Tracのインストールが完了して、Webページにアクセスした際に出たエラーです。

Tracのログイン方法を設定していない場合に出ます。

「5. Apache環境設定」に従い、Apacheの設定ファイル内にBasic認証の設定を入れることで回避出来ました。



- エラーメッセージその6

attachments: エラー
([Errno 2] No such file or directory: '/home/trac/attachments/VERSION')
conf: エラー
([Errno 2] No such file or directory: '/home/trac/conf/VERSION') 
htdocs: エラー
([Errno 2] No such file or directory: '/home/trac/htdocs/VERSION')
log: エラー
([Errno 2] No such file or directory: '/home/trac/log/VERSION')
plugins: エラー
([Errno 2] No such file or directory: '/home/trac/plugins/VERSION')
templates: エラー
([Errno 2] No such file or directory: '/home/trac/templates/VERSION')
wiki-macros: エラー
([Errno 2] No such file or directory: '/home/trac/wiki-macros/VERSION') 

Tracのインストールが完了して、Webページにアクセスした際に出たエラーです。

Tracのプロジェクト格納用ディレクトリのパスが正しくない場合に出ます。

「4. Trac環境設定」で、trac-adminコマンドをinitenvオプション付きで実行する際にディレクトリパスを指定しますが、その際にプロジェクト格納用ディレクトリ(project1)を指定しなかった場合に出ました。

つまり、


# trac-admin /home/trac/ initenv   ・・・ ×


# trac-admin /home/trac/project1/ initenv  ・・・ ○

となります。



2007.11.06 追記

- エラーメッセージその7


Failed to create environment. You need to install mxDateTime


別環境でPythonをソースからインストールし、Tracを導入しようとしたところ出たエラーメッセージです。

mxDateTime というPython用モジュールがないとの事だったので、それを導入する事で解消できました。


とりあえず、上記のサイトからソースをダウンロードして


# python setup.py build --skip install

で、いけました。



2007.11.06 追記

- エラーメッセージその8


TracError: Unsupported version control system "svn". Check that the Python bindings for "svn" are correctly installed

同じく別環境でsvnをソースからインストールすると出たエラーメッセージです。

適当にやってみると、上手く言ってるように見えて後々色々問題がでてくるなぁ。。。

(以前の環境は、svnをRPMパッケージで入れてたから、苦労しなかったんですが)


で、調べてみたところ同じ問題を抱えていた方がいまして、その方のBlogに記載の方法で解決しました。

助かりました。


つれづれ日記


解決方法は、SubversionのConfigure時に「--with-swig」を付けてインストールすると言う点でしょうか。

私の環境では、Subversion1.4.5を使用しています。

ちなみに、swigはパッケージを使用。


$ ./configure --enable-swig-bindings=python --with-swig=/usr/bin/swig --disable-static
$ make
# make install
$ make swig-py
# make install

次に、上記で出来上がったディレクトリをPython用のディレクトリ内にシンボリックリンクを作成しておきます。


# ln -s /usr/local/lib/svn-python /usr/local/lib/python2.4/site-packages/svn-python
# ln -s /usr/local/lib/svn-python/svn /usr/local/lib/python2.4/site-packages/svn
# ln -s /usr/local/lib/svn-python/libsvn /usr/local/lib/python2.4/site-packages/libsvn



2009.04.14 追記

- エラーメッセージその9


libpqmodule.c:78:20: error: Python.h: そのようなファイルやディレクトリはありません
libpqmodule.c:79:26: error: structmember.h: そのようなファイルやディレクトリはありません
libpqmodule.c:80:24: error: fileobject.h: そのようなファイルやディレクトリはありません 

Tracインストール時に出たエラーです。

これらのエラーメッセージをたどっていくと、最初のほうに


sh: pg_config: command not found

と出ていました。

pg_configはpostgresql-develに含まれているため、これをインストールして再実行してみるとうまくいきました。





Linuxのサーバー管理をしていると、ある一定の時間が過ぎた為、それらの古いファイルやディレクトリを削除したいという時があります。

また、アプリケーション開発においても、アプリから作り出した一時ファイルを定期的に削除したいという要件があったりもします。(言語特有のセッションファイルなどの一時的に作られるファイルは、その言語の仕組みによって定期的に削除されたりもしますが、アプリから作り出した一時ファイルは独自に作る必要があったりします)


Linuxには、「/tmp」という一時ディレクトリがあり、この中に置かれたファイルやフォルダは一定期間が過ぎたら削除されます。

ここで紹介するtmpwatchコマンドは、そういった要件を満たしてくれ、一定期間過ぎたファイルやディレクトリを一括して削除してくれます。

実は「/tmp」ディレクトリも、このtmpwatchコマンドによって管理され、定期的にディレクトリ内が掃除されています。


tmpwatchコマンドの詳細な使い方は、「man tmpwatch」して読んでもらうとして、ここではパターン別でtmpwatchコマンドのオプションや使い方を紹介していきます。



一定期間過ぎたファイルやディレクトリを削除したい場合


例えば、あるディレクトリ以下がこのような状態だったとします。

# ls -l /home/app/tmp/
total 8
-rw-rw-r-- 1 work work 0 Oct 7 22:55 abc.txt
drwxrwxr-x 2 work work 4096 Oct 7 22:55 hoge
-rw-r--r-- 1 root root 3 Oct 13 00:16 xyz.txt

ここで、mtime(最終更新日時)が24時間以上前の「abc.txt」と「hoge」ディレクトリを削除したいとします。

このときは、


# tmpwatch -m 24 /home/app/tmp/

# ls -la
total 12
-rw-r--r-- 1 root root 3 Oct 13 00:16 xyz.txt

と実行します。

オプションを紐解いていくと、「-m」はmtimeを指定しており、「24」の数字は24時間を表します。

最後に、対象としたいディレクトリを指定します。


このようにtmpwatchコマンドは、対象となるタイムスタンプの種類と、それがどれだけの時間を経過していた場合に削除するのかを指定する事ができます。

タイプのスタンプの種類は、atime(アクセス日時。デフォルト)、mtime(最終更新日時)、ctime(最終ステータス更新日時)の3種類が選択できます。



一定の期間を過ぎたファイルだけ(ディレクトリは削除しない)を対象としたい場合


例えば、あるディレクトリ以下がこのような状態だったとして、削除の対象をファイル(cache.txt)だけに限定したいとします。


# ls -lu /home/app/tmp/
total 4
drwxrwxr-x 2 work work 4096 Oct 7 22:54 HOGE
-rw-r--r-- 1 root root 0 Oct 1 23:23 cache.txt

ここでは、atimeが24時間以上経過しているファイルだけを削除してみます。


# tmpwatch 24 -d /home/app/tmp/

# ls -lu
total 4
drwxrwxr-x 2 work work 4096 Oct 7 22:54 HOGE

ディレクトリは削除したくないという場合は、「-d」オプションを使います。

こうすることで、ディレクトリは残ったままで、ファイルだけが削除されます。



特定のディレクトリは除外して、その他のファイルやディレクトリを削除したい場合


一時ファイルを格納する用途のディレクトリでも、特定のディレクトリ名だけは対象外にしたいという場合があります。

例えば、CVSでバージョン管理していているため、CVS用のディレクトリは除外したいというような場合です。

除外したいディレクトリがある場合は「-x」オプションを使う事で回避する事ができます。


# ls -lu /home/app/tmp/
total 12
drwxr-xr-x 2 root root 4096 Oct 7 22:31 CVS
-rw-r--r-- 1 root root 0 Oct 7 22:31 cache.txt
drwxr-xr-x 2 root root 4096 Oct 7 22:31 HOGE

上記のディレクトリ以下に対して、「CVS」ディレクトリを除外し、その他のファイルとディレクトリを削除するようにtmpwatfchを実行します。


# tmpwatch -x /home/app/tmp/CVS 24 /home/app/tmp/

# ls -lu
total 4
drwxr-xr-x 2 root root 4096 Oct 7 22:31 CVS

除外したいディレクトリが複数ある場合は、「-x」オプションを複数指定します。



□ おまけ(/tmpディレクトリの削除の仕組み)


最初に、/tmpディレクトリはtmpwatchコマンドを使って、中身が定期的に掃除されていると書きましたが、どのような仕組みで実行されているのかを見てみます。

といっても、仕組みはいたって単純で・・・


# more /etc/cron.daily/tmpwatch
/usr/sbin/tmpwatch -x /tmp/.X11-unix -x /tmp/.XIM-unix -x /tmp/.font-unix \
-x /tmp/.ICE-unix -x /tmp/.Test-unix 240 /tmp
/usr/sbin/tmpwatch 720 /var/tmp
for d in /var/{cache/man,catman}/{cat?,X11R6/cat?,local/cat?}; do
  if [ -d "$d" ]; then
    /usr/sbin/tmpwatch -f 720 "$d"
  fi
done

上記のように、Cronに登録されているシェルスクリプトが毎日実行されているだけです。

どのディレクトリが対象外になっているのか、また720時間(30日)で不要なファイルが削除されている事がわかります。



このように、不要なファイル・ディレクトリを定期的に削除したいという要件はよくあったりすることなので、専用のプログラムを書かずとも、このtmpwatchコマンドを使って簡単に実行する事ができますので、覚えておくと便利ではないでしょうか。





渋谷をぶらぶら歩いていたら、こんなイベントを見かけました。


Googleでできること1


沢山の風船を体につけて、実際にふわふわと注を舞う事ができるというイベントです。

みてたら5,6mぐらいまでの高さまで持ち上げてくれるみたいです。


絵本に出てくるような体験ができて、飛んでみたら気持ちよさそうだなぁ~(実際は高いところが苦手なので、そんな余裕はないと思いますが)と思っていましたが、なんとこのイベントを主催していたのが・・・。


Googleでできること2


そう。Google。

以前に、同イベント「Googleでできること。 」のポスターを池袋で見かけたという記事(Googleもなりふりかまってられないのかなぁ )を書きましたが、今度は渋谷で広告だけでなく、このような大きなアトラクションを作って広告を打ち出していました。


誰でも参加できて風船で空のたびを楽しむ事ができるようでした。

また、Googleのオリジナル携帯クリーナーも配ってました。

やはり知名度はあるのか、取りすがりの人も結構足を止めてイベントの写真を取ったりしていました。


前回同様にやっぱりネット企業が現実世界で大掛かりなイベントをやると、違和感がありますね。。。

Googleの割には少しスケールが小さい気もしたんですが。

Googleマップを上手く使って都心で大鬼ごっこ大会でもやるのはダメなのかな?とか思ったり。


追記

Google Japan Blogの中にイベントの事が書いてある記事がありました。


「渋谷で空を飛ぶ」イベント開催 @ Google Japan Blog


検索の数と風船の数が連動していたみたいですね。

確かに私が見たときは物凄い数の風船になっていました。