[p4] Depot hierarchy and p4 protect

[P4Sam]

Posted on behalf of forum user 'P4Sam'.



[http://forums.perforce.com/index.php?app=forums&module=forums&section=findpost&pid=6687]
Stephen Garcia, on 2012/12/06 17:21:11 UTC, said:
> protect table
>
> super user root * //...
> write user user1 * //area1/...
> write user user2 * //area2/...
> write user user3 * //area2/extra/...
> write user user3 * //area1/proj2/...
> write user root * -//testDepot/...
>
> expectations (result)
>
> root has access to all depots, except testDepot (success)
> user1 access to proj1 and proj2 (failed, no depots visible)
> user2 has access to proj3 and proj4 (failed, no depots visible)
> user3 has access to proj2 and proj4 (failed, no depots visible)
>

Everything as you have it above looks exactly right, so I suspect there's
some additional complexity (or possibly a typo) in the actual protection table
that's the source of the problem. If you're able, I'd suggest
sending a cut-and-paste of the following to support (assuming you don't want
to post your actual data here):

1) p4 protect -o (as root)
2) p4 depots (as root)
3) p4 info (as user1)
4) p4 depots (as user1)



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/2199-depot-hierarchy-and-p4-protect

[mjanulewicz]

Posted on behalf of forum user 'mjanulewicz'.



[http://forums.perforce.com/index.php?app=forums&module=forums&section=findpost&pid=6687]
Stephen Garcia, on 2012/12/06 17:21:11 UTC, said:
> Hi guys,
>
> So in our environment, we are starting to dabble in perforce for use in project versioning for our students (higher education environment). We are currently early in our building and testing of a suitable production release and there are a couple things that I'm getting stuck on, which at first glance it seems trivial, but i happen to have not found a good explanation for it.
>
> The situation is as follows,
> -We are running the P4 server on a CentOS 6.3 machine.
> -clients are running p4v on windows machines.
> -we want to create depots organized in a neat folder hierarchy withing the root Perforce folder that would make sense when considering classes, student groups, and such.
> -depots are created and work just fine within this hierarchy.
> -P4 protect doesnt.
>
> so the following is a set of test depots i set up with a set of users to demonstrate this issue
>
> /Perforce is the root and working directory for ./P4 as well as for everything else perforce related
>
> depot hierarchy (depots in bold, rest are directories)
>
> testDepot
> area1/ proj1
> area1/ proj2
> area2/ proj3
> area2/extra/ proj4
>
> protect table
>
> super user root * //...
> write user user1 * //area1/...
> write user user2 * //area2/...
> write user user3 * //area2/extra/...
> write user user3 * //area1/proj2/...
> write user root * -//testDepot/...
>
> expectations (result)
>
> root has access to all depots, except testDepot (success)
> user1 access to proj1 and proj2 (failed, no depots visible)
> user2 has access to proj3 and proj4 (failed, no depots visible)
> user3 has access to proj2 and proj4 (failed, no depots visible)
>
> ive tried playing around with ... and * in the protect table to no success on the expectations, as well as checking the users by giving them //... access (that worked, gave user full access to all depots), and im running out of options. It's completely possible i missed something painfully simple and obvious, so im open to suggestion.
>
> Thanks,
> Stephen
>

Another fun thing is using the P4Admin tool to peruse permissions. You can click
on a path, then click on a group/user to see what their access is. Often times
you can see where you have things in the wrong order a bit easier than on the
commandline.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/2199-depot-hierarchy-and-p4-protect

[Stephen Garcia]

Posted on behalf of forum user 'Stephen Garcia'.



[http://forums.perforce.com/index.php?app=forums&module=forums&section=findpost&pid=6693]
P4Sam, on 2012/12/06 22:16:58 UTC, said:
> Everything as you have it above looks exactly right, so I suspect there's some additional complexity (or possibly a typo) in the actual protection table that's the source of the problem. If you're able, I'd suggest sending a cut-and-paste of the following to support (assuming you don't want to post your actual data here):
>
> 1) p4 protect -o (as root)
> 2) p4 depots (as root)
> 3) p4 info (as user1)
> 4) p4 depots (as user1)
>

I dont mind posting the results as this is a test build. thou i did take a
little bit out on info

p4 protect -o (as root)
# Perforce Protections Specification. # # Each line contains a protection mode,
a group/user indicator, the # group/user name, client host id and a depot file
path pattern. # A user gets the highest privilege granted on any line. # # Mode:
The permission level or right being granted or denied. Each # permission level
includes all the permissions above it, # except for 'review'. Each
permission right only includes # the specific right and not all the lesser
rights. Modes # preceded by '=' are rights; all other modes are levels.
# # list - users can see names but not contents of files; # users can see all
non-file related metadata # (clients, users, changelists, jobs, etc.) # # read -
users can sync, diff, and print files # # open - users can add, edit, delete,
and integrate files # # write - users can submit open files # # admin - permits
those administrative commands and command # options that don't affect the
server's security # # super - allows access to the 'p4 protect'
command # # review - allows access to the 'p4 review' command; implies #
read access # # =read - if this right is denied, users cannot sync, diff, # or
print files # # =branch - if this right is denied, users are not permitted # to
use files as a source for 'p4 integrate' # # =open - if this right is
denied, users cannot open files # (add, edit, delete, integrate) # # =write - if
this right is denied, users cannot submit open # files # # Group/User indicator:
either 'group' or 'user'. # # Name: A Perforce group or user
name; may be wildcarded. # # Host: The IP address of a client host; may be
wildcarded, or # may instead use CIDR syntax, e.g. 172.16.0.0/16 would match #
all IPv4 addresses which start with 172.16. # # Path: The part of the depot
being granted access. Protections: super user root * //... write user user1 *
//area1/... write user user2 * //area2/... write user user3 * //area2/extra/...
write user user3 * //area1/proj2/... write user root * -//testDepot/...

p4 depots (as root)
Depot depot 2012/11/29 local depot/... 'Default depot' Depot proj1
2012/12/06 local area1/proj1/... 'Created by root. ' Depot proj2
2012/12/06 local area1/proj2/... 'Created by root. ' Depot proj3
2012/12/06 local area2/proj3/... 'Created by root. ' Depot proj4
2012/12/06 local area2/extra/proj4/... 'Created by root. '

p4 info (as user1) (parts taken out match the correct addresses)
User name: user1 Client name: deimos Client host: (taken out for security
concerns) Client unknown. Current directory: /Perforce Peer address: (taken out
for security concerns) Client address: (taken out for security concerns) Server
address: (taken out for security concerns) Server root: . Server date:
2012/12/07 09:05:24 -0500 EST Server uptime: 193:13:43 Server version:
P4D/LINUX26X86_64/2012.2/538478 (2012/10/16) Server license: none Case Handling:
sensitive

p4 depots (as user1) (nothing returned)





[http://forums.perforce.com/index.php?app=forums&module=forums&section=findpost&pid=6694]
mjanulewicz, on 2012/12/06 22:27:43 UTC, said:
> Another fun thing is using the P4Admin tool to peruse permissions. You can click on a path, then click on a group/user to see what their access is. Often times you can see where you have things in the wrong order a bit easier than on the commandline.
>
the p4admin tool shows no access to any of the users on any of the depots except
for root, who has all super access except for the one depot specified in protect



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/2199-depot-hierarchy-and-p4-protect

[P4Sam]

Posted on behalf of forum user 'P4Sam'.

I think what's tripping you up is the fact that the depot namespace
you've set up is different from how the archives are laid out on disk. The
depot hierarchy you've actually defined looks like:

//depot //proj1 //proj2 //proj3 //proj4

But I don't think this is what you want. Assuming you haven't already
populated these depots, I'd just start over -- use "p4 depot -d"
to delete the "proj" depots, and then use "p4 depot" to
create depots called "area1" and "area2". Then you'll
have:

//depot //area1 //area2

Then you can add anything you like under //area1 and //area2 by mapping them to
your workspace. E.g. to create //area1/proj2 you might create a client with a
mapping like:

Client: stephen-area1 Root: /home/stephen/area1 View: //area1/...
//stephen-area1/...

Then if you create a local directory called:

/home/stephen/area1/proj2

any files you put in there and "p4 add" will go under:

//area1/proj2

Make sense?



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/2199-depot-hierarchy-and-p4-protect

[Stephen Garcia]

Posted on behalf of forum user 'Stephen Garcia'.

P4Sam, Thanks for your input. This method does indeed work permission-wise quite
well. However, I'm curious if there is a way for a roundabout method to
work. Instead of having different directories for the "proj#" within
the depots, for those "proj#" to be the depots themselves, while still
keeping the current directory hierarchy. Is there any way to do this at all?

Thanks,
Stephen



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/2199-depot-hierarchy-and-p4-protect

[P4Sam]

Posted on behalf of forum user 'P4Sam'.



[http://forums.perforce.com/index.php?app=forums&module=forums&section=findpost&pid=6702]
Stephen Garcia, on 2012/12/10 20:42:10 UTC, said:
> Instead of having different directories for the "proj#" within the depots, for those "proj#" to be the depots themselves, while still keeping the current directory hierarchy. Is there any way to do this at all?
>

Which directory hierarchy do you mean in this context? There's:

1) The "depot" namespace (the Perforce paths that start with
"//depotname", which is the standard way to refer to files within
Perforce). This the one that your end users will see in P4V, it's what your
protections mapping will refer to, et cetera. The top level of that namespace is
the depots you define with the "p4 depot" command.

2) The server's filesystem (which is generally invisible and irrelevant to
end users). Each depot's archive files live in the server filesystem
directory defined by the depot's Map: field. By default, the Map: points to
a subdirectory of the server's root directory that has the same name as the
depot (so the server's filesystem looks more or less like the depot
namespace).

3) The client's filesystem (which is mapped to the depot namespace via
client views). Each client's workspace files live in a location defined by
the client's View: field, with the client's Root: field being the top
level of the client's view mapping. By default, the View: maps all depots
1:1 (so after a sync the client's filesystem looks more or less like the
depot namespace).

So if you like how your depot namespace looks, but you want to change where
things are on the server's filesystem, you want to modify the depots'
Map fields (and move the archives, if any, to match -- use "p4 verify"
afterwards to make sure you did it right). See this KB article
[http://kb.perforce.com/article/960/moving-depot-files-to-a-different-location]
for a step-by-step guide to doing this very safely when you have an active
server and active users.



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/2199-depot-hierarchy-and-p4-protect

[Stephen Garcia]

Posted on behalf of forum user 'Stephen Garcia'.

It was a combination of those first two contexts you mentioned. We played around
with mapping and whatnot but figured the way it was working with the "area1
" and "area2" setup was the better idea. In our environment, when
we build it and release it to production, the areas would be equivalent to a
class or faculty and his student's projects so i'm content with the
result. Thank you very much for your input, those that responded. I'll
probably be bothering you guys some more as we keep building this setup.

Thanks,
Stephen



--
Please click here to see the post in its original format:
http://forums.perforce.com/index.php?/topic/2199-depot-hierarchy-and-p4-protect