Copyright (c) 1986, 1993
The Regents of the University of California. All rights reserved.

%sccs.include.proprietary.roff%

@(#)implement.ms 8.2 (Berkeley) 06/01/94

Installation and Operation of \*(UU

4.4BSD Edition .AU D. A. Nowitz .AI AT&T Bell Laboratories Murray Hill, New Jersey 07974 .AU Carl S. Gutekunst .AI Communications Software Research and Development Pyramid Technology Corporation Mountain View, California 94039 .AB \*(Uu is a series of programs designed to permit communication between X systems using a variety of communications links. \*(Uu provides batched, error free file transfers and remote command execution. It is well suited for tasks such as electronic mail, public news networks, and software distribution, particularly when only slow, low-cost communication links are available (e.g., 1200 baud dial-up).

This document describes the 4.3BSD version of \*(Uu. This is a distant but direct descendent of the ``second implementation'' of \*(Uu developed by D. A. Nowitz at AT&T Bell Laboratories. A number of other \*(Uu versions are in common usage; these are discussed only to the extent that they affect administration of 4.3BSD systems.

Revised August 24, 1986 .AE

.OH 'Installation and Operation of UUCP''SMM:14-%' .EH 'SMM:14-%''Installation and Operation of UUCP'

\*(UU OVERVIEW

\*(Uu is a batch-type operation. Users issue commands that are queued in a spool directory for processing by background daemons.

Uucp (UNIX-to-UNIX Copy) and uux (UNIX-to-UNIX Execution) provide the user interface to \*(Uu. Uucp has syntax and semantics similar to the standard X utility cp(1), with the added ability to prefix filenames with system names. Similarly, uux mimics the conventions of sh(1), and allows commands to be prefixed with system names.

Uucico (Copy-In, Copy-Out) is the primary \*(Uu daemon. It processes the requests queued by uucp and uux, initiates calls to remote systems, transfers files, and forks other daemons to execute uux-requested commands. Uucico also acts as the \*(Uu ``shell'' when remote systems call in to requests transfers.

Three types of files are used in \*(Uu operation. Control files describe the \*(Uu environment, including known remote hosts, available devices, and remote file access permissions. Control files are relatively static; they are generally changed only by the system administrator. Spool files (also called Queue files) contain transfer requests and data; they are created and deleted as necessary by uucp, uux, and uucico. Log files accumulate a history of \*(Uu activity; these tend to grow forever if not periodically cleaned up.

Spool files are further divided into three types: Work files contain directions for file transfers between systems. Every invocation of uucp or uux creates one or more work files. Data files contain data for transfer to or from remote systems. Execution files contain directions for X command executions which involve the resources of one or more systems. Execution files are created only by uux. ===========================================================================
SECTION 2: USER UTILITIES
===========================================================================

USER UTILITIES

\*(Uu includes a total of ten ``primary'' utilities, that is, ten utilities for general users. All reside in the /usr/bin directory, where they are easily accessible. This section provides detailed implementation descriptions for the more important commands; see the corresponding man pages for additional information.

The following two commands queue transfer requests:

uucp(1C) 15
UNIX-to-UNIX File Copy. One of more control files are created, containing names of files to be transferred. When necessary, local files are copied into data files for transmission.
uux(1C)
Execute command. An execute file is created, containing a X command to be executed and its arguments. A control file is created that includes all files that must be transferred to execute the command, including the execute file itself. When necessary, local files are copied into data files for transmission. Any output from the command will also be written to data files.

The following four commands provide \*(Uu status information:

uulog(1C) 15
Display selected information from the \*(Uu log.
uuname(1C)
Display the names of all remote hosts that are directly accessible via \*(Uu.
uusnap(8C)
Provide a snapshot of the current queue, including the number of work files, data files, and execute files for each site.
uuq(1C)
A variant of uusnap, lists files and uux commands queued for each site. Uuq also permits the \*(Uu administrator to delete jobs.

The following four commands provide miscellaneous support services:

uudecode(1C) 15
The decoder for files created by uuencode, below.
uuencode(1C)
A filter to convert binary files into printable ASCII. This is useful when transferring object files over communications links that do not support 8-bit transfers.
uupoll(8C)
A user utility to conveniently fork the \*(Uu daemon, uucico.
uusend(1C)
A utility to send files to remote sites more than one ``hop'' distant.
===========================================================================
Uucp - UNIX to UNIX File Copy

The uucp command is the user's primary interface with the system. The uucp command was designed to look like cp to the user. The syntax is

uucp [ option ] ... source ... destination

where the source and destination may contain the prefix system-name! which indicates the system on which the file or files reside or where they will be copied.

The options interpreted by uucp are:

-f 10
Don't make directories when copying the file. The default is to make the necessary directories.
-C
Copy source files to the spool directory. The default is to use the specified source when the actual transfer takes place.
-ggrade
Put grade in as the grade in the name of the work file. This is a single character in the range [0-9][A-Z][a-z]. The grade will be used by uucico to establish the priority of requests. 0 is the highest (best) grade; z is the lowest (worst). The default grade for uucp is n.
-m
Send mail on completion of the work.
-nuser
Notify user on the destination system that a file was sent.

The following options are used primarily for debugging, or when uucp is invoked from other programs:

-r 10
Queue the job but do not start uucico. The assumption is that uucico will be started at a later time, perhaps by cron(8) or uupoll.
-sdir
Use directory dir for the top level spool directory.
-xnum
Num is the level of debugging output desired. This option requires the user to have read permission to the \*(Uu control file L.sys.

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 ``?*[]''; these and other shell characters such as ``!<>'' will need to be quoted or escaped. If a source argument has a system-name! prefix for a remote system, the file name expansion will be done on the remote system.

The command

"" 12
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 ~user prefix. This translates to the login directory on the specified system. A lone ~ prefix is expanded to the name of the specified system's public access directory, usually /usr/spool/uucppublic. For names with partial path-names, the current directory is prepended to the file name. File names with ../ are not permitted.

The command

"" 12
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 classify 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 mentioned above.

After the work has been set up in the spool directories, the \*(Uu daemon uucico is started to try to contact the other machine to execute the work (unless the -r option was specified).

Type 1

Uucp makes a copy of the file. The -m option is not honored in this case.

Type 2

A one line "work file" is created for each file requested and put in the C. spool directory with the following fields, each separated by a blank. (All "work files" and "execute files" use a blank as the field separator.)

[1]
R
[2]
The full path-name of the source or a ~user/path-name. The ~user part will be expanded on the remote system.
[3]
The full path-name of the local destination file. If the ~user notation is used, it will be immediately expanded to be the login directory for the user.
[4]
The user's login name.
[5]
A `-' followed by an option list.
.KS
Type 3

For each source file, a "work file" is created. A -C option on the uucp command will cause the "data file" to be copied into the spool directory and the file to be transmitted from the copy; the copy is deleted when the transfer completes. 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 full path-name of the local source file. If the ~user notation is used, it will be immediately expanded to be the login directory for the user. If the -C option was used, this will be the name of a "data file" 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.
.KE
Type 4 and Type 5

Uucp generates a uucp command and sends it to the remote machine; the remote uucico executes the uucp command. ===========================================================================
Uux - UNIX To UNIX Execution

The uux command is used to set up the execution of a X command where the execution machine and/or some of the files are remote. The syntax of the uux command is

uux [ - "] [" option ] ... command-string

where the command-string is made up of one or more 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 system-name! 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 indicate that the standard input for command-string should be inherited from the standard input of the uux command.

The options, used mostly for debugging and by other programs, are:

-aname 10
Use name as the requestor of the uux command, instead of the real system and login names. Unlike most other \*(Uu arguments, name may consist of a chain of system names separated by `!' characters, as in:
15
uux - -r -aihnp4!decwrl!pyramid!csg seismo!rmail rick
-C 10
Copy source files to the spool directory. Same as for uucp.
-ggrade
Put grade in as the grade in the name of the work file. Same as for uucp. The default grade for uux is A.
-n
Do not mail an acknowledgement to the requestor of the command. Normally the execution daemon, uuxqt, will mail a message to the user who entered the uux command. This message includes the status return value that the program exited with. The -n option requests that this message not be sent.
-r
Do not start the \*(Uucp daemons uucico(8C) or uuxqt(8C) after queuing the job.
-xnum
Num is the level of debugging output desired.
-z
Mail an acknowledgement to the requestor only if the command fails, that is, the command exits with a non-zero status.

The command

"" 12
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''.

Uux generates an "execute file" which contains the names of the files required for execution (including standard input), the user's login name, the destination of the standard output, and the command to be executed. This file is either put in the X. spool directory for local execution, or in the D.hostnameX directory for transfer to the remote system.

For required files which are not on the execution machine, uux will generate receive command files (type 2 above). These command-files will be put on the execution machine and executed by uucico. (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 "execute file" will be processed by the uuxqt(8C) 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.

User Line
U user system

where the user and system are the requestor's login name and system.

Required File Line
F file-name real-name

where the file-name is the generated name of a file for the execute machine and real-name is the last part of the actual file name (contains no path information). Zero or more of these lines may be present in the "execute file" . The uuxqt program will check for the existence of all required files before the command is executed.

Standard Input Line
I file-name

The standard input is either specified by a `<' in the command-string or inherited from the standard input of the uux command if the `-' option is used. If a standard input is not specified, /dev/null is used.

Standard Output Line
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.)

Status Return Line
N

Normally uuxqt mails an acknowledgement message to the requestor after the command completes. The message includes the status return value that the program exited with. This line inhibits mailing of the acknowledgement message. It is generated by the -n option of uux; it is also quietly assumed by uuxqt on the command rmail.

Error Status Return Line
Z

A variant of the Status Return line, this line indicates that an acknowledgement should be mailed only if the command's status return is non-zero, i.e., the program exited with an error. This line is generated by the -z option of uux. It is also quietly assumed by uuxqt on the command rnews. If both the Z and N lines appear, the Z line has precedence.

Requestor Line
R requestor

where requestor is a complete return mailing address to the original requestor. This line is generated by the -a option of uux, and is used to override the mail return address implied by the User line. This is commonly used by mailers and programs like uusend that know how to ``hop'' a file from system to system.

Command Line
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 "required files" will be moved to the execution directory (a subdirectory of the spool directory) and the X command is executed using the Shell specified in the uucp.h header file (usually /bin/sh). 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.

===========================================================================
SECTION 3: SYSTEM UTILITIES
===========================================================================
SYSTEM AND ADMINISTRATIVE UTILITIES

\*(Uu includes four system utilities; these are not normally referenced by users. All except uucpd reside in the \*(Uu administrative directory, /usr/lib/uucp. These include:

uucico(8C) 15
Copy In, Copy Out. This is the primary \*(Uu daemon.
uuclean(8C)
A handy utility to clean up the \*(Uu spool directories.
uucpd
The \*(Uu TCP/IP daemon. This daemon ``answers'' the connection request from a remote uucico to a TCP/IP socket. It is functionally a stripped-down version of rlogind(8) that provides full 8-bit communication. (Note: this utility does not have a man page.)
uuxqt(8C)
Execution Daemon. This is forked by uucico to interpret execution files transferred from a remote system.
===========================================================================
Uucico - Copy In, Copy Out (\*(Uu Daemon)

Uucico is the ``heart'' of the \*(Uu system. The program performs the following major functions:

- 3
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.

Uucico may be started in several ways;

a) 5
by a system daemon (such as cron(8)),
b)
by one of the uucp, uux, uuxqt .R or uupoll programs,
c)
directly by the user (this is usually for testing),
d)
by a remote system. (The uucico program should be specified as the ``shell'' field in the /etc/passwd file for the \*(Uu logins.)

When started by method a, b or c, the program is considered to be in MASTER 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 SLAVE mode.

The MASTER mode will operate in one of two ways. If no system 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 uucico program is generally started by another program. There are several options used for execution:

-ggrade 10
Set the minimum grade of this uucico run to grade. Only files of this grade or better will be transferred.
-r1
Start the program in MASTER mode. This is used when uucico is started by a program or cron shell.
-ssys
Do work only for system sys. If -s is specified, a call to the specified system will be made even if there is no work for system sys in the spool directory. This is useful for polling systems which do not have the hardware to initiate a connection.

The following options are used primarily for debugging:

-ddir
Use directory dir for the top level spool directory.
-xnum
Num is the level of debugging output desired.

The next part of this section will describe the major steps within the uucico program.

Scan For Work

The names of the work related files in a spool subdirectory have format

type . system-name grade number

where:

Type is an upper case letter, ( C - work (copy command) file, D - data file, X - execute file);
System-name is the remote system;
Grade is a character in the range [0-9][A-Z][a-z];
Number is a four digit, padded sequence number.

The file

"" 12
C.res45n0031

would be a "work file" 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 work files (files with prefix C.). A list is made of all systems to be called. Uucico will then call each system and process all "work files" .

Call Remote System

The call is made using information from the control files that reside in the /usr/lib/uucp directory. 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 control file. The information contained for each system is;

[1]
system name,
[2]
times to call the system (days-of-week and times-of-day),
[3]
the caller, that is, the type of device to be used for the call,
[4]
the line speed or network number (as appropriate),
[5]
telephone number or device name (as appropriate),
[6]
login information (multiple fields).

The time field is checked against the present time to see if the call should be made.

The phone number .R may contain abbreviations (e.g. mh, py, boston) which get translated into dial sequences using the L-dialcodes file.

The L-devices 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 uucico will not try to use it. If the call is complete, the login information .R (field [6] of L.sys) is used to login.

The conversation between the two uucico programs begins with a handshake started by the called, SLAVE , system. The SLAVE sends a message to let the MASTER know it is ready to receive the system identification and conversation sequence number. The response from the MASTER is verified by the SLAVE and if acceptable, protocol selection begins. The SLAVE can also reply with a ``call-back required'' message in which case, the current conversation is terminated.

Line Protocol Selection

The remote system sends a message

"" 12
Pproto-list

where proto-list is a string of characters, each representing a line protocol.

The calling program checks the proto-list for a letter corresponding to an available line protocol and returns a use-protocol message. The use-protocol message is

"" 12
Ucode

where code is either a one character protocol letter or N which means there is no common protocol.

The following protocols are implemented in 4.3BSD \*(Uu:

g
General. Default for dialup or hardwired lines, supported by all versions of \*(Uu. This protocol employs small (64 byte) data packets with checksums and packet-by-packet retransmission. This ensures reliable and efficient transfers over slow and noisy links like 1200-baud dial-up lines. These same characteristics make the g protocol bulky and slow over error free links, and very expensive on public data-switched networks.
f
Optimized for use on X.25 PAD public data-switched networks. The protocol employs larger (256 byte) data packets, passes no control characters except CR, and uses only a 7-bit data path. (Note that the files transferred may still contain full 8-bit data.) It assumes that the link is ``mostly'' error-free, calculating a checksum for the entire file only. When an error is detected, the entire file is retransmitted.
t
Optimized for use on TCP/IP networks and other completely error free links. It employs large (1024 byte) packets, and uses the full 8-bit data path.

Note: AT&T System VR2 \*(UU supports the x (X.25) and e (Error Free) protocols, which provide functionality similar to the 4.3BSD f and t protocols, respectively. They are incompatible, however. Thus when attempting to connect two systems via X.25 or an local area network, it is not adequate for both systems to simply ``support X.25'' or ``support error free transfers.'' Both must support the same \*(Uu protocols.

Work Processing

The initial roles ( MASTER or SLAVE ) for the work processing are the mode in which each program starts. (The MASTER has been specified by the -r1 uucico option.) The MASTER 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;

"" 12

S 3
send a file,
R
receive a file,
C
copy complete,
X
execute a uucp command, and
H
hangup.

The MASTER 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 SLAVE will reply with SY, SN, RY, RN, HY, HN, XY, XN, corresponding to yes or no for each request.

The send and receive replies are based on permission to access the requested file/directory using USERFILE and read/write permissions of the file/directory. After each file is copied into the spool directory of the receiving system, a copy-complete message is sent by the receiver of the file. The message CY will be sent if the file has successfully been moved from the temporary spool file to the actual destination. Otherwise, a CN message is sent. (In the case of CN , the transferred file will be in the TM. spool subdirectory.) The requests and results are logged on both systems.

The hangup response is determined by the SLAVE program by a work scan of its spool directory. If work for the MASTER\|'s system exists in the SLAVE\|'s spool directory, an HN message is sent and the programs switch roles. If no work exists, an HY response is sent.

Conversation Termination

When a HY message is received by the MASTER it is echoed back to the SLAVE and the protocols are turned off. Each program sends a final ``OO'' message to the other. The original SLAVE program will clean up and terminate. The MASTER will proceed to call other systems and process work as long as possible or terminate if a -s option was specified.

===========================================================================
Uuxqt - Uucp Command Execution

The uuxqt program is used to execute execute files .R generated by uux. The uuxqt program may be started by either the uucico or uux programs. The program scans the X. spool directory for execute files. 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 execute file .R is described in the uux section above.

Command Execution

The execution is accomplished by executing a sh -c .R 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. ===========================================================================
Uuclean - Uucp Spool Directory Cleanup

This program is typically started by the cron(8) 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:

-ddir 10
The directory to be scanned is dir .
-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.)
-nhours
Change the aging time from 72 hours to hours hours.
-ppre
Examine files with prefix pre for deletion. (Up to 10 file prefixes may be specified.)
-xnum
This is the level of debugging output desired.
===========================================================================
SECTION 4: CONTROL FILES
===========================================================================
SYSTEM CONTROL FILES

Seven Control Files are referenced by the \*(Uu utilities. All live in the \*(Uu administrative directory, /usr/lib/uucp. These are ASCII files, and can be modified using standard text editors such as vi and ex. Lines beginning with a `#' character are comments; lines ending with a `\e' are continued on the next input line.

L-devices(5) 15
Declares all devices that are available to uucico for calling out.
L-dialcodes(5)
Phone number prefixes. Used to map alphabetic prefixes on phone numbers from L.sys to real phone numbers. Also useful to keep a phone number database outside of L.sys.
L.sys(5)
Systems. Declares all ``adjacent'' \*(Uu hosts, with directions on how to reach them.
L.aliases(5)
Contains aliases used to map obsolete or truncated host names to the correct names.
L.cmds(5)
Commands Permissions. Declares those commands for which remote uux execution is permitted.
SQFILE
Sequence-number check file. (Optional)
USERFILE(5)
Directory Tree Permissions. Specifies the set of directory trees that a particular user or host may reference.

A general description of each file follows; see the man pages for complete information. Examples of the six standard files are included in the distribution in the /usr/lib/uucp/UUAIDS directory. L-devices - \*(UU Devices File

This file declares all devices that are available to uucico for calling out. The special device files are assumed to be in the /dev directory. The format for each entry is

"" 12
caller line call-unit class dialer [chat....]

where;

caller 12
is the caller mechanism, that is, the type of device to be used. This can be one of ACU (for Automatic Call Units (modem)), DIR (direct hardwired), PAD (X.25/PAD), and others.
line
is the device for the link. For example, cul0 for a modem, tty10 for a hardwired line.
call-unit
is the automatic call unit associated with device. This is used on autodialers such as the Racal-Vadic MACS and the DEC DN-11 that use one device for data, and a second device for dialing. If unused, this field must contain a placeholder such as ``unused'' or ``0''. Some modems use this field to specify tone or pulse dialing.
class
is the line speed, plus an optional alphabetic prefix. The prefix can be used to distinguish among different devices that have identical caller and line speed.
dialer
applies to ACU devices only; this is the type or brand name of the modem. Supported modems include DN11 (DEC DN-11), hayes (Hayes Smartmodem), vadic (Racal-Vadic 3451), ventel (VenTel 212A), and others.
chat
refers to an expect/send script, similar to that provided in L.sys. The difference is that the script in L-devices is executed before the connection is established, while the script in L.sys is executed afterwards.

The line

"" 12
ACU tty47 unused 1200 hayes

would be set up for a system which had device tty47 wired to a Hayes ``Smartmodem 1200'' for use at 1200 baud. L-dialcodes - Phone Number Prefix File

This file contains entries with location abbreviations used in the L.sys file (e.g. py, mh, boston). The entry format is

"" 12
abb dial-seq

where;

abb 12
is the abbreviation,
dial-seq
is the dial sequence to call that location.

The line

"" 12
py 165-

would be set up so that entry py7777 would send 165-7777 to the dial-unit. L.aliases - Hostname Aliases File

This file defines mapping (aliasing) of remote host names. This is intended for compensating for systems that have changed names, or do not provide their entire machine name (like most USG systems). It is also useful when a machine's name is not obvious or commonly misspelled.

Each line is of the form

real-name alias-name

where real-name is the full, correct name for the host, and alias-name is the old or truncated name. L.sys - \*(Uu Systems File

Each entry in this file represents one system which can be called by the local uucp programs. The format for each entry is

system times caller class device/phone-number [login]

where;

"system" 12
is the hostname of the remote system.
times
is a keyword-encoded string that indicates the days-of-the-week and times-of-day when the system may be called. For example MoTuTh0800-1730 would denote Monday, Tuesday, and Thursday, between 8 a.m. and 5:30p.m.
The day portion may be a list containing any of Su, Mo, Tu, We, Th, Fr, Sa, or Wk for any week-day or Any for any day.
The time should be a range of times (as in 0800-1230). If no time portion is specified, any time of day is assumed to be acceptable for the call.
caller
is one of the caller device-types listed in L-devices.
class
is the line speed for the call (e.g., 300, 1200, 9600), plus an optional alphabetic prefix. Network devices use this field for the network port number.
phone
is the the phone number to call (for ACU devices) or the device filename. A phone number is made up of an optional alphabetic abbreviation and a numeric part. The abbreviation is one which appears in the L-dialcodes file (e.g. mh5900, boston995-9980).
login
is a script describing how to log in to the remote host. It is expressed as a series of fields and subfields in the format
"" 17
expect send [ expect send ] ...
"" 12
where; expect is the string expected to be read and send is the string to be sent when the expect string is received. The send string is normally terminated with carriage-return; an empty send string will send only a carriage-return.
The expect field may be made up of subfields of the form
"" 17
expect[-send-expect]...
"" 12
where the send is sent if the prior expect is not successfully read and the expect following the send is the next expected string.

A typical entry in the L.sys file would be

"" 6
sys Any ACU 1200 mh7654 login:--login: uucp ssword: word

The expect algorithm looks at the last part of the string as illustrated in the password field. L.cmds - Commands Permissions File

This file contains a list of commands, one per line, that are permitted for remote execution via uux. This list should be chosen with great care, since commands that take filenames as arguments will allow users to easily circumvent \*(Uu's security. For most sites, L.cmds should only include the lines: rmail ruusend SQFILE - Sequence Check File (Optional)

This file contains an entry for each remote system with which this site agrees 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 conversation count, and the date/time of the most resent conversation. These items will be updated with each conversation. If a sequence check fails, which could indicate that an unauthorized connection has been attempted, the entry will have to be adjusted.

This facility is technically no longer supported in 4.3BSD \*(Uu, since it was hardly ever used and consumed precious memory space on PDP-11 systems. The compile-time #define GNXSEQ can be set to enable sequence checking should it be needed. USERFILE - Pathnames Permissions File

This file contains user accessibility information. It specifies four types of constraint;

[1]
which files can be accessed by a normal user of the local machine,
[2]
which files can be accessed from a remote computer,
[3]
which login name is used by a particular remote computer,
[4]
whether a remote computer should be called back in order to confirm its identity.

Each line in the file has the following format

"" 6
login,sys [ c ] path-name [ path-name ] ...

where;

login 12
is the login name for a user or the remote computer,
sys
is the system name for a remote computer,
c
is the optional call-back required .R flag,
path-name
is a path-name prefix that is acceptable for user.

The constraints are implemented as follows.

[1]
When the program is obeying a command stored on the local machine, MASTER mode, the path-names allowed are those given for the first line in the USERFILE that has a login name that matches the login name of the user who entered the command. If no such line is found, the first line with a null login name is used.
[2]
When the program is responding to a command from a remote machine, SLAVE mode, the path-names allowed are those given for the first line in the file that has the system name that matches the system name of the remote machine. If no such line is found, the first one with a null system name is used.
[3]
When a remote computer logs in, the login name that it uses must appear in the USERFILE . There may be several lines with the same login name but one of them must either have the name of the remote system or must contain a null system name. Note: This constraint, although stated in the original Nowitz \*(Uu document, was not implemented in Version 7 \*(Uu. For all practical purposes, a remote computer's login was not validated by \*(Uu. This is still the case in 4.3BSD. Remote login checking is implemented in AT&T's System VR2.2 release, and in the \*(Uu provided with Digital Equipment Corporation's ULTRIX. HoneyDanBer analogously requires all remote logins to be listed in its Permissions file.
[4]
If the line matched in ([3]) contains a ``c'', the remote machine is called back before any transactions take place.

The line

"" 12
u,m /usr/xyz

allows machine m to login with name u and request the transfer of files whose names start with ``/usr/xyz''.

The line

"" 12
dan, /usr/dan

allows the ordinary user dan to issue commands for files whose name starts with ``/usr/dan''.

The lines

"" 12
u,m /usr/xyz /usr/spool

u, /usr/spool

allows any remote machine to login with name u , but if its system name is not m , it can only ask to transfer files whose names start with ``/usr/spool''.

The lines

"" 12
root, /

, /usr

allows any user to transfer files beginning with ``/usr'' but the user with login root can transfer any file.

===========================================================================
SECTION 5: SPOOL FILES
===========================================================================

SPOOL FILES

Spool Files contain \*(Uu transfer requests and data. Most have been described in detail earlier in this document.

All spool files live in the /usr/spool/uucp directory tree. To keep the spool directory from becoming hopelessly cluttered, each type of spool file is kept in its own subdirectory. The name of the directory is the same as the common prefix of the filename. For example, work files (files beginning with C.) are kept in the C. directory; execute files (which begin with X.) are kept in the X. directory, and so on.

A total of ten spool subdirectories are used, one of which is optional:

C. 15
Work files.
CORRUPT
Corrupted work and execute files. Uucico and uuxqt will deposit C. and X. files here when they are unable to parse them. A notice will also be placed in the \*(Uu log.
D.
Data files received from remote hosts.
D.hostname
Data files to be sent to remote hosts.
D.hostnameX
Execution files to be sent to remote hosts.
LCK
Per-device and per-site lock (LCK.) files. (Optional)
STST
Per-site system status files.
TM.
Temporary files used in data transfer. When the transfer is complete, the file is typically mv'ed to the D. or X. directory.
X.
Execution files received from remote sites.
XTMP
Temporary files and home directory for uuxqt.

The following sections describe only those spool files that were not discussed earlier. LCK - lock files

Lock files are created for each device in use (except for TCP/IP sockets) and each system conversing. This prevents duplicate conversations and multiple attempts to use the same devices. The form of the lock file name is

"" 12
LCK..str

where str is either a device or system name. The files may be left in the spool directory if uucico aborts. They will be ignored (reused) after 90 minutes. When runs abort and calls are desired before the time limit expires, the lock files should be removed. If the LCK. subdirectory is used, it's access mode can be set to 777, thus allowing normal users to remove dead lock files when necessary. STST - system status files

These files are created in the STST subdirectory by uucico. They contain information of failures such as login, dialup, or sequence check, and will contain a TALKING, RECEIVING, or SENDING status when two machines are conversing. The file name is STST/system, where system is the host name of the remote machine.

For ordinary failures (dialup, login), the file indicates the time of the last failure; this allows uucico to avoid retrying the failed call too soon. 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 contain a TALKING status. In this case, the file must be removed before a conversation is attempted. The easiest way to do this is to use the uupoll command to force uucico to start up. TM - temporary data files

These files are created in the /usr/spool/uucp/TM. directory while files are being copied from a remote machine. Their names have the form

"" 12
TM.pid.ddd

where pid is a process-id and ddd is a sequential three digit number starting at zero for each invocation of uucico and incremented for each file received. After the entire remote file is received, the TM file is moved to the requested destination, often the X. or D. directory. If processing is abnormally terminated or the move fails, the file will remain in the TM. directory.

The stranded files should be periodically removed; the uuclean program is useful in this regard. The command

"" 12
uuclean -d/usr/spool/uucp/TM. -pTM.

will remove all TM files older than three days. ===========================================================================
SECTION 6: LOG FILES
===========================================================================

LOG FILES

The following files provide a history of \*(Uu activities. All live in the spool directory, /usr/spool/uucp. They grow forever, and must be periodically trimmed or deleted; this is usually done weekly (or daily) via cron.

AUDIT 12
This is a directory of audit trail files, one file per site. Uucico uses an audit file for debugging output whenever it is run with debug enabled (via the -x option or a SIGFPE signal), but the standard message output file stderr is not available.
ERRLOG
This is an oft-forgotten log of \*(Uu ``Assert'' errors. An Assert error is a catastrophic and unrecoverable failure of the \*(Uu system. These include spool directories or control files that cannot be opened, an unexpected error return from a system call, or an ``impossible case'' in a utility's control flow.
Utilities that abort with an Assert error return a status code of -1. If a user reports uucp or uux dying with a message like ``uux failed, status -1,'' then the ERRLOG file should be checked.
LOGFILE
This is the primary \*(Uu log. All \*(Uu activity is recorded here, including queue requests from uucp and uux, attempted connections, file transfers, and communications failures.
SYSLOG
This is a log of file transfer statistics: number of bytes, time required, and number of packet retries. The effective data rate can be calculated simply by dividing the number of bytes by the time; low data rates or a large number of retries implies that the communication link may marginal.

Optionally, one LOGFILE per site may be maintained in the LOG subdirectory. This option can be selected at \*(Uu compile time via the LOGBYSITE #define in uucp.h. ===========================================================================
SECTION 7: ADMINSTRATION AND SYSTEM SECURITY
===========================================================================

ADMINISTRATION AND SYSTEM SECURITY X System Files
/etc/passwd

\*(Uu requires a login in /etc/passwd; at its simplest the entry would be uucp::66:1:UNIX-to-UNIX Copy:/usr/spool/uucppublic:/usr/lib/uucp/uucico

This user should own all the \*(Uu files and utilities. Remote sites wishing to call in for \*(Uu transfers would login to uucp (with the correct password, if any), and get uucico as their ``shell.'' Since uucico would be called without any options, it would run in SLAVE mode, thus responding correctly to the remote system, which would be in MASTER mode.

The directory /usr/spool/uucppublic should be created with 777 access modes, owned by uucp. In addition to serving as the home directory for \*(Uu remote logins, uucppublic provides a ``public-access'' directory where any user can read, write, or transfer files.

There are a number of security problems with using a single login, not the least of which is that superuser permission would be necessary to edit the control files. A better arrangement would be: uucp::66:1:UUCP Administrator:/usr/lib/uucp: nuucp::67:1:UNIX-to-UNIX Copy:/usr/spool/uucppublic:/usr/lib/uucp/uucico This provides one login for the \*(Uu administrator (which must be kept secure!) and a second for remote machines to use for login. A still more elaborate setup would use a separate login for each remote site, and possibly provide the administrator with a choice of shells: uucp::66:1:UUCP Administrator:/usr/lib/uucp: UUCP::66:1:UUCP Administrator:/usr/lib/uucp:/bin/csh Uhosta::6001:1:UNIX-to-UNIX Copy:/usr/spool/uucppublic:/usr/lib/uucp/uucico Uhostb::6002:1:UNIX-to-UNIX Copy:/usr/spool/uucppublic:/usr/lib/uucp/uucico Uhostc::6003:1:UNIX-to-UNIX Copy:/usr/spool/uucppublic:/usr/lib/uucp/uucico

It is assumed that the login name used by a remote computer to dial in is not the same as the login name of a normal user of the machine. However, several remote computers may employ the same login name.

Note that uucppublic is not used as the home directory for uucp when it logs into a regular shell. This would be an extreme security hazard, since anyone could slip a ``Trojan horse'' into a .profile or .cshrc file, which would be automatically executed when the \*(Uu administrator logged in.

/etc/rc

The system startup file, /etc/rc, should clean up any stray lock files with the line

rm -f /usr/spool/uucp/LCK.*

or, if the LCK subdirectory is being used,

rm -f /usr/spool/uucp/LCK/LCK.*
/etc/services

If \*(Uu is to be used over TCP/IP links, then an entry for \*(Uu's port number should be added to /etc/services:

uucp 540/tcp uucpd # UUCP TCP/IP ===========================================================================
Shell Scripts For Periodic Cleanup

The \*(Uu system has a fairly large number of activities that must occur periodically. These include starting uucico to process queued requests, running uuclean to remove old spool files, and shuffling the boundlessly-growing log files. Some sites will also want to poll other sites periodically.

While it's possible to put all the necessary commands into cron's control file /usr/lib/crontab, this would be extremely awkward. The usual technique is to use three separate shells scripts, one each for hourly, daily, and weekly operations. Examples are provided in the UUAIDS directory; the following sections provide some specific recommendations.

Hourly

Activities that should occur hourly include:

- 2
Polling of selected sites. Sites that have no dial-out capability will need to be periodically polled. The uupoll command works well for this.
-
Start uucico to complete all unfinished work. This can be as simple as:
"" 7
uucico -r1 &
Daily

The daily script should be started by cron in the wee hours, around 4 a.m. Activities that should occur daily include:

- 2
Call uuclean to remove old spool files. The preferred technique is something like the following: cd /usr/lib/uucp deadtime=`expr 24 * 7` uuclean -d/usr/spool/uucp/AUDIT -n72 uuclean -d/usr/spool/uucp/LCK -pLCK. -pLTMP. -n24 uuclean -d/usr/spool/uucp/STST -n72 uuclean -d/usr/spool/uucp/TM. -pTM. -n72 uuclean -d/usr/spool/uucp/XTMP -n72 uuclean -d/usr/spool/uucp/X. -pX. -n$deadtime uuclean -d/usr/spool/uucp/C. -pC. -n$deadtime uuclean -d/usr/spool/uucp/D. -pD. -n$deadtime uuclean -d/usr/spool/uucp/D.`uuname -l` -pD. -n$deadtime uuclean -d/usr/spool/uucp/D.`uuname -l`X -pD. -n$deadtime
In this example, Audit files, Lock files, System Status files, temp files, and uuxqt output files are cleaned up every 72 hours (3 days). (LTMP. files are temporary files created by the lock mechanism; they are rarely around for more than a few seconds. Note, the above assumes that the LCK subdirectory is being used.) All normal data files are cleaned up every 24 * 7 hours, or every 7 days.
-
Shuffle the log files. At the very least, LOGFILE should be moved to LOGFILE.old, and SYSLOG moved to SYSLOG.old. Busy sites may want to use compress(1) to squeeze down the old files.
-
Use find(1) to clean up the /usr/spool/uucppublic directory. If left unattended, garbage will gradually accumulate there until it fills the file system.
Weekly

Small sites with very little traffic may chose to shuffle the log files once per week, instead of once per day. The weekly script should, like the daily script, be run early in the morning. ===========================================================================
Connecting new systems

When first connecting a new machine to a \*(Uu network, it is useful to try and establish a connection with tip or cu first. The \*(Uu administrator will quickly become aware of any special facilities that are going to be required, for example: What lines and modems are to be used? Is the connection 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 login dialogue in L.sys?

Once a successful login is achieved ``by hand,'' the administrator should have enough information to allow the correct setup of the control files in /usr/lib/uucp.

The \*(Uu administrator should then negotiate with the remote site's \*(Uu administrator as to who (if anyone) will do polling and when. Both administrators must set up the relevant accounts and passwords. The local 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. ============================================================================
Miscellaneous Security Issues

The \*(Uu system, left unrestricted, will let any outside user execute any commands and copy any files that are accessible to the uucp login user. It is up to the individual 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 \*(Uu system.

- 3
The login for uucp does not get a standard shell. Instead, uucico is started. Therefore, the only work that can be done is through uucico .
-
A path check is done on file names that are to be sent or received. USERFILE supplies the information for these checks. 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.
-
Uuxqt is restricted via the L.cmds file to a small list of commands that it will execute. A ``PATH'' shell statement is prepended to the command line as specified in the L.cmds file. The administrator may modify the list or remove the restrictions as desired.
-
All the \*(Uu utilities except uudecode, uuencode, and uusend should be owned by the uucp 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 shell with a uucp login. Optionally, the utilities may belong to group daemon and be given ``setgid'' permissions (mode 06111). Uuxqt should only permit other \*(Uu programs to execute it; its mode should be 04100 or 06110.
-
The control files L.sys, USERFILE, and SQFILE contain highly sensitive information. They should be owned by the uucp login, with read and write permission granted only to the owner (mode 0600). ===========================================================================
SECTION 7: UUCP SOURCE INSTALLATION
===========================================================================
INSTALLING THE \*(UU SYSTEM

The source for the \*(UU system resides in the /usr/src/usr.bin/uucp directory. The README file includes complete instructions on how to rebuild the \*(Uu system from source.

For most environments, only two files will need to be modified: uucp.h includes a large number of tunable system-dependent parameters, including operating system type, devices to be supported, and a variety of optional features. The Makefile may also have to be modified, particularly if you chose to keep certain files in different directories from usual. ===========================================================================
SECTION 8: ACKNOWLEDGMENTS
===========================================================================

ACKNOWLEDGEMENTS

4.3BSD UUCP was a group development effort, involving the contributed work of over one hundred members of the USENET community. We're extremely grateful to them all.

Special thanks go to the following individuals, whose contributions were especially valuable:

- 2
Rick Adams (Center for Seismic Studies) coordinated the 4.3BSD UUCP release, incorporating (and often correcting) hundreds of bug fixes that were posted on the USENET and mailed to him directly. Rick also managed to find time to add many enhancements and corrections of his own.
-
Tom Truscott (Research Triangle Institute) and Bob Gray (then with PAR Tech Corp, now at Univ of Colorado) coordinated the 4.2BSD UUCP release, which was also a group effort. Tom has continued to provide enhancements and fixes in 4.3BSD.
-
Guy Harris (then with Computer Consoles, Inc., now with Sun Microsystems) contributed many general bug fixes; in particular, he was the first to isolate the infamous 4.2BSD ``TIMEOUT'' bug.
-
Lou Salkind (New York University) wrote the uuq utility.
-
James Bloom (U.C. Berkeley) isolated a major day-one bug in the g-protocol driver that had eluded many people's attempts to squash it.
-
Piet Beertema (Centrum voor Wiskunde en Informatica, Amsterdam) wrote the f-protocol to support ``mostly error-free links''; Robert Elz (University of Melbourne) modified the protocol specifically for X.25/PAD.
-
Peter Honeyman (Princeton) assisted Rick by providing information on the facilities provided in HoneyDanBer UUCP; Rick then added many HDB-compatibility features and HDB-like extensions to 4.3BSD UUCP.
-
Ross Green (U.C. Berkeley) produced the first revision of this chapter, updating the aging Nowitz document to more closely reflect reality.

Thanks again to everyone who contributed. Berkeley UUCP continues to be a product of its own users, and would not exist as it does today without them.