[p4] Trying to sort out a protection issue - never mind...

[Robert Cowham]

One extra wrinkle:

Use perforce protections to let the superuser be superuser only from a
specific IP address.

If you ask Perforce nicely, they will probably give you a free licence for
this purpose.

As to the timeout, zero is fine as long as the user isn't in any other
groups with non-zero timeout (at which point zero gets ignored). In such
cases, a timeout of 99999999 (8 x 9) is good - 9 x 9 hits the overflow bug
where logging in on one machine logs you out on another (this is superflous
for David's one user in one group on one machine, but may save you some time
if you vary the recipe slightly).

Robert 

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Weintraub, David
Sent: 26 September 2006 13:50
To: Ivey, William; perforce-user at perforce.com
Subject: Re: [p4] Trying to sort out a protection issue - never mind...

As you discovered, checkpoints can only be run by the superuser.

So, the user that must run the checkpoint must be a super user. However,
this is a super user for Perforce and not root. This means that you can
limit that particular user's access quite a bit without too many problems.

You need to do the following:

* Create a system user on that machine and only that machine. For example,
if you have a Unix system, this would be a user in the /etc/passwd table and
not in the NIS table.

* Create a Perforce super user for that particular system user in order to
do the checkpoint. You could use the same super user as your Perforce
administrator, but because of the next step, you probably want a second
super user.

* Create a group for this user, and this user only. Set the timeout for this
group to zero. That way, if someone else falls into this group, it won't
affect their Perforce login ticket timeout length.

* On the machine in question, log in as the system user. Then, log in as the
Perforce super user. Make sure that you are using Perforce ticket
authentication. By default, this will create a ticket file under the user's
HOME directory (on Unix called .p4ticket). Make sure this system user is the
only one with read/write permission on this ticket file. (It will be this
way by default on Unix. On Windows, I sometimes find that other "admin"
groups may have read/write rights.)

* If you're on a Unix system, create a cronjob for this user to run the
checkpoint. Use the Perforce ticket for this user as the password (p4 -u
<userId> -p <ticketfile> ...). If you're on Windows, create a schedule task
for this user.

* On Unix systems, you can change the password for this system user in the
password database to either "*" or "*LK*". This will prevent anyone from
logging in as that user. However, cron jobs will still run as scheduled. I
don't think there is a Windows equivalent way of doing this.

In the end, you've created a cron job that is run by the system user that
uses the Perforce superuser account to do the checkpoint. However, that
system user has a live forever ticket, so none of your scripts contain the
actual password for this user. Instead, it uses a ticket file that is
unreadable by anyone except this specific system user. On Unix systems,
you've also prevented anyone (except the root user) to be able to login as
this user in order to user that system user's Perforce ticket.

I take it that you're going through all of this as a way of backing up your
Perforce server. You have another system that is running the backups, and
you want to do the checkpoint before you backup the Perforce depot.