Trouble making a connection to a CVS server

This section concerns what to do if you are having trouble making a connection to a cvsnt server. If you are running the cvsnt command line client running on Windows, first upgrade the client to cvsnt 1.9.12 or later. The error reporting in earlier versions provided much less information about what the problem was. If the client is non-Windows, cvsnt 1.9 should be fine.

If the error messages are not sufficient to track down the problem, the next steps depend largely on which access method you are using.


Try running the ssh program from the command line. For example: "ssh servername cvs -v" should print cvsnt version information. If this doesn't work, you need to fix it before you can worry about cvsnt problems.


You don't need a command line rsh program to use this access method, but if you have an rsh program around, it may be useful as a debugging tool. Follow the directions given for :ext:.


Errors along the lines of "connection refused" typically indicate that inetd isn't even listening for connections on port 2401 whereas errors like "connection reset by peer" or "recv() from server: EOF" typically indicate that inetd is listening for connections but is unable to start cvsnt (this is frequently caused by having an incorrect path in inetd.conf). "unrecognized auth response" errors are caused by a bad command line in inetd.conf, typically an invalid option or forgetting to put the authserver command at the end of the line. Another less common problem is invisible control characters that your editor "helpfully" added without you noticing.

One good debugging tool is to "telnet servername 2401". After connecting, send any text (for example "foo" followed by return). If cvsnt is working correctly, it will respond with

cvs [authserver aborted]: bad auth protocol start: foo

If instead you get:

Usage: cvs [cvs-options] command [command-options-and-arguments]

then you're missing the authserver command at the end of the line in inetd.conf; check to make sure that the entire command is on one line and that it's complete.

Likewise, if you get something like:

Unknown command: `authserver'

CVS commands are:
        add          Add a new file/directory to the repository

then you've misspelled authserver in some way. If it isn't obvious, check for invisible control characters (particularly carriage returns) in inetd.conf.

If it fails to work at all, then make sure inetd is working right. Change the invocation in inetd.conf to run the echo program instead of cvs. For example:

2401  stream  tcp  nowait  root /bin/echo echo hello

After making that change and instructing inetd to re-read its configuration file, "telnet servername 2401" should show you the text hello and then the server should close the connection. If this doesn't work, you need to fix it before you can worry about cvsnt problems.

On AIX systems, the system will often have its own program trying to use port 2401. This is AIX's problem in the sense that port 2401 is registered for use with cvsnt. I hear that there is an AIX patch available to address this problem.

Another good debugging tool is the -d (debugging) option to inetd. Consult your system documentation for more information.

If you seem to be connecting but get errors like:

cvs server: cannot open /root/.cvsignore: Permission denied
cvs [server aborted]: can't chdir(/root): Permission denied

then you probably haven't specified -f in inetd.conf.

If you can connect successfully for a while but then can't, you've probably hit inetd's rate limit. (If inetd receives too many requests for the same service in a short period of time, it assumes that something is wrong and temporarily disables the service.) Check your inetd documentation to find out how to adjust the rate limit (some versions of inetd have a single rate limit, others allow you to set the limit for each service separately.)


If you cannot connect using gserver, ensure that your kerberos installation is correctly configured. You will need a working PAM configuraiton if your system uses that, and nsswitch.conf may need to be configured to recognise kerberos users.

Kerberos is rather difficult to configure, and it is beyond the scope of this manual. There are many resources on the internet to help you with this.