DEBUGGING UUCP PROCEDURES

Posted by admin

May 6, 2008

So, what if your transfer did not go through? Well, this section will
detail how to find out what went wrong, and how to correct the situation.
UULOG
—–
The uulog command is used to draw up a log of transactions with remote
systems. You can either draw up the entries by system name, or the name of the
user who initiated the transaction.
For our purposes, we only want to draw up the log by system name. The format
is:
uulog -s[system name]
Now, this will pull up the logs for ALL transactions with this particular
system. We only want the logs for the last attempted transaction with the
system. Unfortunately, this can’t be done, you’ll just have to sort through the
logs until you reach the sequence of the last transaction. If the logs extend
back a long time, say about a week, however, you can use the grep command to
call up the logs only for a certain date:
uulog -s[system] | grep mm/dd-
Where mm is the month (in the form ##, such as 12 or 01) and dd is the day, in
the same form). This takes the output of the uulog command, and searches
through it with the grep command and only prints out those entries which
contain the date the grep command is searching for. The log entries will be in
the form:
[username] [system] (month/day-hour:minute-pid) DESCRIPTION
Where:
username -Is the userid of the account that initiated the transaction.
system -Is the name of the system that the transaction was attempted
with.
month/day -Date of transaction.
hour:minute -Time of transaction.
job number -The transfer’s process id.
DESCRIPTION -The log message.
An example of a typical log entry:
root ripco (11/20-2:00-1234) SUCCEEDED (call to ripco)
In the above example, the root account initiated a transaction with the Ripco
system. The system was contacted on November 20, at 2:00. The job number of the
transaction is 1234.
Here is an explanation of the various log messages you will encounter, and
their causes:
1. SUCCEEDED (call to [system name])
The system was successfully contacted.
2. DIAL FAILED (call to [system name])
Uucp failed to contact the system. The phone number entry for the system in the
Systems file may be wrong, or in the wrong format.
3. OK (startup)
Conversation with the remote system has been initiated.
4. LOGIN FAILED
Uucp was unable to log into the remote system. There may be an error in the
login field in the entry for the remote system in the Systems file, or line
noise may have caused the login to fail.
5. WRONG SYSTEM NAME
The system’s entry in the Systems file has the wrong name for the system at the
phone number specified in the entry.
6. REMOTE DOES NOT KNOW ME
The remote system does not recognize the name of the local system, and will not
perform transactions with an unknown system (some will, some won’t…see the
section on uucp security).
7. REQUEST ([remote file] –> [local file] username)
The file transfer has been requested.
8. OK (conversation complete)
The transfer has been completed.
9. ACCESS DENIED
Security measures prevented the file transfers.
If you get this error, you will receive mail on the local system informing you
that the transfer was denied by the remote.
10. DEVICE LOCKED
All the dialout devices were currently in use.
A successful transaction log will usually look like this:
root ripco (11/20-2:00-1234) SUCCEEDED (call to ripco)
root ripco (11/20-2:01-1234) OK (startup)
root ripco (11/20-2:01-1234) REQUEST (ripco!/etc/passwd –> /ripcofile root)
root ripco (11/20-2:03 1234) OK (conversation complete)
When an error occurs during a transfer with a system, a status file is
created for that system, and remains for a set period of time, usually about an
hour. During this time, that system cannot be contacted. These files, depending
on which version of Unix you are on, will either be in the directory
/usr/spool/uucp, and have the form:
STST..[system name]
or will be in the directory /usr/spool/uucp/.Status, and have the same name as
the system. These status files will contain the reason that the last transfer
attempt with the system failed. These files are periodically purged, and if you
wish to contact the system before its status file is purged, you must delete
its status file.
The files containing the failed transfer request will also remain. If you are
using the latest version of System V, these files will be in a subdirectory of
the directory /usr/spool/uucp. For instance, if the system is called ripco,
the files will be in the directory /usr/spool/uucp/ripco. On other systems,
these files will be in the directory /usr/spool/uucp/C., or /usr/spool/uucp.
These files are in the form:
C.[system name]AAAAAAA
Where [system name] is the name of the system to be contacted, and AAAAAA is a
the transfer’s uucp job number. (You can see the transfer request’s job number
by specifying the j option when you initiate the transfer. For example,
“uucp -j ripco!/etc/passwd /usr/spool/uucppublic/ripcofile” would initiate the
transfer of the ripco system’s password file, and display the job number on
your screen.) Type “cat C.system[jobnumber]”, and you will see something like
this:
R /etc/passwd /usr/pub/.dopeypasswd root -dc dummy 777 guest
On earlier versions of Unix, these files will be in the directory
/usr/spool/uucp/C. To find the file containing your transfer, display the
contents of the files until you find the proper one. If your transfer fails,
delete the transfer request file and the status file, correct any errors in the
Systems file or whatever, and try again!