Helix Coreサーバ管理者ガイド: 基本 (2019.1)

コードドロップのためにリモートディポを使用する

コードドロップを実現するには、2つの組織間に役割を持たせる必要があります。つまり、コードドロップを受領するサイトと、コードドロップを提供するサイトです。多くの場合、次の点が設定されていなければなりません。

  • コードドロップを受領するサイトのHelixサーバ管理者は、コードドロップを提供するサイトを参照するHelixサーバのリモートディポを、自分のサイト内に構築しなければなりません。

    これについては「リモートディポを定義する」で説明されています。

  • コードドロップを提供するサイトのHelixサーバ管理者は、受領側のサイトにあるリモートディポから、自分のサイトのHelixサーバへのアクセスを許可するようHelixサーバの環境設定すべきです。

    これについては「リモートディポへのアクセスを制限する」で説明されています。

  • 受領サイトの構成管理者または統合管理者は、その管理下において、リモートディポからローカルディポへファイルを反映しなければなりません。

    これについては「コードドロップを受領する」で説明されています。

リモートディポを定義する

新しいリモートディポを定義するには、以下を実行します。

  1. p4 depot depotnameでディポを作成します。
  2. Type:remoteに設定します。
  3. Address:フィールドにリモートサーバの名前と接続待ちのポート番号を設定することによって、ローカルのHelixサーバからリモートのHelixサーバに接続できるようにします。

    リモートサーバのホストとポートをAddress:フィールドに設定する書式は、P4PORTを設定するのと同じ書式です。

  4. リモートサーバの希望のネームスペースの箇所へMap:フィールドをマッピングするように設定します。

    リモートディポの場合は、リモートディポのネームスペースに関連するサブディレクトリがマッピング先になります。例えば//depot/outbound/...と指定すると、depotリモートサーバでホストされているoutboundというディポのサブディレクトリにマッピングされます。

    Map:フィールドには、このサブディレクトリを指す、ディポシンタックスで指定された単一行を指定する必要があります。この行の最後には、「...」というワイルドカードを指定する必要があります。

    クライアントビューとマッピングについてよく知らない場合は、『Helix Coreサーバユーザーガイド』を参照してください。Perforceのマッピング機能に関する一般的な情報が記載されています。

  5. Suffix:フィールドはリモートディポには適用されないため、無視してください。

ローカルサイト内のユーザがリモートディポ内のファイルにアクセスできるようにするには、リモートサーバの管理者が、目的のディポおよびMap:フィールドで指定されたディポ内のサブディレクトリに対するreadアクセス権を、ユーザremoteに対して設定する必要があります。

リモートディポを定義する

リサはあるプロジェクトに取り組んでおり、サードパーティ開発会社からのライブラリセットを、自分のサイトの開発者に対して提供しようとしています。そのサードパーティ開発会社はホストpineHelixサーバを設置していて、ポート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のライセンスを消費しません。

Note

リリース2010.2のHelixサーバは、古いHelixサーバremoteとして認証し、リリース2010.2以降のHelixサーバremote(サービスユーザが設定されていない場合)、またはサービスユーザ(設定されている場合)として認証します。

デフォルトでは、Helixサーバ上のすべてのファイルがリモートからアクセス可能です。特定のサーバに対するリモートアクセスを制限または禁止するには、p4 protectを使用して、そのサーバ上でremoteというユーザ(またはリモートサイトのサービスユーザ)に対する権限を設定します。Perforceは、p4 protectのテーブルに次のようなパーミッション行を追加することによって、すべてのファイルおよびすべてのディポについて、ユーザremoteのアクセスを拒否することを推奨します。

list user remote * -//...

リモートディポを使用するにはreadアクセス権が必要になるため、remoteユーザ(またはサービスユーザ)のwriteアクセス権またはsuperアクセス権を削除する必要はありません。仮想ユーザのリモートには、プロテクションテーブルでアクセス権が明示的に付与されない限り、何に対してもアクセス権がないことに注意してください。

Note

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フラグを指定して、oakp4dプロセスを開始するか、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サーバ環境の間で提供資料やコードドロップのやりとりをするには以下を実行します。

  1. pine:1818で作業する開発者は、外部提供するためのコードの内容を書き終えます。
  2. pine:1818のビルド管理者またはリリース管理者は、コードドロップの外部提供を意図したpine:1818上の領域に、提供するコードをブランチします。この例では、リリースされるコードは//depot/outbound/...にブランチされます。.
  3. oak:1234Helixサーバ管理者は、//from-pineサーバ上にoakという名前のリモートディポを構築します。このリモートディポのMap:フィールドでは、oakサーバにおいてpine:1818//depot/outbound配下を参照するための指定を行います。
  4. リリースが使用可能になったことを知らせる通知を受信したoak:1234のビルド管理者またはリリース管理者は、//from-pine/... リモートディポ内のファイルをローカルディポの適切な領域(//depot/codedrops/pineなど)に反映して、コードドロップを実行します。
  5. oak:1234の開発者は、こうしてローカルの//depot/codedrops/pine配下に格納されたpineのコードを使用できるようになります。pineのコードに対してパッチが必要であるならば、oakの開発者は//depot/codedrops/pine配下にそのようなパッチを作成することができます。pineグループは、引き続きそのコードを管理します。