You may have seen Perforce in the news as being the target of the cyber attacks against several well known companies in recent months. We want to reassure you that there has been no determination that any security vulnerabilities in the product played a role in these attacks.  You can read our company response at:

http://perforce.com/perforce/press/pr121_McAfee_statement.pdf

We would like to take this opportunity to remind users and administrators about basic security precautions that can be taken.

PROTECTING YOUR INTELLECTUAL PROPERTY
Productivity and security are absolute requirements in most enterprises, yet they are sometimes seen as enemies of each other.  Productivity always matters.  Security (like backups) is one of those things that means nothing until the day it means everything.  Recent events have raised awareness of the importance of security for Perforce customers. Now is a good time to remind users and administrators of basic steps that should be taken to secure your Perforce installation.

RULE #1:  LOCK YOUR FRONT DOOR
The most effective means of protecting your valuable data in Perforce is to operate it only on a well-secured network.  Perforce is not a security product, but many excellent security products and technologies can be employed to help secure Perforce.  Enterprise-grade VPN solutions encrypt traffic and help prevent unauthorized access.  VPNs help guard the Perforce server and communications channels to all potential clients.  Disk encryption technologies help secure end points, such as vulnerable laptops where Perforce workspaces may have sync’d files.

PERFORCE SECURITY BASICS
Please review this article in the Perforce Knowledge Base:

http://kb.perforce.com/article/1173/basics-of-perforce-security

This is a good starting point, but there are many other factors to consider.

PROTECT THE END POINTS
Your intellectual property is likely sitting on a number of machines — build servers, QA environments, developer workstations, laptops, etc.  Do you have Perforce proxies in place?  If so, that’s another endpoint to secure.  Do you have High Availability and/or Disaster Recovery solutions in place?  More end points to secure.

TAKE ADVANTAGE OF PERFORCE SECURITY STRENGTHS
Perforce can work with network infrastructure to further deflect attacks.  Perforce’s protections mechanism can limit access to groups of people by IP address.  You can deny access to people connecting over a VPN (which will have IP addresses in a predictable range), as opposed to those connecting directly from within a secured, trusted network environment.

Out of the box, Perforce runs in a friendly, trusting, open mode suitable for demonstration purposes.  In secure commercial production environments, you’ll want to consider disabling certain features, such as automatic account creation and “Security Level 0″.

Many SCM systems do not have the capability to keep an audit trail. We suggest that if you are not currently taking advantage of P4AUDIT, you may consider doing so now.  If you operate Perforce on Windows, you may want to ensure that Perforce runs as a non-privileged user. Each of these changes can have convenience, productivity, performance,
and other implications, which should be balanced against the net benefit of security.

Once again, please review the security article in the Perforce Knowledge Base:

http://kb.perforce.com/article/1173/basics-of-perforce-security

If you have any questions, please contact Perforce Technical Support (support at perforce.com).

P4toDB exposes some interesting data that was not previously available. Two such tidbits are the strength of user passwords and the expiration date of logins. This post will show some simple queries to extract the information from the `user` table using the MySQL command-line.

<EDIT> As a point of clarification, the password strength data as discussed here is only available via a Perforce server super-user account. See Access Levels Required by Perforce Commands for some more context on the different permission levels. P4toDB requires a super-user account on the Perforce server, but stores the replicated data on the SQL server, so be mindful of the data you replicate and the users who have access to it via SQL permissions.</EDIT>

The source Perforce server instance in this example has four users: Alice with no password, Bob and Zoe with weak passwords and Carlos with a strong one. Zoe is in a group with a non-default login expiry time. Note that you can enforce strong passwords by having your server at security level 2.

First I’ll talk about password strength. Here’s a query to list the users without a password set:

mysql> SELECT `user`, `email` FROM `user` WHERE `password` = '' ;
+---------+------------------+
| user    | email            |
+---------+------------------+
| Alice   | Alice@hostname   |
+---------+------------------+

Now one for those with weak passwords:

mysql> SELECT `user`, `email` FROM `user` WHERE `password` <> '' AND `strength` = 0;
+---------+----------------+
| user    | email          |
+---------+----------------+
| Bob     | Bob@hostname   |
| Zoe     | Zoe@hostname   |
+---------+----------------+

A strong password is defined as having:

… at least eight characters long, and at least two of the following are true:
- contains uppercase letters.
- contains lowercase letters.
- contains non-alphabetic characters.

And, can be queried as such:

mysql> SELECT `user`, `email` FROM `user` WHERE `strength` = 1;
+--------+-----------------+
| user   | email           |
+--------+-----------------+
| Carlos | Carlos@hostname |
+--------+-----------------+

Perhaps finding out what your user-base has for password strength will be useful to you. Also, if you take the `user` data along with a technique like I illustrated in versioning ‘p4 counters’, you could implement a password hash history or aging mechanism. Typically people use External Authentication Triggers for that task, though.

Read More

P4toDB presents a lot of opportunity to do interesting things with your data that was not possible before. For instance, many SQL servers have a trigger system (similar to what the Perforce server provides) that you can take advantage of to do more or less arbitrary things.

In this example, I’ll illustrate how to make MySQL triggers that version the history for the ‘p4 counters’ command. Counters are an unversioned key/value store on the Perforce server. Basic counter usage does not require history, but it might be nice to have in some situations.

Note that when doing any work that involves writing to the P4toDB-controlled database, that it’s important to avoid modifying the replicated data itself, as P4toDB expects it to be the way it left it. One can also break replication or make it slow via a trigger, so beware.

First up, we need a new table to store the data in. The `name` column is the key and will never change. The only new data that we add to this table is the time when the `value` was modified. I’m assuming you’ve already populated the database and replication is currently running, and that you’ve got the MySQL command-line tool open with administrative access.

CREATE TABLE `counter_history` ( `name` NVARCHAR(2000), `value` LONGTEXT, `modified` DATETIME );

Now we’ll create three new triggers, one to record newly added counters, one for updates to existing ones, and one that runs when a counter is removed. Two commands you’ll need to know about when playing around with these things are SHOW TRIGGERS; and DROP TRIGGER `trigger_name`;.

Here’s the trigger to catch newly-added counters. MySQL presents the old and new values for a row with the “OLD” and “NEW” variables. Note that you should use the “AFTER” trigger, not “BEFORE”, since there’s less opportunity to accidentally modify the replicated data.

DELIMITER //
CREATE TRIGGER `counter_history_insert_trigger` AFTER INSERT ON `counters` FOR EACH ROW BEGIN
INSERT INTO `counter_history` VALUES ( NEW.name, NEW.value, NOW() );
END//
DELIMITER ;

The trigger to catch modified counters has some extra logic. The job, jobreview, journal, logger and review counters are all reserved by the Perforce server and aren’t very interesting to track. There are others I’ve ommitted, like the upgrade counter, which might be worth recording.

Read More

I’m pleased to announce beta availability of a new tool for administrators called P4toDB. P4 -> to -> DataBase is a one-way replicator of Perforce metadata into an SQL database. This affords you more accessible metadata, and all the amenities of the SQL toolchain such as an existing employee skillset, the SQL server itself, ODBC drivers, integrations with reporting tools, programming libraries and so forth. You can also replicate multiple source Perforce servers into a single destination SQL database, so the sky’s the limit for what you can do with it!

Read More

As they say on the old maps: Here be dragons.

Looking at the typical Linux command line tools like ls, I noticed that the output of these commands is normally in colour; this makes the output much easier to scan. So I wondered: could this be done to the output of the Perforce client P4 as well? The search for an answer took me on an interesting journey I’d like to share with you.

Client or Server?

The first question I had to ask myself was: where do I add the colour (excuse my British English spelling), client or server? I already knew that I wanted to simply add ANSI control sequences to the output, but creating a special client for it seemed tedious. Then I analysed what the server actually sends to the client (try “p4 -vrpc=5 info” for a laugh) and realized that I had all the building blocks already in my hand:

What the server returns are format strings in the following form:

RpcRecvBuffer fmt0 = Server date: %serverDate% %serverTimeZone%
RpcRecvBuffer serverDate = 2010/01/08 13:12:12
RpcRecvBuffer serverTimeZone = +0000 GMT Standard Time

What I wanted to colour in were those place holders surrounded by % characters. If only there was a way to change the format string in the server and I’d be done. Turns out, there is a simple way that does not require any server changes.

Read More

That building in the background is (was?) my data center!

With 2009.2, achieving High Availability (HA) and Disaster Recovery (DR) objectives with Perforce made one big step away from the realm of “advanced custom solution” and toward commodity solutions.

Over the years, Perforce customers have deployed Perforce to meet  requirements. Having become familiar with the Perforce journaling mechanism, they found ways to duplicate Perforce metadata updates in real-time to a separate, replicated copy of the Perforce databases. This approach made possible deployment options such as “hot spare” standby/backup servers, warm spare DR servers, and read-only replica servers.  Some custom solutions were presented by customers at Perforce user conferences over the years.

The p4jrep and later the P4jtail utilities evolved in the Public Depot. These utilities worked in some environments, but had limitations that kept them from being widely applicable.   Windows environments aren’t supported, they don’t work with Unicode-enabled servers, and aren’t “officially” supported by Perforce Technical Support.

Enter Perforce 2009.2. Perforce 2009.2 offers new tools to simplify and commoditize HA/DR solutions: p4 replicate, and p4 export. The p4 export command handles raw metadata replication, and provides capabilities such as filtering — useful if you want to, for example, populate a read-only replica stripped of db.have entries. The p4 replicate command can be thought of as a wrapper to p4 export that handles the classic “full replication” scenario used for HA/DR solutions.

These new features are part of the core Perforce server and are fully supported.  They provide a reliable, supported, cross-platform solution for replicating Perforce metadata.  If you’re doing DR you’ll still need to replicate your versioned files.  Ubiquitous tools like rsync (Linux) or ROBOCOPY (Windows) suffice in many environments.  For some environments, more sophisticated technologies such as block-level replication solutions and WAN replication technologies are brought to bear to keep versioned files in sync on remote replicas.

In Consulting, we’ve seen a lot of interest in HA/DR solutions in the past year or so.  With new tooling available in 2009.2, you can bet you’ll hear more about HA/DR in the future.  You’ll hear more from me, and maybe something at the Perforce User Conference in London in 2010.  See you there, maybe?

I recently had the urge to write a Perforce plug-in for the popular free source code editor Notepad++, the result of which you can find in the public depot here: NppPerforcePlugin.

Not wanting to wrap a call to “p4.exe”, I decided to use the Perforce C++ API. This turned out to be surprisingly simple, so I want to share what I learned from using the API to encourage you, my esteemed readers, to write your own plug-ins and tools.

Read More

Hi, me again.

You might have seen my last post on the C++ API and downloaded the Notepad++ plug-in from here: NppPerforcePlugin. If you installed the plug-in and/or looked at the code, you ought to have noticed that there are set of menu options invoking P4V directly (if you happen to have P4V.exe in your path).

A few of these commands have been in the public domain for a while, such as how to invoke Timelapse View™, but you might be interested in what else is available.

The full syntax to call P4V from the command line and immediately invoke a particular component is

p4v.exe -p <port> -c <client> -u <user>
  [-C <charset>] [-P <password>] [-cmd "<command> <file>"]

Port, client and user are mandatory (in that order), everything else is optional. If a command is given, quotes have to be placed around the command and the file name so that both are passed as a single parameter.

Here is the full list of all supported commands (these commands are undocumented and unsupported and subject to change in future versions without notice):

For example:

p4v.exe -p 1666 -c myws -u sven -cmd "properties //depot/myproject/myfile.scala"

This will work with P4V 2009.1 and P4V 2009.2. Enjoy

Happy hacking

Sven Erik

Yes, it’s that time again, and preparations are well under way for the annual Perforce User Conference. This year’s conference takes place on the 11th & 12th of May at the Savill Court Hotel in Old Windsor, just a few miles from Windsor Castle, and conveniently, Heathrow airport.

If you’re a Perforce customer with a tale to tell and you think you might like to speak at the conference, please get in touch because there are still a few days left before the call for papers closes. All we need is a short abstract describing the topic you’d like to speak about; just email it to us at conference@perforce.com and we’ll get right back to you!

If you’re a Perforce customer, and you’ve never attended one of our conferences before, I’d urge you to come along – it’s not a dry, dusty conference full of marketing hype; our conferences are a chance for us to get to know our customers, and for them to get to know us, so there will be people from all across Perforce, including VP’s, senior managers, developers, and representatives from our Licensing and Technical Support teams. We’re all keen to know how you’re getting on with Perforce; we want to know the successes of course, but also the failures, because we’re always looking for ways to make our product even better.

Inside Perforce, the Conferences are always keenly anticipated, and there’s a lot of interest in who the speakers will be this year. Of course, with 2009.2 just out of the door, and some great stuff in development at the moment, we already have some very interesting things that we’ll be talking about!

If you’d like more information, visit the Conference page on our website. Hope to see you there!

In recent visit with a customer, I ran across a situation that I thought warranted a blog entry. This user had a single directory where they were making all of their branches on their server, and the directories they were branching to this location contained 100,000 plus files per branch. As you can imagine, the number of files in this directory tree became large quickly. By itself, this wasn’t a problem, but many users didn’t want this directory in their view, so they added an exclusionary mapping to their workspace view to hide this directory. This is where the problem comes in. The way Perforce builds the client maps causes the server to end up scanning this excluded directory when the p4 dirs command is run on the workspace. Since the directory had so many files in it, it was causing the server to pause for ~15 seconds every time the p4 dirs command was run. It was an easy fix to solve the problem, but not an obvious one for the customer. The fix was to remove the exclusionary mapping, and use specific inclusionary mappings to get only the directories the users wanted in their workspace view. The p4 dirs command returned instantly with this change.  The customer also added some triggers to give users a default workspace view that did not use exclusionary mappings and also to warn users if they added an exclusionary mapping to their view.

So, in summary, their are two things to take away from this story:

1. – Don’t use a single directory on the server for all your branches.

2. – Try to avoid exclusionary mappings when possible in your workspace views, and also in your protections table. It is much better to have many inclusionary mappings than a single exclusionary mapping.

Home

• About

  • p4 blog
  • Disclaimer

• Categories

  • Administration
    • Disaster Recovery
    • High Availability
  • Agile
  • ALM
  • Best practices
    • Security
  • Branching
  • Branching Strategy
  • Certification
  • Collaboration
  • Consulting
    • Automated Lifecycle Management
    • Consultant's Toolkit
  • Documentation
  • Eclipse
  • Events
    • User Conference 2009
    • User Conference 2010
  • Java
  • Mashups
  • Migrations
  • Multi-platform
  • New features
  • P4V
  • Performance
  • Philosophy
  • Programming
    • C++ API
  • Releases
  • Scripting
  • Server
  • Soapbox
  • Social media
  • Tips and Tricks
  • Training
  • UI Design
  • Uncategorized
  • visualization
  • Web Services

• Archives

  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009

• Authors

  • Alan Teague (1)
  • Bill Baffy (1)
  • Dave Robertson (4)
  • Dan Steele (1)
  • James Creasy (2)
  • Jason Novecosky (1)
  • Jason Gibson (15)
  • Julia Angell (1)
  • Kevin Sawicki (4)
  • Laura Wingerd (2)
  • Marc Wensauer (1)
  • Matt Attaway (1)
  • Michael Bishop (1)
  • Nellie Lemonier (1)
  • Rachael Fish (2)
  • Rusty Jackson (7)
  • Stewart Lord (2)
  • Sven Erik Knop (11)
  • Tony Corman (2)
  • Tony Smith (3)
  • Tony Vinayak (4)
  • Tom Tyler (13)
  • Bill White (1)