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.
Go to the first, previous, next, last section, table of contents.