As Dave and I begin working on Ugly Baby with Dejobaan, we had the opportunity to throw the Unity project in our version control system of choice. Coming off the heels of a couple projects versioned with Unity’s Asset Server, I was definitely looking forward to working with something slightly more robust.
Perforce, in a previous life, was very expensive to use ($700+/user). Their free licensing restrictions used to only allow a handful of users/workspaces, which wouldn’t be enough for a small team with a few dev computers. That being said, they have recently changed their terms to allow for up to 20 users/workspaces and unlimited files, or unlimited users, and a limit of 1000 files. Jumping into a game that’s closing in on it’s third or fourth year of iterative development, I decided the former would be the best option for us.
On top of that, it turns out to be very easy to get everything setup for yourself at absolutely no cost.
Setting up the Server
Normally, you’d have to worry about getting a server hosted somewhere, worry about the bandwidth, the disk space, the uptime. Turns out Amazon allows for small servers hosted on their huge EC2 backbone at absolutely no cost.
You have two options here, setup an instance on your own, or use BitNami to do the management of the Amazon EC2 server instance. I have played with both, and ended up sticking with BitNami because I had it setup a server with a base installation of some task management software I wanted to try. BitNami also sends you estimates of what your monthly payment will be with regards to your past week’s activity. It’s a good way to get a heads up if you’re pushing your instance a bit too hard.
This section of the setup will be a little bit sparse, as it’s been a few weeks since I setup my own server, and I did not take notes at the time. If I run through it with a friend, I’ll come back and update the post.
What’s important though, is you setup a server with either Debian or Ubuntu. Having the apt-get package manager makes our lives a bit easier. Realize that if you screw up along the way, and want to start over, simply terminate and delete your server instance off of Amazon’s backend, and start over.
- Download the `daemon` utility. This utility allows `p4d` to be run by the `perforce` user instead of `root`.
sudo apt-get install daemon
- Connect to the directory where the `p4` and `p4d` files where downloaded (probably the home directory).
- Make the `p4` and `p4d` files executable.
chmod +x p4 p4d
- Copy the Perforce executables to `/usr/local/bin` which is already in the system PATH environment variable.
sudo mv p4 /usr/local/bin
sudo mv p4d /usr/local/bin
- Create a group for Perforce files.
sudo addgroup p4admin
- Create a user for Perforce administrative work.
sudo adduser perforce
- Use `visudo` to give the perforce user account the ability to use `sudo`. Add the following line at the end of the file.
perforce ALL = ALL
- Log off your default user account.
- Log in using the `perforce` account.
- Create a directory to hold the repository.
sudo mkdir /perforce_depot
sudo chown perforce:p4admin /perforce_depot
- Create a directory to hold Perforce log files.
sudo mkdir /var/log/perforce
sudo chown perforce:p4admin /var/log/perforce
- Add the following lines to the end of /etc/profile. These settings will be used by client programs run on the Linux server – not by the Perforce server.
# Perforce Settings
- Load the Perforce settings.
- Use `visudo` to remove the perforce user the ability to use sudo. (added in by me, that’s a security risk to leave in otherwise!)
Run Perforce on Boot
- Connect to the initialization control directory.
- Create the Perforce control script using `sudo vi perforce`.
p4stop="p4 admin stop"
case "$1" in
log_action_begin_msg "Starting Perforce Server"
daemon -u $p4user $p4start;
log_action_begin_msg "Stopping Perforce Server"
daemon -u $p4user $p4stop;
echo "Usage: /etc/init.d/perforce (start|stop|restart)"
- Integrate the Perforce control script into the boot process.
sudo update-rc.d perforce defaults
- Goto your home directory then use the control script to start the Perforce server.
sudo /etc/init.d/perforce start
- Use the control script to restart the Perforce server.
sudo /etc/init.d/perforce restart
Run Perforce for the first time
Before Perforce can be used by a team there are two housekeeping task that need to be done – creating the journal and closing a security hole.
- Set the Perforce environment variables.
- Start the perforce server. The command line is short because all of the settings are provided by the variables exported by /etc/profile.
sudo p4d –d
- Create the journal.
sudo p4d –jc
- By default, all users connected to Perforce are administrators. However, that level of security is not acceptable for a normal development environment. Run the `protect` option to switch out of the default security mode. For now, accept the default protections by typing `:wq` and pressing Enter.
sudo p4 protect
- Stop the Perforce server.
sudo p4 admin stop
I would suggest that you protect your Perforce connection by logging into it over SSL, rather than the plaintext connection that acts as a default.
- Create the directories for Perforce’s SSL certs and whatnot.
sudo mkdir /perforce_ssl
sudo chown perforce:p4admin /perforce_ssl
- Edit /etc/profile and /etc/init.d/perforce and add or edit the following lines:
- Create a file called “config.txt” within the perforce_ssl folder, chown it to perforce:perforce, and fill it with the following contents, changing the defaults where you see fit:
# C: Country Name - 2 letter code (default: US)
# ST: State or Province Name - full name (default: CA)
# L: Locality or City Name (default: Alameda)
# O: Organization or Company Name (default: Perforce Autogen Cert)
# OU = Organization Unit - division or unit
# CN: Common Name (usually the DNS name of the server)
# (default: the current server's DNS name)
# EX: number of days from today for certificate expiration
# (default: 730, e.g. 2 years)
# UNITS: unit multiplier for expiration (defaults to "days")
# Valid values: "secs", "mins", "hours"
- After you’ve saved that file, type the following:
- Verify that you have both a certificate.txt and a privatekey.txt in your directory now. If you don’t, check the logs at /var/log/perforce/p4err. Installing this a second time, I discovered that I needed to:
sudo chmod 700 /perforce_ssl/
- Generate a fingerprint for the key and certificate pair. Make a note of this keypair, it can be given to your users to verify the authenticity of your server for secure communications.
- Restart the p4d, and it *should* start up in SSL. Confirm this by connecting via SSL (use ssl:your_ip:your_port) in your p4 client as your host address. (I would also look into setting the security settings high enough to require a password on login.)
Setting up Perforce for Unity
It’s also important to setup the typemap for Perforce, to ensure that the files that are being checked out are properly marked as text, binary, and binary exclusive.
In order to do this, type:
You’ll want to paste in the following typemap, and be sure to save.
Until I have to run through this again, this is the approximation of the work that I needed to do to get Perforce up and running on my EC2 instance. It may be missing certain important bits of information, and it may be wrong, as I do remember running into a few “gotcha!”s during installation.If you have anything specific to ask or pass along, simply reach out to me via the contact page, or try Twitter.
- If you have everything up and running on the server, and you cannot seem to access the server from outside the server, make sure that you did not set the P4PORT to ssl:localhost:1666. This restricts all external connections, even if your firewall has an open port to your server.
The majority of the credit for this knowledge is not my own. Thanks to the following sites that contained most of this information: