Simple configuration such as the installation and operation of cvs has been streamlined in the front http://qinshiqi.iteye.com/admin/blogs/2035529
Here is how to deal with cvs users and multi-libraries
Please read the instructions above first, then continue here:
1. CVS user management
For creating CVS access users, we have two options, which are described below.
1. Create a system user directly
#useradd -g cvsg user1 Create a system user and join the cvsg user group
#passwd user1 Add a password for the user
After creating a user, you can log in to access the cvs server through the client tool
Benefits: Basically no good...if If I have to find a few points, I can only say: the configuration is simple and trouble-free.
Disadvantage: If it is a work team with 20-100 people or more, it is necessary to create a system user for each individual. Even if it is set to not allow login by default, it will cause system resource consumption and increase management difficulty, and the most important point is this. The setting method is not professional and safe enough. If the cvs resource library is placed on the Internet, a large number of system users will become an unavoidable security risk, and it is impossible to talk about confidentiality.
2. All newly created cvs access users log in through the cvs management user
. The essence of this method is that when a new cvs user is created, the operating system user is not actually created, but the new user is authenticated by encryption. User login (that is, the cvsnew user we created earlier), we are creating the first cvsroot chwon operation, changing the owner of the cvs repository to cvsnew, the purpose is to allow the cvsnew user to have operations on all files in the repository permissions so that the new user can have full access to the repository through the cvsnew user.
After initializing cvsroot, there is a CVSROOT directory in the cvsroot directory. There are three user configuration files in this directory: passwd, writers, readers. We can subdivide management of user access rights through these three files. The following details how to cooperate These three files manage users.
1) User profile format introduction:
passwd: user list file for cvs users, its format is very similar to /etc/passwd file
[cvs username]: [encrypted password]: [equivalent system user]
readers: user list file with cvs read permission
A simple One-dimensional user list, one user name on one line, OK when
written
from top to bottom
2) Manually create user configuration files
Just after installing the cvs service, these three files may not exist, we can
enter the CVSROOT directory by manually creating #cd /usr/cvsapusic/CVSROOT
#touch passwd writers readers Manually create user configuration files
#chmod 770 passwd writers readers Modify the permissions and attributes of user configuration files
3) Create a new cvs user
#cd /usr/cvsapusic/CVSROOT Enter the CVSROOT directory
# htpasswd passwd user1 Create a cvs user by encrypting and verifying the passwd file
Create a cvs user by encrypting and verifying the passwd file. If htpasswd is not installed, please install yum info httpd
(We don't need to care about how to encrypt and verify, just know the operation method~~)
New password:xxx Enter the new user password
Re-type new password:xxx Confirm the password
Or generate a password through http://qinshiqi.iteye.com/admin/blogs/2036738
4) Edit the user
#cat passwd View the user list file
user1:.tW.1auR7dD/I The user has been created and encrypted as shown in the example
#vi passwd Edit user
user1:.tW.1auR7dD/I:cvsnew Add a colon after the user password and the equivalent system user of cvsroot to
save and exit. At this point, the creation of a new cvs user is completed. You can log in to the cvs server through the client tool to cvs Access the resource library.
5) Deleting a user
Deleting a user is also easy, just edit the passwd file, delete the corresponding user entry, save and exit, and I won't introduce it here.
6) Assign permissions to each cvs user.
If the user is not added to the writers or readers table after the new user is created, the user has all permissions by default, including check out, commit, and delete.
For example, if you want user1 to only have the permission to read the cvs repository, you can edit the readers table and add user1.
For example, if you want user2 to have the permission to read and write the cvs repository, you can edit the writers table and add user2
#vi readers
user1
user3
user4
...
#vi writers
user2
user5
...
Advantages: The operation is very simple and the function is very powerful. This is the typical user management configuration method of the cvs server. It is recommended that everyone choose this method.
Cons: Takes a little more time
Note: If the user is not added to the writers or readers table after the new user is created, the user has all permissions by default, including check out, commit, and delete. I tested it myself and found the following :
1. Passwd must be required, if not, the user will not have any permissions
2. Readers feel that users who write or not have read and checked permissions
3. If writers exists, the user has only read-only permission. If it does not exist, all users have read-write and submit permission.
Note: See here, the above configurations are a workspace, a passwd, a reader, a writer. In many enterprises, employees are fixed, but some projects do not have permission to access, so the password table can share a set of passwords, so We can create a passwd file under /cvsroot/, and then create a shortcut to passwd (a link address) under each workspace
2. Establishing multiple source code repositories for cvs server
I just described how to configure the path of cvsroot by modifying cvspserver, but there will be multiple cvsroot requirements in software companies, requiring each resource repository to be independent and inaccessible to each other. method to achieve.
to create directories:
# mkdir -p /cvsroot/doc
# mkdir -p /cvsroot/source
authorization
[root@localhost /]# chmod 775 -R /cvsroot/doc
[root@localhost /]# chmod 775 -R /cvsroot/source
[root@localhost /]# chown cvsroot:cvsg -R /cvsroot/doc
[root@localhost /]# chown cvsroot:cvsg - R /cvsroot/source
init
root@localhost /]# cvs -d /cvsroot/doc init
[root@localhost /]# cvs -d /cvsroot/source init
Method 1, directly modify the /etc/xinetd.d/cvs file ( cvspserver )
[root@localhost CVSROOT]# cat /etc/xinetd.d/cvs
# default: off
# description: The CVS service can record the history of your source \
# files. CVS stores all the versions of a file in a single \
# file in a clever way that only stores the differences \
# between versions.
service cvspserver
{
disable = no
port = 2401
socket_type = stream
protocol = tcp
wait = no
user = root
passenv = PATH
server = /usr/bin/cvs
# env = HOME=/home/cvsroot
server_args = -f --allow-root=/home/cvsroot --allow-root=/cvsroot/doc --allow-root=/cvs/root/source pserver
# bind = 127.0.0.1
# only_from = 192.168.0.0/24
}
The following parameters can be added as needed
log_on_failure += USERID
only_from = 192.168.0.0/24
flags = REUSE
It can be seen from the above that adding the resource library path is actually modifying the server_args item, provided that the path to the resource library exists.
.Restart the xinetd service for verification
# service xinetd restart
Method 2, cvs file redirection
Due to the limited length of server_args in xinetd, we can do the following to redirect the cvspserver file
service cvspserver
{
disable = no
port = 2401
socket_type = stream
protocol = tcp
wait = no
user = root
passenv = PATH
server = /cvsroot/cvs.run
# server = /usr/bin/cvs
# env = HOME=/home/cvsroot
# server_args = -f --allow-root=/home/cvsroot --allow-root=/cvsroot/doc --allow-root=/cvs/root/source pserver
# bind = 127.0.0.1
# only_from = 192.168.0.0/24
}
To avoid other unforeseen errors, comment out the original server, server_args, log_on_failure and other configuration items, and add a new line of code server = /cvsroot/cvs.run (path is optional).
1) Create and write cvs.run file
# cd /usr/local/bin
#touch cvs.run
# chmod 770 cvs.run
cvs.run must be executable
Manually write the contents of the cvs.run file as follows:
# vi cvs.run
#!/bin/bash
/usr/bin/cvs -f \
--allow-root=/home/cvsroot \
--allow-root=/cvsroot/source \
--allow-root=/cvsroot/doc \
pserver
You can fill in all cvs source code warehouse paths in the cvs.run file, save and exit after writing, so that all cvs resource paths are centralized in one file management.
[root@localhost cvsroot]# vi cvs.run
#!/bin/bash
/usr/bin/cvs -f \
--allow-root=/home/cvsroot \
--allow-root=/cvsroot/source \
-- allow-root=/cvsroot/doc \
pserver
~
[root@localhost cvsroot]# service xinetd restart
Stopping xinetd: [ OK ]
Starting xinetd: [ OK ]
3. Now the CVS user management of each resource library is independent, and only system users can connect three libraries at the same time.
In this way, the mutual independence of the resource library is realized.
If you want to manage files with the same set of users, you can use shortcuts
[root@localhost /]# cd cvsroot
[root@localhost cvsroot]# cd doc
[root@localhost doc]# cd CVSROOT
[root@localhost CVSROOT]# ln -s /home/cvsroot/CVSROOT/passwd passwd
[root@localhost CVSROOT]# ln -s /home/cvsroot/CVSROOT/passwd /cvsroot/source/CVSROOT/passwd
1 |
touch passwd writers readers |
1 |
chmod 777 passwd writers readers |
The file does not have permission to operate
[root@localhost CVSROOT]# pwd
/cvsroot/source/CVSROOT
[root@localhost CVSROOT]# vi writers
yfeife
***********************************************
A more comprehensive article with pictures and texts
http://my.oschina.net/linjunlong/blog/120816
http://linjunlong.com/p/589.html
http://blog.csdn.net/lidongtang/article/details/8165574