.\" 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.2 (Berkeley) %G%
Installation and Operation of UUCP
Computer Systems Research Group
Computer Science Division
Department of Electrical Engineering and Computer Science
University of California, Berkeley
Uucp is a series of programs designed to permit communication between
systems using either dial-up or
hardwired communication lines.
It is used for file transfers and remote command execution.
The first version of the system was designed and implemented
There have been many changes to the implementation of UUCP
since the release of 4.2BSD.
Many problems been fixed,
and several improvements to provide greater throughput have been incorporated.
A number of new features and facilites have been added,
The first part of this document gives a detailed
description of the use of UUCP.
The rest of the document indicates the changes that have been made to UUCP,
and provides an update on the installation and implementation details.
It is for use by an administrator/installer of the system;
it is not meant as a user's guide.
.OH 'Installation and Operation of UUCP''SMM:9-%'
.EH 'SMM:9-%''Installation and Operation of UUCP'
Uucp Implementation Description
Uucp is a batch type operation.
Files are created in a spool directory for processing
There are three types of files used for the execution
contain data for transfer to remote systems.
contain directions for file transfers between systems.
involve the resources of one or more systems.
The uucp system consists of ten primary and four
These programs are summaried in section 9.
The three most important primary programs are:
This program creates work and gathers data files in the spool directory
for the transmission of files.
This program creates work files, execute files and gathers data files for the remote execution of
This program updates the log file with new entries
and reports on the status of uucp requests.
The three most important secondary programs are:
This program executes the work files for data transmission.
This program executes the execution files for
This program removes old files from the spool directory.
The next six sections of this paper will describe the operation
the installation of the system,
the security aspects of the system,
the files required for execution,
and the administration of the system.
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
which indicates the system on which the file
or where they will be copied.
The options interpreted by
Make directories when necessary for copying the file.
Don't copy source files to the spool directory,
but use the specified source when the actual
in as the grade in the name of the work file.
(This can be used to change the order of work for a particular
Send mail on completion of the work.
The following options are used primarily for debugging:
Queue the job but do not start
is the level of debugging output desired.
The destination may be a directory name,
in which case the file name is taken from the last part of the
name may contain special shell characters
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
This translates to the login directory on
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 other systems.
Send files to a remote systems.
Send files from remote systems
to another remote system.
Receive files from remote systems when the source
contains special shell characters as
After the work has been set up in the spool directory,
program is started to try to contact the other
machine to execute the work (unless the \-r option
command is used to do the work.
options are not honored in this case.
is created for each file requested and put in the 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 destination file.
notation is used, it will be immediately
expanded to be the login directory for the user.
A ``\-'' followed by an option list.
(Only the \-m and \-d options will appear in this list.)
is created and the source file is copied into a
In this case, the file will be transmitted from
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 file mode bits of the source file
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, essentially for debugging, are:
Num is the level of debugging output desired.
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 spool directory
for local execution or sent to the remote system using
a generated send command (type 3 above).
For required files which are not on the execution machine,
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 requester'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.)
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
In addition, a shell ``PATH'' statement is prepended
to the command line as specified in the
After execution, the standard output is copied or set up to be
sent to the proper place.
programs create individual
log files for each program invocation.
may be executed to prepend these files to the
This method of logging was chosen to minimize file
locking of the logfile during program execution.
program merges the individual
log files and outputs specified log entries.
The output request is specified by the use of the
is the remote system name;
The intersection of lines satisfying the two options is output.
means all system names or users respectively.
Uucico - Copy In, Copy Out
program will perform 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;
directly by the user (this is usually for testing),
(The uucico program should be specified as the ``shell''
field in the ``/etc/passwd'' file for the ``uucp'' logins.)
When started by method a, b or c, the program is considered to
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:
is started by a program or ``cron'' 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:
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 the spool directory have format
type . system-name grade number
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
(files with prefix ``C.'').
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 several
files which reside in the uucp program 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 precise format of the
file is described in section 10, ``System File Details''.
The information contained for each system is;
(days-of-week and times-of-day),
device or device type to be used for call,
phone number if field [3] is
or the device name (same as field [3])
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
where code is either a one character
which means there is no common protocol.
) for the work processing are
the mode in which each program starts.
has been specified by the ``\-r1'' uucico 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 the
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 spool
directory with a name beginning with ``TM'.)
The requests and results are logged on both systems.
The hangup response is determined by the
program by a work scan of the spool directory.
If work for the remote 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 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.
is described in the ``Uux''
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 daemon, once a day.
Its function is to remove files from the spool directory 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.
Changes to the UUCP Implementation
The demands placed on UUCP networking,
have prompted several changes and improvements to the UUCP software.
Such things as low cost, autodial, autoanswer, high speed modems,
and the availability of X.25 and TCP/IP as carriers,
have encouraged new facilities in UUCP to be developed.
The following areas have been changed between the 4.2 and 4.3 BSD releases.
General fixes and performance improvements.
Administration control facilites.
Modem and autodialer support has been extended.
New protocols for different transport media.
Fixes and performance improvements.
Many of the fixes related to portability considerations,
and improvements as provided by the USENET community.
The \fIsitename\fR truncation length as been extended to 14 characters from
the original 7 characters.
This maintains compatibility with the current System V version of UUCP.
An effort as been made to improve the overall performance of the UUCP system
by organizing its workload in a more sensible way.
For example the program \fIuucico\fR will not resend files it has already sent,
when the files are specified in one ``C.'' file.
Administration and control facilities.
There is a new program, \fIuuq\fR,
to give more descriptive information on status of jobs in the UUCP spool queue.
It also allows the user to delete spooled requests,
In the past, on large UUCP sites,
the spool directory could grow large with many files
within the ``/usr/spool/uucp'' directory.
To help the UUCP administrator control the system,
a number of subdirectories have been created to easy this congestion.
The system status ``STST'' files are kept in a subdirectory.
Corrupted ``C.'' and ``X.'' files,
that could not be processed,
are placed in the ``CORRUPT'' subdirectory,
Lock files may be kept in a subdirectory,
If an ``X.'' request fails,
the notification is returned to the originator of the request,
instead of ``uucp'' on the previous system.
There is a new \fIsystem\fR file, ``L.aliases'',
that may be used when a site changes it's name.
\fIuucp\fR, \fIuux\fR, \fIuucico\fR, etc.,
Modem and autodialer support:
In a short period of time,
there has been a big increase in the transfer rates and capabilites
that are being provided with modern modems.
Most modems will allow several combinations of baud rate,
and provide autodial and autoanswer facilites as well.
Most sites will have but a few modems,
they are therefore a precious resource an effort has been made to use them
The \fIuucico\fR program now has code to dial in and out on the same device,
if that modem as both autodial and autoanswer provision.
There is a new dialing facility \fIacucntrl\fR that has been built to handle
some of the changes in modem technology.
There are a number of new modems and autodialers that can now be handled.
Here is a list of some of the new devices:
Racal Vadic 811 dialer with 831 adaptor,
Racal Vadic 820 dialer with 831 adaptor,
Racal Vadic MACS 811 dialer with 831 adaptor,
Racal Vadic MACS 820 dialer with 831 adaptor,
Concord Data Systems CDS 224,
ATT 2224 2400 baud modem.
It now correctly does the closing hangup sequence.
It will try up to TRYCALLS to dial a site
instead of one try for each dialer.
New protocols for different transportation mediums
The UUCP software has had provision for different protocols
to be used in the sending and receiving of data,
but originaly only one was implemented
and this is the one that is largely used throughout the UUCP community.
The standard `g' protocol,
has a maxium throughput around 9000 baud,
regardless of the physical medium.
The use of checksums and the like are of little use when the protocol
is bounded within another protocol such as TCP or X.25.
It is a waste of time and cpu resources to calculate CRC's
when the carrier already provides error free transmissions.
The UUCP system did not utilize LAN's and high speed carriers well.
Two new protocols have been added
to provide for efficient use of new carrier facilities.
The protocols now available to UUCP are:
`t' protocol, optimised for use on TCP/IP carriers.
`f' protocol, optimised for use on X.25 PAD carriers.
`g' protocol, standard UUCP protocol used for dialup or hardwired lines.
The `t' protocol presumes an error free channel,
and is essentially the `g' protocol without the checksumming and packetizing.
Other changes where necessary to run UUCP on top of a TCP carrier,
the code could not do ioctl's on sockets that are connections to remote hosts.
The `f' protocol relies on flow control of the data stream.
It is meant for working over links that can be guaranteed to be errorfree,
specifically X.25/PAD links.
A checksum is calculated over a whole file only.
If a transport fails the receiver can request retransmissions.
This protocol uses a 7-bit datapath only,
so it may be used on carriers that are not 8-bit transparent.
As well as adding new protocols,
the existing `g' protocol code has been cleaned up.
You can specify a maximum grade to send either
on the command line using (-gX)
Any/C|Evening will only send grade C,
or higher during the day and will send everything in the evening
The \fIsystem\fR files in the ``/usr/lib/uucp'' directory can contain comments,
by putting a `#' as the first character on a line.
Lines may be continued by placing a `\\' as the last character of a line.
This is helpful in making an understandable \fIL.sys\fR file.
Some new options are available to \fIuucico\fR, these include:
This flag reverses \fIuucico\fR role.
Let the remote system be master first instead of being the slave.
\fIuucico\fR will only call ``local'' sites.
Local sites are those sites having one of
\fBLOCAL\fR, \fBTCP\fR or \fBDIRECT\fR in the CALLER field of ``L.sys''.
If ``/etc/nologin'' is present,
usually created by \fIshutdown\fR,
\fIuucico\fR and \fIuuxqt\fR will gracefully exit,
instead of getting killed off when the system goes down.
Does an exponential backoff on retry time if call fails
instead of always waiting the default 5 minutes.
The default may be overridden by adding ",TIME" to the time field in ``L.sys''.
will use a default retry time of 2 minutes.
If \fIuucico\fR receives a SIGFPE while running,
it will toggle debugging on and off.
It will not send files to remote system if the remote system
is returning an out of temp space error.
Add ABORT sequence to the expect/send sequence so it does not have
to wait for timeout if cannot get through a dataswitch.
This example will only call noao in the evening.
then wait 1 second (\ed),
and then send a carriage return.
Look for CLASS, then send NOAOUUCP.
if it sees the word Down before finishing logging in,
it will hang up immediately.
delay 1 second and then send a CR.
This abort sequence is useful
if you must go through a dataswitch to get to the computer.
The time field in the ``L.sys'' file now handles
"Evening" and "Night" in addition to:
Any, Mo, Tu, We, Th, Fr, Sa, Su.
Evening and Night are defined to be:
Evening = Wk1700-0800|Sa|Su
Night = Any2300-0800|Sa|Su0800-1700
The expect/send code now handles '\e' sequences:
indicates a delay 1 second
indicates a carriage return with no linefeed
indicates do not send a CR after these characters
the octal character xxx (e.g. \es == \e040
The file \fIL-devices\fR now handles "chat" scripts,
to help get through local port selectors and smart modems.
This helps keep \fIL.sys\fR readable but increases functionality.
For compatibility with System V UUCP system,
in the Date fields of ``L.sys'':
`|' was changed to `,' (| is supported, but not encouraged)
`,' was changed to `;' (to allow , to be the date seperator)
For Honey DanBer compatibility,
the Grade flag is now passed as:
You can specify a time for the expect send sequences with ~ instead
of getting the default MAXMSGTIME.
system Any ACU 1200 1234567 ogin~20--ogin~10--ogin user password pw
will look for ``ogin'' for 20 seconds,
look for ``ogin'' for 10 seconds,
send a CR and look for ``ogin'' for MAXMSGTIME seconds
Added code to support GTEs PC Pursuit service.
It's mainly the handling of the dialback they use.
Added time "NonPeak" for Tymnet/Telenet services that charge lower rates
from 6pm-7am M-F and Sat & Sun.
Running \fIuucico\fR with debugging turned on,
requires ``L.sys'' to have read access.
The naming of a site is important since it provides a means of
There are two names used within the UUCP system,
these are the \fIloginname\fR and the \fIsitename\fR.
It is important that the \fIloginname\fR used by a remote machine
to call into a local machine
is not the same as that of a normal user of the local machine.
It is common for many remote machines to have the same \fIloginname\fR,
Each machine in a UUCP network is given a unique \fIsitename\fR.
The \fIsitename\fR identifies the calling machine to the called machine.
A \fIsitename\fR can be up to 14 characters in length.
It is useful to have a \fIsitename\fR that is unique in the first 7 characters,
to be compatible with earlier implementaions of UUCP.
It is desirable that the \fIsitename\fR will convey this uniqueness
and perhaps a real world identity to the rest of the network.
The \fIsitename\fR and the \fIloginname\fR are not the same thing!
They may have the same values,
but this is purely a decision of the UUCP administrators
when the network connections are set up.
The UUCP system organization.
There are several directories that are used by the UUCP system as distributed.
This directory contains the source files for generating the UUCP system.
This is the directory where system binaries,
and system control files reside.
This is the spool directory used to store transfer requests and data.
This is the directory where the programs used by users will be kept.
The following files are required for execution,
and should reside in the \fIsystem\fR directory,
This file contains entries for all devices that are to be used by UUCP.
This file contains dialing abbreviations.
Used to provide sitename aliases.
This file contains commands that can be used by a remote site.
Contains site connection information for each system that can be called.
The sequence numbering and check file.
Remote system access rights.
The program used to control calling remote systems.
The actual transfer program.
A utility to cleanup after UUCP.
Allows UUCP to execute commands.
The \fIcommand\fR directory, /usr/bin,
contains the following user available commands:
spools a UNIX to UNIX file-copy request.
spools a request for remote execution.
provides a facility to transfer binary files using mail.
binary file encoder (for \fIuusend\fR)
binary file decoder (for \fIuusend\fR)
provides a snap-shot of \fIuucp\fP activity.
polls remote system until an answer is received.
prints a list of known remote UUCP hosts.
reports information from the UUCP spool queue.
The \fIspool\fR directory,
contains the following files and directories:
A directory for command, ``C.'' files.
A directory for data, ``D.'', files.
A directory for command execution, ``X.'', files.
A directory for local ``D.'' files.
A directory for local ``X.'' files.
A directory for corrupted ``C.'' and ``X.'' files.
A file where internal error messages are collected.
A directory for device and site lock files.
A directory for individual site LOGFILE's.
the log file of UUCP activity.
A directory for site STST files.
the log file of UUCP file transfers.
A directory for temporary, ``TM.'', files.
There is an additional directory,
that is used as a general Public accecs directory for UUCP.
It is not used by UUCP directly
but it is normally the home directory for the UUCP system owner.
Most importantly this directory is owned by uucp,
and the access permissions are 0777,
this usually garrantees a place that files can be sent to,
This file contains entries for the call-unit devices and
hardwired connections which are to be used by UUCP.
The special device files are assumed to be in the /dev directory.
The format for each entry is:
\fIType Device Useful Class Dialer\fR [\fIChat\fR ...]
is the type of calling to use.
There are several different calling types.
\fBACU\fR indicates a dialing devices.
\fBDIR\fR is used when a direct connection is used.
\fBDK\fR an AT&T Datakit.
\fBMICOM\fR Micom terminal switch.
\fBPAD\fR X.25 PAD connection.
\fBPCP\fR GTE Telenet PC Pursuit.
\fBSYTEK\fR Sytek high-speed dedicated modem port.
\fBTCP\fR TCP/IP connection.
is the entry in ``/dev'' corresponding to a real device,
the owner should be uucp.
information to be used by the device,
such as the name of the callunit to be used,
or from the list of available dialers.
The list of available dialers includes:
Use a \fIDialer\fR field of \fBDF112T\fR to use tone dialing,
or \fBDF112P\fR for pulse dialing.
AT&T 2224 2400 baud modem.
Concord Data Systems 224 2400 baud modem.
Hayes Smartmodem 1200 and compatible autodialing modems.
Use a \fIDialer\fR field of \fBhayestone\fR to use tone dialing,
or \fBhayespulse\fR for pulse dialing.
It is also permissible to include the letters `T' and `P' in the phone number
to change to tone or pulse midway through dialing.
(Note that a leading `T' or `P' will be interpreted as a dialcode!)
Hayes Smartmodem 2400 and compatible modems.
Use a \fIDialer\fR field of \fBhayes2400tone\fR to use tone dialing,
or \fBhayes2400pulse\fR for pulse dialing.
Novation ``Smart Cat'' autodialing modem.
Penril Corp ``Hayes compatible'' modems.
Racal-Vadic 820 dialer with 831 adapter in a MACS configuration.
Racal-Vadic 212 autodialing modem.
Racal-Vadic 811s dialer with 831 adapter.
Racal-Vadic 820 dialer with 831 adapter.
Racal-Vadic 3450 and 3451 series autodialing modems.
Ventel 212+ autodialing modem.
Racal-Vadic 811 dialer with 831 adapter in a MACS configuration.
is a send/expect sequence that can be used to talk through dataswitches,
or issue special comands to a device such as a modem.
The syntax is identical to that of the Expect/Send script of \fIL.sys\fR.
the \fIL-devices\fR script is used before the connection is made,
while the \fIL.sys\fR script is used after.
This file contains entries with location abbreviations used
in the ``L.sys'' 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.
The \fIL.aliases\fR file provides a mapping facility of \fIsitenames\fR.
This facility is useful when \fIsitenames\fR are changed,
and the change is only temporary,
or the change is permanent but it is not widely known by the users of the net.
The format of the file is:
The ``L.aliases'' file may be used to map hosts with longer names in ``L.sys''
to 7 character names that some hosts send.
This provides a mechanism to handle those sites,
The L.cmds file contains a list of commands that are permitted
for remote execution with \fIuux\fR.
The commands are listed one per line.
Most sites L.cmds will be something like:
PATH=/bin:/usr/bin:/usr/ucb:/usr/local/bin
can be used to set a search path.
Each entry in this file represents one system
which can be called by the local UUCP programs.
The fields are described below.
\fISitename Times Caller Class Device\fR [\fIExpect Send\fR]....
is the name of the remote system.
Every machine with which this system communicates via UUCP should be listed,
regardless of who calls whom.
Systems not listed in ``L.sys'' will not be permitted a connection.
is a comma-separated list of the times of the day and week that
calls are permitted to this site.
This can be used to restrict long distance telephone calls
to those times when rates are lower.
List items are constructed as:
\fIkeyword\fPhhmm\fB-\fPhhmm\fB/\fP\fIgrade\fP\fB;\fP\fIretry_time\fP
\fIKeyword\fR is required, and must be one of:
Any time, any day of the week.
Any weekday. In addition,
\fBMo, Tu, We, Th, Fr, Sa,\fR and \fBSu\fR
can be used for Monday through Sunday, respectively.
When evening telephone rates are in effect,
from 1700 to 0800 Monday through Friday,
and all day Saturday and Sunday.
When nighttime telephone rates are in effect,
from 2300 to 0800 Monday through Friday,
all day Saturday, and from 2300 to 1700 Sunday.
.B Any2300-0800,Sa,Su0800-1700 .
This is a slight modification of
It matches when the USA X.25 carriers have their lower rate period. This
is 1800 to 0700 Monday through Friday, and all day Saturday and Sunday.
calling into this site is forbidden or impossible.
This is intended for polled connections,
where the remote system calls into the local machine periodically.
This is necessary when one of the machines is lacking
either dial-in or dial-out modems.
The optional \fIhhmm-hhmm\fR
subfield provides a time range that modifies the keyword.
in 24-hour time (from 0000 to 2359).
The time range is permitted to "wrap" around midnight,
and will behave in the obvious way.
It is invalid to follow the \fBEvening\fR, \fBNonPeak\fR,
and \fBNight\fR keywords with a time range.
The \fIgrade\fR subfield is optional; if present,
it is composed of a `/' (slash) and single character denoting the \fIgrade\fR
Grades are in the range [\fB0-9A-Za-z\fR].
This specifies that only requests of grade \fIgrade\fR
or better will be transferred during this time.
(The grade of a request or job is specified
when it is queued by \fIuucp\fR or \fIuux\fR).
By convention, mail is sent at grade \fBC\fR,
news is sent at grade \fBd\fR,
and uucp copies are sent at grade \fBn\fR.
Unfortunately, some sites do not follow these conventions,
so it is not 100% reliable.
The \fIretry_time\fR subfield is optional;
it must be preceded by a `;' (semicolon) and
specifies the time, in minutes,
before a failed connection may be tried again.
the retry time starts at 10 minutes and gradually increases at each failure,
until after 26 tries \fIuucico\fR gives up completely (MAX RETRIES).
If the retry time is too small,
\fIuucico\fR may run into MAX RETRIES too soon.
is the type of device used.
It may be one of the following:
\fBACU DIR MICOM PAD PCP SYTEK TCP\fR
the derscriptions in L-devices apply here.
If several alternate ports or network connections should be tried,
is usually the speed (baud) of the device,
typically 300, 1200, or 2400 for \fRACU\fR devices and 9600 for direct lines.
Valid values are device dependent,
and are specified in the ``L-devices'' file.
the speed may be preceded by a non-numeric prefix.
This is used in ``L-devices''
to distinguish among devices that have identical \fICaller\fR and baud,
but yet are distinctly different.
1200 could refer to all Bell 212-compatible modems,
V1200 to Racal-Vadic modems,
and C1200 to CCITT modems,
is the port number (an integer number) or a port name from ``/etc/services''
that is used to make the connection.
For standard Berkeley TCP/IP,
UUCP normally uses port number 540.
varies based on the \fICaller\fR field.
this is the phone number to dial.
The number may include: digits \fB0\fR through \fB9\fR;
for dialing those symbols on tone telephone lines;
(hyphen) to pause for a moment, typically two to four seconds;
(equal sign) to wait for a second dial tone
(implemented as a pause on many modems).
Other characters are modem dependent;
generally standard telephone punctuation characters
(such as the slash and parentheses) are ignored, although
The phone number can be preceded by an alphabetic
string; the string is indexed and converted through the ``L-dialcodes'' file.
For \fBDIR\fR devices, the
field contains the name of the device in /dev
that is used to make the connection.
There must be a corresponding line in ``L-devices'' with identical
\fICaller, Class\fR, and \fIDevice\fR fields.
For \fBTCP\fR and other network devices,
holds the true network name of the remote system,
which may be different from its UUCP name
(although one would hope not).
refer to an arbitrarily long set of strings that
alternately specify what to
to login to the remote system once a physical connection has
been established. A complete set of expect/send strings is referred
.IR "expect/send script" .
The same syntax is used in the
file to interact with the dialer prior to making a connection;
there it is referred to as a \fIchat script\fR.
The complete format for one
\fIexpect\fP\fB~\fP\fItimeout\fP\fB-\fP\fIsend\fP\fB-\fP\fI\
expect\fP\fB~\fP\fItimeout send\fP
is compared against in coming text from the remote host;
is matched. By default, the
is followed by a `\er' (carriage return). If the
string is not matched within
seconds (default 45), then it is assumed that the match failed.
The `\fIexpect\fP\fB-\fP\fIsend\fP\fB-\fP\fIexpect\fP' notation
provides a limited loop mechanism; if the first
string fails to match, then the
string between the hyphens is transmitted, and
string. This can be repeated indefinitely. When the last
hangs up and logs that the connection failed.
The timeout can (optionally) be specified by appending the parameter
`\fB~\fP\fInn\fP' to the expect string, when \fInn\fR is the timeout
Backslash escapes that may be imbedded in the
\eb Generate a 3/10 second BREAK.
\eb\fIn\fP Where \fIn\fP is a single-digit number;
generate an \fIn\fP/10 second BREAK.
\ec Suppress the \er at the end of a \fIsend\fP string.
\ed Delay; pause for 1 second. (\fISend\fR only.)
\exxx Where \fIxxx\fP is an octal constant;
denotes the corresponding ASCII character.
As a special case, an empty pair of double-quotes \fB""\fP in the
string is interpreted as ``expect nothing'';
that is, transmit the \fIsend\fR string regardless of what is received.
Empty double-quotes in the \fIsend\fR string
cause a lone `\er' (carriage return) to be sent.
One of the following keywords may be substituted for the
BREAK Generate a 3/10 second BREAK
BREAK\fIn\fP Generate an \fIn\fP/10 second BREAK
CR Send a Carriage Return (same as "").
EOT Send an End-Of-Transmission character, ASCII \e004.
Note that this will cause most hosts to hang up.
PAUSE Pause for 3 seconds.
PAUSE\fIn\fP Pause for \fIn\fR seconds.
P_ODD Use odd parity on future send strings.
P_ONE Use parity one on future send strings.
P_EVEN Use even parity on future send strings. (Default)
P_ZERO Use parity zero on future send strings.
string consists of the keyword
then the string following is used to arm an abort trap. If that string
is subsequently received any time prior to the completion of the entire
will abort, just as if the
script had timed out. This is useful for trapping error messages from
port selectors or front-end processors such as ``Host Unavailable'' or
"" "" ogin:--ogin: nuucp ssword: ufeedme
This is executed as, ``When the remote system answers,
the remote to transmit the string `ogin:'. If it doesn't
within 45 seconds, send another carriage return. When it finally does,
it the string `nuucp'. Then
the string `ssword:'; when that is received,
This file contains user accessibility information.
It specifies the file system directory trees that are accessible to
local users and to remote systems via UUCP
[\fIloginname\fP]\fB,\fP[\fIsitename\fP] [ \fBc\fP ] \fIpathname\fP \c
[\fIpathname\fP] [\fIpathname\fP]
The first two items are separated by a comma;
any number of spaces or tabs may separate the remaining items.
is a login name (from ``/etc/passwd'')
is the name of a remote machine,
this is the same name used in ``L.sys''.
The \fIc\fR denotes the optional \fIcallback\fR field.
If a \fBc\fP appears here,
a remote machine that calls in will be told that callback is requested,
and the conversation will be terminated.
The local system will then immediately call the remote host back.
is a pathname prefix that is permissible for this \fIloginname\fR
It accepts the pathnames on the first line that has a null
A line with both \fIloginname\fR and \fIsitename\fR are null,
can be used to conveniently specify the paths for both "no match" cases
if lines earlier in ``USERFILE'' did not define them.
Installing the UUCP system.
There are several source modifications that may be required
before the system programs are compiled.
Two files which may require modification,
the ``Makefile'' file and the ``uucp.h'' file.
The following paragraphs describe some of the options
The installer of UUCP may wish to change some of the defines in ``uucp.h'',
some of the interesting defines are mentioned below.
if \fBDIALINOUT\fR is defined then \fIacucntrl\fR will allow modems to be
If \fBDONTCOPY\fR is defined in ``uucp.h'',
\fIuucp\fR will not make a copy of the source file by default.
if \fBLOCKDIR\fR is defined then lock files
will be stored in the ``/usr/spool/uucp/LCK'' directory.
If \fBLOGBYSITE\fR is defined,
\fIuucp\fR logging is done with a log file per site,
If \fBNOSTRANGERS\fR is defined in ``uucp.h'',
the remote site must be in your ``L.sys'' or the call will be rejected.
variable definitions which may need modification.
where all the system will end up,
${DESTDIR}/usr/lib/uucp, low level binaries, site information, and dialing
information resides here.
${DESTDIR}/usr/bin, the user utilities reside here.
${DESTDIR}/usr/spool/uucppublic, uucp owns this directory.
A place where files can almost always be sent.
${DESTDIR}/usr/spool/uucp,
where all commands and data is held until transfers can take place.
${SPOOL}/XTMP, a place where UUCP executeable commands will be kept.
${SPOOL}/CORRUPT, where corrupted ``C.'' and ``D.'' files end up.
${SPOOL}/AUDIT, an audit trail.
${SPOOL}/LCK, a place to keep lock files.
${SPOOL}/STST, a place to keep ``STST'' files for different systems.
not counting XTMP, that may be built under SPOOL,
``C.'', ``D.\fIHOSTNAME\fRX'', ``D.\fIHOSTNAME\fR'', ``D.'', ``X.'', and ``TM.''.
will compile the entire system.
will build all the directories needed for the system,
giving them appropriate owners and permissions.
will install the commands in the correct directories,
setting ownership and permissions.
Connecting new systems to the network.
When first connecting a new machine to a UUCP network,
it is advisable to try and establish a connection with
\fItip\fR or \fIcu\fR first.
The administrator should then be 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 Chat dialogue in
Once a \fIlogin\fR connection can be completed the Admisitrator should
have enough information to allow the correct setup of the \fIsystem\fR files
The UUCP administrator should then
negociate with the remote site UUCP administrator
as to when and who will do polling.
The relevant accounts and passwords must be set up.
Decide on what permissions and security precausions are to be observed.
Arrange testing time and facilites to complete initial connection to the system.
The uucp system, left unrestricted,
will let any outside user execute any commands
and copy in/out any file which is readable/writable
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
(See the ``Files required for execution'' section
for the file description.)
A conversation sequence count can be set up so
can be more confident that the caller
program comes with a list of commands that it
A ``PATH'' shell statement is prepended to the command
The installer may modify the list or remove the
file should be owned by uucp and have mode 0400
to protect the phone numbers and login information
(Programs uucp, uucico, uux, uuxqt should be also
owned by uucp and have the setuid bit set.)
This section indicates some events and files which must be
Some administration can be accomplished by
which can be initiated by
Others will require manual intervention.
are given toward the end of this section.
SQFILE \- sequence check file
This file is set up in the
directory and contains an entry for each remote
system with which you agree 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, the entry will have to
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/copied to the requested destination.
If processing is abnormally terminated or the
move/copy fails, the file will remain in the
The leftover files should be periodically removed;
program is useful in this regard.
files older than three days.
During execution of programs, individual
directory with information about
queued requests, calls to remote systems,
commands and file copy results.
These files should be combined into the
This program will put the new
files at the beginning of the existing
will accomplish the merge.
Options are available to print some or all the
log entries after the files are merged.
should be removed periodically
since it is copied each time new LOG
entries are put into the file.
files are created initially with mode 0222.
If the program which creates the file terminates normally,
Aborted runs may leave the files with mode
program will not read or remove them.
To remove them, either use
or change the mode to 0666 and let
STST \- system status files
These files are created in the spool directory by the
They contain information of failures such as login, dialup or
sequence check and will contain a
status when to machines are conversing.
The form of the file name is
is the remote system name.
For ordinary failures (dialup, login), the file will prevent
repeated tries for about one hour.
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
Lock files are created for each device in use (e.g. automatic calling
unit) and each system conversing.
This prevents duplicate conversations and multiple attempts to use the
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 runs abort.
They will be ignored (reused) after a time of about 24 hours.
When runs abort and calls are desired before the time limit,
the lock files should be removed.
program will spool work and attempt to start the
program, but the starting of
(No devices available, login failures etc.).
program should be periodically started.
can be put in a ``shell'' file with a command to merge
files and started by a crontab entry on an hourly basis.
The file could contain the commands
Note that the ``\-r1'' option is required to start the
Another shell file may be set up on a daily basis to remove
files for work which can not be accomplished for
reasons like bad phone number, login changes etc.
A shell file containing commands like
Note the ``\-n12'' option causes the
files older than 12 hours to be deleted.
The absence of the ``\-n'' option will use a three day time
A daily or weekly shell should also be created
One can use a command like
mv spool/LOGFILE spool/o.LOGFILE
One or more logins should be set up for
Each of the ``/etc/passwd'' entries should
as the shell to be executed.
The login directory is normally ``/usr/spool/uucppublic''.
The various logins are used in conjunction with the
argument limits the login to the use of UUCP (\fIuucico\fP) only.
It is suggested that the owner and file modes of various
programs and files be set as follows.
login with the ``setuid'' bit set and only execute
permissions (e.g. mode 04111).
This will prevent outsiders from modifying the programs
directory should be owned by
login and set with mode 0400.
projects / unix-history / blob