Trac with Multi SVN Repos

複数の SVN リポジトリを 1 つの Trac で管理する方法です。元ネタは 2009-07-14 に対応された Multiple Repository Support for 0.12 です。multirepos のソースコードは edgewall の sandbox 内に公開されています。インスコ環境は ubuntu です。私は動作環境については、mysql, mod_python を利用していますが、sqlite でも mod_wsgi でも同じように動作すると思います。また、trac と SVN のユーザは一元的に LDAP で管理します。

LDAP のインストールと設定

  1. LDAP のインストール (Ubuntu の場合) 
    sudo apt-get install slapd ldap-utils
sudo dpkg-reconfigure slapd
  2. LDAP の設定とユーザの追加など
    Ubuntu の LDAP ページなど、各 Linux ディストリのページがオヌヌメ

SVN のインストールと設定

  1. SVN のインストール 
    sudo apt-get install subversion libapache2-svn　subversion-tools
  2. SVN リポジトリの作成 (複数個ね) 
    sudo -u www-data svnadmin create /var/svn/repo1
sudo -u www-data svnadmin create /var/svn/repo2
sudo -u www-data svnadmin create /var/svn/repo3
sudo -u www-data svnadmin create /var/svn/repo4
sudo -u www-data svnadmin create /var/svn/repo5
  3. Apache の設定と認証の LDAP 統合 
    sudo a2enmod dav_svn
sudo a2enmod authnz_ldap
cd /etc/apache2/mods-enabled
sudo vi dav_svn.conf
    以下のように編集します 
    <Location /svn>
  DAV svn
  SVNParentPath /var/svn
  SVNListParentPath on
  AuthType Basic
  AuthBasicProvider ldap
  AuthLDAPURL "ldap://localhost:389/ou=people,dc=example,dc=com?uid"
  AuthzLDAPAuthoritative off
  Require valid-user
  # チェックアウトは誰でもできるけど、コミットだけ絞りたいときは Require valid-user を以下のようにする
  # <LimitExcept GET PROPFIND OPTIONS REPORT>
  #   Require valid-user
  # </LimitExcept>
</Location>
  4. Apache の設定を適用する 
    sudo /etc/init.d/apache2 reload
  5. http://localhost/svn/ とかにアクセス可能であれば正常にインストールされている。また subversion client からも同様の URL でチェックアウトできる

Trac のインストールと設定

  1. 必要なパッケージをインストールするなどしておく (Genshiの最新版が必要です) 
    sudo apt-get install libapache2-mod-python python-setuptools darcs unzip wget
sudo easy_install -U "Genshi==dev"
  2. svn より最新のソースコードを取得します (edgewall の svn って遅いですよね・・・) 
    cd /tmp/
svn co http://svn.edgewall.com/repos/trac/sandbox/multirepos
  3. セットアップを実行します 
    sudo python setup.py install
  4. ディレクトリー群の作成 
    sudo mkdir /var/trac /var/trac/htdigest /var/cache/egg
  5. trac-env の作成 
    sudo -u www-data trac-admin /var/trac/sample permission add admin TRAC_ADMIN
  6. trac の設定 
    sudo -u www-data trac-admin /var/trac/sample permission add admin TRAC_ADMIN
    以下の箇所を編集 (hg を使いたい場合はプラグインを入れて repository_type = hg にすればok。あと svn と hg を共有したいときは repo1.type = hg、 repo2.type = svn みたいに個別に設定もできる) 
    [trac]
repository_dir = /var/svn/repo1
repository_type = svn
[repositories]
repo1.dir = /var/svn/repo2
repo2.dir = /var/svn/repo3
repo3.dir = /var/svn/repo4
repo4.dir = /var/svn/repo5
    編集を適用 
    sudo trac-admin /var/trac/sample repository resync "(default)"
sudo trac-admin /var/trac/sample repository resync repo2
sudo trac-admin /var/trac/sample repository resync repo3
sudo trac-admin /var/trac/sample repository resync repo4
sudo trac-admin /var/trac/sample repository resync repo5
  7. commit hook に以下を追加 
    sudo trac-admin /var/trac/sample changeset added "(default)" $REV
sudo trac-admin /var/trac/sample changeset added repo2 $REV
sudo trac-admin /var/trac/sample changeset added repo3 $REV
sudo trac-admin /var/trac/sample changeset added repo4 $REV
sudo trac-admin /var/trac/sample changeset added repo5 $REV
  8. apache の設定 
    sudo vi /etc/apache2/sites-available/trac
    以下の記述を追加 
     <Location "/trac">
   SetHandler mod_python
   PythonHandler trac.web.modpython_frontend
   PythonOption TracEnvParentDir "/var/trac/"
   PythonOption TracUriRoot /trac
   SetEnv PYTHON_EGG_CACHE "/var/cache/egg"
 </Location>
 <LocationMatch "/[^/]+/login">
  AuthType Basic
  AuthBasicProvider ldap
  AuthLDAPURL "ldap://localhost:389/ou=people,dc=example,dc=com?uid"
  AuthzLDAPAuthoritative off
  Require valid-user
 </LocationMatch>
    apache の設定を適用する 
    sudo a2enmod auth_digest
sudo a2ensite trac
sudo /etc/init.d/apache2 reload
  9. http://localhost/trac/sample にアクセスすれば見れますよ。実際の動作させると Browse Source がこんなんになります。リポジトリがいっぱいあって Trac を使ってみたい方はぜひ。
送信者 Surgo

コメント

コメントを投稿

このブログの人気の投稿

Python から Win32 API 経由で印刷する

Win32 API から印刷をするためには、プリンタデバイスコンテキスト (Printer DC) を利用します。具体的には以下のような順序で印刷します。 プリンタドライバからハンドルを取得する プリンタドライバのステータス API から印刷可能か同かを取得する プリンタデバイスコンテキストを作成する ドキュメントを開始する 必要であればフォント等を設定し、印字、改ページ処理などをする ドキュメントを終了する (この時点でプリンタスプールサービスに登録されるようです) プリンタデバイスコンテキストを開放する プリンタドライバのステータス API を監視し、印刷が正常に終了したかを取得する プリンタドライバのハンドルを解放する 太字の手順 (3 - 7) は Win32 API で共通ですが、それ以外の手順 (1, 2, 8, 9) はプリンタドライバに依存しているため、Python から制御したい場合はライブラリを作成する必要があります。これについては、ドライバマニュアルとにらめっこしながら ctypes.windll でがんばります・・・。プリンタ接続、用紙切れ、ミスフィード等のプリントエラーを制御する必要がなければ、書く必要はありません (排他制御が必要なプリンタを除く)。プリンタドライバ毎に変わる部分は置いといて、太字の Win32 API の部分の覚書です。 プリンタデバイスコンテキストを作成する import win32ui import win32con PRINTER_NAME = '[コンパネ -> プリンタとFAX -> に登録しているプリンター名]' PIXELS_PER_INCH = 1440 # 1 インチ毎のピクセル数 INCH_PER_POINT = 72 # 1 インチ毎のポイント数 SCALE_FACTOR = int(PIXELS_PER_INCH / INCH_PER_POINT) #　わざわざ計算せず 20 と指定する場合が多い dc = win32ui.CreateDC() dc.CreatePrinterDC(PRINTER_NAME) # 指定したプリンタ名のプリンタデバイスコンテキストを作成する self.dc.SetMapMode(win32con.MM
続きを読む

Disqus のスケール - Django 編

イメージ
やり直し。2010 年の Django Con のスライド より。 Disqus は多くのサイトに組み込まれているサービスのため、メンテナンスによる停止が難しい。 >>> サーバの構成 エッジロードバランサーに HAProxy: heartbeat 構成。レポートが素敵。 HTTP ゲートウェイキャッシュに Varnish Django サーバとして Apache + mod_wsgi: 30 台ぐらい。メモリリークを防ぐために maximum-requests をセット。Ganglia で監視 キャッシュに memcached: 25 台ぐらい PostgreSQL ロードバランサーに HAProxy/ PgBouncer : コネクションプール用。 PostgreSQL: 10 台ぐらい。 Slony-I で非同期レプリケーションとフェイルオーバー。 ログは syslog-ng: pgFouine でスロークエリーをロギング。 全部でサーバ 100 台ぐらい。他にユーティリティサーバ 15 台、後は HAProxy と heartbeat 用に 20 台ぐらいの構成。Varnish と syslog-ng を除けば Django のデプロイ手順に掲載されているような教科書通り (良い意味です) の構成です。(なんで Apache なの？nginx + gunicorn 速いよって突っ込まれてますね >>> データベースのパーティショニング Django はアプリケーションレベルで簡単に 垂直 パーティショニングができます。アプリケーションごとに DB 分けたり、DB をアプリケーションレベルでルーティングできます ( ドキュメント )。 水平パーティショニング (a.k.a シャーディング) もアプリケーションで 書ける (なるほど・・・)。 >>> キャッシュの削除 Django は QuerySet の結果をキャッシュするけど、それがかなりメモリを消費する。なので SkinnyQuerySet を作った (たぶん Johnny Cache の方が有名？
続きを読む

Disqus のスケール - Django で月間80億PVを処理する

私が把握してる限り Django で一番大きなサービス Disqus のスケール (執筆時点ではサービスダウンしてる)。元ネタは Scaling Django to 8 Billion Page Views です。 月間80億PV 、 45k req/s のほぼすべてのトラフィックを Django で処理しているとのこと。抄訳になるかな。 WAF は 高速開発とパフォーマンス 、 新しい人が入ってすぐに開発に参加できることとカスタマイズ 等のトレードオフがあります。この記事ではそのトレードオフである高速開発とパフォーマンスをどう両立させるか、Disqus のノウハウが紹介されています。 >>> なぜ WAF (Web Application Framework) は遅いのか 最初に思い浮かぶのは、アプリケーションに必要ではないボイラープレート ( django.contrib とか?) や不要なコードがあるため。そもそも Django の思想が Python 同様 " バッテリー同梱 (batteries included) " のため、Django は他の Python 製 WAF よりボイラープレートが多いです。Disqus 曰く "実は 言語や WAF は遅さにあまり関係ない " それより " ネットワーク内の他のサービスとの通信 " のオーバーヘッドが原因とのこと。これは一般的によく言われてることですし、大規模になればなるほどそう。Disqus の場合は PostgreSQL, redis, Cassandra , Memcached 等のサービスが使われているそうです。DB へのスロークエリーやネットワークのレイテンシーは Django のようなボイラープレートによるオーバーヘッドを軽く上回ります。この待ち時間を回避する一番メジャーな方法はキャッシュの使用です。Django では キャッシュフレームワーク を使用します。Django でキャッシュを使うのは簡単ですし、バックエンドに Memcached を使うと充分高速化できます。 はい。ここまでは一般的な話です。こっから。 >>> 45k req/seq を処理する キャッシュしたところで
続きを読む