<ian@airs.com>
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.
The rest of this section is some descriptive text from the Free Software Foundation.
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 their rights.
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.
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; most of the names of these programs are based on earlier UUCP packages.
uucp
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
`airs'. For more details, see section Invoking uucp.
uux
uux program is used to request the execution of a program 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 such that when rnews runs on `airs' it will receive the
same standard input. For more details, see section Invoking uux.
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. Normally the system will also start the daemon periodically to
check if there is any work to be done. The advantage of this approach
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 anybody notices.
uustat
uustat program does many 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 the remote systems your system knows about. The system
administrator can use uustat to automatically discard old jobs
while sending mail to the user who requested them. For more details,
see section Invoking uustat.
uuname
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. For more details, see
section Invoking uuname.
uulog
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 queued jobs in
the past. For more details, see section Invoking uulog.
uuto
uupick
uuto is a simple shell script interface to uucp. It will
transfer a file, or the contents of a directory, to a remote system, and
notify a particular user on the remote system when it arrives. The
remote user can then retrieve the file(s) with uupick. For more
details, see section Invoking uuto, and see section Invoking uupick.
cu
cu program can be used to call up another system and
communicate with it as though you were directly connected. It can also
do simple file transfers, though it does not provide any error checking.
For more details, section Invoking cu.
These eight programs just described, uucp, uux,
uuto, uupick, uustat, uuname, uulog,
and cu are the user programs provided by Taylor UUCP.
uucp, uux, and uuto add requests to the work queue,
uupick extracts files from the UUCP public directory,
uustat examines the work queue, uuname examines the
configuration files, uulog examines the log files, and cu
just uses the UUCP configuration files.
The real work is actually done by two daemon processes, which are normally run automatically rather than by a user.
uucico
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. For more details, see section Invoking uucico.
uuxqt
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. For more details, see section Invoking uuxqt.
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, as well as the rmail request itself,
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. 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 on the work
queue, 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 another system.
Taylor UUCP comes with a few other programs that are useful when installing and configuring UUCP.
uuchk
uuchk program reads the UUCP configuration files and displays
a rather lengthy description of what it finds. This is useful when
configuring UUCP to make certain that the UUCP package will do what you
expect it to do. For more details, see section Invoking uuchk.
uuconv
uuconv program can be used to convert UUCP configuration
files from one format to another. This can be useful for administrators
converting from an older UUCP package. Taylor UUCP is able to read and
use old configuration file formats, but some new features can not be
selected using the old formats. For more details, see section Invoking uuconv.
uusched
uusched script is provided for compatibility with older UUCP
releases. It starts uucico to call, one at a time, all the
systems for which work has been queued. For more details, see
section Invoking uusched.
tstuu
tstuu program is a test harness for the UUCP package; it can
help check that the package has been configured and compiled correctly.
However, it uses pseudo-terminals, which means that it is less portable
than the rest of the package. If it works, it can be useful when
initially installing Taylor UUCP. For more details, see section Testing the Compilation.
This chapter describes how to run the UUCP programs.
All of the UUCP programs support a few standard options.
debug
configuration command for details (see section Debugging Levels).
Multiple types may be given, separated by commas, and the `--debug'
option may appear multiple times. A number may also be given, which
will turn on that many types from the foregoing list; for example,
`--debug 2' is equivalent to `--debug abnormal,chat'. To turn
on all types of debugging, use `-x all'.
The uulog program uses `-X' rather than `-x' to select
the debugging type; for uulog, `-x' has a different meaning,
for reasons of historical compatibility.
uucp [options] `source-file' `destination-file' uucp [options] `source-file'... `destination-directory'
The uucp command copies files between systems. Each `file'
argument is either a file name on the local machine or is of the form
`system!file'. The latter is interpreted as being on a remote
system.
When uucp is used with two non-option arguments, the contents of
the first file are copied to the second. With more than two non-option
arguments, each source file is copied into the destination directory.
A file may be transferred to or from `system2' via `system1' by using `system1!system2!file'.
Any file name that does not begin with `/' or `~' will be prepended with the current directory (unless the `-W' or `--noexpand' options are used). For example, if you are in the directory `/home/ian', then `uucp foo remote!bar' is equivalent to `uucp /home/ian/foo remote!/home/ian/bar'. Note that the resulting file name may not be valid on a remote system.
A file name beginning with a simple `~' starts at the UUCP public
directory; a file name beginning with `~name' starts at the home
directory of the named user. The `~' is interpreted on the
appropriate system. Note that some shells will interpret an initial
`~' before uucp sees it; to avoid this the `~' must be
quoted.
The shell metacharacters `?' `*' `[' and `]' are interpreted on the appropriate system, assuming they are quoted to prevent the shell from interpreting them first.
The file copy does not take place immediately, but is queued up for the
uucico daemon; the daemon is started immediately unless the
`-r' or `--nouucico' option is given. The next time the
remote system is called, the file(s) will be copied. See section Invoking uucico.
The file mode is not preserved, except for the execute bit. The resulting file is owned by the uucp user.
The following options may be given to uucp.
uucico daemon, the copy
will fail. The files must be readable by the uucico daemon, and
by the invoking user.
uucico daemon immediately; merely queue up the
file transfer for later execution.
uustat.
See section Invoking uustat.
It is possible for some complex operations to produce more than one
jobid, in which case each will be printed on a separate line. For
example
uucp sys1!~user1/file1 sys2!~user2/file2 ~user3will generate two separate jobs, one for the system `sys1' and one for the system `sys2'.
uuto shell script; see section Invoking uuto. It causes uucp to interpret the final argument as
`system!user'. The file(s) are sent to
`~/receive/user/local' on the remote system, where
user is from the final argument and local is the local UUCP
system name. Also, uucp will act as though `--notify user'
were specified.
uux [options] command
The uux command is used to execute a command on a remote system,
or to execute a command on the local system using files from remote
systems. The command is not executed immediately; the request is queued
until the uucico daemon calls the system and transfers the
necessary files. The daemon is started automatically unless one of the
`-r' or `--nouucico' options is given.
The actual command execution is done by the uuxqt daemon on the
appropriate system.
File arguments can be gathered from remote systems to the execution system, as can standard input. Standard output may be directed to a file on a remote system.
The command name may be preceded by a system name followed by an exclamation point if it is to be executed on a remote system. An empty system name is taken as the local system.
Each argument that contains an exclamation point is treated as naming a file. The system which the file is on is before the exclamation point, and the file name on that system follows it. An empty system name is taken as the local system; this form must be used to transfer a file to a command being executed on a remote system. If the file name is not absolute, the current working directory will be prepended to it; the result may not be meaningful on the remote system. A file name may begin with `~/', in which case it is relative to the UUCP public directory on the appropriate system. A file name may begin with `~name/', in which case it is relative to the home directory of the named user on the appropriate system.
Standard input and output may be redirected as usual; the file names
used may contain exclamation points to indicate that they are on remote
systems. Note that the redirection characters must be quoted so that
they are passed to uux rather than interpreted by the shell.
Append redirection (`>>') does not work.
All specified files are gathered together into a single directory before execution of the command begins. This means that each file must have a distinct name. For example,
uux 'sys1!diff sys2!~user1/foo sys3!~user2/foo >!foo.diff'
will fail because both files will be copied to `sys1' and stored under the name `foo'.
Arguments may be quoted by parentheses to avoid interpretation of
exclamation points. This is useful when executing the uucp
command on a remote system.
Most systems restrict the commands which may be executed using `uux'. Many permit only the execution of `rmail' and `rnews'.
A request to execute an empty command (e.g., `uux sys!') will create a poll file for the specified system; see section Calling Other Systems for an example of why this might be useful.
The following options may be given to uux.
uucico daemon,
the copy will fail. The files must be readable by the uucico
daemon, as well as the by the invoker of uux.
uucico daemon, the changed versions will be used. The files must
be readable by the uucico daemon, as well as by the invoker of
uux.
uuxqt daemons, including the Taylor UUCP uuxqt, this is
the default action; for those, `--notification=error' will have no
effect. However, some uuxqt daemons will send mail if the job
succeeds, unless the `--notification=error' option is used. Some
other uuxqt daemons will not send mail even if the job fails,
unless the `--notification=error' option is used.
uucico daemon immediately; merely queue up the
execution request for later processing.
uustat. See section Invoking uustat. Cancelling any file copies
will make it impossible to complete execution of the job.
Here are some examples of using uux.
uux -z - sys1!rmail user1
This will execute the command `rmail user1' on the system
`sys1', giving it as standard input whatever is given to uux
as standard input. If a failure occurs, mail will be sent to the user
who ran the command.
uux 'diff -c sys1!~user1/file1 sys2!~user2/file2 >!file.diff'
This will fetch the two named files from system `sys1' and system
`sys2' and execute `diff', putting the result in
`file.diff' in the current directory on the local system. The
current directory must be writable by the uuxqt daemon for this
to work.
uux 'sys1!uucp ~user1/file1 (sys2!~user2/file2)'
Execute uucp on the system `sys1' copying `file1' (on
system `sys1') to `sys2'. This illustrates the use of
parentheses for quoting.
uustat -a
uustat --all
uustat [-eKRiMNQ] [-sS system] [-uU user] [-cC command] [-oy hours]
[-B lines] [--executions] [--kill-all] [--rejuvenate-all]
[--prompt] [--mail] [--notify] [--no-list] [--system system]
[--not-system system] [--user user] [--not-user user]
[--command command] [--not-command command] [--older-than hours]
[--younger-than hours] [--mail-lines lines]
uustat [-kr jobid] [--kill jobid] [--rejuvenate jobid]
uustat -q [-sS system] [-oy hours] [--system system]
[--not-system system ] [--older-than hours] [--younger-than hours]
uustat --list [-sS system] [-oy hours] [--system system ]
[--not-system system] [--older-than hours] [--younger-than hours]
uustat -m
uustat --status
uustat -p
uustat --ps
The uustat command can display various types of status
information about the UUCP system. It can also be used to cancel or
rejuvenate requests made by uucp or uux.
With no options, uustat displays all jobs queued up for the
invoking user, as if given the `--user' option with the appropriate
argument.
If any of the `-a', `--all', `-e', `--executions', `-s', `--system', `-S', `--not-system', `-u', `--user', `-U', `--not-user', `-c', `--command', `-C', `--not-command', `-o', `--older-than', `-y', or `--younger-than' options are given, then all jobs which match the combined specifications are displayed.
The `-K' or `--kill-all' option may be used to kill off a selected group of jobs, such as all jobs more than 7 days old.
The following options may be given to uustat.
uuxqt
rather than uucico. Queued execution requests may be waiting for
some file to be transferred from a remote system. They are created by
an invocation of uux.
uucp or
uux. A job may only be killed by the user who created the job,
or by the UUCP administrator, or the superuser. The `-k' or
`--kill' options may be used multiple times on the command line to
kill several jobs.
uucp or uux. A job may only be
rejuvenated by the user who created the job, or by the UUCP
administrator, or the superuser. The `-r' or `--rejuvenate'
options may be used multiple times on the command line to rejuvenate
several jobs.
uustat --all
Display status of all jobs. A sample output line is as follows:
bugsA027h bugs ian 04-01 13:50 Executing rmail ian@airs.com (sending 12 bytes)
The format is
jobid system user queue-date command (size)
The jobid may be passed to the `--kill' or `--rejuvenate' options. The size indicates how much data is to be transferred to the remote system, and is absent for a file receive request. The `--system', `--not-system', `--user', `--not-user', `--command', `--not-command', `--older-than', and `--younger-than' options may be used to control which jobs are listed.
uustat --executions
Display status of queued up execution requests. A sample output line is as follows:
bugs bugs!ian 05-20 12:51 rmail ian
The format is
system requestor queue-date command
The `--system', `--not-system', `--user', `--not-user', `--command', `--not-command', `--older-than', and `--younger-than' options may be used to control which requests are listed.
uustat --list
Display status for all systems with queued up commands. A sample output line is as follows:
bugs 4C (1 hour) 0X (0 secs) 04-01 14:45 Dial failed
This indicates the system, the number of queued commands, the age of the oldest queued command, the number of queued local executions, the age of the oldest queued execution, the date of the last conversation, and the status of that conversation.
uustat --status
Display conversation status for all remote systems. A sample output line is as follows:
bugs 04-01 15:51 Conversation complete
This indicates the system, the date of the last conversation, and the
status of that conversation. If the last conversation failed,
uustat will indicate how many attempts have been made to call the
system. If the retry period is currently preventing calls to that
system, uustat also displays the time when the next call will be
permitted.
uustat --ps
Display the status of all processes holding UUCP locks. The output
format is system dependent, as uustat simply invokes ps on
each process holding a lock.
uustat -c rmail -o 168 -K -Q -M -N -W "Queued for over 1 week"
This will kill all `rmail' commands that have been queued up waiting for delivery for over 1 week (168 hours). For each such command, mail will be sent both to the UUCP administrator and to the user who requested the rmail execution. The mail message sent will include the string given by the `-W' option. The `-Q' option prevents any of the jobs from being listed on the terminal, so any output from the program will be error messages.
uuname [-a] [--aliases] uuname -l uuname --local
By default, the uuname program simply lists the names of all the
remote systems mentioned in the UUCP configuration files.
The uuname program may also be used to print the UUCP name of the
local system.
The uuname program is mainly for use by shell scripts.
The following options may be given to uuname.
uulog [-#] [-n lines] [-sf system] [-u user] [-DSF] [--lines lines]
[--system system] [--user user] [--debuglog] [--statslog]
[--follow] [--follow=system]
The uulog program may be used to display the UUCP log file.
Different options may be used to select which parts of the file to
display.
uulog specifies the debugging
type using `-X' rather than the usual `-x'.
The operation of uulog depends to some degree upon the type of
log files generated by the UUCP programs. This is a compile time
option. If the UUCP programs have been compiled to use HDB style log
files, uulog changes in the following ways:
uuxqt log file.
uuto files... system!user
The uuto program may be used to conveniently send files to a
particular user on a remote system. It will arrange for mail to be sent
to the remote user when the files arrive on the remote system, and he or
she may easily retrieve the files using the uupick program
(see section Invoking uupick). Note that uuto does not provide any
security--any user on the remote system can examine the files.
The last argument specifies the system and user name to which to send the files. The other arguments are the files or directories to be sent.
The uuto program is actually just a trivial shell script which
invokes the uucp program with the appropriate arguments. Any
option which may be given to uucp may also be given to
uuto. See section Invoking uucp.
uupick [-s system] [--system system]
The uupick program is used to conveniently retrieve files
transferred by the uuto program.
For each file transferred by uuto, uupick will display the
source system, the file name, and whether the name refers to a regular
file or a directory. It will then wait for the user to specify an
action to take. One of the following commands must be entered:
uupick.
The `-s' or `--system' option may be used to restrict
uupick to only present files transferred from a particular
system. The uupick program also supports the standard UUCP
program options; see section Standard Options.
cu [options] [system | phone | "dir"]
The cu program is used to call up another system and act as a
dial in terminal. It can also do simple file transfers with no error
checking.
The cu program takes a single non-option argument.
If the argument is the string `dir' cu will make a direct connection to the port. This may only be used by users with write access to the port, as it permits reprogramming the modem.
Otherwise, if the argument begins with a digit, it is taken to be a phone number to call.
Otherwise, it is taken to be the name of a system to call.
The `-z' or `--system' options may be used to name a system beginning with a digit, and the `-c' or `--phone' options may be used to name a phone number that does not begin with a digit.
The cu program locates a port to use in the UUCP configuration
files. If a simple system name is given, it will select a port
appropriate for that system. The `-p', `--port', `-l',
`--line', `-s', and `--speed' options may be used to
control the port selection.
When a connection is made to the remote system, cu forks into two
processes. One reads from the port and writes to the terminal, while
the other reads from the terminal and writes to the port.
The cu program provides several commands that may be used during
the conversation. The commands all begin with an escape character,
which by default is ~ (tilde). The escape character is only
recognized at the beginning of a line. To send an escape character to
the remote system at the start of a line, it must be entered twice. All
commands are either a single character or a word beginning with %
(percent sign).
The cu program recognizes the following commands.
cu variable to the given value. If value is not given, the
variable is set to `true'.
cu variable to `false'.
The cu program also supports several variables. They may be
listed with the `~v' command, and set with the `~s' or
`~!' commands.
cu will delay for a second, after
recognizing the escape character, before printing the name of the local
system. The default is true.
The following options may be given to cu.
uucico [options]
The uucico daemon processes file transfer requests queued by
uucp and uux. It is started when uucp or
uux is run (unless they are given the `-r' or
`--nouucico' options). It is also typically started periodically
using entries in the `crontab' table(s).
When uucico is invoked with `-r1', `--master',
`-s', `--system', or `-S', the daemon will place a call
to a remote system, running in master mode. Otherwise the daemon will
start in slave mode, accepting a call from a remote system. Typically a
special login name will be set up for UUCP which automatically invokes
uucico when a remote system calls in and logs in under that name.
When uucico terminates, it invokes the uuxqt daemon,
unless the `-q' or `--nouuxqt' options were given;
uuxqt executes any work orders created by uux on a remote
system, and any work orders created locally which have received remote
files for which they were waiting.
If a call fails, uucico will normally refuse to retry the call
until a certain (configurable) amount of time has passed. This may be
overriden by the `-f', `--force', or `-S' options.
The `-l', `--prompt', `-e', or `--loop' options may
be used to force uucico to produce its own prompts of
`login: ' and `Password:'. When another uucico daemon
calls in, it will see these prompts and log in as usual. The login name
and password will normally be checked against a separate list kept
specially for uucico, rather than the `/etc/passwd' file
(see section Configuration File Names). It is possible, on some systems, to
configure uucico to use `/etc/passwd'. The `-l' or
`--prompt' options will prompt once and then exit; in this mode the
UUCP administrator, or the superuser, may use the `-u' or
`--login' option to force a login name, in which case uucico
will not prompt for one. The `-e' or `--loop' options will
prompt again after the first session is over; in this mode uucico
will permanently control a port.
If uucico receives a SIGQUIT, SIGTERM or
SIGPIPE signal, it will cleanly abort any current conversation
with a remote system and exit. If it receives a SIGHUP signal it
will abort any current conversation, but will continue to place calls to
(if invoked with `-r1' or `--master') and accept calls from
(if invoked with `-e' or `--loop') other systems. If it
receives a SIGINT signal it will finish the current conversation,
but will not place or accept any more calls.
The following options may be given to uucico.
uucico to be easily run from
inetd. The login name and password are checked against the UUCP
password file, which need not be `/etc/passwd'. The `--login'
option may be used to force a login name, in which cause uucico
will only prompt for a password.
kill to shut it down.
uuxqt daemon when finished.
uustat). This can be convenient
for automated polling scripts, which may want to simply attempt to call
every system rather than worry about which particular systems may be
called at the moment. This option also suppresses the log message
indicating that there is no work to be done.
uucico
detaches from the terminal before each call out to another system and
before invoking uuxqt. This option prevents this.
uucico to prompt only
for the password, not the login name.
uucico to use TLI calls to perform I/O.
uuxqt [-c command] [-s system] [--command command] [--system system]
The uuxqt daemon executes commands requested by uux from
either the local system or from remote systems. It is started
automatically by the uucico daemon (unless uucico is given
the `-q' or `--nouuxqt' options).
There is normally no need to run uuxqt, since it will be invoked
by uucico. However, uuxqt can be invoked directly to
provide greater control over the processing of the work queue.
Multiple invocations of uuxqt may be run at once, as controlled
by the max-uuxqts configuration command; see section Miscellaneous config File Commands.
The following options may be given to uuxqt.
uuchk [-s system] [--system system]
The uuchk program displays information read from the UUCP
configuration files. It should be used to ensure that UUCP has been
configured correctly.
The `-s' or `--system' options may be used to display the
configuration for just the specified system, rather than for all
systems. The uuchk program also supports the standard UUCP
program options; see section Standard Options.
uuconv -i type -o type [-p program] [--program program] uuconv --input type --output type [-p program] [--program program]
The uuconv program converts UUCP configuration files from one
format to another. The type of configuration file to read is specified
using the `-i' or `--input' options. The type of
configuration file to write is specified using the `-o' or
`--output' options.
The supported configuration file types are `taylor', `v2', and `hdb'. For a description of the `taylor' configuration files, see section Taylor UUCP Configuration Files. The other types of configuration files are used by traditional UUCP packages, and are not described in this manual.
An input configuration of type `v2' or `hdb' is read from a compiled in directory (specified by `oldconfigdir' in `Makefile'). An input configuration of type `taylor' is read from a compiled in directory by default, but may be overridden with the standard `-I' or `--config' options (see section Standard Options).
The output configuration is written to files in the directory in which
uuconv is run.
Some information in the input files may not be representable in the
desired output format, in which case uuconv will silently discard
it. The output of uuconv should be carefully checked before it
is used. The uuchk program may be used for this purpose; see
section Invoking uuchk.
The `-p' or `--program' option may be used to convert specific
cu configuration information, rather than the default of only
converting the uucp configuration information; see section The Main Configuration File.
The uuchk program also supports the standard UUCP program
options; see section Standard Options.
The uusched program is actually just a shell script which invokes
the uucico daemon. It is provided for backward compatibility.
It causes uucico to call all systems for which there is work.
Any option which may be given to uucico may also be given to
uusched. See section Invoking uucico.
These are the installation instructions for the Taylor UUCP package.
If you have a source code distribution, you must first compile it for your system. Free versions of Unix, such as Linux, NetBSD, or FreeBSD, often come with pre-compiled binary distributions of UUCP. If you are using a binary distribution, you may skip to the configuration section (see section Configuring Taylor UUCP).
Follow these steps to compile the source code.
uucp rather than a real person; they should probably
not be owned by root).
configure. This script was generated using
the autoconf program written by David MacKenzie of the Free
Software Foundation. It takes a while to run. It will generate the
file `config.h' based on `config.h.in', and, for each source
code directory, will generate `Makefile' based on
`Makefile.in'.
You can pass certain arguments to configure in the environment.
Because configure will compile little test programs to see what
is available on your system, you must tell it how to run your compiler.
It recognizes the following environment variables:
configure can find
`gcc' it will use it, otherwise it will use `cc'.
configure will use `-g'.
configure will use the empty string.
configure will use the empty string.
configure finds the BSD install program,
it will set this to `install -c'; otherwise, it will use `cp'.
sh, bash, or ksh,
invoke configure as `CC=rcc configure'. If you are using
csh, do `setenv CC rcc; sh configure'.
On some systems you will want to use `LIBS=-lmalloc'. On Xenix
derived versions of Unix 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 `LIBS=-lc -lx'.
If configure fails for some reason, or if you have a very weird
system, you may have to configure the package by hand. To do this, copy
the file `config.h.in' to `config.h' and edit it for your
system. Then for each source directory (the top directory, and the
subdirectories `lib', `unix', and `uuconf') copy
`Makefile.in' to `Makefile', find the words within @
characters, and set them correctly for your system.
configure script will default to passing `-posix' to
gcc. However, using `-posix' changes the environment to
POSIX, and on ISC 3.0, at least, the default for POSIX_NO_TRUNC
is 1. This can lead to a problem when uuxqt executes
rmail. IDA sendmail has dbm configuration files named
`mailertable.{dir,pag}'. Notice these names are 15 characters
long. When uuxqt compiled with the `-posix' executes
rmail, which in turn executes sendmail, the later is run
under the POSIX environment too. This leads to sendmail bombing
out with `'error opening 'M' database: name too long'
(mailertable.dir)'. It's rather obscure behaviour, and it took me a day
to find out the cause. I don't use the `-posix' switch; instead, I
run gcc with `-D_POSIX_SOURCE', and add `-lcposix' to
`LIBS'.
configure worked correctly by checking
`config.h' and the instances of `Makefile'.
configure script.
If your system supports pseudo-terminals, and you compiled the code to
support the new style of configuration files (HAVE_TAYLOR_CONFIG
was set to 1 in `policy.h'), you should be able to use the
tstuu program to test the uucico daemon. If your system
supports STREAMS based pseudo-terminals, you must compile tstuu.c with
`-DHAVE_STREAMS_PTYS'. (The STREAMS based code was contributed by
Marc Boucher).
To run tstuu, just type `tstuu' with no arguments. You must
run it in the compilation directory, since it runs `./uucp',
`./uux' and `./uucico'. The tstuu program will 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. The
tstuu program will create a directory `/usr/tmp/tstuu' and
fill it with configuration files, and create spool directories
`/usr/tmp/tstuu/spool1' and `/usr/tmp/tstuu/spool2'.
If your system does not support the FIONREAD call, the
`tstuu' program will run very slowly. This may or may not get
fixed in a later version.
The tstuu program will finish with an execute file named
`X.something' and a data file named `D.something'
in the directory `/usr/tmp/tstuu/spool1' (or, more likely, in
subdirectories, depending on the choice of SPOOLDIR in
`policy.h'). Two log files will be created in the directory
`/usr/tmp/tstuu'. They will be named `Log1' and `Log2',
or, if you have selected HAVE_HDB_LOGGING in `policy.h',
`Log1/uucico/test2' and `Log2/uucico/test1'. There should be
no errors in the log files.
You can test uuxqt with `./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 (see section 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 the files
`Debug1' and `Debug2' in the directory `/usr/tmp/tstuu'.
After that, you're pretty much on your own.
On some systems you can also use tstuu to test 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, on 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 a setuid 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
`/usr/lib/uucp/uucico'.
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 you can not run tstuu, or if it fails inexplicably, don't
worry about it too much. On some systems tstuu will fail because
of problems using pseudo terminals, which will not matter in normal use.
The real test of the package is talking to another system.
You can install the executable files by becoming 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, but
it only does this the first time Taylor UUCP is installed (so that if
you install several versions of Taylor UUCP, you can still go back to
your original UUCP programs). You can retrieve the original programs by
typing `make uninstall'.
Note that by default the programs are compiled with debugging
information, and they are not stripped when they are installed. You may
want to strip the installed programs to save disk space. For more
information, see your system documentation for the strip program.
Of course, simply installing the executable files is not enough. You must also arrange for them to be used correctly.
You will have to decide what types of configuration files you want to use. This package supports a new sort of configuration file; see section Taylor UUCP Configuration Files. It also supports V2 configuration files (`L.sys', `L-devices', etc.) and HDB configuration files (`Systems', `Devices', etc.). No documentation is provided for V2 or HDB 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 dial file (see section The Dialer Configuration File), or with a HDB `Dialers' file.
Use of HDB 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, as found in some versions of HDB, 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 dial file; see section The Dialer Configuration File. You will have to invoke
the dialer program via a shell script or another program, since an exit
code of 0 is required to recognize success; the dialHDB program
in the `contrib' directory may be used for this purpose.
The uuconv (see section Invoking uuconv) program can be used to
convert from V2 or HDB configuration files to the new style (it can also
do the reverse translation, if you are so inclined). It will not do all
of the work, and the results should be carefully checked, but it can be
quite useful.
If you are installing a new system, you will, of course, have to write the configuration files; see section Taylor UUCP Configuration Files for details on how to do this.
After writing the configuration files, use the uuchk program to
verify that they are what you expect; see section Invoking uuchk.
After you have written the configuration files, and verified them with
the uuchk program (see section Invoking uuchk), you must check that
UUCP can correctly contact another system.
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 happens. The exact location of the log file depends upon the
settings in `policy.h' when you compiled the program, and on the
use of the logfile command in the `config' file. Typical
locations are `/usr/spool/uucp/Log' or a subdirectory under
`/usr/spool/uucp/.Log'.
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 with the
debug command (see section 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 `config' file can override the default
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') (see section Status Directory) will prevent too many
attempts from occurring in rapid succession.
On older System V based systems which do not have the setreuid
system call, problems may arise if ordinary users can start an execution
of uuxqt, perhaps indirectly via uucp or uux. UUCP
jobs may wind up executing with a real user ID of the user who invoked
uuxqt, which can cause problems if the UUCP job checks the real
user ID for security purposes. On such systems, it is safest to put
`run-uuxqt never' (see section Miscellaneous config File Commands) in the
`config' file, so that uucico never starts uuxqt, and
invoke uuxqt directly from a `crontab' file.
Please let me know about any problems you have and how you got around
them. If you do report a problem, please include the version number of
the package you are using, the operating system you are running it on,
and a sample of the debugging file showing the problem (debugging
information is usually what is needed, not just the log file). General
questions such as "why doesn't uucico dial out" are impossible
to answer without much more information.
By default uucp and uux will automatically start up
uucico to call another system whenever work is queued up.
However, the call may fail, or you may have put in time restrictions
which prevent the call at that time (perhaps because telephone rates are
high) (see section When to Call). Also, a remote system may have work
queued up for your system, but may not be calling you for some reason
(perhaps you have agreed that your system should always place the call).
To make sure that work gets transferred between the systems withing a
reasonable time period, you should arrange to periodically invoke
uucico.
These periodic invocations are normally triggered by entries in the `crontab' file. The exact format of `crontab' files, and how new entries are added, varies from system to system; check your local documentation (try `man cron').
To attempt to call all systems with outstanding work, use the command `uucico -r1'. To attempt to call a particular system, use the command `uucico -s system'. To attempt to call a particular system, but only if there is work for it, use the command `uucico -C -s system'. (see section Invoking uucico).
A common case is to want to try to call a system at a certain time, with periodic retries if the call fails. A simple way to do this is to create an empty UUCP command file, known as a poll file. If a poll file exists for a system, then `uucico -r1' will place a call to it. If the call succeeds, the poll file will be deleted.
A poll file can be easily created using the `uux' command, by requesting the execution of an empty command. To create a poll file for system, just do something like this:
uux -r system!
The `-r' tells `uux' to not start up `uucico' immediately. Of course, if you do want `uucico' to start up right away, omit the `-r'; if the call fails, the poll file will be left around to cause a later call.
For example, I use the following crontab entries locally:
45 * * * * /bin/echo /usr/lib/uucp/uucico -r1 | /bin/su uucpa 40 4,10,15 * * * /usr/bin/uux -r uunet!
Every hour, at 45 minutes past, this will check if there is any work to
be done, and, if there is, will call the appropriate system. Also, at
4:40am, 10:40am, and 3:40pm, this will create a poll file file for
`uunet', forcing the next run of uucico to call
`uunet'.
To accept calls from another system, you must arrange matters such that
when that system calls in, it automatically invokes uucico on
your system.
The most common arrangement is to create a special user name and
password for incoming UUCP calls. This user name typically uses the
same user ID as the regular uucp user (Unix permits several user
names to share the same user ID). The shell for this user name should
be set to uucico.
Here is a sample `/etc/passwd' line to accept calls from a remote system named airs:
Uairs:password:4:8:airs UUCP:/usr/spool/uucp:/usr/lib/uucp/uucico
The details may vary on your system. You must use reasonable user and
group ID's. You must use the correct file name for uucico. The
password must appear in the UUCP configuration files on the remote
system, but will otherwise never be seen or typed by a human.
Note that uucico appears as the login shell, and that it will be
run with no arguments. This means that it will start in slave mode and
accept an incoming connection. See section Invoking uucico.
On some systems, creating an empty file named `.hushlogin' in the
home directory will skip the printing of various bits of information
when the remote uucico logs in, speeding up the UUCP connection
process.
For the greatest security, each system which calls in should use a
different user name, each with a different password, and the
called-login command should be used in the `sys' file to
ensure that the correct login name is used. See section Accepting a Call,
and see section Security.
If you never need to dial out from your system, but only accept incoming
calls, you can arrange for uucico to handle logins itself,
completely controlling the port, by using the `--endless' option.
See section Invoking uucico.
Taylor UUCP does not include a mail package. All Unix systems come with
some sort of mail delivery agent, typically sendmail or
MMDF. Source code is available for some alternative mail
delivery agents, such as IDA sendmail and smail.
Taylor UUCP also does not include a news package. The two major Unix
news packages are C-news and INN. Both are available in
source code form.
Configuring and using mail delivery agents is a notoriously complex topic, and I will not be discussing it here. Configuring news systems is usually simpler, but I will not be discussing that either. I will merely describe the interactions between the mail and news systems and UUCP.
A mail or news system interacts with UUCP in two ways: sending and receiving.
When mail is to be sent from your machine to another machine via UUCP,
the mail delivery agent will invoke uux. It will generally run a
command such as `uux - system!rmail address', where
system is the remote system to which the mail is being sent. It
may pass other options to uux, such as `-r' or `-g'
(see section Invoking uux).
The news system also invokes uux in order to transfer articles to
another system. The only difference is that news will use uux to
invoke rnews on the remote system, rather than rmail.
You should arrange for your mail and news systems to invoke the Taylor
UUCP version of uux. If you only have Taylor UUCP, or if you
simply replace any existing version of uux with the Taylor UUCP
version, this will probably happen automatically. However, if you have
two UUCP packages installed on your system, you will probably have to
modify the mail and news configuration files in some way.
Actually, if both the system UUCP and Taylor UUCP are using the same
spool directory format, the system uux will probably work fine
with the Taylor uucico (the reverse is not the case: the Taylor
uux requires the Taylor uucico). However, data transfer
will be somewhat more efficient if the Taylor uux is used.
To receive mail, all that is necessary is for UUCP to invoke
rmail. Any mail delivery agent will provide an appropriate
version of rmail; you must simply make sure that it is in the
command path used by UUCP (it almost certainly already is). The default
command path is set in `policy.h', and it may be overridden for a
particular system by the command-path command
(see section Miscellaneous sys File Commands).
Similarly, for news UUCP must be able to invoke rnews. Any news
system will provide a version of rnews, and you must ensure that
is in a directory on the path that UUCP will search.
In general, the layout of the spool directory may be safely ignored.
However, it is documented here for the curious. This description only
covers the SPOOLDIR_TAYLOR layout. The ways in which the other
spool directory layouts differ are described in the source file
`unix/spool.c'.
Directories and files are only created when they are needed, so a typical system will not have all of the entries described here.
rmail
and rnews, send an `E' command rather than an execution file
(see section The E Command).
uucico will
create an execution file on the fly when it receives an `E'
command.
uustat --status basically just formats and prints the contents of
the status files (see section uustat Examples).
Each status file has a single text line with six fields.
uucico was unable to open the port.
uucico is currently talking to the system.
time system call).
uucico may attempt another call. This is set based
on the retry time; see section When to Call. The `-f' or `-S'
options to uucico direct it to ignore this wait time; see
section Invoking uucico.
uuxqt executes a job requested by uux, it first
changes the working directory to the `.Xqtdir' subdirectory. This
permits the job to create any sort of temporary file without worrying
about overwriting other files in the spool directory. Any files left
in the `.Xqtdir' subdirectory are removed after each execution is
complete.
uuxqt are executing simultaneously,
each one executes jobs in a separate directory. The first uses
`.Xqtdir', the second uses `.Xqtdir0001', the third uses
`.Xqtdir0002', and so forth.
uuxqt encounters an execution file which it is unable to
parse, it saves it in the `.Corrupt' directory, and sends mail
about it to the UUCP administrator.
uuxqt executes a job, and the job fails, and there is enough
disk space to hold the command file and all the data files, then
uuxqt saves the files in the `.Failed' directory, and sends
mail about it to the UUCP administrator.
sequence command is used for a system
(see section Miscellaneous sys File Commands). The sequence number for the system
system is stored in the file `.Sequence/system'. It is
simply stored as a printable number.
uucico receives the file into
`.Temp/system/temp', where system is the name of
the remote system, and temp is the temporary file name. If a
conversation fails during a file transfer, these files are used to
automatically restart the file transfer from the point of failure.
If the `S' or `E' command does not include a temporary file
name, automatic restart is not possible. In this case, the files are
received into a randomly named file in the `.Temp' directory
itself.
uucico will store the
data file in the `.Preserve' directory, and send mail to the
requestor describing the failure and naming the saved file.
uucico acknowledges receipt of a
file, it is possible for the acknowledgement to be lost. If this
happens, the remote system will resend the file. If the file were an
execution request, and uucico did not keep track of which files
it had already received, this could lead to the execution being
performed twice.
To avoid this problem, when a conversation fails, uucico records
each file that has been received, but for which the remote system may
not have received the acknowledgement. It records this information by
creating an empty file with the name
`.Received/system/temp', where system is the name
of the remote system, and temp is the temp field of the
`S' or `E' command from the remote system (see section The S Command). Then, if the remote system offers the file again in the next
conversation, uucico refuses the send request and deletes the
record in the `.Received' directory. This approach only works for
file sends which use a temporary file name, but this is true of all
execution requests.
Lock files for devices and systems are stored in the lock directory,
which may or may not be the same as the spool directory. The lock
directory is set at compilation time by LOCKDIR in
`policy.h', which may be overridden by the lockdir command
in the `config' file (see section Miscellaneous config File Commands).
For a description of the names used for device lock files, and the format of the contents of a lock file, see section UUCP Lock Files.
uucico
while talking to a remote system, and are used to prevent multiple
simultaneous conversations with a system.
On systems which limit file names to 14 characters, only the first eight
characters of the system name are used in the lock file name. This
requires that the names of each directly connected remote system be
unique in the first eight characters.
uuxqt starts up, it uses lock files to determine how many
other uuxqt daemons are currently running. It first tries to
lock `LCK.XQT.0', then `LCK.XQT.1', and so forth. This is
used to implement the max-uuxqts command (see section Miscellaneous config File Commands). It is also used to parcel out the `.Xqtdir'
subdirectories (see section Execution Subdirectories).
uuxqt is invoked with the `-c' or `--command'
option (see section Invoking uuxqt), it creates a lock file named after the
command it is executing. For example, `uuxqt -c rmail' will create
the lock file `LXQ.rmail'. This prevents other uuxqt
daemons from executing jobs of the specified type.
uuxqt is executing a particular job, it creates a lock file
with the same name as the `X.' file describing the job, but
replacing the initial `X' with `L'. This ensures that if
multiple uuxqt daemons are running, they do not simultaneously
execute the same job.
fcntl system
call.
The spool directory may need to be cleaned up periodically. Under some circumstances, files may accumulate in various subdirectories, such as `.Preserve' (see section Other Spool Subdirectories) or `.Corrupt' (see section Execution Subdirectories).
Also, if a remote system stops calling in, you may want to arrange for
any queued up mail to be returned to the sender. This can be done using
the uustat command (see section Invoking uustat).
The `contrib' directory includes a simple `uuclean' script which may be used as an example of a clean up script. It can be run daily out of `crontab'.
You should periodically trim the UUCP log files, as they will otherwise
grow without limit. The names of the log files are set in
`policy.h', and may be overridden in the configuration file
(see section The Main Configuration File). By default they are are
`/usr/spool/uucp/Log' and `/usr/spool/uucp/Stats'. You may
find the savelog program in the `contrib' directory to be of
use. There is a manual page for it in `contrib' as well.
This chapter describes the configuration files accepted by the Taylor
UUCP package if compiled with HAVE_TAYLOR_CONFIG set to 1 in
`policy.h'.
The configuration files are normally found in the directory newconfigdir, which is defined by the `Makefile' variable `newconfigdir'; by default newconfigdir is `/usr/local/conf/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' or `--config' option; this can be useful when testing a new configuration. When you use the `-I' option the programs will revoke any setuid privileges.
UUCP uses several different types of configuration files, each describing a different kind of information. The commands permitted in each file are described in detail below. This section is a brief description of some of the different types of files.
The `config' file is the main configuration file. It describes general information not associated with a particular remote system, such as the location of various log files. There are reasonable defaults for everything that may be specified in the `config' file, so you may not actually need one on your system.
There may be only one `config' file, but there may be one or more of each other type of file. The default is one file for each type, but more may be listed in the `config' file.
The `sys' files are used to describe remote systems. Each remote system to which you connect must be listed in a `sys' file. A `sys' file will include information for a system, such as the speed (baud rate) to use, or when to place calls.
For each system you wish to call, you must describe one or more ports; these ports may be defined directly in the `sys' file, or they may be defined in a `port' file.
The `port' files are used to describe ports. A port is a particular hardware connection on your computer. You would normally define as many ports as there are modems attached to your computer. A TCP connection is also described using a port.
The `dial' files are used to describe dialers. Dialer is essentially another word for modem. The `dial' file describes the commands UUCP should use to dial out on a particular type of modem. You would normally define as many dialers as there are types of modems attached to your computer. For example, if you have three Telebit modems used for UUCP, you would probably define three ports and one dialer.
There are other types of configuration files, but these are the important ones. The other types are described below.
All the configuration files follow a simple line-oriented `keyword value' format. Empty lines are ignored, as are leading spaces; unlike HDB, 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 `\#', 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 argument.
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.
This section provides few typical examples of configuration files. There are also sample configuration files in the `sample' subdirectory of the distribution.
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 section The Main Configuration 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 line in `config':
nodename airs
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 would use the following commands in `config' to change to directories on the partition `/uucp':
spool /uucp/spool pubdir /uucp/uucppublic logfile /uucp/spool/Log 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 section The System Configuration 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 unknown receive-request no # The public directory is /usr/spool/anonymous unknown pubdir /usr/spool/anonymous # Only files in the public directory may be sent (the default anyhow) unknown remote-send ~
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 be quoted.
The next example will permit remote systems to upload files to a special directory named `/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) unknown commands # 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
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 section The System Configuration 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:
call-login
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 (see section Configuration File Names).
call-timegrade
chat-fail
protocol-param