Configuring CVS

---

This section will describe how to configure CVS for server mode, once the standard CVS client tools have been installed. Password server-mode CVS works as a service that's run from the inetd "superserver." Configuring CVS for server access is as simple-and as tricky!-as correctly configuring inetd. As has already been noted, pserver mode is a rather insecure way to run a CVS repository. However, this section is as much about demonstrating how to configure an inetd service as it is about installing CVS, and so the pserver mode is demonstrated.

Unfortunately, different distributions sometimes use different versions of inetd; for example, Red Hat Linux uses the xinetd program, whereas Slackware Linux uses a more traditional Unix implementation. Whichever inetd implementation is used, it still has to run the same CVS command. The next few sections describe the configuration options related to CVS that are common to all implementations of inetd. The section "Installing CVS on Different Distributions" later in this chapter describes how to hook CVS and its server-mode parameters into the implementations of inetd on the three sample distributions.

The various compile-time options supported by CVS were discussed earlier in this chapter; see Table 12-1 for a list of these features. Notably, several options deal with authentication in server mode, such as Kerberos and simple password. This section will only discuss configuring a CVS server in normal password, or pserver, mode. Many distributions might not support some of the other modes (by not having Kerberos installed, for example), and pserver mode is the most common. Additionally, pserver mode is the simplest and makes the best example inetd installation. Consult the CVS documentation for information on other configuration options.

An installation of CVS in pserver mode consists of a few separate steps, described in the next section. These steps really go beyond what's strictly required to install an inetd service. However, every inetd service is going to have some kind of specific configuration requirements, like these steps or others. It's therefore useful to track the overall configuration of CVS-not just the inetd-related steps- to gain insight into general configuration techniques.

Creating the Repository Directory

The first step in the installation of CVS in pserver (or any other) mode is to create a directory for the data files. Recall that CVS encompasses the notion of a repository; this must be an actual directory where files that are checked in are stored, as well as the history of those files and various control information.

This directory can be located wherever is convenient. One possibility might be a subdirectory of the /opt or /usr/local directories. However, the Filesystem Hierarchy Standard (FHS) actually specifies a directory for such things as these databases: the /var directory. A reasonable choice then is the directory /usr/local/var/cvs. (The /usr/local/var directory was chosen over /var because, as was discussed in Chapter 7, most native package managers typically ignore the contents of /usr/local, treating it as system-specific material.)

The following simple command can be used to create the directory:

 % mkdir -p /usr/local/var/cvs 

The -p argument to the mkdir command instructs it to create not only the cvs directory, but also any of its parent directories that don't already exist. For example, there is frequently no /usr/local/var directory by default, so the preceding command would fail; with the -p option, the /usr/local/var directory will be created along with its child directory /usr/local/var/cvs.

Mission-Critical CVS Repositories

Using /usr/local/var (or even /opt/var, depending on taste) to hold CVS data is a good choice for a personal installation or for limited use. However, more important uses of CVS, such as those for organizations that actually produce software, have additional requirements, such as regular data backups and possibly failure tolerance and "hot backup" servers. After all, a CVS repository represents the master copy of whatever it manages; if you put all your eggs in one basket, it'd better be an extremely safe basket! Such users of CVS would likely place the CVS repository on a separate volume, partition, disk, server, and so on, and mount it as something like /cvs. Such users would also be sure to regularly back up the /cvs repository directory, and would also probably use one of the more secure CVS modes to better protect the server from attack.

Creating the User Accounts

Once the directory that is to house the CVS repository and related data has been selected and created, at least one user account must be created to access it. You can use a variety of ways to accomplish this task, and they are outlined in this section.

Relying on the System Accounts

CVS, by default, will grant access to any user who has a valid account on the underlying system. For example, any user with a valid user ID and password will be able to log in to and access the contents of the CVS repository (though that user would also have to have the correct Unix filesystem permissions). Thus, the simplest way to manage access to CVS is simply to pass the buck and let the standard operating system services handle it.

However, in this case, users will actually be logged in as themselves, and so they will be accessing the filesystem with their normal permissions. This might become a management burden, since file permissions are a little trickier to manage. (Setting up the file permissions for this example is covered in a later section.) Additionally, using this approach means that users literally have to have an account on the machine, meaning they can log into it, as well as use CVS; this may be a security risk if the machine is intended to be strictly a CVS server.

The upside of letting the system manage accounts is that it's easy to manage the users (simply because you don't have to manage them at all). The downside is that it's harder to manage file permissions and requires every CVS user to have an account on the system. This technique is most useful when the CVS pserver is to be used by a small workgroup and run on a server (perhaps a development server) to which all members of the group have access. It's less useful for larger projects with a more extensive user base.

Sharing a Single User Account

CVS provides an alternative to administrators who don't wish to defer authentication to the operating system. Instead, a single account can be set up for CVS, and it can even be an inactive account (that is, an account that doesn't permit logins). The CVS repository directory can be created to be visible only to this single real user, and the administrator can create multiple "phantom" accounts that are visible only to CVS.

This is accomplished by using CVS' local passwd file. This file is similar to the standard Unix /etc/passwd file, but is only used by CVS. The file allows administrators to map phantom CVS accounts to physical accounts. Users can be added to CVS simply by adding them to CVS' passwd file and mapping the phantom accounts to the single real account.

The upside of this approach is that it is a little more secure, since there is only one account to maintain, and the account can be granted restricted permissions to reduce the potential damage in the event of a security break-in. Also, the permissions on the repository directory itself are easier to manage, since there's only one physical account that needs access to it. The downside is that the administrators have to manage a CVS-specific passwd file. This approach is probably more appropriate for larger projects with many developers, with at least one person designated as an official CVS administrator.

This approach is the one taken by this book for the remainder of the example. In reality, it's also possible to use both techniques simultaneously, in a sort of hybrid mode. Setting up the permissions for both techniques and the procedures for adding users to the phantom CVS passwd file is covered in the next section.

Setting Permissions

This section will describe how to configure the permissions for the repository directory and give some details on how to manage user accounts. Each of the two cases previously outlined is discussed. The case where CVS' authentication is deferred to the operating system has more complicated repository directory permissions but simpler user administration, whereas the opposite is true of the virtual CVS accounts case.

Settings for the System Authentication Case

In the first case, CVS is configured to simply rely on the underlying operating system to handle authentication. That is, whenever a user logs in, CVS essentially just asks the operating system whether the username and password are valid. If they are, the process running CVS switches to that user identity and attempts to perform whatever CVS command the user requested.

This means the CVS server is actually running with the Unix permissions of the user account that logged in. That, in turn, means that if a particular user account doesn't have permission to read or write the actual CVS repository directory, then the account won't be able to access the installation of CVS!

So, the file permissions on the directory must be specified. Typically, installations in this case have three major properties:

• The repository directory is owned by a CVS-specific group in the /etc/group file (or another mechanism, such as the Network Information Service [NIS]).

• All users on the system who need access to CVS are included as members of the CVS group.

• The repository directory has permissions of group-readable and groupwritable, and has the sticky bit set.

The first property is easy to achieve. Most distributions come with tools for managing users and groups, and the chown or chgrp command can be used to set the group associated with a given directory. Once the group exists, a command like the following (which uses the example path of /usr/local/var/cvs) will change ownership of the directory to the group cvsusers:

 % chgrp -R cvsusers /usr/local/var/cvs 

The second property in the list is also easy to achieve. For standalone systems that use the /etc/passwd and /etc/group files for authentication, there are typically utilities (such as useradd and groupadd) for adding, deleting, and managing the contents of users and groups. This is a pretty basic task, so if you don't know how to do this, check the documentation for your distribution. Systems that are on a network may use another authentication scheme (such as NIS, Kerberos, or another PAM module) that has a different mechanism for managing groups and group members; if you think that this might be the case, you may have to contact your network administrators for assistance in creating a group in the appropriate manner.

The third property-setting the sticky bit on the directory-is likewise easy, but requires some explanation. You should be familiar with the traditional Unix file permissioning scheme: that is, there are three classes of access and four permissions that can be individually granted to each class. The classes are the account that owns the file (user), members of the group to which the file belongs (group), and everyone else (other). The chmod command is used to set permissions for each class, and the permissions are read, write, execute (which is used for executable programs and scripts, and to view the contents of a directory), and sticky.

The sticky permission (sometimes called sticky bit) denotes that the file is to retain the permissions set on it, no matter what happens. Usually, the sticky bit is used to indicate that an executable program is to be run as the user or group who owns the file, rather than the user who actually ran the program. (When used this way, the sticky bit is called the setuid bit.) When applied to a directory, however, the sticky bit means that all subdirectories and files that are created underneath the directory are to retain the same permissions as the directory itself. The correct permissions and the sticky bit can be set on the /usr/local/var/cvs directory via the following commands:

 % mkdir -p /usr/local/var/cvs % chgrp -R cvsusers /usr/local/var/cvs % chmod -R ug+rwx /usr/local/var/cvs % chmod -R ug+s /usr/local/var/cvs 

The -R parameter to chgrp and chmod instructs them to be "recursive" and repeat the command on all files and subdirectories contained within.

The reason it's important to use the sticky bit on the CVS repository directory is because there are multiple users, and the CVS pserver program actually runs as the individual users. If a user adds a file to CVS, the file is actually created and owned by the user who checked it in and will adopt that user's default permissions. This means that it's possible for one user to check in a file that's not accessible by another user, which is inconvenient, to say the least. Setting the sticky bit on the CVS repository directory overrides this behavior and forces any new files to have the same permissions as the /usr/local/var/cvs directory itself, preventing this problem.

Which User Owns the Repository

Astute readers may be wondering which user has to actually own the CVS repository directory (which is /usr/local/var/cvs in this example). That is, which user has to actually run the mkdir command to create the directory? Well, the beauty of the sticky bit technique is that it doesn't matter! The root user can create the directory, and as long as the sticky bits are set correctly, as in the example, then any user in the CVS group will have full access to the repository.

Once these basic conditions are met, the CVS repository directory is ready to be used (though of course the server itself is not quite configured yet; read on for the remaining steps). Remember, though, that deferring user authentication to the operating system is just one way that CVS can be managed; the next section covers the other case.

Settings for the Virtual Accounts Case

The second major authentication technique for a CVS pserver installation is to use a list of virtual users specific to CVS. In this case, only a single user needs to be created on the underlying operating system. Additionally, this user never needs a login shell, so the account can have an empty or otherwise disabled password, to prevent security risks from allowing in a remote user. Instead of having an account on the system, users of CVS have phantom or virtual accounts within CVS itself; the virtual accounts are mapped to the physical account on the system.

Setting up this scenario is quite simple. Since there's only one user, there doesn't need to be a separate user group, and there's no sticky bit silliness to manage. Instead, the repository is simply created and owned by the single real user account, and all the virtual CVS users are mapped to (and run with the permissions of) the physical account. So, setting up the repository directory is as simple as executing these commands:

 % mkdir -p /usr/local/var/cvs % chown -R cvs:cvs /usr/local/var/cvs 

This example assumes that the physical CVS username is cvs, and that a group is created for it, also called cvs. Not all distributions have a separate group for each user account; check your distribution's documentation for how to manage users and groups.

Adding virtual users to CVS is a bit more complicated. Once the CVS server is up and running, there is a special module named CVSROOT that users can check out. This directory contains various files that control how CVS behaves; one of those files is CVSROOT/passwd. This file contains usernames and passwords for the virtual accounts, and an additional field specifying the physical account name to which each virtual account corresponds. In this example, all accounts are mapped to the physical cvs user.

Unfortunately, managing the contents of the CVSROOT/passwd file (and performing additional administrative tasks) is getting beyond this discussion, which is simply focused on installing CVS. If you are interested, consult the documentation on CVS found at http://www.cvshome.org, especially the Cederqvist manual. The remainder of this section will focus on installing CVS pserver via the inetd service.

Using Hybrid CVS Authentication

These examples describe two ways to set up user authentication with CVS: either by deferring authentication to the operating system entirely or by mapping phantom CVS user accounts to an actual physical system account. In reality, this isn't an either/or proposition: CVS can be configured to operate in both modes at once. That is, CVS will always check the list of virtual accounts first; however, if the user isn't found there, it will then check with the operating system. This means that some users can be mapped to a physical account, whereas others can be left alone to log in through the operating system. This adds an additional layer of flexibility.

Establishing the Run-Time Parameters

The previous sections described how to decide on the values of various parameters that CVS requires to operate. The next step is to pull these parameters and values together into an actual command to run. This will be the command that the inetd server is configured to run for CVS connections, and this section will discuss how to formulate the specific command.

Really, it's quite simple. If you were to type the command to run CVS directly on the command line, it would have this general format:

 % cvs -f --allow-root=<path to CVS repository> pserver 

The key is the list of parameters. The -f argument instructs CVS to disregard any settings that may be in the user's ~/.cvsrc configuration file. This is important, because such options might change the behavior of CVS when running in server mode. The -allow-root parameter specifies the directory (or directories, since there can be more than one such parameter) of the CVS repository (which is /usr/local/var/cvs in this book's example). The pserver argument has no value and simply instructs the program (which normally runs as a client) to switch to server mode, using password authentication.

So, substituting in the repository path for this example, the specific command you need is as follows:

 % cvs -f --allow-root=/usr/local/var/cvs pserver 

This is the command that needs to be entered into the configuration for inetd. The precise mechanics of doing this varies by implementation of inetd. The next few sections discuss how to accomplish this on the sample distributions.

---