Starting: 1st of Every Month 
+91 8409492687 
Contact@DevOpsSchool.com
The Perforce Broker (P4Broker) enables you to restrict the commands that can be executed, or redirect specific commands to alternate (replica or edge) Perforce servers.
The Perforce Broker is a server process that mediates between Perforce client applications and Perforce servers, including proxy servers.
Use Case Of Perforce Broker aka Helix Broker
- Separate Helix Server aks Perforce server replica for Read and Write operations –
Perforce client applications can connect to a proxy server that connects to the broker, which then connects to a Perforce server. Or, Perforce client applications can connect to a broker configured to redirect reporting-related commands to a read-only replica server, while passing other commands through to a master server. - Load-balancing – You can use a Perforce Broker aka Helix Broker to solve load-balancing as well
- To implement Security – You can use a Perforce Broker aka Helix Broker to solve security related issues as well. To reject the some of the p4 command request which is not allowed.
- To Resrict the size of the Changelist – You can use a Perforce Broker aka Helix Broker to reject the changelist if size is huge.
How to Install the Perforce Broker aka Helix Broker?
Download the p4broker executable from the Perforce website,
Copy it to a suitable directory on the host (such as /usr/local/bin), and ensure that the binary is executable:
[code]$ chmod +x p4broker[/code]
How to run the Perforce Broker aka Helix Broker
[code]$ p4broker -c config_file(p4broker.conf)[/code]
[code]</pre>
<strong>How to verify the Perforce Broker aka Helix Broker</strong>
<pre>[code]$ p4 info
$ p4 broker[/code]
The general syntax of a command handler specification is outlined in the sample broker.conf:
[code]command: commandpattern
{
# Conditions for the command to meet; (optional)
flags = required flags;
user = required user;
workspace = required client workspace;
prog = required Perforce client application;
version = required version of client application;
# What to do with matching commands (required)
action = pass | reject | redirect | filter | respond ;
# How to go about it
destination = altserver; # Required for action = redirect
execute = filter program; # Required for action = filter
message = message; # Required for action = reject and
# action = respond. Otherwise optional
}[/code]
For example, if you’d like to prevent users from using the 2018.2 P4V to access the server, you can use the following:
[code]command: .*
{
prog = P4V\/.*\/2018\.2\/.*;
version = v77;
action = reject;
message = “The 2018.2 P4V is not allowed to connect to this server.”;
}[/code]
Using P4Broker to redirect read-only commands.
https://community.perforce.com/s/article/1253
Reference
https://www.perforce.com/perforce/r16.2/manuals/p4dist/chapter.broker.html
https://www.perforce.com/perforce/doc.current/manuals/p4dist/Content/P4Dist/chapter.broker.html
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| # Add the Perforce packaging key to your APT keyring: | |
| $ wget -qO - https://package.perforce.com/perforce.pubkey | gpg --dearmor | sudo tee /usr/share/keyrings/perforce.gpg | |
| # If you are required to use an older OS that does not support the above method, you can use: | |
| $ wget -qO - https://package.perforce.com/perforce.pubkey | sudo apt-key add - | |
| # Create a file called /etc/apt/sources.list.d/perforce.list with the following line: | |
| deb [signed-by=/usr/share/keyrings/perforce.gpg] https://package.perforce.com/apt/{os} {distro} release | |
| # Add Perforce's repository to your APT configuration: | |
| Create a file called /etc/apt/sources.list.d/perforce.list with the following line: | |
| Where {os} is replaced with ubuntu, and {distro} is replaced by one of the following: precise, trusty, xenial, bionic, or focal | |
| $ deb [signed-by=/usr/share/keyrings/perforce.gpg] https://package.perforce.com/apt/{os} {distro} release | |
| # Run apt-get update | |
| $ apt-get update | |
| # Install P4vD Helix Perforce Broker | |
| $ apt-get install helix-p4dctl | |
| $ apt-get install helix-cli | |
| $ apt-get install helix-broker | |
| # https://www.perforce.com/manuals/p4sag/Content/P4SAG/install.linux.packages.install.html | |
| :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: | |
| :: | |
| :: Thank you for choosing Perforce Helix | |
| :: The following has been installed by the 'helix-broker' package: | |
| :: | |
| :: - The Helix Broker (p4broker) | |
| :: - A 'perforce' system user | |
| :: - p4dctl, a tool for managing Perforce service instances | |
| :: - The Helix Command-Line Client (p4) | |
| :: | |
| :: The Helix Broker is now installed, but not yet configured. | |
| :: To configure a new Broker instance, copy the p4dctl Broker | |
| :: template to a new file, fill in the placeholders, make the Broker | |
| :: root directory, then create and edit the sample Broker | |
| :: configuration. | |
| :: | |
| :: sudo -u perforce sh -c \ | |
| :: "cp /etc/perforce/p4dctl.conf.d/p4broker.template \ | |
| :: /etc/perforce/p4dctl.conf.d//p4broker-master.conf; \ | |
| :: mkdir /opt/perforce/servers/p4broker-master; \ | |
| :: /opt/perforce//sbin/p4broker -C > \ | |
| :: /opt/perforce/servers/p4broker-master/broker.conf" | |
| :: | |
| :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: | |
| $ ls /etc/perforce/p4dctl.conf.d/p4broker.template | |
| $ cp /etc/perforce/p4dctl.conf.d/p4broker.template /etc/perforce/p4dctl.conf.d/p4broker-master.conf | |
| $ ls /etc/perforce/p4dctl.conf.d//p4broker-master.conf | |
| $ mkdir /opt/perforce/servers/p4broker-master | |
| $ /opt/perforce/sbin/p4broker -C > /opt/perforce/servers/p4broker-master/broker.conf | |
| $ ls /opt/perforce/servers/p4broker-master/broker.conf | |
| root@ip-172-31-25-99:/home/ubuntu# more /opt/perforce/servers/p4broker-master/broker.conf | |
| #------------------------------------------------------------------------------- | |
| # Sample p4broker configuration file | |
| # | |
| # The following paragraphs illustrate the configuration of the Helix Core | |
| # Broker by example. Change the values and configuration to suit your | |
| # environment and requirements. | |
| # | |
| # Note that by default this broker will simply allow all commands to pass | |
| # through, and be executed against the target server. Uncomment and edit | |
| # the examples below to get started. | |
| #------------------------------------------------------------------------------- | |
| target = ssl:localhost:1666; | |
| listen = 1669; | |
| directory = /opt/perforce/servers/p4broker-master/; | |
| logfile = broker.log; | |
| debug-level = server=1; | |
| admin-name = "Helix Core Admins"; | |
| admin-phone = 999/911; | |
| admin-email = helix-core-admins@example.com; | |
| server.id = brokerSvrID; | |
| # Compress broker <-> server connection. If the broker is across a slow link | |
| # such as a WAN, compression can increase performance. If the broker is near | |
| # the server (such as on the same machine,) then avoiding recompressing the | |
| # client's protocol stream saves work. | |
| compress = false; | |
| # Optional user account to authenticate the broker to the target server with. | |
| #service-user = "svc-user-broker"; | |
| # Optional alternate P4TICKETS location. | |
| #ticket-file = "/p4/broker/.p4tickets"; | |
| $ vi /opt/perforce/servers/p4broker-master/broker.conf | |
| command: .* | |
| { | |
| action = reject; | |
| message = "Server down for maintenance. Back soon"; | |
| } | |
| p4dctl error: | |
| 'p4broker-master' p4broker: '/usr/sbin/p4broker' exited with status 255. | |
| Started 0 services. |
by
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| #------------------------------------------------------------------------------- | |
| # p4broker configuration file | |
| # This is for the main broker instance listening at TCP:1666 and pointed at TCP:1667 | |
| # and is intended for use during maintenance mode | |
| #------------------------------------------------------------------------------- | |
| target = localhost:1667; | |
| listen = 1666; | |
| directory = /metadata; | |
| logfile = /p4/1/logs/p4broker.log; | |
| debug-level = server=1; | |
| admin-name = "Patrick M. Slattery"; | |
| admin-phone = 802-654-9825; | |
| admin-email = perforce-admins@mywebgrocer.com; | |
| # Compress broker <-> server connection. If the broker is across a slow link | |
| # such as a WAN, compression can increase performance. If the broker is near | |
| # the server (such as on the same machine,) then avoiding recompressing the | |
| # client's protocol stream saves work. | |
| compress = false; | |
| # Optional user account to authenticate the broker to the target server with. | |
| #service-user = "svc-user-broker"; | |
| # Optional alternate P4TICKETS location. | |
| #ticket-file = "/p4/broker/.p4tickets"; | |
| # | |
| # Redirection mode. Pedantic redirection always redirects a command when it | |
| # matches a rule in the broker config. Selective redirection permits | |
| # redirection of commands within a single TCP/IP connection until a command | |
| # has been executed against the master server, at which point all commands | |
| # for the connection are sent to the master server. Selective redirection is | |
| # the default as it gives GUI users a better experience when replication | |
| # delays might otherwise cause incorrect results to be returned. | |
| redirection = selective; | |
| #redirection = pedantic; | |
| #------------------------------------------------------------------------------- | |
| # Definitions of all altservers in the environment. | |
| #------------------------------------------------------------------------------- | |
| # Note that the altserver name can not be 'random' as that is reserved for use | |
| # in the destination field of command handlers to specify that the altserver | |
| # should be chosen randomly. | |
| # | |
| #altserver: replica_name | |
| #{ | |
| # # | |
| # # Address of target server. Note that target servers must be configured | |
| # # to use P4AUTH to ensure that login tickets are valid for all servers in | |
| # # the brokered environment. I.e. the target and alternate servers must | |
| # # share their authentication. | |
| # # | |
| # target = localhost:1669; | |
| #} | |
| #------------------------------------------------------------------------------- | |
| # Command policies | |
| #------------------------------------------------------------------------------- | |
| # | |
| # The general syntax is: | |
| # | |
| # command: <regex pattern> | |
| # { | |
| # # Conditions for the command to meet (optional) | |
| # # Note that with the exception of 'flags', these are regex patterns. | |
| # # See 'p4 help grep' for an explanation of the regex syntax. | |
| # flags = <required flags>; | |
| # args = <required arguments>; | |
| # user = <required user>; | |
| # workspace = <required client workspace>; | |
| # prog = <required client program>; | |
| # version = <required version of client program>; | |
| # | |
| # # What to do with matching commands (required) | |
| # action = pass | reject | redirect | filter ; | |
| # | |
| # # How to go about it | |
| # destination = <altserver>; # Required for action = redirect | |
| # execute = <path to filter program>; # Required for action = filter | |
| # message = <rejection message>; # Required for action = reject | |
| #} | |
| # | |
| # Note that when specifying regex patterns, bare strings like 'integ' will also | |
| # match 'integrate'. To match an exact string, append the beginning/end of line | |
| # anchors. E.g. '^integ$'. | |
| # | |
| # Block all access to the server during periods of maintenance. | |
| # | |
| command: .* | |
| { | |
| action = reject; | |
| message = "The Perforce server is currently down for maintenance."; | |
| } |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| #------------------------------------------------------------------------------- | |
| # p4broker configuration file | |
| # This is for the main broker instance listening at TCP:1666 and pointed at TCP:1667 | |
| # and is intended for use during normal server operation | |
| #------------------------------------------------------------------------------- | |
| target = localhost:1667; | |
| listen = 1666; | |
| directory = /metadata; | |
| logfile = /p4/1/logs/p4broker.log; | |
| debug-level = server=1; | |
| admin-name = "Patrick M. Slattery"; | |
| admin-phone = 802-654-9825; | |
| admin-email = perforce-admins@mywebgrocer.com; | |
| # Compress broker <-> server connection. If the broker is across a slow link | |
| # such as a WAN, compression can increase performance. If the broker is near | |
| # the server (such as on the same machine,) then avoiding recompressing the | |
| # client's protocol stream saves work. | |
| compress = false; | |
| # Optional user account to authenticate the broker to the target server with. | |
| #service-user = "svc-user-broker"; | |
| # Optional alternate P4TICKETS location. | |
| #ticket-file = "/p4/broker/.p4tickets"; | |
| # | |
| # Redirection mode. Pedantic redirection always redirects a command when it | |
| # matches a rule in the broker config. Selective redirection permits | |
| # redirection of commands within a single TCP/IP connection until a command | |
| # has been executed against the master server, at which point all commands | |
| # for the connection are sent to the master server. Selective redirection is | |
| # the default as it gives GUI users a better experience when replication | |
| # delays might otherwise cause incorrect results to be returned. | |
| redirection = selective; | |
| #redirection = pedantic; | |
| #------------------------------------------------------------------------------- | |
| # Definitions of all altservers in the environment. | |
| #------------------------------------------------------------------------------- | |
| # Note that the altserver name can not be 'random' as that is reserved for use | |
| # in the destination field of command handlers to specify that the altserver | |
| # should be chosen randomly. | |
| # | |
| #altserver: replica_name | |
| #{ | |
| # # | |
| # # Address of target server. Note that target servers must be configured | |
| # # to use P4AUTH to ensure that login tickets are valid for all servers in | |
| # # the brokered environment. I.e. the target and alternate servers must | |
| # # share their authentication. | |
| # # | |
| # target = localhost:1669; | |
| #} | |
| #------------------------------------------------------------------------------- | |
| # Command policies | |
| #------------------------------------------------------------------------------- | |
| # | |
| # The general syntax is: | |
| # | |
| # command: <regex pattern> | |
| # { | |
| # # Conditions for the command to meet (optional) | |
| # # Note that with the exception of 'flags', these are regex patterns. | |
| # # See 'p4 help grep' for an explanation of the regex syntax. | |
| # flags = <required flags>; | |
| # args = <required arguments>; | |
| # user = <required user>; | |
| # workspace = <required client workspace>; | |
| # prog = <required client program>; | |
| # version = <required version of client program>; | |
| # | |
| # # What to do with matching commands (required) | |
| # action = pass | reject | redirect | filter ; | |
| # | |
| # # How to go about it | |
| # destination = <altserver>; # Required for action = redirect | |
| # execute = <path to filter program>; # Required for action = filter | |
| # message = <rejection message>; # Required for action = reject | |
| #} | |
| # | |
| # Note that when specifying regex patterns, bare strings like 'integ' will also | |
| # match 'integrate'. To match an exact string, append the beginning/end of line | |
| # anchors. E.g. '^integ$'. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| #!/bin/bash -xe | |
| # | |
| exec 2>&1 | |
| export P4SSLDIR={{pkg.svc_files_path}}/sslkeys | |
| exec p4broker -c {{pkg.svc_config_path}}/p4broker.conf | |
| if [ ${MAINT_MODE} = 0 ]; then | |
| ln -s ${METADATA}/p4broker.conf.down ${METADATA}/p4broker.conf | |
| MAINT_MODE=1 | |
| else | |
| ln -s ${METADATA}/p4broker.conf.up ${METADATA}/p4broker.conf | |
| MAINT_MODE=0 | |
| fi |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| The Helix Broker (P4Broker) enables you to implement local | |
| policies in your Helix environment by allowing you to restrict | |
| the commands that can be executed, or redirect specific commands to | |
| other Helix Versioning Engines. The Helix Broker is a server process that | |
| mediates between Helix client applications and Helix servers, | |
| including proxy servers. The Helix Broker is designed to run | |
| on a host that lies close to the Helix Versioning Engine (P4D), | |
| preferably on the same machine. Example: Helix client | |
| applications can connect to a proxy server that connects to the | |
| broker, which connects to a Helix Versioning Engine. | |
| This document tells you how to install, configure and launch the | |
| Helix broker. To deploy the Helix Broker, you must: | |
| 1. Install it | |
| 2. Create a broker configuration file | |
| 3. Start the broker | |
| The following sections tell you how to perform these steps. | |
| Support Status | |
| -------------- | |
| The Helix Broker is currently supported. | |
| Supported Platforms | |
| ------------------- | |
| Linux kernel 2.6 for ARM | |
| Linux kernel 2.6 for 64-bit Itanium | |
| Linux kernel 2.6 for Intel(x86,x86_64) | |
| FreeBSD 10.0 for Intel(x86, x86_64) | |
| Windows for 64-bit Itanium | |
| Windows for Intel(ntx86,ntx64) | |
| Apple Darwin 9.0 for Intel(x86,x86_64) | |
| Terms of Use | |
| ------------ | |
| THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" | |
| AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE | |
| IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE | |
| ARE DISCLAIMED. IN NO EVENT SHALL PERFORCE SOFTWARE, INC. BE LIABLE FOR ANY | |
| DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES | |
| (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; | |
| LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND | |
| ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT | |
| (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS | |
| SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. | |
| Compatibility | |
| ------------- | |
| The 2014.2 Release of the Helix Broker requires a 2007.2 or later client, | |
| and a 2007.2/131114 or later p4d. It is not compatible with | |
| older releases of Perforce. | |
| Installing the Broker | |
| --------------------- | |
| Download the p4broker executable from the Perforce Web site to a suitable | |
| directory on the machine where it'll run (such as /usr/local/bin or | |
| C:\Program Files\Perforce). On Unix systems, ensure that the binary is | |
| executable by setting the appropriate permissions. For example: | |
| chmod +x /usr/local/bin/p4broker | |
| Creating a Broker Configuration File | |
| ------------------------------------ | |
| The broker configuration file is a text file containing rules that: | |
| o Specify commands that individual users can issue, and | |
| o Define the commands that are to be redirected to | |
| specified servers | |
| To generate a sample broker configuration file, issue the following | |
| command: | |
| p4broker -C > p4broker.conf | |
| You can edit the newly-created p4broker.conf file to specify your | |
| requirements. The following section explains the configuration | |
| options available to you. | |
| Format of Broker Configuration Files | |
| ------------------------------------ | |
| A broker configuration file contains three sections: | |
| o Global settings: settings that apply to all broker | |
| operations. | |
| o Alternate server definitions: the addresses and names of | |
| servers to which commands can be redirected in specified | |
| circumstances | |
| o Command handler specifications: specify how individual | |
| commands should be handled; in the absence of a command handler | |
| for any given command, the Helix Broker will permit the | |
| execution of the command. | |
| o Router specifications: when using the p4broker to route between | |
| a group of workspace servers in a Helix Cluster, or between | |
| a group of edge servers. | |
| In broker configuration files you must double-quote text that contains | |
| spaces. | |
| Global Settings | |
| --------------- | |
| The following settings apply to all operations you are specifying | |
| for the broker. | |
| target: The default Helix Versioning Engine (P4D) to which commands are | |
| sent unless overridden by other settings in the configuration | |
| file. Syntax: target = host:port; | |
| listen: The address on which the Helix Broker listens for | |
| commands from Helix client applications. Use 'rsh' to run | |
| the broker from inetd (along with the -q command-line flag.) | |
| Syntax: listen = [host:]port; | |
| directory: The home directory for the Helix Broker. Other paths | |
| specified in the broker configuration file must be relative to this | |
| location. Syntax: directory = path; | |
| logfile: The path to the Helix Broker logfile. | |
| Syntax: logfile = path; | |
| debug-level: The level of debugging output to log. | |
| Syntax: debug-level = server=1; | |
| admin-name: The name of your Perforce Administrator. This | |
| information is displayed to the user in certain error messages. | |
| Syntax: admin-name = "name"; | |
| admin-email: The email address at which users can contact their | |
| Perforce Administrator. Syntax: admin-email = email address; | |
| admin-phone: The telephone number of the Perforce Administrator. | |
| Syntax: admin-phone = phone#; | |
| redirection: The redirection mode to use. Two modes are defined: | |
| 'selective' and 'pedantic'. Versions of the P4Broker prior to | |
| 2008.1 only supported 'pedantic' mode in which all requests for | |
| redirection are honoured. In 'selective' mode, redirection is | |
| permitted, within a session, until one command has been executed | |
| against the default (target) server. From then on, all commands | |
| within that session will run against the default server and will | |
| not be redirected. This mode is intended to help GUI interfaces | |
| display more accurate information when used with replicas. Note | |
| that from the 2008.1 P4Broker, 'selective' redirection is the | |
| default. | |
| Syntax: redirection = selective | pedantic ; | |
| destination: When this setting is used at the global level | |
| it pertains to a p4broker being used as a cluster router. | |
| Adding the global directive: | |
| Syntax: destination target; | |
| will cause the router to direct all requests to the current | |
| depot-master. This syntax should be used when a cluster | |
| does not contain any workspace servers. This option was | |
| added in 2014.2. | |
| Alternate Servers | |
| ----------------- | |
| The Helix Broker can direct user requests to an alternate | |
| server to reduce the load on the default server. These alternate | |
| servers must be replicas of the target server. There is no | |
| limit to the number of alternate servers you can define in a | |
| broker configuration file. | |
| The syntax for specifying an alternate server is as follows: | |
| altserver: name | |
| { | |
| target = host:port; | |
| } | |
| The name assigned to the alternate server is used in command | |
| handler specifications, as described in the next section. | |
| Command Handlers | |
| ---------------- | |
| Command handlers enable you to specify how specific commands are | |
| handled. When users run commands, the Helix Broker will search for | |
| matching command handlers, and evaluate them until the first non-passing | |
| match is found. If no command handler matches the user's command, it will | |
| be forwarded to the target Helix Versioning Engine for normal processing. | |
| The general syntax of a command handler specification is as | |
| follows: | |
| command: commandpattern | |
| { | |
| # Conditions for the command to meet; (optional) | |
| flags = required flags; | |
| user = required user; | |
| workspace = required client workspace; | |
| prog = required Helix client application; | |
| version = required version of client application; | |
| checkauth = require user be authenticated; | |
| # What to do with matching commands (required) | |
| action = pass | reject | redirect | filter | respond ; | |
| # How to go about it | |
| destination = altserver; # Required for action = redirect | |
| execute = filter program; # Required for action = filter | |
| message = message; # Required for action = reject and | |
| # action = respond. Otherwise optional | |
| } | |
| The following table describes the parameters in detail. | |
| action: Defines how the Helix Broker handles the specified | |
| commands. Valid values are: | |
| o pass | |
| o reject | |
| o redirect | |
| o filter | |
| o respond | |
| destination: For redirected commands: the name of the alternate | |
| server to which the commands are redirected. Must be the name of | |
| a previously defined alternate server. If the name is 'random', | |
| the alternate server is chosen arbitrarily from those available. | |
| checkauth: Check that the user has access to the Helix Versioning | |
| Engine before performing the action. This can be set to "true" or | |
| "false". If set to "true", the Helix Broker will run "p4 protects -m" | |
| with the user's connection. If set to FALSE or unset, the check | |
| is not performed. If a filter program is run, the highest level | |
| permission the user has is passed in as the maxPerm parameter. | |
| execute: The path to a filter program to be executed. For details | |
| about filter programs, see "Filter Programs," below. Note that | |
| for interpreted scripts, you may need to first give the path to | |
| the interpreter, then pass the script as an argument to it. | |
| flags: A list of flags that must be present on the command line of | |
| the command being handled. This feature enables you to specify | |
| different handling for the same p4 command, depending on which | |
| flags the user specifies. Note that only single character flags | |
| may be specified here. Multi-character flags, and flags that | |
| take arguments should be handled by a filter program (see below). | |
| message: A message to be sent to the user; may be used with any | |
| of the above actions. | |
| prog: The Helix client application through which the user | |
| issued the command. This feature enables you to handle commands | |
| on a per-application basis. | |
| user: The name of the user who issued the command. | |
| version: The version of the Helix client program through which | |
| the user issued the command. | |
| workspace: The Helix client workspace setting in effect when | |
| the command was issued. | |
| Filter Programs | |
| --------------- | |
| When the action for a command handler is filter, the Helix | |
| Broker executes the program or script specified by the execute | |
| parameter and performs the action returned by the program. Filter | |
| programs enable you to enforce policies beyond the capabilities | |
| provided by the broker configuration file. | |
| The Helix Broker invokes the filter program by passing command | |
| details to the program"s standard input (stdin) in the following | |
| format: | |
| command: user command | |
| clientProg: client program | |
| clientVersion: version of client program | |
| clientProtocol: level of client protocol | |
| apiProtocol: level of api protocol | |
| workspace: name of client workspace | |
| user: name of requesting user | |
| clientIp: IP address of client | |
| proxyIp: IP address of proxy (if any) | |
| cwd: Client's working directory | |
| maxPerm: highest permission (if checkauth set) | |
| argCount: number of arguments to command | |
| Arg0: first argument (if any) | |
| Arg1: second argument (if any) | |
| Your filter program *must* read this data from stdin before | |
| performing any additional processing, regardless of whether the | |
| script requires the data. If the filter script does not read | |
| the data from stdin, "broken pipe" errors can occur. In this case, | |
| the broker rejects the user's command. Note that non-printable | |
| command arguments are percent-encoded. | |
| Your filter program must respond to the Broker on stdout with one | |
| of the following messages: | |
| action: PASS | |
| message: Some message for the user (optional) | |
| action: REJECT | |
| message: Some message for the user (required) | |
| action: REDIRECT | |
| altserver: <altserver name> | |
| message: Some message for the user (optional) | |
| action: RESPOND | |
| message: Some message for the user (required) | |
| The 'action' keyword is always required and tells the Broker how to | |
| respond to the user's request. The available actions are: | |
| PASS - Run the user's command unchanged | |
| REJECT - Reject the command with a message | |
| REDIRECT - Run the command on a different server | |
| RESPOND - Just respond with a message to the user (no command | |
| is run on the server). | |
| Note that for backwards compatibility purposes, the response format used by | |
| older versions of the broker is still accepted. | |
| If the filter program returns any response other than the three | |
| listed above, the user's command is rejected. Errors that occur | |
| during the execution of your filter script code cause the broker | |
| to reject the user's command. In this case, the broker returns the | |
| error message. | |
| Starting the Broker | |
| ------------------- | |
| To start the Helix Broker from the command line, issue the | |
| following command: | |
| p4broker -c config_file -d | |
| Alternatively, you can set P4BROKEROPTIONS before launching | |
| the broker, to specify the broker configuration file to use. For example: | |
| Unix: | |
| export P4BROKEROPTIONS="-c /usr/perforce/broker.conf" | |
| p4broker -d | |
| Windows: | |
| p4 set -s P4BROKEROPTIONS="-c c:\p4broker\broker.conf" | |
| p4broker | |
| The Helix Broker reads the specified broker configuration file | |
| and on Unix platforms the -d flag causes the Helix Broker to | |
| detach itself from the controlling terminal and run in the | |
| background. | |
| To configure the Helix Broker to start automatically, put this | |
| command in a startup script that is appropriate to your host operating | |
| system. On Windows systems, you can run the broker as a service: | |
| http://kb.perforce.com/article/998 | |
| Configuring Alternate Servers with Authentication Servers | |
| ---------------------------------------------------------- | |
| Alternate servers require users to authenticate themselves when | |
| they run commands. For this reason, the Helix Broker must be | |
| used in conjunction with the Helix authentication server | |
| (P4AUTH) and p4d at version 2007.2/131114 or later. | |
| When used in this configuration, a single "p4 login" request can | |
| create a ticket that is valid for the user across all servers in | |
| the Helix Broker's configuration, enabling the user to log in | |
| once. The Helix Broker assumes that a ticket granted by the | |
| target server is valid across all alternate servers. | |
| Important: If the target server in the broker configuration file | |
| is a central authentication server, the value assigned to the | |
| "target" parameter must precisely match the setting of P4AUTH on | |
| the alternate server machine(s). Similarly, if an alternate server | |
| defined in the broker configuration file is used as the central | |
| authentication server, the value assigned to the "target" parameter | |
| for the alternate server must match the setting of P4AUTH on the | |
| other server machine(s). | |
| Protections | |
| ----------- | |
| The p4 protect command can distinguish connections coming from a broker if | |
| the string 'proxy-' is prepended to the IP addresses of the true client | |
| and used in the protections table. For example, 'proxy-*' applies to all | |
| connections from all brokers and 'proxy-10.0.0.5' identifies a host with | |
| an IP address of 10.0.0.5 and connecting to p4d through a broker. This | |
| behavior is configurable; see 'p4 help protect'. | |
| Routing | |
| ----------- | |
| In routing mode a p4broker will keep a local cache of the mapping of | |
| client to server location. This functionality is used to direct | |
| requests from clients that are distributed across a group of edge | |
| or workspace servers (the later being in a Helix Cluster). | |
| Configuring routing for use with a Helix Cluster | |
| ---------------------------------------------------------- | |
| In 2014.2 a p4broker can be used as a router to distribute work across | |
| a group of clustered workspace servers. To enable this functionality an | |
| additional router block must be specified in the configuration file. | |
| The general syntax of a command handler specification is as | |
| follows: | |
| router: routerId | |
| { | |
| # Mandatory cluster configuration (should match those values | |
| # set in the cluster's p4d configurations) | |
| cluster.id = mycluster; | |
| p4.utils.dir = /opt/perforce/bin; | |
| zk.host.port.pairs = svr1.foo.com:2181,svr2.foo.com:2181,svr1.foo.com:2181; | |
| # Optional override of default timeout of 300 seconds (5 min) | |
| # This controls how long the router's p4zk process will wait | |
| # for the Zookeeper servers to accept a connection. | |
| zk.connect.timeout = 150; | |
| } | |
| It should be noted that once a broker is started with a router block | |
| in its configuration file it will launch a child p4zk process to | |
| handle communcation with cluster. The broker will communicate | |
| with the p4zk process across a unix domain socket located in the | |
| broker's configuration directory. The associated p4zk process will | |
| keep track of changes in the cluster's membership and update the | |
| altserver entries and/or the target entry as needed. | |
| Configuring routing for use with a group of Edge Servers | |
| ---------------------------------------------------------- | |
| To route between a group of edge servers: | |
| * Setup altserver entries for each edge server | |
| * Add the globally scoped keyword: router; to the configuration | |
| Example: | |
| router; | |
| altserver: edge1 | |
| { | |
| target = edge1.foo.com:2666; | |
| } | |
| altserver: edge2 | |
| { | |
| target = edge2.foo.com:2666; | |
| } | |
| altserver: edge3 | |
| { | |
| target = edge3.foo.com:2666; | |
| } | |
| --------------------------------------------------------------------------- | |
| Note: see the following marks in the notes below. | |
| * -- requires new p4 client program | |
| ** -- requires new p4d server program | |
| *** -- requires new p4p program | |
| **** -- requires new p4broker program | |
| --------------------------------------------------------------------------- |
I’m a DevOps/SRE/DevSecOps/Cloud Expert passionate about sharing knowledge and experiences. I am working at Cotocus. I blog tech insights at DevOps School, travel stories at Holiday Landmark, stock market tips at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at I reviewed , and SEO strategies at Wizbrand.
Please find my social handles as below;
Rajesh Kumar Personal Website
Rajesh Kumar at YOUTUBE
Rajesh Kumar at INSTAGRAM
Rajesh Kumar at X
Rajesh Kumar at FACEBOOK
Rajesh Kumar at LINKEDIN
Rajesh Kumar at PINTEREST
Rajesh Kumar at QUORA
Rajesh Kumar at WIZBRAND
