|
|
| Previous | Table of Contents | Next |
The log files on V2 are quite different from HDB log files. Unlike HDB, all of the log entries are placed into a single file in /usr/spool/uucp, appropriately named LOGFILE. A second file exists called SYSLOG, which records the actual amount of data transferred and the time it took to do it. The LOGFILE will grow continually. If you are running short of disk space, this is the first place to check.
An entry from LOGFILE looks like this:
user system date/time comment root unilabs (2/12-5:42) NO (AVAILABLE DEVICE) root unilabs (2/12-5:42) FAILED (call to unilabs ) root unilabs (2/12-5:59) QUEUED (C.unilabsn0297) root unilabs (2/12-5:59) QUEUED (C.unilabsn0298) root unilabs (2/12-5:59) SUCCEEDED (call to unilabs ) root unilabs (2/12-5:59) HANDSHAKE FAILED (LOGIN) unilabs unilabs (2/12-18:35) OK (startup)
In the next few entries, you can see that the files /tmp/spool and /tmp/sys were sent to unilabs. Files that are sent show in a REQUEST entry with an S followed by the name of the file.
root unilabs (2/12-18:35) REQUEST (S /tmp/spool ~ root) root unilabs (2/12-18:35) REQUEST (SUCCEEDED) root unilabs (2/12-18:35) REQUEST (S /tmp/sys ~ root) root unilabs (2/12-18:35) REQUEST (SUCCEEDED) root unilabs (2/12-18:35) OK (conversation complete)
These log entries don’t contain as much information as the log files in HDB, but fortunately you have a second log file, SYSLOG, that can be examined for other important information.
The SYSLOG file contains information of the actual transfer. The first few examples shown here indicate that this machine received data from the remote machine, unilabs.
user system date/time secs comments chare unilabs (11/21-22:56) (722404580) received data 148 bytes 2 secs chare unilabs (11/21-22:56) (722404593) received data 1197 bytes 6 secs chare unilabs (11/21-22:56) (722404601) received data 148 bytes 1 secs
These entries relate to the two files you saw transferred in the LOGFILE, namely /tmp/sys and /tmp/spool. These two files were sent from bugs to unilabs.
root unilabs (2/12-18:35) (729560123) sent data 97 bytes 0 secs root unilabs (2/12-18:35) (729560125) sent data 115 bytes 0 secs
It takes time to process and review logfile information. Consequently, an understanding of this information is essential to the system troubleshooter.
Version 2 maintenance is simplified somewhat through the use of the uuclean command, which operates a lot like HDB. The uuclean command cleans up the UUCP spool directory (/usr/spool/uucp, typically) somewhat intelligently. For systems that cannot be reached, a mail message is sent back to the originator. uuclean works by deleting locally created rnews files, executing remotely created rnews files, and removing everything that shouldn’t be there.
The periodic removal of logfiles should also be performed to eliminate redundant UUCP log information and free up disk space. However, the original Version 2 UUCP implementation cannot perform this task automatically.
Although some feel that using the UUCP protocol over the TCP/IP transport is redundant, it can be useful at times. If, for example, you have been using a Usenet news feed over UUCP, you can switch to a TCP/IP transport until you are ready to implement INN or some other TCP/IP-based news server software using your existing implementation. UUCP use over TCP/IP is restricted to the Basic Networking Utilities, which are also known as HoneyDanBer UUCP.
Two files need to be changed before TCP/IP can be used as the transport: the Systems and Devices files. Although the UUCP g protocol can be used, the UUCP e protocol is optimized for the transport characteristics of TCP/IP. The desired protocol type is included with the device identification. Because the UUCP g protocol has extensive error-checking built into it, it is considered to be a waste of resources when used with a high-speed connection such as TCP/IP. In this case, protocol e is often used. To define the protocol, follow the dataport with a comma and the protocol to use, as shown in the following example:
TCPnet TCP,e …
Aside from direct serial and modem connections, UUCP also supports connections over other transports, such as TCP/IP and the Streams-based TLIS connections. Connections using the TLIS are not directly supported by all vendors of Unix.
TLIS connections are configured in the Devices file. It is possible to configure TLIS to make a connection with or without the Network Listener Service. TCP/IP connections do not use this service. To establish a direct connection to another machine using the TLIS, but not the Network Listener, the device entry would be as follows:
STARLAN,eg starlan - - TLIS \D
This would define an entry to access the STARLAN network, and enable both the ‘e’ and ‘g’ protocols to be used, depending on what was determined at connect time. The device being used is called starlan, with no dialer-port or speed associated with the device. The dialer-token is set to TLIS, and the \D instructs uucico to use the phone number, which is defined in the Systems file.
The TCP/IP entry for the device file looks quite similar to the TLIS network device:
TCP TCP,e - Any TCP 540
This entry defines a device called TCP that uses the UUCP e protocol. This TCP keyword is known to UUCP systems that support TCP/IP connections. Notice that the protocol in use here is protocol e, which is the best choice when using end-to-end error free connections. There is no dialer port, and the speed of the connection in this example is Any. The dialer used is TCP, and the TCP/IP port number is defined as 540 for connecting to the remote machine.
To use either the TLIS or the TCP transports, the administrator of the other system must have previously configured his or her system to allow a connection in this manner.
Although it works, the configuration and use of the TCP/IP transport is not common for UUCP. It is more common for UUCP to be completely removed when TCP/IP is placed into operation.
The following two programs can assist you in analyzing log files and building a secure USERFILE for use with Version 2 UUCP.
| Previous | Table of Contents | Next |