Tracを1.0.1にアップグレードしました
くりすです。
本サイトのTrac
を0.12.3から1.0.1にアップグレードしましたので、その手順をメモしておきます。
もくじ
- ねらい
- 構成の細分化とは
virtualenv
って何だ
- アップグレードの実行
virtualenv
のセットアップvirtualenv
を使った、最新版TracのインストールTrac
を0.12.3から1.0.1にアップグレードする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
- まず、現在のデータをコピーします。
$ rsync -a /home/trac/cur/ /home/trac/new
rsyncコマンドにおいて、末尾の`/`のあるなしは極めて重要です。
/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
が生まれます。
- 新しく作った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
(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 1 1 <uwsgi> 2 2 <socket>127.0.0.1:7777</socket> 3 3 <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> 5 6 <module>trac.web.main:dispatch_request</module> 6 7 </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までお伝えください)
導入はいたって簡単でした。
- ソースコードを引っ張ってきます。
$ cd your_trac_dir/plugins $ wget http://trac-hacks.org/svn/fullblogplugin/0.11/sample-plugins/BlogDraftPlugin.py
- 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です
- サービス系を再起動します。
# service uwsgi restart # service nginx restart
こうすると、trac.iniのdraft_category
で定めたカテゴリ名を投稿に含めると、それは下書きとなり、当初の投稿者(ログイン状態)以外は閲覧や編集ができなくなります。
長文を書いていたりブログを書いてる途中で眠くなったりしたときに使えますね。
Wikiにも下書き機能ないのかなぁ。
2つめのTracをホストしてみました
大学や仕事のこと、私的なことなどといったプライベートなあれこれもチケット管理しようといった考えから、公開用であるこのTrac
プロジェクトとは別に、認証もかけて自分専用のプロジェクトをホストしようと思いました。
同じホスト(同じサーバ)で2つのTrac
をホストした理由は、単にSSL証明書を節約するためです。
準備
例によって、任意のパスにTrac
用のディレクトリを作成し、Trac
化します。
詳細は以前の投稿を参照のほど。
[email protected] ~:$ mkdir another_project [email protected] ~:$ trac-admin another_project initenv [email protected] ~:$ chown -R trac:www-data another_project [email protected] ~:$ chmod -R 775 another_project
失敗例
nginxの設定で、location /private
を設定し、パスを変える方法は失敗でした。
なぜかというと、Trac
にprivate
というハンドラがないからです。
それから、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
にシンボリックリンク張って、uwsgi
とnginx
を再起動して完了。
Tracの設定を見なおしたりしてみました
自分のアカウントでhttp-basic認証でログインしていても、どうもAdmin
メニューからTracの一般設定ができないと思っていました。
結局何が問題だったかというと、自分のアカウントにTRAC_ADMINが設定されていなかっただけでした。凡ミス。
次のコマンドにて解決。
[email protected] ~:$ trac-admin ~/your_trac_project permission add foo TRAC_ADMIN
先日のブログエントリに記載したコマンドを、自分で実行するのを忘れていたとは。
さらに検証してみると、TRAC_ADMIN
でなかったのにAdmin
メニューが選択できたのは、自分がBLOG_ADMIN
だったからでした。
あれ?と思ったら、まずは設定から見なおしてみると十中八九なんか見つかります。
それはそうと、SharingButtonsPluginを導入してみました。
Wiki
にはボタンが設置されたことを確認しましたが、Blog
はどうやら外部プラグインを使っているため非対応なのか、表示されません。
暇があったら、様々なプラグインにも対応できるようにこれを改造してみてもいいかもしれませんね。
nginxとuwsgiを使ってTracをホストしよう
このTrac
をセットアップするのに多くの時間を費やし、文献を読みあさったのでここに手順やハマりどころをまとめておきます。
そこらの文献というのはなぜかコマンドをどの権限やパスで実行するか明記していないケースがあるので、この記事ではコマンドの説明をするときはbash
っぽくプロンプトの部分から記述します。
- なんかサーバを用意します(当サーバはAmazon EC2上のUbuntu 12.04.2)
以降、ホスト名はreimu
と表します(このホストがreimu.x86-64.jpだから)
- 必要なものをパッケージマネージャなり公式サイトなりから引っ張ってきます。
わたしはaptを使って手を抜きました。依存環境などもまるまる降ってくるし、アップデートの適用もシステムと一緒にできるという恩恵にあずかれます。
[email protected] ~:# apt-get install nginx uwsgi uwsgi-plugin-python trac trac-git
trac-git
はTrac
でgit
使いたいから入れておいたもので、必須ではありません。
で、uwsgi
って結局なんなん: Uwsgi?
- わたしはWebサイトごとにユーザを作るスタイルを採用しているので、
Trac
用にユーザを作っちゃいます。[email protected] ~:# adduser -G www-data trac
nginx
が走るグループは、環境によってはwww-data
ではないかもしれません(httpd
とか)
ユーザ分けとかどうでもいい場合はwww-data
さんが参照できるディレクトリを用意するだけで大丈夫です。
Trac
のプロジェクトが入るディレクトリを適当に作り、Trac
に付属しているTrac-admin?コマンドでそのディレクトリをTrac
化します。
これは通常ユーザ(この記事の例ではtrac
,Trac
用のユーザを作らなかった場合はwww-data
)で行います。[email protected] ~:$ mkdir your_trac_project [email protected] ~:$ trac-admin ~/your_trac_project initenv
initenv
を行っているときに、プロジェクトの名称とデータベースファイルのパスを決められます。
これがTrac
のタイトルとして反映されます。たとえばこのTrac
なら真剣な悪ふざけになっています。 どうやらUTF-8なら2バイト文字でもいいみたいです。
- このへんで
Trac
の管理者アカウントを登録しておきましょう。[email protected] ~:$ trac-admin ~/your_trac_project permission add foo TRAC_ADMIN
これで、ユーザfoo
が管理者になりましたので、foo
としてhttp-auth-basic
(以下Basic認証と記述)でログインできるように設定します(後述)。
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に関する設定が入っています。
htpasswd
を使って、Basic認証に使うアカウントを生成します。
Apacheを入れていないUbuntuではそんなコマンドないかもしれないですが、apache-utils
をインストールすればOKです(記事は省略)[email protected] ~:$ htpasswd -c /path/to/your/.htpasswd foo [email protected] ~:$ chgrp www-data /path/to/your/.htpasswd [email protected] ~:$ chmod 750 /path/to/your/.htpasswd
これによってユーザfoo
が含まれる.htpasswd
が生成されたので、このユーザでログインすることでTrac
のWebインタフェースからの管理ができるようになりました。
個人的にはここでroot
以外が.htpasswd
を読めるのがきもい。まあしょうがない。
- 上で書いたconfigをenableします。
[email protected] ~:# ln -s /etc/nginx/sites-available/trac /etc/nginx/sites-enabled/trac [email protected] ~:# ln -s /etc/uwsgi/apps-available/trac.xml /etc/uwsgi/apps-enabled/trac.xml
uwsgi
とnginx
をrestart
して完成。[email protected] ~:# service uwsgi restart [email protected] ~:# service nginx restart
ああそういえば:
エラーが発生したときは、結構な確率でパーミッションがおかしいです。
とくにTrac
を運用するにあたってwww-data
が読み書きできなくてはいけないファイルは、
your_trac_project/conf/trac.ini
your_trac_project/db/trac.db
が大事です。これらのファイルについて
www-data
がrとwの権限を持っているかチェックしましょう。
それからハマりどころとして、
uwsgi
の設定にてPythonのプラグインを使うことを明記しないとちゃんと動かなかったのでメモ。
ざっとこんなところかしら。なんか抜けがある気がするので暇な時に検証します。