Configuring UUCP: Version 2
This article discusses issues involved in configuring
Version 2 UUCP.
Although this version has been largely superseded by
BNU (Basic Networking
Utilities, also known as HoneyDanBer, or HDB) UUCP,
it is still found
on some older versions of UNIX.
I should point out that I've written this article using
personal notes, and the relevant documentation for reference,
no longer have access to a system which runs Version
2 UUCP. Also,
I refer occasionally to the article "UUCP: Administering
in the March/April 1993 issue of Sys Admin.
What Is Version 2 UUCP?
Version 2 UUCP was the first commercial release of UUCP
UNIX. To find out which UUCP release you have, look
If you find a file called L.sys, then you have Version
this article is for you. If you find Systems, then you'll
to refer to "UUCP: Administering BNU."
This discussion assumes the presence of two machines
a working modem or serial connection.
Version 2 UUCP's directory structure is similar to that
of HDB UUCP,
with most of the differences occurring at the file level.
shows the file layout, while Figure 2 lists the files
and gives a
brief description of the files' contents.
Naming Your Host
If your system consists only of a UUCP connection between
of machines, the names of the machines are of interest
only to the
system administrators involved. However, if you plan
to join Usenet,
you should contact the system administrator of your
Usenet feed so
that you can find out if your chosen system name has
used. (For more information on naming the host, see
issue of Sys Admin.)
To use Version 2 UUCP (hereafter referred to as V2),
you must configure
the following files to allow for a minimal UUCP network,
that allows you to initiate a call to a remote system
cu, or uucico.
The L-devices File
The L-devices file contains descriptions for the devices
uses to make connections to remote systems. An L-devices
look like this:
type device call-unit speed
ACU tty000 - 1200
The type field consists the type of link typically
used for this device. ACU (automatic call unit or modem)
and DIR (direct)
are usually the only types supported, but other types
may be supported,
depending upon the operating system version. For example,
supports types like TCP (TCP/IP) and PAD (X.25). Such
cases are rare,
however, as very few implementations of V2 support device
than ACU and DIR. Multiple entries of the same type
may be listed
in the file.
The device field holds the name of the physical device
to establish the link.
The call-unit field is used only on systems with a Bell
dialer and separate modem. In this case, you would enter
for the data line in the device field and enter the
the device as the dialer. Because dialers are not commonly
having been replaced with the "smart" modem,
the hyphen serves
as a place holder.
The speed field contains the connect speed for this
Testing the Connection
At this point in the configuration, it's a good idea
to evaluate the
continuity of the connection between your systems. To
do this, use
the cu command (located in /bin in V2). The syntax is
cu -l tty01
(substitute the appropriate device name in the command
line). If you get a connected message, then you can
attempt to log
in to the remote system. If, on the other hand, you
get an error message
such as "NO DEVICE AVAILABLE," or "REQUESTED
UNKOWN," then you must reconfigure the L-devices
Figure 3 shows a sample cu connection.
The L.sys File
The L.sys file is essentially the same as the Systems
file in HDB UUCP. The format of each entry in the file
system schedule device speed
xray Wk0800-1700 ACU 1200 5551234
The system field identifies the system this entry
is used to contact. Values entered in this field must
be unique to
schedule defines calling times for the remote system,
of a series of times and related keywords. This field
can be used
to control calling costs if the link is expensive. For
contents of this field may include:
Start-end -- The starting hour and the
ending hour using the 24-hour clock (0800 being 8:00
and 2000 being 8:00 P.M.).
Any -- No limit on calling.
Never -- No calling permitted.
Wk -- Calling restricted to weekdays (Monday
Mo,Tu,We,Th,Fr,Sa,Su -- Calling allowed
on specific days of the week.
You can combine these components to build a very restrictive
For example, to allow calling only between 8:00 A.M.
A.M. on Saturday and Sunday, then the appropriate entry
An optional retry subfield can be included after
the schedule field by adding a comma and a time period
uucico doesn't restart automatically after this time
instead, this is the delay period used after an unsuccessful
As noted earlier, the device type in V2 is restricted
to one of the
device types allowed in L-devices: ACU or DIR. When
is made to the remote system, the device entry is checked
device entries in the L-devices file. If there are multiple
entries for a device, the first available device is
The speed field contains the baud rate to be used when
the remote system. A corresponding entry for this speed
in the L-devices file.
The phone number field holds the number to be dialed
the remote system. If this entry is for a direct link
to a remote
system, this field contains a hyphen.
The balance of the entry consists of the chat script,
which is used
to negotiate the login to the remote system. The script
a series of expect-send sequences that define the login
required for access to the remote computer. The expect-send
pairs are separated by spaces; optional subexpect-subsend
Consider the following example:
login:-BREAK-login: nuucp word: loginAok
In this example, uucico expects the remote system
to print login:. If this doesn't occur within a predefined
period of time, the local system sends a BREAK signal
login:. The BREAK signal is a modem break, which may
a getty running on the remote system, or cause that
to switch to another speed. Once login: appears, the
system sends nuucp, and waits for the word: string.
When word: appears, the system sends loginAok, which
is the system password. When the script succeeds, the
has logged into the remote system.
The subexpect-subsend pairs, such as
login: nuucp word: loginAok
enable the local system to log in if the remote
system answers at a different speed from that used by
the local modem.
For example, if the local system is calling at 1200
baud and the
remote system answers at 2400 baud, it would be necessary
a BREAK twice, assuming that the related gettydefs entry
"go from 2400->300->1200." Therefore,
the chat script would
login:-BREAK-login:-BREAK-login: nuucp word: loginAok
The difference to note between the primary expect-send
and the subexpect-subsend is that the subexepect-subsend
will be used only if the expect string is not received.
uucico stops looking at the incoming characters once
is found for the expect text. However, it is commonplace
use the last text expected to ensure that the send sequence
sent to the remote system too soon.
Testing the Connection with uucico
Once the L-devices and L.sys files have been configured,
use the debug option on uucico to test communications.
uucico works essentially the same way for both Version
HDB. Once the call is initiated, uucico keeps track
process by creating a status file for the machine in
directory. The status file -- called STST. followed
name of the machine -- contains the details of the last
If the status file is present when the remote system
calls in, the
remote is notified that there is a LOCK file and the
dropped. If the status file is there when the local
system tries to
call out, the call is blocked, and a message is logged
a status file has prevented the call. The contents of
a status file
are shown in Figure 4.
The status part of the entry typically explains the
With a status file present, other jobs queued for the
can't make a call until the retry time period has expired.
this, you can remove the status file.
Version 2 Permissions
In HDB UUCP one file essentially controls access to
commands and to
files on your system. With V2, there are as many as
five files, with
three being the typical configuration. These files are
USERFILE controls access to the files on your system
remote and local users. A variety of sources recommend
for each entry in your /etc/passwd file, you create
in your USERFILE. Listing 1(a) shows a Bourne shell
to accomplish this, while Listing 1(b) shows the output
of the script.
Like the entries in the HDB Permissions files, each
entry defines a number of constraints for file transfer,
which files on the system can be accessed for UUCP by
a local user. Both USERFILE and UNIX file permissions
be satisfied for the request to succeed.
which files can be accessed by a remote system.
the login name the remote system must use when calling
callback configuration (the local machine calls the
remote back to confirm the remote's identity).
Not all constraints must be configured, but the fewer
the greater the risk of a security violation.
USERFILE entries consist of
username,system [c] pathname(s)
uu101,thumper /usr/spool/uucppublic /usr/tmp
uu102,bugs c /u/tmp
The username (uu101, uu102) defines
the name which must be used to log in to the local system.
must be configured in the /etc.passwd file, using a
system defines the name of the remote system.
The callback flag, shown as a single c with spaces on
either side, is similar to the CALLBACK option in HDB
If c appears after the system name, the local system
to a call from the remote system by hanging up the phone
the remote system back. This allows the local system
to validate the
identity of the remote system.
The pathname component is a space-delimited absolute-pathname
list of the directories accessible by the remote machine.
Unfortunately for the system administrator, USERFILE
is a complicated
beast, capable of causing many long nights in the office
(I know --
I've been there). A further complication is that the
same entry may
behave a little differently on different systems. Again
the only symptom of the problem is a loss of security,
isn't visible until you've already lost data on your
The following are aspects of UUCP's use of the USERFILE
when uucp and uux are run by users or
when uucico runs in Master mode, only the username portion
of the USERFILE entry is used.
when uucico runs in Slave mode, only the systemname
section of the entry is used (in the course of any conversation,
can switch between Slave and Master any number of times).
in any USERFILE for systems other than BSD 4.2,
and BSD 4.3, there must be one entry that doesn't have
a system name,
and one entry that doesn't have a username. In BSD 4.2
and 4.3, these
entries can be one and the same. The empty system name
entry is used
when uucico is in Slave mode and has already searched
and cannot find a matching entry. The empty username
entry is used
by uucp, uux, uuxqt, and uucico when in
Master mode, in the case where there is no matching
username in /etc/passwd.
The exact operation and use of USERFILE differs between
of UUCP, so you must examine carefully the documentation
your operating system.
Special USERFILE Entries
If no username is specified in the entry, as in
any user on the system may request outbound transfer
of any file on your system. If you prefer not to use
an entry like
this, then you must create an entry for every user on
To allow uuxqt file access while uucico is in Slave
mode, USERFILE must include an entry which has no system
This entry is used even when uuxqt is started
on your local system! Based on what I've said thus far,
expect that this entry would mean that any system logging
a username of nuucp will have access to /usr/spool/uucppublic.
In fact, this isn't exactly true, because only the system
used to validate file transfers requests when the local
is in Slave mode.
You can also grant individual users special access permissions
certain systems. You can then combine the system name
entry in the USERFILE file, but you should also have
system call in with its own login name and password,
as, for example,
uu101,thumper /usr/spool/uucppublic/ /usr/tmp /u/src
It is not uncommon to see entries that look like this:
With this arrangement, however, there is nothing to
someone from changing the name of their remote system
and then calling
yours. This problem arises because uucico doesn't use
name when in Slave mode. The best way to limit this
to set up individual UUCP login names for each of the
will be calling you.
The L.cmds File
The next component in the issue of security is remote
which is defined in the file L.cmds. Typically, the
restricts the commands that can be run by a remote system.
command in question is not listed in the L.cmds file,
execution of it via uux is denied. Usually, L.cmds contains
only one command: rmail.
The L.cmds on my system contains the following entries:
which indicate that both the rmail and uucico
commands may be executed by uux. Be careful about which
you add to this file. Even some seemingly innocuous
cat, can be dangerous to your system.
Finally, there is SQFILE, which is used to keep track
conversations that have taken place between your machines.
an optional file, so if you want to use conversation
counts, you must
create it in /usr/lib/uucp. SQFILE must be owned by
uucp, and must have a file mode of 400. SQFILE must
contain an entry for each file for which you want conversations
The remote system must also be configured to use SQFILE.
Once the file is created, edit it to include the names
of the files
you want to monitor, one system per line. After the
first call, uucico
adds the the number of conversations, and the date and
time of the
When one system calls the other, uucico compares the
information on the two systems; if they don't agree,
then the login
fails. The log files on the calling system contain a
that there is a SEQ number problem. To correct this,
the two system
administrators must edit the files manually.
The log files for V2 are quite different from those
of HDB. Unlike
HDB, V2 places all of the log entries in a single file,
in /usr/spool/uucp. A second file, called SYSLOG, records
the actual amount of data transferred and the time it
took to do it.
LOGFILE will grow continously, so if you are running
of disk space, this is the first place you should look.
An entry from LOGFILE looks like
user system date/time comment
root unilabs (2/12-5:42) NO (AVAILABLE DEVICE)
root unilabs (2/12-5:42) FAILED (call to unilabs)
root unilabs (2/12-5:59) QUEUED (C.unilabsn0297)
root unilabs (2/12-5:59) QUEUED (C.unilabsn0298)
root unilabs (2/12-5:59) SUCCEEDED (call to unilabs)
root unilabs (2/12-5:59) HANDSHAKE FAILED (LOGIN)
unilabs unilabs (2/12-18:35) OK (startup)
The next few entries show that the files /tmp/spool
and /tmp/sys were S (sent) to unilabs:
root unilabs (2/12-18:35) REQUEST (S /tmp/spool ~ root)
root unilabs (2/12-18:35) REQUEST (SUCCEEDED)
root unilabs (2/12-18:35) REQUEST (S /tmp/sys ~ root)
root unilabs (2/12-18:35) REQUEST (SUCCEEDED)
root unilabs (2/12-18:35) OK (conversation complete)
These log entries don't contain the same information
as those in HDB, but the second log file, SYSLOG, provides
the remaining information. SYSLOG contains information
the actual transfer. The first examples here show that
received the data from the remote machine, unilabs.
user system date/time secs comments
chare unilabs (11/21-22:56) (722404580) received data \ 148 bytes 2 secs
chare unilabs (11/21-22:56) (722404593) received data \ 1197 bytes 6 secs
chare unilabs (11/21-22:56) (722404601) received data \ 148 bytes 1 secs
The next entries relate to the two files shown as transfered
in the LOGFILE: /tmp/sys, and /tmp/spool. These
two files were sent from bugs to unilabs.
root unilabs (2/12-18:35) (729560123) sent data 97
bytes 0 secs
root unilabs (2/12-18:35) (729560125) sent data 115
bytes 0 secs
Maintenance for Version 2 is simplified somewhat through
the use of
the uuclean command, which operates quite similarly
uuclean is used to clean up the UUCP spool directory
typically) in a somewhat intelligent way. For systems
be reached, uuclean sends a mail message back to the
deletes locally created rnews files, executes remotely
rnews files, and removes everything which shouldn't
The main additional maintenance required is to periodically
the logfiles, so that they won't consume your available
with redundant UUCP log information.
V2 UUCP is no longer in wide use, as it has been superseded
more easily configured, maintained, and modified HDB
UUCP. If you
do use it, however, be sure to refer to your system
as each vendor does things a bit differently. In addition,
recommend that you add one or more books (such as those
on the configuration and administration of UUCP.
For more reading on UUCP, I suggest the following books,
some of which
were used as references for this series.
Todino, Grace. Using UUCP and USENET. Sebastopol,
O'Reilly and Associates, 1989.
Todino, Grace, and Tim O'Reilly. Managing UUCP
and USENET. Sebastopol, CA: O'Reilly and Associates,
Anderson, Costales, Henderson. UNIX Communications.
Corte Madera, CA: The Waite Group, 1988.
Thomas, Rebecca, and Rik Farrow. UNIX Administration
Guide for System V. Englewood Cliffs, NJ: Prentice-Hall,
Farrow, Rik. UNIX System Security. Reading,
MA: Addison-Wesley, 1991.
About the Author
Chris Hare is Ottawa Technical Services Manager for
Choreo Systems, Inc.
He has worked in the UNIX environment since 1986 and
in 1988 became one of
the first SCO authorized instructors in Canada. He teaches
system administration, and programming classes. His
current focus is on
networking, Perl, and X. Chris can be reached at firstname.lastname@example.org,
email@example.com, which is his home.