p4 server

Create, modify, or delete a Helix Server specification.

Syntax

p4 [g-opts] server serverID
p4 [g-opts] server -g
p4 [g-opts] server -d serverID
p4 [g-opts] server -o [-l] serverID
p4 [g-opts] server -i [-c edge-server|commit-server]
p4 [g-opts] server -c edge-server|commit-server serverID

Syntax conventions

Description

A server specification describes the high-level configuration and intended usage of a Helix Server. For installations with only one Helix Server, the server specification is optional.

The p4 server command puts the server spec into a temporary file and invokes the editor configured by the P4EDITOR variable. Saving the file creates or saves changes to the server specification.

An operator type user cannot execute this command. (The three user types are explained in the description of p4 user.)

Filtering

The ClientDataFilter, RevisionDataFilter, and ArchiveDataFilter fields are for replicated environments where you filter out unnecessary metadata. For instance, a build server does not need to replicate the have listClosed An internal list indicates which files and revisions the client workspace has sync'd from the depot. See 'p4 have' in Helix Core Command-Line (P4) Reference. for every open client workspace on the master server. See "Filtering metadata during replication or edge-to-edge chaining" in Helix Core Server Administrator Guide.

Warning

You must reseed the server if you change the RevisionDataFilter filter.

Tip

(2019.1 and later) For a convenient way to adjust the configuration, see the DistributedConfig: field.

Form Fields

Field Name Type Description

ServerID:

Read-only

A unique identifier for this server. This must match the contents of the server’s server.id file as defined by the p4 serverid command.

Important

To avoid configuration problems, the value of serverID should always match the value of P4NAME if both are set. We recommend setting serverID, but support P4NAME for backward compatibility.

Type:

Writable

Server executable type. One of the following:

Type Notes
server declares a server instance
proxy declares a P4P instance
broker declares a P4Broker instance
connector declares a git-connector instance

Each type can offer one or more services.

Services:

Writable

Services provided by a specific server type. For information on these services, see "Deployment architecture" in the Helix Core Server Administrator Guide.

To assign a service to a server, the administrator uses the Services: field that appears with the p4 server command:

Services for server type server
Service Description Notes

standard

standard Helix Core Server

The server that supports directly-connected clients in a single-server environment. (This is the default and does not require explicit assignment in p4 server form.)
replica read-only replica server

  • Maintains copies of target server metadata and file content.

  • Services commands that read metadata

  • Rejects commands that would update metadata.

  • Use with a broker. See Using P4Broker to redirect read-only commands)

  • Enables Offline Checkpoints to prevent target server downtime for checkpoint or backup.

  • Can be used as a warm stand-by server for disaster recovery

See Configuring a read-only replica in Helix Core Server Administrator Guide.
forwarding-replica replica that forwards update commands
commit-server central server in a multi-server installation
  • A multi-server Helix service consists of a combination of a commit server and one or more edge servers.
  • A commit server stores the canonical archives and permanent metadata.
  • Similar to a Perforce master server, but might not contain all workspace information.

(See Commit-edge in Helix Core Server Administrator Guide.)
edge-server node in a multi-server installation
  • Performance can improve if clients connect to a regional edge server that is geographically closer than the remote commit server. (See Commit-edge in Helix Core Server Administrator Guide.)
  • Geographically separated edge servers can form a chain that ultimately arrives at the commit server.

  • Maintains a copy of commit server metadata, file content as controlled by the lbr.replication setting of the edge server, and local metadata for edge workspace "work-in-progress" data. (See the Knowledge Base article, "Edge Servers", especially the section on "p4 submit".)
build-server replica that supports builder server (or build farm) integration

In addition to supporting read-only commands, allows the p4 client and p4 sync commands to be used to create clients and sync files on the build server.

  • Supports read-only commands
  • Also supports the p4 client and p4 sync commands to create clients and sync files on the build server. See Build server.
standby read-only replica server that uses journalcopy

Same as a read-only replica except:

forwarding-standby

 

forwarding-replica that uses journalcopy

 

Same as the fowarding-replica except:

local

 

personal server in the DVCS environment

See Using Helix Core Server for Distributed Versioning.

 
P4AUTH server that provides central authentication A federated architecture of independent servers can share a single server for authentication. See Centralized authorization server (P4AUTH).
P4CHANGE server that provides central change numbers A federated architecture of independent servers can share a single server for changelist numbers. See Centralized changelist server (P4CHANGE)
distribution-server content distribution server Server for distribution of select content pushed from a source Helix Core Server. See Distribution Server in Helix Core Server Administrator Guide.
Services for server type proxy
Service Description Notes

proxy

Helix Core Proxy

Server spec required when a proxy connects to the Helix Core Server that is running with security level 6. See Helix Proxy.
Services for server type broker
Service Description Notes

broker

Helix Core Broker

Server spec required when a broker connects to the Helix Core Server that is running with security level 6. See Helix Broker.
Services for server type connector
Service Description Notes

git-connector

Helix Core Git Connector intermediary server for Git to Helix Core

Mirrors, caches, or replicates Git repositories. See Working with Git.
Tip

For additional details, see:

Options: Writable

  • mandatory: A standby or forwarding-standby server that persists journalcopy'ed metadata before that metadata is replicated to other replicas. A standby or forwarding-standby server with this option set can be used for failover whether or not the server from which it is journalcopy'ing is available at the time of the failover.

  • nomandatory: (default) Replication to other replicas can occur before the metadata has been persisted by this standby or forwarding-standby server. Failover can occur to this standby or forwarding-standby server only if the server from which it is journalcopy'ing is available at the time of the failover.

This field is relevant to standby and forwarding-standby servers and is ignored by other types of servers.
ReplicatingFrom: Writable

Server ID of the server from which this server is replicating or journalcopy'ing. This field is required when the server is a standby or forwarding-standby server and the mandatory option is set for either.

Note

If you want a forwarding replica to offload read-only commands from an edge server, set this field in the forwarding replica's server spec to the server ID of the edge server.

Name:

Writable

The P4NAME associated with this server.

You can leave this blank or you can set it to the same value as the serverid.

Address:

Writable

The P4PORT used by this server.

Commit and edge servers require this field if you want to use p4 reload in this way:

p4 reload -c client-name -p serverID

ExternalAddress:

Writable

  • This field contains the external address the commit server uses to connect to the edge server. Set to the P4PORT used during the commit-edge setup to create the service user login ticket from the commit server to the edge server. If the edge server uses ssl, the port must include the ssl prefix.

  • This field is required for parallel submit in a multi-server environment.
    For example: tokyo-edge.your-company.com:1666
  • Prior to 2019.2, for a Git Connector server, this optional field could contain a list of repos to be updated, with a space before each repo name. Beginning in 2019.2, UpdateCachedRepos is the field to use for this purpose.

UpdateCachedRepos:

Writable

Beginning in 2019.2, this optional field can contain a list of repos to be updated, with each repo name on a separate line. See the Upgrading Git Connector and Configuring Git Connector to Poll Repos topics in Working with Git in Helix Core Server Administrator Guide.

Description:

Writable

An optional description for this server.

User:

Writable

The service user name used by the server. For additional information about the use of this field, see the section on "Service users" in Helix Core Server Administrator Guide.

AllowedAddresses:

Writable A list of addresses that are valid this server. At security level 6, this field is used to associate intermediary servers with specified service users. Connections through intermediary servers without matching server specs will be blocked.

ClientDataFilter:

Writable

For a replica server, this optional field can contain one or more patterns describing how active client workspace metadata is to be filtered. Active client workspace metadata includes have lists, working records, and pending resolves.

To include active client metadata, use the syntax:

//client-pattern/...

To exclude active client metadata, use the syntax:

-//client-pattern/...

All patterns are specified in client syntax.

RevisionDataFilter:

Writable

For a replica server, this optional field can contain one or more patterns describing how submitted revision metadata is to be filtered. Submitted revision metadata includes revision records, integration records, label contents, and the files listed in submitted changelists.

To include submitted revision depot metadata, use the syntax:

//depot/pattern/...

To exclude submitted revision depot metadata, use the syntax:

-//depot/pattern/...

All patterns are specified in depot syntax.

ArchiveDataFilter:

Writable

For a replica server, this optional field can contain one or more patterns describing the policy for automatically scheduling the replication of file content. If this field is present, only those files described by the pattern are automatically transferred to the replica. Other files are not transferred until they are referenced by a replica command that needs the file content.

Files specified in the ArchiveDataFilter: field are transferred to the replica regardless of whether any users of the replica have made requests for their content.

To automatically transfer files on submit, use the syntax:

//depot/pattern/...

To exclude files from automatic transfer, use the syntax:

-//depot/pattern/...

All patterns are specified in depot syntax.

If you want to include most depot paths, use this pattern:

//...
-//depot/projA/...
-//depot/projB/...

which begins by including all paths.

If you want to include only a few specific depot paths, use this pattern:

//depot/projA/...
//depot/projB/...

which implicitly excludes all paths that are not explicitly included.

Warning

Changes to ArchiveDataFilter are ignored unless the replica or edge serve is restarted.

DistributedConfig:

Writable

For all server types, this field shows a line for each configurable that is set to a non-default value. In this field, the admin can edit certain values, add a new line to set certain configurables to a non-default value, or delete a line to reset certain configurables to their default value.

Note that:

  • the commit server's any# values, for example, any#monitor=30, apply throughout the multi-server environment, unless overridden locally
  • this server's local values, for example, monitor=40, override the any# values

When p4 server is invoked with the -c flag, the configuration values are populated with currently configured values, recommended default values if unset, or unset for unset values with no default.

If this field is present when invoked with -c, the configuration commands in this field are run on the current server using the scope of the server specified in the serverID field.

For an edge or commit server, this optional field is displayed only when you use the -c flag.

Tip

If there is a line under a field, indent that line. For example,

Description:
    Created by maria

Options

-c edge-server | commit-server

Allow the user to set, change or display configuration values used to set up the multi-server environment on an edge or commit server by using the DistributedConfig: field.

Configuration fields are initially populated with:

  • the configured values if set
  • default values if unset, or
  • unset for unset values with no default

After exiting from the form, any configuration commands in the DistributedConfig: field will be run on the current server for the scope of the serverID.

The commands only apply to the serverID server, and so the server# prefix is not allowed in these commands. The only supported services are edge-server and commit-server. The service dictates which configuration values are used to initially populate the form the first time that the server command is run.

-d serverID

Delete the named server specification.

-g

Generate a new serverID as part of the form.

-i

Read a server specification from standard input.

You can combine this option with the -c option to generate and run configuration variables used to set up an edge or commit server. When used with -c, only the fields explicitly set in standard input from the DistributedConfig: field will be configured.

-l

Deprecated because of the functionality of the DistributedConfig: field.

-o

Write the named server specification to standard output.

g-opts

See Global options.

Usage Notes

Can File Arguments Use Revision Specifier? Can File Arguments Use Revision Range? Minimal Access Level Required

N/A

N/A

  • Only standard users with the super access level can add or modify server specs because only super users have access to p4 server serverID and the -i, -g, and -d options.

  • Standard users can view server specs by using the -o serverID option.

  • Operator users and service users have no access to the p4 server command.

Related Commands

Get or set the unique ID associated with a Helix Server.

p4 serverid

To list all known servers

p4 servers