Introduction

Perforce is a very fast Software Configuration Management System. For trial purposes or for personal use you can download their full server and run it with all the features, the only restriction is that you can only create two users (which can be a little problem when you have automatic servers doing stuff in the background). Anyhow, if you want to know all about it, read more here (hey, they can sell their own stuff :). Ok. Now you know what perforce is, right? It's pretty easy to install it under windows or unix, in windows it's simply an installer, under unix you can just untar it wherever you want it and hook it up through your rc-scripts. Once running there are a couple of things you should do before letting users loose on the repository.

Protection levels

One of the first things you should do is to make sure your permissions are initialized to a sane state. This makes the repository sane in terms of security and what people can do and it also eases your (the admin's) life since by default everyone is root in perforce!

Basic systems administration doctrine states that you should never ever give permissions to users, instead always add the user to a group with the permissions. Consider the case where you have given the user Brian access to a dozen files scattered across the file system. Now Jay comes along and wants access to the same files. Finding all the files and making sure that the permissions are the same is tedious and error prone. The same holds true for revoking those permissions. It's also very hard to get a grasp of what permissions any given user have.

Now if you add Brian and Jay to a group that holds permissions to these files, it's fairly easy to grasp that they are members of this group. An added benefit is also that the group can have a meaningful name, like ExternalDevelopers, which makes it easier to remember conceptually what permissions they should have.

So in terms of our perforce repository we can start off easy and create three new groups: Admins, Users and Guests. Admins will of course have supervisor privileges, ordinary users have read/write and the Guests only have read permissions. To create a new group or edit an existing group, simply type p4 group <name>. E.g. to create the group "Admins" I'd type "p4 group Admins".

# A Perforce Group Specification.
#
#  Group:       The name of the group.
#  MaxResults:  A limit on the results of operations for users in
#               this group, or 'unlimited'.  See 'p4 help maxresults'.
#  MaxScanRows: A limit on the data scanned during operations for users
#               in this group, or 'unlimited'.  See 'p4 help maxresults'.
#  Timeout:     A time (in seconds) which determines how long a 'p4 login'
#               session ticket remains valid (default is 12 hours).
#  Subgroups:   Other groups automatically included in this group.
#  Users:       The users in the group.  One per line.

Group:	Admins

MaxResults:	unlimited

MaxScanRows:	unlimited

Timeout:	43200

Subgroups:

Users:
	Administrator
    

Looking at listing (2) for the protection database. The default protection table will grant write permissions to all users, we've changed this to that we only grant permissions for people that actually are known and members of the specified groups. To edit the protection database, type p4 protect.

If you should be so unlucky to have a clown finger moment while you're doing this and accidentally lock yourself out of the database by revoking the only super access account from the protection table you are in big trouble. If you don't mind loosing the protection database, you could just stop the server and remove the file db.protect in the server directory... This is of course not ideal and at your own risk. Don't shoot yourself in the foot.

# Perforce Protections Specification.
#
#  Each line contains a protection mode, a group/user indicator, the
#  group/user name, client host id and a depot file path pattern.
#  A user gets the highest privilege granted on any line.
#
#  Mode:        The permission being granted.  Each permission includes
#               all the permissions above it, except for 'review'.
#
#               list   - users can see names but not contents of files;
#                        users can see all non-file related metadata
#                        (clients, users, changelists, jobs, etc.)
#
#               read   - users can sync, diff, and print files
#
#               open   - users can add, edit, delete, and integrate files
#
#               write  - users can submit open files
#
#               super  - allows access to the 'p4 protect' command
#
#               review - allows access to the 'p4 review' command; implies
#                        read access
#
#  Group/User indicator: either 'group' or 'user'.
#
#  Name:        A Perforce group or user name; may be wildcarded.
#
#  Host:        The IP address of a client host; may be wildcarded.
#
#  Path:        The part of the depot being granted access.

Protections:
	read group Guests * //...
	write group Users * //...
	super group Admins * //...
    

Set your password

Perforce have by default no passwords on the user accounts, in all it seems like it's more of an open environment kind of server (i.e. not hostile internet). You as the super user should have a password though, even if you only have "trusted" users on your network otherwise the protection levels are kind of pointless.

p4 counter -f monitor 1
net stop perforce
net start perforce
	

You can read more about passwords and security levels here.

Rename the depot

The root folder of perforce is called a depot. The default one is simply called "depot", which is a little bit silly and potentially confusing. That's why you should probably delete the default one and create a new one with a better name. Delete the old one by "p4 depot -d depot" and create a new one named e.g. happygames by "p4 depot happygames". The sheet that comes up should look somewhat like this:

# A Perforce Depot Specification.
#
#  Depot:       The name of the depot.
#  Owner:       The user who created this depot.
#  Date:        The date this specification was last modified.
#  Description: A short description of the depot (optional).
#  Type:        Whether the depot is 'local', 'remote', or 'spec'.
#  Address:     Connection address (remote depots only).
#  Suffix:      Suffix for all saved specs (spec depot only).
#  Map:         Path translation information (must have ... in it).
#
# Use 'p4 help depot' to see more about depot forms.

Depot:	foobars

Owner:	Administrator

Date:	2006/04/25 20:58:15

Description:
	Created by Administrator.

Type:	local

Map:	happygames/...
    

Enable monitor

Monitors enables you to look at what people currently are doing with the server. This can be a great tool to track down slowdowns and just generally get information of what is taking so long :) View it as a ps for perforce. It's disabled by default because it sucks a tiny bit of performance, but it should not be that bad to enable. Simply enable the counter and restart the perforce service like this:

p4 counter -f monitor 1
net stop perforce
net start perforce
	

After that you can now inspect what people are doing, e.g. foobar have been syncing to the repository for 3 hours etc.

In closing

All the administration tasks described here are also discussed in perforce's own documentation, which is really good and easy to understand with lots of examples. You should take a look at it there as well, I've merely given a couple of pointers to stuff to consider at the beginning of a new server (and maybe for an existing server as well if you haven't gotten around to it).

References

• Practical Perforce, a pragmatic take on how to manage and do common operations in perforce the way it was intended. Go with the flow and read it!
• Perforce home
• Perforce technical documentation. Read the System Administrator's Guide especially.

Comments