Configurables

server.allowpush

server.allowremotelocking

ssl.tls.version.min

ssl.tls.version.max

The default method to use for authenticating new users.

• perforce specifies that the user is to be authenticated using Perforce’s db.user table. This is the default setting.

  If there are no active LDAP configurations, this setting might cause a new user to be authenticated against an AD/LDAP server, using an authentication trigger if such a trigger exists.

• ldap specifies the user be authenticated in against an AD/LDAP server without having to use authentication triggers.

  In addition, if you want new users to be automatically created when they have successfully authenticated against an AD/LDAP server, set the configurable auth.ldap.userautocreate to a non-zero value.

An alphanumeric identifier that must be set for all servers in a distributed configuration if you want to implement single login to the master, which is then valid across all replica instances.

You must also set rpl.forward.login to one for each replica participating in the distributed configuration.

If auth.default.method is set to ldap, a value of 1 for this configurable will cause users to be auto-created when they log in to Perforce and they have been successfully authenticated against an AD/LDAP server using p4 login.

The path to a file that contains one or more PEM-formatted certificates used to verify the certificate presented by the AD/LDAP server when using SSL or TLS and auth.ldap.ssllevel is >=1.

Specifies the name of the LDAP configuration to use for authentication and the order in which it should be used to search for a given user name. The lowest number confers the highest priority.

You may skip numbers. For example:

auth.ldap.order.1=UK_LDAP
auth.ldap.order.2=US_LDAP
auth.ldap.order.5=RU_LDAP

If this configurable has been set, if it specifies an existing LDAP configuration, if LDAP authentication is enabled, and if the Perforce server is restarted, authentication trigger support is disabled.

Specifies the paging limit in bytes for LDAP searches with paged results. Set the configurable to a value less than the LDAP server’s result limit. For example, if the LDAP server’s limit is 2.0 KB, set the configurable to 1.9 KB.

Level of SSL certificate validation:

• 0: No validation; default.
• 1: Certificate must be valid, but the common name is not checked.
• 2: Certificate must be valid and the certificate common name matches the AD/LDAP server’s host name.

The path of the directory where db.* files for a read-only client will be placed.

For example, if you create a read-only client whose name is myroc and client.readonly.dir is set to /perforce/1, then syncing files using this client will write to the database /perforce/1/server.dbs/client/hashdir/db.myroc

How many seconds to wait before refreshing the list of Perforce-related processes running on a Helix Core server machine. The default value of 0 means the feature is off. This configurable enables you to determine which process identifier you might want to terminate. For details, see "Fixing a hung Helix Core server" at http://answers.perforce.com/articles/KB/3785

The value sets the maximum size of memory allotted to the db.monitor table, which tracks the p4d commands that are currently running.

Setting this configurable to 0 means that the table is written to disk. However, writing the table to memory is recommended to improve performance.

If the size of the table exceeds the value of db.monitor.shared, an error is returned. Commands are still executed, but they are not recorded in the table.

Enable and configure lockless reads; when enabled, many common commands no longer block other commands attempting to update the database. See the Helix Versioning Engine Administrator Guide: Fundamentals for details.

0: Disable peeking. Behavior is identical to 2013.2 and earlier.

1: New locking order is enabled, peeking is disabled, (diagnostic use only).

2: New locking order is enabled, peeking is enabled, hx/dx optimization on.

3: New locking order is enabled, peeking is enabled, hx/dx optimization is off.

Control behavior of commands that access metadata (db.* files) on the Helix Core server:

readonly: User commands that read metadata are accepted; commands that modify metadata are rejected.

Equivalent to starting a replica with the p4d -M readonly option.

This configurable cannot be set globally; you must specify a server id.

Buffer size for journal and checkpoint read/write operations.

Set to 1 to disable fsync() call when server closes a db.* database file, and permit the OS to determine when to write the modified data.

Default type for new changelists: either public or restricted. If unset, new changelists are public.

Maximum revision size for p4 annotate.

Wait this many seconds before forcibly updating an access time, even if server must wait for a lock.

Wait this many seconds before requesting a write lock to update an access time.

Maximum number of revisions that can be searched with p4 grep.

By default, use new integration engine with p4 integrate. (The p4 merge command always uses the v3 integration engine regardless of this setting.)

Sites that wish to continue to use the old (2006.1) integration logic must set this configurable to 2 by running p4 configure set dm.integ.engine=2.

If set to 1 or 2, p4 keys requires admin access. If set to 2, p4 key requires admin access.

Default minimum password length for servers where security is set to a nonzero value.

Allow Perforce administrators to use -a, -g, and -u with p4 protects. By default, only superusers can use these options.

Determine (in accord with the use of IP addresses in the protections table) whether a user can access a server from a given IP address. By default, if a connection comes through an intermediary, the proxy- prefix is prepended to the client IP address.

Set this variable to 0 if you do not want to have connections that come in through an intermediary to have the proxy- prefix.

For more information, see the p4 protect command.

Control behavior of automatic repo creation in a depot of type graph.

0: When a user does a git push, if that repo does not already exist in the graph depot, this new repo is added in the graph depot.

1: When a user does a git push, if that repo does not already exist in the graph depot, the git push fails and the repo is not added to the graph depot.

Enable resolve for attributes set with p4 attribute.

Set to 0 to disable log rotation after journal rotation.

By default, when the journal is rotated, any structured logs are also rotated. Disabling this behavior can help when you’re doing frequent journal rotations and you want the log rotated on a different schedule.

When a shelf is viewed or modified, update its access time if its last access time was longer than the limit specified by the value of dm.shelve.accessupdate

Use the p4 -Ztag change -o command to display the access time for shelved files.

Maximum number of files that can be shelved with p4 shelve.

Maximum size of a file that can be shelved, or 0 for unlimited.

Enable to make edge servers always promote shelved files to the commit server (rather than use the -p option). Generally, it is a bad idea to enable automatic promotion because it causes a lot of unnecessary file transfers for shelved files that are not meant to be shared.

Wait this many seconds before forcibly updating an access time, even if server must wait for a lock.

Wait this many seconds before requesting a write lock to update an access time.

Number of password attempts before delay. After the third failed login attempt, the user must wait 10 seconds.

Control behavior of automatic user creation.

0: Create users as required. When executed by a nonexistent user, most Perforce commands cause a user to be created. An example of a command that does not create a user is p4 info.

1: New users may only be created by running p4 user.

2: New users may only be created by superusers running p4 user.

Scan the first filesys.binaryscan bytes for binary data when running p4 add.

Buffer size for client-side read/write operations.

Use to prevent addition of files that have a symlink in their directory path. When set to 1, attempts to p4 add a file that is symbolically linked below the client root fail.

Setting this configurable to 2 allows the user to bypass the check by using the -f (force) option.

Minimum disk space required for any depot before server rejects commands. (If there is less than filesys.depot.min disk space available for any one depot, commands are rejected for transactions involving all depots.)

To specify size, use the following binary abbreviations, which are slightly different from the more familiar decimal abbreviations:

t or T for tebibytes (1 T is approximately 1.1 TB)
g or G for gibibytes (1 G is approximately 1.07 GB)
m or M for mebibytes (1 M is approximately 1.05 MB)
k or K for kibibytes (1 K is 1,024 bytes)

You can also use a percentage to specify the relative amount of free disk space required.

Minimum filesize before preallocation (Windows).

Minimum disk space required on server journal filesystem before server rejects commands.

To specify size, use the following binary abbreviations, which are slightly different from the more familiar decimal abbreviations:

t or T for tebibytes (1 T is approximately 1.1 TB)
g or G for gibibytes (1 G is approximately 1.07 GB)
m or M for mebibytes (1 M is approximately 1.05 MB)
k or K for kibibytes (1 K is 1,024 bytes)

You can also use a percentage to specify the relative amount of free disk space required.

Minimum disk space required on server log filesystem before server rejects commands.

To specify size, use the following binary abbreviations, which are slightly different from the more familiar decimal abbreviations:

t or T for tebibytes (1 T is approximately 1.1 TB)
g or G for gibibytes (1 G is approximately 1.07 GB)
m or M for mebibytes (1 M is approximately 1.05 MB)
k or K for kibibytes (1 K is 1,024 bytes)

You can also use a percentage to specify the relative amount of free disk space required.

Minimum disk space required on server root filesystem before server rejects commands.

To specify size, use the following binary abbreviations, which are slightly different from the more familiar decimal abbreviations:

t or T for tebibytes (1 T is approximately 1.1 TB)
g or G for gibibytes (1 G is approximately 1.07 GB)
m or M for mebibytes (1 M is approximately 1.05 MB)
k or K for kibibytes (1 K is 1,024 bytes)

You can also use a percentage to specify the relative amount of free disk space required.

Minimum disk space required for temporary operations before server rejects commands.

To specify size, use the following binary abbreviations, which are slightly different from the more familiar decimal abbreviations:

t or T for tebibytes (1 T is approximately 1.1 TB)
g or G for gibibytes (1 G is approximately 1.07 GB)
m or M for mebibytes (1 M is approximately 1.05 MB)
k or K for kibibytes (1 K is 1,024 bytes)

You can also use a percentage to specify the relative amount of free disk space required.

Set to 1 to support filenames longer than 260 characters on Windows platforms.

Depending on the depth of your workspace path, this might need to be set on the client, server, and/or proxy (which acts as a client).

A file name length of up to 32,767 characters is allowed. Each component of the path is limited to 255 characters. The server root or client root cannot be a long path.

Maximum file size for text type detection.

Enabling this configurable, specifies the storage method as compressed text (ctext) rather than RCS format text. The user still sees the file type as text.

It’s a good idea to set this variable when using a commit/edge configuration or when sharing archive files between servers.

Buffer size for read/write operations to server’s archive of versioned files.

1: File paths are always case-insensitive.

2: File paths are case-insensitive if server is case-insensitive.

3: File paths are always case-sensitive.

Control behavior of user commands that access versioned files on the Helix Core server:

readonly: User commands that read depot files are accepted; user commands that modify files are rejected.

shared: This is a synonym for ondemand mode.

ondemand: Replicate versioned files if, and only if, explicitly requested by users of the replica server.

cache: Commands that reference file content are accepted, but do not automatically transfer files. You may now use this option with edge servers or build servers to enable parallel file transfers.

none: No access to versioned files is permitted.

This configurable cannot be set globally; you must specify a server id.

Equivalent to starting a replica p4d process with one of the -D readonly, -D shared, (or -D ondemand), -D cache, or -D none options.

In the event of a failed transfer, a replica will make lbr.retry.max attempts to retrieve the file.

Verify contents from the client to server? (1 for yes, 0 for no)

Verify contents from the server to client? (1 for yes, 0 for no)

Lowest version of client software permitted to connect to this server, set by p4 configure set minClient=version.

Message to issue if client software is too old, set by p4 configure set minClientMessage=message.

Server process monitoring:

0: Server process monitoring off.

1: Monitor active commands only.

2: Monitor both active commands and idle connections.

5: Monitor both active commands and idle connections, including a list of the files locked by the command for more than one second.

10: Monitor both active commands and idle connections, including a list of the files locked by the command for more than one second, with lock wait times included in the lock information.

25: Monitor both active commands and idle connections, including a list of the files locked by the command for any duration, with lock wait times included in the lock information.

See p4 monitor for details.

TCP connection changes to improve performance over long latency connections.

To enable, set to 1. Clients set by using p4 set or P4CONFIG files. Servers set by using p4 configure. On Windows, send buffer sizes are not autotuned but manually configurable with net.tcpsize.

Maximum length of queue for pending connections. Consider increasing if users find themselves unable to connect to extremely heavily-loaded servers.

Number of unacknowledged keepalives before failure.

If non-zero, disable the sending of TCP keepalive packets.

Idle time (in seconds) before starting to send keepalives.

Interval (in seconds) between sending keepalive packets.

A value in megabytes that controls the proxy’s cache faulting behavior. A single p4 sync will not publish more than net.maxfaultpub megabytes of faults into pdb.lbr.

You must restart the server after changing the value of this configurable.

Time, in seconds, before a network connection times out.

Best practice is not to set server-wide: if set on server, requires that users complete command-line forms within this limit. If set in user’s individual P4CONFIG file, applies to user’s workstation (and requires only that the versioning service reply to user requests within the allotted time limit).

You must restart the server after changing the value of this configurable.

Man-in-the-middle network security level: This enables checks for possible interception or modification of data such as using an SSH tunnel or other TCP forwarder for users with passwords set.

0: Disable MitM checks.

1: Check proxy/broker connections in legacy contexts.

2: Connections from clients are checked for TCP forwarding.

3: Connections from clients, proxies, and brokers are checked for TCP forwarding.

4: All connections are checked; client software older than release 2010.1 cannot connect.

5: Requires that proxies, brokers, and all Perforce intermediate servers have valid logged-in service users associated with them. This allows administrators to prevent unauthorized proxies and services from being used.

You must restart the server after changing the value of this configurable.

Specifies the number of files in a batch.

See p4 sync on Parallel processing.

Specifies the number of bytes in a batch.

See p4 sync on Parallel processing.

A value greater than one enables parallel processing up to the specified number of threads, when syncing a client or submitting files.

In addition to setting this variable, you must use the --parallel option to the p4 sync command or the p4 submit command to further describe the processing desired. If you use net.parallel.submit.* configurables to automate parallel processing, you do not need to use the --parallel option.

Values can range between 0 and 100. See the p4 sync command or the p4 submit command.

Specifies the minimum number of files in a parallel sync. A sync that is too small does not initiate parallel file transfers.

See p4 sync on Parallel processing.

Specifies the minimum number of bytes in a parallel sync. A sync that is too small does not initiate parallel file transfers.

See p4 sync on Parallel processing.

For automatic parallel processing: specifies the number of files in a batch.

See the p4 submit command on Parallel submits.

For automatic parallel processing: specifies the minimum number of files to be sent in a parallel submit.

See the p4 submit command on Parallel submits.

For automatic parallel processing: specifies the number of threads to be used for sending files in parallel. The specified threads grab work in batches. The size of a batch is specified using the net.parallel.submit.batchconfigurable.

See the p4 submit command on Parallel submits.

Specifies the number of independent network connections that can be used for syncing files concurrently. The specified threads grab work in batches.

Set SO_REUSEPORT for listening socket.

You must restart the server after changing the value of this configurable.

If 1, permit the operating system to determine whether IPv4 or IPv6 is used when resolving hostnames. This is applicable only if a host name (either FQDN or unqualified is used).

If an IPv4 literal address (e.g. 127.0.0.1) is used, the transport is always tcp4, and if an IPv6 literal address (e.g. ::1) is used, then the transport is always tcp6.

You must restart the server after changing the value of this configurable.

Set the proxy monitoring interval. Default is 10 seconds.

Set to 1 to disable fsync() call when server writes to a versioned file in RCS format, and permit the OS to determine when to write the modified data.

Specifies one or more clients whose requests should be blocked. For more information, see "Blocking Clients" in Helix Versioning Engine Administrator Guide: Fundamentals.

Level of database table checksum verification to perform when rotating journal. Each level corresponds to a larger set of database tables.

0: Disable checksums.

1: Verify the most important system and revision tables.

2: Verify all of level 1, plus tables that hold metadata that does not vary between replicas.

3: Verify all metadata, including metadata that is expected to vary on build-farm and edge-server replicas.

Level of on-the-fly changelist verification to perform.

0: Perform no verification.

1: Write journal note at the end of a submit.

2: Replica verifies changelist summary and writes to integrity.csv if the changelist does not match.

3: Replica verifies changelist summary and writes to integrity.csv even if the changelist does match.

Setting affects p4 submit, p4 push, p4 fetch, p4 populate, and p4 unzip commands.

Level of table checksumming to perform.

0: Perform table-level checksumming only.

1: Journal notes for table-unload and table-scan are processed by the replica, and are logged to integrity.csv if the check fails.

2: Results of journal note processing in the replica are logged even if the results match.

Enable replica/master network compression:

0: No data stream compression.

1: Data streams used for archive transfer to the replica (p4 pull -u) are compressed.

2: Data streams used by p4 pull -u and p4 pull are compressed.

3: All data streams (p4 pull -u, p4 pull, and data streams for commands forwarded to the master or commit server) are compressed.

4: Compress only the journal pull and journal copy connections between the replica and the master.

Set to 1 on each replica to enable single-sign-on authentication for users in a distributed configuration. The auth.id configurable must also be the same for all servers participating in a distributed configuration.

For more information, see "Authenticating users" in Helix Versioning Engine Administrator Guide: Multi-Site Deployment.

Used to tune server performance when a forwarding replica has lots of users. Please consult Perforce Support for guidance in adjusting values.

Used to tune server performance when a forwarding replica has lots of users. Please consult Perforce Support for guidance in adjusting values.

Used to tune server performance when a forwarding replica has lots of users. Please consult Perforce Support for guidance in adjusting values.

The number of standby servers that must acknowledge a persisted transaction before the transaction is visible to a workspace server and before the client is notified of successful completion.

The default value means one standbys has to acknowledge a transaction.

Do not set this configurable to a higher value than the number of available standby servers.

Set to 0 means that if the standby stops running, transactions will continue to be processed without requiring acknowledgments. If then the master fails, you might lose data.

Set to 1 means that if the standby stops running, update transactions will not complete and therefore, if the master then fails, no data from completed transactions are lost.

With a distributed Perforce service, there are both local and global labels. Local labels are restricted to a single edge server, and cannot be used on other servers. Global labels are created and updated on the commit server, and are visible to all servers. However, global labels can only be used with global (unbound) client workspaces.

For the 2013.2 release, the default is for labels to be local. Set rpl.labels.global to 1 to make labels global by default.

When this configurable is set to 0, users can use the -g option with the commands p4 label, p4 labelsync, and p4 tag to create or update global labels. When this configurable is set to 1, the meaning of the -g option is inverted to allow updating of local labels.

Set to one to replicate the db.user.rp table.

The db.user.rp table contains information about users who have directly logged into and used a replica. It records the ticket that the replica issued to the user and the last time the user accessed the replica. This table is currently journaled, but it is not replicated by default.

Typically you would not want to replicate this data. But there are times when this might be needed. For example, if you are chaining a read-only replica to another replica to provide a warm standby for failover, you might want your warm standby to replicate the db.user.rp table. This would disable the automatic filtering of db.user.rp records, and your replica would then replay (and re-journal) all the db.user.rp journal records it receives from its target.

If set, a replica server will re-verify the integrity of a cached file every time it delivers the file to the user, If the files do not match, it will re-fetch the file from the upstream server. This is computationally expensive on the replica and typically only useful in conjunction with Perforce technical support.

Server security level:

0: Legacy support: passwords not required, strength requirements unenforced.

1: Strong passwords required, existing passwords not reset, compatible with pre-2003.2 client software.

2: Strong passwords required, existing passwords reset, requires 2003.2 or higher client software.

3: Passwords must be strong, and ticket-based authentication (p4 login) is required.

4: All of the above restrictions. Also, authenticated service users must be used for all replica server and remote depot connections to this server.

Determines whether changes can be fetched.

• If set to 1, this server can fetch from other servers.
• If set to 2, other servers can fetch from this server.
• If set to 3, both 1 and 2 are allowed.

Determines whether changes can be pushed.

• If set to 1, this server can push to other servers.
• If set to 2, other servers can push to this server.
• If set to 3, both 1 and 2 are allowed.

DVCS configurations with files of type +l can use the --remote flag on the p4 edit, p4 delete, and p4 revert commands. This locks +l file types exclusively on the shared server. The locks are released automatically when the modified files are pushed.

The shared server must be a commit server and this configurable must have 1, not 0, as its value.

To learn about +l, see the Helix Versioning Engine User Guide on File type modifiers.

If set to a non-zero value, allows this server to run the p4 unsubmit and p4 fetch -u commands.

Policy for per-command resource limits:

0: All users may use command-line overrides for MaxResults, MaxScanRows, and MaxLockTime limits defined in the p4 group specs.

1: Per-command options may specify lower, but not higher, resource limits.

2: All command-line resource limit options are silently ignored.

The filesystem location with respect to which a relative address given in the Map: field of a depot form is evaluated. If it is not set, the Map: field relative address is evaluated with respect to the value stored in P4ROOT. For more information, see the p4 depot command.

Controls whether the view maps of a non-stream client on an edge server are made global when a client is modified.

View maps of a client on a replica must be made global if that client is to be used as a template on another server.

This configurable can be set globally or individually for each server. This allows client maps to be global on most edge servers while keeping them local on those edge servers that don’t need or want them to be global.

Setting this configurable does not immediately make any client view maps global; that happens only when a client is modified afterwards. Clearing this configurable does not delete the view maps of any clients, but it does prevent subsequent changes to a client’s view map from being propagated to other servers. If a client with global view maps is deleted, its view maps are also deleted globally regardless of the value of server.global.client.views; this is to prevent orphaned view maps.

Setting this configurable does not require a server restart.

Set this configurable to disable server locks when running the p4 archive or p4 restore commands.

Directory for server locks, specified relative to P4ROOT. To disable server locking, set this configurable to disabled. (If db.peeking is nonzero (enabled), server.locks cannot be disabled; you can disable locking by setting server.locks.sync to 0.)

Set this configurable to 1 to make p4 lock from an edge server take global locks on the commit server by default.

When set, the p4 sync command takes a client workspace lock in shared mode. The default value of 0 prevents sync from taking a client workspace lock.

If db.peeking is enabled, the server.locks.dir directory must exist. The changes to locking behavior that occur when you enable db.peeking obviate the need to set server.locks.dir to disabled, but if performance issues arise with respect to multiple concurrent, large, and/or interrupted p4 sync commands, you can obtain the old behavior for syncing by setting server.locks.sync to 0.

If monitoring is enabled, and if this configurable is set to a nonzero value, the service refuses to accept more than this many simultaneous command requests.

The counter name for the structured log file designated by n. (For example, if the structured log file is errors.csv, n is 3.)

See "Logging and structured files" in the Helix Versioning Engine Administrator Guide: Fundamentals for more information.

Server log file name associated with each structured log file. See p4 logparse for a list of valid filenames.

n may not exceed 500.

For each structured log file, the size, in megabytes, at which the associated log file is rotated.

For each structured log file, the number of rotated log files to retain on the server at any one time.

The service user as which a server (or proxy) authenticates against a master server in a replication/proxy configuration, or against a remote server in the context of remote depots.

Number of buckets (subdirectories) into which files in the spec depot are hashed. Set to 0 to disable hashing, which may slow performance on older filesystems where performance is a function of the number of files per directory.

By default, Perforce’s SSL support is based on the AES256-SHA cipher suite. To use CAMELLIA256-SHA, set this tunable to 1.

Controls the TLS version(s) allowed for SSL connections. The connection uses the highest version in common between server and client.

ssl.tls.version.min specifies the lowest version, and ssl.tls.version.max specifies the highest version.

Valid values are 10 for TLSv1.0, 11 for TLSv1.1, and 12 for TLSv1.2.

To see the values on the server:

p4 configure show ssl.tls.version.min
p4 configure show ssl.tls.version.max

To set the values on the server, issue commands, then restart the server so the changes take effect. For example, to allow TLSv1.1 or TLSv1.2 but exclude TLSv1.0:

p4 configure set ssl.tls.version.min=11
p4 configure set ssl.tls.version.max=12

To allow only a single version, assign the same value to both configurables.

On a client, to verify that TLSv1.0 does not connect:

p4 -v ssl.tls.version.min=10 -v ssl.tls.version.max=10 info

For replica servers, set startup.1 through startup.n to be p4 pull threads to be spawned at startup.

The startup.n configurables are processed sequentially. Processing stops at the first gap in the numerical sequence; any commands after a gap are ignored.

For replica servers, the file used by the server to track the current journal position.

Enable the generation of global changelist ids. This is relevant for users of the Helix Versioning Engine’s distributed versioning (DVCS) features.

• uuid generates the id in uuid format.
• checksum generates the id in checksum format.
• serverid generates the id in serverid+change format.

For more information on global changelist ids, see the section "Track a changelist’s identity from server to server" in the "Fetching and Pushing" chapter of Using Helix Core for Distributed Versioning.

Always re-transfer files after a failed submit.

Set this configurable to have the server check whether files are already in the expected archive location and to not re-transfer files when retrying a failed submit.

You can override the set behavior by using the --noretransfer option to the p4 submit command.

When set, open files that users have locked (with the p4 lock command) are automatically unlocked after a failed p4 submit.

Limit in microseconds for retrying a failed file rename. Affects Windows Rename() retry loop.

Specifies the default client to be used as a template if the user omits the -t option on the p4 client command.

Specifies the default label to be used as a template if the user omits the -t option on the p4 label command.