Using remote depots for code drops

Performing a code drop requires coordination between two organizations, namely the site receiving the code drop and the site providing the code drop. In most cases, the following things must be configured:

• The Helix Server administrator at the site receiving the code drop must create a remote depot on his or her Helix Server that points to the site providing the code drop.

  This is described in Defining remote depots.

• The Helix Server administrator at the site providing the code drop should configure his or her Helix Server to allow the recipient site’s remote depot to access the providing site’s Helix Server.

  This is described in Restricting access to remote depots.

• The configuration manager or integration manager at the receiving site must integrate the desired files from the remote depot into a local depot under his or her control.

  This is described in Receiving a code drop.

Defining remote depots

To define a new remote depot:

1. Create the depot with p4 depot depotname.
2. Set the Type: to remote.

3. Direct your Helix Server to contact the remote Helix Server by providing the remote server’s name and listening port in the Address: field.

   A remote server’s host and port are specified in the Address: field just as though it were a P4PORT setting.

4. Set the Map: field to map into the desired portion of the remote server’s namespace.

   For remote depots, the mapping contains a subdirectory relative to the remote depot namespace. For example, //depot/outbound/... maps to the outbound subdirectory of the depot named depot hosted on the remote server.

   The Map: field must contain a single line pointing to this subdirectory, specified in depot syntax, and containing the "..." wildcard on its right side.

   If you are unfamiliar with client views and mappings, see "Configure workspace views" in the Helix Core Command-Line (P4) Guide.

5. The Suffix: field does not apply to remote depots; ignore this field.

In order for anyone on your site to access files in the remote depot, the administrator of the remote server must grant read access to user remote to the depots and subdirectories within the depots specified in the Map: field.

Depot:       from-pine
Type:        remote
Address:     pine:1818
Map:         //depot/outbound/...

Restricting access to remote depots

Remote depots are accessed either by a virtual user named remote, or (if configured) by the service user of the accessing server’s p4d. Service users (including the virtual remote user) do not consume Perforce licenses.

By default, all files on a Helix Server can be accessed remotely. To limit or eliminate remote access to a particular server, use p4 protect to set permissions for user remote (or the remote site’s service user) on that server. Perforce recommends that administrators deny access to user remote across all files and all depots by adding the following permission line in the p4 protect table:

list user remote * -//...

Because remote depots can only be used for read access, it is not necessary to remove write or super access to user remote (or the service user). Keep in mind that the virtual user remote does not have access to anything unless that access is granted explicitly in the protection table.

Example security configuration

Using the two organizations described in Receiving a code drop, a basic set of security considerations for each site would include:

On the local (oak) site:

• Deny access to //from-pine to all users. Developers at the oak site have no need to access files on the pine server by means of the remote depot mechanism.

• Grant read access to //from-pine to your integration or build managers. The only user at the oak site who requires access the //from-pine remote depot is the user (in this example, adm) who performs the integration from the remote depot to the local depot.

  The oak administrator adds the following lines to the p4 protect table:

  list user * * -//from-pine/...
  read user adm * //from-pine/...

On the remote (pine) site, access to code residing on pine is entirely the responsibility of the pine server’s administrator. At a minimum, this administrator should:

• Preemptively deny access to user remote across all depots from all IP addresses:

  list user remote * -//...

  Adding these lines to the p4 protect table is sound practice for any Helix Server installation, whether its administrator intends to use remote depots or not.

• If both servers are at Release 2010.2 or higher: contact the oak site’s administrator and obtain the name of the oak site’s service user.

  In this example, the oak site’s service user is service-oak. When a user of the oak server accesses a remote depot hosted on pine, the oak server will authenticate with the pine server as a user named service-oak.

  As administrator of the pine site, you must:

  • Create a service user on your site named service-oak. (see "service users" under "Types of users" in the p4 user topic of Helix Core Command-Line (P4) Reference). This user’s name must match the name of the receiving site’s service user.
  • Assign this user a strong password.

  • Inform the oak administrator of this password.

    The administrator of the oak site must:

  • Use the password set by the pine administrator to obtain a ticket valid for pine for the user service-oak (that is, run p4 login service-oak against the pine server).
  • Place the ticket somewhere where the oak server’s p4d process can access it. (For example, the .p4tickets file in the server’s root directory, with P4TICKETS set to point to the location of the ticket file.)
  • Configure oak to work with the pine service user, either by starting oak's p4d process with the -u service-oak flag, or configure the server with p4 configure set serviceUser=service-oak.)
  • Grant read access to user remote (or the oak site’s service user) to only those areas of the pine server into which code drops are to be placed. Further restrict access to requests originating from the IP address of the Helix Server that is authorized to receive the code drop.

  In this example, outgoing code drops reside in //depot/outbound/... on the pine server. If oak's IP address is 192.168.41.2, the pine site’s protections table looks like:

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

• If both sites are at Release 2010.2 or higher, and the oak server is configured to use service-oak as its service user, the pine site’s protections table looks like:

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

  Only servers at IP address 192.168.41.2 that have valid tickets for the pine site’s service-oak user, are permitted to access the pine server through remote depots, and only //depot/outbound/... is accessible.

Receiving a code drop

To perform a handoff or code drop between two Helix Server installations:

1. Developers on pine:1818 complete work on a body of code for delivery.
2. The build or release manager on pine:1818 branches the deliverable code into an area of pine:1818 intended for outbound code drops. In this example, the released code is branched to //depot/outbound/....
3. A Helix Server administrator at oak:1234 configures a remote depot called //from-pine on the oak server. This remote depot contains a Map: field that directs the oak server to the //depot/outbound area of pine:1818.
4. Upon notification of the release’s availability, a build or release manager at oak:1234 performs the code drop by integrating files in the //from-pine/... remote depot into a suitable area of the local depot, such as //depot/codedrops/pine.

5. Developers at oak:1234 can now use the pine organization’s code, now hosted locally under //depot/codedrops/pine. Should patches be required to pine's code, oak developers can make such patches under //depot/codedrops/pine. The pine group retains control over its code.