Replication and protections
To apply the IP address of a replica user’s workstation against the
protections table, prepend the string proxy- to the
workstation’s IP address.
Before you prepend the string proxy- to the
workstation’s IP address, make sure that a broker or proxy is in place.
For instance, consider an organization with a remote development site
with workstations on a subnet of 192.168.10.0/24. The
organization also has a central office where local development takes
place; the central office exists on the 10.0.0.0/8 subnet. A
Perforce
service resides in the 10.0.0.0/8 subnet, and a replica
resides in the 192.168.10.0/24 subnet. Users at the remote
site belong to the group remotedev, and occasionally visit
the central office. Each subnet also has a corresponding set of IPv6
addresses.
To ensure that members of the remotedev group use the
replica while working at the remote site, but do not use the replica when
visiting the local site, add the following lines to your protections
table:
list group remotedev 192.168.10.0/24 -//... list group remotedev [2001:db8:16:81::]/48 -//... write group remotedev proxy-192.168.10.0/24 //... write group remotedev proxy-[2001:db8:16:81::]/48 //... list group remotedev proxy-10.0.0.0/8 -//... list group remotedev proxy-[2001:db8:1008::]/32 -//... write group remotedev 10.0.0.0/8 //... write group remotedev [2001:db8:1008::]/32 //...
The first line denies list access to all users in the
remotedev group if they attempt to access
Helix Server
without using the replica from their workstations in the
192.168.10.0/24 subnet. The second line denies access in
identical fashion when access is attempted from the IPV6
[2001:db8:16:81::]/48 subnet.
The third line grants write access to all users in the
remotedev group if they are using the replica and are
working from the 192.168.10.0/24 subnet. Users of
workstations at the remote site must use the replica. (The replica itself
does not have to be in this subnet, for example, it could be at
192.168.20.0.) The fourth line grants access in identical
fashion when access is attempted from the IPV6
[2001:db8:16:81::]/48 subnet.
Similarly, the fifth and sixth lines deny list access to
remotedev users when they attempt to use the replica from
workstations on the central office’s subnets (10.0.0.0/8 and
[2001:db8:1008::]/32). The seventh and eighth lines grant
write access to remotedev users who access the
Helix Server
directly from workstations on the central office’s subnets. When
visiting the local site, users from the remotedev group must
access the
Helix Server directly.
When the
Perforce
service evaluates protections table entries, the
dm.proxy.protects configurable is also evaluated:
- dm.proxy.protects defaults to
1, which causes theproxy-prefix to be prepended to all client host addresses that connect via an intermediary (proxy, broker, replica, or edge server), indicating that the connection is not direct. - Setting
dm.proxy.protectsto0removes theproxy-prefix, which allows you to write a single set of protection entries that apply both to directly-connected clients and clients that connect via an intermediary. This is more convenient but might be less secure insofar as a connection is made using an intermediary. If you use this setting, all intermediaries must be at release 2012.1 or higher.
Enabling commands that are served by the replica, such as p4 files
The example above allows only commands that are executed by the master server to run. For example, p4 edit in a forwarding-replica scenario. Commands that are served by the replica, such as p4 files, are disallowed.
| If the dm.proxy.protects configurable is set to its default value of 1 |
To run commands against the replica directly, such as p4 files, you need:
To run a command that needs to be passed over Helix Proxy to the master, such as p4 sync or p4 edit, you need two entries: write user fred 1.2.3.4 //depot/...
|
|
If dm.proxy.protects is set to 0
|
One entry is sufficient for all commands: write user fred 1.2.3.4 //depot/... |
