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.