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

コードドロップの送受信を実行するには、コードドロップを渡すサイトとコードドロップを受け取るサイトとの間で調整を行う必要があります。 ほとんどの場合、以下のようなフローになります。

  • コードドロップを受け取るサイト(受信サイト)の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コマンドライン(P4)ガイド』の 「ワークスペースビューを構成する」を参照してください。

  5. 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ユーザを含む)は、 Helix Coreのライセンスを使用しません。

デフォルトでは、 Helixサーバ上のすべてのファイルが リモートからアクセス可能です。特定のサーバに対するリモートアクセスを制限または禁止するには、 p4 protectを使用して、 そのサーバ上でremoteユーザ(またはリモートサイトのサービスユーザ)に対する権限を設定します。 p4 protectテーブルに以下の権限行を追加して、 すべてのファイルとすべてのディポについて、remoteユーザのアクセスを拒否することをお勧めします。 

list user remote * -//...

リモートディポを使用するにはreadアクセス権が必要になるため、 remoteユーザまたはサービスユーザのwriteアクセス権や superアクセス権を削除する必要はありません。プロテクションテーブルでアクセス権が明示的に設定されていない限り、 組み込みのremoteユーザは何にもアクセスできません。remoteユーザに対しては、アクセス権を設定しないことをお勧めします。 パートナーサイトのサーバが サービスユーザを使用するように設定されている場合、 それらのサービスユーザを使用して、サーバのどの部分をコードドロップで利用できるかを さらに制限することができます。

リモートユーザまたはサービスユーザのセキュリティ構成の例

チェンジリストサーバ(P4CHANGE)でコードドロップの送受信を行う場合、リモートユーザまたはサービスユーザに対して制限付きの読み取りアクセス権を付与するケースが考えられます。サービスユーザが設定されている状態でチェンジリストサーバ(P4CHANGE)を使用する場合、サービスユーザを使用して集中チェンジリストサーバにアクセスし、変更番号を取得します。サービスユーザが設定されていない場合は、組み込みの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サーバ環境において 手堅い運用方法です。

  • oakサイトの管理者に連絡し、 oakサイトのサービスユーザの名前を取得します。

    この例では、oakサイトのサービスユーザは service-oakです。oakサーバのユーザがpineという ホストにあるリモートディポにアクセスすると、 oakサーバはpineサーバをservice-oakという名前の ユーザとして認証します。

    リモートユーザまたはサービスユーザに対して制限付きの読み取りアクセス権を付与する

    pineサイトの管理者として、以下のことを行う必要があります。

    1. service-oakというサイト上でサービスユーザを作成します(『Helix Coreコマンドライン(P4)リファレンス』の p4 userトピックの「ユーザのタイプ」の「サービスユーザ」を参照)。 このユーザ名は受け取り側サイトのサービスユーザ名と 一致する必要があります。
    2. このユーザに強力なパスワードを割り当てます。

    3. このパスワードをoakの管理者に連絡します。

      oakサイトの管理者は以下のことを行う必要があります。

    4. pineの管理者によって設定されたパスワードを使用して、 ユーザservice-oak用にpineの有効なチケットを取得します (つまり、pineサーバに対して p4 login service-oakを実行します)。
    5. oakサーバのp4dプロセスから アクセス可能な場所にチケットを格納します。(例えば、 P4TICKETSをチケットファイルの位置を示すように設定し、 サーバのルートディレクトリ内の.p4ticketsファイルに チケットを格納します。)
    6. oakを、pine のサービスユーザが操作できるように構成します。そのためには、 -u service-oakフラグを指定して、oakのp4dプロセスを開始するか、p4 configure set serviceUser=service-oakを使用してサーバを設定します。
    7. コードドロップの格納先となるpineサーバの領域に対してのみ、 remoteユーザ(またはoakサイトのサービスユーザ)の readアクセス権を許可します。 サービスユーザは複製処理で使用されるため、複製処理で必要なアクセス権を検討する必要があります。
    8. アクセス権を、 コードドロップの受信を許可された Helixサーバ のIPアドレスから送信されたリクエストだけに制限します。

    この例では、提供されるコードドロップはpineサーバ上の //depot/outbound/...に格納されます。 oakのIPアドレスが192.168.41.2の場合、 pineサイトのプロテクションテーブルは以下のようになります。

    list user remote * -//...
read user remote 192.168.41.2 //depot/outbound/...

  • 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:1234の Helixサーバ管理者は、 //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グループは、引き続きそのコードを管理します。