Chapter 1
Welcome to Perforce:
Installing and Upgrading

This chapter includes a brief overview of things to consider at installation time, along with some basic security and administration tips. More detailed information on administrative tasks is found in later chapters.

Getting Perforce

The server and client executables are available from the Downloads page on the Perforce web site:

http://www.perforce.com/perforce/loadprog.html

UNIX Installation

To limit access to the Perforce server files, ensure that the p4d executable is owned and run by a Perforce user account that has been created for the purpose of running the Perforce server.

To start using Perforce:

1. Download the p4 and p4d files for your platform from the Perforce web site.

2. Make the downloaded p4 and p4d files executable.

3. Create a server root directory to hold the Perforce database and versioned files.

4. Tell the Perforce server what port to listen to by specifying a TCP/IP port to p4d.

5. Start the Perforce server (p4d).

6. Specify the name or TCP/IP address of the Perforce server machine and the p4d port number to the Perforce client program(s) by setting the P4CLIENT environment variable.

Download the files and make them executable

Create a Perforce server root directory

To specify a server root, set the environment variable P4ROOT to point to the server root, or use the -r root_dir flag when invoking p4d. Perforce client programs never use the P4ROOT directory or environment variable; the p4d server is the only process that uses the P4ROOT variable.

Because all Perforce files are stored beneath the server root, the contents of the server root will grow over time. See "Installation and Administration Tips" on page 18 for a brief overview of diskspace requirements, and "Disk space allocation" on page 108 for more detail.

A Perforce server requires no privileged access; there is no need to run p4d as root or any other privileged user. For more information, see the section entitled "UNIX: Run p4d as a non-privileged user" on page 22.

The server root can be located anywhere, but the account that runs p4d must have read, write, and execute permissions on the server root and all directories beneath it. For security purposes, set the umask(1) file creation-mode mask of the account that runs p4d to a value that denies other users access to the server root directory.

Telling Perforce servers on which port to listen

If p4d is to listen on a different port, specify that port with the -p port_num flag when starting p4d (as in, p4d -p 1818), or set the port with the P4PORT environment or registry variable.

Unlike P4ROOT, the environment variable P4PORT is used by both the Perforce server and Perforce client programs, and must be set on both Perforce server machines and Perforce client workstations.

Telling Perforce client programs which port to connect to

Examples:

If the Perforce client program is running on the same host as p4d. only the p4d port number need be provided in P4PORT. If p4d is running on a host named or aliased perforce, and is listening on port 1666, the definition of P4PORT for the client can be dispensed with altogether. For example:

If your p4d host is not named perforce, you can simplify life somewhat for your Perforce users by setting perforce as an alias to the true host name in your users' workstations' /etc/hosts files, or by doing so via Sun's NIS or Internet DNS.

Starting the Perforce server

p4d &

Example:  Starting a Perforce server.

P4PORT can be overridden by starting p4d with the -p flag, and P4ROOT can be overridden by starting p4d with the -r flag. A journal file can be specified with the -J flag, and errors can be logged to a file specified with a -L flag. A startup command that overrides the environment variables might look like this:

p4d -r /usr/local/p4root -J /var/log/journal -L /var/log/p4err -p 1818 &

The -r, -J, and -L flags (and others) are discussed in "Supporting Perforce: Backup and Recovery" on page 25. A complete list of server flags is provided in the "Perforce Server (p4d) Reference" on page 139.

Stopping the Perforce server

p4 admin stop

If you are running a release of Perforce from prior to 99.2, you must find the process ID of the p4d server and kill the process manually from the UNIX shell. Use kill -15 (SIGTERM) instead of kill -9 (SIGKILL), as p4d might leave the database in an inconsistent state if p4d is in the middle of updating a file when a SIGKILL signal is received.

Windows Installation

Use the Perforce installer to:

• Install Perforce client software ("User install").

This option enables you to install p4.exe (the Perforce Command-Line Client), p4win.exe (P4Win, the Perforce Windows Client), and p4scc.dll (Perforce's implementation of the Microsoft common SCM interface).

• Install Perforce as either a Windows server or service as appropriate. ("Administrator typical" and "Administrator custom" install).

These options enable you to install Perforce client programs and the Perforce Windows server (p4d.exe) and service (p4s.exe) executables, or to automatically upgrade an existing Perforce server or service running under Windows.

Under Windows 2000 or higher, you must have Administrator privileges to install Perforce as a service, and Power User privileges to install Perforce as a server.

• Uninstall Perforce: remove the Perforce server, service, and client executables, registry keys, and service entries. The Perforce database and the depot files stored under your server root are preserved.

Windows services and servers

On UNIX systems, there is only one Perforce "server" program (p4d) responsible for this back-end task. On Windows, however, the back-end program can be started either as a Windows service (p4s.exe) process that runs at boot time, or as a server (p4d.exe) process that must be invoked from a command prompt.

The Perforce service (p4s.exe) and the Perforce server (p4d.exe) executables are copies of each other; they are identical apart from their filenames. When run, the executables use the first three characters of the name with which they were invoked (either p4s or p4d) to determine their behavior. (For example, invoking copies of p4d.exe named p4smyservice.exe or p4dmyserver.exe invoke a service and a server, respectively.)

In most cases, it is preferable to install Perforce as a service, not a server. For a more detailed discussion of the distinction between services and servers, see "Windows services vs. Windows servers" on page 124.

Starting and stopping Perforce

If you install Perforce as a server under Windows, invoke p4d.exe from a command prompt. The flags for p4d under Windows are the same as those used under UNIX.

To stop a Perforce service (or server) at Release 99.2 or above, use the command:

p4 admin stop

For older revisions of Perforce, shut down services manually by using the Services applet in the Control Panel. Shut down servers running in command prompt windows by typing CTRL-C in the window or by clicking on the icon to Close the command prompt window.

Although these manual shutdown options work with Release 99.2 and earlier versions of Perforce, they are not necessarily "clean", in the sense that the server or service is shut down abruptly. With the availability of the p4 admin stop command in 99.2, the manual shutdown options are obsolete.

Upgrading a Perforce Server

Using old client programs with a new server

Perforce's remote depot support is an exception: remote depot support is not guaranteed to work unless all Perforce servers are at or above Release 98.2.

Important notes for 2001.1 and later

On larger installations, you must upgrade the database manually. Although the upgraded database is typically smaller than a pre-2001.1 database, the upgrade process may (temporarily) require approximately three times the size of the existing database to store files required during the upgrade.

If you are upgrading from Release 97.3 or earlier to 2001.1 or later, the automatic or manual upgrade procedures will not work; you will likely have to make an intermediate checkpoint. Contact Perforce technical support for assistance before upgrading a Release 97.3 or earlier server.

UNIX upgrades

You must back up your server as described in "Backup Procedures" on page 31 as part of any upgrade process.

For additional safety, run p4 verify as part of your upgrade. See "Verifying during server upgrades" on page 48 for details.

Upgrading from UNIX Release 98.2 or later

1. Download the new p4d executable for your platform

2. Stop the current instance of p4d

3. Make a checkpoint and back up your old installation

4. Install the new p4d in the desired location

5. Run p4d -xu to upgrade the database.

   Note

   If your server has fewer than 1000 changes, the upgrade runs automatically. Larger installations require that you run p4d -xu manually. You must have sufficient disk space to complete the upgrade. The required amount is typically two to three times the size of the larger of the db.have or db.integ files. The db.have and db.integ files reside in your P4ROOT directory.

6. Restart the new p4d with your site's usual parameters.

Windows upgrades

The upgrade process on Windows is extremely conservative; in the event of an error condition during an upgrade, you will be able to revert to your pre-upgrade Perforce server or service.

If you have any questions or difficulties during an upgrade, contact Perforce technical support.

Installation and Administration Tips

Release and license information

Licensing information is contained in a file called license in the server root directory. The license file is a plain text file supplied by Perforce Software. Without the license file, the Perforce server limits itself to two users and two client workspaces.

To view current licensing information, invoke p4d -V from the server root directory where the license file resides, or by specifying the server root directory either on the command line (p4d -V -r server_root) or in the P4ROOT environment variable.

If the server is running, you can also use p4 info to view your licensing information.

The server version is also displayed when invoking p4d -V or p4 -V.

Observe proper backup procedures

• Make sure journaling is active,

• Create checkpoints regularly, and

• Use p4 verify regularly.

Use separate physical drives for server root and journal

By storing the journal on a separate drive, you can be reasonably certain that if a disk failure corrupts the drive containing P4ROOT, such a failure will not affect your journal file. You can then use the journal file to restore any lost or damaged metadata.

Further details are available in "Supporting Perforce: Backup and Recovery" on page 25.

Use protections and passwords

p4 protect

Without passwords, any user is able to impersonate any other Perforce user, either with the -u flag or by setting P4USER to an existing Perforce user name. Use of Perforce passwords prevents such impersonation. See the Perforce User's Guide for details.

To set (or reset) a user's password, use p4 passwd username (as a Perforce superuser), and enter the new password for the user, or invoke p4 user -f username (also while as a Perforce superuser) and enter the new password into the user specification form. The former command is supported in release 99.1 or later; the latter command is supported under all releases from 97.3 onwards.

The security-conscious Perforce superuser also uses p4 protect to ensure that no access higher than list is granted to non-privileged users, and to ensure that each user has a Perforce password.

Allocate disk space for anticipated growth

For a more detailed example of a disk sizing estimate, see "Disk space allocation" on page 108.

Managing disk space after installation

• Configure Perforce to store the journal file on a separate physical disk. Use the P4JOURNAL environment variable or p4d -J to specify the location of the journal file.

• Checkpoint on a daily basis to keep the journal file short.

• Compress checkpoints, or use the -z option to tell p4d to compress checkpoints on the fly.

• Use the -jc prefix option with the p4d command to write the checkpoint to a different disk. Alternately, use the default checkpoint files, but back up your checkpoints to a different drive and then delete the copied checkpoints from the root directory. Moving checkpoints to separate drives is good practice not only in terms of diskspace, but due to the fact that old checkpoints are needed when recovering from a hardware failure, and if your checkpoint and journal files reside on the same disk as your depot, a hardware failure could leave you without the ability to restore your database.

• On UNIX systems, you can relocate some or all of the depot directories to other disks by using symbolic links. If you use symbolic links to shift depot files to other volumes, create the links only after stopping the Perforce server.

• If your installation's database files have grown to more than 10 times the size of a checkpoint, you may be able to reduce the size of the files by recreating them from a checkpoint. See "Checkpoints for Database Tree Rebalancing" on page 119.

Large filesystem support

If you anticipate any of your Perforce database files growing beyond the 2GB level, install the Perforce server on a platform with support for large files. The following combinations of operating system and Perforce server revision support database files larger than 2GB:

UNIX and NFS support

Consequently, under Solaris 2.6 or higher, you can store your journal, log, depot, and db.* files on NFS-mounted filesystems.

Some issues still remain regarding file locking on non-commercial implementations of NFS (for instance, Linux and FreeBSD). On these platforms, store your journal, log, depot, and db.* files on a drive local to the server machine, not on an NFS-mounted volume.

These issues affect only the Perforce Server process (p4d). Perforce client programs, (such as p4, the Perforce Command-Line Client) have always been able to work with client workspaces on NFS-mounted drives, such as client workspaces located in users' home directories.

Windows: Username and password required for network drives

Although Perforce operates reliably with its root directory on a network drive, it does so only at a substantial performance penalty, as all writes to the database are performed over the network. For optimal performance, install the Windows service to use local drives rather than networked drives.

For more information, see "Installing the Perforce service on a network drive" on page 125.

UNIX: Run p4d as a non-privileged user

Create a non-privileged UNIX user (for example, "perforce") to manage p4d and (optionally) a UNIX group for it (for example, "p4admin"). Use the umask(1) command to ensure that the server root (P4ROOT) and all files and directories created beneath it are writable only by the UNIX user perforce, and (optionally) readable by members of the UNIX group p4admin.

Under this configuration, the Perforce server (p4d), running as UNIX user perforce, can write to files in the server root, but no users are able to read or overwrite its files. Access to read the files created by p4d (that is, the depot files, checkpoints, journals, and so on) can subsequently be granted to trusted users by making them members of the UNIX group p4admin.

Logging errors

Although p4d tries to ensure that all error messages reach the user, if an error occurs and the client program disconnects before the error is received, p4d also logs these errors to its error output.

The Perforce server also supports trace flags used for debugging purposes. See "Perforce server trace flags" on page 60 for details.

Case sensitivity issues

Tune for performance

For more detailed performance tuning information, see "Tuning Perforce for Performance" on page 107.