Installation and Operation of UUCP 4.3BSD Edition D. A. Nowitz Bell Laboratories Murray Hill, New Jersey 07974 Ross Green Computer Systems Research Group Computer Science Division Department of Electrical Engineering and Computer Science University of California, Berkeley Berkeley, CA 94720 _A_B_S_T_R_A_C_T Uucp is a collection of programs designed to permit communication between UNIX* systems using either dial-up or hardwired communication lines. It is used for file transfers and remote command execution. The first version of the system was designed and implemented by M. E. Lesk (SMM:21). There have been many changes to the implemen- tation of UUCP since the release of 4.2BSD. Many problems been fixed, and several improvements to provide greater throughput have been incorporated. A number of new features and facilities have been added. These include: o+ Improved administration. o+ Extended modem support. o+ New transfer protocols o+ Security enhancements. The first part of this document gives a detailed description of the use of UUCP. The command descrip- tions do not describe all the options available; see the manual pages for complete descriptions. The rest of the document indicates the changes that have been __________________________ * UNIX is a Trademark of Bell Laboratories. September 2, 1987 - 2 - made to UUCP, and provides an update on the installa- tion and implementation details. It is for use by an administrator or installer of the system; it is not meant as a user's guide. Revised May 1986 _1. _U_u_c_p _I_m_p_l_e_m_e_n_t_a_t_i_o_n _D_e_s_c_r_i_p_t_i_o_n Uucp is a batch type operation. Files are created in a spool directory for processing by the uucp demons. For efficiency, the files are separated by type into subdirec- tories of this directory. The subdirectories will be described in section 9. There are three types of files used for the execution of work. _D_a_t_a _f_i_l_e_s contain data for transfer to remote systems. _W_o_r_k _f_i_l_e_s contain instructions for file transfers between systems. _E_x_e_c_u_t_i_o_n _f_i_l_e_s are instructions for UNIX command executions which involve the resources of one or more systems. The uucp system consists of ten primary (i.e. invoked by users) and four secondary programs. These programs are sum- marized in section 9. The three most important primary pro- grams are: uucp This program creates work and gathers data files in the spool directories for the transmission of files. uux This program creates work files, execute files and gathers data files for the remote execution of UNIX commands. uusnap This program provides a snapshot of the current queue including transfers queued and commands to be executed locally. The three most important secondary programs are: uucico This program actually performs the data transmission. uuxqt This program executes the execution files for UNIX command execution. uuclean This program removes old files from the spool directories. The next six sections of this paper will describe the opera- tion of each program. The remainder of this paper describes September 2, 1987 - 3 - the installation of the system, the security aspects of the system, the files required for execution, and the adminis- tration of the system. _2. _U_u_c_p - _U_N_I_X _t_o _U_N_I_X _F_i_l_e _C_o_p_y The _u_u_c_p command is the user's primary interface with the system. The _u_u_c_p command was designed to look like _c_p to the user. The syntax is _u_u_c_p [ option ] ... source ... destination where the source and destination may contain the prefix _s_y_s_t_e_m-_n_a_m_e! which indicates the system on which the file or files reside or where they will be copied. The options interpreted by _u_u_c_p are: -f Don't make directories when copying the file. The default is to make the necessary direc- tories. -C Copy source files to the spool directory. The default is to use the specified source when the actual transfer takes place. -g_l_e_t_t_e_r Put _l_e_t_t_e_r in as the grade in the name of the work file. (This can be used to change the order of work for a particular machine.) -m Send mail on completion of the work. -n_u_s_e_r Notify _u_s_e_r on the destination system that a file was sent. The following options are used primarily for debugging: -r Queue the job but do not start _u_u_c_i_c_o pro- gram. -s_d_i_r Use directory _d_i_r for the top level spool directory. -x_n_u_m _N_u_m is the level of debugging output desired. The destination may be a directory name, in which case the file name is taken from the last part of the source's name. The source name may contain special shell characters such as ``?*[]''. If a source argument has a _s_y_s_t_e_m-_n_a_m_e! prefix for a remote system, the file name expansion will be done on the remote system. Quote or escape characters that have special meaning to your shell, for example, `!' in csh. The command September 2, 1987 - 4 - uucp *.c usg!/usr/dan will set up the transfer of all files whose names end with ``.c'' to the ``/usr/dan'' directory on the ``usg'' machine. The source and/or destination names may also contain a ~_u_s_e_r prefix. This translates to the login directory on the specified system. For names with partial path-names, the current directory is prepended to the file name. File names with ../ are not permitted. The command uucp usg!~dan/*.h ~dan will set up the transfer of files whose names end with ``.h'' in dan's login directory on system ``usg'' to dan's local login directory. For each source file, the program will check the source and destination file-names and the system-part of each to clas- sify the work into one of five types: [1] Copy source to destination on local system. [2] Receive files from a remote system. [3] Send files to a remote system. [4] Send files from remote system to another remote system. [5] Receive files from remote system when the source pathname contains special shell characters as men- tioned above. After the work has been set up in the spool directories, the _u_u_c_i_c_o program is started to try to contact the other machine to execute the work (unless the -r option was speci- fied). _T_y_p_e _1 _U_u_c_p makes a copy of the file. The -_m option is not honored in this case. _T_y_p_e _2 A one line _w_o_r_k _f_i_l_e is created for each file requested and put in the appropriate spool directory with the following fields, each separated by a blank. (All _w_o_r_k _f_i_l_e_s and _e_x_e_- _c_u_t_e _f_i_l_e_s use a blank as the field separator.) [1] R September 2, 1987 - 5 - [2] The full path-name of the source or a ~user/path- name. The ~_u_s_e_r part will be expanded on the remote system. [3] The full path-name of the local destination file. If the ~_u_s_e_r notation is used, it will be immedi- ately expanded to be the login directory for the user. [4] The user's login name. [5] A ``-'' followed by an option list. _T_y_p_e _3 For each source file, a _w_o_r_k _f_i_l_e is created. A ``-C'' op- tion on the _u_u_c_p command will cause the _d_a_t_a _f_i_l_e to be copied into the spool directory and the file to be transmit- ted from the copy. The fields of each entry are given below. [1] S [2] The full-path name of the source file. [3] The full-path name of the destination or ~user/file-name. [4] The user's login name. [5] A ``-'' followed by an option list. [6] The name of the _d_a_t_a _f_i_l_e in the spool directory. [7] The file mode bits of the source file in octal print format (e.g. 0666). [8] The user to notify on the remote system that the transfer has completed. _T_y_p_e _4 _a_n_d _T_y_p_e _5 _U_u_c_p generates a _u_u_c_p command and sends it to the remote machine; the remote _u_u_c_i_c_o executes the _u_u_c_p command. _3. _U_u_x - _U_N_I_X _T_o _U_N_I_X _E_x_e_c_u_t_i_o_n The _u_u_x command is used to set up the execution of a UNIX command where the execution machine and/or some of the files are remote. The syntax of the uux command is _u_u_x [ - ] [ option ] ... command-string where the command-string is made up of one or more September 2, 1987 - 6 - arguments. All special shell characters such as ``<>|*?!'' must be quoted either by quoting the entire command-string or quoting the character as a separate argument. Within the command-string, the command and file names may contain a _s_y_s_t_e_m-_n_a_m_e! prefix. All arguments which do not contain a ``!'' will not be treated as files. (They will not be copied to the execution machine.) The ``-'' is used to indi- cate that the standard input for _c_o_m_m_a_n_d-_s_t_r_i_n_g should be inherited from the standard input of the _u_u_x command. The options, essentially for debugging, are: -r Don't start _u_u_c_i_c_o or _u_u_x_q_t after queuing the job; -x_n_u_m Num is the level of debugging output desired. The command pr abc | uux - usg!lpr will set up the output of ``pr abc'' as standard input to an lpr command to be executed on system ``usg''. _U_u_x generates an _e_x_e_c_u_t_e _f_i_l_e which contains the names of the files required for execution (including standard input), the user's login name, the destination of the standard out- put, and the command to be executed. This file is either put in the appropriate spool directory for local execution or sent to the remote system using a generated send command (type 3 above). For required files which are not on the execution machine, _u_u_x will generate receive command files (type 2 above). These command-files will be put on the execution machine and executed by the _u_u_c_i_c_o program. (This will work only if the local system has permission to put files in the remote spool directory as controlled by the remote ``USERFILE''.) The _e_x_e_c_u_t_e _f_i_l_e will be processed by the _u_u_x_q_t program on the execution machine. It is made up of several lines, each of which contains an identification character and one or more arguments. The order of the lines in the file is not relevant and some of the lines may not be present. Each line is described below. _U_s_e_r _L_i_n_e U user system where the _u_s_e_r and _s_y_s_t_e_m are the requester's login name and system. September 2, 1987 - 7 - _R_e_q_u_i_r_e_d _F_i_l_e _L_i_n_e F file-name real-name where the _f_i_l_e-_n_a_m_e is the generated name of a file for the execute machine and _r_e_a_l-_n_a_m_e is the last part of the actual file name (contains no path information). Zero or more of these lines may be present in the _e_x_e_- _c_u_t_e _f_i_l_e. The _u_u_x_q_t program will check for the existence of all required files before the command is executed. _S_t_a_n_d_a_r_d _I_n_p_u_t _L_i_n_e I file-name The standard input is either specified by a ``<'' in the command-string or inherited from the standard input of the _u_u_x command if the ``-'' option is used. If a standard input is not specified, ``/dev/null'' is used. _S_t_a_n_d_a_r_d _O_u_t_p_u_t _L_i_n_e O file-name system-name The standard output is specified by a ``>'' within the command-string. If a standard output is not specified, ``/dev/null'' is used. (Note - the use of ``>>'' is not implemented.) _C_o_m_m_a_n_d _L_i_n_e C command [ arguments ] ... The arguments are those specified in the command- string. The standard input and standard output will not appear on this line. All _r_e_q_u_i_r_e_d _f_i_l_e_s will be moved to the execution directory (a subdirectory of the spool directory) and the UNIX command is executed using the Shell specified in the _u_u_c_p._h header file. In addition, a shell ``PATH'' statement is prepended to the command line. After execution, the temporary standard output file is copied to or set up to be sent to the proper place. _4. _U_u_s_n_a_p - _U_u_c_p _Q_u_e_u_e _S_n_a_p_s_h_o_t This program displays a synopsis of the current _u_u_c_p situa- tion. For each site that has work queued or that had an abnormal termination on the last connection, a line summar- izing the work to be done is output. The line will indicate how many commands there are to be sent, how many data files have been received and not processed, and how many jobs September 2, 1987 - 8 - received from the site there are to be executed. A status message describing the last connection will be included if the connection terminated abnormally. _5. _U_u_c_i_c_o - _C_o_p_y _I_n, _C_o_p_y _O_u_t The _u_u_c_i_c_o program will perform the following major func- tions: - Scan the spool directory for work. - Place a call to a remote system. - Negotiate a line protocol to be used. - Execute all requests from both systems. - Log work requests and work completions. _U_u_c_i_c_o may be started in several ways; a) by a system daemon, b) by one of the _u_u_c_p, _u_u_x, _u_u_x_q_t or _u_u_p_o_l_l programs, c) directly by the user (this is usually for test- ing), d) by a remote system. (The _u_u_c_i_c_o program should be specified as the ``shell'' field in the ``/etc/passwd'' file for the ``uucp'' logins.) When started by method a, b or c, the program is considered to be in _M_A_S_T_E_R mode. In this mode, a connection will be made to a remote system. If started by a remote system (method d), the program is considered to be in _S_L_A_V_E mode. The _M_A_S_T_E_R mode will operate in one of two ways. If no sys- tem name is specified (-s option not specified) the program will scan the spool directory for systems to call. If a system name is specified, that system will be called, and work will only be done for that system. The _u_u_c_i_c_o program is generally started by another program. There are several options used for execution: -r1 Start the program in _M_A_S_T_E_R mode. This is used when _u_u_c_i_c_o is started by a program or ``cron'' shell. -s_s_y_s Do work only for system _s_y_s. If -_s is speci- fied, a call to the specified system will be made even if there is no work for system _s_y_s in the spool directory. This is useful for September 2, 1987 - 9 - polling systems which do not have the hardware to initiate a connection. The following options are used primarily for debugging: -d_d_i_r Use directory _d_i_r for the top level spool directory. -x_n_u_m _N_u_m is the level of debugging output desired. The next part of this section will describe the major steps within the _u_u_c_i_c_o program. _S_c_a_n _F_o_r _W_o_r_k The names of the work related files in a spool subdirectory have format type . system-name grade number where: _T_y_p_e is an upper case letter, ( _C - copy command file, _D - data file, _X - execute file); _S_y_s_t_e_m-_n_a_m_e is the remote system; _G_r_a_d_e is a character; _N_u_m_b_e_r is a four digit, padded sequence number. The file C.res45n0031 would be a _w_o_r_k _f_i_l_e for a file transfer between the local machine and the ``res45'' machine. The scan for work is done by looking through the appropriate spool directory for _w_o_r_k _f_i_l_e_s (files with prefix ``C.''). A list is made of all systems to be called. _U_u_c_i_c_o will then call each system and process all _w_o_r_k _f_i_l_e_s. _C_a_l_l _R_e_m_o_t_e _S_y_s_t_e_m The call is made using information from several files which reside in the uucp system directory (usually /usr/lib/uucp). At the start of the call process, a lock is set to forbid multiple conversations between the same two systems. The system name is found in the ``L.sys'' file. The precise format of the ``L.sys'' file is described in section 10, ``System File Details''. The information contained for each system is; September 2, 1987 - 10 - [1] system name, [2] times to call the system (days-of-week and times- of-day), [3] device or device type to be used for call, [4] line speed, [5] phone number if field [3] is _A_C_U or the device name (same as field [3]) if not _A_C_U, [6] login information (multiple fields), The time field is checked against the present time to see if the call should be made. The _p_h_o_n_e _n_u_m_b_e_r may contain abbreviations (e.g. mh, py, boston) which get translated into dial sequences using the _L-_d_i_a_l_c_o_d_e_s file. The _L-_d_e_v_i_c_e_s file is scanned using fields [3] and [4] from the ``L.sys'' file to find an available device for the call. The program will try all devices which satisfy [3] and [4] until the call is made or no more devices can be tried. If a device is successfully opened, a lock file is created so that another copy of _u_u_c_i_c_o will not try to use it. If the call is complete, the _l_o_g_i_n _i_n_f_o_r_m_a_t_i_o_n (field [6] of ``L.sys'') is used to login. The conversation between the two _u_u_c_i_c_o programs begins with a handshake started by the called, _S_L_A_V_E, system. The _S_L_A_V_E sends a message to let the _M_A_S_T_E_R know it is ready to receive the system identification and conversation sequence number. The response from the _M_A_S_T_E_R is verified by the _S_L_A_V_E and if acceptable, protocol selection begins. The _S_L_A_V_E can also reply with a ``call-back required'' message in which case, the current conversation is terminated. _L_i_n_e _P_r_o_t_o_c_o_l _S_e_l_e_c_t_i_o_n The remote system sends a message P_p_r_o_t_o-_l_i_s_t where proto-list is a string of characters, each represent- ing a line protocol. The calling program checks the proto-list for a letter corresponding to an available line protocol and returns a _u_s_e-_p_r_o_t_o_c_o_l message. The _u_s_e-_p_r_o_t_o_c_o_l message is U_c_o_d_e September 2, 1987 - 11 - where code is either a one character protocol letter or _N which means there is no common protocol. _W_o_r_k _P_r_o_c_e_s_s_i_n_g The initial roles ( _M_A_S_T_E_R or _S_L_A_V_E ) for the work process- ing are the mode in which each program starts. (The _M_A_S_T_E_R has been specified by the ``-r1'' _u_u_c_i_c_o option.) The _M_A_S_T_E_R program does a work search similar to the one used in the ``Scan For Work'' section. There are five messages used during the work processing, each specified by the first character of the message. They are; S send a file, R receive a file, C copy complete, X execute a _u_u_c_p command, and H hangup. The _M_A_S_T_E_R will send _R, _S or _X messages until all work from the spool directory is complete, at which point an _H message will be sent. The _S_L_A_V_E will reply with _S_Y, _S_N, _R_Y, _R_N, _H_Y, _H_N, _X_Y, _X_N, corresponding to _y_e_s or _n_o for each request. The send and receive replies are based on permission to access the requested file/directory using the ``USERFILE'' and read/write permissions of the file/directory. After each file is copied into the spool directory of the receiv- ing system, a copy-complete message is sent by the receiver of the file. The message _C_Y will be sent if the file has successfully been moved from the temporary spool file to the actual destination. Otherwise, a _C_N message is sent. (In the case of _C_N, the transferred file will be in a spool sub- directory with a name beginning with ``TM'.) The requests and results are logged on both systems. The hangup response is determined by the _S_L_A_V_E program by a work scan of its spool directory. If work for the _M_A_S_T_E_R's system exists in the _S_L_A_V_E's spool directory, an _H_N message is sent and the programs switch roles. If no work exists, an _H_Y response is sent. _C_o_n_v_e_r_s_a_t_i_o_n _T_e_r_m_i_n_a_t_i_o_n When a _H_Y message is received by the _M_A_S_T_E_R it is echoed back to the _S_L_A_V_E and the protocols are turned off. Each September 2, 1987 - 12 - program sends a final ``OO'' message to the other. The ori- ginal _S_L_A_V_E program will clean up and terminate. The _M_A_S_T_E_R will proceed to call other systems and process work as long as possible or terminate if a -_s option was specified. _6. _U_u_x_q_t - _U_u_c_p _C_o_m_m_a_n_d _E_x_e_c_u_t_i_o_n The _u_u_x_q_t program is used to execute _e_x_e_c_u_t_e _f_i_l_e_s generated by _u_u_x. The _u_u_x_q_t program may be started by either the _u_u_c_i_c_o or _u_u_x programs. The program scans the appropriate spool directory for _e_x_e_c_u_t_e _f_i_l_e_s (prefix ``X.''). Each one is checked to see if all the required files are available and if so, the command line or send line is executed. The _e_x_e_c_u_t_e _f_i_l_e is described in the ``Uux'' section above. _C_o_m_m_a_n_d _E_x_e_c_u_t_i_o_n The execution is accomplished by executing a _s_h -_c of the command line after appropriate standard input and standard output have been opened. If a standard output is specified, the program will create a send command or copy the output file as appropriate. _7. _U_u_c_l_e_a_n - _U_u_c_p _S_p_o_o_l _D_i_r_e_c_t_o_r_y _C_l_e_a_n_u_p This program is typically started by the daemon, once a day. Its function is to remove files from the spool directories which are more than 3 days old. These are usually files for work which can not be completed. The options available are: -d_d_i_r The directory to be scanned is _d_i_r. -m Send mail to the owner of each file being removed. (Note that most files put into the spool directory will be owned by the owner of the uucp programs since the setuid bit will be set on these programs. The mail will therefore most often go to the owner of the uucp programs.) -n_h_o_u_r_s Change the aging time from 72 hours to _h_o_u_r_s hours. -p_p_r_e Examine files with prefix _p_r_e for deletion. (Up to 10 file prefixes may be specified.) -x_n_u_m This is the level of debugging output desired. September 2, 1987 - 13 - _8. _C_h_a_n_g_e_s _t_o _t_h_e _U_U_C_P _I_m_p_l_e_m_e_n_t_a_t_i_o_n The demands placed on UUCP networking and new technol- ogy have prompted several changes and improvements to the UUCP software. Such things as low cost, autodial, autoanswer, high speed modems, and the availability of X.25 and TCP/IP as carriers, have encouraged new facilities to be developed for UUCP. The following areas have been changed between the 4.2 and 4.3 BSD releases: o+ General fixes and performance improvements. o+ Administration control facilities. o+ Modem and autodialer support has been extended. o+ New protocols for different transport media. o+ Security enhancements. _F_i_x_e_s _a_n_d _p_e_r_f_o_r_m_a_n_c_e _i_m_p_r_o_v_e_m_e_n_t_s. These include many fixes related to portability and general improvements as provided by the USENET community. In particular, the _s_i_t_e_n_a_m_e truncation length has been extended to 14 characters from the original 7. This makes it compatible with the current System V version of UUCP. An effort has been made to improve the overall perfor- mance of the UUCP system by organizing its workload in a more sensible way. For example the program _u_u_c_i_c_o will not resend files it has already sent when the files are speci- fied in one ``C.'' file. _A_d_m_i_n_i_s_t_r_a_t_i_o_n _a_n_d _c_o_n_t_r_o_l _f_a_c_i_l_i_t_i_e_s. There is a new program, _u_u_q, to give more descriptive information on status of jobs in the UUCP spool queue. It also allows users to delete requests that are still in the queue. In the past, on large UUCP sites, the spool directory could grow large with many files within the ``/usr/spool/uucp'' directory. To help the UUCP administra- tor control the system, a number of subdirectories have been created to ease this congestion. The system status ``STST'' files are kept in a sub- directory. Corrupted ``C.'' and ``X.'' files that could not be processed are placed in the ``CORRUPT'' subdirectory, September 2, 1987 - 14 - instead of terminating the connection. Lock files may be kept in a subdirectory, ``LCK'', if desired. If an ``X.'' request fails, the notification is returned to the originator of the request, not to ``uucp'' on the previous system. There is a new _s_y_s_t_e_m file, ``L.aliases'', that may be used when a site changes its name. Most of the utilities check ``L.aliases'' for correct mapping. _M_o_d_e_m _a_n_d _a_u_t_o_d_i_a_l_e_r _s_u_p_p_o_r_t In a short period of time, there has been an increase in the transfer rates and capabilities that are being pro- vided with modern modems. Most modems allow several combi- nations of baud rate, and provide autodial and autoanswer facilities as well. Most sites will have but a few modems; they are there- fore a precious resource, and an effort has been made to use them to maximum potential. The _u_u_c_i_c_o program now has code to place and receive calls on the same device, if that modem has both autodial and autoanswer support. There is a new dialing facility _a_c_u_c_n_t_r_l that has been designed to handle some of the changes in modem technology. There are a number of new modems and autodialers that are now supported. Here is a list of some of the new devices: Racal-Vadic 212 Racal-Vadic 811 dialer with 831 adapter Racal-Vadic 820 dialer with 831 adapter Racal-Vadic MACS 811 dialer with 831 adapter Racal-Vadic MACS 820 dialer with 831 adapter DEC DF112 Novation Penril Hayes 2400 Smartmodem Concord Data Systems CDS 224 AT&T 2224 2400 baud modem _N_e_w _p_r_o_t_o_c_o_l_s _f_o_r _d_i_f_f_e_r_e_n_t _t_r_a_n_s_p_o_r_t_a_t_i_o_n _m_e_d_i_u_m_s The UUCP software has had provision for different pro- tocols to be used for sending and receiving data, but origi- nally only one was implemented and this is the one that is largely used throughout the UUCP community. It has a max- imum throughput of around 9000 baud, regardless of the phy- sical medium. The use of checksums and short data packets are of little use when the protocol is layered above another reliable protocol such as TCP or X.25. The UUCP system did not utilize LAN's and high speed carriers well. Two new September 2, 1987 - 15 - protocols have been added to provide for this. The proto- cols now available to UUCP are: `t' protocol, optimized for use on TCP/IP carriers. `f' protocol, optimized for use on X.25 PAD carriers. `g' protocol, standard UUCP protocol used for dialup or hardwired lines. The existing `g' protocol code has been cleaned up in this version. The `t' protocol is essentially the `g' pro- tocol except that the channel is assumed to be free from errors. As such, no checksums are used and files are transferred without packetizing. The `f' protocol relies on the flow control of the data stream. It is meant for use over links that can be guaranteed to be free from errors, specifically X.25/PAD links. The checksum is calculated over whole files only. If a transport fails the receiver can request retransmissions. This protocol uses a 7-bit data path only, so it may be used on carriers that do not handle 8-bit data paths transparently. _C_h_a_n_g_e_s _t_o _u_u_c_i_c_o _U_u_c_i_c_o used to attempt to place a call using every dialer on the system. Since this could take a long time at large sites, the defined constant TRYCALLS now limits the number of attempts. You can specify a maximum grade to send either on the command line using -gX option or by specifying the time to call in the ``L.sys'' file as follows: Any/C,Evening This will only send grade C or higher transfers, usually mail, during the day and will send any grades in the even- ing. The code for the closing hangup sequence has been fixed. Some new options were added to _u_u_c_i_c_o. These include: -R This flag reverses _u_u_c_i_c_o's initial role (lets the remote system be master first rather than slave). -L _u_u_c_i_c_o will only call ``local'' sites. Local sites are those sites having one of LOCAL, TCP or DIR in the CALLER field of ``L.sys''. If ``/etc/nologin'' is present, usually created by _s_h_u_t_d_o_w_n(8), _u_u_c_i_c_o and _u_u_x_q_t will exit gracefully, instead of getting killed off when the system goes down. September 2, 1987 - 16 - _U_u_c_i_c_o now uses an exponential back off on the retry time if consecutive calls fail instead of always waiting 5 minutes. The default may be overridden by adding ";_t_i_m_e" to the time field in ``L.sys''. ucbvax Any;2 The preceding fragment indicates that a default retry time of 2 minutes will be used. If _u_u_c_i_c_o receives a SIGFPE while running, it will tog- gle debugging. It will not send files to a remote system returning an out of temporary file space error. More functionality has been added to the expect/send sequences. The ABORT command was added to the expect/send sequence so it does not have to wait for timeout if cannot get through a port selector. You can specify a time for the expect/send sequences with ~ to override the default timeout. The expect/send sequences now allow escape sequences to specify characters that could not be specified before. The time field in the ``L.sys'' file now handles ``Evening'', ``Night'', and ``NonPeak'' in addition to Any, Mo, Tu, We, Th, Fr, Sa, Su, and Wk. The file _L-_d_e_v_i_c_e_s now handles ``chat'' scripts, to help get through local port selectors and smart modems. This helps keep ``L.sys'' readable while using the increased functionality. For compatibility with the System V UUCP, the following changes were made in the date fields of ``L.sys'': `|' changed to `,' (`|' is supported, but not encouraged) `,' changed to `;' (to allow `,' to be the date separator) For Honey DanBer compatibility, _u_u_c_i_c_o now passes the maximum grade to the remote system as ``-vgrade=X'' instead of the old -pX Support has been added for GTE's PC Pursuit service. It is mainly the handling of the call back method they use. Users must now have read access to ``L.sys'' in order to run _u_u_c_i_c_o with debugging turned on. September 2, 1987 - 17 - _9. _T_h_e _U_U_C_P _s_y_s_t_e_m. _N_a_m_e_s The name of a site is important since it provides a means of identifying a machine, and consequently, that machine's users. There are two kinds of names used within the UUCP system; _l_o_g_i_n_n_a_m_es and _s_i_t_e_n_a_m_es. It is important that the _l_o_g_i_n_n_a_m_es used by a remote machine to call into a local machine is not the same as that of a normal user of the local machine. Each _l_o_g_i_n_n_a_m_e corresponds with a line in ``/etc/passwd''. It is the administrator's decision whether each remote site should use the same login name or different ones. Each machine in a UUCP network is given a unique _s_i_t_e_n_a_m_e. The _s_i_t_e_n_a_m_e identifies the calling machine to the called machine. A _s_i_t_e_n_a_m_e can be up to 14 characters in length. It is useful to have a _s_i_t_e_n_a_m_e that is unique in the first 7 characters, to be compatible with earlier implementations of UUCP. It is desirable that the _s_i_t_e_n_a_m_e will convey this uniqueness and perhaps a real world iden- tity to the rest of the network. _T_h_e _U_U_C_P _s_y_s_t_e_m _o_r_g_a_n_i_z_a_t_i_o_n. There are several directories that are used by the UUCP system as distributed. These are: src (/usr/src/usr.bin/uucp) This directory con- tains the source files for the UUCP system. system (/usr/lib/uucp) This directory contains the system binaries and system control files. spool (/usr/spool/uucp) This spool directory is used to store transfer requests and data. command (/usr/bin) This directory contains the user- level programs. _T_h_e _s_y_s_t_e_m _d_i_r_e_c_t_o_r_y The following files are required for execution, and should reside in the _s_y_s_t_e_m directory, /usr/lib/uucp. L-devices Contains entries for all devices that are to be used by UUCP. L-dialcodes Contains dialing abbreviations. L.aliases Contains site name aliases. September 2, 1987 - 18 - L.cmds Contains the list of commands that can be used by a remote site. L.sys Contains site connection information for each system that can be called. SEQF The sequence numbering and check file. USERFILE Remote system access rights. acucntrl The program used to control calling remote systems. uucico The actual transfer program. uuclean A utility to clean up after UUCP. uuxqt Executes commands received from remote systems. _T_h_e _c_o_m_m_a_n_d _d_i_r_e_c_t_o_r_y The _c_o_m_m_a_n_d directory, /usr/bin, contains the following user available commands: uucp Spools a UNIX to UNIX file-copy request. uux Spools a request for remote execution. uusend Provides a facility to transfer binary files using mail. uuencode Binary file encoder (for _u_u_s_e_n_d) uudecode Binary file decoder (for _u_u_s_e_n_d) uulog Reports from log files. uusnap Provides a snapshot of _u_u_c_p activity. uupoll Polls a remote system. uuname Prints a list of known remote UUCP hosts. uuq Reports information from the UUCP spool queue. _T_h_e _s_p_o_o_l _d_i_r_e_c_t_o_r_y The _s_p_o_o_l directory, /usr/spool/uucp, contains the fol- lowing files and directories: C. A directory for command (``C.'') files. September 2, 1987 - 19 - D. A directory for data (``D.'') files. X. A directory for command execution (``X.'') files. D._m_a_c_h_i_n_e A directory for local ``D.'' files. D._m_a_c_h_i_n_eX A directory for local ``X.'' files. CORRUPT A directory for corrupted ``C.'' and ``X.'' files. ERRLOG A file where internal error messages are collected. LCK A directory for device and site lock files (optional). LOG A directory for individual site LOGFILE's (optional). LOGFILE The log file of UUCP activity (optional). STST A directory for per site system status files (``STST''). SYSLOG The log file of UUCP file transfers. TM. A directory for temporary (``TM.'') files. This version has broken the spool directory into the above list of directories leaving only a few system files in the top level directory. The logs from each system may be kept together or in separate files in a subdirectory (LOG). This decision is made when the system is compiled. There is an additional directory, /usr/spool/uucppublic, that is used as a general public access directory for UUCP. It is not used by UUCP directly but it is normally the home directory for the UUCP system owner. Most importantly this directory is owned by uucp, and the access permissions are 0777. This usually guaran- tees a place that files can be copied to, and retrieved from, on any site. _1_0. _S_y_s_t_e_m _f_i_l_e _d_e_t_a_i_l_s. The _s_y_s_t_e_m files in the ``/usr/lib/uucp'' directory can contain comments, by putting a `#' as the first character on a line. Lines may be continued by placing a `\' as the last character of a line. This is helpful in making the files more readable. September 2, 1987 - 20 - _L-_d_e_v_i_c_e_s This file contains entries for the call-unit devices and hardwired connections which are to be used by UUCP. The special device files are assumed to be in the /dev direc- tory. The format for each entry is: _T_y_p_e _D_e_v_i_c_e _U_s_e_f_u_l _C_l_a_s_s _D_i_a_l_e_r [_C_h_a_t ...] where; _T_y_p_e Is the type of connection to use. ACU Indicates that a dialing device is used. LOCAL Indicates an ACU with a ``preferred'' connection. DIR Indicates that a direct connection is used. DK Indicates that an AT&T Datakit is used. MICOM Indicates that a Micom terminal switch is used. PAD Indicates that a X.25 PAD connection is used. PCP Indicates that GTE Telenet PC Pursuit is used. SYTEK Indicates that a Sytek high-speed dedicated modem port is used. TCP Indicates that a TCP/IP connection is used. _D_e_v_i_c_e Is the entry in ``/dev'' corresponding to a real device. UUCP should be able to access this dev- ice. _C_a_l_l__U_n_i_t Is the device for dialing if different from the device used for the data transfer. This field must contain a place holder if unused (such as ``unused''). _C_l_a_s_s is the line baud rate for dialers and direct lines September 2, 1987 - 21 - or the port number for network connections. _D_i_a_l_e_r is either direct, or from the list of available dialers. The list of available dialers includes: DF02 DEC DF02 or DF03 modems. DF112 DEC DF112 modems. Use a _D_i_a_l_e_r field of DF112T to use tone dialing, or DF112P for pulse dialing. att AT&T 2224 2400 baud modem. cds224 Concord Data Systems 224 2400 baud modem. dn11 DEC DN11 UNIBUS dialer. hayes Hayes Smartmodem 1200 and compatible autodialing modems. Use a _D_i_a_l_e_r field of hayestone to use tone dial- ing, or hayespulse for pulse dialing. It is also permissible to include the letters `T' and `P' in the phone number (in ``L.sys'') to change to tone or pulse midway through dialing. (Note that a leading `T' or `P' will be interpreted as a dialcode!) hayes2400 Hayes Smartmodem 2400 and compatible modems. Use a _D_i_a_l_e_r field of hayes2400tone to use tone dialing, or hayes2400pulse for pulse dialing. novation Novation ``Smart Cat'' autodialing modem. penril Penril Corp ``Hayes compatible'' modems. rvmacs Racal-Vadic 820 dialer with 831 adapter in a MACS configuration. va212 Racal-Vadic 212 autodialing modem. va811s Racal-Vadic 811s dialer with 831 adapter. va820 Racal-Vadic 820 dialer with 831 adapter. vadic Racal-Vadic 3450 and 3451 series auto- dialing modems. September 2, 1987 - 22 - ventel Ventel 212+ autodialing modem. vmacs Racal-Vadic 811 dialer with 831 adapter in a MACS configuration. _C_h_a_t is a send/expect sequence that can be used to talk through dataswitches, or issue special commands to a device such as a modem. The syntax is identical to that of the Expect/Send script of ``L.sys'' and will be described later. The difference is that, the _L-_d_e_v_i_c_e_s script is used before the connection is made, while the ``L.sys'' script is used after. _L-_d_i_a_l_c_o_d_e_s This file contains entries with location abbreviations used in the ``L.sys'' file (e.g. py, mh, boston). The entry format is: abb dial-seq where; abb is the abbreviation, dial-seq is the dial sequence to call that location. The line py 165- would be set up so that entry py7777 in ``L.sys'' would send 165-7777 to the dial-unit. _L._a_l_i_a_s_e_s. The _L._a_l_i_a_s_e_s file provides a mapping facility for _s_i_t_e_n_a_m_es. This facility is useful when a _s_i_t_e_n_a_m_e is changed temporarily, or until a permanent change becomes widely known by the users of the net. The format of the file is: real_name alias_name The ``L.aliases'' file may be used to map hosts with longer names in ``L.sys'' to 7 character names that some hosts send. This provides a mechanism to handle those sites, entries should be: fullname 7-char-name September 2, 1987 - 23 - _L._c_m_d_s The L.cmds file contains a list of commands that are permitted for remote execution with _u_u_x. The commands are listed one per line. Most sites L.cmds will be something like: rmail rnews ruusend A line of the form: PATH=/bin:/usr/bin:/usr/ucb:/usr/local/bin can be used to set a search path. _L._s_y_s Each entry in this file represents one system that com- municates with the local system and has the form: _S_i_t_e_n_a_m_e _T_i_m_e_s _C_a_l_l_e_r _C_l_a_s_s _D_e_v_i_c_e [_E_x_p_e_c_t _S_e_n_d].... _S_i_t_e_n_a_m_e is the name of the remote system. Every machine with which this system communicates via UUCP should be listed, regardless of who calls whom. Systems not listed in ``L.sys'' will not be per- mitted a connection. _T_i_m_e_s is a comma-separated list of the times of the day and week that calls are permitted to this site. This can be used to restrict long distance tele- phone calls to those times when rates are lower. List items are constructed as: _k_e_y_w_o_r_dhhmm-hhmm/_g_r_a_d_e;_r_e_t_r_y__t_i_m_e _K_e_y_w_o_r_d is required, and must be one of: Any Any time, any day of the week. Wk Any weekday. In addition, Mo, Tu, We, Th, Fr, Sa, and Su can be used. Evening When evening telephone rates are in effect, from 1700 to 0800 Monday through Friday, and all day Saturday and Sunday. _E_v_e_n_i_n_g is the same as _W_k_1_7_0_0- _0_8_0_0,_S_a,_S_u. Night When nighttime telephone rates are in September 2, 1987 - 24 - effect, from 2300 to 0800 Monday through Friday, all day Saturday, and from 2300 to 1700 Sunday. _N_i_g_h_t is the same as _A_n_y_2_3_0_0-_0_8_0_0,_S_a,_S_u_0_8_0_0-_1_7_0_0. NonPeak This is a slight modification of _E_v_e_n_- _i_n_g. It matches when the USA X.25 car- riers have their lower rate period. This is 1800 to 0700 Monday through Friday, and all day Saturday and Sunday. _N_o_n_- _P_e_a_k is the same as _A_n_y_1_8_0_0-_0_7_0_0,_S_a,_S_u. Never Calling this site is forbidden or impos- sible. This is intended for polled con- nections, where the remote system calls into the local machine periodically. The optional _h_h_m_m-_h_h_m_m subfield provides a time range that modifies the keyword. _h_h_m_m refers to _h_o_u_r_s and _m_i_n_u_t_e_s in 24-hour time (from 0000 to 2359). The time range is permitted to "wrap" around midnight, and will behave in the obvious way. It is invalid to follow the Evening, Non- Peak, and Night keywords with a time range. The _g_r_a_d_e subfield is optional; if present, it is composed of a `/' (slash) and single charac- ter denoting the _g_r_a_d_e of the connection. Grades are in the range [0-9A-Za-z]. This specifies that only requests of grade _g_r_a_d_e or better will be transferred during this time. (The grade of a request or job is specified when it is queued by _u_u_c_p or _u_u_x). By convention, mail is sent at grade C, news is sent at grade d, and uucp copies are sent at grade n. Unfortunately, some sites do not follow these conventions consistently. The _r_e_t_r_y__t_i_m_e subfield is optional; it must be preceded by a `;' (semicolon) and specifies the minimum time, in minutes, before a failed connec- tion will be tried again. By default, the retry time starts at 10 minutes and gradually increases at each failure, until after 26 tries _u_u_c_i_c_o gives up completely (MAX RETRIES). If the retry time is too small, _u_u_c_i_c_o may run into MAX RETRIES too soon. _C_a_l_l_e_r is the type of device used. It may be one of the following: ACU DIR LOCAL MICOM PAD PCP SYTEK TCP The descriptions are the same as listed in ``L- devices'' above. If several alternate ports or September 2, 1987 - 25 - network connections should be tried, use multiple ``L.sys'' entries. _C_l_a_s_s is usually the speed (baud) of the device, typi- cally 300, 1200, or 2400 for ACU devices and 9600 for direct lines. Valid values are device depen- dent, and are specified in the ``L-devices'' file. On some devices, the speed may be preceded by a non- numeric prefix. This is used in ``L-devices'' to distin- guish among devices that have identical _C_a_l_l_e_r and baud, but yet are distinctly different. For example, 1200 could refer to all Bell 212-compatible modems, V1200 to Racal-Vadic modems, and C1200 to CCITT modems, all at 1200 baud. On TCP connections, _C_l_a_s_s is the port number (an integer) or a port name from ``/etc/services'' that is used to make the connection. For standard Berkeley TCP/IP, UUCP normally uses port number 540. _D_e_v_i_c_e varies based on the _C_a_l_l_e_r field. For ACU dev- ices, this is the phone number to dial. The number may include: digits 0 through 9; # and * for dialing those symbols on tone telephone lines; - (hyphen) to pause for a moment, typically two to four seconds; = (equal sign) to wait for a second dial tone (implemented as a pause on many modems). Other characters are modem dependent; generally standard telephone punctuation characters (such as the slash and parentheses) are ignored, although _u_u_c_i_c_o does not guarantee this. The phone number can be preceded by an alphabetic string; the string is indexed and converted through the ``L-dialcodes'' file. For DIR devices, the _D_e_v_i_c_e field contains the name of the device in /dev that is used to make the connection. There must be a corresponding line in ``L-devices'' with identical _C_a_l_l_e_r, _C_l_a_s_s, and _D_e_v_i_c_e fields. For TCP and other network devices, _D_e_v_i_c_e holds the network name for establishing a connection to the remote system, which may be different from its UUCP name. The _E_x_p_e_c_t and _S_e_n_d refer to an arbitrarily long set of strings that alternately specify what to _e_x_p_e_c_t and what to _s_e_n_d to login to the remote system once a physical connec- tion has been established. A complete set of expect/send strings is referred to as an ``_e_x_p_e_c_t/_s_e_n_d _s_c_r_i_p_t''. The same syntax is used in the _L-_d_e_v_i_c_e_s file to interact with the dialer prior to making a connection; there it is referred to as a _c_h_a_t _s_c_r_i_p_t. The complete format for one _e_x_p_e_c_t/_s_e_n_d pair is: September 2, 1987 - 26 - _e_x_p_e_c_t~_t_i_m_e_o_u_t-_f_a_i_l_s_e_n_d-_e_x_p_e_c_t~_t_i_m_e_o_u_t _s_e_n_d _E_x_p_e_c_t, _f_a_i_l_s_e_n_d, and _s_e_n_d are character strings. _E_x_p_e_c_t is compared against incoming text from the remote host; _s_e_n_d is sent back when _e_x_p_e_c_t is matched. By default, the _s_e_n_d is followed by a `\r' (carriage return). If the _e_x_p_e_c_t string is not matched within _t_i_m_e_o_u_t seconds (default 45), then it is assumed that the match failed. The `_e_x_p_e_c_t-_f_a_i_l_s_e_n_d-_e_x_p_e_c_t' notation provides a limited loop mechanism; if the first _e_x_p_e_c_t string fails to match, then the _f_a_i_l_s_e_n_d string between the hyphens is transmitted, and _u_u_c_i_c_o waits for the second _e_x_p_e_c_t string. This can be repeated indefinitely. When the last _e_x_p_e_c_t string fails, _u_u_c_i_c_o hangs up and logs that the connection failed. The timeout can (optionally) be specified by appending the parameter `~_n_n' to the expect string, when _n_n is the timeout time in seconds. Backslash escapes that may be embedded in the _e_x_p_e_c_t or _s_e_n_d strings include: \b Generate a 3/10 second BREAK. \b_n Where _n is a single-digit number; generate an _n/10 second BREAK. \c Suppress the \r at the end of a _s_e_n_d string. \d Delay; pause for 1 second. (_S_e_n_d only.) \r Carriage Return. \s Space. \n Newline. \xxx Where _x_x_x is an octal constant; denotes the corresponding ASCII character. As a special case, an empty pair of double-quotes "" in the _e_x_p_e_c_t string is interpreted as ``expect nothing''; that is, transmit the _s_e_n_d string regardless of what is received. Empty double-quotes in the _s_e_n_d string cause a lone `\r' (carriage return) to be sent. One of the following keywords may be substituted for the _s_e_n_d string: BREAK Generate a 3/10 second BREAK BREAK_n Generate an _n/10 second BREAK CR Send a Carriage Return (same as ""). EOT Send an End-Of-Transmission character, ASCII \004. Note that this will cause most hosts to hang up. NL Send a Newline. PAUSE Pause for 3 seconds. September 2, 1987 - 27 - PAUSE_n Pause for _n seconds. P_ODD Use odd parity on future send strings. P_ONE Use parity one on future send strings. P_EVEN Use even parity on future send strings. (Default) P_ZERO Use parity zero on future send strings. Finally, if the _e_x_p_e_c_t string consists of the keyword ABORT, the following string is used to arm an abort trap. If that string is subsequently received any time prior to the completion of the entire _e_x_p_e_c_t/_s_e_n_d script, then _u_u_c_i_c_o will abort, just as if the script had timed out. This is useful for trapping error messages from port selectors or front-end processors such as ``Host Unavailable'' or ``Sys- tem is Down.'' An example expect/send sequence might look something like this: "" \d\r CLASS HOST ABORT Down GO \d\r ogin:~30-\b-ogin: uucp word: password First, _u_u_c_i_c_o will expect nothing, wait 1 second (\d), and then send a carriage return. The next expected message is ``CLASS'', in response to which _u_u_c_i_c_o sends ``HOST''. From then on, if it sees the word ``Down'' before finishing log- ging in, it will hang up immediately. In the mean time, it looks for ``GO''. After this is received, it delays 1 second and then sends a CR. _U_u_c_i_c_o resets the timeout to 30 seconds while whating to receive ``ogin:''. If there is no response, a break will be sent and the program will wait for 45 seconds for ``ogin:'' again. When this is received, ``uucp'' will be sent. The sequence ends by waiting for ``word:'' and responding with ``password''. At this point, UUCP has completed the login and continues with the protocol for establishing the connection.. _U_S_E_R_F_I_L_E This file contains user accessibility information. It specifies the file system directory trees that are accessi- ble to local users and to remote systems via UUCP Each line in ``USERFILE'' is of the form: [_l_o_g_i_n_n_a_m_e],[_s_i_t_e_n_a_m_e] [ c ] _p_a_t_h_n_a_m_e [_p_a_t_h_n_a_m_e] [_p_a_t_h_n_a_m_e] The first two items are separated by a comma; any number of spaces or tabs may separate the remaining items. The _l_o_g_i_n_n_a_m_e is a user name (from ``/etc/passwd'') on the local machine. The _s_i_t_e_n_a_m_e is the name of a remote machine. This is September 2, 1987 - 28 - the same name used in ``L.sys''. The _c denotes the optional _c_a_l_l_b_a_c_k field. If a c appears here, a remote machine that calls in will be told that callback is requested, and the conversation will be terminated. The local system will then immediately call the remote host back. The _p_a_t_h_n_a_m_e is a pathname prefix that is permissible for this _l_o_g_i_n_n_a_m_e and/or _s_i_t_e_n_a_m_e. When _u_u_c_i_c_o runs in master role or _u_u_c_p or _u_u_x are run by local users, the permitted pathnames are those on the first line with a _l_o_g_i_n_n_a_m_e that matches the name of the user who executed the command. If no such line exists, then the first line with a null (missing) _l_o_g_i_n_n_a_m_e field is used. (Beware: _u_u_c_i_c_o is often run by the superuser or the UUCP administrator through _c_r_o_n. When _u_u_c_i_c_o runs in slave role, the permitted pathnames are those on the first line with a _s_i_t_e_n_a_m_e field that matches the hostname of the remote machine. If no such line exists, then the first line with a null (missing) _s_i_t_e_n_a_m_e field is used. _U_u_x_q_t works differently; it knows neither a login name nor a hostname. It accepts the pathnames on the first line that has a null _s_i_t_e_n_a_m_e field. (This is the same line that is used by _u_u_c_i_c_o when it cannot match the remote machine's hostname.) A line with both _l_o_g_i_n_n_a_m_e and _s_i_t_e_n_a_m_e null, for exam- ple , /usr/spool/uucppublic can be used to conveniently specify the paths for both ``no match'' cases if lines earlier in ``USERFILE'' did not define them. _1_1. _I_n_s_t_a_l_l_i_n_g _t_h_e _U_U_C_P _s_y_s_t_e_m. There are several source modifications that may be required before the system programs are compiled. Two files which may require modification, the ``Makefile'' file and the ``uucp.h'' file. The following paragraphs describe some of the options available at build time. _U_u_c_p._h _m_o_d_i_f_i_c_a_t_i_o_n_s The installer of UUCP may wish to change some of the defines in ``uucp.h''. Some of the interesting defines are September 2, 1987 - 29 - mentioned below. if DIALINOUT is defined then _a_c_u_c_n_t_r_l will allow modems to be used in both directions. If DONTCOPY is defined in ``uucp.h'', _u_u_c_p will not make a copy of the source file by default. if LOCKDIR is defined then lock files will be stored in the ``/usr/spool/uucp/LCK'' directory. If LOGBYSITE is defined, _u_u_c_p logging is done with a log file per site, instead of one LOGFILE. If NOSTRANGERS is defined in ``uucp.h'', the remote site must be in your ``L.sys'' or the call will be rejected. _M_a_k_e_f_i_l_e _m_o_d_i_f_i_c_a_t_i_o_n There are several _m_a_k_e variable definitions which may need modification. LIBDIR the directory where low level binaries, site information, and dialing informa- tion are stored BIN The directory in which the user utili- ties reside. PUBDIR A directory where files can almost always be sent. This should be UUCP's home directory and writable by everyone. SPOOL The top level spool directory. XQTDIR The directory where temporary files will be stored by _u_u_x_q_t. CORRUPT The directory where corrupted ``C.'' and ``D.'' files end up. AUDIT The directory where debugging traces are stored by _u_u_c_i_c_o when debugging is remotely enabled or enabled by a signal. LCK The directory where lock files are kept. _T_i_p(1) and other programs may need to be modified if this is changed as the lock files are shared. LOG The directory where the log files are placed if ``LOGBYSITE'' is defined in ``uucp.h''. September 2, 1987 - 30 - STST The directory where the remote system status files (``STST'') are stored. HOSTNAME The machine's name. _B_u_i_l_d_i_n_g _t_h_e _s_y_s_t_e_m The command make will compile the entire system. The command make mkdirs will build all the directories needed for the system, giving them appropriate owners and permissions. The command make install will install the commands in the correct directories, setting ownership and permissions. _1_2. _C_o_n_n_e_c_t_i_n_g _n_e_w _s_y_s_t_e_m_s _t_o _t_h_e _n_e_t_w_o_r_k. When first connecting a new machine to a UUCP network, it is advisable to try and establish a connection with _t_i_p or _c_u first. The administrator should then be aware of any special facilities that are going to be required, things like; What lines and modems are to be used? Is the connec- tion through different hardware and carriers? Does the remote system care about parity? What speed lines are being used and do they cycle through several speeds? Is there a line switch front end that will require special Chat dialo- gue in ``L.sys''? Once a _l_o_g_i_n connection can be completed the adminis- trator should have enough information to allow the correct setup of the _s_y_s_t_e_m files in /usr/lib/uucp. The UUCP administrator should then negotiate with the remote site's UUCP administrator as to who will do polling and when. Both administrators must set up the relevant accounts and passwords. The UUCP administrator should decide on what permissions and security precautions are to be observed. Testing time and facilities will need to be arranged to complete initial connection testing between the systems. September 2, 1987 - 31 - _1_3. _S_e_c_u_r_i_t_y The uucp system, left unrestricted, will let any out- side user execute any commands and copy any files that are accessible to the uucp login user. It is up to the indivi- dual sites to be aware of this and apply the protections that they feel are necessary. There are several security features available aside from the normal file mode protections. These must be set up by the installer of the _u_u_c_p system. - The login for uucp does not get a standard shell. Instead, the _u_u_c_i_c_o program is started. Therefore, the only work that can be done is through _u_u_c_i_c_o. - A path check is done on file names that are to be sent or received. The ``USERFILE'' supplies the information for these checks. The ``USERFILE'' can also be set up to require call-back for certain login-ids. (See the description of ``USERFILE'' above.) - A conversation sequence count can be set up so that the called system can be more confident that the caller is who he says he is. - The _u_u_x_q_t program comes with a list of commands that it will execute. A ``PATH'' shell statement is prepended to the command line as specified in the _u_u_x_q_t program. The installer may modify the list or remove the restrictions as desired. - The ``L.sys'' file should be owned by uucp and only read- able by uucp to protect the phone numbers and login information for remote sites. (Programs uucp, uucico, uux, uuxqt should be also owned by uucp and have the set user id bit set.) _1_4. _A_d_m_i_n_i_s_t_r_a_t_i_o_n This section indicates some events and files which must be administered for the _u_u_c_p system. Some administration can be accomplished by _s_h_e_l_l _f_i_l_e_s which can be initiated by _c_r_o_n(8). Others will require manual intervention. _S_Q_F_I_L_E - _s_e_q_u_e_n_c_e _c_h_e_c_k _f_i_l_e This file is set up in the _l_i_b_r_a_r_y directory and con- tains an entry for each remote system with which you agree to perform conversation sequence checks. The initial entry is just the system name of the remote system. The first conversation will add two items to the line, the conversa- tion count, and the date/time of the most resent conversa- tion. These items will be updated with each conversation. September 2, 1987 - 32 - If a sequence check fails, which could indicate that an unauthorized connection has been attempted, the entry will have to be adjusted. _T_M - _t_e_m_p_o_r_a_r_y _d_a_t_a _f_i_l_e_s These files are created in the _s_p_o_o_l directory while files are being copied from a remote machine. Their names have the form TM.pid.ddd where _p_i_d is a process-id and _d_d_d is a sequential three digit number starting at zero for each invocation of _u_u_c_i_c_o and incremented for each file received. After the entire remote file is received, the _T_M file is moved to the requested destination. If processing is abnormally ter- minated or the move fails, the file will remain in the spool directory. The leftover files should be periodically removed; the _u_u_c_l_e_a_n program is useful in this regard. The command uuclean -pTM will remove all _T_M files older than three days. _S_T_S_T - _s_y_s_t_e_m _s_t_a_t_u_s _f_i_l_e_s These files are created in the spool directory by the _u_u_c_i_c_o program. They contain information of failures such as login, dialup or sequence check and will contain a _T_A_L_K_- _I_N_G status when two machines are conversing. The file name is the remote system name in the ``STST'' directory. For ordinary failures (dialup, login), the file will prevent repeated tries too frequently. For sequence check failures, the file must be removed before any future attempts to converse with that remote system. If the file is left due to an aborted run, it may con- tain a _T_A_L_K_I_N_G status. In this case, the file must be removed before a conversation is attempted. _L_C_K - _l_o_c_k _f_i_l_e_s Lock files are created for each device in use (e.g. automatic calling unit) and each system conversing. This prevents duplicate conversations and multiple attempts to use the same devices. The form of the lock file name is LCK..str where _s_t_r is either a device or system name. The files may September 2, 1987 - 33 - be left in the spool directory if runs abort. They will be ignored (reused) after a time of about 24 hours. When runs abort and calls are desired before the time limit expires, the lock files should be removed. _S_h_e_l_l _F_i_l_e_s The _u_u_c_p program will spool work and attempt to start the _u_u_c_i_c_o program, but the starting of _u_u_c_i_c_o will some- times fail. (No devices available, login failures etc.). Therefore, the _u_u_c_i_c_o program should be periodically started. The command to start _u_u_c_i_c_o can be put in a ``shell'' file and started by _c_r_o_n on an hourly basis. The file could contain the command: uucico -r1 Note that the ``-r1'' option is required to start the _u_u_c_i_c_o program in MASTER mode. Another shell file may be set up on a daily basis to remove _T_M, _S_T and _L_C_K files and _C. or _D. files for work which can not be accomplished for reasons like bad phone number, login changes etc. A shell file containing commands like uuclean -pTM -pC. -pD. uuclean -pST -pLCK -n12 can be used. Note the ``-n12'' option causes the _S_T and _L_C_K files older than 12 hours to be deleted. The absence of the ``-n'' option will use a three day time limit. A daily or weekly shell should also be created to remove or save old _L_O_G_F_I_L_Es. One can use a command like mv spool/LOGFILE spool/o.LOGFILE _L_o_g_i_n _E_n_t_r_y One or more logins should be set up for _u_u_c_p. Each of the ``/etc/passwd'' entries should have the _u_u_c_i_c_o as the shell to be executed. The login directory is normally ``/usr/spool/uucppublic''. The various logins are used in conjunction with the ``USERFILE'' to restrict file access. Specifying the _s_h_e_l_l argument limits the login to the use of UUCP (_u_u_c_i_c_o) only. _F_i_l_e _M_o_d_e_s It is suggested that the owner and file modes of vari- ous programs and files be set as follows. The programs _u_u_c_p, _u_u_x, _u_u_c_i_c_o and _u_u_x_q_t should be September 2, 1987 - 34 - owned by the _u_u_c_p login with the ``setuid'' bit set and only execute permissions (e.g. mode 04111). This will prevent outsiders from modifying the programs to get at a standard _s_h_e_l_l for the _u_u_c_p logins. ``L.sys'', ``SQFILE'', and the ``USERFILE'' which are put in the _p_r_o_g_r_a_m directory should be owned by the _u_u_c_p login and set so that they can only be read by the _u_u_c_p login and are writable by no one. September 2, 1987