一般剛裝完p4,要進行以下幾步的配置:
1. execute "p4 passwd" to set administrator's password.
初始狀態administrator是沒有密碼的,所以一開始你要做login,肯定就會告訴你You don't have permission for this operation. set完password之後,p4 login就好了.
2. execute "
p4 counter -f security 1" for security level setting.
預設security level是0,也就是說,使用者不需要任何密碼也可以建立並登陸.此選項一共有0,1,2,3四個選項,我在後面附上每一項的詳細解釋(1),這裡一般選擇1就可以了.
3. 這裡插一句,如果在上面一步出現You don't have permission for this operation.提示的話,說明之前已經有其他使用者進行過"p4 protect"操作.意思就是已經有別的使用者搶奪了superuser許可權並且把其他人的許可權都鎖定在superuser以下.這時候很簡單,你只要把perforce安裝目錄下面db.protect檔案刪掉就好了.之後security protect就解除了.
4. execute "p4 protect" to create Protections Specification for security protected.
這回輪到我執行"p4 protect"了,呵呵,執行之後會彈出一個記事本,這回讓我們來自己描述Protections Specification.看最後面兩行,如果是新建立的,p4會將目前使用者定義為superuser,其他所有使用者都為wirte 許可權.
例如: super user administrator * //...
write user * * //...
最前面的單詞是表示要分配的許可權(之後我會附上所有許可權的詳細解釋(2)),之後的user可以有兩種選擇user/group,意思就是要分配給使用者還是分配給組,之後就是使用者名稱或者組名了,如果是*的話,就是所有使用者啦,當然也包含新建立的使用者.如果到這裡關閉記事本儲存的話.基本配置就已經完成了.但是還有一個問題沒有解決.就是任何人都可以隨意的建立write許可權的使用者.這就要進行下一步了.
5.記得上一步預設自動向Protections Specification裡面添加的"write user * * //..."這一句嗎?呵呵,裡面的使用者名稱的位置被一個*星號取代,意味著所有使用者包括新建立的使用者都具有write許可權,當然導致任何人都可以自動建立不存在的使用者而自動獲得write許可權.在這裡只要把Protections Specification裡面的"write user * * //..."刪除,然後依次添加其他合法成員的許可權配置就ok.如果以前人數太多,添加太麻煩,那可以添加一個組,將許可權分配給這個組,然後把所有成員歸屬到這個組裡面就ok啦.這種實現辦法我也附在後面啦(3).
到這裡為止,我的問題基本就解決了,這個時候再用p4的client在未授權下去建立新使用者,都會得到You don't have permission for this operation.的反饋.之前的我被添加的一大堆亂七八糟的使用者怎麼辦呢,執行"p4 users"得到列表,用"p4 user -d username"一個個刪除吧.如果是superuser,可以用-f參數強制移除,就像這樣:"p4 user -d -f username".
附:
(1)
-----------------------------------------------------------------------------
Server security levels
Perforce superusers can configure server-wide password usage
requirements, password strength enforcement, and supported
methods of user/server authentication by setting the security
counter. To change the security counter, issue the command:
p4 counter -f security seclevel
where seclevel is 0, 1, 2, or 3. After setting the counter, stop
and restart the server.
Choosing a server security level
The default security level is 0: passwords are not required, and
password strength is not enforced.
To ensure that all users have passwords, use security level 1.
Users of old client programs can still enter weak passwords.
To ensure that all users have strong passwords, use security
level 2. Old Perforce software continues to work, but users of
old Perforce client software must change their password to a
strong password by using a Perforce client program at Release
2003.2 or above.
To require that all users have strong passwords, and to require
the use of session-based authentication, use security level 3 and
current Perforce client software.
Level 0 corresponds to pre-2003.2 server operation. Levels 1 and
2 were designed for support of legacy client software. Level 3
affords the highest degree of security.
The Perforce server security levels and their effects on the
behavior of Perforce client programs are defined below.
Security level
Server behavior
0
(or unset)
Legacy support: passwords are not required. If passwords are
used, password strength is not enforced.
Users with passwords can use either their P4PASSWD setting or the
p4 login command for ticket-based authentication.
Users of old Perforce client programs are unaffected.
1
Strong passwords are required for users of post-2003.2 Perforce
client programs, but existing passwords are not reset.
Pre-2003.2 Perforce client programs can set passwords with p4
passwd or in the p4 user form, but password strength is not
enforced.
Users with passwords can use either their P4PASSWD setting or the
p4 login command for ticket-based authentication.
2
All unverified strength passwords must be changed.
Users of pre-2003.2 client programs cannot set passwords.
Users of client programs at release 2003.2 or higher must use p4
passwd and enter their passwords at the prompt. Setting passwords
with the p4 user form or the p4 passwd -O oldpass -P newpass
command is prohibited.
On Windows, passwords are no longer stored in (or read from) the
registry. (Storing P4PASSWD as an environment variable is
supported, but passwords set with p4 set P4PASSWD are ignored.)
Users who have set strong passwords with a 2003.2 or higher
Perforce client program can use either their P4PASSWD setting for
password-based authentication, or the p4 login command for
ticket-based authentication.
3
All password-based authentication is rejected.
Users must use ticket-based authentication (p4 login).
If you have scripts that rely on passwords, use p4 login to
create a ticket valid for the user running the script, or use p4
login -p to display the value of a ticket that can be passed to
Perforce commands as though it were a password (that is, either
from the command line, or by setting P4PASSWD to the value of the
valid ticket).
Password strength
Certain combinations of server security level and Perforce client
software releases require users to set "strong" passwords. A
password is considered strong if it is at least eight characters
long, and at least two of the following are true:
The password contains uppercase letters.
The password contains lowercase letters.
The password contains nonalphabetic characters.
For example, the passwords a1b2c3d4, A1B2C3D4, aBcDeFgH are
considered strong.
--------------------------------------------------------------------
(2)
--------------------------------------------------------------------
Disabling User Auto Creation
How do I disable automatically creating users?
Perforce's default behavior is to automatically create users if
they don't currently exist when they first log into Perforce,
until the server reaches the number of users determined by their
current license. A Perforce server administrator may want to
disable this feature to avoid unnecessarily creating user
accounts in Perforce.
DETAILS
You disable user auto-creation by removing all generic "user"
protections (user protections using the "*" wild card for the
user name) from your Perforce protections table and using
"groups" and individual instead. In this example, the Perforce
administrator wants to give everyone write access to the depot
while keeping a specific "super" user account:
Save a list of all your users. Unix based systems or Windows
systems with Cygwin installed can use this command:
p4 users | cut -d " " -f 1This will create a list of user names
you can cut and paste or save to a file.
Create a group for all of your users:
p4 group all_usersThe group specification will open in your
default editor.
Add the list of users to the "Users" field of the group
specification.
Save the group and quit the text editor.
Open your Perforce protections table:
p4 protectThe protections table will open in your default editor.
Add a line to the protections table for the new group:
write group * //... Delete the line that grants all users any
access to the depot similar to:
write user * //... Don't grant any permissions to all users
("user *"). Grant permissions only to groups and individual users
, and user "group * " as a substitute for "user *".
--------------------------------------------------------------------
(3)
--------------------------------------------------------------------
# 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 being granted. Each permission includes
# all the permissions above it, except for 'review'.
#
# 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
#
# super - allows access to the 'p4 protect' command
#
# review - allows access to the 'p4 review' command; implies
# read access
#
# 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.
#
# Path: The part of the depot being granted access.
Protections:
super user fansy * //...
write user line * //...
write user cfy00 * //...
super user administrator * //...