Info file uucp.info, produced by Makeinfo, -*- Text -*- from input
This file documents Taylor UUCP, version 1.03.
Copyright (C) 1992 Free Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the section entitled "Copying" are included exactly as in the
original, and provided that the entire resulting derived work is
distributed under the terms of a permission notice identical to this
Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the section entitled "Copying" may be included
in a translation approved by the author instead of in the original
File: uucp.info, Node: Top, Next: Copying, Prev: (dir), Up: (dir)
This is the documentation for the Taylor UUCP package, version 1.03.
The programs were written by Ian Lance Taylor. The author can be
reached at `<ian@airs.com>', or, equivalently, `<uunet!airs!ian>', or
`c/o Infinity Development, P.O. Box 520, Waltham MA, 02254'.
There is a mailing list for discussion of the package. To join the
list, send a message to `<taylor-uucp-request@gnu.ai.mit.edu>'. Make
sure you include the address you want to receive messages at; do not
rely on the `From:' header. To send a message to the list, send it to
`<taylor-uucp@gnu.ai.mit.edu>'.
* Copying:: Taylor UUCP copying conditions
* Introduction:: Introduction to Taylor UUCP
* Overall Installation:: Taylor UUCP installation
* Configuration Files:: Taylor UUCP configuration files
* Protocols:: UUCP protocol internals
* Hacking:: Hacking Taylor UUCP
* Acknowledgements:: Acknowledgements
* Index (concepts):: Concept index
* Index (configuration file):: Index to new configuration files
-- The Detailed Node Listing --
Taylor UUCP Overall Installation
* Configuration:: Configuring Taylor UUCP
* Compilation:: Compiling Taylor UUCP
* Testing:: Testing Taylor UUCP
* Installation:: Installing Taylor UUCP
* Usage:: Using Taylor UUCP
* TCP:: TCP together with Taylor UUCP
Taylor UUCP Configuration Files
* Configuration File Format:: Configuration file format
* Configuration Examples:: Examples of configuration files
* Time Strings:: How to write time strings
* Chat Scripts:: How to write chat scripts
* config File:: The main configuration file
* sys File:: The system configuration file
* port File:: The port configuration files
* dial File:: The dialer configuration files
* Security:: Security issues
Examples of Configuration Files
* config File Examples:: Examples of the main configuration file
* Leaf Example:: Call a single remote site
* Gateway Example:: The gateway for several local systems
The Main Configuration File
* Miscellaneous (config):: Miscellaneous config file commands
* Configuration File Names:: Using different configuration files
* Log File Names:: Using different log files
* Debugging Levels:: Debugging levels
The System Configuration File
* Defaults and Alternates:: Using defaults and alternates
* Naming the System:: Naming the system
* Calling Out:: Calling out
* Accepting a Call:: Accepting a call
* Protocol Selection:: Protocol selection
* File Transfer Control:: File transfer control
* Miscellaneous (sys):: Miscellaneous sys file commands
* Default sys File Values:: Default values
* When to Call:: When to call
* Placing the Call:: Placing the call
* Logging In:: Logging in
* Lock Files:: UUCP lock file format
* UUCP Protocol:: The common UUCP protocol
* g Protocol:: The UUCP `g' protocol
* f Protocol:: The UUCP `f' protocol
* t Protocol:: The UUCP `t' protocol
* e Protocol:: The UUCP `e' protocol
* x Protocol:: The UUCP `x' protocol
* d Protocol:: The UUCP `d' protocol
* Capital G Protocol:: The UUCP `G' protocol
* Documentation References:: Documentation references
* Initial Handshake:: Initial handshake
* File Requests:: File requests
* Final Handshake:: Final handshake
* System Dependence:: System Dependence
* Naming Conventions:: Naming Conventions
File: uucp.info, Node: Copying, Next: Introduction, Prev: Top, Up: Top
Taylor UUCP Copying Conditions
******************************
This package is covered by the GNU Public License. See the file
`COPYING' for details. If you would like to do something with this
package that you feel is reasonable but you feel is prohibited by the
license, contact me to see if we can work it out.
Here is some propaganda from the Free Software Foundation. If you
find this stuff offensive or annoying, remember that you probably did
not spend any money to get this code. I did not write this code to
make life easier for developers of UUCP packages, I wrote it to help
end users, and I believe that these are the most appropriate
conditions for distribution.
All the programs, scripts and documents relating to Taylor UUCP are
"free"; this means that everyone is free to use them and free to
redistribute them on a free basis. The Taylor UUCP-related programs
are not in the public domain; they are copyrighted and there are
restrictions on their distribution, but these restrictions are designed
to permit everything that a good cooperating citizen would want to do.
What is not allowed is to try to prevent others from further sharing
any version of these programs that they might get from you.
Specifically, we want to make sure that you have the right to give
away copies of the programs that relate to Taylor UUCP, that you
receive source code or else can get it if you want it, that you can
change these programs or use pieces of them in new free programs, and
that you know you can do these things.
To make sure that everyone has such rights, we have to forbid you to
deprive anyone else of these rights. For example, if you distribute
copies of the Taylor UUCP related programs, you must give the
recipients all the rights that you have. You must make sure that
they, too, receive or can get the source code. And you must tell them
Also, for our own protection, we must make certain that everyone
finds out that there is no warranty for the programs that relate to
Taylor UUCP. If these programs are modified by someone else and
passed on, we want their recipients to know that what they have is not
what we distributed, so that any problems introduced by others will
not reflect on our reputation.
The precise conditions of the licenses for the programs currently
being distributed that relate to Taylor UUCP are found in the General
Public Licenses that accompany them.
File: uucp.info, Node: Introduction, Next: Overall Installation, Prev: Copying, Up: Top
Introduction to Taylor UUCP
***************************
General introductions to UUCP are available, and perhaps one day I
will write one. In the meantime, here is a very brief one that
concentrates on the programs provided by Taylor UUCP.
Taylor UUCP is a complete UUCP package. It is covered by the GNU
Public License, which means that the source code is always available.
It is composed of several programs, the names of which were
established by earlier UUCP packages.
The `uucp' program is used to copy file between systems. It is
similar to the standard Unix `cp' program, except that you can
refer to a file on a remote system by using `system!' before the
file name. For example, to copy the file `notes.txt' to the
system `airs', you would say `uucp notes.txt airs!~/notes.txt'.
In this example `~' is used to name the UUCP public directory on
The `uux' program is used to request a program to be executed on a
remote system. This is how mail and news are transferred over
UUCP. As with `uucp', programs and files on remote systems may
be named by using `system!'. For example, to run the `rnews'
program on `airs' passing it standard input, you would say `uux -
airs!rnews'. The `-' means to read standard input and set things
up so that when `rnews' runs on `airs' it will receive the same
Neither `uucp' nor `uux' actually do any work immediately.
Instead, they queue up requests for later processing. They then start
a daemon process which processes the requests and calls up the
appropriate systems. Usually the daemon will also be started
regularly to check if there is any work to be done and to do it. The
advantage of this system is that it all happens automatically. You
don't have to sit around waiting for the files to be transferred. The
disadvantage is that if anything goes wrong it might be a while before
The `uustat' program does several things. By default it will
simply list all the jobs you have queued with `uucp' or `uux'
that have not yet been processed. You can use `uustat' to remove
any of your jobs from the queue. You can also it use it to show
the status of the UUCP system in various ways, such as showing the
connection status of all systems your system knows about.
The `uuname' program by default lists all the remote systems your
system knows about. You can also use it to get the name of your
local system. It is mostly useful for shell scripts.
The `uulog' program can be used to display entries in the UUCP log
file. It can select the entries for a particular system or a
particular user. You can use it to see what has happened to your
These five programs just described, `uucp', `uux', `uustat',
`uuname', and `uulog', are the user programs provided by Taylor UUCP.
The first two add requests to the work queue, the third examines the
work queue, the fourth examines the configuration files, and the last
examines the log files. The real work is actually done by two daemon
processes, which are normally run automatically rather than by a user.
The `uucico' daemon is the program which actually calls the remote
system and transfers files and requests. `uucico' is normally
started automatically by `uucp' and `uux'. Most systems will
also start it periodically to make sure that all work requests are
handled. `uucico' checks the queue to see what work needs to be
done, and then calls the appropriate systems. If the call fails,
perhaps because the phone line is busy, `uucico' leaves the
requests in the queue and goes on to the next system to call. It
is also possible to force `uucico' to call a remote system even if
there is no work to be done for it, so that it can pick up any
work that may be queued up remotely.
The `uuxqt' daemon processes execution requests made by the `uux'
program on remote systems. It also processes requests made on
the local system which require files from a remote system. It is
normally started by `uucico'.
Suppose you, on the system `bantam', want to copy a file to the
system `airs'. You would run the `uucp' command locally, with a
command like `uucp notes.txt airs!~/notes.txt'. This would queue up a
request on `bantam' for `airs', and would then start the `uucico'
daemon. `uucico' would see that there was a request for `airs' and
attempt to call it. When the call succeeded, another copy of `uucico'
would be started on `airs'. The two copies of `uucico' would tell
each other what they had to do and transfer the file from `bantam' to
`airs'. When the file transfer was complete the `uucico' on `airs'
would move it into the UUCP public directory.
UUCP is often used to transfer mail. This is normally done
automatically by mailer programs. When `bantam' has a mail message to
send to `ian' at `airs', it executes `uux - airs!rmail ian' and writes
the mail message to the `uux' process as standard input. The `uux'
program, running on `bantam', will read the standard input and store
it and the `rmail' request on the work queue for `airs'. `uux' will
then start the `uucico' daemon. The `uucico' daemon will call up
`airs', just as in the `uucp' example, and transfer the work request
and the mail message itself. The `uucico' daemon on `airs' will put
the files on a local work queue. When the communication session is
over, the `uucico' daemon on `airs' will start the `uuxqt' daemon.
`uuxqt' will see the request to run, and will run `rmail ian' with the
mail message as standard input. The `rmail' program, which is not
part of the UUCP package, is then responsible for either putting the
message in the right mailbox on `airs' or forwarding the message on to
Taylor UUCP comes with two other programs that are useful when
installing and configuring UUCP.
The `uuchk' program reads the UUCP configuration files and
displays a rather lengthy description of what it finds. This is
very useful when configuring UUCP to make certain that the UUCP
package will do what you expect it to do.
The `tstuu' program is a test harness for the UUCP package, which
will help ensure that it has been configured and compiled
correctly. It does not test everything, however, and it only
runs on Unix systems which support Berkeley style
pseudo-terminals. It can be useful when initially installing
File: uucp.info, Node: Overall Installation, Next: Configuration Files, Prev: Introduction, Up: Top
Taylor UUCP Overall Installation
********************************
These are the installation instructions for the Taylor UUCP package.
* Configuration:: Configuring Taylor UUCP
* Compilation:: Compiling Taylor UUCP
* Testing:: Testing Taylor UUCP
* Installation:: Installing Taylor UUCP
* Usage:: Using Taylor UUCP
* TCP:: TCP together with Taylor UUCP
File: uucp.info, Node: Configuration, Next: Compilation, Prev: Overall Installation, Up: Overall Installation
You will have to decide what types of configuration files you want
to use. This package supports a new sort of configuration file; *Note
Configuration files::. It also supports V2 configuration files
(`L.sys', `L-devices', etc.) and BNU configuration files (`Systems',
`Devices', etc.). No documentation is provided for V2 or BNU
configuration files. All types of configuration files can be used at
once, if you are so inclined. Currently using just V2 configuration
files is not really possible, because there is no way to specify a
dialer (there are no built in dialers, and the program does not know
how to read `acucap' or `modemcap'); however, V2 configuration files
can be used with a new style dialer file (*note dial file::.), or with
Use of BNU configuration files has two known bugs. A blank line in
the middle of an entry in the `Permissions' file will not be ignored as
it should be. Dialer programs are not recognized directly. If you
must use a dialer program, rather than an entry in `Devices', you must
use the `chat-program' command in a new style dialer file; see *Note
dial file::. You will have to invoke the dialer program via a shell
script, since an exit code of 0 is required to recognize success.
If you are installing a new system, or you want to use the new form
of configuration files, you must write the configuration files.
You must also decide what sort of spool directory you want to use.
If you will only be using these programs, I recommend
`SPOOLDIR_TAYLOR'; otherwise select the spool directory corresponding
to your existing UUCP package. The details of the spool directory
choices are described at somewhat tedious length in `sys3.unx'.
File: uucp.info, Node: Compilation, Next: Testing, Prev: Configuration, Up: Overall Installation
1. Take a look at the top of `Makefile.in' and set the appropriate
values for your system. These control where the program is
installed and which user on the system owns them (normally they
will be owned by a special user `uucp' rather than a real person;
they should probably not be owned by `root').
2. Run the shell script `configure'. This script was generated using
David MacKenzie's `autoconf' program. It takes a while to run.
It will generate a file `conf.h', and copy `Makefile.in' to
`Makefile' with substitions (specifically, it will replace all
words between `@' characters in `Makefile.in').
You can pass certain arguments to `configure' in the
environment. Because `configure' will compile and run little
test programs to see what is available on your system, you must
tell it how to run your compiler. It recognizes the following
The C compiler. If this is not set, then if `configure' can
find `gcc' it will use `gcc -O', otherwise it will use `cc'.
Flags to pass the C compiler during configuration testing.
If this is not set, `configure' will use the empty string.
Flags to pass to the C compiler when compiling the actual
code. If this is not set, `configure' will use `-g'.
Flags to pass to the C compiler when only linking, not
compiling. If this is not set, `configure' will use the
Libraries to pass to the C compiler. If this is not set,
`configure' will use the empty string.
The program to run to install UUCP in the binary directory.
If `configure' finds the BSD `install' program, it will set
this to `install -c'; otherwise, it will use `cp'.
The program to run to install UUCP data files, such as the
man pages and the info pages. If `configure' finds the BSD
`install' program, it will set this to `install -c -m 644';
otherwise, it will use `cp'.
Suppose you want to set the environment variable `CC' to
`rcc'. If you are using `sh' or `bash', invoke `configure' as
`CC=rcc configure'. If you are using `csh', do `setenv CC rcc;
On some systems you will want to use `LIBS=-lmalloc'. On some
you will want `LIBS=-lsocket'. On Xenix derived systems do not
use `LIBS=-lx' because this will bring in the wrong versions of
certain routines; if you want to use `-lx' you must specify
If `configure' fails for some reason, or if you have a very
wierd system, you may have to configure the package by hand. To
do this, copy the file `conf.h-dist' to `conf.h' and edit it for
your system. Then copy `Makefile.in' to `Makefile', find the
words within `@' characters, and set them correctly for your
3. You should verify that `configure' worked correctly by checking
the files `conf.h' and `Makefile'.
4. This package uses the `alloca' function. The `configure' script
will try to figure out how to make it work on your system. If
`alloca' cannot be found, a simplistic substitute from `alloca.c'
will be used. If you provide your own `alloca.o' file, it will
be used instead; you might, for example, use the one from the GNU
emacs distribution. If none of this makes any sense to you,
don't worry; everything will probably work fine.
5. Edit `policy.h' for your local system. The comments should
explain the various choices. The default values are intended to
be reasonable, so you may not have to make any changes.
6. Type `make' to compile everything. You may get warnings about
implicit function declarations; ignore these (if you think they
can be eliminated, and you really know what you are talking
about, you may tell me about them). You may also get warnings
about `getopt.c' (this is from the GNU library and I do not want
to change it) and about a variable not protected from `setjmp' in
`sys2.c' (the data flow ensures that this can never be a
problem). The `tstuu.c' file is not particularly portable; if
you can't figure out how to compile it you can safely ignore it,
as it is only used for testing. If you have any other problems
there is probably a bug in the `configure' script.
7. Please report any problems you have. That is the only way they
will get fixed for other people. Supply a patch if you can, or
File: uucp.info, Node: Testing, Next: Installation, Prev: Compilation, Up: Overall Installation
This package is in use at many sites, and has been running at
`airs.com' for several months. However, it will doubtless fail in
some situations. Do not rely on this code until you have proven to
yourself that it will work.
You can use the `uuchk' program to test your configuration files.
It will read them and print out a verbose description. This is
particularly important if you are using V2 or BNU configuration files,
because there may be bugs in how they are read. This program should
not be made suid, because it will display passwords if it can read
If your system supports BSD style pseudo-terminals, and you
compiled the code to support the new style of configuration files, you
should be able to use the `tstuu' program to test the `uucico' daemon.
Just type `tstuu' with no arguments while logged in to the compilation
directory (since it runs `./uucp', `./uux' and `./uucico') to run a
lengthy series of tests (it takes over ten minutes on a slow VAX).
You will need a fair amount of space available in `/usr/tmp'. You
will probably want to put it in the background. Do not use `^Z',
because the program traps on `SIGCHLD' and winds up dying. It will
create a directory `/usr/tmp/tstuu' and fill it with configuration
files, and create spool directories `/usr/tmp/tstuu/spool1' and
The program will finish with an execute file `X.SOMETHING' and a
data file `D.SOMETHING' in `/usr/tmp/tstuu/spool1' (or, more likely,
in subdirectories, depending on the choice of `SPOOLDIR' in
`sysdep.h'). The log files `/usr/tmp/tstuu/Log1' and
`/usr/tmp/tstuu/Log2' (or, if you have selected `HAVE_BNU_LOGGING',
`/usr/tmp/tstuu/Log1/uucico/test2' and
`/usr/tmp/tstuu/Log2/uucico/test1') should look fairly normal. You
can test `uuxqt' by typing `./uuxqt -I /usr/tmp/tstuu/Config1'. This
should leave a command file `C.SOMETHING' and a data file
`D.SOMETHING' in `/usr/tmp/tstuu/spool1' or in subdirectories. Again,
there should be no errors in the log file.
Assuming you compiled the code with debugging enabled, the `-x'
switch can be used to set debugging modes; see the `debug' command for
details (*note Debugging Levels::.). Use `-x all' to turn on all
debugging and generate far more output than you will ever want to see.
The `uucico' daemons will put debugging output in
`/usr/tmp/tstuu/Debug1' and `/usr/tmp/tstuu/Debug2'. At this point
you're pretty much on your own.
On some systems you can also use `tstuu' to test my `uucico'
against the system `uucico', by using the `-u' switch. For this to
work, change the definitions of `ZUUCICO_CMD' and `UUCICO_EXECL' at
the top of `tstuu.c' to something appropriate for your system. The
definitions in `tstuu.c' are what I used for Ultrix 4.0, in which
`/usr/lib/uucp/uucico' is particularly obstinate about being run as a
child; I was only able to run it by creating a login name with no
password whose shell was `/usr/lib/uucp/uucico'. Calling login in
this way will leave fake entries in `wtmp' and `utmp'; if you compile
`tstout.c' (in the `contrib' directory) as an suid `root' program,
`tstuu' will run it to clear those entries out. On most systems, such
hackery should not be necessary, although on SCO I had to su to `root'
(`uucp' might also have worked) before I could run
You can test `uucp' and `uux' (give them the `-r' switch to keep
them from starting `uucico') to make sure they create the right sorts
of files. Unfortunately if you don't know what the right sorts of
files are I'm not going to tell you here.
If `tstuu' passes, or you can't run it for some reason or other,
move on to testing with some other system. Set up the configuration
files (*note Configuration files::.), or use an existing configuration.
Tell `uucico' to dial out to the system by using the `-s' system
switch (e.g. `uucico -s uunet'). The log file should tell you what
If you compiled the code with debugging enabled, you can use
debugging mode to get a great deal of information about what sort of
data is flowing back and forth; the various possibilities are
described under the `debug' command (*note Debugging Levels::.). When
initially setting up a connection `-x chat' is probably the most
useful (e.g. `uucico -s uunet -x chat'); you may also want to use `-x
handshake,incoming,outgoing'. You can use `-x' multiple times on one
command line, or you can give it comma separated arguments as in the
last example. Use `-x all' to turn on all possible debugging
information. The debugging information is written to a file, normally
`/usr/spool/uucp/Debug' although the default can be changed in
`policy.h' and the configuration file can override the name with the
`debugfile' command. The debugging file may contain passwords and
some file contents as they are transmitted over the line, so the
debugging file is only readable by the `uucp' user.
You can use the `-f' switch to force `uucico' to call out even if
the last call failed recently; using `-S' when naming a system has the
same effect. Otherwise the status file (in the `.Status' subdirectory
of the main spool directory, normally `/usr/spool/uucp') will prevent
too many attempts from occurring in rapid succession.
Again, let me know about any problems you have and how you got
File: uucp.info, Node: Installation, Next: Usage, Prev: Testing, Up: Overall Installation
You can install by suing to `root' and typing `make install'. Or
you can look at what make install does and do it by hand. It tries to
preserve your old programs, if any. You can retrieve them by typing
File: uucp.info, Node: Usage, Next: TCP, Prev: Installation, Up: Overall Installation
This package does not come with any fancy shell scripts or
scheduling programs. Maybe someday. If you have another package, you
may well be able to use the scheduling mechanisms it provides.
Otherwise, the program can be used by making crontab entries.
Whenever you want to call all systems with outstanding work, use
Whenever you want to call a specific system `foo', use
If you want to make sure that a system foo gets retried if the
original call fails, create an empty work file for it. For example,
if using `SPOOLDIR_TAYLOR',
touch /usr/spool/uucp/foo/C./C.A0000
If using `SPOOLDIR_BNU', use
touch /usr/spool/uucp/foo/C.fooA0000
I use the following crontab entries locally:
45 * * * * /bin/echo /usr/lib/uucp/uucico -r1 | /bin/su uucpa
40 4,10,15 * * * touch /usr/spool/uucp/uunet/C./C.A0000
Every hour, at 45 minutes past, this will check if there is any
work to be done. Also, at 4:40am, 10:40am and 3:40pm this will create
an empty work file for `uunet', forcing the next check to call `uunet'.
You will also want to periodically trim the log files, which by
default are `/usr/spool/uucp/Log' and `/usr/spool/uucp/Stats'. The
`savelog' program in the `contrib' directory may be of use.
File: uucp.info, Node: TCP, Prev: Usage, Up: Overall Installation
TCP together with Taylor UUCP
=============================
If your system has a Berkeley style socket library, you can compile
the code to permit making connections over TCP. Specifying that a
system should be reached via TCP is easy, but nonobvious.
If you are using the new style configuration files, see *Note
Configuration files::. Basically, you can just add the line `port
type tcp' to the entry in the system configuration file. By default
UUCP will get the port number by looking up `uucp' in `/etc/services';
if `uucp' is not found, port 540 will be used. You can set the port
number to use with the command `port service XXX', where XXX can be
either a number or a name to look up in `/etc/services'. You can
specify the address of the remote host with `address A.B.C'; if you
don't give an address, the remote system name will be used. You
should give an explicit chat script for the system when you use TCP;
the default chat script begins with a carriage return, which will not
work with some UUCP TCP servers.
If you are using V2 configuration files, add a line like this to
foo Any TCP uucp foo.domain chat-script
This will make an entry for system foo, to be called at any time,
over TCP, using port number `uucp' (as found in `/etc/services'; this
may be specified as a number), using remote host `foo.domain', with
If you are using BNU configuration files, add a line like this to
foo Any TCP - foo.domain chat-script
and a line like this to Devices:
You only need one line in Devices regardless of how many systems you
contact over TCP. This will make an entry for system foo, to be called
at any time, over TCP, using port number `uucp' (as found in
`/etc/services'; this may be specified as a number), using remote host
`foo.domain', with some chat script.
The `uucico' daemon can also be run as a TCP server. This code
mostly works, but it's not perfect. I don't recommend investigating it
unless you are willing to tinker a bit. You will not be able to use
the default port number because `uucico' will not be running as `root'
and will therefore not be able to bind a reserved port.
Basically, you must define a port, either using the port file
(*note port file::.) if you are using the new configuration method or
with an entry in Devices if you are using BNU; there is no way to
define a port using V2. If you are using BNU the port must be named
`TCP'; a line as shown above will suffice. You can then start
`uucico' as `uucico -p TCP' (after the `-p', name the port; in BNU it
must be `TCP'). This will wait for incoming connections, and fork off
a child for each one. Each connection will be prompted with `login:'
and `Password:'; the results will be checked against the UUCP (not the
system) password file (*note Configuration File Names::.). Of course,
you can get a similar effect by using the BSD `uucpd' program.
You can also have `inetd' start up `uucico' with the `-l' switch,
which will cause it to prompt with `login:' and `Password:' and check
the results against the UUCP (not the system) password file. This may
be used in place of `uucpd'.
File: uucp.info, Node: Configuration Files, Next: Protocols, Prev: Overall Installation, Up: Top
Taylor UUCP Configuration Files
*******************************
This chapter describes the configuration files accepted by the
Taylor UUCP package if compiled with `HAVE_TAYLOR_CONFIG' defined in
The configuration files are normally found in the directory
NEWCONFIGDIR, which is defined by the `Makefile' variable
`newconfigdir'; by default NEWCONFIGDIR is `/usr/local/lib/uucp'.
However, the main configuration file, `config', is the only one which
must be in that directory, since it may specify a different location
for any or all of the other files. You may run any of the UUCP
programs with a different main configuration file by using the `-I'
option; this can be useful when testing a new configuration. When you
use the `-I' option the programs will revoke their setuid privileges.
* Configuration File Format:: Configuration file format
* Configuration Examples:: Examples of configuration files
* Time Strings:: How to write time strings
* Chat Scripts:: How to write chat scripts
* config File:: The main configuration file
* sys File:: The system configuration file
* port File:: The port configuration files
* dial File:: The dialer configuration files
* Security:: Security issues
File: uucp.info, Node: Configuration File Format, Next: Configuration Examples, Prev: Configuration Files, Up: Configuration Files
Configuration File Format
=========================
All the configuration files follow a simple line-oriented `KEYWORD
VALUE' format. Empty lines are ignored, as are leading spaces; unlike
BNU, lines with leading spaces are read. The first word on each line
is a keyword. The rest of the line is interpreted according to the
keyword. Most keywords are followed by numbers, boolean values or
simple strings with no embedded spaces.
The `#' character is used for comments. Everything from a `#' to
the end of the line is ignored unless the `#' is preceded by a `\'
(backslash); if the `#' is preceeded by a `\', the `\' is removed but
the `#' remains in the line. This can be useful for a phone number
containing a `#'. To enter the sequence `\#', you would use `\\#'.
The backslash character may be used to continue lines. If the last
character in a line is a backslash, the backslash is removed and the
line is continued by the next line. The second line is attached to the
first with no intervening characters; if you want any whitespace
between the end of the first line and the start of the second line,
you must insert it yourself.
However, the backslash is not a general quoting character. For
example, you cannot use it to get an embedded space in a string
Everything after the keyword must be on the same line. A BOOLEAN
may be specified as `y', `Y', `t', or `T' for true and `n', `N', `f',
or `F' for false; any trailing characters are ignored, so `true',
`false', etc., are also acceptable.
File: uucp.info, Node: Configuration Examples, Next: Time Strings, Prev: Configuration File Format, Up: Configuration Files
Examples of Configuration Files
===============================
All the configuration commands are explained in the following
sections. However, I'll start by giving a few examples of
configuration files. For a more complete description of any of the
commands used here see the appropriate section of this chapter.
* config File Examples:: Examples of the main configuration file
* Leaf Example:: Call a single remote site
* Gateway Example:: The gateway for several local systems
File: uucp.info, Node: config File Examples, Next: Leaf Example, Prev: Configuration Examples, Up: Configuration Examples
To start with, here are some examples of uses of the main
configuration file, `config'. For a complete description of the
commands that are permitted in `config', see *Note config file::.
In many cases you will not need to create a `config' file at all.
The most common reason to create one is to give your machine a special
UUCP name. Other reasons might be to change the UUCP spool directory
or to permit any remote system to call in.
If you have an internal network of machines, then it is likely that
the internal name of your UUCP machine is not the name you want to use
when calling other systems. For example, here at `airs.com' our
mail/news gateway machine is named `elmer.airs.com' (it is one of
several machines all named `LOCALNAME.airs.com'). If we did not
provide a `config' file, then our UUCP name would be `elmer'; however,
we actually want it to be `airs'. Therefore, we use the following
The UUCP spool directory name is set in `policy.h' when the code is
compiled. You might at some point decide that it is appropriate to
move the spool directory, perhaps to put it on a different disk
partition. You might use the following commands in `config' to change
to directories on the partition `/uucp':
debugfile /uucp/spool/Debug
You would then move the contents of the current spool directory to
`/uucp/spool'. If you do this, make sure that no UUCP processes are
running while you change `config' and move the spool directory.
Suppose you wanted to permit any system to call in to your system
and request files. This is generally known as "anonymous UUCP", since
the systems which call in are effectively anonymous. By default,
unknown systems are not permitted to call in. To permit this you must
use the `unknown' command in `config'. The `unknown' command is
followed by any command that may appear in the system file; for full
details, see *Note sys file::.
I will show two possible anonymous UUCP configurations. The first
will let any system call in and download files, but will not permit
them to upload files to your system.
# No files may be transferred to this system
# The public directory is /usr/spool/anonymous
unknown pubdir /usr/spool/anonymous
# Only files in the public directory may be sent (the default anyhow)
Setting the public directory is convenient for the systems which call
in. It permits to request a file by prefixing it with `~/'. For
example, assuming your system is known as `server', then to retrieve
the file `/usr/spool/anonymous/INDEX' a user on a remote site could
just enter `uucp server!~/INDEX ~'; this would transfer `INDEX' from
`server''s public directory to the user's local public directory.
Note that when using `csh' or `bash' the `!' and the second `~' must
The next example will permit remote systems to upload files to a
special directory `/usr/spool/anonymous/upload'. Permitting a remote
system to upload files permits it to send work requests as well; this
example is careful to prohibit commands from unknown systems.
# No commands may be executed (the list of permitted commands is empty)
# The public directory is /usr/spool/anonymous
unknown pubdir /usr/spool/anonymous
# Only files in the public directory may be sent; users may not download
# files from the upload directory
unknown remote-send ~ !~/upload
# May only upload files into /usr/spool/anonymous/upload
unknown remote-receive ~/upload
File: uucp.info, Node: Leaf Example, Next: Gateway Example, Prev: config File Examples, Up: Configuration Examples
A relatively common simple case is a "leaf site", a system which
only calls or is called by a single remote site. Here is a typical
`sys' file that might be used in such a case. For full details on
what commands can appear in the `sys' file, see *Note sys file::.
This is the `sys' file that is used at `airs.com'. We use a single
modem to dial out to `uunet'. This example shows how you can specify
the port and dialer information directly in the `sys' file for simple
cases. It also shows the use of the following:
Using `call-login' and `call-password' allows the default login
chat script to be used. In this case, the login name is specified
in the call-out login file (*note Configuration File Names::.).
`uunet' is requested to not send us news during the daytime.
If the modem returns `BUSY' or `NO CARRIER' the call is
Since `uunet' tends to be slow, the default timeout has been
This `sys' file relies on certain defaults. It will allow `uunet'
to queue up `rmail' and `rnews' commands. It will allow users to
request files from `uunet' into the UUCP public directory. It will
also `uunet' to request files from the UUCP public directory; in fact
`uunet' never requests files, but for additional security we could add
the line `request false'.
# The following information is for uunet
# The login name and password are kept in the callout password file
# We can send anything at any time.
# During the day we only accept grade 'Z' or above; at other times
# (not mentioned here) we accept all grades. uunet queues up news
# at grade 'd', which is lower than 'Z'.
call-timegrade Z Wk0755-2305,Su1655-2305
# uunet tends to be slow, so we increase the timeout
# We are using a preconfigured Telebit 2500.
port dialer chat "" ATZ\r\d\c OK ATDT\D CONNECT
port dialer chat-fail BUSY
port dialer chat-fail NO\sCARRIER
port dialer complete \d\d+++\d\dATH\r\c
port dialer abort \d\d+++\d\dATH\r\c
# Increase the timeout and the number of retries.
protocol-parameter g timeout 20
protocol-parameter g retries 10
File: uucp.info, Node: Gateway Example, Prev: Leaf Example, Up: Configuration Examples
Many organizations have several local machines which are connected
by UUCP, and a single machine which connects to the outside world.
This single machine is often referred to as a "gateway" machine.
For this example I will assume a fairly simple case. It should
still provide a good general example. There are three machines,
`elmer', `comton' and `bugs'. `elmer' is the gateway machine for
which I will show the configuration file. `elmer' calls out to
`uupsi'. As an additional complication, `uupsi' knows `elmer' as
`airs'; this will show how a machine can have one name on an internal
network but a different name to the external world. `elmer' has two
modems. It also has an TCP/IP connection to `uupsi', but since that
is supposed to be reserved for interactive work (it is, perhaps, only
a 9600 baud SLIP line) it will only use it if the modems are not
A network this small would normally use a single `sys' file.
However, for pedagogical purposes I will show two separate `sys'
files, one for the local systems and one for `uupsi'. This is done
with the `sysfile' command in the `config' file. Here is the `config'
sysfile /usr/local/lib/uucp/sys.local
sysfile /usr/local/lib/uucp/sys.remote
Using the defaults feature of the `sys' file can greatly simplify
the listing of local systems. Here is `sys.local'. Note that this
assumes that the local systems are trusted; they are permited to
request any world readable file and to write files into any world
# Get the login name and password to use from the call-out file
# The systems must use a particular login
# Permit sending any world readable file
# Permit requesting into any world writable directory
# Now define the systems themselves. Because of all the defaults we
# used, there is very little to specify for the systems themselves.
The `sys.remote' file describes the `uupsi' connection. The
`myname' command is used to change the UUCP name to `airs' when
# The login name and password are in the call-out file
# We can call out at any time
# uupsi uses a special login name
# uuspi thinks of us as `airs'
# We use port2 first, then port1, then TCP
# We don't bother to make a special entry in the port file for TCP, we
# just describe the entire port right here. We use a special chat
# script over TCP because the usual one confuses some TCP servers.
The ports are defined in the file `port' (*note port file::.). For
this example they are both connected to the same type of 2400 baud
Dialers are described in the `dial' file (*note dial file::.).
# The chat script used to dial the phone. \D is the phone number.
chat "" ATZ\r\d\c OK ATDT\D CONNECT
# If we get BUSY or NO CARRIER we abort the dial immediately
# When the call is over we make sure we hangup the modem.
complete \d\d+++\d\dATH\r\c
File: uucp.info, Node: Time Strings, Next: Chat Scripts, Prev: Configuration Examples, Up: Configuration Files
Several commands use time strings to specify a range of times. This
section describes how to write time strings.
A time string may be a list of simple time strings separated with a
vertical bar `|' or a command `,'.
Each simple time string must begin with `Su', `Mo', `Tu', `We',
`Th', `Fr', or `Sa', or `Wk' for any weekday, or `Any' for any day.
Following the day may be a range of hours separated with a hyphen
using 24 hour time. The range of hours may cross 0; for example
`2300-0700' means any time except 7 AM to 11 PM. If no time is given,
calls may be made at any time on the specified day(s).
The time string may also consist of the single word `Never', which
does not match any time, or a single word with a name defined in a
previous `timetable' command (*note Miscellaneous (sys)::.).
Here are a few sample time strings with an explanation of what they
`Wk2305-0855,Sa,Su2305-1655'
This means weekdays before 8:55 AM or after 11:05 PM, any time
Saturday, or Sunday before 4:55 PM or after 11:05 PM. These are
approximately the times during which night rates apply to phone
calls in the U.S.A. Note that this time string uses, for
example, `2305' rather than `2300'; this will ensure a cheap rate
phone call even if the computer clock is running up to five
minutes ahead of the real time.
`Wk0905-2255,Su1705-2255'
This means weekdays from 9:05 AM to 10:55 PM, or Sunday from 5:05
PM to 10:55 PM. This is approximately the opposite of the
Since no time is specified, this means any time on any day.
projects / unix-history / blob