CVSUPD(8) FreeBSD System Manager's Manual CVSUPD(8) NNAAMMEE ccvvssuuppdd - network distribution server for CVS repositories SSYYNNOOPPSSIISS ccvvssuuppdd [--eeffvv] [--AA _a_d_d_r] [--bb _b_a_s_e] [--cc _c_o_l_l_P_a_t_h] [--CC _m_a_x_C_l_i_e_n_t_s] [--ll _l_o_g] [--pp _p_o_r_t] [--PP _r_a_n_g_e] [--ss _s_c_a_n_D_i_r] [--ZZ _c_o_m_p_r_L_e_v_e_l] DDEESSCCRRIIPPTTIIOONN ccvvssuuppdd is the server program for the CCVVSSuupp network distribution package. For information about the companion client program, see cvsup(1). In normal usage, ccvvssuuppdd should be started with the `--CC _m_a_x_C_l_i_e_n_t_s' option. Unless --ff is specified, it runs as a background daemon, fielding connection requests from remote clients. For each connection, ccvvssuuppdd forks a child process to serve the files requested by the client. The following options are supported: --AA _a_d_d_r Specifies a local address (dotted quad or hostname) on which the server will accept connections. This may be useful on hosts which have multiple IP addresses. --bb _b_a_s_e Uses _b_a_s_e as the base directory for the configuration files. The default is _/_u_s_r_/_l_o_c_a_l_/_e_t_c_/_c_v_s_u_p. --cc _c_o_l_l_P_a_t_h Searches the specified directories for information about the collections being offered. _c_o_l_l_P_a_t_h contains of one or more directory names, separated by colons. Non-absolute pathnames are interpreted relative to the base directory. The default search path is `sup'. --CC _m_a_x_C_l_i_e_n_t_s Limits the number of simultaneous clients to _m_a_x_C_l_i_e_n_t_s. Clients beyond the specified maximum are politely refused service. If this option is not specified, ccvvssuuppdd serves one client in the foreground and then exits. --ee Suppresses the redirection of the standard output and stan- dard error when running as a daemon and logging to a syslog facility. Otherwise, these descriptors are redirected to _/_d_e_v_/_n_u_l_l. This option is useful for capturing any panic messages which might be emitted in the rare event of a crash of the server. Such messages are very helpful for debugging, but there is no reliable way to send them to syslog. A rec- ommended way to use the option is like this: cvsupd -e ... >>/var/tmp/cvsupd.out 2>&1 assuming that the command line syntax of sh(1) is used. --ff When --CC _m_a_x_C_l_i_e_n_t_s is specified, causes ccvvssuuppdd to stay in the foreground instead of becoming a background daemon. --ll _l_o_g Directs log messages to _l_o_g. If _l_o_g is of the form @@_f_a_c_i_l_i_t_y (e.g., `@local0') then logging is done via syslog to the indicated facility. Otherwise, _l_o_g is treated as the name of a log file. If the file already exists, new messages are appended to its end. For each client served, at least two messages are logged. The first message identifies the client by username and host- name. The last message reports the success or failure of the update and gives the total network I/O in Kbytes (1K = 1024). Additional messages may be emitted to report errors or other noteworthy conditions. --pp _p_o_r_t Listens for connections on an alternate TCP port. The default port is 5999. When not in passive mode, the server also uses the next lower port to establish a second connec- tion (called the data connection) back to the client. --PP _r_a_n_g_e Sets the range of server TCP ports to be used for the data connection, when in passive mode. _R_a_n_g_e may be a single integer or a range given as `lo-hi'. --ss _s_c_a_n_D_i_r Enables mirror mode, and specifies the directory under which the scan files can be found. If it is not an absolute path- name, _s_c_a_n_D_i_r is interpreted relative to the base directory. See _R_U_N_N_I_N_G _A _C_V_S_u_p _M_I_R_R_O_R _S_I_T_E, below. --vv Prints the version number and exits, without serving any clients. --ZZ _c_o_m_p_r_L_e_v_e_l Sets the compression level to _c_o_m_p_r_L_e_v_e_l. The compression level must be between 0 and 9. A level of 0 means no com- pression, while 9 provides maximum compression. The default level is 1. Higher levels provide relatively little improve- ment, at a rather high cost in CPU cycles. PPRREEPPAARRIINNGG AA FFIILLEE CCOOLLLLEECCTTIIOONN RREEPPOOSSIITTOORRYY The file collections which ccvvssuuppdd makes available to clients are described by various configuration files. The configuration files reside under the directory _b_a_s_e_/_c_o_l_l_D_i_r, where _b_a_s_e is the directory specified by the --bb _b_a_s_e command line option, or _/_u_s_r_/_l_o_c_a_l_/_e_t_c_/_c_v_s_u_p by default. _c_o_l_l_D_i_r is any of the directories specified with the --cc option, or `sup' by default. Each collection's configuration files are kept in a separate subdirectory of _b_a_s_e_/_c_o_l_l_D_i_r, named after the collection itself. For example, the configuration for the `src-base' collection would be found in _b_a_s_e_/_c_o_l_l_D_i_r_/_s_r_c_-_b_a_s_e. Within the collection's subdirectory, there should be a _r_e_l_e_a_s_e_s file and a list file. The _r_e_l_e_a_s_e_s file contains one line per release. The first word of each line is the name of the release, e.g., `cvs'. That must be followed by the following phrases, in any order: lliisstt==_f_i_l_e Specifies the name of the list file, relative to the collec- tion's subdirectory. The list file is described below. pprreeffiixx==_d_i_r_e_c_t_o_r_y Specifies where the files making up the collection are to be found. If _d_i_r_e_c_t_o_r_y is not an absolute pathname, it is interpreted relative to the base directory _b_a_s_e. If there is no pprreeffiixx clause, the prefix defaults to _b_a_s_e. kkeeyywwoorrddpprreeffiixx==_d_i_r_e_c_t_o_r_y Specifies a ``pseudo-prefix'' which is used only for expand- ing the absolute pathnames for the `$Header$' and `$Source$' RCS keywords. The _d_i_r_e_c_t_o_r_y should normally be the absolute pathname of the CVS repository on the machine containing the master copy of the repository. The use of kkeeyywwoorrddpprreeffiixx ensures that CCVVSSuupp will expand the RCS keywords identically on all machines, even though the repositories may reside in different directories. ssuuppeerr==_c_o_l_l_e_c_t_i_o_n Specifies the immediate super-collection of the current col- lection. In large distributions, the collections are often organized in a hierarchical manner. At the top of the hier- archy is a collection containing all of the distributed files. At the next level are several sub-collections, each containing a subset of the files. Each sub-collection may in turn have further sub-collections, and so forth. The ssuuppeerr keyword specifies the collection's parent in such a hierar- chical arrangement. This keyword is optional. If it is omitted, ccvvssuuppdd assumes nothing about the relationship between the current collection and the other available collections. Information from the ssuuppeerr keywords is used for finding the appropriate scan files when the server is running as a mirror site. See _R_U_N_N_I_N_G _A _C_V_S_u_p _M_I_R_R_O_R _S_I_T_E. nnoocchheecckkrrccss Disables the comparison of MD5 checksums for updated RCS files. Checksum mismatches for RCS files may not be meaning- ful, since a given logical RCS file can have many different textual renditions. nnoorrccss Disables special processing for RCS files. They will be treated the same as other files. nnoorrssyynncc Disables the use of the _r_s_y_n_c algorithm. NNoottee:: this keyword is deprecated in the _r_e_l_e_a_s_e_s file. Use nnoorrssyynncc or rrnnoorrssyynncc in the list file instead. (See below.) Unrecognized phrases are accepted but ignored, for backward compatibility with the ssuupp package. Note that even though ccvvssuuppdd often serves only a single release, the _r_e_l_e_a_s_e_s file is still required. The list file specifies the details of how to upgrade the client's ver- sion of the collection. Each line contains a single command. Blank lines are ignored, as are lines beginning with `#'. Any filenames speci- fied are taken as relative to the pprreeffiixx directory given in the _r_e_l_e_a_s_e_s file. Many of the list file commands accept file name patterns as arguments. These are similar to the patterns accepted by sh(1), and may include the wild card constructs `*', `'?, and `[...]'. With the exception of oommiittaannyy patterns, any slash characters in file names must be matched explicitly by slash characters in the pattern. Leading periods in file names are not treated specially. For example, the pattern `*' matches the filename `.profile'. uuppggrraaddee _p_a_t_t_e_r_n _._._. All files and directories matching any of the given patterns will be included in the list of files to be upgraded. If a directory name is matched, it recursively includes all files and subdirectories within it. aallwwaayyss _p_a_t_t_e_r_n _._._. This command is the same as uuppggrraaddee, except that it overrides any oommiittaannyy commands. oommiittaannyy _p_a_t_t_e_r_n _._._. Files or directories matching any of the given patterns will be omitted from the upgrade. If a directory name is matched, then it and all files and subdirectories beneath it are omit- ted. The patterns for oommiittaannyy are interpreted differently than other patterns. For normal patterns, a slash character in a pathname must be matched explicitly by a slash character in the pattern. For oommiittaannyy patterns, slashes are treated the same as other characters. Thus the pattern `*.c' will match any pathname ending in `.c', including, for example, `foo/bar/lam.c'. ssyymmlliinnkk _p_a_t_t_e_r_n _._._. Symbolic links matching any of the given patterns will be upgraded as symbolic links, rather than as the files they refer to. Otherwise, symbolic links are followed and their target files are sent to the client. rrssyymmlliinnkk _p_a_t_t_e_r_n _._._. This command is similar to ssyymmlliinnkk, but if a directory is matched, all symbolic links beneath it in the tree are treated as matched. nnoorrssyynncc _p_a_t_t_e_r_n _._._. The rsync algorithm will not be used for updating files matching any of the given patterns. This is useful for log files, where CCVVSSuupp's ``append'' optimization is more effec- tive than the rsync algorithm. rrnnoorrssyynncc _p_a_t_t_e_r_n _._._. This command is similar to nnoorrssyynncc, but if a directory is matched, all files beneath it in the tree are treated as matched. eexxeeccuuttee _c_o_m_m_a_n_d (_p_a_t_t_e_r_n _._._.) The given _c_o_m_m_a_n_d will be executed by the client whenever a file matching one of the _p_a_t_t_e_r_ns is successfully updated. The _c_o_m_m_a_n_d comprises all words up to the first (`' charac- ter. Any occurrences of the string `%s' are replaced by the pathname of the updated file on the client host. Occurrences of `%%' are replaced by `%'. The command is executed by passing it to _/_b_i_n_/_s_h. There may be multiple patterns, separated by white space. They are interpreted relative to the pprreeffiixx directory. Each pattern should be written to match the appropriate files as they exist on the _s_e_r_v_e_r. For example, the `,v' suffix of an RCS file name must be matched, even though that suffix will not be present on the client if checkout mode is in effect. Slashes in file names must be matched by explicit slashes in the pattern. CVS `Attic' directories are implicitly included in the matching process, and should not be specified directly in the patterns. A matching file will be found whether it is in the Attic or not. If an eexxeeccuuttee statement matches a directory, its command is executed if the directory is created for the first time, or if its attributes are changed. The command is executed when ascending out of the directory, i.e., after its files and subdirectories have been processed. If multiple eexxeeccuuttee statements match a file, all of the asso- ciated commands are executed in sequence. For security reasons, the client may choose to ignore all eexxeeccuuttee statements. Unrecognized commands are accepted but ignored, for backward compatibil- ity with ssuupp. RRUUNNNNIINNGG AA CCVVSSuupp MMIIRRRROORR SSIITTEE A mirror is a server which obtains and updates its files from a master site by means of CCVVSSuupp, and redistributes them via CCVVSSuupp to other sites. Mirror sites are commonly used in large projects to spread the load among a number of servers. The files being distributed originate at a master site. Each mirror site updates its own copies of the files periodically from there. Clients in turn obtain their updates from any of the mirror sites. ccvvssuuppdd has a special mode of operation for mirror sites that dramatically increases its efficiency. This mode is enabled by the --ss _s_c_a_n_D_i_r option on the command line. Without the --ss option, ccvvssuuppdd makes a full file tree traversal over the files in each requested collection, performing a stat(2) system call on every file. It does this for each client that connects to it, on the assumption that any of the files could change at any time. Such a traversal imposes a heavy seek load on the disks con- taining the files, and limits the number of clients that can be served simultaneously. On a mirror site, the files in the collections are known to change only when new versions of them come in via CCVVSSuupp. The --ss option allows ccvvssuuppdd to take advantage of this property to completely avoid the file tree traversals. This reduces the disk load on the server by orders of magni- tude. In place of the file tree traversal, ccvvssuuppdd gets the necessary information about the files in the collections by reading _s_c_a_n files. The scan files are created by the ccvvssuupp client when it updates the files on the mirror site from the originals at the master site. In CVSUP(1), these files are referred to as _l_i_s_t files. Both names refer to the same files. Each time ccvvssuuppdd serves a client, it finds the scan files created by the most recent update from the master site. Thus the server always has fully up-to-date information about the files in the collections, without the need to perform a file tree traversal. The --ss option is followed by a directory name which specifies where the scan files can be found. It is normally a subdirectory of the base directory, and it must match the location where the ccvvssuupp client main- tains its list files. By default, ccvvssuupp locates these files under the _s_u_p subdirectory of the base directory. To match this, ccvvssuuppdd should be run with `-s sup'. If ccvvssuupp's list file location is changed from the default using the --cc option, then ccvvssuuppdd's scan directory must be changed the same way. There is no default for the --ss option. If it is not given explicitly on the command line, no scan files are used. There does not need to be a scan file for every collection. ccvvssuuppdd first looks for the scan file for the collection requested by the client. If that scan file does not exist, ccvvssuuppdd tries the scan files for each suc- cessive super-collection, and uses the first one it finds. (See the description of the ssuuppeerr keyword in _P_R_E_P_A_R_I_N_G _A _F_I_L_E _C_O_L_L_E_C_T_I_O_N _R_E_P_O_S_I_T_O_R_Y for details.) If no suitable scan file is located, ccvvssuuppdd falls back on performing a file tree traversal. AACCCCEESSSS CCOONNTTRROOLL Access to the server is unrestricted by default, but there is a reason- ably flexible mechanism for limiting access based on the IP addresses of connecting clients. It is enabled by placing a set of rules into the access file _b_a_s_e_/_c_v_s_u_p_d_._a_c_c_e_s_s. The access file is a text file with one rule per line. Comments begin with `#' and extend to the end of the line. White space is ignored except where it is needed to separate adja- cent tokens. Blank lines are ignored. Each rule consists of the following components: ·· A flag indicating whether the rule is a _p_e_r_m_i_t rule, an _a_u_t_h_e_n_t_i_c_a_t_e rule, or a _d_e_n_y rule. The flag is expressed as a single character: `+' means _p_e_r_m_i_t, `*' means _a_u_t_h_e_n_t_i_c_a_t_e_, and `-' means _d_e_n_y_. ·· An IP address to compare with the client's IP address to determine whether the rule applies to the client. This may be expressed either as a numeric IP address or as a host name. Numeric addresses consist of 1 to 4 octet values, separated by dots. If fewer than 4 octets are specified, the trailing octets are assumed to contain 0. Host names are converted to numeric addresses when they are read. If a host has multiple addresses, a separate rule is added for each address. This may or may not have the desired effect. Host names should be used with caution. A name that is slow to resolve can bog down the server significantly. ·· A _m_a_t_c_h_i_n_g mask to be ANDed with the IP addresses of the rule and the client before comparing the addresses. This mask is specified as `/' followed by an integer giving the number of high-order 1s in the mask. For example, `/24' specifies a mask of 0xffffff00. The _m_a_t_c_h_i_n_g mask is optional; if omitted, it defaults to `/32'. ·· A _c_o_u_n_t_i_n_g mask that determines how the clients that match the rule are counted. (See below.) It is specified the same way as the _m_a_t_c_h_i_n_g mask. The _c_o_u_n_t_i_n_g mask is optional; if omitted, it defaults to the same value as the _m_a_t_c_h_i_n_g mask. ·· A _l_i_m_i_t specifying the maximum number of matching clients allowed at the same time. This is specified as a decimal integer, preceded by white space to separate it from the preceding component. The _l_i_m_i_t is optional. If omitted, it defaults to 0 for a _d_e_n_y rule, or to infinity for a _p_e_r_m_i_t rule. When a client connects to the server, its IP address is checked against successive rules in sequence. Each rule is processed as follows: 1. The IP address of the rule is compared with the IP address of the client, after ANDing each address with the _m_a_t_c_h_i_n_g mask. If the addresses do not match, the rule is ignored. 2. The IP addresses of all other currently connected clients are com- pared with the IP address of the connecting client, after ANDing each address with the _c_o_u_n_t_i_n_g mask. If the number of matching clients (not counting the connecting client) is less than the _l_i_m_i_t, then the rule _s_u_c_c_e_e_d_s. Otherwise, the rule _f_a_i_l_s. 3. If the rule is a _p_e_r_m_i_t rule and it succeeded, the client is allowed access, and the rest of the rules are ignored. 4. If the rule is an _a_u_t_h_e_n_t_i_c_a_t_e rule and it succeeded, the server attempts to verify the client's identity using a challenge-response protocol (see _A_U_T_H_E_N_T_I_C_A_T_I_O_N, below). Access is granted or denied based on the outcome of authentication. The rest of the rules are ignored. 5. If the rule is a _d_e_n_y rule and it failed, the client is denied access, and the rest of the rules are ignored. 6. Otherwise, processing continues with the next rule. There is an implicit _a_u_t_h_e_n_t_i_c_a_t_e rule at the end of the list which matches any IP address. Thus, if the processing reaches the end of the list of rules without having allowed or denied access, access is con- trolled by the authentication mechanism. Here are some examples illustrating how the rules are commonly used. -spam.cyberpromo.com Deny all access from a specific host. +mirror.FreeBSD.org Permit unlimited access from a specific host. -user.FreeBSD.org 1 Limit a specific host to at most 1 connection at a time. -198.211.214/24 Deny all access from hosts in a specific class C address block. -198.211.214/24 3 Allow at most 3 connections total from the hosts in a specific class C address block. -198.211.214/24/32 3 Allow at most 3 connections from each of the hosts in a specific class C address block. Note the difference between the previous two examples. The first example imposes a per-network limit, while the second example imposes a per-host limit. The difference is in the _c_o_u_n_t_i_n_g mask. The 24 bit mask in the first example produces a single counter that is shared by all of the hosts in the specified address block. The 32 bit mask in this example produces a separate counter for each host. -0.0.0/0/24 1 Allow no more than 1 connection at a time from each block of 256 addresses. *0.0.0.0/0 For all clients, use authentication to decide whether access is allowed. When updating the access file, it is not necessary to halt the server. But the file should be copied for editing, and then the new version should be moved atomically into place. There is no need to signal the server after updating the file. The server will notice that the file has been touched, and will rescan it automatically. In addition, the server rescans the file every 3 hours to keep up with DNS changes that might affect the resolved addresses of host names. Syntax errors in individual rules are logged, and the offending rules are ignored. Host name lookup failures are also logged. AAUUTTHHEENNTTIICCAATTIIOONN CCVVSSuupp implements an authentication mechanism which can be used to control access to the server. It uses a challenge-response protocol which is immune to packet sniffing and replay attacks. No passwords are sent over the network in either direction. Both the client and the server can independently verify the identities of each other. Authentication of the client is invoked by a successful _a_u_t_h_e_n_t_i_c_a_t_e rule in the _b_a_s_e_/_c_v_s_u_p_d_._a_c_c_e_s_s file, or by ``falling off the end'' of the file. If there is no _c_v_s_u_p_d_._a_c_c_e_s_s file, clients are not authenticated. The file _b_a_s_e_/_c_v_s_u_p_d_._p_a_s_s_w_d holds the information used for performing authentication. This file contains a record for each client who is allowed access to the server. Each record occupies one line in the file. Lines beginning with `#' are ignored, as are lines containing only white space. White space is significant everywhere else in the file. Fields are separated by `:' characters. The first record of the file is special. It specifies the identity of the server itself. This server record has the form: _s_e_r_v_e_r_N_a_m_e:_p_r_i_v_a_t_e_K_e_y _S_e_r_v_e_r_N_a_m_e is the canonical name of the server, e.g., `CVSup.FreeBSD.ORG'. This name is sent to the client, which uses it to choose an appropriate client name and shared secret for authentication. The name is case-insensitive. _P_r_i_v_a_t_e_K_e_y is any string of characters except `:'. When the server gen- erates random challenges to send to the client, it uses _p_r_i_v_a_t_e_K_e_y to make the challenges harder to guess. Challenges are random and quite unpredictable in any case, so the _p_r_i_v_a_t_e_K_e_y isn't really very important. It can be left empty if desired, but the `:' that precedes it must be present. All of the remaining records in the file correspond to individual clients. Each client record has the following form: _c_l_i_e_n_t_N_a_m_e:_s_h_a_r_e_d_S_e_c_r_e_t:_c_l_a_s_s:_c_o_m_m_e_n_t All fields must be present even if some of them are empty. _C_l_i_e_n_t_N_a_m_e is the name of the client to which the record applies. By convention, e- mail addresses are used for all client names, e.g., `BillyJoe@FreeBSD.ORG'. Client names are case-insensitive. _S_h_a_r_e_d_S_e_c_r_e_t is a secret string of characters known only to the client and the server. It is generated from a password chosen by the client, using the ccvvppaasssswwdd utility. The client proves its identity to the server (and vice versa) by demonstrating that it knows the _s_h_a_r_e_d_S_e_c_r_e_t. A client's access may be disabled by changing its _s_h_a_r_e_d_S_e_c_r_e_t field to `*'. The shared secret is never sent across the network, nor can it be used to find out the client's password. However, given the shared secret, a mod- ified version of ccvvssuupp could impersonate the client. Thus, care must be taken to ensure that the _c_v_s_u_p_d_._p_a_s_s_w_d file is readable only by the server. _C_l_a_s_s is reserved for future use. It should be empty. _C_o_m_m_e_n_t contains any additional information about the client that might be useful to the server administrator. For example, it may contain the client's full name and other contact information. When updating the _c_v_s_u_p_d_._p_a_s_s_w_d file, it is not necessary to halt the server. But the file should be copied for editing, and then the new ver- sion should be moved atomically into place. There is no need to signal the server after updating the file. Syntax errors in individual records of the _c_v_s_u_p_d_._p_a_s_s_w_d file are logged, and the offending records are ignored. HHOOWW AACCCCEESSSS CCOONNTTRROOLL AANNDD AAUUTTHHEENNTTIICCAATTIIOONN IINNTTEERRAACCTT Here is a summary of the interactions between the access control and authentication mechanisms. The key principle is that access control takes place first. The outcome of access control determines whether authentication is performed too. 1. If there is no _c_v_s_u_p_d_._a_c_c_e_s_s file, then all clients are granted access. No authentication is done, even if _c_v_s_u_p_d_._p_a_s_s_w_d exists. 2. If the _c_v_s_u_p_d_._a_c_c_e_s_s file exists but is empty, all clients are sub- jected to authentication. If _c_v_s_u_p_d_._p_a_s_s_w_d does not exist, nobody can access the server. 3. If _c_v_s_u_p_d_._a_c_c_e_s_s exists and has some rules in it, but there is no _c_v_s_u_p_d_._p_a_s_s_w_d file, then successful _a_u_t_h_e_n_t_i_c_a_t_e rules cause access to be denied. Access is still granted to those who match successful _p_e_r_m_i_t rules. Falling off the end of the _c_v_s_u_p_d_._a_c_c_e_s_s file results in denial of access. 4. If both the _c_v_s_u_p_d_._a_c_c_e_s_s and _c_v_s_u_p_d_._p_a_s_s_w_d files exist, then: ·· Successful _p_e_r_m_i_t rules cause access to be granted without authentication. ·· Successful _a_u_t_h_e_n_t_i_c_a_t_e rules cause authentication to be per- formed. Access is granted or denied based on the outcome of that. Falling off the end of the _c_v_s_u_p_d_._a_c_c_e_s_s file is included in this case. ·· Failing _d_e_n_y rules cause access to be denied. RRCCSS KKEEYYWWOORRDD EEXXPPAANNSSIIOONN In checkout mode, CCVVSSuupp expands RCS keywords as described in co(1). It expands all of the standard keywords, and also the non-standard `$CVSHeader$' keyword. This expands the same as `$Header$', except that the RCS file's pathname is expressed relative to the pprreeffiixx directory, rather than as an absolute pathname. The pprreeffiixx is assumed to be the root of the CVS repository. It is also possible to define aliases for the standard RCS keywords, and to selectively enable or disable the recognition of individual keywords. These properties are controlled on a repository-wide basis by directives in a file named _p_r_e_f_i_x_/_C_V_S_R_O_O_T_/_o_p_t_i_o_n_s. Each directive occupies one line of the file. Comments begin with `#' and extend to the end of line. Blank lines are ignored. The syntax is ridiculous, for historical rea- sons. To define a keyword alias, use a line of the form: tag=_a_l_i_a_s[=_k_e_y_w_o_r_d] For example: tag=FreeBSD=CVSHeader defines a new RCS keyword `$FreeBSD$', which expands the same as `$CVSHeader$'. If the second `=' and the _k_e_y_w_o_r_d are omitted, the key- word defaults to `Id'. To disable all but certain selected keywords, use a line of the form: tagexpand=i_k_e_y_w_o_r_d[,_._._.] For example: tagexpand=iFreeBSD,Id disables the expansion of all keywords except `$FreeBSD$' and `$Id$'. The leading `i' stands for ``include''. To enable all but certain selected keywords, use a line of the form: tagexpand=e_k_e_y_w_o_r_d[,_._._.] For example: tagexpand=eFreeBSD,Id enables the expansion of all keywords except `$FreeBSD$' and `$Id$'. The leading `e' stands for ``exclude''. SSHHUUTTDDOOWWNN If there exists a file _b_a_s_e_/_c_v_s_u_p_d_._H_A_L_T that is newer than the time when the server was started, then the server will reject all new incoming con- nection requests. Clients which had already started will run to comple- tion, but no new ones will be accepted. This mechanism is awkward and weak, and will probably be changed in a future release. SSEECCUURRIITTYY ccvvssuuppdd does not create or write any files, except for its log file if one is specified on the command line. There is thus little risk that ccvvssuuppdd can be subverted into damaging the system on which it is running. A more likely risk is that ccvvssuuppdd might be spoofed into sending out files that are not intended to be publicly distributed. ccvvssuuppdd is very careful to prevent this from happening. Nevertheless, for maximum protection it is a good idea to run ccvvssuuppdd as a completely unprivileged user analogous to `nobody', serving only files that are readable by everyone. CCVVSSuupp has no provision for encrypting the data sent across the network. If secrecy is desired then the connection can be tunneled through sssshh. FFIILLEESS /usr/local/etc/cvsup Default _b_a_s_e directory. sup Default _c_o_l_l_D_i_r subdirectory. _b_a_s_e_/_c_o_l_l_D_i_r_/_c_o_l_l_e_c_t_i_o_n/releases Releases file. _b_a_s_e_/_c_o_l_l_D_i_r_/_c_o_l_l_e_c_t_i_o_n/_l_i_s_t List file. _b_a_s_e/cvsupd.HALT Shutdown file. _b_a_s_e/cvsupd.access Access control file. _b_a_s_e/cvsupd.passwd Authentication password file. _p_r_e_f_i_x/CVSROOT/options RCS keyword configuration file. SSEEEE AALLSSOO co(1), cvpasswd(1), cvs(1), cvsup(1). http://www.cvsup.org/ AAUUTTHHOORRSS John Polstra . LLEEGGAALLIITTIIEESS CVSup is a registered trademark of John D. Polstra. BBUUGGSS An RCS file is not recognized as such unless its name ends with `,v'. Any directory named `Attic' is assumed to be a CVS Attic, and is treated specially. FreeBSD January 1, 2002 FreeBSD