Limited Time Offer!

For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!

Enroll Now

Shelving operations in P4V

I found very good feature in perforce about Shelving operations in P4V. This is something id deport is not ready to check in the src code due to release or code freeze, still you can store changes in depot without check in.

Tagged : / / / /

Perforce Central Authorization Server: P4AUTH

Perforce Central Authorization Server: P4AUTH

Author: Rajesh Kumar
Email Id: rajesh@scmGalaxy.com

 

Contents
Problem Statement:
Solution:  P4Auth
Advantage of Perforce centralized authorization server
Overview of P4Auth
How to Implement?
Verification: centralized authorization server
Configure outer server to listen central authorization server
Commands to the central server
Limitations and notes
FAQ
Reference:

Problem Statement:

Prepare a report on Perforce Servers Automation which consists of following requirement.
We need to develop a centralized web based tool which will control and manage all the perforce Servers instance and Minimize the time spending on admin work related to following…
1. User Creation /Deletion
2. Group Creation / Deletion
3.  Assigning Depot Access to group such as modifying protect table

Solution:  P4Auth

The feature (centralised server) you are looking for has been available Undocumented for several years. However since the 2010.2 release, it is now fully supported and documented.
In multiple perforce Server scenario, we can configure them to retrieve protections and licensing data from a centralized authorization server.

Advantage of Perforce centralized authorization server

  • By using a centralized server, we are freed from the necessity of ensuring that all your servers contain the same users and protections entries.

  • If a user does not exist on the central authorization server, that user does not appear to exist on the outer server.
  • If a user exists on both the central authorization server and the outer server, the most permissive protections of the two lines of the protections table are assigned to the user.

  • We can use any existing Perforce Server in your organization as your central authorization server.
  • The license file for the central authorization server must be valid, as it governs the number of licensed users that are permitted to exist on outer servers.

 

Overview of P4Auth

  • Allow multiple edge servers to authenticate off a central server.
  • Introduced in 2002.2. However since the 2010.2 release, it is now fully supported and documented.
  • Undocumented and officially unsupported till 2010.1
  • See ‘p4 help undoc’ for documentation.
  • Shares protections, groups, users, and passwords with the central server.
  • Servers need constant access to the central server. If the network connection is down no commands can be authenticated.

How to Implement?

To configure a Perforce Server to use a central authorization server, set P4AUTH before starting the server, or specify it on the command line when you start the server. Setting P4AUTH by means of a p4 configure set P4AUTH=server:port command takes effect immediately.

  • Pass -a to p4d at startup point to the central server or set P4AUTH=<ip:port> and restart the server.
  • Protections table entries that use IPs need to be Prefixed with proxy- for clients connecting through edge servers.
  • The user ‘remote’ account needs to be configured on the central auth servers.

 

Verification: centralized authorization server

If your server is making use of a centralized authorization server, the following line will appear in the output of p4 info:

Authorization Server: host:port

Where host:port refer to the host and port number of the central authorization server.

Configure outer server to listen central authorization server

In the following example, an outer server (named server2) is configured to use a central authorization server (named central). The outer server listens for user requests on port 1999 and relies on the central server’s data for user, group, protection, review, and licensing information. It also joins the protection table from the server at central:1666 to its own protections table.

For example:
p4d -In server2 -a central:1666 -p 1999

Commands to the central server

 

Central authorization server, outer servers forward the following commands to the central server for processing:

Command Forwarded? Notes
p4 group Yes Local group data is derived from the central server.
p4 groups Yes Local group data is derived from the central server.
p4 passwd Yes Password settings are stored on, and must meet the security level requirements of?, the central server.
p4 review No Service user (or remote) must have access to the central server.
p4 reviews No Service user (or remote) must have access to the central server.
p4 user Yes Local user data is derived from the central server.
p4 users Yes Local user data is derived from the central server.
p4 protect No The local server’s protections table is displayed if the user is authorized (as defined by the combined protection tables) to edit it.
p4 protects Yes Protections are derived from the central server’s protection table as appended to the outer server’s protection table.
p4 login Yes Command is forwarded to the central server for ticket generation.
p4 logout Yes Command is forwarded to the central server for ticket invalidation.

Limitations and notes

         

  • All servers that use P4AUTH must have the same unicode setting as the central authorization server.
  • Setting P4AUTH by means of a p4 configure set P4AUTH=server:port command takes effect immediately. You do not have to stop and restart the outer server.
  • To ensure that p4 review and p4 reviews work correctly, you must enable remote depot access for the service user (or, if no service user is specified, for a user named remote) on the central server.
  • To ensure that the central server correctly distinguishes forwarded commands from commands issued by trusted, directly-connected clients, you must define any IP-based protection entries by prepending the string “proxy-” to the IP address.
  • Protections for non-forwarded commands are enforced by the outer server and use the plain client IP address, even if the protections are derived from lines in the central server’s protections table

FAQ

When we create Centralized Authorization server, how does it impact on performance, considering perforce servers are located in multi-site location such as India-USA-Canada-Australia etc etc?
High latency network between the centralised server and outer servers may have Some performance impact. Perforce team have not conducted any performance Benchmark test for this. We need to look into this and find out feasible solution for this.
Many commands such as group, groups, passwd, review, reviews, user, users, protect, protects, login, logout is hitting to  central server, Does it create huge process queue in central perforce server imagining min. 500 user is using these commands in one point of time? How this will be tackled?
Perforce is able to handle a large number of requests. Therefore from a performance point of view, the bottleneck will be the centralised server hardware. As I mentioned, some customers have been using centralised servers for many years and I am not aware of anyone having significant performance problem because of this feature.
Can I imagine a web based tool which can administer 100’s of perforce server instance and where employee can browse all listed depot and if they need access (read/Write/Super) on any depot/branch/codeline, they can raise a request through given interface in web tool and this request directly goes to admin(Super) of that particular Server Instance in form of an email, and he can reject/approve this access. As soon as he accept the request, new access definition should be added in perforce protection table?

This is not something you can have “out of the box” but this is certainly something that you should be able to implement using our p4php and p4perl api:

Reference:

http://www.perforce.com/perforce/r10.2/manuals/p4sag/03_superuser.html#1093172
http://www.perforce.com/perforce/r10.2/manuals/cmdref/env.P4AUTH.html

For more info.

http://www.scmgalaxy.com/forum/perforce/

Tagged : / / / / / / /

Thanks for the Invitation to the PerForce Group

Thanks for the Invitation to the PerForce Group.

Thanks for the Invitation to the PerForce Group.

 

However, I have no idea what to discuss here as I have never used PerForce and doubt very much I ever will.  After 10 years of experience with ClearCase and ClearQuest, I have been unemployed for 18 months now, and my COBRA ends this Friday, May 6th.  I got very tired of applying for jobs where I have been run over by the technology revolution.  I am also tired of recruiters who contact me and do not do their homework.  They are wasting their time, mine. and that of the hiring manager.  For that reason I needed to look outside the box and am now undergoing PMP training.  Later I will be taking the PMP Certification Exan.

  • Rajesh Kumar

    Rajesh Kumar 

    Thats good news indeed that you are going through PMP certification.

    However, I guess this discussion can be made on group Discussion place instead of blog place.

    What you say?

  • mfeighner

    mfeighner 

    Yes, that would be in order.  I posted here only because that is where I was invited.

  • Rajesh Kumar

    Rajesh Kumar 

    Hi mfeighner,

    its been long time to see you post here. Hows life going on? Where you have joined recently?

Tagged : / / / / /

How to Setup p4 in Linux / Unix

How to Setup p4 in Linux / Unix
Well many people have these questions to me that they are facing issues setting up p4 client in Linux or Unix. The Solution is pretty much straight forwards but sometimes we miss some of things which delay the setup process.
Here I have tried to points out these already available on Perforce Knowledge base site.
Download and Installations:

1. Download the p4 executable file from the Perforce web site:

http://www.perforce.com/perforce/downloads/index.html 
The Perforce client programs are typically downloaded to /usr/local/bin.

2. Make the p4 file executable (chmod +x p4)

Perforce Configuration and Workspace Setting
Method 1
Using Config Files:
Config files are text files containing Perforce settings that are in effect for files in and below the directory where the config file resides. Config files are useful if you have multiple client workspaces on the same machine. By specifying the settings in config files, you avoid the inconvenience of changing system settings every time you want to work with a different work-space.
To use config files, you define the P4CONFIG environment variable, specifying a file name (for example, .p4config). When you issue a command, Perforce searches the current working directory and its parent directories for the specified file and uses the settings it contains (unless the settings are overridden by command-line flags).
P4CONFIG = .p4config
Each setting in the file must be specified on its own line, using the following format:
setting=value

The following settings can be specified in a config file.

Setting Description
P4CLIENT Name of the current client workspace.
P4EDITOR The editor invoked by those Perforce commands that use forms.
P4HOST Hostname of the client workstation. Only useful if the Host: field of the current client workspace has been set in the p4 client form.
P4PASSWD Supplies the current Perforce user’s password for any Perforce client command.
P4PORT The host and port number of the Perforce server or proxy with which to communicate.
P4USER Current Perforce user name.

For details about these settings, refer to the Perforce Command Reference.

Example: Using config files to handle switching between two workspaces
Ona switches between two workspaces on the same machine. The first workspace is ona-ash. It has a client root of /tmp/user/ona and connects to the Perforce server at ida:1818. The second workspace is called ona-agave. Its client root is /home/ona/p4-ona, and it uses the Perforce server at warhol:1666.

Rama sets the P4CONFIG environment variable to .p4config. She creates a file called .p4config in /tmp/user/rama containing the following text:
P4PORT=ida:1818
P4CLIENT=ona-ash

She creates a second .p4config file in/home/rama/p4-ona. It contains the following text:
P4PORT=warhol:1666
P4CLIENT=ona-agave

Any work she does on files under /tmp/user/rama is managed by the Perforce server at ida:1818 and work she does on files under /home/rama/p4-ona is managed by the Perforce server at warhol:1666.

Method 2: Environment Variable Setting

To configure server connection settings using environment variables, set P4PORT to host:port, as in the following examples.

If the server is running on and is listening to port set P4PORT to
your computer 1666 localhost:1666
perforce 1666 1666

Example:
export P4PORT=X.X.X.X\:1667
export P4PASSWD=pass
export P4USER=user
export P4CLIENT=Sonar
export PATH

Defining client workspaces 
To define a client workspace:

1. Specify the workspace name by setting P4CLIENT; for example, on a UNIX system:

$ P4CLIENT=bruno_ws ; export P4CLIENT

 

2.

Issue the p4 client command.

Perforce displays the client specification form in your text editor.

3. Specify (at least the minimum) settings and save the specification.

The minimum settings you must specify to configure a client workspace are:

 

Workspace name

The workspace name defaults to the client machine’s hostname, but a client machine can contain multiple workspaces. To specify the effective workspace, set P4CLIENT.

Client root

The client root is the top directory of your client workspace, where Perforce stores your working copies of depot files. Be sure to set the client root, or you might inadvertently sync files to your client machine’s root directory.

Note:
To specify server settings on the command line, use the -p flag. For example:
p4 -p localhost:1776 sync //depot/dev/main/jam/Jambase

Reference:
http://www.perforce.com/perforce/doc.current/manuals/p4guide/02_config.html#1069873 
http://www.perforce.com/perforce/doc.current/manuals/p4guide/02_config.html#1071378 
http://www.perforce.com/perforce/doc.current/manuals/p4guide/01_install.html#1070774

Tagged : / / /

Perforce Customization To Revert Changelist

Perforce Customization To Revert Changelist

Attachech Python File: Download here Perforce Python script to revert Changelist

Purpose

In Perforce if we check in any change list and in case if we want to revert the change list. Perforce does not have feature to Revert Change List.

We have to do it manually by using following steps.

1) Take a change list version which is predecessor of the current one which we want to revert
2) Do head sync to that change list revision.
3) Check out the files which we want to revert. Resolve them and check in

But we can very well eliminate the above three manual steps and automate the process of Reverting Change list by Customizing Perforce to have Revert Change List Feature.
This feature will be very useful if the Changelist which we want to revert have large number of files

Risk
There is no Risk with this feature because the changelist which we revert are not directly submitted. When we do a Revert Change List a new Change List will be created and we have the capability to resolve the conflict if there are more than one Revision for that file.

Required Software Version
Download Recent version of Python from http://www.python.org/download/ and   Install Python and set the path for library files of python in the environment variables just like java.

Software Program Required for Customization

I have downloaded Python Program from the following URL which will help in Reverting Change List. (http://www.tilander.org/aurora/2007/06/reverting-a-perforce-changelis.html).

Perforce Client Side Changes for Customization

Following Customization needs to be done to add Revert ChangeList option in  perforce.

1.    Open Perforce
2.    Go to Tools >> Customize
3.    Click Add Button
4.    Enter Name as RevertChangeList, Give the location of the Python Program
5.    Give the argument as -c $c -p $p -u $u %c
C – Client
P –  Port Number
U –User

image

Note : Make sure “Close window upon exit” is not checked initially for the first time. So that we can see the success message in console.
In case if it is checked. If the Python Program fails. Then we may not be able to see the message.

6.    Once this is done then Click View Submitted Change List. Right click the change list which you want to revert and click RevertChangeList.

 

image

7.    Once this is done all the files that were reverted will be available under Default Changelist.
8.    Create New Changelist and move all from Default Changelist.
9.    Check the whether they are reverted properly. If there are some version conflict then resolve them and checkin.
10.    Using this feature I had reverted changelist Number : 163806
11.    Outside Perforce also this utility can be run. We can also run the utility from windows prompt by giving following command

Command :
p4revert.py -c <Client> -p <Port> -u <User> <ChangeList>

Example:
p4revert.py -c Mramchandran -p 10.10.50.201:1666 -u jayesh 163806

This is not tested. It is also convenient to use through perforce.

Troubleshooting

1.If my Revert ChangeList contains file say A.java and that file is also part of another change list in the client machine. Then the file A.java will not be reverted.
2. Always check the number of files that are present in the changelist is same as same number of files that are present in the new change list once RevertChangeList is done.

Limitations
1. The only limitation this tool has is the Revert ChangeList customization is written in Python. It will be good if we can understand the logic and convert to Java.

References

1. http://www.tilander.org/aurora/2007/06/reverting-a-perforce-changelis.html
2. http://kb.perforce.com/?article=014
3. http://www.python.org/download/

Contributed Made by: Ramchandran M

Tagged : / / / /

Ways to Pass Password in Triggers file or Script file in Perforce

Option 1
If your Perforce server is set to security level 2 or lower you can have your trigger script run as the same user every time (typically a “background” user). Then, either have the server’s P4PASSWD environment variable set to the background user’s password,

Option 2
You can also use the -P flag to specify the password with the P4 commands issued by the script.

Option 3
You can echo the password and pipe it to the login command. Note that there is no space between the password and the pipe symbol.

echo <password>| p4 login

Option 4
If you do not want to place a password in the script, you can use a text file containing the password. Make sure this password file has appropriate read and write privileges.

p4 login < password.txt

Option 5
A more secure method is to use ticket based authentication and a group to keep a background user “logged in” at the Perforce server:

1. Create a group:

p4 group always_on

2. Add your background user to the “Users” field.

3. Change the timeout from the default setting (12 hours), which is set in seconds. The new value depends on the server version:

# 2008.1 and later: Set this value to “unlimited”. A timeout value of zero is no longer accepted.

# 2005.1 to 2007.3: Set this value to zero.

# 2004.2 and earlier: Set this to a very large value — but not too large, as some server versions do not handle situations where the timeout is set to exceed the “Unix Epoch”, which is approximately in the year 2038. A safe value is 315532800 seconds, which is about 10 years.

# Save the group.

# In your trigger script, log the background user in and run the trigger once.

echo password| p4 -p server:port -u username login

# If the trigger runs properly, you can remove the password line.

The user now remains logged in. Since this is ticket based authentication, they remain logged in even if the server is shut down or the hardware is rebooted.

Tagged : / / /

Perforce Command Line Global Options

<!– .style1 { font-size: 24px; font-weight: bold; } –>

Perforce Command Line Global Options

Global options for Perforce commands; these options can be supplied on the command line before any Perforce command.

Syntax
p4 [-cclient -ddir -Hhost -pport -Ppass -uuser -xfile -Ccharset -Qcharset -Llanguage] [-G] [-s] [-z tag] cmd [args …]
p4 -V
p4 -h

 

Options
 
-c client
Overrides any P4CLIENT setting with the specified client name.
-d dir
Overrides any PWD setting (i.e. current working directory) and replaces it with the specified directory.
-G
Causes all output (and batch input for form commands with -i) to be formatted as marshalled Python dictionary objects. This is most often used when scripting.
-H host
Overrides any P4HOST setting and replaces it with the specified hostname.
-p port
Overrides any P4PORT setting with the specified port number.
-P pass
Overrides any P4PASSWD setting with the specified password.
-s
Prepends a descriptive field (for example, text:, info:, error:, exit:) to each line of output produced by a Perforce command. This is most often used when scripting.
-u user
Overrides any P4USER, USER, or USERNAME setting with the specified user name.
-x file
Instructs Perforce to read arguments, one per line, from the specified file. If file is a single hyphen (-), then standard input is read.
-C charset
Overrides any P4CHARSET setting with the specified character set.
-Q charset
Overrides any P4COMMANDCHARSET setting with the specified character set.
-L language
This feature is reserved for system integrators.
-z tag
Causes output of many reporting commands to be in the same tagged format as that generated by p4 fstat.
-V
Displays the version of the p4 client program and exits.
-h
Displays basic usage information and exits.

 

Usage Notes
Be aware that the global options must be specified on the command line before the Perforce command. Options specified after the Perforce command will not be interpreted as global options, but as options for the command being invoked. It is therefore possible to have the same command line option appearing twice in the same command, being interpreted differently each time.
For example, the command p4 -c anotherclient edit -c 140 file.c will open file file.c for edit in pending changelist 140 under client workspace anotherclient.
The -x option is useful for automating tedious tasks; a user adding several files at once could create a text file with the names of these files and invoke p4 -x textfile add to add them all at once.
The -x option can be extremely powerful – as powerful as whatever generates its input. For example, a UNIX developer wishing to edit any file referring to an included file.h file, for instance, could grep -l file.h *.c | cut -f1 -d: | p4 -x – edit.
In this example, the grep command lists occurrences of file.h in the *.c files, the -l option tells grep to list each file only once, and the cut command splits off the filename from grep’s output before passing it to the p4 -x command.
The -s option can be useful in automated scripts.
For example, a script could be written as part of an in-house build process which executes p4 -s commands, discards any output lines beginning with “info:”, and alerts the user if any output lines begin with “error:”.
Python developers will find the -G option extremely useful for scripting. For instance, to get a dictionary of all fields of a job whose ID is known, use the following:
job_dict = marshal.load(os.popen(‘p4 -G job -o ‘ + job_id, ‘rb’))
In some cases, it may not be intuitively obvious what keys are used by the client program. If you pipe the output of any p4 -G invocation to the following script, you will see every record printed out in key/value pairs:
Tagged : / / / / /

Perforce Command Line

Command

Description

p4 add
Open file(s) in a client workspace for addition to the depot.
p4 admin
Perform administrative operations on the server.
p4 branch
Create or edit a branch specification and its view.
p4 change
Create or edit a changelist specification.
p4 changelists
List submitted and pending changelists.
p4 changelist
Create or edit a changelist specification.
p4 client
Create or edit a client workspace specification and its view.
p4 clients
List all client workspaces currently known to the system.
p4 delete
Open file(s) in a client workspace for deletion from the depot.
p4 depot
Create or edit a depot specification.
p4 depots
Display a list of depots known to the Perforce server.
p4 describe
Provides information about changelists and the changelists’ files.
p4 groups
List groups of users.
p4 group
Add or delete users from a group, or set the maxresults, maxscanrows, and timeout limits for the members of a group.
p4 have
List files and revisions that have been synced to the client workspace
p4 info
Display information about the current client and server.
p4 integrate
Open files for branching or merging.
p4 integrated
Show integrations that have been submitted.
p4 job
Create or edit a defect, enhancement request, or other job specification.
p4 jobs
List jobs known to the Perforce server.
p4 label
Create or edit a label specification and its view.
p4 labels
Display list of defined labels.
p4 lock
Lock an opened file against changelist submission.
p4 login
Log in to a Perforce server by obtaining a ticket.
p4 logout
Log out of a Perforce server by removing or invalidating a ticket.
p4 passwd
Change a user’s Perforce password on the server.
p4 rename
Renaming files under Perforce.
p4 resolve
Resolve conflicts between file revisions.
p4 revert
Discard changes made to open files.
p4 set
Set Perforce variables in the Windows registry.
p4 submit
Send changes made to open files to the depot.
p4 sync
Copy files from the depot into the workspace.
p4 tag
Tag files with a label.
p4 triggers
Edit a list of scripts to be run conditionally whenever changelists are submitted, forms are updated, or when integrating Perforce with external authentication mechanisms.
p4 user
Create or edit Perforce user specifications and preferences.
p4 users
Print a list of all known users of the current server.
p4 verify
Verify that the server archives are intact.
p4 workspace
Create or edit a client workspace specification and its view.
Tagged : / / / / /