= Trac と mod_wsgi = #Tracandmod_wsgi '''重要な Note:''' ''バージョン 1.3 か 2.3 かそれ以降の `mod_wsgi` を使用してください。バージョン 2.0 には添付ファイルのダウンロードで問題を生じます ([http://trac.edgewall.org/ticket/7205 #7205] 参照)。'' [http://code.google.com/p/modwsgi/ mod_wsgi] は WSGI 互換の Python アプリケーションを Apache 上で直接起動させることができる Apache のモジュールです。 mod_wsgi アダプタは、 Python ベースの Web アプリケーションを Apache にホスティングするための WSGI 互換のインタフェースを提供する Apacheのモジュールです。アダプタは Apache の C 言語ランタイム向けに完全に C 言語で書かれており、 Apache 内部にホストされる WSGI アプリケーションでは、従来からある mod_python や CGI 向けの WSGI アダプタ使用する場合に比べて相当よい性能を出すことができます。 すでに Trac は mod_wsgi の top で起動させることができるようになっています。下記に示すようにアプリケーションスクリプトを Python のファイルとして作成してください。一般的にこのスクリプトは、 .wsgi という拡張子で保存します。 {{{ import os os.environ['TRAC_ENV'] = '/usr/local/trac/mysite' os.environ['PYTHON_EGG_CACHE'] = '/usr/local/trac/mysite/eggs' import trac.web.main application = trac.web.main.dispatch_request }}} 環境変数 {{{TRAC_ENV}}} は通常通り Trac environment のディレクトリを指定します (複数の Trac environment を含むディレクトリであれば {{{TRAC_ENV_PARENT_DIR}}} を使うこともできます)。 {{{PYTHON_EGG_CACHE}}} は Python eggs を一時的に展開するのに使用するディレクトリを指定します。[[BR]] 明快さのために、このファイルの拡張子は {{{.wsgi}}} とすべきです。 Apache にアクセス権を開放できるのであれば、このファイルは自分が所有権を持つディレクトリに置くこともできます。 この .wsgi ファイルは TracAdmin のコマンド {{{deploy}}} を使用することで作成することができます。 Trac と egg ファイルをインストールしたパスが通常と異なる場合、それらのパスを以下の要領で wsgi スクリプトの先頭に記述する必要があります: {{{ import site site.addsitedir('/usr/local/trac/lib/python2.4/site-packages') }}} パスはインストールした Trac のライブラリに位置に一致するように変更してください。 wsgi-script の準備ができたら、以下のように httpd.conf に設定を追加してください。 {{{ WSGIScriptAlias /trac /usr/local/trac/mysite/apache/mysite.wsgi WSGIApplicationGroup %{GLOBAL} Order deny,allow Allow from all }}} Trac environment のサブディレクトリにスクリプトがある場合、 Apache がスクリプトを起動する為には、スクリプトが含まれるディレクトリまで完全に Apache がアクセスできなければなりません。 {{{WSGIApplicationGroup}}} ディレクティブを使用すると、常に mod_wsgi が作成した最初の Python インタプリタ内で Trac が起動することが保証されます; これは Trac で使用している Subversion の Python バインディングがサブインタプリタでは動作しないことがあるため必要になります。リクエストがハングし、 Apache がクラッシュしたような結果が返ります。この設定を行った後は Apache を再起動しないと反映されません。 Apache, mod_wsgi, Python 本体 (Trac とその依存ライブラリを除く) の設定をテストしたい場合、簡単な wsgi アプリケーションを使用するとリクエストが処理されているか確認することができます (以下に示す内容だけを持つ .wsgi スクリプトを使用してください): {{{ def application(environ, start_response): start_response('200 OK',[('Content-type','text/html')]) return ['Hello World!'] }}} mod_wsgi の [http://code.google.com/p/modwsgi/wiki/IntegrationWithTrac インストール例] に Trac の情報が掲載されています。 トラブルシューティングの Tips は [TracModPython#Troubleshooting mod_python のトラブルシューティング] セクションも参考になります。 Apache に関連する問題の多くは似通っていて、多くの場合 mod_wsgi を使用する [http://code.google.com/p/modwsgi/wiki/ApplicationIssues アプリケーション側の問題] です。 == Trac と PostgreSQL == #TracwithPostgreSQL mod_wsgi アダプタを使用し、 Trac のインスタンスを複数ホストしている場合に、 PostgreSQL (もしかすると MySQL も?) をデータベースバックエンドとして使用していると、大量のデータベース接続が生成され (PostgreSQL のプロセスも大量に発生し) てしまいます。 さしあたり動く解決方法として、 Trac が持つコネクションプールを無効化する方法があります。これは trac.db.postgres_backend の PostgreSQLConnection クラスで定義されている poolable を False に設定することで適用できます。 この方法を適用するために、 Trac のソースを変更する必要はありません。以下に示す行を trac.wsgi に追加してください: {{{ import trac.db.postgres_backend trac.db.postgres_backend.PostgreSQLConnection.poolable = False }}} この設定で Trac ページを生成した後にコネクションを捨てるようになり、データベースへの接続数は最小に保たれます。