Section 9.2. Connectivity Problems
9.2. Connectivity ProblemsIf you are having difficulty connecting to a repository, first confirm that the repository path is declared correctly. The most common mistake when checking out a new sandbox is to forget to specify the repository path at all. Another common mistake is to forget to specify the connection method if you are using a method other than local or ext. If you want to examine the data sent to or received from the server, set the CVS_CLIENT_LOG environment variable to a filename. It must be set on the client computer, and the traffic is logged in files in the current working directory named for that filename, with the suffixes .in and .out. For instance, if you set CVS_CLIENT_LOG to cvslog, the traffic is logged to cvslog.in and cvslog.out. (Traffic to the server is logged to cvslog.in, and traffic from the server is logged to cvslog.out.) The gserver, kserver, and pserver connection methods rely on a server that is started with inetd. inetd sets a limit on the number of connections per unit of time and delays further connections. If you expect heavy use of CVS, you may need to configure inetd to accept more connections per minute. Not doing so may cause "connection refused" error messages. If you're having trouble with the write proxy system, the most likely cause is the client being an older client and the server not being configured correctly to support it. See Chapter 6 for the configuration information. 9.2.1. Root and Repository File ProblemsIf you are in an active sandbox and are receiving an error like the one shown in Example 9-2, the Root or Repository file in the CVS subdirectory of the current sandbox directory has become unreadable. Chapter 6 includes an explanation of these files and what they should contain, but the simplest way to correct a problem in a sandbox is to remove and recreate the sandbox. If there are changes in the sandbox files, be sure to preserve them before removing the sandbox. Example 9-2. Repository undeclared
Certain changes in a repository or a repository's host environment can cause the Root and Repository files in a sandbox to be out of date. Examples of these changes include a change to the repository computer's hostname, a change to the user's username, and a change in the preferred connection method. The traditional way to manage these changes is to commit and release the sandbox beforehand and create a new sandbox afterward. If you do not want to create a new sandbox, you can edit the appropriate files in the sandbox. Example 9-3 is a small script that relies on bash and perl to change the hostname in a sandbox Root file automatically. In the example, helit is the old hostname, and lat the new. Example 9-3. Changing the Root files automatically
9.2.2. Misconfigured Access MethodsSome of the access methods require configuration. The pserver, kserver, and gserver methods require configuration at the repository, and the ext, kserver, and gserver methods require configuration at the sandbox. Example 9-4 shows the error that occurs when the pserver method is used but the user does not exist in the repository's user database. Example 9-5 shows the error that occurs when kserver is used but the client is not compiled to support it. Example 9-4. Pserver misconfiguration
Example 9-5. Kserver misconfiguration
In addition to checking the configuration of the access method, check whether the username you're trying to use exists on the server and has access to the repository project files you are trying to reach. If you are using the pserver access method, also check that the passwd file in the repository's CVSROOT directory is mapping your CVS username onto an existing system username with the appropriate permission. If you are using Kerberos 4 or the GSS-API with Kerberos 5, ensure that you have a Kerberos username and a current ticket and that the CVS server has its ticket. System times are also critical with Kerberos. 9.2.3. Isolating Connectivity ProblemsIsolating a problem is a common and useful troubleshooting tactic. If you are having trouble accessing a repository, there may be a problem with the protocol you are using to connect with, the configuration of either CVS or the protocol, or, more rarely, the CVS code. To fix your problem, you need to figure out where it is. There is a common set of client and server code used by all CVS remote-access methods. The fork connection method can be used to determine that this common CVS code is functioning correctly. To determine whether Kerberos, the GSS-API, rsh, or your rsh replacement are working, you can use a simple service with the same protocol as the method you are having trouble with. To test whether a connection problem is caused in CVS itself, try using the fork access method to create a sandbox on the same computer as the repository. If this fails, check your repository path and check that the project name you are using is valid. If both are correct, there is a problem in the CVS client and server code that should probably be reported as a bug. Example 9-6 shows what should happen when you test the server with fork. Example 9-6. Testing the server with fork
If the fork test shows that your repository path and project name are valid and that the common CVS server is functioning correctly, you can isolate the problem further by testing the access method with a simple program that uses the same protocol. You must do this with the protocol client you are attempting to use with CVS, and you must use the same hostname. Kerberos 4 or 5 can be tested with the Kerberos rsh replacements, and ext or server can be tested with rsh. If ext is used with a replacement for rsh, that replacement should be used in the test. You can test pserver with telnet. Example 9-7 shows a successful attempt to connect to a host named helit using the SSH protocol. SSH clients are commonly used as rsh replacements. Example 9-7. Testing ext
9.2.4. rsh-Replacement ProblemsIf you are using the ext connection method, you can choose from many programs to manage your connection; however, such a choice can cause problems. The replacement must not convert line endings, as CVS expects to do that itself. If your replacement converts line endings, CVS is unable to determine where the end of each line is, so the merge methodology fails. It's highly unlikely that you'll find an rsh replacement that isn't 8 bit clean, but if you're using binary files or compression and you get strange file corruption problems, you just might have found one. 8 bit clean refers to how the program handles character sets: 7 bit programs kept the eighth bit of the byte for use as a parity or flag bit. The replacement must accept the following syntax: program [-b] [-l username] host commands The -b is optional if you are not using OS/2, but the rest of the syntax is required. The repository server must be running a server process that can accept the protocol the replacement is using and that can run the commands sent by the rsh-replacement program. To test most of these requirements, you can run a command that uses the full syntax, as shown in Example 9-8. Example 9-8. Testing ssh for suitability
If you need to pass a command or call an option to your rsh replacement, you can do so by creating a small script and calling that script instead of the replacement program. Example 9-9 shows one such script. Example 9-9. ssh script
|
EAN: 2147483647
Pages: 148