[p4] How do you handle this situation

Ivey, William william_ivey at bmc.com
Sat Jan 12 10:01:11 PST 2008


> The problem with P4AUTH is that it introduces failure points in
> a distributed environment.

Yes, that occurred to me a bit later. In fact, it was driven home
by our loss of network connectivity on Friday which isolated one 
of our servers. If it had been the PAUTH target, three others would
have been useless too.

We've found it useful for utility servers - such as image servers -
but those are physically close to the authenticating server.

I like the idea of automating user changes. I'll have to look into
that. Thanks.

-Wm


-----Original Message-----
From: Stephen Vance [mailto:steve at vance.com] 
Sent: Friday, January 11, 2008 6:02 PM
To: Ivey, William
Cc: perforce-user at perforce.com
Subject: Re: [p4] How do you handle this situation

Here's what I helped a client set up. Keep track of your cost centers 
internally. Have Perforce consolidate all licenses into a big license 
with duplicates for each server. Install that license on all servers. 
Set up a journal tailer on a master server that replays its db.user 
records into the other servers. This gets you password synchronization, 
as well, if you're not using auth triggers. The client even defined a 
"home server" for each person that server would only distribute changes 
for the users that used it as their "home server."

The problem with P4AUTH is that it introduces failure points in a 
distributed environment. Auth triggers work well and can be used against

replicated LDAP repositories and the like, which are more robust than 
P4AUTH, but they don't substitute for the user table.

One upside about the strategy described above is that chances are good 
that when user propagation fails, the users can't log into the remote 
server anyway for the same reason.

Steve

Ivey, William wrote:
> We have multiple Perforce servers with their own licenses and user
sets
>
> for various teams.
>
>  
>
> The situation now is that some people have been moved from team
>
> to team but are still required to support code they left behind.
> Obviously
>
> the old team isn't keen on paying for a license from their cost center
> that
>
> might be used for a couple of hours a week or month.
>
>  
>
> Just wondering what others have done in cases such as this before I
have
>
> a chat with Perforce licensing.
>
>  
>
> Consolidating all the licenses into one big 'un and using a single
> server
>
> to authenticate everyone doesn't appear to be practical at this time
> though
>
> it is an attractive idea. (I see P4AUTH is still on the undoc list,
> though.)
>
>  
>
> -Wm
>
>  
>
>  
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>   

-- 
Stephen Vance
www.vance.com



More information about the perforce-user mailing list