862 lines
40 KiB
Plaintext
862 lines
40 KiB
Plaintext
Info file uucp.info, produced by Makeinfo, -*- Text -*- from input
|
||
file uucp.texi.
|
||
|
||
This file documents Taylor UUCP, beta 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
|
||
preserved on all copies.
|
||
|
||
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
|
||
one.
|
||
|
||
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
|
||
English.
|
||
|
||
|
||
File: uucp.info, Node: Top, Next: Copying, Prev: (dir), Up: (dir)
|
||
|
||
Taylor UUCP 1.03
|
||
****************
|
||
|
||
This is the documentation for the Taylor UUCP package, beta 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>'.
|
||
|
||
* Menu:
|
||
|
||
* Copying:: Taylor UUCP copying conditions
|
||
* Introduction:: Introduction to Taylor UUCP
|
||
* Overall Installation:: Taylor UUCP installation
|
||
* Configuration files:: Taylor UUCP configuration files
|
||
* 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
|
||
|
||
* config file:: The main configuration file
|
||
* sys file:: The system configuration file
|
||
* port file:: The port configuration files
|
||
* dial file:: The dialer configuration files
|
||
* Example:: Brief example of configuration files
|
||
|
||
|
||
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
|
||
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.
|
||
|
||
|
||
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.
|
||
|
||
`uucp'
|
||
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
|
||
`airs'.
|
||
|
||
`uux'
|
||
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
|
||
standard input.
|
||
|
||
Neither `uucp' nor `uux' actually do any work immediately. Instead
|
||
they queue up requests for later processing. They then normally start
|
||
a daemon process which processes the requests and calls up the
|
||
appropriate systems. The daemon will usually 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
|
||
anybody notices.
|
||
|
||
`uustat'
|
||
The `uustat' program does several things. It can be used to
|
||
report the status of your jobs, and 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.
|
||
|
||
`uuname'
|
||
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.
|
||
|
||
`uulog'
|
||
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
|
||
queued jobs in the past.
|
||
|
||
These five programs, `uucp', `uux', `uustat', `uuname', `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.
|
||
|
||
`uucico'
|
||
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' and most systems will
|
||
also run it periodically to make sure that all requests are
|
||
handled. `uucico' checks the queue to see what work needs to be
|
||
done, and then calls the appropriate the system. 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.
|
||
|
||
`uuxqt'
|
||
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, saying
|
||
something like `uucp notes.txt airs!~/notes.txt'. This would queue up
|
||
a request on `bantam' to call `airs' and 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 the file would be transferred 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 another system.
|
||
|
||
Taylor UUCP comes with two other programs that are useful when
|
||
installing and configuring UUCP.
|
||
|
||
`uuchk'
|
||
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.
|
||
|
||
`tstuu'
|
||
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
|
||
Taylor UUCP.
|
||
|
||
|
||
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.
|
||
|
||
* Menu:
|
||
|
||
* 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
|
||
|
||
Configuring Taylor UUCP
|
||
=======================
|
||
|
||
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
|
||
a BNU `Dialers' file.
|
||
|
||
Use of BNU configuration file has one known bug. A blank line in
|
||
the middle of an entry in the `Permissions' file will not be ignored as
|
||
it should be.
|
||
|
||
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
|
||
|
||
Compiling Taylor UUCP
|
||
=====================
|
||
|
||
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.
|
||
|
||
You can pass certain arguments to `configure' in the
|
||
environment. Useful arguments are `LIBS', `CC', and `INSTALL'.
|
||
For example, if you wanted to include the `posix' library, then
|
||
(using `sh' or `bash') you could enter `LIBS=-lposix ./configure'.
|
||
|
||
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
|
||
`LIBS=-lc -lx'. I know this information is a bit sketchy; on
|
||
most systems you will not need to give a value for `LIBS' at all.
|
||
|
||
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
|
||
system.
|
||
|
||
3. You should verify that `configure' worked correctly by checking
|
||
the files `conf.h' and `Makefile'.
|
||
|
||
There are two known problems on SCO 3.2.2 that `configure'
|
||
will not figure out. The default version of `memmove' is buggy,
|
||
so unless you have patched it you should set `HAVE_MEMMOVE' to 0.
|
||
The `ftime' function will sometimes go backward in time by
|
||
almost a second; this will not cause any real harm, but it will
|
||
garble your transfer time statistics so you may want to set
|
||
`HAVE_FTIME' to 0.
|
||
|
||
If you find any problems in `conf.h' and `Makefile' please
|
||
tell me about them so that I can fix them or at least add more
|
||
warnings here.
|
||
|
||
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
|
||
just ask for help.
|
||
|
||
|
||
File: uucp.info, Node: Testing, Next: Installation, Prev: Compilation, Up: Overall Installation
|
||
|
||
Testing Taylor UUCP
|
||
===================
|
||
|
||
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
|
||
them.
|
||
|
||
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
|
||
`/usr/tmp/tstuu/spool2'.
|
||
|
||
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 config file::.). 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
|
||
`/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 `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
|
||
happens.
|
||
|
||
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 sys file::.). 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
|
||
around them.
|
||
|
||
|
||
File: uucp.info, Node: Installation, Next: Usage, Prev: Testing, Up: Overall Installation
|
||
|
||
Installing Taylor UUCP
|
||
======================
|
||
|
||
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
|
||
`make uninstall'.
|
||
|
||
|
||
File: uucp.info, Node: Usage, Next: TCP, Prev: Installation, Up: Overall Installation
|
||
|
||
Using Taylor UUCP
|
||
=================
|
||
|
||
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
|
||
|
||
uucico -r1
|
||
|
||
Whenever you want to call a specific system foo, use
|
||
|
||
uucico -s foo
|
||
|
||
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
|
||
|
||
Under `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, *Note
|
||
Configuration files::. Basically when definining the system put in
|
||
the line `port type tcp' and, if necessary, `port service XXX' where
|
||
XXX is the port number to use (the default is to look up `uucp' in
|
||
`/etc/services' and if not found to use port 540). You can specify
|
||
the address of the remote host with `address a.b.c'. If you don't
|
||
specify 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
|
||
`L.sys':
|
||
|
||
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
|
||
some chat script.
|
||
|
||
If you are using BNU configuration files, add a line like this to
|
||
Systems:
|
||
|
||
foo Any TCP - foo.domain chat-script
|
||
|
||
and a line like this to Devices:
|
||
|
||
TCP uucp - -
|
||
|
||
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. 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:', and the
|
||
results will be checked against the UUCP (not the system) password
|
||
file (*note config file::.). 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: Acknowledgements, 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
|
||
`conf.h'.
|
||
|
||
All the configuration files follow a simple line-oriented keyword
|
||
value format. The first word on each line is a keyword of some sort
|
||
(empty lines are ignored, as are leading spaces; unlike BNU, lines
|
||
with leading spaces are read). 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, and 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 `#') (the backslash is not a general quoting character;
|
||
to enter the sequence `\#', you would use `\\#'). 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.
|
||
|
||
* Menu:
|
||
|
||
* config file:: The main configuration file
|
||
* sys file:: The system configuration file
|
||
* port file:: The port configuration files
|
||
* dial file:: The dialer configuration files
|
||
* Example:: Brief example of configuration files
|
||
|
||
|
||
File: uucp.info, Node: config file, Next: sys file, Prev: Configuration files, Up: Configuration files
|
||
|
||
The main configuration file
|
||
===========================
|
||
|
||
The main configuration file may be specified by the `-I' option to
|
||
`uucico' (and all the other programs as well). It is named `config'
|
||
and is in the directory NEWCONFIGDIR which is defined by the Makefile
|
||
variable `newconfigdir' (by default it is `/usr/local/lib/uucp'). As
|
||
all the values that may be specified in it also have defaults, there
|
||
need not be a main configuration file at all.
|
||
|
||
`nodename STRING'
|
||
`hostname STRING'
|
||
`uuname STRING'
|
||
These keywords are equivalent. They specify the UUCP name of the
|
||
local host. If there is no configuration file, an appropriate
|
||
function will be used to get the host name, if possible.
|
||
|
||
`spool STRING'
|
||
Specify the spool directory. The default is from `sysdep.h'.
|
||
Command files, work files, temporary files, log files, etc., are
|
||
stored in this directory and in subdirectories of it.
|
||
|
||
`sysfile STRINGS'
|
||
Specify the system file(s). The default is the file `sys' in the
|
||
directory NEWCONFIGDIR. These files holds information about other
|
||
systems with which this system communicates; *Note sys file::.
|
||
Multiple system files may be specified by given on the line, and
|
||
the `sysfile' command may be repeated; each system file has its
|
||
own set of defaults.
|
||
|
||
`portfile STRINGS'
|
||
Specify the port file(s). The default is the file `port' in the
|
||
directory NEWCONFIGDIR. These files describe ports which are
|
||
used to call other systems and accept calls from other systems;
|
||
*Note port file::. No port files need be named at all. Multiple
|
||
port files may be given on the line, and the `portfile' command
|
||
may be repeated.
|
||
|
||
`dialfile STRINGS'
|
||
Specify the dial file(s). The default is the file `dial' in the
|
||
directory NEWCONFIGDIR. These files describe dialing devices
|
||
(modems); *Note dial file::. No dial files need be named at all.
|
||
Multiple dial files may be given on the line, and the `dialfile'
|
||
command may be repeated.
|
||
|
||
`dialcodefile STRINGS'
|
||
Specify the dialcode file(s). The default is the file `dialcode'
|
||
in the directory NEWCONFIGDIR. These files specify dialcodes that
|
||
may be used when sending phone numbers to a modem. This permits
|
||
using the same set of phone numbers in different area-codes or
|
||
with different phone systems, by using dialcodes to specify the
|
||
calling sequence. When a phone number goes through dialcode
|
||
translation, the leading alphabetic characters are stripped off.
|
||
The dialcode files are read line by line, just like any other
|
||
configuration file, and when a line is found whose first word is
|
||
the same as the leading characters from the phone number, the
|
||
second word on the line (which would normally consist of numbers)
|
||
replaces the dialcode in the phone number. No dialcode file need
|
||
be used. Multiple dialcode files may be specified on the line,
|
||
and the `dialcodefile' command may be repeated; all the dialcode
|
||
files will be read in turn until a dialcode is located.
|
||
|
||
`pubdir STRING'
|
||
Specify the public directory. The default is from `sysdep.h'. On
|
||
Unix, when a file is named using a leading `~/', it is taken from
|
||
or to the public directory. Each system may use a separate public
|
||
directory by using the `pubdir' command in the system
|
||
configuration file; *Note sys file::.
|
||
|
||
`callfile STRINGS'
|
||
Specify the call out login name and password file(s). The
|
||
default is the file `call' in the directory NEWCONFIGDIR. If the
|
||
call out login name or password for a system are given as `*'
|
||
(*note sys file::.), these files are read to get the real login
|
||
name or password. Each line in the file(s) has three words: the
|
||
system name, the login name, and the password. This file is only
|
||
used when placing calls to remote systems; the password file
|
||
described under `passwdfile' below is used for incoming calls.
|
||
The intention of the call out file is to permit the system file
|
||
to be publically readable; the call out files must obviously be
|
||
kept secure. These files need not be used. Multiple call out
|
||
files may be specified on the line, and the `callfile' command
|
||
may be repeated; all the files will be read in turn until the
|
||
system is found.
|
||
|
||
`passwdfile STRINGS'
|
||
Specify the password file(s) to use for login names when `uucico'
|
||
is doing its own login prompting, which it does when given the
|
||
`-e', `-l' or `-w' switch. The default is the file `passwd' in
|
||
the directory NEWCONFIGDIR. Each line in the file(s) has two
|
||
words: the login name and the password (e.g. `Ufoo foopas'). The
|
||
login name is accepted before the system name is known, so these
|
||
are independent of which system is calling in; a particular login
|
||
may be required for a system by using the `called-login' command
|
||
in the system file (*note sys file::.). These password files are
|
||
optional, although one must exist if `uucico' is to present its
|
||
own login prompts. Multiple password files may be specified on
|
||
the line, and the `passwdfile' command may be repeated; all the
|
||
files will be read in turn until the login name is found.
|
||
|
||
`logfile STRING'
|
||
Name the log file. The default is from `sysdep.h'. Logging
|
||
information is written to this file. If `HAVE_BNU_LOGGING' is
|
||
defined in `conf.h', then by default a separate log file is used
|
||
for each system. Using this command to name a log file will
|
||
cause all the systems to use it.
|
||
|
||
`statfile STRING'
|
||
Name the statistics file. The default is from `sysdep.h'.
|
||
Statistical information about file transfers is written to this
|
||
file.
|
||
|
||
`debugfile STRING'
|
||
Name the file to which debugging information is written. The
|
||
default is from `policy.h'. This command is only effective if
|
||
the code has been compiled to include debugging (this is
|
||
controlled by the `DEBUG' variable in `policy.h'). After the
|
||
first debugging message has been written, messages written to the
|
||
log file are also written to the debugging file to make it easier
|
||
to keep the order of things straight. The debugging file is
|
||
different from the log file because information such as passwords
|
||
can appear in it, so it must be not be publically readable.
|
||
|
||
`debug STRING ...'
|
||
Set the debugging level. This command is only effective if the
|
||
code has been compiled to include debugging. The default is to
|
||
have no debugging. The arguments are strings which name the
|
||
types of debugging to be turned on. The following types of
|
||
debugging are defined:
|
||
|
||
`chat'
|
||
Output debugging messages for chat scripts.
|
||
|
||
`handshake'
|
||
Output debugging messages for the initial handshake.
|
||
|
||
`proto'
|
||
Output debugging messages for protocols.
|
||
|
||
`port'
|
||
Output debugging messages for actions on the communication
|
||
port.
|
||
|
||
`config'
|
||
Output debugging messages while reading the configuration
|
||
files.
|
||
|
||
`spooldir'
|
||
Output debugging messages for actions in the spool directory.
|
||
|
||
`execute'
|
||
Output debugging messages whenever another program is
|
||
executed.
|
||
|
||
`incoming'
|
||
List all incoming data in the debugging file.
|
||
|
||
`outgoing'
|
||
List all outgoing data in the debugging file.
|
||
|
||
`all'
|
||
All of the above.
|
||
|
||
The debugging level may also be specified as a number. A 1 will
|
||
set `chat' debugging, a 2 will set both `chat' and `handshake'
|
||
debugging, and so on down the possibilities. Currently a 9 will
|
||
turn on all possible debugging, since there are 9 types of
|
||
debugging messages listed above; more debugging types may be
|
||
added in the future. The `debug' command may be used several
|
||
times in the configuration file; every debugging type named will
|
||
be turned on. When running any of the programs, the `-x' switch
|
||
(actually, for `uulog' it's the `-X' switch) may be used to turn
|
||
on debugging. The argument to the `-x' switch is one of the
|
||
strings listed above, or a number as described above, or a comma
|
||
separated list of strings (e.g. `-x chat,handshake'). The `-x'
|
||
switch may also appear several times on the command line, in
|
||
which case all named debugging types will be turned on. The `-x'
|
||
debugging is in addition to any debugging specified by the
|
||
`debug' command; there is no way to cancel debugging information.
|
||
The debugging level may also be set specifically for calls to or
|
||
from a specific system with the `debug' command in the system
|
||
file (*note sys file::.).
|
||
|
||
The debugging messages are somewhat idiosyncratic, and it may be
|
||
necessary to refer to the source code for additional information
|
||
in some cases.
|
||
|
||
`unknown STRING ...'
|
||
The STRING and subsequent arguments are treated as though they
|
||
appeared in the system file (*note sys file::.). They are used
|
||
to apply to any unknown systems that may call in, probably to set
|
||
file transfer permissions and the like. If the `unknown' command
|
||
is not used, unknown systems are not permitted to call in.
|
||
|
||
`max-uuxqts NUMBER'
|
||
Specify the maximum number of `uuxqt' processes which may run at
|
||
the same time. Having several `uuxqt' processes running at once
|
||
can significantly slow down a system, but since `uuxqt' is
|
||
automatically started by `uucico', it can happen quite easily.
|
||
The default for `max-uuxqts' is 0, which means that there is no
|
||
limit. If BNU configuration files are being read and the code
|
||
was compiled without `HAVE_TAYLOR_CONFIG', then if the file
|
||
`Maxuuxqts' in the configuration directory contains a readable
|
||
number it will be used as the value for `max-uuxqts'.
|
||
|
||
`v2-files BOOLEAN'
|
||
If the code was compiled to be able to read V2 configuration
|
||
files, a false argument to this command will prevent them from
|
||
being read. This can be useful while testing. The default is
|
||
true.
|
||
|
||
`bnu-files BOOLEAN'
|
||
If the code was compiled to be able to read BNU configuration
|
||
files, a false argument to this command will prevent them from
|
||
being read. This can be useful while testing. The default is
|
||
true.
|
||
|
||
|