[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