Installing and Configuring CVS
Introduction
This document focuses on installing and configuring CVS on RedHat Linux as an SCM Repository for
WSAD 5.0. WSAD (hereafter called Application Developer) works seamlessly with CVS, the dominant
open-source, network-transparent version control system. CVS runs on most platforms, including
Windows, Linux, AIX, and UNIX. However the most stable platform and the most used platform are
Linux and Unix. Windows is not very stable at this time.
Installing it with Application Developer on RedHat Linux has several advantages:
Linux is now the dominant open-source operating system.
RedHat is one of the major distributors of Linux.
CVS is included in the RedHat Linux distribution.
CVS for Linux is stable, reliable, and scalable, and is useful for individual developers and
small teams as well as large, distributed teams.
Application Developer runs on RedHat Linux.
When using Application Developer, you can use CVS as a local repository or as a shared
repository for the entire team.
However, installing and configuring CVS for Linux is not trivial and there is little good
documentation available. The step-by-step instructions below should help system
administrators configure CVS for Linux for developers using Application Developer.
note: CVS comes standard on Redhat 7 and higher. The installation instructions for WSAD
4.0 and WSAD 5.0 are the same serverside; the client view superficially. Redhat 7 to Rehat 9
are similair with regards to CVS - there should be no conflicts and very little extra instructions
when using Redhat 9.
Install CVS on RedHat Linux
To check to see if your version of Redhat has CVS installed, enter the command rpm -qa|grep
'cvs'. If the return is cvs-*.**.***, it means that CVS is already installed.
If the command returns nothing, you need to install CVS. The CVS rpm is normally on Installation CD
#2 of the RedHat Linux distribution in the directory RedHat/RPMS. After you mount the CD to
/mnt/cdrom, use the rpm command to install CVS: rpm -i /mnt/cdrom/RedHat/RPMS/cvs-
*.**.***-*.i386rpm
Set up the CVS user accounts and groups
1. Log in as root.
2. Create a user named cvs, with a primary group cvs (refer to the “adduser” command).
3. Create users who will use cvs in Application Developer. This article uses cvsdev1 and
cvsdev2.
4. Developers who use cvs can use their private groups as their primary groups. For example,
cvsdev1's primary group is cvsdev1, but make sure that they also belong to the cvs group.
Set up the folder and repository
1. Log in as user cvs.
2. Create a directory named repository under its own home directory, which is /home/cvs.
3. Set the access level and access mode of directory /home/cvs/repository: chmod 770
/home/cvs/repository
4. Set setgid bit on directory /home/cvs/repository: chmod g+s /home/cvs/repository
Explanation: when a file is created in a directory, it belongs by default to the primary group of
the owner. With the setgid bit set on the directory, new files will belong to the same group as
the directory instead of to the owner's primary group. For example, if user cvsdev1 creates
files in the directory /home/cvs/repository, those files will belong to the cvs group instead
of to its primary group cvsdev1.
This step is crucial because it lets CVS users check out files created by other users. If this
step is not completed, then when you check out a file created by another user, the operation
will fail with this message:
Failed to create lock directory for /home/cvs/repository/...: Permission denied.
Failed to obtain dir lock in repository /home/cvs/repository/...
5. Initialize the repository:
cvs -d /home/cvs/repository init
6. Log out user cvs.
Modify xinetd service to enable pserver protocol
1. Log in as root.
2. Create a file named cvspserver in directory /etc/xinetd.d with this content:
# default: off
# description: An cvs server.
service cvspserver
{
disable = no
socket_type = stream
protocol = tcp
user = root
wait = no
server = /usr/bin/cvs
server_args = -f --allow-root=/home/cvs/repository pserver
log_on_success +=USERID
log_on_failure += USERID
}
3. Open /etc/services and verify that these two lines are present. If they are not, add them:
cvspserver 2401/tcp # CVS client/server operations
cvspserver 2401/udp # CVS client/server operations
4. Restart xinetd service:
service xinetd restart
Set up user environment
1. Open the file /etc/profile. You should to see these lines in the file:
USER='id -un'
LOGNAME=$USER
MAIL="/var/spool/mail/$USER"
2. Add one line after the environment variable MAIL.
CVSROOT=":pserver:$USER@localhost:/home/cvs/repository"
3. In the file, you should also see a line like this:
export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE INPUTRC
4. Modify it and add CVSROOT into the export list like this:
export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE INPUTRC CVSROOT
Extra Information regarding installation
When using WSAD 5.0 to access the CVS server, it is recommend that the “extsh” protocol be used. It is built
using encryption and is built on top of the standard “pserver” protocol. It was not available on earlier versions of
WSAD, but greatly increases security.
Maintenance of CVS
CVS needs minimal maintenance. Backups can be made weekly or biweekly or any interval that is comfortable
with the developers. Backups can be used with the “tar” command. It is recommended that all files which are tar
retain their user permissions. At minimal the repository directory, /user/cvs/repository, and its’ sub-directories.
At most, all directories should be backed up. Currently a crontab job is used. The script is located @
“/home/eleison/backup.sh”. For more information refer to the following:
http://ccvs.cvshome.org/fom//cache/234.html
For general information regarding CVS:
http://www.cvshome.org/
Current connection setting:
Host: cica_cvs.combined.com
Port: Default
Repository path: /home/cvs/repository
For secure CVS, change the users passwd and groups files. Passwd should use the new
shell described below (/bin/cvsShell) with –rwxr-xr-x permissions.
#! /usr/bin/perl -w
#
# $Id: cvssh.pl,v 1.3 2002/06/09 13:48:46 ksoonson Exp $
#
# "Shell" for a restricted account, limiting the available commands
# Roland Mas, debian-sf (Sourceforge for Debian)
#
# Inspired from the grap.c file in Sourceforge 2.5
use strict ;
use vars qw/ @allowed_options @allowed_commands $errmsg @cmd / ;
use subs qw/ &reject / ;
no locale ;
@allowed_options = ('-c', '-e') ;
@allowed_commands = ('cvs','scp') ;
# Clean up our environment
delete @ENV{qw(IFS CDPATH ENV BASH_ENV PATH)};
if ($#ARGV != 1) {
if ($#ARGV < 1) {
$errmsg = "Not enough arguments." ;
} else { $errmsg = "Too many arguments." ;
} &reject ;
}
if (scalar (grep { $_ eq $ARGV[0] } @allowed_options) == 0) {
$errmsg = "Option not allowed." ;
&reject ;
}
@cmd = split (/ +/, $ARGV[1]) ;
if (scalar (grep { $_ eq $cmd[0] } @allowed_commands) == 0) {
$errmsg = "Command not allowed." ;
&reject ;
}
exec @cmd ;
sub reject {
print "This is a restricted account.\n" .
"You cannot execute anything here.\n" .
# $errmsg . "\n" .
"Goodbye.\n" ;
exit 1 ;
}
In the “group” file the user should be included in the cvs group…