UUCP Versions UUCP Chat−Transfer Session

UUCP also supports Usenet, a bulletin−board network that uses the public domain Netnews software to exchange news about a wide variety of topics. 24.4.1 How Does UUCP Work? Using UUCP basically means dealing with three main programs: uucp, for a file transfer to or from a remote machine similar to the cp program; however, with extended addressing capabilities 1. uux, for a command execution on a remote machine usually restricted in some way because of security reasons 2. mail, a version of a mail program that is compatible with UUCP this is binmail; it should not be confused with usrucbmail that is an e−mail user agent that was discussed in the Chapter 20 3. The listed programs are user related, i.e., they are primarily used from the command line. However, it happens much more in the background; two running UUCP daemons, uucico and uuxqt, invisible to users actually do most of the work. uucico is involved in transferring files and remote execution requests between UNIX systems, and uuxqt in their processing on a remote UNIX system. UUCP is a store−and−forward subsystem: requests for transfer and remote processing are not executed immediately; instead they are spooled for later execution. UUCP daemons take care of spooled requests and process them once the connection between remote UNIX systems has been established. A more detailed description of what happens is: When uucp or uux programs are invoked, a work file containing information about the source and destination files, the program options, and the type of requests is created in the directory usrspooluucp. If a file transfer was required, a file to be transferred is also copied. • The uucico daemon is involved to make the transfer; it scans the spool directory for work files and attempts to contact specified remote UNIX systems and execute the instructions in the work files. In the BNU UUCP version, an intermediate process called uusched does the scan and calls uucico when the needed conditions are met. • The work files contain only a part of the information uucico needs to know: what to do, but not when or how to do it. This information is contained in a set of the UUCP configuration files in the directory usrlibuucp, and this is a duty of the system administrator to set up in advance. •

24.4.2 UUCP Versions

The first UUCP system was built in 1976 at ATT Bell Laboratories, and this version was known as Version 2 UUCP. It was distributed with UNIX Version 7 in 1977. Updated versions were already incorporated in the SVR1 and SVR2 platforms. 602 With SVR3, a new upgraded version known as BNU an acronym for basic network utility began to be distributed. This version wasis also known as HoneyDanBer UUCP. Further UUCP improvement and update continued on both major UNIX platforms. The BSD 4.3s UUCP presented another significant update, merging some BNU features while retaining more continuity with other Version 2 UUCP implementations. The trend has continued up to the present time. Typically, as for all of UNIX, different UUCP flavors and versions have much in common, and they provide the very same tasks. A kind of generalization could be to say that the BSD−like UNIX platforms were primarily oriented toward the Version 2 UUCP, while the System V−like UNIX platforms were BNU UUCP oriented. We will discuss this topic bearing in mind both major UUCP versions, underlying specific differences as they appear. How can we be sure about a running UUCP version? By listing the usrlibuucp directory and searching for some typical files, we can conclude something; if the file L.sys is there, this is Version 2 UUCP; otherwise, the file Systems belongs to BNU UUCP. The UUCP home directory has been changed; for example on SunOS, the file etcuucpL.sys existed. Nowadays, Solaris, HP−UX and other modern UNIX flavors, keep UUCP configuration files in the etcuucp directory.

24.4.3 UUCP Chat−Transfer Session

Assuming the basic idea of how UUCP works, let us analyze in more detail a UUCP session. Lets suppose a hypothetical case: Two remote UNIX hosts: red and blue have all the facilities to communicate over the telephone network. • A UUCP file transfer from the host red for the host blue is initiated. • Both hosts are set up appropriately. • The last line saying: set up appropriately is the crucial one; the way the hosts would communicate absolutely depends on the way the UUCP subsystems are configured. Everything is written in the UUCP configuration file: on a BNU UUCP subsystem the etcuucpSystems file earlier usrlibuucpSystems, or on a Version 2 UUCP subsystem the etcuucpL.sys file or usrlibuucpL.sys. A corresponding configuration entry at the host red would look like: blue Any ACU 19200 3217654 ogin: iamred ssword: passme This entry defines that the system red can call the system blue: At any time • Over a modem connected to a telephone line ACU = Automatic Calling Unit • At a speed of 19200 bps • Using the telephone number 3217654 • Logging in with login name: iamred • Identifying with password: passme • A UUCP session for the supposed configuration data starts with a users command at the host red 603 If there are multiple ways to reach a remote host, it could be multiple entries for that host in the configuration file. However, the configuration file Systems or L.sys only includes a designation for the specified connection; it does not describe the implemented hardware. Another file, Devices in BNU or L−devices in Version 2, contains one−to−one mapping between the designated connection and what device name the daemon uucico should use to access the actual device for example, the serial line to use. If a device is a modem, additional needed information how to dial could be found in the file acucap, or Dialers in BNU or modemcap in Version 2. In the early days of UUCP, some UUCP versions even had dialing instructions hardcored into the uucp program. There are several reasons why the file transfer may not occur immediately. First, the transfer can be restricted to a particular time through the configuration file itself; second, the telephone line can be busy at that very moment. In that case, uucico will leave the corresponding status file and try again the next time it is invoked. The procedure will repeat until successful transfer is performed, or the minimum retry period has elapsed by default, 55 or 60 minutes. The file transfer is performed between two uucico daemons, on the source and the destination host. The uucico on the source calling system is playing master role — it controls the link; the uucico on the destination receiving system plays slave role — it checks local permissions to authorize the transfer. Two daemons communicate chat between themselves; when nothing is left to be transferred in either direction, they agree to hang up. At that point, another daemon uuxqt is invoked to scan the spool directory for any outstanding execution request from the remote system. If such a request exists, uuxqt forks a command to do what the user asked for. We will return to the UUCP configuration files later.

24.5 UUCP Commands, Daemons, and Related Issues