These are the installation instructions for the Taylor UUCP package.
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 dialer 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 dialer file; see section The Dialer Configuration File. You will have to
invoke the dialer program via a shell script, since an exit code of 0 is
required to recognize success.
The 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.
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 `unix/spool.c'.
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 `conf.h' based on `conf.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'.
configure finds the
BSD install program, it will set this to `install -c -m
644'; otherwise, it will use `cp'.
sh or bash, 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 wierd
system, you may have to configure the package by hand. To do this, copy
the file `conf.h.in' to `conf.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 means nothing for uucp, but 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 `-posix' executes rmail, which in
turn executes sendmail, the later is run under 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
`-posix', instead I run gcc with `-D_POSIX_SOURCE', and
add `-lcposix' to `LIBS'.
configure worked correctly by checking
`conf.h' and the instances of `Makefile'.
configure script.
This package is in use at many sites, and has been running at `airs.com' for over a year. 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 program
should not be made setuid, because it will display passwords if it can
read them.
If your system supports 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 (if your
system supports STREAMS based pseudo-terminals, you must compile tstuu.c
with `-DHAVE_STREAMS_PTYS', at least at the moment; the STREAMS
based code was contributed by Marc Boucher).
To run tstuu, just type `tstuu' with no arguments while
logged in to the compilation directory (since it runs `./uucp',
`./uux' and `./uucico'). It 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. 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'.
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 does not seem to work under SunOS 4.1.1. This seems to be due to a bug in the implementation of ptys.
The 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'. You can test
uuxqt by running the command `./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 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 (see section Taylor UUCP 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 (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 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, 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, and a sample of the debugging file showing the problem. General questions such as "why doesn't uucico dial out" are impossible to answer without much more information.
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'.
Simply installing the executable files is not enough, however. You must also arrange for them to be used correctly.
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 there may be 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 works get transferred between the systems withing a reasonable
time period, you should arrange to periodically invoke uucico.
These periodic invocations are normally caused 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'.
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 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.
The file can be easily created using the `touch' command. The name
of a poll file currently depends on the type of spool directory you are
using, as set in `policy.h'. If you are using
SPOOLDIR_TAYLOR (the default), put something like this in your
`crontab' file:
touch /usr/spool/uucp/sys/C./C.A0000
In this example sys is the system you wish to call, and
`/usr/spool/uucp' is your UUCP spool directory.
If you are using SPOOLDIR_HDB, use
touch /usr/spool/uucp/sys/C.sysA0000
For example, 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, 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 check to call `uunet'.
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 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.
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', 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'.
News 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 when sending mail via UUCP. If you simply
replace any existing version of uux with the Taylor UUCP version,
this will probably happen automatically. However, if both versions
exist 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.
As noted in section Sending mail or news via UUCP, mail is sent by requesting a
remote execution of rmail. To receive mail, then, all that is
necessary is for UUCP to invoke rmail itself.
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.
You should also periodically trim the log files, as they will otherwise continue to 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
may be of use. There is a manual page for it in `contrib' as well.
If your system has a Berkeley style socket library, or a System V style TLI interface library, you can compile the code to permit making connections over TCP. Specifying that a system should be reached via TCP is easy, but nonobvious.
If you are using the new style configuration files, see section Taylor UUCP Configuration Files. Basically, you can just add the line `port type tcp' to the entry in the system configuration file. By default UUCP will get the port number by looking up `uucp' in `/etc/services'; if `uucp' is not found, port 540 will be used. You can set the port number to use with the command `port service xxx', where xxx can be either a number or a name to look up in `/etc/services'. You can specify the address of the remote host with `address a.b.c'; if you don't give an address, the remote system name will be used. You should give an explicit chat script for the system when you use TCP; the default chat script begins with a carriage return, which will not work with some UUCP TCP servers.
If you are using V2 configuration files, add a line like this to `L.sys':
sys Any TCP uucp host.domain chat-script
This will make an entry for system sys, 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 `host.domain', with some chat script.
If you are using HDB configuration files, add a line like this to Systems:
sys Any TCP - host.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 sys, 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 `host.domain', with some chat script.
The uucico daemon can also be run as a TCP server. To use the
default port number, which is a reserved port, uucico must be
invoked by root (or it must be set user ID to root, but I don't
recommend doing that).
Basically, you must define a port, either using the port file
(see section The Port Configuration File) if you are using the new configuration method or
with an entry in Devices if you are using HDB; there is no way to define
a port using V2. If you are using HDB 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 HDB it must be `TCP'). This will wait for incoming
connections, and fork off a child for each one. Each connection will be
prompted with `login:' and `Password:'; the results will be
checked against the UUCP (not the system) password file
(see section Configuration File Names).
Of course, you can get a similar effect by using the BSD uucpd
program.
You can also have inetd start up uucico with the `-l'
switch, which will cause it to prompt with `login:' and
`Password:' and check the results against the UUCP (not the system)
password file. This may be used in place of uucpd.