A single system username can be shared by multiple users with different CVS''''usernames. This can be used to allow several people to work on a project and record the changes across multiple users. (Of course, this could also be done with group permissions.) If appropriate for your security needs, you can restrict the system usernames so that they can only run CVS.

+

A single system username can be shared by multiple users with different CVSusernames. This can be used to allow several people to work on a project and record the changes across multiple users. (Of course, this could also be done with group permissions.) If appropriate for your security needs, you can restrict the system usernames so that they can only run CVS.

The ''passwd'' file should be edited in place; it should not be checked out to sandboxes.

The ''passwd'' file should be edited in place; it should not be checked out to sandboxes.

Most projects involve a repository on a different machine than the client. This chapter discusses remote repositories, access methods, how to set up each access method, and security considerations for each type of access.

This chapter also discusses the two access methods for local repositories: local and fork. fork represents a way to access a local repository as if it were a remote repository.

CVS can operate equally well as a single program that handles both the sandbox and the repository or as a pair of programs — a client managing the sandbox and a server managing the repository.

CVS can run as a single program if both sandbox and repository are on the same computer or if the repository is on a file server and the computer the sandbox is on perceives the shared directories as local.

If your file server or networking filesystem changes files in transit, the changes can corrupt the CVS data. This corruption can be subtle enough that it doesn't show up for weeks or months.

If you have a personal repository for private work, you may choose to keep the repository on the same computer as your sandbox. If you are sharing a mainframe with several other people, you may have a shared repository on the same mainframe as your sandboxes. In such situations, be particularly careful to back up the repository. When the repository and the sandbox are on different computers, each acts as a partial backup of the other. When they are on the same computer, that inherent backup is not available.

Specifying Repository Paths

Whenever CVS runs a command from a client, it needs to know where to find the CVS repository. The address of the repository is called the repository path . CVS looks for repository paths in the sandbox, the CVSROOTenvironment variable, and the -d repository_path command option.

If you run a CVS command from within a sandbox, CVS uses the repository path that is stored in the sandbox. When a sandbox is not available — such as when you're creating a sandbox or issuing a command from outside a sandbox — you must specify which repository you are attempting to access. You also need to specify the repository path if you are in a sandbox but wish to access a different repository than the one the sandbox uses.

You can specify a repository path from the command line with the -drepository_pathoption, or you can specify it with the CVSROOT environment variable. CVS uses the path given with the -d option in preference to the path in the sandbox, and it uses either the sandbox or the -dpath in preference to the path in the environment variable.

Tip

The rtag, rlog, rdiff, rannotate, and export commands can run without a sandbox. If these commands are run outside a sandbox, they need either the -d option or the CVSROOT environment variable.

For connecting to a local machine as if it were a remote machine (useful if you are trying to diagnose problems).

server

For the internal rsh server, available only on some operating systems (including Windows).

gserver

For connections through the GSS-API (currently Kerberos 5.0).

kserver

For connections through Kerberos 4 and earlier.

pserver

For the pserver (built-in password server) connection method.

Everything except the path itself can be left out of a repository path definition.

If the method is left out, and the host is not included or is the local host, CVS uses the local access method. If the method is left out but the host is included, CVS uses either the server or the ext methods, depending on whether an internal rsh server is available. If user is left out, CVS uses the username in the current environment. If password is left out and required, CVS asks for it. If the port is left out and the method requires a port, CVS uses the default port for that method. (The default port for each access method is given in the following sections on each method.) If the host is left out, localhost is assumed.

Tip

If you put a colon immediately after the username, CVS attempts to connect with an empty password.

If an element of the repository path is included but not needed for the current method, CVS displays a message stating which element is not necessary.

The local Access Method

If your repository is on the same computer as your sandbox (or the sandbox you want to make) or on a shared filesystem that is accessed as if it were a local partition, you can use the localmethod to access the repository.

For the local access method, the repository path format is:

[:local:]/path

When running a command that requires an explicit path declaration, put the repository path in your CVSROOT environment variable or use the path as the argument to the -d repository_pathoption. You will most likely need this path declaration when creating a sandbox, but it is also necessary for cvs exportand cvs rtag.

Tip

If you just enter the directory path with no hostname or method declaration, CVS uses the local access method.

With local access, CVS does not run in client/server mode. One program manages both the sandbox and the repository. The program runs under the username that it was called with, and it has the access permissions of that user. Any programs CVS calls (such as programs called from a scripting file) run with the same username and access permissions.

If local access mode is being used on a single-user computer, security normally is not an issue. On shared filesystems or mainframes, your repository security problems are the same as the usual security issues for file sharing. Use the security services of your operating system to secure a shared repository that is accessed with the local method.

Example 8-1 shows how to check out a sandbox using the local access method.

The ext and server Access Methods

In my experience, ext is the most commonly used access method, and it is usually used with SSH. ext stands for external, which refers to an external (to CVS) rsh or remote shell program. This method uses a remote shell program to connect the sandbox client computer to the repository server computer. The server method is almost the same as the ext method. The only difference is that server uses a remote shell program that is included with CVS.

To use a program other than rsh with the ext connection method, the CVS_RSH environment variable on the client should be set to the name of the program and the directory containing the program should be in the user's PATH on the client computer. Alternatively, you can set the CVS_RSH environment variable to the absolute path to the program, without modifying the PATH variable.

ext accepts any command line-based program that can be called with the following syntax:

program [-b] [-l username] host commands

The program must run the commands in a remote shell and pipe standard input (stdin) and standard output (stdout) without filtering the content. The -b is necessary only if the program is running on OS/2 and is used to force rsh to run in binary mode, without end-of-file conversion. The-lusername is used (by CVS) only if there is a username included in the repository path.

For the ext access method, the repository path format is:

[:ext:][user@]hostname[:]/path

The user needs to have a username on both the client computer and the server computer. If these names are the same, the user@ part of the repository path isn't needed. In versions of CVS prior to 1.11.1, the colon between hostname and path was required.

Either the user's PATH environment variable on the server must include the directory that contains the cvs executable, or the user's CVS_SERVER environment variable on the client must contain the path to the cvs executable on the server. If you're using PATH, this variable must be set in a configuration file, such as .cshrc or .bashrc, that is read by nonlogin shells.

The rsh (or rsh-like) program starts the cvs executable on the server computer, using the username and permissions of the user the rsh program has connected as. Any programs CVS calls (such as programs called from a scripting file) run with this username and access.

As a trouble-prevention measure, before trying to use your rsh or rsh-like program with CVS, attempt to log into the server with it, using the program [-b] [-l username] host commandscommand format, as shown in Example 8-2.

Neither the rsh nor the server methods use encryption, and both transmit a clear-text username and password to a valid user account on the repository server. For this reason, I strongly recommend you use SSH or some other secured connection whenever you connect across an untrusted network. You should consider using a secured connection even on a trusted network. If there is any external connection to your network (even through a firewall), I recommend encrypting the connection.

Example 8-3 shows how to check out a sandbox using the ext access method.

rsh

rsh is the default program used with the ext method. If no other program is specified in the CVS_RSH environment variable, CVS calls rsh. If rsh is not in the user's PATH on the client or not available on the server, CVS cannot connect.

On the server, the user's .rhosts file in the user's home directory must have a line in the format client_name username, where client_name is the name of the client computer and username is the user's name on the client computer.

Tip

The rsh program provided with Windows NT modifies end-of-line characters and is unsuitable for use with CVS. In the HP-UX 9 operating system, use the remsh program rather than rsh, as rsh is a different program entirely. Use the CVS_RSH environment variable to define the replacement programs for both operating systems.

The server Access Method

The server access method uses a version of rsh internal to CVS. The.rhosts file on the server must be set, as described in Section 8.3.1 of this chapter.

To determine whether the server access method is available you can attempt to check out a sandbox with the method, as shown in Example 8-4.

The server method is not available in all operating systems. Both client and server must be able to run the internal rsh program.

SSH

Secure Shell (SSH) is an rsh replacement that encrypts the data stream. You can authenticate your SSH connection with a pair of keys (private and public) or with a password.

There are two SSH protocols: SSH1 and SSH2. The server must be running an SSH daemon that understands the protocol the client is using. SSH clients also come with a key-generation program that generates the private and public keys that will be used to encrypt the data stream.

To use SSH with CVS:

Install an SSH client on the sandbox computer and a daemon on the repository server, as given in the instructions for your SSH programs. Ensure that the path to the SSH program is in the PATH environment variable on the client computer.

Ensure that the server speaks the same protocol as the client. If the documentation for either program doesn't specify whether it uses SSH1 or SSH2, it probably uses the older, SSH1 protocol.

Ensure that the user has a username and password for the server as well as the client.

Generate an SSH key for the client, using the key-generation program. You may add the key to the user's home directory on the server, as explained in the documentation for your SSH program. If you do so, the user won't need to provide a password when connecting with SSH. This step is optional.

Test whether the connection works by attempting to log in to the server with the username from step 3, as shown in Example 8-5.

Put the name of your SSH program (or its path) into the CVS_RSH environment variable on the client computer.

Run CVS usingext as the method in the repository path, as shown in Example 8-3.

Example 8-5 shows a test connection to a server with an SSH client program, as described in step 5.

Other Connection Programs

The ext method can run with any other program that calls a remote program in the way that rsh and ssh do. The program must not modify data in transit, and it must be called using the format:

program [-b] [-l username] host commands

If you wish to use Kerberos with CVS, you can use the Kerberos version of rsh to connect using the ext method. If you wish to use Kerberos more directly, use the kserver or gserver access methods.

If you need to call rsh or ssh with an option, write a shell script like the one in Example 8-6 and put the path to that shell script in yourCVS_RSH variable. CVS will invoke the shell script, which in turn will invoke rsh or ssh with the options you desire.

Example 8-6. Invoking ssh with command-line options

#! /bin/bash
exec ssh -F ~/.sshconf "$@"

The fork Access Method

Thefork access method acts likeext without the external connection. You can use it only when the repository and the sandbox are on the same computer. fork makes CVS run in client/server mode and is most useful for debugging — to isolate whether a fault is in CVS's remote protocols or in the networking — but it is also used as a substitute for the local method.

The fork method uses the CVS_SERVER environment variable, as described in Section 8.3 earlier in this chapter.

The repository path format for fork is:

[:fork:]/path

With the fork access method, both client and server programs run under the username that the client was called with and have the filesystem access of that user. Any programs CVS calls (such as programs called from a scripting file) run with the same username and access.

Security normally is not an issue with the fork access method if the method is used on a single-user computer. However, be aware of the security issues of shared filesystems or shared mainframes; use the security services of your operating system to secure a shared repository that is accessed with the fork method.

Example 8-7 shows how to check out a sandbox using the fork access method.

The gserver Access Method

The gserver access method uses the GSS-API (Generic Security Service Application Programming Interface) to support authentication and encryption of the CVS connection. The GSS-API in itself does not authenticate or encrypt the connection; these processes are performed by an authentication or encryption system configured to work with the GSS-API. The most common system used with the GSS-API is Kerberos 5.

The GSS-API is explained in RFC 2743, available at http://www.ietf.org/rfc/rfc2743.txt. RFC 1964 explains how the GSS-API interacts with Kerberos 5. To use Kerberos 5 with CVS, use the GSS-API and the gserver access method. Kerberos 4 is used with the kserver access mode, explained in the next section.

The repository path format for the GSS-API is:

:gserver:[user@]hostname[:[port]]/path

The default port for gserver is 2401. If user is not specified, the client sends the username of the calling user on the client computer.

The CVS client and server must both be compiled to run the GSS-API. If you intend to encrypt the data stream, you also need to have encryption enabled at compile time. You can test whether your CVS program has the GSS-API compiled by attempting to check out a sandbox. Example 8-8 shows the result when CVS does not support the GSS-API.

To recompile CVS to support the GSS-API, follow the instructions given below. A more detailed discussion on installing from source is provided in Chapter 2, but the examples in that discussion do not include the GSS-API.

You need to use the --with-gssapi[=directory]option to configure CVS to use the GSS-API. If you want encryption, use --enable-encryptas well.

Note

Check your INSTALL file for the exact syntax of configuration options in your version of CVS.

On some operating systems, the GSS-API is installed automatically. If that's the case with your system, you may need to use --without-gssapi if you don't also have Kerberos 5 available.

To compile CVS with GSS-API support:

Ensure that your computer has an installation of both the GSS-API and Kerberos 5, with the header files.

cd to the CVS source directory.

Run makedistclean to remove any cached configuration information or other remnants of previous compilations.

Run configure with the arguments you need. To configure CVS for the GSS-API, you need --with-gssapi[=header files]. To enable encryption, use --enable-encrypt. The header files argument to --with-gssapi should be the path of the GSS_APIdirectory that contains libraries and include files (or a directory above that directory).

Run make.

Change user to root or another privileged user.

Run make install.

Tip

Check the output of configure carefully to ensure that CVS read the GSS-API include files. The output from configure is saved in config.log.

Using the GSS-API, CVS can authenticate and encrypt the data stream, but it does not do these things by default. Use the -a CVS option to authenticate the data stream, and use the -xCVS option to encrypt it. You may want to include these options in your .cvsrc file. For example, to both authenticate and encrypt the data stream, place the following in .cvsrc:

cvs -ax

To support the gserver access method, CVS needs to run a server on the computer that hosts the repository. CVS uses most of the same code to support the gserver and pserver methods. To configure the repository to run the CVS server, edit inetd.conf and add cvs pserver (not gserver). See Section 8.8 of this chapter for more information on this configuration.

Install and configure Kerberos 5, per the instructions for your Kerberos system. The principal name for CVS is cvs/HOSTNAME, where HOSTNAME is the canonical name of the host.

Warning

CVS 1.11.2 has a bug in its GSS-API code. It fails to connect and produces the following error message whenever it attempts to connect to a GSS-API server: cvs [import aborted]: gserver currently only enabled for socket connections.

Later versions do not have this problem, and there is a patch for 1.11.2 in the archives of the info-cvs mailing list.

The extent to which the GSS-API is secure depends on the particular system you choose and whether you choose to authenticate or encrypt the message stream. It's useful because of that flexibility; you can determine precisely which level of security you want. At present, the only system available to work with the GSS-API and CVS is Kerberos 5, which provides a high level of authentication security across an untrusted network, if the hosts connecting through it are secure.

Once the GSS-API and Kerberos 5 are installed and configured and CVS is recompiled, you can get a Kerberos ticket for your user on the client and then run CVS commands normally. Example 8-10 shows how to check out a sandbox using the gserver access method.

The kserver Access Method

The kserver method is used to connect using Kerberos 4. If you do not have an existing Kerberos 4 installation on your CVS repository server, I recommend you use Kerberos 5. Kerberos 4 has known weaknesses that Kerberos 5 resolves. This section assumes that you have an existing Kerberos 4 installation and the documentation to configure and use it.

Tip

Kerberos 4 is a reasonably secure authentication system, but it has known flaws. Kerberos 5 fixes some of them; most critically, it prevents a replay attack. In Kerberos 4, there is a five-minute window in which an attacker can sniff an authentication request, modify and re-send it, and get an authentication ticket. Kerberos 5 allows only one ticket to be produced per request.

The repository path format for Kerberos is:

:kserver:[user@]hostname[:[port]]/path

The default port for kserver is 1999. If user is not specified, the client sends the username of the calling user on the client computer.

The CVS client and server must both be compiled to run Kerberos 4. If you intend to encrypt the data stream, you also need to have encryption enabled at compile time. You can test whether your CVS program has compiled kserver support by checking the command list, as shown in Example 8-11.

You can test for encryption support by checking the options list, as shown earlier in Example 8-9.

To use CVS with kserver, install and configure Kerberos 4 as described in your Kerberos manual. You need to have the header files for Kerberos 4 available for CVS to link to. The principal name for CVS is cvs.

To recompile CVS to support Kerberos 4, follow the instructions in Chapter 2 on installing from source. Use the --with-krb4[=header-files]option to configure to get Kerberos authentication support. Use the Kerberos directory as the argument to--with-krb4. (You need the Kerberos directory you intend to compile against, usually one with include and lib subdirectories.) If you also desire encryption, use --enable-encryptas well.

Tip

Check your INSTALL file for the exact syntax of configure options in your version of CVS.

CVS needs to run a server on the repository computer to support the kserver access method. Edit inetd.conf and add a line for cvs kserver. See Section 8.8 of this chapter for details on how to edit inetd.conf.

Using Kerberos 4, CVS can encrypt the data stream, but it does not do this by default. Use the -xoption to encrypt the data stream. You may want to include this option in your .cvsrc file. For example:

cvs -x

To run CVS, get a Kerberos ticket for the user on your client; then call CVS the usual way with the kserver method. Example 8-12 shows how to check out a sandbox using the kserver access method.

The pserver Access Method

The pserver method allows users to connect to the repository with a username and password that are stored on the repository server. The main advantage of pserver is that it permits anonymous, passwordless, read-only access. The main disadvantages of pserver mode are that it uses a trivial encoding scheme for passwords and the data stream is not encrypted. pserver mode is included in CVS automatically, but it requires a password file that needs to be configured.

To use pserver, you need a username on the repository computer, to enable CVS to run programs on that computer. You may share this username (your system username) with other users and have a separate CVS username to identify you to CVS as an individual. You also need to log in before running other commands.

To support the pserver access method, CVS needs to run a server on the computer that hosts the repository. To configure the repository to run the CVS server, edit inetd.conf and add cvs pserver. See Section 8.8 of this chapter for more information on inetd configuration.

The repository path format for pserver is:

:pserver:[[user][:password]@][hostname:[port]]/path

The default port for pserver is 2401. If the user is not specified, the client sends the username of the calling user on the client computer.

You need to configure the passwd file and possibly the readers and writers files before you can use pserver. These files are explained in Section 8.7.1 and Section 8.7.2 of this chapter. You also need to use the login command, explained in Section 8.7.3.

Warning

You can bypass the passwd file by using the SystemAuth configuration option in the config file (explained in Chapter 6).

If you bypass the passwd file using SystemAuth, CVS uses the shell account passwords for your users with the minimal security it uses for pserver passwords. Be sure you take the security risks into account if you choose to do this.

Once CVS is configured for pserver, you can check out a sandbox or use other CVS commands normally, using the pserver repository path when necessary. Example 8-13 shows how to check out a sandbox using the pserver access method.

The passwd File

The passwd file in the repository's CVSROOT directory stores passwords and usernames for the pserver access method. The format is as follows:

CVS_username:password:system_username

The CVS_username is the name the user sends to CVS. The system_username is the name the CVS programs run under. If these names are the same, the system_username does not need to be given, as it defaults to the CVS_username. The CVS_username is shown in the author field of cvs log output.

The system_username must exist on the repository server. The CVS_username doesn't need to exist on the server unless it's the same as the system_username. If the system_username does not exist on the server, the commands fail, even if the user authenticates as far as CVS is concerned.

If the password field is empty, the user automatically authenticates even with no password.

The passwords are encrypted with the standard Unix crypt( ) function and need to be encrypted elsewhere and pasted in; there currently is no code that edits this file. You can use the Unix mkpasswd utility to create a suitable encrypted string from a plain-text password.

Tip

Another way to generate passwords is to use the Perl command perl -e 'print crypt "password", "salt";'. Replace salt with any two characters, to randomize the results.

A single system username can be shared by multiple users with different CVSusernames. This can be used to allow several people to work on a project and record the changes across multiple users. (Of course, this could also be done with group permissions.) If appropriate for your security needs, you can restrict the system usernames so that they can only run CVS.

The passwd file should be edited in place; it should not be checked out to sandboxes.

Note

You can grant anonymous, read-only access to CVS using pserver. Set up the passwd file in the CVSROOT directory with the user anonymous (or any other username) with no password or system name, and add the user anonymous to the readers file.

A better way to grant anonymous, read-only access is to use the operating system's built-in security. This method is explained in Chapter 6.

The readers file is described in the next section.

The readers and writers Files

The readers and writers files in the repository's CVSROOT directory control whether someone using the pserver access method has permission to write to the repository. These files affect only users using the pserver access method; repository access using the other access methods is controlled by the filesystem permissions.

The readers and writers files use the CVS username, not the system username, to determine whether a user has access.

Users gain access to the repository according to the following rules:

If a user is listed in the readers file, she has read-only access to the repository.

If the writers file exists and a user is not listed in the writers file, she has read-only access to the repository.

If a user is listed in the writers file but not in the readers file, she has read-write access to the repository.

If a user is listed in both readers and writers, CVS takes the conservative choice and she has read-only access to the repository.

Both files are one name per line. You must have a newline character after the last username. An example readers or writers file is shown in Example 8-15.

Example 8-15. readers or writers file

jenn
doppel
asmith
peter

login and logout

The passwd file controls whether the CVS server requires a password for any given user. If the server requires a password, pserver requires you to use the cvs login and cvs logout commands. Run the cvs login command before any other CVS command, setting the repository path, if necessary, with one of the usual methods. Example 8-16 shows how to log in with pserver mode.

Once you have successfully logged in, CVS records the password and other data in the.cvspass file in your home directory on your client computer. This filename can be changed by putting the path to the new file in the CVS_PASSFILE environment variable in the client before you run login. CVS stores the data indefinitely in the format /1 user@host:port/path Aencoded_password, one repository to a line. (Yes, there is a literal A before the password; that's an internal version identification system.)

You can remove this line from the file by using cvs logoutwith the same CVSROOT, in which case you would need to log in again the next time you wish to use pserver access to connect to that repository.

The password is encoded using a simple encoding scheme and can be decrypted easily by a malicious user. It is encoded against inadvertent, nonmalicious reading, but it is not secure.

Security

CVS searches the passwd file in the CVSROOT directory for usernames and passwords for pserver access. Because of the trivial encoding, passwords used for pserver access should not be the same as the passwords used for access to the main filesystem of the repository server. The passwdfile should not be included in the checkoutlist list in the cbeckoutlist file. It should always be edited in place, because multiple copies of the passwords in various sandboxes is a security risk.

CVS can also fall back to system-level user authentication. If a user is not found in the passwd file, CVS (by default) authenticates the user with the system's normal authentication method. To prevent users from connecting to CVS with systemwide passwords, this fallback system should usually be disabled; it should definitely be disabled if the data might be transmitted across an untrusted network. Disable it by editing the config file in the CVSROOT directory and setting the SystemAuth value to no.

If users with pserver access can edit the CVSROOT scripting files, an attacker who decrypts a pserver access password can force CVS to run arbitrary scripts. Fortunately, scripts run with the access level of the system user as determined when CVS reads the passwd file; the access level is not determined by the daemon that runs CVS.

Be aware that once an intruder has write access to the CVS repository, he may be able to gain additional access to the system. If your communications travel over a hostile network, don't use pserver for access where users can change data. pserver can be useful for read-only, anonymous access, but I recommend you use something else for other kinds of access. If you need to use pserver, an SSH tunnel may be a reasonable compromise.

Using inetd with gserver, kserver, and pserver

gserver , kserver , and pserver access modes require a server to run on the repository computer. For these modes, the server is started with inetd or xinetd . inetd is configured in the "Other services" section of /etc/inetd.conf, as shown in Example 8-18 and Example 8-19. Note that the configuration must be all on one line.

The gserver access method connects to a pserver CVS server. The code that runs the server end of pserver checks whether it has been connected to with the pserver or gserver access method and runs the appropriate server code.

The parameter to the --allow-root option is the path to the repository root directory. If there will be several different repository root directories, add more --allow-rootoptions.

You can use the -T option or the TMPDIR environment variable to set a specific temporary directory. If no directory is listed, /tmpis used.

Note

It can be useful to run the server as a special user, possibly named cvs, to limit the amount of damage that can be done if one of the arbitrary scripts (or CVS itself) is insecure. If you do this, ensure that the repository root directory and the CVSROOT files start out being owned by the cvs user, and make sure that the cvs user is in all the groups that can use the repository. You also need to ensure that all users run as user cvs, perhaps by having that as the system username in pserver access mode.

If CVS has root privileges, it runs the scripts called from the scripting files as the user who calls CVS, not the user named in inetd, so this is not a special concern.

If your version of inetd doesn't allow you to specify port numbers in inetd.conf, add lines to /etc/services, as shown in Example 8-20. Then use those service names instead of the port numbers in inetd.conf.

Example 8-20. Port services

cvspserver 2401/tcp
cvs 1999/tcp cvskserver

CVS looks for the cvs service if it is running kserver access mode, and it looks for cvspserver if it is running in gserver or pserver mode. If you installed CVS from a package, CVS may have been modified to use cvskserver. Onceinetd.conf is set up, you'll need to restart inetd.

If you use xinetd instead of inetd, you need to create /etc/xinetd.d/cvspserver or /etc/xinetd.d/cvskserver and enter code similar to the code shown in Example 8-21, rather than editing/etc/inetd.conf.

The -f, -T, and --allow-rootoptions to the CVS server are the same as they are for inetd. To use the code in Example 8-21 for the kserver access method, change the filename and port and use kserver instead of pserver in theserver-args line. If cvspserver or cvskserver are defined in /etc/services, the line that defines the port is not needed.

Client Ports

If you're using pserver or gserver, the client defaults to use port 2401. If your repository server is listening on a different port, specify the port in the repository path or set the CVS_CLIENT_PORT environment variable on the client computer. You can also compile the client with the CVS_AUTH_PORT macro set to the new port.

If you're using kserver , the client defaults to use port 1999. If your repository server is listening on a different port, you can use the repository path or the CVS_CLIENT_PORT environment variable. The CVS_PORT macro sets the default port for kserver mode during compilation.