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.
|Note:||CVS is a bit outdated and is being replaced by SVN which in turn is being replaced with GIT|
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 screen shot 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 labeled [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:email@example.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 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 labeled 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.