Olaf Kirch - Linux Network Administrator Guide, Second Edition

The exact location and naming of spool files may vary, depending on some compile-time options. HDB-compatible UUCPs generally store spool files in a /var/spool/uucp subdirectory with the name of the remote site. When compiled for Taylor configuration, UUCP creates subdirectories below the site-specific spool directory for different types of spool files.

At regular intervals, UUCP dials up the remote system. When a connection to the remote machine is established, UUCP transfers the files describing the job, plus any input files. The incoming jobs will not be executed immediately, but only after the connection terminates. Execution is handled by uuxqt, which also takes care of forwarding any jobs that are designated for another site.

To distinguish between more and less important jobs, UUCP associates a grade with each job. This is a single digit ranging from 0 through 9, A through Z, and a through z, in decreasing precedence. Mail is customarily spooled with grade B or C, while news is spooled with grade N. Jobs with higher grades are transferred earlier. Grades may be assigned using the -g flag when invoking uucp or uux.

You can also prohibit the transfer of jobs below a given grade at certain times. To do this we set the maximum spool grade that will be prohibited during a conversation. The maximum spool grade defaults to z, meaning all grades will be transferred every time. Note the semantic ambiguity here: a file is transferred only if it has a grade equal to or above the maximum spool grade threshold.

To understand why uucico needs to know particular information, a quick description of how it actually connects to a remote system is helpful.

When you execute uucico -s system from the command line, uucico first has to connect physically. The actions taken depend on the type of connection to open. Thus, when using a telephone line, it has to find a modem and dial out. Over TCP, it has to call gethostbyname to convert the name to a network address, find out which port to open, and bind the address to the corresponding socket.

A successful connection is followed by authorization. This procedure generally consists of the remote system asking for a login name and possibly a password. This exchange is commonly called the login chat . The authorization procedure is performed either by the usual getty/login suite, or on TCP sockets by uucico itself. If authorization succeeds, the remote end fires up uucico. The local copy of uucico that initiated the connection is referred to as master , and the remote copy as slave .

Next follows the handshake phase : the master sends its hostname plus several flags. The slave checks this hostname for permission to log in, send, and receive files, etc. The flags describe (among other things) the maximum grade of spool files to transfer. If enabled, a conversation count or call sequence number check takes place here. With this feature, both sites maintain a count of successful connections, which are compared. If they do not match, the handshake fails. This is useful to protect yourself against impostors.

Finally, the two uucico s try to agree on a common transfer protocol . This protocol governs the way data is transferred, checked for consistency, and retransmitted in case of an error. There is a need for different protocols because of the differing types of connections supported. For example, telephone lines require a "safe" protocol, which is pessimistic about errors, while TCP transmission is inherently reliable and can use a more efficient protocol that foregoes most extra error checking.

After the handshake is complete, the actual transmission phase begins. Both ends turn on the selected protocol driver. At this point, the drivers possibly perform a protocol-specific initialization sequence.

The master then sends all files queued for the remote system whose spool grade is high enough. When it has finished, it informs the slave that it is done and that the slave may now hang up. The slave now can either agree to hang up or take over the conversation. This is a change of roles: now the remote system becomes master, and the local one becomes slave. The new master now sends its files. When done, both uucico s exchange termination messages and close the connection.

If you need additional information on UUCP, please refer to the source code. There is also a really antique article floating around the Net, written by David A. Novitz, which gives a detailed description of the UUCP protocol. [90] It's also included in the 4.4BSD System Manager's Manual. The Taylor UUCP FAQ also discusses some details UUCP's implementation. It is posted to comp.mail.uucp regularly.

In this section, we describe the most important command-line options for uucico:

- - system, -s system

Calls the named system unless prohibited by call-time restrictions.

- S system

Calls the named system unconditionally.

- -master, -r1

Starts uucico in master mode. This is the default when -s or -S is given. All by itself, the -r1 option causes uucico to try to call all systems in the sys file described in the next section of this chapter, unless prohibited by call or retry time restrictions.

- -slave, -r0

Starts uucico in slave mode. This is the default when no -s or -S is given. In slave mode, either standard input/output are assumed to be connected to a serial port, or the TCP port specified by the -p option is used.

- -ifwork, -C

This option supplements -s or -S and tells uucico to call the named system only if there are jobs spooled for it.

- -debug type, -x type , -X type

Turns on debugging of the specified type. Several types can be given as a comma-separated list. The following types are valid: abnormal , chat , handshake , uucp-proto , proto , port , config , spooldir , execute , incoming , and outgoing . Using all turns on all options. For compatibility with other UUCP implementations, a number may be specified instead, which turns on debugging for the first n items from the above list.

Debugging messages will be logged to the Debug file below /var/spool/uucp .

In contrast to simpler file transfer programs, UUCP was designed to be able to handle all transfers automatically. Once it is set up properly, interference by the administrator should not be necessary on a day-to-day basis. The information required for automated transfer is kept in a couple of configuration files that reside in the /usr/lib/uucp directory. Most of these files are used only when dialing out.

To say that UUCP configuration is difficult would be an understatement. It is really a hairy subject, and the sometimes terse format of the configuration files doesn't make things easier (although the Taylor format is almost easy reading compared to the older formats in HDB or Version 2).

To give you a feel for how all the configuration files interact, we will introduce you to the most important ones and have a look at sample entries from these files. We won't explain everything in detail now; a more accurate account is given in separate sections that follow. If you want to set up your machine for UUCP, you had best start with some sample files and adapt them gradually. You can pick either those shown below or those included in your favorite Linux distribution.