CVSUP(1) FreeBSD General Commands Manual CVSUP(1) NNAAMMEE ccvvssuupp - network distribution package for CVS repositories SSYYNNOOPPSSIISS ccvvssuupp [--11eeEEggkkvvzzZZ] [--bb _b_a_s_e] [--cc _c_o_l_l_D_i_r] [--dd _d_e_l_L_i_m_i_t] [--hh _h_o_s_t] [--ii _p_a_t_t_e_r_n] [--ll _l_o_c_k_f_i_l_e] [--LL _v_e_r_b_o_s_i_t_y] [--pp _p_o_r_t] [--PP _p_o_r_t_|_l_o_-_h_i_|_-_|_m] [--rr _m_a_x_R_e_t_r_i_e_s] _s_u_p_f_i_l_e [_d_e_s_t_D_i_r] DDEESSCCRRIIPPTTIIOONN CCVVSSuupp is a software package for distributing and updating collections of files across a network. The name CCVVSSuupp refers to the package as a whole. It consists of a client program, ccvvssuupp, and a server program, ccvvssuuppdd. This manual page describes the general aspects of the CCVVSSuupp package, as well as the particulars of the ccvvssuupp client program. For detailed infor- mation about ccvvssuuppdd, see cvsupd(8). Unlike more traditional network distribution packages, such as rrddiisstt and ssuupp, CCVVSSuupp is tailored specifically for distributing CVS repositories. CCVVSSuupp takes advantage of the properties of CVS repositories and the files they contain (in particular, RCS files), enabling it to perform updates much faster than traditional systems. QQUUIICCKK SSTTAARRTT FFOORR FFrreeeeBBSSDD SSUUPP UUSSEERRSS If you have been using ssuupp to retrieve the FreeBSD `cvs', `current', or `stable' release, you will find it easy to switch to CCVVSSuupp. A utility, ssuuppccoonnvv, is provided for that purpose. If you invoke it on an existing FreeBSD _s_u_p_f_i_l_e, with the command `supconv _s_u_p_f_i_l_e', the converted ver- sion of the file will appear in `_s_u_p_f_i_l_e.cvsup'. Alternatively, you can convert your _s_u_p_f_i_l_es manually. To receive the `cvs' release, simply use your existing _s_u_p_f_i_l_e, un- changed. To receive the `current' release, edit your _s_u_p_f_i_l_e as follows: 1. Change all occurrences of `release=current' to `release=cvs'. 2. Change all occurrences of `prefix=/usr/src' and `prefix=/usr/ports' to `prefix=/usr'. 3. Add the phrase `tag=.' to each line of your _s_u_p_f_i_l_e. To receive the `stable' release: 1. Change all occurrences of `release=current' to `release=cvs'. 2. Change all occurrences of `prefix=/usr/src' to `prefix=/usr'. 3. Add the phrase `tag=RELENG_2_1_0' to each line of your _s_u_p_f_i_l_e. Note: there is no `stable' release of the ports collection. After you have made any necessary modifications to your _s_u_p_f_i_l_e, run the client by typing `cvsup _s_u_p_f_i_l_e'. _W_A_R_N_I_N_G: If you want to get the `current' or `stable' release, make sure you specify the `tag' value correctly. If you misspell the tag, or capi- talize it inaccurately, CCVVSSuupp will delete your existing files, since they are effectively ``dead'' for the specified tag. OOPPTTIIOONNSS The client program ccvvssuupp requires at least a single argument, _s_u_p_f_i_l_e. It names a file describing one or more collections of files to be trans- ferred and/or updated from the server. The _s_u_p_f_i_l_e has the same format as the corresponding file used by ssuupp. An optional argument _d_e_s_t_D_i_r may also be specified. If given, it names a directory under which all updated files will be placed. When _d_e_s_t_D_i_r is specified, the client's original files are left untouched. This feature is primarily intended for testing. The following options are supported by ccvvssuupp: --11 Disables automatic retries when transient failures occur and the GUI is not being used. Without this option, a transient failure such as a dropped network connection causes ccvvssuupp to retry repeatedly, using randomized exponential backoff to space the retries. This option is equivalent to --rr 00,, and is implied when the GUI is used. --bb _b_a_s_e Specifies the base directory under which ccvvssuupp will maintain its bookkeeping files, overriding any bbaassee specifications in the _s_u_p_f_i_l_e. --cc _c_o_l_l_D_i_r Specifies the subdirectory of _b_a_s_e where the information about the collections is maintained. The default is _s_u_p. --dd _d_e_l_L_i_m_i_t Specifies the maximum number of files that may be deleted in a single update run. Any attempt to exceed the limit results in a fatal error. This can provide some protection against temporary configuration mistakes on the server. The default limit is infinity. --ee Enables the execution of shell commands received from the server, as if the eexxeeccuuttee keyword were added to every collec- tion in the _s_u_p_f_i_l_e. --EE Disables the execution of shell commands received from the server, as if the eexxeeccuuttee keyword were removed from every collection in the _s_u_p_f_i_l_e. --gg Disables the use of the graphical user interface. This op- tion is implied if the DISPLAY environment variable is not set. --hh _h_o_s_t Specifies the server host to contact, overriding any hhoosstt specifications in the _s_u_p_f_i_l_e. --ii _p_a_t_t_e_r_n Causes ccvvssuupp to include only files and directories matching _p_a_t_t_e_r_n in the update. If a directory matches the pattern, then the entire subtree rooted at the directory is included. If this option is specified multiple times, the patterns are combined using the `or' operation. If no --ii options are giv- en, the default is to update all files in each collection. The _p_a_t_t_e_r_n is a standard file name pattern. It is inter- preted relative to the collection's prefix directory. Slash characters are matched only by explicit slashes in the pat- tern. Leading periods in file name are not treated special- ly. The GUI has a type-in field where the patterns may be edited. --kk Causes ccvvssuupp to keep the temporary copies of any incorrectly edited files, in the event of checksum mismatches. This op- tion is for debugging, to help determine why the files were edited incorrectly. Regardless of whether this option is specified, the permanent versions of faulty files are re- placed with correct versions obtained by transferring the files in their entirety. Such transfers are called fixups. --ll _l_o_c_k_f_i_l_e Creates and locks the _l_o_c_k_f_i_l_e while the update is in progress. If _l_o_c_k_f_i_l_e is already locked, ccvvssuupp fails without performing automatic retries. This option is useful when ccvv-- ssuupp is executed periodically from ccrroonn. It prevents a job from interfering with an earlier job that is perhaps taking extra long because of network problems. POSIX-style file locking is used, as described in fcntl(2). The process-ID is written to the lock file in text form when the lock is successfully acquired. Upon termination of the update, the lock file is removed. --LL _v_e_r_b_o_s_i_t_y Sets the verbosity level for non-GUI output. A level of 0 causes ccvvssuupp to be completely silent unless errors occur. A level of 1 (the default) causes each updated file to be list- ed. A level of 2 provides more detailed information about the updates performed on each file. All messages are direct- ed to the standard output. This option is ignored when the GUI is used. --pp _p_o_r_t Sets the TCP port to which ccvvssuupp attempts to connect on the server host. This feature is primarily for testing. The de- fault port is 5999. When not in passive mode (see the de- scription of the --PP option), the server also uses the next lower port to establish a second connection back to the client. --PP _p_o_r_t_|_l_o_-_h_i_|_-_|_m Controls the establishment of the auxiliary TCP connection(s) used to carry information between the client and the server. Altogether, the client and server require four unidirectional channels to communicate: two from the client to the server, and two from the server to the client. These four unidirec- tional channels can be set up in different ways, to support various firewall setups. The modes provided for this are ac- tive mode, passive mode, multiplexed mode, and SOCKS mode. By default, the channels are established in active mode. Ac- tive mode implements the four unidirectional channels using two bidirectional TCP connections. The original connection from the client to the server implements two channels, and a second TCP connection implements the other two channels. To establish the second TCP connection, the server connects back to the client. In the absence of the --PP option, the client listens for the connection on a port chosen by the operating system. Many operating systems use ports in the range 1024-5000 for this purpose. The user can specify a particu- lar port with --PP _p_o_r_t, or a range of ports with --PP _l_o_-_h_i. These port specifications cannot be used through a SOCKS proxy server. Passive mode is similar in that it also uses two TCP connec- tions to implement the four unidirectional channels. Howev- er, in passive mode the client connects to the server to cre- ate the second TCP connection. Passive mode can be useful when the client is behind a firewall that allows outbound connections, but denies most incoming connections. To select passive mode, use the option --PP --. Passive mode cannot be used through a SOCKS proxy server. Multiplexed mode uses only a single TCP connection to imple- ment the four channels. A built-in packet layer multiplexes the different logical channels on top of the TCP connection, in a manner not unlike sssshh's port forwarding feature. This adds a very small amount of communication overhead (<1%) and a little bit of CPU overhead, but it should work behind al- most any kind of firewall setup. The firewall must permit the client host to initiate connections to port 5999 of the server host; beyond that, no special permissions are re- quired. To select multiplexed mode, use the option --PP mm. Multiplexed mode can be used in conjunction with a SOCKS proxy server. Simply run ccvvssuupp under the mm33ssoocckkss command, and specify the --PP mm option. SOCKS mode is an alternate mode for use with SOCKS proxy servers. In SOCKS mode, four TCP connections are used, each in one direction only. The use of four unidirectional TCP connections works around a limitation in the SOCKS proxy server that would otherwise cause it to deadlock. (Believe it or not, the SOCKS server uses blocking I/O calls.) SOCKS mode is selected when ccvvssuupp is run under the mm33ssoocckkss command, and no --PP option is given. See also _U_S_I_N_G _C_V_S_u_p _W_I_T_H _S_O_C_K_S, below. --rr _m_a_x_R_e_t_r_i_e_s Limits the number of automatic retries that will be attempted when transient errors such as lost network connections are encountered. By default, when the GUI is not used, ccvvssuupp will retry indefinitely until an update is successfully com- pleted. The retries are spaced using randomized exponential backoff. Use of the GUI implies --rr 00. Note that --rr 00 is equivalent to the --11 option. --vv Prints the version number and exits, without contacting the server. --zz Enables compression for all collections, as if the ccoommpprreessss keyword were added to every collection in the _s_u_p_f_i_l_e. --ZZ Disables compression for all collections, as if the ccoommpprreessss keyword were removed from every collection in the _s_u_p_f_i_l_e. The _s_u_p_f_i_l_e is as described in sup(1). However, not all of the keywords described there are supported by ccvvssuupp, and a couple of new ones may be specified. Default settings may be specified in a line whose collection name is **ddeeffaauulltt. Such defaults will apply to subsequent lines in the _s_u_p_f_i_l_e. Multiple **ddeeffaauulltt lines may be present. New values augment or override any defaults specified earlier in the _s_u_p_f_i_l_e. Values specified explicit- ly for a collection override any default values. The most commonly used keywords are: rreelleeaassee==_r_e_l_e_a_s_e_n_a_m_e With traditional ssuupp, this keyword specifies a particular re- lease from which all files are to be taken. For example, ex- isting FreeBSD ssuupp archives normally support the releases `cvs', `current', and `stable'. CCVVSSuupp always operates direct- ly from the CVS repository. It does not require separate source trees for `stable' and `current' on the server ma- chine. Therefore, the release should normally be specified as `cvs'. bbaassee==_b_a_s_e This specifies a directory under which ccvvssuupp will maintain its bookkeeping files, describing the state of each collec- tion on the client machine. The _b_a_s_e directory must already exist; ccvvssuupp will not create it. The default _b_a_s_e directory is _/_u_s_r_/_l_o_c_a_l_/_e_t_c_/_c_v_s_u_p. pprreeffiixx==_p_r_e_f_i_x This is the directory under which updated files will be placed. By default, it is the same as _b_a_s_e. If it is not an absolute pathname, it is interpreted relative to _b_a_s_e. The _p_r_e_f_i_x directory must already exist; ccvvssuupp will not create it. As a special case, if _p_r_e_f_i_x is a symbolic link pointing to a nonexistent file named `SKIP', then ccvvssuupp will skip the col- lection. The parameters associated with the collection are still checked for validity, but none of its files will be up- dated. This feature allows a site to use a standard _s_u_p_f_i_l_e on several machines, yet control which collections get updat- ed on a per-machine basis. hhoosstt==_h_o_s_t_n_a_m_e This specifies the server machine from which all files will be taken. ccvvssuupp requires that all collections in a single run come from the same host. If you wish to update collec- tions from several different hosts, you must run ccvvssuupp sever- al times. ddeelleettee The presence of this keyword gives ccvvssuupp permission to delete files. If it is missing, no files will be deleted. The presence of the ddeelleettee keyword puts ccvvssuupp into so-called _e_x_a_c_t mode. In exact mode, CCVVSSuupp does its best to make the client's files correspond to those on the server. This in- cludes deleting individual deltas and symbolic tags from RCS files, as well as deleting entire files. In exact mode, CCVVSSuupp verifies every edited file with a checksum, to ensure that the edits have produced a file identical to the master copy on the server. If the checksum test fails for a file, then CCVVSSuupp falls back upon transferring the entire file. In general, CCVVSSuupp deletes only files which are known to the server. Extra files present in the client's tree are left alone, even in exact mode. More precisely, CCVVSSuupp is willing to delete two classes of files: ++oo Files that were previously created or updated by CCVVSSuupp itself. ++oo Checked-out versions of files which are marked as dead on the server. uussee--rreell--ssuuffffiixx Causes ccvvssuupp to append a suffix constructed from the release and tag to the name of each list file that it maintains. See _T_H_E _L_I_S_T _F_I_L_E for details. ccoommpprreessss This enables compression of all data sent across the network. Compression is quite effective, normally eliminating 65% to 75% of the bytes that would otherwise need to be transferred. However, it is costly in terms of CPU time on both the client and the server. On local area networks, compression is gen- erally counter-productive; it actually slows down file up- dates. On links with speeds of 56K bits/second or less, com- pression is almost always beneficial. For network links with speeds between these two extremes, let experimentation be your guide. The --zz command line option enables the ccoommpprreessss keyword for all collections, regardless of what is specified in the sup- file. Likewise, the --ZZ command line option disables the ccoommpprreessss option for all collections. nnoorrssyynncc Disables the use of Tridgell & Mackerras' _r_s_y_n_c algorithm for updating regular (non-RCS) files. The algorithm works cor- rectly for any kind of file, but it may be ineffective and computationally expensive for files such as compressed tar archives. eexxeeccuuttee Enables the execution of shell commands received from the server. This should be used with caution, since it may con- stitute a security risk. pprreesseerrvvee Causes ccvvssuupp to attempt to transfer all possible file at- tributes from the server to the client. The attributes sup- ported depend on both the host platform and the client plat- form. On FreeBSD systems, the following attributes are sup- ported: ++oo Owner. ++oo Group. ++oo Permissions. ++oo Flags. ++oo Modification time. Of these, the first four are controlled by the pprreesseerrvvee key- word, while the fifth is preserved in all cases. The pprreesseerrvvee keyword is not intended to be used for updating user files or CVS repositories. It is intended only for spe- cialized applications in which a host's entire file tree is to be replicated exactly. Any differences between the server host and the client host can cause problems if pprreesseerrvvee is specified. For example, if the client receives a file whose owner does not exist on the client machine, it will be unable to preserve the owner. This may in turn cause the permis- sions to have unintended meanings. In addition, each subse- quent update run will cause further unsuccessful attempts to correct the file's owner on the client, wasting time and bandwidth. Finally, pprreesseerrvvee mode increases the network traffic and slows down updates. For pprreesseerrvvee mode to function properly, the client must be executed with root access permissions. If the client is not root, then attempts to preserve the owner, group, and flags are suppressed. The pprreesseerrvvee keyword is ignored in checkout mode. ccvvssuupp accepts but ignores the other _s_u_p_f_i_l_e keywords described in sup(1). Some additional, more specialized keywords are described below. OOPPEERRAATTIIOONN ccvvssuupp includes a graphical user interface (GUI) which allows one to moni- tor its progress and performance during an update. The GUI is disabled if the --gg command line option is given, or if the DISPLAY environment variable is not set. The GUI includes a ``Filter'' type-in field, where patterns may be entered to restrict the files to be updated. The pat- terns are as described for the --ii option. If multiple patterns are en- tered, they should be separated by white space. At present, the GUI does not support changing the parameters specified in the _s_u_p_f_i_l_e. That is planned for a future release. Despite its relative uselessness, the GUI is fun to watch. CCVVSS MMOODDEE CCVVSSuupp supports two primary modes of operation. They are called _C_V_S mode and _c_h_e_c_k_o_u_t mode. In CVS mode, the client receives copies of the actual RCS files making up the master CVS repository. CVS mode is the default mode of operation. It is appropriate when the user wishes to maintain a full copy of the CVS repository on the client machine. For the FreeBSD source archives, using CVS mode is roughly equivalent to specifying the `cvs' release with tra- ditional ssuupp. CCHHEECCKKOOUUTT MMOODDEE In checkout mode, the client receives specific revisions of files, checked out directly from the server's CVS repository. Checkout mode al- lows the client to receive the equivalent of the traditional FreeBSD `current' and `stable' releases, without requiring any extra disk space on the server for storing those releases in checked-out form. Checkout mode provides much flexibility beyond that basic functionality, however. The client can specify any CVS symbolic tag, or any date, or both, and CCVVSSuupp will provide the corresponding checked-out versions of the files in the repository. Checkout mode is selected on a per-collection basis, by the presence of one or both of the following keywords in the _s_u_p_f_i_l_e: ttaagg==_t_a_g_n_a_m_e This specifies a symbolic tag that should be used to select the revisions that are checked out from the CVS repository. The tag may refer to either a branch or a specific revision. It must be symbolic; numeric revision numbers are not sup- ported. For the FreeBSD source repository, the most commonly used tags will be: RELENG_2_1_0 The `stable' branch. RELENG_2_1_5_RELEASE The 2.1.5 release. . The main branch (the `current' re- lease). This is the default, if only the ddaattee keyword is given. ddaattee==[_c_c]_y_y_._m_m_._d_d_._h_h_._m_m_._s_s This specifies a date that should be used to select the revi- sions that are checked out from the CVS repository. The client will receive the revisions that were in effect at the specified date and time. At present, the date format is inflexible. All 17 or 19 characters must be specified, exactly as shown. For the years 2000 and beyond, specify the century _c_c. For earlier years, specify only the last two digits _y_y. Dates and times are considered to be GMT. The default date is `.', which means ``as late as possible''. To enable checkout mode, you must specify at least one of these keywords. If both are missing, CCVVSSuupp defaults to CVS mode. If both a branch tag and a date are specified, then the revisions on the given branch, as of the given date, will be checked out. It is permit- ted, but not particularly useful, to specify a date with a specific re- lease tag. In checkout mode, the tag and/or date may be changed between updates. For example, suppose that a collection has been transferred using the specification `tag=.'. The user could later change the specification to `tag=RELENG_2_1_0'. This would cause CCVVSSuupp to edit the checked-out files in such a way as to transform them from the `current' versions to the `stable' versions. In general, CCVVSSuupp is willing to transform any tag/date combination into any other tag/date combination, by applying the intervening RCS deltas to the existing files. When transforming a collection of checked-out files from one tag to an- other, it is important to specify the lliisstt keyword in the _s_u_p_f_i_l_e, to en- sure that the same list file is used both before and after the transfor- mation. The list file is described in _T_H_E _L_I_S_T _F_I_L_E, below. TTHHEE LLIISSTT FFIILLEE For efficiency, ccvvssuupp maintains a bookkeeping file for each collection, called the list file. The list file contains information about which files and revisions the client currently possesses. It also contains in- formation used for verifying that the list file is consistent with the actual files in the client's tree. The list file is not strictly necessary. If it is deleted, or becomes inconsistent with the actual client files, ccvvssuupp falls back upon a less efficient method of identifying the client's files and performing its up- dates. Depending on CCVVSSuupp ''ss mode of operation, the fallback method em- ploys time stamps, checksums, or analysis of RCS files. Because the list file is not essential, ccvvssuupp is able to ``adopt'' an ex- isting file tree created by ssuupp or ccttmm. ccvvssuupp identifies the client's versions of the files, updates them as necessary, and creates a list file for future use. Adopting a foreign file tree is not as fast as perform- ing a normal update. It also produces a heavier load on the server. The list file is stored in a collection-specific directory; see _F_I_L_E_S for details. Its name always begins with `checkouts'. If the keyword uussee-- rreell--ssuuffffiixx is specified in the _s_u_p_f_i_l_e, a suffix, formed from the release and tag, is appended to the name. The default suffix can be overridden by specifying an explicit suffix in the _s_u_p_f_i_l_e: lliisstt==_s_u_f_f_i_x This specifies a suffix for the name of the list file. A leading dot is provided automatically. For example, `list=stable' would produce a list file named _c_h_e_c_k_o_u_t_s_._s_t_a_b_l_e, regardless of the release, tag, or uussee--rreell-- ssuuffffiixx keyword. RREEFFUUSSEE FFIILLEESS The user can specify sets of files that he does not wish to receive. The files are specified as file name patterns in so-called _r_e_f_u_s_e files. The patterns are separated by whitespace, and multiple patterns are permitted on each line. Files and directories matching the patterns are neither updated nor deleted; they are simply ignored. The patterns are similar to those of sh(1), except that there is no spe- cial treatment for slashes or for filenames that begin with a period. For example, the pattern `*.c' will match any file name ending with `.c' including those in subdirectories, such as `foo/bar/lam.c'. All patterns are interpreted relative to the collection's prefix directory. As many as three refuse files are examined for each _s_u_p_f_i_l_e line. There can be a global refuse file named _b_a_s_e_/_c_o_l_l_D_i_r_/_r_e_f_u_s_e which applies to all collections and releases. There can be a per-collection refuse file named _b_a_s_e_/_c_o_l_l_D_i_r_/_c_o_l_l_e_c_t_i_o_n_/_r_e_f_u_s_e which applies to a specific collec- tion. Finally, there can be a per-release and tag refuse file which ap- plies only to a given release/tag combination within a collection. The name of the latter is formed by suffixing the name of the per-collection refuse file in the same manner as described above for the list file. None of the refuse files are required to exist. As an example, suppose that the _b_a_s_e and _c_o_l_l_D_i_r both have their default values, and that the collection and release are `src-all' and `cvs', re- spectively. Assume further that checkout mode is being used with `tag=RELENG_2_2'. The three possible refuse files would then be named: _/_u_s_r_/_l_o_c_a_l_/_e_t_c_/_c_v_s_u_p_/_s_u_p_/_r_e_f_u_s_e _/_u_s_r_/_l_o_c_a_l_/_e_t_c_/_c_v_s_u_p_/_s_u_p_/_s_r_c_-_a_l_l_/_r_e_f_u_s_e _/_u_s_r_/_l_o_c_a_l_/_e_t_c_/_c_v_s_u_p_/_s_u_p_/_s_r_c_-_a_l_l_/_r_e_f_u_s_e_._c_v_s_:_R_E_L_E_N_G___2___2 UUSSIINNGG CCVVSSuupp FFOORR MMIIRRRROORRIINNGG Although CCVVSSuupp is optimized for CVS repositories, it works quite well as a general purpose mirroring tool. It is able to update all types of files. ++oo RCS files are updated by transferring individual tags and deltas, and merging them into the client file. ++oo Regular files are updated using the rsync algorithm, if it is en- abled. If the rsync algorithm is disabled, files which have had data appended to them on the server (e.g., log files) receive only the new tail portion. Other regular files are replaced in whole. ++oo Empty directories are preserved. ++oo Symbolic links are updated as dictated by ssyymmlliinnkk and rrssyymmlliinnkk com- mands in the server's configuration files. See cvsupd(8). ++oo Hard links are preserved within each collection, but not between col- lections. ++oo Device nodes are updated by major and minor device number. This may not produce the desired results if the client host and the server host run different operating systems. CCVVSSuupp AANNDD FFIIRREEWWAALLLLSS ccvvssuupp provides a number of different modes designed to work thorough var- ious firewall setups. These are controlled by the --PP option and by the use of the mm33ssoocckkss command. To allow ccvvssuupp to be used, the firewall must at a minimum permit outbound connections to port 5999 of the server host. If this condition is met, then multiplexed mode (--PP mm) should work, with or without SOCKS. With slightly more permissive firewall rules it may be possible to use passive mode or one of the other modes, for a slight gain in efficiency. See the description of the --PP option for details. UUSSIINNGG CCVVSSuupp WWIITTHH SSOOCCKKSS Communication through a SOCKS proxy server is currently supported only under FreeBSD. It requires a modified Modula-3 runtime system as provid- ed by the _l_a_n_g_/_m_o_d_u_l_a_-_3_-_l_i_b port, and an add-on SOCKS library from the _l_a_n_g_/_m_o_d_u_l_a_-_3_-_s_o_c_k_s port. Also, the SOCKS library uses dynamic linking techniques which require that the ccvvssuupp executable be fully dynamic. The FreeBSD port _n_e_t_/_c_v_s_u_p links ccvvssuupp fully dynamic as required. To enable SOCKS operation, simply execute ccvvssuupp with the mm33ssoocckkss command provided in the _l_a_n_g_/_m_o_d_u_l_a_-_3_-_s_o_c_k_s package. See m3socks(1) for further details. UUSSIINNGG sssshh PPOORRTT FFOORRWWAARRDDIINNGG As an alternative to SOCKS, a user behind a firewall can penetrate it with the TCP port forwarding provided by the Secure Shell package sssshh. The user must have a login account on the CCVVSSuupp server host in order to do this. The procedure is as follows: 1. Choose an arbitrary unprivileged TCP port number which is likely to be free on both the client host and the server host. In the follow- ing, we refer to the chosen port number as _p_p_p_p. 2. Establish a connection to the server host with sssshh, like this: ssh -f -x -L 5999:localhost:5999 -R pppp:localhost:pppp \ host sleep 60 This sets up the required port forwarding. You must start the ccvvssuupp update before the 60-second sslleeeepp finishes. Once the update has be- gun, sssshh will keep the forwarded channels open as long as they are needed. 3. Run ccvvssuupp on the local host, including these arguments on the com- mand line: -h localhost -P pppp 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/checkouts* List files. _b_a_s_e_/_c_o_l_l_D_i_r/refuse Global refuse file. _b_a_s_e_/_c_o_l_l_D_i_r_/_c_o_l_l_e_c_t_i_o_n/refuse* Per-collection and per-release and tag refuse files. SSEEEE AALLSSOO ctm(1), cvs(1), cvsupd(8), m3socks(1), rcsintro(1), ssh(1), sup(1), supconv(1), supfilesrv(8). AAUUTTHHOORRSS John 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. Because of bugs in the SOCKS library or server, most forms of the --PP op- tion cannot be used with SOCKS. Multiplexed mode (--PP mm) can be used, but the other forms of --PP are rejected. The GUI interacts poorly with some window managers, notably FVWM. There are problems with both versions 1 and 2 of FVWM, though it appears that they are not as bad in version 2. Adding the line Style "cvsup" ClickToFocus to FVWM2's _._f_v_w_m_r_c file helps quite a bit. The problem appears to be caused by window manager bugs, triggered by the GUI's use of the `WM_TAKE_FOCUS' protocol. As a work-around, you can always use the sup- compatible GUI provided by the --gg option. FreeBSD August 23, 1996 10