3. Installing Taylor UUCP

These are the installation instructions for the Taylor UUCP package.

3.1 Compiling Taylor UUCP
3.2 Testing the Compilation
3.3 Installing the Binaries
3.4 Configuring Taylor UUCP
3.5 Testing the Installation

3.1 Compiling Taylor UUCP

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 3.4 Configuring Taylor UUCP).

Follow these steps to compile the source code.

1. Take a look at the top of `Makefile.in' and set the appropriate values for your system. These control where the programs are 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 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:

   `CC'

   The C compiler. If this is not set, then if configure can find `gcc' it will use it, otherwise it will use `cc'.

   `CFLAGS'

   Flags to pass to the C compiler when compiling the actual code. If this is not set, configure will use `-g'.

   `LDFLAGS'

   Flags to pass to the C compiler when only linking, not compiling. If this is not set, configure will use the empty string.

   `LIBS'

   Libraries to pass to the C compiler. If this is not set, configure will use the empty string.

   `INSTALL'

   The program to run to install UUCP in the binary directory. If this is not set, then if configure finds the BSD install program, it will set this to `install -c'; otherwise, it will use `cp'.

   Suppose, for example, you want to set the environment variable `CC' to `rcc'. If you are using 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'.

   You can also pass other arguments to configure on the command line. Use `configure --help' for a complete list. Of particular interest:

   `--prefix=dirname'

   The directory under which all files are installed. Default `/usr/local'.

   `--with-newconfigdir=dirname'

   The directory in which to find new style configuration files. Default `prefix/conf/uucp'.

   `--with-oldconfigdir=dirname'

   The directory in which to find old style configuration files. Default `/usr/lib/uucp'.

   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.

3. Igor V. Semenyuk provided this (lightly edited) note about ISC Unix 3.0. The 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'.

4. On some versions of BSDI there is a bug in the shell which causes the default value for `CFLAGS' to be set incorrectly. If `echo ${CFLAGS--g}' echoes `g' rather than `-g', then you must set `CFLAGS' in the environment before running configure. There is a patch available from BSDI for this bug. (Reported by David Vrona).

5. On AIX 3.2.5, and possibly other versions, `cc -E' does not work, reporting `Option NOROCONST is not valid'. Test this before running configure by doing something like `touch /tmp/foo.c; cc -E /tmp/foo.c'. This may give a warning about the file being empty, but it should not give the `Option NOROCONST' warning. The workaround is to remove the `,noroconst' entry from the `options' clause in the `cc' stanza in `/etc/xlc.cfg'. (Reported by Chris Lewis).

6. You should verify that configure worked correctly by checking `config.h' and the instances of `Makefile'.

7. Edit `policy.h' for your local system. The comments explain the various choices. The default values are intended to be reasonable, so you may not have to make any changes.

   You must decide what type of configuration files to use; for more information on the choices, see 3.4 Configuring Taylor UUCP.

   You must also decide what sort of spool directory you want to use. If this is a new installation, I recommend `SPOOLDIR_TAYLOR'; otherwise, select the spool directory corresponding to your existing UUCP package.

8. Type `make' to compile everything.

   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. To use STREAMS pseudo-terminals, tstuu.c must be compiled with `-DHAVE_STREAMS_PTYS'; this is not determined by the configure script.

   If you have any other problems there is probably a bug in the configure script.

9. Please report any problems you have. That is the only way they will get fixed for other people. Supply a patch if you can (see section 7.3 Patches), or just ask for help.

3.2 Testing the Compilation

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 5.6.4 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.

3.3 Installing the Binaries

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.

3.4 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; see 5. 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 5.9 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 5.9 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 2.13 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 5. 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 2.12 Invoking uuchk.

3.5 Testing the Installation

After you have written the configuration files, and verified them with the uuchk program (see section 2.12 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 5.6.4 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 4.4.2 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 5.6.1 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.