.\" Copyright (c) 1986 Regents of the University of California.
.\" All rights reserved. The Berkeley software License Agreement
.\" specifies the terms and conditions for redistribution.
.\" @(#)implement.ms 6.4 (Berkeley) %G%
Installation and Operation of \*(UU
Murray Hill, New Jersey 07974
Communications Software Research and Development
Pyramid Technology Corporation
Mountain View, California 94039
\*(Uu is a series of programs designed to permit communication
systems using a variety of communications links.
\*(Uu provides batched, error free file transfers and remote command
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.
.OH 'Installation and Operation of UUCP''SMM:9-%'
.EH 'SMM:9-%''Installation and Operation of UUCP'
\*(Uu is a batch-type operation.
Users issue commands that are queued in a spool directory for processing
\fIUucp\fP (UNIX-to-UNIX Copy) and \fIuux\fP (UNIX-to-UNIX Execution)
provide the user interface to \*(Uu.
has syntax and semantics similar to the standard
utility \fIcp\fP(1), with the added ability to prefix filenames with
Similarly, \fIuux\fP mimics the conventions of \fIsh\fP(1), and allows
commands to be prefixed with system names.
\fIUucico\fP (Copy-In, Copy-Out) is the primary \*(Uu daemon.
It processes the requests queued by \fIuucp\fP and \fIuux\fP,
initiates calls to remote systems, transfers files, and forks other
daemons to execute \fIuux\fP-requested commands.
\fIUucico\fP also acts as the \*(Uu ``shell'' when remote systems call in
Three types of files are used in \*(Uu operation.
\fIControl files\fP 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
\fISpool files\fP (also called \fIQueue files\fP) contain transfer requests
and data; they are created and deleted as necessary
by \fIuucp\fP, \fIuux\fP, and \fIuucico\fP.
\fILog files\fP accumulate a history of \*(Uu activity; these tend to
grow forever if not periodically cleaned up.
Spool files are further divided into three types:
contain directions for file transfers between systems.
Every invocation of \fIuucp\fP or \fIuux\fP creates one or more work files.
\fIData files\fP contain data for transfer to or from remote systems.
\fIExecution files\fP contain directions for
involve the resources of one or more systems.
Execution files are created only by \fIuux\fP.
.\"===========================================================================
.\" SECTION 2: USER UTILITIES
.\"===========================================================================
\*(Uu includes a total of ten ``primary'' utilities, that is, ten
utilities for general users.
All reside in the \fB/usr/bin\fP directory, where they are easily accessible.
This section provides detailed implementation descriptions for the more
important commands; see the corresponding \fIman\fP pages for additional
The following two commands queue transfer requests:
One of more \fIcontrol files\fP are created, containing names of files to be
When necessary, local files are copied into \fIdata files\fP for
An \fIexecute file\fP is created, containing a
command to be executed and its arguments.
A \fIcontrol file\fP is created that includes all files that must be
transferred to execute the command, including the \fIexecute file\fP itself.
When necessary, local files are copied into \fIdata files\fP for
Any output from the command will also be written to \fIdata files\fP.
The following four commands provide \*(Uu status information:
Display selected information from the \*(Uu log.
Display the names of all remote hosts that are directly accessible via \*(Uu.
Provide a snapshot of the current queue, including
the number of work files, data files, and execute files for each site.
A variant of \fIuusnap\fP, lists files and \fIuux\fP commands
\fIUuq\fP also permits the \*(Uu administrator to delete jobs.
The following four commands provide miscellaneous support services:
The decoder for files created by \fIuuencode\fP, below.
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.
A user utility to conveniently fork the \*(Uu daemon, \fIuucico\fP.
A utility to send files to remote sites more than one ``hop'' distant.
.\"===========================================================================
Uucp - UNIX to UNIX File Copy
command is the user's primary interface with the system.
command was designed to look like
\ ...\ \ source\ ...\ \ destination
where the source and destination
may contain the prefix \fIsystem-name\fP\fB!\fP
which indicates the system on which the file
or where they will be copied.
The options interpreted by
Don't make directories when copying the file.
The default is to make the necessary directories.
Copy source files to the spool directory.
The default is to use the specified source when the actual
in as the grade in the name of the work file.
This is a single character in the range \fB[0-9][A-Z][a-z]\fP.
The \fIgrade\fP will be used by \fIuucico\fP to establish the
\fB0\fP is the highest (best) grade; \fBz\fP is the lowest (worst).
Send mail on completion of the work.
Notify \fIuser\fR on the destination system that a file was sent.
The following options are used primarily for debugging, or when
is invoked from other programs:
Queue the job but do not start \fIuucico\fP.
The assumption is that \fIuucico\fP will be started at a later time, perhaps
by \fIcron\fP(8) or \fIuupoll\fP.
for the top level spool directory.
is the level of debugging output desired.
This option requires the user to have read permission to the \*(Uu
control file \fIL.sys\fP.
The destination may be a directory name,
in which case the file name is taken from the last part of the
name may contain special shell characters
these and other shell characters such as ``\fB!<>\fP'' will need to be quoted
If a source argument has a
prefix for a remote system,
the file name expansion will be done on the remote system.
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 \fB~\fP\fIuser\fP
This translates to the login directory on
A lone \fB~\fP prefix is expanded to the name of the specified system's
public access directory, usually
\fB/usr/spool/uucppublic\fP.
For names with partial path-names,
the current directory is prepended to the file name.
uucp\ \ usg!~dan/*.h\ \ ~dan
will set up the transfer of files whose names end with ``.h''
directory on system ``usg'' to dan's local
the program will check the source and destination
and the system-part of each to
classify the work into one of five types:
Copy source to destination on local system.
Receive files from a remote system.
Send files to a remote system.
Send files from remote system
to another remote system.
Receive files from remote system when the source pathname
contains special shell characters as
After the work has been set up in the spool directories,
the \*(Uu daemon \fIuucico\fP is started to try to contact the other
machine to execute the work (unless the \-r option
makes a copy of the file.
option is not honored in this case.
is created for each file requested and put in the \fBC.\fP spool directory
with the following fields, each separated by a blank.
use a blank as the field separator.)
The full path-name of the source or a ~user/path-name.
part will be expanded on the remote system.
The full path-name of the local destination file.
notation is used, it will be immediately
expanded to be the login directory for the user.
A `\-' followed by an option list.
A \fB\-C\fP option on the
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.
The full-path name of the source file.
The full-path name of the destination or
A `\-' followed by an option list.
The full path-name of the local source file.
notation is used, it will be immediately
expanded to be the login directory for the user.
If the \fB\-C\fP option was used, this will be the name of a
The file mode bits of the source file
The user to notify on the remote system that the transfer has completed.
command and sends it to the remote machine;
.\"===========================================================================
Uux - UNIX To UNIX Execution
command is used to set up the execution of a
where the execution machine and/or some of the
The syntax of the uux command is
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
All arguments which do not contain a ``!'' will not
(They will not be copied to the execution machine.)
The `\-' is used to indicate that the standard input
should be inherited from the standard input
The options, used mostly for debugging and by other programs, are:
Use \fIname\fP as the requestor of the \fIuux\fP command, instead of the
real system and login names.
Unlike most other \*(Uu arguments, \fIname\fP may consist of a chain of
system names separated by `!' characters, as in:
uux\ \ \-\ \ \-r\ \ \-aihnp4!decwrl!pyramid!csg\ \ seismo!rmail\ \ rick
Copy source files to the spool directory.
in as the grade in the name of the work file.
Do not mail an acknowledgement to the requestor of the command.
Normally the execution daemon, \fIuuxqt\fP, will mail a message
to the user who entered the \fIuux\fP command.
This message includes the status return value that the program exited with.
The \fB\-n\fP option requests that this message not be sent.
Do not start the \*(Uucp daemons \fIuucico\fP(8C) or \fIuuxqt\fP(8C)
Num is the level of debugging output desired.
Mail an acknowledgement to the requestor only if the command fails, that
is, the command exits with a non-zero status.
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''.
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 \fBX.\fP spool directory
or in the \fBD.\fP\fIhostname\fP\fBX\fP directory
for transfer to the remote system.
For required files which are not on the execution machine,
will generate receive command files (type 2 above).
These command-files will be put on the execution machine and
(This will work only if the local system has permission
to put files in the remote spool directory as controlled
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.
are the requestor's login name and system.
is the generated name of a file for the execute machine
is the last part of the actual file name (contains no
Zero or more of these lines may be present in the
program will check for the existence of all required
files before the command is executed.
The standard input is either specified by a `<' in the
command-string or inherited from the standard input of the
command if the `\-' option is used.
If a standard input is not specified,
O\ \ file-name\ \ system-name
The standard output is specified by a `>' within the
If a standard output is not specified,
(Note \- the use of ``>>'' is not implemented.)
Normally \fIuuxqt\fP 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 \fB-n\fP option of \fIuux\fP;
it is also quietly assumed by \fIuuxqt\fP on the command \fBrmail\fP.
A variant of the \fIStatus Return\fP 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 \fB-z\fP option of \fIuux\fP.
It is also quietly assumed by \fIuuxqt\fP on the command \fBrnews\fP.
If both the \fBZ\fP and \fBN\fP lines appear, the \fBZ\fP line has
is a complete return mailing address to the original requestor.
This line is generated by the \fB-a\fP option of \fIuux\fP, and is used
to override the mail return address implied by the \fIUser\fP line.
This is commonly used by mailers and programs like \fIuusend\fP that
know how to ``hop'' a file from system to system.
The arguments are those specified in the command-string.
The standard input and standard output will not appear on this
will be moved to the execution directory (a subdirectory
command is executed using the Shell specified in the
header file (usually \fI/bin/sh\fP).
In addition, a shell ``PATH'' statement is prepended
After execution, the temporary standard output file is copied to
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 \fIuucpd\fP reside in the \*(Uu administrative directory,
Copy In, Copy Out. This is the primary \*(Uu daemon.
A handy utility to clean up the \*(Uu spool directories.
This daemon ``answers'' the connection request from a remote \fIuucico\fP
It is functionally a stripped-down version of \fIrlogind\fP(8) that provides
full 8-bit communication.
(Note: this utility does not have a \fIman\fP page.)
This is forked by \fIuucico\fP to interpret execution files
transferred from a remote system.
.\"===========================================================================
Uucico - Copy In, Copy Out (\*(Uu Daemon)
is the ``heart'' of the \*(Uu system.
The program performs the following major functions:
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.
may be started in several ways;
by a system daemon (such as \fIcron\fP(8)),
directly by the user (this is usually for testing),
(The \fIuucico\fP program should be specified as the ``shell''
field in the \fB/etc/passwd\fP file for the \*(Uu logins.)
When started by method a, b or c, the program is considered to
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
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
If a system name is specified, that system will be called,
and work will only be done for that system.
program is generally started by another program.
There are several options used for execution:
Set the minimum grade of this \fIuucico\fP run to \fIgrade\fP.
Only files of this grade or better will be transferred.
is started by a program or \fIcron\fP shell.
a call to the specified system
will be made even if there is no work for system
This is useful for polling systems which do not have
the hardware to initiate a connection.
The following options are used primarily for debugging:
for the top level spool directory.
is the level of debugging output desired.
The next part of this section will describe the major steps within
The names of the work related files in a spool subdirectory have format
type \fB.\fP system-name grade number
-\ work (copy command) file,
is a character in the range \fB[0-9][A-Z][a-z]\fP;
is a four digit, padded sequence number.
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
(files with prefix \fBC.\fP).
A list is made of all systems to be called.
will then call each system and process all
The call is made using information from the \fIcontrol\fP files
that reside in the \fB/usr/lib/uucp\fP 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
The information contained for each system is;
(days-of-week and times-of-day),
the \fIcaller\fP, that is, the type of device to be used for the call,
the line speed or network number (as appropriate),
telephone number or device name (as appropriate),
login information (multiple fields).
The time field is checked against the present time to see
if the call should be made.
may contain abbreviations (e.g. mh, py, boston) which get translated into dial
file is scanned using fields [3] and [4] from the
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
If a device is successfully opened, a lock file
is created so that another copy of
If the call is complete, the
The conversation between the two
programs begins with a handshake started by the called,
sends a message to let the
know it is ready to receive the system
identification and conversation sequence number.
and if acceptable, protocol selection begins.
can also reply with a ``call-back required''
message in which case, the current conversation
The remote system sends a message
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
is either a one character
which means there is no common protocol.
The following protocols are implemented in 4.3BSD \*(Uu:
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 \fBg\fP protocol bulky and slow over
error free links, and very expensive on public data-switched networks.
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.
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 \fBx\fP (\fIX.25\fP) and \fBe\fP
(\fIError Free\fP) protocols, which provide functionality similar to the
4.3BSD \fBf\fP and \fBt\fP 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
Both must support the same \*(Uu protocols.
) for the work processing are
the mode in which each program starts.
has been specified by the \fB\-r1\fP \fIuucico\fP option.)
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.
messages until all work from the spool directory is
complete, at which point an
\fISY\fR, \fISN\fR, \fIRY\fR, \fIRN\fR, \fIHY\fR, \fIHN\fR,
The send and receive replies are
based on permission to access the
requested file/directory using
and read/write permissions of the file/directory.
After each file is copied into the spool directory
a copy-complete message is sent by the receiver of the file.
file has successfully been moved from the
temporary spool file to the actual destination.
the transferred file will be in the \fBTM.\fP spool subdirectory.)
The requests and results are logged on both systems.
The hangup response is determined by the
program by a work scan of its spool directory.
If work for the \fIMASTER\fP\|'s system exists in the
message is sent and the programs switch roles.
message is received by the
and the protocols are turned off.
Each program sends a final ``OO'' message to the
program will clean up and terminate.
will proceed to call other systems
and process work as long as possible
.\"===========================================================================
Uuxqt - Uucp Command Execution
program is used to execute
program may be started by either the
The program scans the \fBX.\fP spool directory for
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 execution is accomplished by executing a
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
.\"===========================================================================
Uuclean - Uucp Spool Directory Cleanup
This program is typically started by the
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:
The directory to be scanned is
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
The mail will therefore most often go to the owner
Change the aging time from 72 hours to
Examine files with prefix
(Up to 10 file prefixes may be specified.)
This is the level of debugging output desired.
.\"===========================================================================
.\" SECTION 4: CONTROL FILES
.\"===========================================================================
Seven \fIControl Files\fP are referenced by the \*(Uu utilities.
All live in the \*(Uu administrative directory, \fB/usr/lib/uucp\fP.
These are ASCII files, and can be modified using standard text editors such
as \fIvi\fP and \fIex\fP.
Lines beginning with a `#' character are comments;
lines ending with a `\e' are continued on the next input line.
Declares all devices that are available to \fIuucico\fP for calling out.
Used to map alphabetic prefixes on phone numbers from \fIL.sys\fP to
Also useful to keep a phone number database outside of \fIL.sys\fP.
Declares all ``adjacent'' \*(Uu hosts, with directions on how to reach them.
Contains aliases used to map obsolete or truncated host names to the
Declares those commands for which remote \fIuux\fP execution is permitted.
Sequence-number check file. (Optional)
Directory Tree Permissions.
Specifies the set of directory trees that a particular user or host may
A general description of each file follows; see the \fIman\fP pages for
Examples of the six standard files are included in the distribution in the
\fB/usr/lib/uucp/UUAIDS\fP directory.
L-devices \- \*(UU Devices File
This file declares all devices that are available to
The special device files are assumed to be in the
The format for each entry is
caller line call-unit class dialer [chat....]
is the caller mechanism, that is, the type of device to be used.
This can be one of \fBACU\fP (for Automatic
Call Units (modem)), \fBDIR\fP (direct hardwired), \fBPAD\fP
is the device for the link.
For example, \fBcul0\fP for a modem, \fBtty10\fP for a hardwired line.
is the automatic call unit associated with
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.
is the line speed, plus an optional alphabetic prefix.
The prefix can be used to distinguish among different devices that
have identical \fIcaller\fP and line speed.
applies to \fBACU\fP devices only;
this is the type or brand name of the modem.
Supported modems include \fBDN11\fP (DEC DN-11),
\fBhayes\fP (Hayes Smartmodem),
\fBvadic\fP (Racal-Vadic 3451),
\fBventel\fP (VenTel 212A), and others.
refers to an \fIexpect/send\fP script, similar to that provided in
The difference is that the script in
is executed before the connection is established, while the script in
ACU\ \ tty47\ \ unused\ \ 1200\ \ hayes
would be set up for a system which
had device tty47 wired to a
Hayes ``Smartmodem 1200''
L-dialcodes \- Phone Number Prefix File
This file contains entries with location abbreviations used
file (e.g. py, mh, boston).
is the dial sequence to call that location.
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
It is also useful when a machine's name is not obvious or commonly misspelled.
is the full, correct name for the host, and
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]
is the hostname of the remote system.
is a keyword-encoded string that indicates the days-of-the-week
and times-of-day when the system may
For example \fBMoTuTh0800\-1730\fP would denote Monday, Tuesday,
and Thursday, between 8 a.m. and 5:30p.m.
The day portion may be a list containing
\fBSu\fP, \fBMo\fP, \fBTu\fP, \fBWe\fP, \fBTh\fP, \fBFr\fP, \fBSa\fP,
The time should be a range of times (as in \fB0800\-1230\fP).
If no time portion is specified, any time
of day is assumed to be acceptable for the call.
is one of the caller device-types listed in \fIL-devices\fP.
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.
is the the phone number to call (for \fBACU\fP devices) or the
A phone number is made up of an optional
alphabetic abbreviation and a numeric part.
The abbreviation is one which appears in the
file (e.g. mh5900, boston995\-9980).
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
is the string expected to be read and
is the string to be sent when the
string is normally terminated with carriage-return;
string will send only a carriage-return.
The expect field may be made up of subfields
expect\fB[\fR\-send\-expect\fB]\fR...
is the next expected string.
A typical entry in the L.sys file would be
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 \fIuux\fP.
This list should be chosen with great care, since commands that take filenames
as arguments will allow users to easily circumvent \*(Uu's security.
should only include the lines:
SQFILE \- Sequence Check File (Optional)
This file contains an entry for each remote
system with which this site agrees to perform conversation
The initial entry is just the system name of
The first conversation will add two items to the line,
the conversation count, and the date/time of the most
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
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
The compile-time #define GNXSEQ can be set to enable sequence checking
USERFILE \- Pathnames Permissions File
This file contains user accessibility information.
It specifies four types of constraint;
which files can be accessed by a normal user of the local machine,
which files can be accessed from a remote computer,
which login name is used by a particular remote computer,
whether a remote computer should be called back in order to confirm
Each line in the file has the following format
is the login name for a user or the remote computer,
is the system name for a remote computer,
is a path-name prefix that is acceptable for
The constraints are implemented as follows.
When the program is obeying a command stored on the local machine,
the path-names allowed are those given for the first line in the
that has a login name that matches the login name of the user
If no such line is found, the first line with a
When the program is responding to a command from a remote machine,
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
If no such line is found, the first one with a
When a remote computer logs in, the login name that
it uses must appear in the
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
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 \fIis\fP 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 \fIPermissions\fP file.
If the line matched in ([3]) contains a ``c'',
the remote machine is called back before any transactions take place.
and request the transfer of files whose names start with
to issue commands for files whose name starts with
allows any remote machine to login with name
but if its system name is not
it can only ask to transfer files whose names start with
allows any user to transfer files beginning with ``/usr''
.\"===========================================================================
.\" SECTION 5: 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
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
For example, \fIwork files\fP (files beginning with \fBC.\fP) are kept
in the \fBC.\fP directory; \fIexecute files\fP (which begin with \fBX.\fP)
are kept in the \fBX.\fP directory, and so on.
A total of ten spool subdirectories are used, one of which is optional:
Corrupted \fIwork\fP and \fIexecute\fP files.
\fIUucico\fP and \fIuuxqt\fP will deposit \fBC.\fP and \fBX.\fP files here
when they are unable to parse them.
A notice will also be placed in the \*(Uu log.
\fIData files\fP received from remote hosts.
\fIData files\fP to be sent to remote hosts.
\fIExecution files\fP to be sent to remote hosts.
Per-device and per-site lock (\fBLCK.\fP) files. (Optional)
Per-site system status files.
Temporary files used in data transfer.
When the transfer is complete, the file is typically
\fImv\fP'ed to the \fBD.\fP or \fBX.\fP directory.
\fIExecution files\fP received from remote sites.
Temporary files and home directory for \fIuuxqt\fP.
The following sections describe only those spool files that were not
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
The form of the lock file name is
is either a device or system name.
The files may be left in the spool directory if
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 \fBLCK.\fP 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 \fBSTST\fP subdirectory by
They contain information of failures such as login, dialup, or
sequence check, and will contain a
\fITALKING\fP, \fIRECEIVING\fP, or \fPSENDING\fP
status when two machines are conversing.
where \fIsystem\fP is the host name of the remote machine.
For ordinary failures (dialup, login), the file indicates the time
this allows \fIuucico\fP 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
In this case, the file must be removed before a conversation
The easiest way to do this is to use the \fIuupoll\fP command to
force \fIuucico\fP to start up.
TM \- temporary data files
These files are created in the
directory while files are being copied
Their names have the form
is a sequential three digit number starting at zero
and incremented for each file received.
After the entire remote file is received, the
file is moved to the requested destination,
often the \fBX.\fP or \fBD.\fP directory.
If processing is abnormally terminated or the
move fails, the file will remain in the
The stranded files should be periodically removed;
program is useful in this regard.
uuclean\ \ -d/usr/spool/uucp/TM.\ \ \-pTM.
files older than three days.
.\"===========================================================================
.\"===========================================================================
The following files provide a history of \*(Uu activities.
All live in the spool directory, \fB/usr/spool/uucp\fP.
They grow forever, and must be periodically trimmed or deleted;
this is usually done weekly (or daily) via \fIcron\fP.
This is a directory of audit trail files, one file per site.
uses an audit file for debugging output
whenever it is run with debug enabled (via the \fB-x\fP option or a
\fBSIGFPE\fP signal), but the standard message output file \fBstderr\fP is
This is an oft-forgotten log of \*(Uu ``Assert'' errors.
An Assert error is a catastrophic and unrecoverable failure of the \*(Uu
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 \fIuucp\fP or \fIuux\fP dying with a message like
``uux failed, status -1,'' then the ERRLOG file should be checked.
This is the primary \*(Uu log. All \*(Uu activity is recorded here,
including queue requests from \fIuucp\fP and \fIuux\fP, attempted
connections, file transfers, and communications failures.
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
low data rates or a large number of retries implies that the communication
Optionally, one \fILOGFILE\fP per site may be maintained in the \fBLOG\fP
This option can be selected at \*(Uu compile time via the LOGBYSITE #define
.\"===========================================================================
.\" SECTION 7: ADMINSTRATION AND SYSTEM SECURITY
.\"===========================================================================
ADMINISTRATION AND SYSTEM SECURITY
\*(Uu requires a login in \fB/etc/passwd\fP;
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
\fBuucp\fP (with the correct password, if any), and get
Since \fIuucico\fP would be called without any options, it would run in
mode, thus responding correctly to the remote system, which
should be created with 777 access modes, owned by \fBuucp\fP.
In addition to serving as the home directory for \*(Uu remote logins,
provides a ``public-access'' directory where any user can read, write,
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 \fIcontrol\fP 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
However, several remote computers may employ the same
used as the home directory for
when it logs into a regular shell.
This would be an extreme security hazard, since anyone could slip a
file, which would be automatically executed when the \*(Uu administrator
The system startup file, \fB/etc/rc\fP, should clean up any stray lock
rm -f /usr/spool/uucp/LCK.*
or, if the LCK subdirectory is being used,
rm -f /usr/spool/uucp/LCK/LCK.*
If \*(Uu is to be used over TCP/IP links, then an entry for \*(Uu's port
number should be added to \fB/etc/services\fP:
uucp\ \ 540/tcp\ \ uucpd\ \ # UUCP TCP/IP
.\"===========================================================================
Shell Scripts For Periodic Cleanup
The \*(Uu system has a fairly large number of activities that must
These include starting \fIuucico\fP to process queued requests,
running \fIuuclean\fP 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 \fIcron\fP's
control file \fB/usr/lib/crontab\fP, 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
directory; the following sections provide some specific recommendations.
Activities that should occur hourly include:
Polling of selected sites.
Sites that have no dial-out capability will need to be periodically polled.
The \fIuupoll\fP command works well for this.
Start \fIuucico\fP to complete all unfinished work.
This can be as simple as:
The daily script should be started by \fIcron\fP in the wee hours, around
Activities that should occur daily include:
to remove old spool files.
The preferred technique is something like the following:
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
Audit files, Lock files, System Status files, temp files, and \fIuuxqt\fP
output files are cleaned up every 72 hours (3 days).
(\fBLTMP.\fP 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
subdirectory is being used.)
All normal data files are cleaned up every 24 * 7 hours, or every 7 days.
At the very least, LOGFILE should be moved to LOGFILE.old, and SYSLOG moved
Busy sites may want to use \fIcompress\fP(1) to squeeze down the old files.
Use \fIfind\fP(1) to clean up the
If left unattended, garbage will gradually accumulate there until it fills
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.
.\"===========================================================================
When first connecting a new machine to a \*(Uu network,
it is useful to try and establish a connection with
\fItip\fR or \fIcu\fR first.
The \*(Uu administrator will quickly become aware of any special facilities
that are going to be required,
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
Once a successful login is achieved ``by hand,'' the administrator should
have enough information to allow the correct setup of the \fIcontrol\fR files
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
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
The login for uucp does not get a standard shell.
Therefore, the only work that can be done is through
A path check is done on file names that are to be sent
supplies the information for these checks.
can also be set up to require call-back
A conversation sequence count can be set up so
can be more confident that the caller
file to a small list of commands that it
A ``PATH'' shell statement is prepended to the command
The administrator may modify the list or remove the
All the \*(Uu utilities except \fIuudecode\fP, \fIuuencode\fP,
and \fIuusend\fP should be owned by the
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
Optionally, the utilities may belong to group \fBdaemon\fP and be given
``setgid'' permissions (mode 06111).
\fIUuxqt\fP should only permit other \*(Uu programs to execute it;
its mode should be 04100 or 06110.
The \fIcontrol\fP files \fIL.sys\fP, \fIUSERFILE\fP, and \fISQFILE\fP
contain highly sensitive information.
They should be owned by the
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
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:
includes a large number of tunable system-dependent parameters,
including operating system type, devices to be supported,
and a variety of optional features.
may also have to be modified,
particularly if you chose to keep certain files in different
.\"===========================================================================
.\" SECTION 8: ACKNOWLEDGMENTS
.\"===========================================================================
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
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 \fIuuq\fP utility.
James Bloom (U.C. Berkeley) isolated a major
day-one bug in the \fBg\fP-protocol driver
that had eluded many people's attempts to squash it.
Piet Beertema (Centrum voor Wiskunde en Informatica, Amsterdam) wrote the
\fBf\fP-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.