Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 Server Administration Documentation | 2025.1

# Remote depots for code drops

Performing a code drop requires coordination between the site receiving the code drop and the site providing the code drop. In most cases:

- The P4 Server administrator at the site receiving the code drop creates a remote depot on that site's P4 Server that points to the site providing the code drop. See Define a remote depot.

- The P4 Server administrator at the site providing the code drop configures that site's P4 Server to allow the recipient site’s remote depot to access the providing site’s P4 Server. See Restrict access to remote depots.

- The configuration manager or integration manager at the receiving site integrates the desired files from the remote depot into a local depot. See Receive a code drop.

## Define a remote depot

To define a new remote depot:

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

3. Direct your P4 Server to contact the remote P4 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 P4 CLI Documentation.

5. The `Suffix` field does not apply to remote depots.

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.

Example: Define a remote depot

Lisa is coordinating a project and wants to provide a set of libraries to her developers from a third-party development shop. The third-party development shop uses a P4 Server on host `pine` that listens on port `1818`. Their policy is to place releases of their libraries on their server’s single depot `depot` under the subdirectory `outbound`.

Lisa creates a new depot from which she can access the code drop; she’ll call this depot `from-pine`; she’d type `p4 depot from-pine` and fill in the form as follows:

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

This creates a remote depot called `from-pine` on Lisa’s P4 Server. This depot (`//from-pine`) maps to the third party’s `depot`'s namespace under its `outbound` subdirectory.

## Restrict access to remote depots

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

Prior to 2025.1, all files on a P4 Server could be accessed remotely by default. With 2025.1 (and later), the remote user is restricted by the rmt.allow.remoteuser configurable.

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. We recommend 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` user or the service user. The built-in user remote does not have access to anything unless that access is granted explicitly in the protection table. Nevertheless, it remains good practice to deny access to user `remote`. If the servers at partner sites are configured to use service users, you can use their service users to further restrict which portions of your server are available for code drops.

We recommend using a service user.

## Example security configuration with remote or service user

For both for code drops and scenarios with a Centralized changelist server (P4CHANGE), there are use cases for Grant limited read access to remote or service user. In the case of a Centralized changelist server (P4CHANGE), if a service user is configured, that service user is used to contact the centralized change server and obtain the change number. If not, the built-in `remote` user is used.

In this example, we use the two organizations described in Receive a code drop. The security considerations for each site 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 P4 Server installation, whether its administrator intends to use remote depots or not.

- 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`.

  #### Grant limited read access to remote or service user

  As administrator of the `pine` site, you must:

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

  3. Inform the `oak` administrator of this password.

     The administrator of the `oak` site must:

  4. 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).
  5. 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.)
  6. 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`.)
  7. 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. Service users are used for replication, so you must consider the access rights that replication requires.
  8. Restrict access to requests originating from the IP address of the P4 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 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 can access the `pine` server through remote depots, and only `//depot/outbound/...` is accessible.

## Receive a code drop

To perform a handoff or code drop between two P4 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 P4 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.

Your search for returned results