CVS Server Configuration
If you have already have a CVS repository on your system, this
page explains how to make it available to other hosts by setting
up a network-accessible CVS server.
Introduction to CVS
CVS stands for Concurrent Versions System, and is set of programs
that allows multiple developers to work on the same source code
without interfering with each other. This chapter assumes that
you are already familiar with the workings of CVS, and want to
know how to set up a server that allows a repository to be accessed
over the network. A server like allows people to check out code
to their personal computers, work on it, and then check it back
in again over the network.
There are actually several ways of making a repository network-accessible,
such as via SSH or RSH. The method that Webmin supports is the running
of CVS in pserver mode from a super-server like inetd or xinetd.
There is no actual separate CVS server process that runs all the
time in the background, like Apache or an NFS daemon. Instead,
the cvs program is run by inetd only when a client cvs program connects
to it.
To control who can access files, a CVS server uses username and
password authentication. The supplied login can be checked
against the system Unix user list, or a separate file of usernames
and passwords. Users can be given full read-write access to the
repository, or read-only access to prevent them from checking
in files.
The CVS Server module
This module can be found in Webmin under the Servers category.
When you enter it, the main page displays a list of icons as shown
in the screenshot below. Almost all of the actual forms and pages for configuring
the server can be reached by clicking on the icons.

The CVS server module
If a CVS repository is not found on your system, the main page will
display an error message instead. By default, Webmin looks in
/usr/local/cvsroot, but this is unlikely to be correct on most
systems. To change the path, click on
Module Config and update
the
CVS root directory field.
The module's main page can also display an error message if the
cvs command is not found on your system, or if its version number
cannot be determined. If the command is not in Webmin's search
path, you will need to adjust the
Path to cvs executable field
on the module configuration page.
Setting up the CVS server
If the CVS server has not yet been set up on your system, a button
labelled
Setup CVS Server will be displayed at the bottom of
the module's main page. When clicked, an entry will be added to
the inetd or xinetd configuration (covered in chapter 15) to
run the server program cvs pserver on the standard TCP port 2401.
The current CVS root directory will be supplied as a parameter
to this command, so make sure that it is set correctly before clicking
the button. Clients should now be able to connect to the repository,
as explained in the section on
Using the CVS server.
The server is always set up to run as a service called cvspserver,
which runs as root with no IP access control restrictions. If
you are using xinetd, the Extended Internet Services module
can be used to restrict access to the service. Because most repositories
only need to be accessible to CVS clients on a company network,
this is usually a good idea. It is also possible to control access
to the service if you are using inetd through the use of TCP-wrappers,
but that must be done manually.
When the server is active, the button will be replaced with one
labelled
Deactivate CVS Server instead. If clicked, the appropriate
entry in the inetd or xinetd configuration will be disabled so
that clients can no longer connect. To enable it again, hit the
Activate CVS Server button that will appear on the main page
instead.
If you have both xinetd and inetd installed, then the former will
be used when setting up the server for the first time. When setting
up, activating or deactivating the server, the module will automatically
signal inetd or xinetd to re-read its configuration file, so
there is no need to click the
Apply Changes button in the appropriate
module.
Using the CVS server
Once your server is running, CVS clients can connect to it using
a repository path like :pserver:_username_@_hostname_:_repository_.
Naturally,
username must be replaced with the name of a user
that the CVS server accepts,
hostname with the hostname of
your system and
repository with the correct repository directory.
To check out a directory, you could run commands like :
CVSROOT=:pserver:jcameron@fudu.webmin.com:/usr/local/cvsroot
export CVSROOT cvs login cvs checkout path/to/directory
The cvs login command should only be run if the server requires
a password for the username. It will prompt you for a password,
which is stored permanently in the file ~/.cvspass for use by
other CVS commands in future. Any time the cvs command is run on
update, check out, commit to or access the repository in any way,
it will make a connection to the server specified in the CVSROOT
environment variable, and login with the username from the variable
and the specified password.
Adding and editing users
The CVS server requires that all clients supply a valid username
and password before they can perform any operations on the repository.
Users are authenticated against a list of accounts used only
by the server, and optionally against the standard Unix user
database from the /etc/passwd and /etc/shadow files. Using
only the server's user list for authentication is the best option,
as it gives you more control over who is allowed to connect. See
the documentation for the *Check users against system password
file?* field in the
Configuring the CVS server section for
more information on turning on or off Unix authentication.
You can specify for each CVS user the name of a Unix user whose permissions
will be used for all file access. This can be useful if all files
in your repository are owned by a single user, in which case all
CVS access should be done as that user. This avoids the problem
of ensuring that file permissions in the repository are set correctly
so that people can edit and read each others' files.
To add a new login to the CVS user list, the steps to follow are :
- On the module's main page, click on the CVS Users icon. This will take you to a page containing a table of all existing users, as shown in the screenshot below.
- Click on the Add a new CVS user link above or below the table to go to the user creation form.
- Enter a unique name for the user into the Login username field. A Unix user of the same name must already exist � if not, the Access files as Unix user field must be set.
- The Login password field is for entering the user's password. The available options are : *None required *If selected, the CVS server will accept any password or none at all when a client connects as this user. *Copy from Unix *If chosen, the user's password is initially set to that of the Unix user with the same name. *Set to *If selected, you must enter a password for the user into the field next to it.
- The Access files as Unix user field controls which Unix user the CVS server will switch to when this CVS user connects. If Same as username is selected, then the Unix user with the same name will be used. However, if the other option is chosen you must enter a Unix username into the adjacent field to access files as instead.
- Click the Create button to have the user added to the server's list. You will be returned to the table of users, which should include your new entry. If you chose for it to access files as a different Unix user, the its name will be shown in brackets next to the CVS login name.

The CVS users list
Once a user has been created, you can edit it by clicking on its
name in the table on the CVS Users page. The editing form is the
same as the one user for user creation, except that the *Copy from
Unix* option in the
Login password field is replaced with *Leave
unchanged* which must be selected if you are not changing the
password. When you are done editing a user, click the
Save button.
Or to delete the user, click on
Delete on the editing form instead.
This page can also be used to set up synchronization between the
CVS user list and the Unix user database. This can be useful for
keeping passwords in sync, or for having a CVS user deleted when
the corresponding Unix user is removed. Chapter 4 explains in
more detail how user synchronization works in Webmin, but to
set it up for this module the steps to follow are :
- On the main page, click on the CVS Users icon and then scroll down to the form below the list of existing users.
- To have a new CVS user created for each Unix user created in Webmin, select the Add a new CVS user when a Unix user is added checkbox. Below it is a field labeled Access files as Unix user that you can use to set the Unix access user for automatically created CVS users. This option is most useful when all users access repository files as a single Unix user. Otherwise you might as well just allow all Unix users to login to your CVS server.
- To have the password or username of a CVS user changed when the corresponding Unix user is updated, check the Update a CVS user when the matching Unix user is modified checkbox.
- To have a CVS user deleted when the Unix user of the same name is removed, check the *Delete a CVS user when the matching Unix user is deleted *box.
- Click the Save button to save the new synchronization settings. They will apply to users created, edited and deleting in the Users and Groups module from now on.
Limiting user access
This section explains how to configure the CVS server to limit
which users are allowed to write to the repository. This can be
useful if you want to give anyone on the Internet access to your
source code, for example if you are hosting an open-source project.
A user with no password but read-only access could be created
for anyone in the world to login as, while developers login with
password-protected accounts that have full read-write privileges.
The steps to restrict write access to your server are :
- On the module's main page, click on the User Access Control icon. This will take you to a form listing users who current have read and write access.
- To give read-only access to only a few users and read-write to the rest, select the Listed users are read-only *radio button. Then enter the names of those users who should not be able to write to the repository into the left-hand text box below. On the right, the option *All users can write should be selected. Alternately, to give read-write access to a few users and read-only to everyone else, select Only listed users can write. Then enter the names of those users who will be able to write to the CVS repository into the right-hand text box. On the left, No read-only users should be selected. There is not much point entering usernames into both boxes, as any user who is in both lists will be given read-only access.
- Click the Save button to make your changes immediately active and return to the module's main page.
Configuring the CVS server
There are a few options related to authentication and logging
that can be set for the CVS server. In most cases the defaults will
work fine, but you can change them by following these steps :
- On the main page of the module, click on the Server Configuration icon to go to a form for editing server options.
- To allow any Unix user to login to the server, set the Check users against system password file? field to Yes. If No is selected, only those users defined on the CVS Users page will be able to access the repository.
- The Event types to log in history field controls what kind of client activity is logged to the CVSROOT/history file. You can either select All types to log everything, or Selected types to log the kinds of events that are checked below.
- To change the directory that CVS puts lock files in, edit the Lock files directory field. This is necessary if you have read-only users who cannot write to the repository, as when Default is selected lock files will be created within the repository itself.
- Click the Save button to have the server begin using the new settings.
Browsing the repository
One handy feature of the CVS Server module is the ability to view
files and directories in the repository. You can do this by clicking
on the
Browse Repository icon on the module's main page, which
will take you to a page listing the contents of the repository
root directory. A list of modifications to a file can be viewed
by clicking on its name, and the latest checked-in version displayed
by clicking on the number under the
Rev column.
The listing can be sorted by clicking on column headings, such
as
Age or
Author. Below the listing is a menu labelled *Show
only files with tag* for restricting the listing to files tagged
with the chosen name. Tags are often used to identify code for
a branch or version of a project, or from a particular source.