Posts in category trac

Tracを1.0.1にアップグレードしました

くりすです。

本サイトのTracを0.12.3から1.0.1にアップグレードしましたので、その手順をメモしておきます。

もくじ

  1. ねらい
    1. 構成の細分化とは
    2. virtualenvって何だ
  2. アップグレードの実行
    1. virtualenvのセットアップ
    2. virtualenvを使った、最新版Tracのインストール
    3. Tracを0.12.3から1.0.1にアップグレードする
    4. uwsgiの設定を書き換える

1. ねらい

今回Tracを1.0.1にアップグレードするにあたって、単なるアップグレードではなく、サーバの構成をより細分化することも目的としました。

1.1. 構成の細分化とは

ここでいう構成の細分化とは、システムに搭載する個々のアプリケーションの影響範囲をできるだけ小さくする工夫です。

さて、私が使っているUbuntu 12.04 LTSのサーバには、パッケージマネージャを使ってTracをインストールすることができます:

# apt-get install trac

ところが、パッケージマネージャを使う方法には次のようなデメリットがあります:

  • パッケージマネージャで提供されるアプリケーションは必ずしも最新版ではない
  • システム全体に対してインストールすることになってしまうので、サーバの構成への影響が大きい
    • レンタルサーバなどを使っていてroot権限を持っていない場合などは、そもそもこの方法を用いることができない

そこで、virtualenvを用いて、専用のPython環境を構築することにしました。

1.2. virtualenvって何だ

virtualenvとは、Python環境のセットを好きなだけ錬成するしくみ、つまりPythonの仮想環境です。

virtualenvを使うと、

  • システムのPythonに影響を及ぼさない
    • 一般ユーザの権限でもライブラリのインストールが容易
    • /etc/usrなどに余計なファイルを作らない
    • パッケージマネージャで入れたライブラリと競合しない
  • 必要なだけ専用のPython環境を作ることができる
  • Pythonのバージョンが選べる

といったメリットを得ることができます。

2. アップグレードの実行

以下、例示しているディレクトリは/home/trac/curが従来のTrac環境、/home/trac/newが新しいTrac環境を表します。各自の環境に合わせて読み替えてください。

2.1. virtualenvのセットアップ

virtualenvはサラのUbuntuには入っていませんでしたので、インストール。

# apt-get install python-virtualenv
  1. まず、現在のデータをコピーします。
    $ rsync -a /home/trac/cur/ /home/trac/new
    
    rsyncコマンドにおいて、末尾の`/`のあるなしは極めて重要です。
  1. /home/trac/new下にvirtualenvを生成します。root権限は必要ありません(したがってsudoも不要)
    $ cd /home/trac/new
    $ virtualenv env
    
    そうすると、5秒ほどで専用のPython環境/home/trac/new/envが爆誕します。コマンド引数の内容は任意で、たとえば
    $ virtualenv trac_python_env
    
    とすれば、/home/trac/new/trac_python_envが生まれます。
  1. 新しく作ったPython環境を起動します。
    $ source env/bin/activate
    
    そうすると、先ほど生成したPython仮想環境が起動し、
    (env)$
    
    というプロンプトに変化します。(env)という表示は、envという名称のvirtualenvを使用していることを示します。

2.2. virtualenvを使った、最新版Tracのインストール

新しく作ったPython環境においては、基本的にeasy_installあるいはpipを用いて追加モジュールのインストールをします。中にはGenshi(後述)などコンパイルを要するモジュールもあるので、build-essentialを用意しておいたほうがよいでしょう。

# apt-get install build-essential
  1. (env)が起動している状態で、pip install tracを実行します。root権限やsudoは不要。
    (env)$ pip install trac
    
    Tip: Tracがレンダリングに用いるGenshiというモジュールは、高速化のためにPython.hというC++ヘッダファイルを使ってコンパイルするので、
    # apt-get install python-dev
    
    としてこれをインストールしてやると、Genshiの高速化機能の恩恵を受けることができます。

2.3. Tracを0.12.3から1.0.1にアップグレードする

Tracのアップグレードについては詳しい手順は公式ドキュメントに譲ります。要約するとこんな感じです:

(env)$ cd /home/trac
(env)$ trac-admin new upgrade
(env)$ trac-admin new wiki upgrade

これで、Tracは最新版(1.0.1)になりました。最後に、uwsgiの設定を更新しましょう。

2.4. uwsgiの設定を書き換える

本ブログの一番最初の記事に記載していますtrac.xmlがベースです。これを/etc/uwsgi/sites-available/trac.xmlとして準備します。

Note: これはuwsgi 1.0.3-debian 用の設定です。最新版のuwsgi(2.0)では異なる部分が結構あるので、その場合以下は参考にできないかもしれません。

  • .xml

    old new  
    11<uwsgi>
    22    <socket>127.0.0.1:7777</socket>
    33    <plugin>python</plugin>
    4     <env>TRAC_ENV=/home/trac/cur</env>
     4    <env>TRAC_ENV=/home/trac/new</env>
     5    <virtualenv>/home/trac/new/env</virtualenv>
    56    <module>trac.web.main:dispatch_request</module>
    67</uwsgi>

Note: アップグレードなので/etc/uwsgi/sites-enabled/trac.xmlは既に/etc/uwsgi/sites-available/trac.xmlのシンボリックリンクとして存在します。

nginxの設定には変更はありません。

最後に、uwsgiを再起動してアップグレード作業は完了です。

# service uwsgi restart

次はnginxを1.4.4に、uwsgiを2.0にアップグレードしたいので勉強します。

あとUpstartを用いて、uwsgiをソケットアクティベーション型の運用にしたいですね。
Running uWSGI via Upstart --- uWSGI 2.0 Documentation

BlogDraftPluginを導入しました

またもやアウトプットが滞っているくりすです。

先ほど、TracFullBlogに下書き機能は無いのかなと思って調べてみたところ、FullBlogPlugin 公式サイトBlogDraftPlugin.pyというものがちらっと言及されているのを見つけました。
ところが本当にちらっとなんです。なんでも「サンプルプラグイン」という扱いで、ものすごく簡易な説明がソースコード内に埋め込まれてるくらいのドキュメンテーションです。(サイトあんぞコラという場合は@x86_64までお伝えください)

導入はいたって簡単でした。

  1. ソースコードを引っ張ってきます。
    $ cd your_trac_dir/plugins
    $ wget http://trac-hacks.org/svn/fullblogplugin/0.11/sample-plugins/BlogDraftPlugin.py
    
  1. trac.iniを以下のように編集して、BlogDraftPluginに対応させます。
    [components]のセクション:
    +++ blogdraftplugin.* = enabled
    
    [trac]のセクション:
    --- permission_policies = DefaultPermissionPolicy, LegacyAttachmentPolicy
    +++ permission_policies = BlogDraftPlugin, DefaultPermissionPolicy, LegacyAttachmentPolicy ; Defaultよりも先である必要があります
    
    [fullblog]のセクション:
    +++ draft_category = draft, Draft ; "draft"でなくても、例えば"shitagaki"でもOKです
    
  1. サービス系を再起動します。
    # service uwsgi restart
    # service nginx restart
    

こうすると、trac.iniのdraft_categoryで定めたカテゴリ名を投稿に含めると、それは下書きとなり、当初の投稿者(ログイン状態)以外は閲覧や編集ができなくなります。

長文を書いていたりブログを書いてる途中で眠くなったりしたときに使えますね。

Wikiにも下書き機能ないのかなぁ。

2つめのTracをホストしてみました

大学や仕事のこと、私的なことなどといったプライベートなあれこれもチケット管理しようといった考えから、公開用であるこのTracプロジェクトとは別に、認証もかけて自分専用のプロジェクトをホストしようと思いました。

同じホスト(同じサーバ)で2つのTracをホストした理由は、単にSSL証明書を節約するためです。


準備

例によって、任意のパスにTrac用のディレクトリを作成し、Trac化します。
詳細は以前の投稿を参照のほど。

trac@reimu ~:$ mkdir another_project
trac@reimu ~:$ trac-admin another_project initenv
trac@reimu ~:$ chown -R trac:www-data another_project
trac@reimu ~:$ chmod -R 775 another_project

失敗例

nginxの設定で、location /privateを設定し、パスを変える方法は失敗でした。
なぜかというと、Tracprivateというハンドラがないからです。

それから、uwsgiのSocketポートを変えただけでも、同様にだめでした。

そんなにたくさん試行錯誤はしていません。エンジニアたるものもっと失敗にぶち当たるべき。

成功例

結局、私的に使うやつなのでポート番号くらい非defaultでもいいだろということで、別のポートでlistenすることにしました。

/etc/nginx/sites-available/trac_private
server {
    listen 55555 ssl;
    server_name x86-64.jp;
    ssl_certificate /path/to/your/ssl/cert.pem;
    ssl_certificate_key /path/to/your/ssl/key.key;
    root /home/trac/another_project;
    
    location /favicon.ico { }
    location /robots.txt { }

    if ($scheme = http) {
    	return 301 https://$server_name$request_uri;
    }
    
    location / {
    	include uwsgi_params;
    	uwsgi_param REMOTE_USER $remote_user;
        uwsgi_param HTTPS on; # リクエストが勝手にHTTPになる現象をこの行で解決
    	include uwsgi_params;
    	uwsgi_pass 127.0.0.1:7778;
    	auth_basic "Trac";
    	auth_basic_user_file "/path/to/your/.htpasswd";
    }
}

uwsgi_passのSocketポート番号は、ほかに走っているuwsgiアプリケーションと違うのに気をつけてください。同じだと破滅が起こります。

このconfをsites-enabledにシンボリックリンク張って、uwsginginxを再起動して完了。

Tracの設定を見なおしたりしてみました

自分のアカウントでhttp-basic認証でログインしていても、どうもAdminメニューからTracの一般設定ができないと思っていました。

結局何が問題だったかというと、自分のアカウントにTRAC_ADMINが設定されていなかっただけでした。凡ミス。
次のコマンドにて解決。

trac@reimu ~:$ trac-admin ~/your_trac_project permission add foo TRAC_ADMIN

先日のブログエントリに記載したコマンドを、自分で実行するのを忘れていたとは。

さらに検証してみると、TRAC_ADMINでなかったのにAdminメニューが選択できたのは、自分がBLOG_ADMINだったからでした。


あれ?と思ったら、まずは設定から見なおしてみると十中八九なんか見つかります。


それはそうと、SharingButtonsPluginを導入してみました。
Wikiにはボタンが設置されたことを確認しましたが、Blogはどうやら外部プラグインを使っているため非対応なのか、表示されません。
暇があったら、様々なプラグインにも対応できるようにこれを改造してみてもいいかもしれませんね。

nginxとuwsgiを使ってTracをホストしよう

このTracをセットアップするのに多くの時間を費やし、文献を読みあさったのでここに手順やハマりどころをまとめておきます。

そこらの文献というのはなぜかコマンドをどの権限やパスで実行するか明記していないケースがあるので、この記事ではコマンドの説明をするときはbashっぽくプロンプトの部分から記述します。

  1. なんかサーバを用意します(当サーバはAmazon EC2上のUbuntu 12.04.2)
    以降、ホスト名はreimuと表します(このホストがreimu.x86-64.jpだから)
  1. 必要なものをパッケージマネージャなり公式サイトなりから引っ張ってきます。
    わたしはaptを使って手を抜きました。依存環境などもまるまる降ってくるし、アップデートの適用もシステムと一緒にできるという恩恵にあずかれます。
    root@reimu ~:# apt-get install nginx uwsgi uwsgi-plugin-python trac trac-git
    
    trac-gitTracgit使いたいから入れておいたもので、必須ではありません。
    で、uwsgiって結局なんなん: Uwsgi?
  1. わたしはWebサイトごとにユーザを作るスタイルを採用しているので、Trac用にユーザを作っちゃいます。
    root@reimu ~:# adduser -G www-data trac
    
    nginxが走るグループは、環境によってはwww-dataではないかもしれません(httpdとか)
    ユーザ分けとかどうでもいい場合はwww-dataさんが参照できるディレクトリを用意するだけで大丈夫です。
  1. Tracのプロジェクトが入るディレクトリを適当に作り、Tracに付属しているTrac-admin?コマンドでそのディレクトリをTrac化します。
    これは通常ユーザ(この記事の例ではtrac, Trac用のユーザを作らなかった場合はwww-data)で行います。
    trac@reimu ~:$ mkdir your_trac_project
    trac@reimu ~:$ trac-admin ~/your_trac_project initenv
    
    initenvを行っているときに、プロジェクトの名称とデータベースファイルのパスを決められます。
    これがTracのタイトルとして反映されます。たとえばこのTracなら真剣な悪ふざけになっています。 どうやらUTF-8なら2バイト文字でもいいみたいです。
  1. このへんでTracの管理者アカウントを登録しておきましょう。
    trac@reimu ~:$ trac-admin ~/your_trac_project permission add foo TRAC_ADMIN
    
    これで、ユーザfooが管理者になりましたので、fooとしてhttp-auth-basic(以下Basic認証と記述)でログインできるように設定します(後述)。

  1. Tracについての、uwsgi用とnginx用のconfigを作ります。
    わたしはこうしました:
/etc/uwsgi/apps-available/trac.xml
<uwsgi>
    <socket>127.0.0.1:7777</socket>
    <plugin>python</plugin> <!--この行が意外と重要-->
    <env>TRAC_ENV=/home/trac/project-directory</env>
    <module>trac.web.main:dispatch_request</module>
</uwsgi>
/etc/nginx/sites-available/trac
server {
    listen 80;
    listen 443 ssl;
    server_name x86-64.jp;
    ssl_certificate /path/to/ssl-cert.pem;
    ssl_certificate_key /path/to/ssl-key.key;
    root /home/trac/your_trac_project;
    
    location /favicon.ico { }
    location /robots.txt { }

    if ($scheme = http) {
    	return 301 https://$server_name$request_uri;
    }
    
    location / {
    	include uwsgi_params;
    	uwsgi_pass 127.0.0.1:7777;
    }

    location /login {
    	include uwsgi_params;
    	uwsgi_param REMOTE_USER $remote_user;
    	uwsgi_pass 127.0.0.1:7777;
    	auth_basic "Trac";
    	auth_basic_user_file "/path/to/your/.htpasswd";
    }
}
uwsgi用のconfで書いたソケットはportが7777なので、こちらのconfでもuwsgi_passを7777に設定しておきます。
このようにして、nginxにアクセスがあったとき、uwsgiを通してTracのコンテンツを引っ張りにいく設定にします。 ちなみにこのTracはSSL-enabledなので、ところどころSSLに関する設定が入っています。
  1. htpasswdを使って、Basic認証に使うアカウントを生成します。
    Apacheを入れていないUbuntuではそんなコマンドないかもしれないですが、apache-utilsをインストールすればOKです(記事は省略)
    trac@reimu ~:$ htpasswd -c /path/to/your/.htpasswd foo
    trac@reimu ~:$ chgrp www-data /path/to/your/.htpasswd
    trac@reimu ~:$ chmod 750 /path/to/your/.htpasswd
    
    これによってユーザfooが含まれる.htpasswdが生成されたので、このユーザでログインすることでTracのWebインタフェースからの管理ができるようになりました。
    個人的にはここでroot以外が.htpasswdを読めるのがきもい。まあしょうがない。
  1. 上で書いたconfigをenableします。
    root@reimu ~:# ln -s /etc/nginx/sites-available/trac /etc/nginx/sites-enabled/trac
    root@reimu ~:# ln -s /etc/uwsgi/apps-available/trac.xml /etc/uwsgi/apps-enabled/trac.xml
    
  1. uwsginginxrestartして完成。
    root@reimu ~:# service uwsgi restart
    root@reimu ~:# service nginx restart
    

ああそういえば:

エラーが発生したときは、結構な確率でパーミッションがおかしいです。
とくにTracを運用するにあたってwww-dataが読み書きできなくてはいけないファイルは、

  • your_trac_project/conf/trac.ini
  • your_trac_project/db/trac.db

が大事です。これらのファイルについてwww-dataがrとwの権限を持っているかチェックしましょう。

それからハマりどころとして、uwsgiの設定にてPythonのプラグインを使うことを明記しないとちゃんと動かなかったのでメモ。


ざっとこんなところかしら。なんか抜けがある気がするので暇な時に検証します。

参考文献

  1. TracInstallUbuntu
  2. TracNginxRecipe
  3. ラフなラボ: Nginx + uwsgi で Trac環境を作った時のメモ
  4. Cookbook recipe for nginx/uwsgi woes