Installing CVS on Different Distributions

 < Free Open Study > 

The previous sections described how to select parameters for configuring inetd to run CVS in pserver mode, and produced the actual command that needs to be run. The following sections will describe how to configure the sample distributions to actually run that command from within inetd.

Installing on Red Hat Linux

As discussed in Chapter 4, Red Hat Linux uses the xinetd program as its implementation of inetd. This program is a modernized version of the classic inetd that uses newer techniques for making configuration simpler. Classic inetd implementations (which are covered in the section "Installing on Slackware Linux") use a single configuration file to drive all inetd services. In contrast, xinetd uses the "drop-in configuration" technique (also discussed throughout Chapter 4) to configure services.

Updating the /etc/services File

This section will describe how to update the /etc/services file, which contains information assigning names to network services, to include CVS. The /etc/services file is a part of the operating system, rather than specific to any particular distribution or implementation of inetd. Thus, even though it's presented under the Red Hat Linux-specific section, it will need to be applied to each distribution.

The /etc/services file assigns symbolic names to TCP/IP network ports. For example, the standard port number for telnet connections is 23; there is thus a line in /etc/services that assigns the name "telnet" to port 23, like so:

 telnet  23/tcp 

You can probably already discern the general format from that line. It's very simple: a service name followed by the port number and the port number type, either TCP (stream oriented) or UDP (datagram oriented). (Whether a program uses TCP or UDP is determined by how the program was written.)

Programs written to employ the network typically determine the port number to use by looking up the service name via the operating system. For example, a program that needs to know the port for telnet would look up "telnet" from the operating system, which in turn consults /etc/services and returns a port number of 23.

Standard port numbers are typically assigned by a standards body such as the Internet Engineering Task Force (IETF) or the International Association for Names and Addresses (IANA), or agreed upon by convention. Most Linux distributions come with a recent /etc/services file that includes the vast majority of ports and service names with which users interact. In fact, the stock /etc/services file on a recent Red Hat Linux system includes well over 400 predefined network services. This list is fairly complete and contains many services that are not strictly required, but are present for reference; for example, it contains an entry for the Quake multiplayer network game!

Since the list of standard ports is constantly evolving, older distributions may not have as recent a list, so whenever you add a service to /etc/services, always check to make sure that it's not already there under a different name. For example, the version of /etc/services that ships with Red Hat Linux 7.3 already has an entry for CVS in pserver mode, as you can see here:

 cvspserver  2401/tcp 

So, on Red Hat Linux 7.3 systems, you don't actually have to modify the /etc/services file. However, some older versions of Red Hat Linux and other distributions' copies may not include this line, or may include it under a different name (such as "cvs" instead of "cvspserver"). Regardless, however, the port will be 2401. Adding two names for the same service won't break anything, though; it is simply redundant. (In fact, you don't really even need to add this line to /etc/services at all, and can instead use the raw port number directly. However, adding the line to /etc/services makes things more "human readable.")

The /etc/xinetd.d Directory

The xinetd program uses the drop-in configuration directory technique to configure services. That is, when xinetd is started up, it examines a particular directory looking for files containing configuration, and then reads those files. Each file contains configuration information for a different service that xinetd is to manage. By default and as installed on Red Hat Linux systems, the directory that xinetd uses for configuration files is /etc/xinetd.d.

To configure a service to run with xinetd, the first step is simply to create a file in /etc/xinetd.d that contains configuration data for the service. By convention, each file in /etc/xinetd.d is named according to the service it configures (though this is not required); for example, /etc/xinetd.d/wu-ftpd is the configuration file for the wu-ftpd FTP server program. For CVS, the file should be named /etc/xinetd.d/cvs.

Constructing the Configuration File

The next step is to create the contents of the CVS configuration file. This file contains information such as whether the server is enabled (since xinetd allows for a particular service to be configured but not actually active), whether the service is stream or datagram oriented, which user the service is to run as, and so on. This file has the following general format:

 service <service name> {       configuration parameter] = [value] } 

The <service name> parameter is the name of the service as specified in /etc/services. The configuration parameter lines each contain a parameter and a value, and specify the bulk of the actual configuration data used by xinetd. Table 12-2 summarizes the most common parameters.

Table 12-2: xinetd Configuration File Parameters




"yes" or "no"; indicates whether the service is active or not.


"stream" or "dgram"; indicates whether the service is stream or datagram-oriented.


"yes" or "no"; indicates whether the service will wait for additional incoming connections, or exit after servicing just one.


Username under which the service is to run (usually root).


Path to the service program executable.


Any arguments that need to be passed to the program.nice. Can be used to determine a priority for the service; this can reduce (or increase) the priority of a particular service to give it a reduced (or increased) portion of CPU time.

Table 12-2 shows only a portion of the total available options that can be used in a configuration file for xinetd services. The full documentation can be obtained from the manual page for xinetd.conf-that is, via the command man xinetd.conf. Although Table 12-2 is a good starting point for configuring an xinetd service and may be adequate for most simple cases, more complicated inetd services may require some of the options listed in the manual page.

Recall that Red Hat Linux 7.3 already includes an entry in /etc/services for CVS-"cvspserver"-so that much is easy. (On a distribution that uses xinetd but does not already have an entry for CVS, the administrator would have to add the entry and reference it in the xinetd configuration file, or use the numeric port number.) The disable parameter obviously needs to be "no", or else xinetd will still not run the CVS server. The socket_type parameter must be "stream", and the wait parameter must be "no"; these are properties of the CVS pserver program, and cannot be altered. The nice argument is really optional in this case, but can be left at "10". That will keep the CVS server running at a reasonable priority with respect to other processes on the system. (That is, it won't monopolize the CPU, but also won't get totally ignored by the system. See the manual page for the nice command for more information.)

The remaining three options- user, server, and server_args-are the values that were decided on earlier in this section. In the example, the user under which CVS is to run is cvs. The program itself was compiled from source code and installed in /usr/local/bin, so the server argument must be /usr/local/bin/cvs. Finally, the server_args parameter must be the arguments described earlier: -f -allow-root=/usr/local/var/cvs pserver. Listing 12-1 shows a complete xinetd configuration file for CVS.

Listing 12-1: xinetd Configuration File for CVS pserver Mode

start example
 service cvspserver {       disable     = no       socket_type = stream       wait        = no       user        = cvs       server      = /usr/local/bin/cvs       server_args = -f --allow-root=/usr/local/var/cvs pserver       nice        = 10       port        = 2401 } 
end example

Managing xinetd

Now that CVS has been configured for xinetd, xinetd will begin managing it. However, if xinetd is already running, then it will need to be restarted. Additionally, some installations of Red Hat Linux may have xinetd installed, but not running. In these cases, xinetd will need to be configured to run on system startup. This section will describe how to accomplish these tasks.

If it's already running, restarting xinetd will cause it to reload its configuration files; this will result in xinetd "noticing" the new configuration file for CVS and running the server. The kill command can be used to terminate the old process, and xinetd can then be restarted from the command line. However, there is an easier way to do this on Red Hat Linux systems: As discussed in Chapter 4, Red Hat includes a command called service that can be used to conveniently start, stop, and restart services. Thus, the command service xinetd restart is much simpler than using the kill command and restarting xinetd manually.

There's actually yet another way to cause xinetd to "notice" CVS. By sending the SIGUSR2 signal to xinetd, the administrator can instruct xinetd to reload its configuration file, without actually exiting, which is a bit more graceful than killing and restarting the process. This can be accomplished with the following command:

 % kill -USR2 'pidof xinetd' 

There are actually a few more special signals that xinetd can handle; for more information on these signals or the SIGUSR2 signal already mentioned, readers should consult the manual page for xinetd.

One other convenient utility provided by Red Hat is the chkconfig command. This command was mentioned in Chapter 4, and allows administrators to examine, enable, and disable specific services (not just xinetd services!) running on the system. The chkconfig command can enable or disable xinetd services, as well as standard servers. So, once the CVS pserver xinetd service has been configured, it can be turned on and off using the chkconfig tool. For example, you could disable the CVS pserver from this example through this command:

 % chkconfig cvs off 

CVS pserver can later be reenabled by a similar command, replacing "off" with "on".

Installing on Slackware Linux

Configuring CVS to be run in pserver mode on a Slackware system is similar in spirit to the installation on Red Hat Linux, as discussed in the previous section. However, Slackware uses a traditional implementation of the inetd superserver, in contrast to Red Hat's modernized version. This makes for a few differences in the details of how to install it.

Actually, hooking CVS into Slackware's inetd is quite simple. First, the /etc/services needs to be modified, in precisely the same way as for Red Hat Linux. Then, the /etc/inetd.conf file needs to include a line that adds the CVS pserver to the list of ports that inetd monitors. Again, Slackware's philosophy of simplicity pays off: This operation involves adding a single line, rather than having to deal with multiple files in a directory and a custom format for the configuration file itself.

The following code is typically enough to configure CVS for Slackware's inetd (or for most Unix-like systems' inetd servers, for that matter).

 cvspserver   stream   tcp   nowait   root        /usr/bin/cvs cvs -f --allow-root=/usr/local/var/cvs pserver 

Note that the preceding two lines should be joined into a single line in your copy of /etc/inetd.conf.


For full details on configuring applications to work with inetd, see Chapter 5.

The only difficulty that might arise with this technique is that many traditional implementations of inetd only support up to five arguments for the program executed (and one of those arguments has to be the name of the program itself). If you're running a sizable CVS repository with multiple roots, you might encounter this limit through the need for multiple -allow-root arguments. In these cases, however, inetd can be configured to call a very simple shell script which itself invokes the required CVS command. Since the shell script will have no limit on the number of arguments, CVS will run normally.

Installing on Debian GNU/Linux

Debian GNU/Linux uses a traditional implementation of the inetd program, like Slackware Linux. (Contrast this with Red Hat Linux's use of the xinetd variant.) This obviously means that preparing a CVS pserver installation on Debian GNU/Linux is very similar to doing so on Slackware Linux; in fact, the processes are identical.

Debian, however, also offers an additional tool used to manage the services run by its inetd version. The tool is named update-inetd and is discussed in the section entitled "Using the update-inetd Program" in Chapter 6. You may wish to investigate this tool, instead of doing things manually as you would on Slackware Linux.

 < Free Open Study > 

Tuning and Customizing a Linux System
Tuning and Customizing a Linux System
ISBN: 1893115275
EAN: 2147483647
Year: 2002
Pages: 159 © 2008-2017.
If you may any questions please contact us: