After you have set up UUCP, maintenance is straightforward. This section explains ongoing UUCP tasks with regard to security, maintenance, and troubleshooting.
The default /etc/uucp/Permissions file provides the maximum amount of security for your UUCP links. The default Permissions file contains no entries.
You can set additional parameters for each machine to define:
Ways it can receive files from your machine
Directories for which it has read and write permission
Commands it can use for remote execution
A typical Permissions entry is:
MACHINE=datsun LOGNAME=Udatsun VALIDATE=datsun COMMANDS=rmail REQUEST=yes SENDFILES=yes |
This entry allows files to be sent and received (to and from the "normal" UUCP directories, not from anywhere in the system) and causes the UUCP user name to be validated at login time.
UUCP does not require much maintenance. Apart from making sure that the crontab file is in place, as described in the section "uudemon.poll Shell Script", all you have to worry about is the growth of mail files and the public directory.
All email messages generated by the UUCP programs and scripts go to the user ID uucp. If you do not log in frequently as that user, you might not realize that mail is accumulating (and consuming disk space). To solve this, make an alias in /etc/aliases and redirect that email either to root or to yourself and others responsible for maintaining UUCP. Don't forget to run the newaliases command after modifying the aliases file.
The directory /var/spool/uucppublic is the one place in every system to which UUCP by default is able to copy files. Every user has permission to change to /var/spool/uucppublic and read and write files in it. However, its sticky bit is set, so its mode is 01777. As a result, users cannot remove files that have been copied to it and that belong to uucp. Only you, as UUCP administrator logged in as root or uucp, can remove files from this directory. To prevent the uncontrolled accumulation of files in this directory, you should make sure to clean it up periodically.
If this is inconvenient for users, encourage them to use uuto and uupick rather than removing the sticky bit, which is set for security reasons. (See the uuto(1C) man page for instructions for using uuto and uupick.) You can also restrict the mode of the directory to only one group of people. If you do not want to run the risk of someone filling your disk, you can even deny UUCP access to it.
These procedures describe how to solve common UUCP problems.
You can check if the modems or other ACUs are not working properly in several ways.
Run uustat -q. This will give counts and reasons for contact failure.
Run cu -d -lline, where line is /dev/cua/a. This lets you call over a particular line and print debugging information on the attempt. The line must be defined as direct in the /etc/uucp/Devices file. (You must add a telephone number to the end of the command line if the line is connected to an autodialer or the device must be set up as direct.)
Verify that you have up-to-date information in your Systems file if you are having trouble contacting a particular machine. Some things that might be out of date for a machine are its:
If you cannot contact a particular machine, you can check out communications to that machine with Uutry and uucp.
To try to make contact, type /usr/lib/uucp/Uutry -r machine and press Return.
Replace machine with the host name of the machine you are having problems contacting. This command:
Starts the transfer daemon (uucico) with debugging. You can get more debugging information if you are root.
Directs the debugging output to /tmp/machine.
Prints the debugging output to your terminal (tail -f).
Press Control-c to end output. You can copy the output from /tmp/machine if you want to save it.
If Uutry doesn't isolate the problem, try to queue a job by typing uucp --r file machine\!/dir/file and press Return.
Replace file by the file you want to transfer, machine by the machine you want to copy to, and /dir/file where the file will be placed on the other machine. The r option queues a job but does not start the transfer.
Now use Uutry again.
If you still cannot solve the problem, you might need to call your local support representative. Save the debugging output; it will help diagnose the problem.
You might also want to decrease or increase the level of debugging provided by Uutry through the -x n option, where n indicates the debug level. The default debug level for Uutry is 5.
Debug level 3 provides basic information as to when and how the connection is established, but not much information about the transmission itself. Debug level 9, on the other hand, provides exhaustive information about the transmission process. Be aware that debugging occurs at both ends of the transmission. If you intend to use a level higher than 5 on a moderately large text, get in touch with the administrator of the other site and agree on a time for doing so.
UUCP has two types of error messages: ASSERT and STATUS.
When a process is aborted, ASSERT error messages are recorded in /var/uucp/.Admin/errors. These messages include the file name, sccsid, line number, and text. These messages usually result from system problems.
STATUS error messages are stored in the /var/uucp/.Status directory. The directory contains a separate file for each remote machine your computer attempts to communicate with. These files contain status information on the attempted communication and whether it was successful.
Several commands are available for checking basic networking information:
uuname - Use this command to list those machines your machine can contact.
uulog - Use this command to display the contents of the log directories for particular hosts.
uucheck -v - Run this command to check for the presence of files and directories needed by uucp. This command also checks the Permissions file and outputs information on the permissions you have set up.