コードドロップのためにリモートディポを使用する
コードドロップを実現するには、2つの組織間に役割を持たせる必要があります。つまり、コードドロップを受領するサイトと、コードドロップを提供するサイトです。 多くの場合、次の点が設定されていなければなりません。
-
コードドロップを受領するサイトのHelixサーバ管理者は、コードドロップを提供するサイトを参照するHelixサーバのリモートディポを、自分のサイト内に構築しなければなりません。
これについては「リモートディポを定義する」で説明されています。
-
コードドロップを提供するサイトのHelixサーバ管理者は、受領側のサイトにあるリモートディポから、自分のサイトのHelixサーバへのアクセスを許可するようHelixサーバの環境設定すべきです。
これについては「リモートディポへのアクセスを制限する」で説明されています。
-
受領サイトの構成管理者または統合管理者は、その管理下において、リモートディポからローカルディポへファイルを反映しなければなりません。
これについては「コードドロップを受領する」で説明されています。
リモートディポを定義する
新しいリモートディポを定義するには、以下を実行します。
p4 depot
でディポを作成します。depotname
Type:
をremote
に設定します。-
Address:
フィールドにリモートサーバの名前と接続待ちのポート番号を設定することによって、ローカルのHelixサーバからリモートのHelixサーバに接続できるようにします。リモートサーバのホストとポートを
Address:
フィールドに設定する書式は、P4PORT
を設定するのと同じ書式です。 -
リモートサーバの希望のネームスペースの箇所へ
Map:
フィールドをマッピングするように設定します。リモートディポの場合は、リモートディポのネームスペースに関連するサブディレクトリがマッピング先になります。 例えば
//depot/outbound/...
と指定すると、depot
リモートサーバでホストされているoutbound
というディポのサブディレクトリにマッピングされます。Map:
フィールドには、このサブディレクトリを指す、ディポシンタックスで指定された単一行を指定する必要があります。この行の最後には、「...
」というワイルドカードを指定する必要があります。クライアントビューとマッピングについてあまり詳しくない場合は、『Helix Coreサーバユーザガイド』の「ワークスペースビューを構成する」を参照してください。
Suffix:
フィールドはリモートディポには適用されないため、無視してください。
ローカルサイト内のユーザがリモートディポ内のファイルにアクセスできるようにするには、リモートサーバの管理者が、目的のディポおよびMap:
フィールドで指定されたディポ内のサブディレクトリに対するread
アクセス権を、ユーザremote
に対して設定する必要があります。
例 リモートディポを定義する
リサはあるプロジェクトに取り組んでおり、サードパーティ開発会社からのライブラリセットを、自分のサイトの開発者に対して提供しようとしています。 そのサードパーティ開発会社はホストpine
にHelixサーバを設置していて、ポート1818
で接続待ちをしています。 社内のポリシーを使用して、depot
というディポ内のoutbound
というサブディレクトリに、ライブラリのリリースを配置します。
リサは新しいディポを作成し、そのディポ内でコードドロップにアクセスします。リサはこのディポにfrom-pine
という名前を指定し、p4
depot from-pine
と入力して、次のようにフォームを入力します。
Depot: from-pine Type: remote Address: pine:1818 Map: //depot/outbound/...
これでリサのHelixサーバにfrom-pine
というリモートディポが作成されます。このディポ(//from-pine
)は、サブディレクトリdepot
下にあるサードパーティのoutbound
のネームスペースをマッピングします。
リモートディポへのアクセスを制限する
リモートディポは、remote
という仮想ユーザか、(設定されていれば)アクセス元サーバのp4d
のサービスユーザによってアクセスされます。 サービスユーザ(仮想ユーザremote
を含む)はPerforceのライセンスを消費しません。
リリース2010.2のHelixサーバは、古いHelixサーバをremote
として認証し、リリース2010.2以降のHelixサーバをremote
(サービスユーザが設定されていない場合)、またはサービスユーザ(設定されている場合)として認証します。
デフォルトでは、Helixサーバ上のすべてのファイルがリモートからアクセス可能です。 特定のサーバに対するリモートアクセスを制限または禁止するには、p4 protect
を使用して、そのサーバ上でremote
というユーザ(またはリモートサイトのサービスユーザ)に対する権限を設定します。 Perforceは、p4 protect
のテーブルに次のようなパーミッション行を追加することによって、すべてのファイルおよびすべてのディポについて、ユーザremote
のアクセスを拒否することを推奨します。
list user remote * -//...
リモートディポを使用するにはread
アクセス権が必要になるため、remote
ユーザ(またはサービスユーザ)のwrite
アクセス権またはsuper
アクセス権を削除する必要はありません。 仮想ユーザのリモートには、プロテクションテーブルでアクセス権が明示的に付与されない限り、何に対してもアクセス権がないことに注意してください。
Helixサーバリリース2010.2時点で、ユーザremote
のアクセスを拒否することは慣例として推奨されます。 パートナーサイトのサーバがサービスユーザを使用するように設定されている場合、それらのサービスユーザを使用して、サーバのどの部分をコードドロップで利用できるかをさらに制限することができます。
セキュリティ構成の例
コードドロップを受領するで説明された2つの組織を例に、それぞれの組織におけるセキュリティ構成の基本を以下に示します。
ローカルサイト(oak
)で、以下の操作を行います。
- すべてのユーザに対して、
//from-pine
へのアクセスを拒否します。oak
サイトで作業を行う開発者は、リモートディポを使用してpine
サーバ上のファイルにアクセスする必要はありません。 -
統合管理者またはビルド管理者に対して、
//from-pine
へのread
アクセス権を設定します。oak
サイトにおいてリモートディポ//from-pine
へのアクセスを要求する唯一のユーザは、リモートディポからローカルディポへの反映を実行するユーザ(この例ではadm
)です。oak
の管理者は、p4 protect
のテーブルに次の行を追加します。list user * * -//from-pine/... read user adm * //from-pine/...
リモートサイト(pine
)では、pine
上にあるコードへのアクセスは、完全にpine
のサーバ管理者の管理下にあります。 少なくともこの管理者は、次のことをする必要があります。
-
あらかじめ、ユーザ
remote
に対して、すべてのIPアドレスからのすべてのディポに対するアクセスを拒否します。list user remote * -//...
この行を
p4 protect
テーブルに追加することは、システム管理者がリモートディポを使用するかどうかとは関係なく、あらゆるHelixサーバ環境において手堅い運用方法です。 -
両方のサーバがリリース2010.2以降である場合、
oak
サイトの管理者に連絡して、oak
サイトのサービスユーザの名前を確認してください。この例では、
oak
サイトのサービスユーザはservice-oak
です。oak
サーバのユーザがpine
というホストにあるリモートディポにアクセスすると、oak
サーバはpine
サーバをservice-oak
という名前のユーザとして認証します。pine
サイトの管理者として、以下のことを行う必要があります。- サイトに
service-oak
というサービスユーザを作成します。 (「サービスユーザ」を参照)。 このユーザ名は受け取り側サイトのサービスユーザ名と一致する必要があります。 - このユーザに強力なパスワードを割り当てます。
-
このパスワードを
oak
の管理者に連絡します。oak
サイトの管理者は以下のことを行う必要があります。 - pineの管理者によって設定されたパスワードを使用して、ユーザ
service-oak
用にpine
の有効なチケットを取得します(つまり、pine
サーバに対してp4 login service-oak
を実行します)。 oak
サーバのp4d
プロセスからアクセス可能な場所にチケットを格納します。 (例えば、P4TICKETS
をチケットファイルの位置を示すように設定し、サーバのルートディレクトリ内の.p4tickets
ファイルにチケットを格納します。)oak
を、pine
のサービスユーザが操作できるように構成します。そのためには、-u service-oak
フラグを指定して、oak
のp4d
プロセスを開始するか、p4 configure set serviceUser=service-oak
を使用してサーバを設定します。- コードドロップの格納先となる
pine
サーバの領域に対してのみ、remote
ユーザ(またはoak
サイトのサービスユーザ)のread
アクセス権を許可します。 さらにアクセスを、コードドロップを受領することを認可されたHelixサーバのIPアドレスから発信されたリクエストに制限します。
この例では、
//depot/outbound/...
(pine
サーバ上)にコードドロップが格納されます。oak
のIPアドレスが192.168.41.2
の場合、pine
サイトのプロテクションテーブルは以下のようになります。list user remote * -//... read user remote 192.168.41.2 //depot/outbound/...
- サイトに
-
両方のサイトがリリース2010.2以降であり、
oak
サーバがservice-oak
をサービスユーザとして使用するように設定されている場合、pine
サイトのプロテクションテーブルは以下のようになります。list user remote * -//... list user service-oak * -//... read user service-oak 192.168.41.2 //depot/outbound/...
pine
サイトのservice-oak
ユーザ用の有効なチケットを持つ、IPアドレスが192.168.41.2であるサーバのみ、リモートディポ経由でpine
サーバにアクセスすることができます。アクセスできるのは、//depot/outbound/...
のみです。
コードドロップを受領する
2つのHelixサーバ環境の間で提供資料やコードドロップのやりとりをするには以下を実行します。
pine:1818
で作業する開発者は、外部提供するためのコードの内容を書き終えます。pine:1818
のビルド管理者またはリリース管理者は、コードドロップの外部提供を意図したpine:1818
上の領域に、提供するコードをブランチします。 この例では、リリースされるコードは//depot/outbound/...
にブランチされます。oak:1234
のHelixサーバ管理者は、//from-pine
サーバ上にoak
という名前のリモートディポを構築します。 このリモートディポのMap:
フィールドでは、oak
サーバにおいてpine:1818
の//depot/outbound
配下を参照するための指定を行います。- リリースが使用可能になったことを知らせる通知を受信した
oak:1234
のビルド管理者またはリリース管理者は、//from-pine/...
リモートディポ内のファイルをローカルディポの適切な領域(//depot/codedrops/pine
など)に反映して、コードドロップを実行します。 -
oak:1234
の開発者は、こうしてローカルの//depot/codedrops/pine
配下に格納されたpine
のコードを使用できるようになります。pine
のコードに対してパッチが必要であるならば、oak
の開発者は//depot/codedrops/pine
配下にそのようなパッチを作成することができます。pine
グループは、引き続きそのコードを管理します。