株式会社八角研究所 > グループ演習用に Trac Lightning 2.1 を設定してみる

エンジニア募集中!

独立心旺盛で、新しい技術で新しいWebサービスを作りたいと思っているけれど、ひとりでやることに限界を感じているフリーのエンジニアの方。あなたの期待にこたえられる仲間と環境を、八角研究所なら提供できると思います。社員としてではない関わり方も、あるかもしれません。

2009年04月15日 17:22

グループ演習用に Trac Lightning 2.1 を設定してみる * * * *

by mokada

Tags: 気になる技術をメモりたい Trac

どこだかの研修で Trac を導入しようとしてます。Trac Lightning 2.1 をつかいます。グループ演習なので、グループごとにプロジェクトをひとつ作成して、次のように権限設定したいわけです。

  • 各グループには、リーダーとメンバーがいる
  • リーダーは自分のプロジェクトにたいして多くの権限をもっている(例:マイルストーンの管理)
  • メンバーは自分のプロジェクトにたいしてリーダーほどではないが権限をもっている(例:チケットの登録)
  • リーダーもメンバーも自分のプロジェクトの subversion リポジトリの読み書きができる
  • すべてのリーダーとメンバーは自分の属さないプロジェクトにたいして閲覧のみの権限をもっている。ただし、リポジトリブラウザでファイル内容を閲覧することはできない
  • すべてのリーダーとメンバーは自分の属さないプロジェクトの subversion リポジトリにアクセスする権限をもたない
  • 研修生の教育にあたるマネージャは、すべてのプロジェクトにたいして閲覧のみの権限をもっている。リポジトリブラウザでファイル内容を閲覧することも、subversion リポジトリに読み込みのみの権限でアクセスすることも可能

Group A と Group B があるとし、Group A のプロジェクトを ProjectA として、図にすると、以下のような感じ。

アクセスポリシー

とりあえずすこし調査した上で思いついた方法をつかって設定してみます。もしかすると根本的に何かが間違っているかもしれないので、あまり参考にしなくていいです。グループやメンバーの人数が増えると非常に面倒になってくる箇所があるので、もっとよい方法があるのかもしれません。あったら教えてほしいであります。

検証用プロジェクトとユーザの準備

以下では、とりあえず検証用に次のようなプロジェクトとユーザを想定してみます。

プロジェクト

  • ProjectA
  • ProjectB

ユーザ

  • leader_a : ProjectA のリーダー
  • leader_b : ProjectB のリーダー
  • member_a : ProjectA のメンバー
  • member_b : ProjectB のメンバー
  • manager : マネージャ(研修生の上司)
  • admin : システムの管理者

まずプロジェクトを作成。

>create-project ProjectA
>create-project ProjectB

次にウェブから admin でログインして、ProjectA に leader_a と member_a、ProjectB に leader_b と member_b を Add external user しておきます。

manager は外部からログイン可能にしたいのですけど、どこのプロジェクトに属しているわけでもないのですが………。こういう場合どうすればいいんだろう。実用上問題なさそうなので、とりあえず ProjectA 上でユーザ作成してみましたが。

あと、

WARNING: [leader_a, member_a, manager] users are not added to the team

みたいのが表示されるのがうざいです………。このユーザたちは ProjectB チームには所属しないのだから、別に are not added でいいのに。警告がでるとか、そんなにイレギュラーなつかいかたしてるのかー。

設定のしかたを考えてみる

まず各プロジェクトの初期状態の権限設定を確認しておきます。ProjectA を例に権限の一覧を表示してみると、次のような感じです。

>trac-admin path-to-ProjectA permission list

User           Action
--------------------------------
admin          CODE_REVIEW_MGR
admin          TRAC_ADMIN
anonymous      BROWSER_VIEW
anonymous      CHANGESET_VIEW
anonymous      DISCUSSION_VIEW
anonymous      FILE_VIEW
anonymous      LOG_VIEW
anonymous      MILESTONE_VIEW
anonymous      REPORT_SQL_VIEW
anonymous      REPORT_VIEW
anonymous      ROADMAP_VIEW
anonymous      SEARCH_VIEW
anonymous      TICKET_VIEW
anonymous      TIMELINE_VIEW
anonymous      WIKI_VIEW
authenticated  CODE_REVIEW_DEV
authenticated  DISCUSSION_APPEND
authenticated  TICKET_CREATE
authenticated  TICKET_EDIT_CC
authenticated  TICKET_MODIFY
authenticated  WIKI_CREATE
authenticated  WIKI_MODIFY
developer      authenticated
guest          developer
leader         CODE_REVIEW_MGR
leader         MILESTONE_CREATE
leader         MILESTONE_MODIFY
leader         TICKET_ADMIN

まず anonymous と authenticated に付与されている権限を見直す必要がありそうです。たとえば Group B のメンバーは、たとえ認証されていたとしても ProjectA で WIKI の編集とかしてほしくないですから、認証済みというだけでユーザに閲覧以上の権限を与える必要はないわけです。ついでに、認証してないユーザというか、アカウントをもたないユーザというのは今回想定しないので、その気になれば誰でも authenticated になることができるわけなので、anonymous と authenticated を区別する必要はなさそうです。

また、他のグループの開発物がソースコードまで見れてしまうとズルする人がでてくるかもしれないので、リポジトリブラウザによるファイル内容の閲覧は、自分のプロジェクトに限ります。ファイル一覧くらいは、見れてもよいかな、ということにしておきます。

developer、guest、leader といったグループですが、今回の目的にはつかえそうにないので、つかいません。

そんなかんじで anonymous & authenticated のもつ閲覧権限をベースに、自分の属するグループに対する権限については、別途ユーザごとに追加していきます。

以上まとめると次のような感じ。

  • authenticated に与える権限は anonymous と同レベルでよい
  • anonymous から FILE_VIEW と CHANGESET_VIEW を奪っておく
  • developer、 guest、 leader はつかわない。念のため権限を奪っておく
  • 自分の属するグループに対する権限は、別途ユーザに追加する

実際に設定してみる

anonymous、authenticated、他グループの権限設定からはじめます。次のようにコマンドを実行して……

>trac-admin path-to-ProjectA permission remove anonymous FILE_VIEW CHANGESET_VIEW
>trac-admin path-to-ProjectA permission remove authenticated *
>trac-admin path-to-ProjectA permission remove leader *
>trac-admin path-to-ProjectA permission remove developer *
>trac-admin path-to-ProjectA permission remove guest *

もういちど list コマンドで権限一覧を確認してみます。

User       Action
--------------------------
admin      CODE_REVIEW_MGR
admin      TRAC_ADMIN
anonymous  BROWSER_VIEW
anonymous  DISCUSSION_VIEW
anonymous  LOG_VIEW
anonymous  MILESTONE_VIEW
anonymous  REPORT_SQL_VIEW
anonymous  REPORT_VIEW
anonymous  ROADMAP_VIEW
anonymous  SEARCH_VIEW
anonymous  TICKET_VIEW
anonymous  TIMELINE_VIEW
anonymous  WIKI_VIEW

次にプロジェクトのリーダーとメンバー、あとマネージャにそれっぽい権限付与を行います。メンバーが複数いると、メンバーの人数分だけコマンド実行が必要になりますが……。なんかいい方法はないものか。

>trac-admin path-to-ProjectA permission add leader_a FILE_VIEW CHANGESET_VIEW TICKET_ADMIN MILESTONE_ADMIN REPORT_ADMIN WIKI_ADMIN
>trac-admin path-to-ProjectA permission add member_a FILE_VIEW CHANGESET_VIEW TICKET_CREATE TICKET_APPEND TICKET_CHGPROP TICKET_MODIFY WIKI_CREATE WIKI_MODIFY WIKI_DELETE
>trac-admin path-to-ProjectA permission add manager FILE_VIEW CHANGESET_VIEW

ともかく、以上は ProjectA にたいする設定ですが、同じことを、ProjectB と leader_b、member_b についても行います。

ちゃんと設定できたか適当に確認してみる

ProjectA に leader_a でログイン

  • マイルストーンとかコンポーネントの管理ができた
  • リポジトリブラウザでファイルの中身もみれた

ProjectA に member_a でログイン

  • チケットの登録ができた
  • リポジトリブラウザでファイルの中身もみれた
  • マイルストーンとかは閲覧しかできない

ProjectA に leader_b でログイン

  • チケットの登録はできない
  • マイルストーンとかは閲覧しかできない
  • リポジトリブラウザでファイルの中身もみれない
  • 閲覧だけならだいたいできる

うむ、問題なさそう。

Subversion も設定しよう

さて実は、プロジェクトメンバー以外は、リポジトリブラウザではファイルの中身を見ることはできないのですが、Subversion クライアントでリポジトリにアクセスするとあっさりチェックアウトできてしまいます。なので、次に Subversion クライアントからのリポジトリへのアクセスも制限を加えないといけません。

TracLight/projects/svnauthz が Subversion のアクセス権限を詳細に設定するためのファイルです(このファイルをつかうということ自体は TracLight/CollabNetSVN/httpd/conf/httpd.conf で宣言されてます )。これを次のように編集。

[groups]
project_a = leader_a, member_a
project_b = leader_b, member_b


[/]
admin = rw

[ProjectA:/]
@project_a = rw
admin = rw
manager = r
* =

[ProjectB:/]
@project_b = rw
admin = rw
manager = r
* =

これで、自分のプロジェクト以外の Subversion リポジトリへのアクセスはできなくなります。ただし、admin ユーザはすべてのプロジェクトで読み書き可能、manager ユーザはすべてのプロジェクトで閲覧のみ可能としました。

そして、今回はリポジトリブラウザ上では自分のプロジェクトでなくてもファイル一覧までは閲覧可能という変なポリシーなわけですが、ここで設定した Subversion リポジトリへのアクセス制御をリポジトリブラウザによる閲覧にも反映させたければ、trac.ini に次のように(太字部分)エントリを追加すれば実現できます。

[trac]
repository_dir = ...(略)
authz_module_name = ProjectA 
authz_file = svnauthz

この記事の執筆者

いちおう代表 mokada 34歳

この人の会社をみる この人関連のイベントをさがす この人と一緒にはたらく

この記事を読んだ人はこんな記事も読んでいます

コメント

(メールアドレスは公開されません。メールで返答が欲しい場合などに入力してください)

このエントリへのトラックバックURL

トラックバック

モテる会社の作りかた

「モテる」の定義を考えてみた - モテる=たくさんの人に好意を寄せられること ではない モテをテーマに書く以上、定義ははっきりさせねば! ということで、「モテる」ってどういうことなのか、考えてみました。 一般的なモテる人のイメージは、 多くの異性に告白される人 いつも周囲に人が集まる人気者 人をたぶらかすテクニックを身につけた詐欺師まがい といった感じでしょうか。   確かに、どれも、「人から好意を寄せられる」という点では モテている人ですよね。 でも、みんな本当に、そういうモテ方をしたいの...

メンバー紹介

sugimaru

sugimaru

すぎまるです。22時のシンデレラです。

boy

boy

少年です。 18歳以下(嘘)でも立派に社員です。 よろしくおねがいします。

はち子さん

はち子

広報を担当している、はち子です。本当は広報じゃなくて事務デスが、広報って言うほうがかっこいいし! 社内でゆいいつ、...