UUCP: Administering BNU
Chris Hare In this article I describe how to set up BNU (or HoneyDanBer) UUCP. To do this, I look at the BNU files themselves and at a couple of the setup programs provided by UNIX vendors. In an earlier article, "UUCP -- A User's Perspective" (Sys Admin Jan/Feb 1993), I dealt with the history and layout of BNU and Version 2 UUCP; I won't repeat that material here. A later article will describe the administration of Version 2. What Is BNU? With AT&T's System V Release 3, a new UUCP version was released. This version was known by a number of names, most notably Basic Networking Utilities (BNU) or HoneyDanBer (HDB) UUCP. The latter name combined the login names of the people who created the new version -- Peter Honeyman ("Honey"), David A. Nowitz ("Dan"), and Brian E. Redman ("Ber"). Written in 1983, BNU was intended to provide functionality that Version 2 UUCP didn't have, and to correct some of that version's design deficiencies. Some of the new functionality provided support for newer modems and networks. To find out which version you have -- Version 2 or BNU -- look in the /usr/lib/uucp directory. If you find a Systems file, then you have BNU, and this article is for you. If you find L.sys, then wait for the later article on Version 2 UUCP. UUCP Layout UUCP is set up in three directories: /usr/bin, /usr/lib/uucp, and /usr/spool/uucp. Figure 1 lists the files included in /usr/bin and /usr/lib/uucp; your system's directories may contain other related files (SCO UNIX, for example, includes a number of other files such as binary dialer programs for specific modems). Configuring UUCP Only three files -- Devices, Systems, and Permissions -- in the /usr/lib/uucp directory must be modified in order to bring up a UUCP connection. Even if you leave all of the other files as they were shipped from the vendor, making the changes to these files will result in a functioning UUCP system. Since the files as shipped from vendors are typically full of comments, it may not actually be necessary to remove the documentation from the shelf. Naming Your Host Before you select a UUCP name for your host system, you need to be aware of the various ways in which your system is identified. You can use the uuname command to determine the various names: uuname -s will return the name of the operating system, while uuname -n (or hostname, on systems that support this command) will give you the nodename or hostname. The operating system name is not part of UUCP, but is inherent in the operating system itself. Many implementations of UUCP limit the number of characters allowable in the UUCP name to six or seven, and so the UUCP name may not even be the same as the node name. Even though you can use longer names in the commands, the names of the different machines should be unique for the first seven characters. If you are not connected to Usenet or the Internet, then you basically have a free hand in naming your machines. However, if you are part of Usenet, then you should contact your Usenet hookup and ask them to find out if the name you want is already in use. Alternatively, you can ask your local UUCP registry to verify that the machine which you are connecting doesn't have a name conflict with another machine. The actual mechanism for changing or setting the system name depends upon the UNIX derivative you are using. On SCO UNIX, for example, the name is generally compiled into the kernel, while SCO XENIX uses the file /etc/systemid. You will need to check your system documentation to determine the method by which the system name is defined. The Devices File The Devices file, in /usr/lib/uucp, defines the devices that can be used to establish a connection. These devices range from serial lines direct to another computer, to modems and UUCP over TCP/IP or X.25 connections. The Devices file controls the physical devices available for carrying UUCP connections and specifies their configuration parameters. Each entry consists of the following fields: name, device, dataport, dialer-port, speed, dialer-token pairs (see Figure 2 for examples of entries in a Devices file). The name field contains the name or type of the device. The entry in this field must match the entry in the third field of the corresponding entry in the Systems file. The allowable values for this field -- and the device types they represent -- are: ACU -- an Automatic Call Unit, or modem. The modem may be directly attached to the computer or accessed through a LAN switch, according to the UUCP documentation. ACUs or modems are typically attached directly to the system. Direct -- a Direct link to a remote system, modem, or LAN Switch. The uucico program does not use lines of this type, only cu does. The uppercase "D" is an important clue when looking at the available dialers. For modems a Direct line is also defined so that a command like cu -l tty?? will work. This entry is also useful for configuring the modem. sysname -- an entry for connection to a specific system, perhaps using some other specialized dialer for routing through a LAN switch. The dataport field identifies the actual device to be used to establish the connection. For direct serial and modem links, this will contain the name of the actual device. For TCP connections, this field will say "TCP." Optionally, you can specify the protocol for connections that make use of a specific device. For most connections, the UUCP protocol g is used. Since this protocol has intensive error-checking built in, it represents 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, enter the dataport, followed by a comma and the appropriate protocol (note that not all systems will support either the protocol selection or TCP connections).
TCPnet TCP,e ...
The dialer-port field is a carryover from the days where the dialer was separate from the modem. This is an optional field, and may be used if the Name keyword is "ACU," and the dialer is an 801 dialer. If you don't have an 801 dialer, then put a hyphen (-) in this field. The speed field identifies the transmittal speed at which connections will be accepted for this device. The field may contain a single speed, such as 2400, or it may contain the word "Any," which will match any requested speed, as defined in the Systems file. The dialer-token pairs field contains (1) the name of the dialer program to be used with this modem dialer, and (2) the token that identifies the type of processing to be used on the phone number. It's often the case that no token is used. The two tokens available areT, which advises uucico that the phone number should be processed using the dialcodes file, andD, which indicates that the phone number in the Systems file is to be used. The dialer program can be a binary program in some implementations of UUCP, direct for use with direct serial connections, or the name of a dialer program which is in the Dialers file. Along with direct serial and modem connections, UUCP also supports connections over other transports, such as TCP/IP and the Streams-based TLIS connections (though not all UNIX vendors support connections using TLIS). TLIS connections are configured in the Devices file using the syntax described here. It is possible to configure TLIS to make a connection with or without the Network Listener Service. To establish a direct connection to another machine using the TLIS, but not the Network Listener, the device entry would be:
STARLAN,eg starlan - - TLISD
This would define an entry to access the STARLAN network, and would allow both the e and g protocols to be used, depending upon what was determined at connect time. The device being used is called starlan, and no dialer-port or speed is associated with the device. The dialer-token is set to TLIS, to use this service, and the \D instructs uucico to use the phone number as 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, using a device called TCP, which is a keyword known to UUCP systems which support TCP/IP connections. Notice that the protocol in use here is protocol e, which is for use over end-to-end error-free connections. As in the STARLAN example, there is no dialer port, and the speed of the connection in this example is Any. The dialer used is TCP, with the TCP/IP port number to connect to on the remote machine defined as 540, which is defined in the system's /etc/services file. In order to use either the TLIS or the TCP transports, the systems at both ends of the transaction must have been configured to allow such connections. All of the device files to be used by UUCP must be owned by uucp and have a group of uucp. Failure to properly set file ownership and permissions will result in error messages about not being able to access the device in question. Testing the Connection Before going on to set up the Systems file, you can use the cu command to test the connection set up by the device definition. As an example, here's a device definition from the Devices file on which I am working:
bugs tty21 - 9600 direct Direct tty21 - 9600 direct
Figure 3 shows how to use cu to see if the connection is "live." If no communication is established with the remote machine, it's a good idea to debug the actual connection by verifying the media used to make the connection. In the example above, it would be a matter of making sure that the cable is plugged in at both ends, that the other machine is running, and that the port enabled for login. If that doesn't correct the problem, then there may be trouble with the cable. In any case, once the connection has been verified, it's reasonable to continue with the setup of the other UUCP files. The Dialers File The Dialers file contains a series of characters which will be sent to a modem to initiate a phone call. In some UUCP implementations, the dialer programs may be binary. Each entry in the Dialers file has three parts:
Type 801 Char SCript
The "Type" defines the type of device. The second field, which provides the translations for the 801 dialer codes, isn't used anymore and is typically filled with =,-,. The third field is a chat script which works similarly to the chat script in the Systems file. The chat script is a series of expect-send pairs, meaning, I expect this, and send this. The special characters, which are preceded with a backslash (\), are defined in Table 1. In the following sample entry in a Dialers file
Type 801 Char SCript hayes =,-, "" \dAT\r\c OK\r ATL1M1\r\c \ OK\r \ \EATDT,,\T\r\c CONNECT intacu ==-, "" \K\dEN\dAT\r\c : Q\c + \ \021\c "" \pEN\c + \0041 + AT\r\c : \ D\T\r\c COMPLETE TBIT =W-, "" ATZ\r\c OK\r A\pA\pA\pT OK\ ATQ4E0X0 OK\r ATS53=1S48=1S50=255 \ S51=255S101=0S111=30\r\c\ OK\r \ ATDT\T\r\c CONNECT
the hayes entry defines a Hayes 2400-baud modem; intacu defines the 1200-baud internal modem; and TBIT defines a Telebit Trailblazer Plus. The hayes entry chat script can be broken down as follows:
Expect Send "" (nothing) \dAT\r\c (delay, send AT) OK\r ATL1M1\r\c OK\r \EATDT,,\T\r\c CONNECT
What the chat script is really doing is communicating with and configuring the modem prior to making the call. The Send sequence \EATDT,,\T\r\c tells the modem to turn on echo and dial the phone number. The dialer token \T causes the phone number to be put in place when the script is actually used. As I mentioned earlier, there are other methods of communicating with the device. Both SCO UNIX and SCO XENIX support binary programs as the dialer, and a generic dialer program that uses configuration files to define what is to be sent is also available. The Systems File The next step in getting BNU up and running is to set up the Systems file so that calls can be made by uucico and cu. The Systems file defines the names of the UUCP systems from which calls will be expected (and allowed). Each entry is in the format
System_Name Time_to_Call Type Speed \ Phone_Number Login_script
For example, consider this entry in the unilabs Systems file
gateway Any INTACU 1200 9999999 "" \d\r\d\r\ ogin: nuucp22 word: testing
The System_Name (gateway) is the name of the remote machine to be contacted. Time_to_Call is the calling schedule for this machine. This entry can be used to restrict when the machine may be called. This can be handy if the link between the machines is an expensive one. The Time_to_Call or schedule field can have the following values: Days of the Week
Start Hour - End Hour
0000-2400
The time specification uses the 24-hour clock in order to distinguish between 5:00 AM and 5:00 PM. The specification can span over midnight, as in 2310-0700, which would allow calls from 11:10 PM to 7:00 AM. There is a fine distinction to made in the time specification, however: uucico itself interprets the times on a same-day basis, so uucico would interpret the previous example as allowing calls from 0000-0700 and 2310-2359 on the same day. This is really only a problem if combining the time with a specification like Wk, or specific days. For example, Wk2310-0700 would work for Mon-Fri, but would not allow calls after 2359 Friday night, until 0000 Monday morning. The schedule fields can have only a day specification, with no time value, which means that the system can call any time of the day. The time subfields, however, must have a day specification. For example, to allow calls between 2310-0700 every day of the week, you would use the specification Any2310-0700 in the schedule field. It is also possible to have multiple calling periods for a single system by separating each of the periods with a comma. For example, to allow calling only between 2300-0700 on weekdays but anytime on weekends, you would enter Wk2300-0700,SaSu. However, this multiple time specification is not supported in all implementations. The schedule field may also specify an optional retry number, i.e., a value that changes the default number of minutes before another attempt will be made to call this system. BNU systems default to a five-minute interval which increases with each unsuccessful connection. To specify a different retry interval, enter a semicolon after the schedule value and then enter the retry value in minutes -- as in Any;2, which would define a retry period of two minutes. Note that this doesn't invoke uucico more quickly, but instructs uucico the next time that it is invoked to wait for this period of time before attempting to connect again. The Type field correlates the name of the device to use with its definition in the Devices file. Any name defined in the Devices file is valid here. For a TCP connection, the device named here is TCP with the protocol to be used defined. Following the device name is an optional field that specifies the protocol used on this call. The default is protocol g, but for high-speed reliable transport like TCP/IP, the e protocol is more efficient. The TLI and TLIS transports can also be used with correct configuration. The Speed field defines the speed in bauds for the connection to this system. No keywords are permitted. The Phone_Number field contains the actual number to dial and is used only with modems. Direct connections mark this field with a hyphen (-). The phone number may include any number of things, including dialcodes, support for calling card numbers, etc. For example, if you must dial 9 in order to get an outside line, then you would need to pause the dialer to wait for the secondary dial tone. To program a wait for the secondary tone, enter the equals sign (=) in your number. In some implementations of modem software, however, the equals sign simply generates a pause. It may be necessary to review your modem's documentation to determine the character which will generate a pause. This field may also contain a "plain-English" word which is listed in the Dialcodes file. This allows for the use of normal text to specify the location of the phone number and lets the system translate this into the proper numerical area code. This is not magically set up: you have to configure the list of area codes that you will allow in the Systems file. Figure 4 shows several sample entries for the Phone_Number field. Finally comes what may be the most difficult part of the entry: the chat script. This chat script is a combination of expect-send pairs which define the login sequence to gain access to the remote computer. Each pair is separated by a space, with optional subexpect-subsend pairs separated by hyphens. Consider the following example
login:-BREAK-login: nuucp word: loginAok
uucico expects the remote system to print login:. If this doesn't happen within a predefined period of time, it sends a BREAK signal, and again expects to see login. The BREAK signal is a modem break, which may wake up a getty running on the remote system, or cause that getty to switch to a speed that works for this connection. When the login prompt appears, the system sends nuucp and waits for the word: string. When that appears, the system sends loginAok, which is the password. At this point, the login to the system has succeeded. If the expect string is not received, the subexpect-subsend pairs are used. These pairs can enable a login if the answering system is running at a different speed. For example, if you are calling at 1200 baud and the remote system answers at 2400 baud, you would need to send a BREAK twice, assuming that the related gettydefs entry says go from 2400->300->1200. Therefore, the chat script would look like
login:-BREAK-login: \ -BREAK-login: nuucp word: \ loginAok
It should be pointed out that uucico stops looking at the incoming characters once a match is found for the "expect" text. However, it is commonplace to use the last text expected to ensure that the send sequence isn't sent to the remote system too soon. Before you can define the chat script, you need at the very least the uucp login name and password you will use to access the remote system. Use the cu command to contact the remote system in order to find out what you'll need to define for the script. A sample session would look like
chare@unilabs> cu -l tty21 Connected < send NEWLINE> login: nuucp Welcome to Unilabs Research Shere=bugs ~.
So to create a chat script for the system bugs, which is directly connected, you would describe it this way:
expect nothing send newline expect login: send nuucp
This would translate into a chat script which looks like
"" \r\c login: nuucp
The pair of double quotes means "expect nothing," while \r\c is "send newline." These are two of a number of special characters used in chat scripts, all of which are listed in Table 2. Sample chat scripts, including some considerably more complex than this example, are shown in Figure 5. Some additional cautions: when using UUCP over TCP/IP, do not include BREAKs, or other subexpect-subsend combinations. Not only are they unnecessary, but they can lead to problems in establishing a connection. Figure 6 shows sample Systems file entries. The Dialcodes File As I mentioned earlier, dialcodes are used to specify English words in lieu of area codes and dialing prefixes. This file has two fields: the first is the English keyword, and the second is the dialstring which will be substituted. For example
toronto 9=1-416
says that when I specify a phone number in the Systems file like
toronto5551212
it is expanded to
9=1-4165551212
prior to dialing. According to David Nowitz's original paper on Version 2 UUCP, the Dialcodes file was meant to enable the use of the same Systems file at multiple sites. Each site would supplement its Systems file with a customized Dialcodes file. Testing the Connection -- Using uucico After setting up the Systems file, it's again a good idea to verify that the configuration to this point is correct. You can accomoplish this either by using the uucico command with the -x option to specify a debug level or by using the uutry (Uutry on some systems) command. Perhaps the most difficult part of dealing with uucico is understanding its error messages (Table 4 lists UUCP error messages), which sometimes are inscrutable even to the most experienced system administrator. To test the connection and the uucico process, I recommend using the -x# option to uucico, which will print debug information on the screen. The # is a debug level, ranging from 1 to 9, with 9 being the maximum amount of debugging information available. The amount of information provided at a given level varies greatly from implementation to implementation. The following is a terminal session showing the debug path:
chare@unilabs> /usr/lib/uucp/uucico -r1 -x9 \ -sbugs conn(bugs Device Type bugs wanted getto ret -1 Call Failed: DEVICE LOCKED Conversation Complete: Status FAILED
In this first case, the conversation to bugs failed because the device was locked, which means that someone else was using the device. The only recourse is to wait until the device is free. A second example
chare@unilabs> /usr/lib/uucp/uucico -r1 -x9 \ -sthumper conn(thumper) Device Type thumper wanted getto ret -1 Call Failed: CAN'T ACCESS DEVICE Conversation Complete: Status FAILED
generates a CAN'T ACCESS DEVICE error message. Upon reviewing the permissions for the associated device, I found that the owner of the device file was root, not uucp. As a result, uucp couldn't open the device. A third example,
chare@unilabs> /usr/lib/uucp/uucico -r1 -x9 \
-sbugs
conn(bugs)
Device Type bugs wanted
getto ret 6
expect: ("")
got it
sendthem (DELAY
^MDELAY
^M^M)
expect: (ogin:)
^M^Jroot@bugs> ^M^J^M^Jroot@bugs> root@bugs> \ timed out
Call Failed: LOGIN FAILED
Conversation Complete: Status FAILED
reveals, not a potential, but a real security problem. The last user to use the port exited without logging out, and the remote system was not set up to drop the line when the connection was closed. Such events should be immediately reported to the system administrator of the other machine. Note that this time I failed to access the machine because I couldn't successfully complete the chat script. Listing 1 shows a successful UUCP transaction. (For typesetting purposes, the ^M^Js have been replaced by line breaks.) This seemingly simple transaction establishes that the UUCP connection is working. The transaction on the first imsg line is important -- it validates the calling systems, making sure that they know each other. The slave machine, usually the one being called, prints the message Shere=nodename, where nodename is its machine name (this is not consistent across implementations; in some cases the slave only prints Shere). The master usually replies with Snodename -Qseq -xnum, where nodename is the master's nodename, seq is the sequence number or zero if not used, and num is the level of debugging in effect. If the two machines agree to talk to each other, then the slave prints the message ROK, and the call continues. The log files kept by the various UUCP commands are also a good source of debugging information -- I will be looking at these later in this article. The debugging process may require you to circumvent the normal retry mechanism so that you can fix a problem and immediately call back. UUCP status files are kept on a machine-by-machine basis in the directory /usr/spool/uucp/.Status. Currently this directory on my system has the following files
total 3 -rw-rw-rw- 1 uucp \ other 32 Dec 30 00:04 \ bugs -rw-rw-rw- 1 uucp \ other 45 Dec 30 00:11 \ thumper -rw-rw-rw- 1 uucp \ other 38 Dec 30 00:11 \ wabbit
which record status information on these three systems. Samples from two separate status files look like this
Type count time \ retry status system 0 0 725691861 0 SUCCESSFUL \ bugs 6 1 725692313 300 \ LOGIN FAILED wabbit
The fields are defined as follows: Type -- a code which indicates the status of the job. This is explained in the status field. count -- number of call attempts made by the local system; this is incremented each time uucico tries to call the remote. time -- the time in number of seconds since 1 January 1970, when this system was last called (Listing 2 shows a program called gtimes, which will print the correct text for this time). retry -- when to retry this system again; the value is stored in seconds. status -- a text description of the status of the last call. system -- the name of the system. Status files are updated and removed periodically during the normal course of operation. However, if UUCP fails abnormally, it may be necessary to remove status files. The retry interval for system wabbit (shown above) is 300 seconds; to circumvent this retry limit, simply remove the status file for the desired system from /usr/spool/uucp/.Status/system. This will make UUCP believe that there wasn't a problem, and the call will be made immediately. Permissions File With the Devices and Systems entries configured and verified, the next step is to examine the security of the UUCP system. The normal user account protections remain in place with most UUCP accounts -- the one account that deviates from this is anonymous UUCP access, if you allow it. By normal protection mechanisms, I mean the login/password combination. It is wise to configure your UUCP accounts to have passwords: this makes it harder for anyone to break into your system via UUCP (for more information on password controls, see "How UNIX Password Controls Work," Sys Admin, May/June 1992). The Permissions file allows you to control the authorizations given to a remote system both when it calls you and when you call it. You may choose to use only the default values for each of the fields in the file. Here is a sample Permissions file entry:
LOGNAME=choreo \ REQUEST=yes \ SENDFILES=yes \ READ=/ \ NOREAD=/etc \ WRITE=/tmp:/usr/tmp: \ /usr/spool/uucppublic \ CALLBACK=no \ COMMANDS=ALL
This entry applies from my primary gateway to my employer's primary gateway. The backslashes on each line indicate that the line continues as if it were all on one line. These are not all of the options, and this is a non-default entry. The default permissions associated with a login are
READ=/usr/spool/uucppublic WRITE=/usr/spool/uucppublic REQUEST=no SENDFILES=call COMMANDS=rmail
Each entry must have either a LOGNAME or MACHINE option, or both. The LOGNAME option applies when a system calls in and logs in using the logname specified. The MACHINE option applies when users from your system call the remote machine. LOGNAME and MACHINE entries may be combined, but they don't have to be. However, if you want complete control over the systems that access your machine via UUCP, you need separate login ids and combined LOGNAME/MACHINE entries in the Permissions file. Table 3 lists all of the keyword options that can be used in the Permissions file, and Figure 7 shows permissions entry examples. The following are usages you should be aware of when defining Permissions entries for systems.
In addition to proper login and password controls, there are several advanced security measures available to further protect your system from marauders. These are the VALIDATE, CALLBACK, SENDFILEs, and REQUEST options. VALIDATE is used to validate the hostname of the calling system and to terminate the call if the caller does not have one of the listed hostnames. For example,
LOGNAME=choreo VALIDATE=choreo:gateway
If a system logs in to my machine using the logname of choreo, but it isn't the machine choreo or gateway, then the call will be terminated. The CALLBACK feature provides another level of protection. In this case, your system tells the calling system during negotiation that it will call back. Your system then terminates the call and uses the information in the Systems file to call the remote machine back. In this case, no work will take place until your system calls the remote machine back. This feature also is a method of determining who will pay for the phone call. The SENDFILES option can be used to determine if your system will send locally queued work after the remote has finished with its requests. For example, imagine two machines, the first called wabbit, the second thumper. In machine wabbit's Permissions file, the entry for thumper includes SENDFILES=call. A user on thumper initiates a request to send a file to wabbit, and a user on wabbit starts a UUCP job to send a file to thumper. thumper calls wabbit, logs in, and sends the file to wabbit. The call is terminated at this point, even though wabbit has a job to go to thumper. This is because the SENDFILES=call option indicates that files can be sent from wabbit to thumper only if wabbit initiates the call, and in this case the call was initiated by thumper. In addition to SENDFILES, you can set the value REQUEST=no, so that remote systems cannot request files from you. With both SENDFILES and REQUEST set this way, your system is pretty much in control of what is going on, regardless of the values for CALLBACK and VALIDATE, since all work destined for outside your system must originate with your system. Two caveats concerning SENDFILES and CALLBACK: if both systems are set CALLBACK=yes, or one system is set CALLBACK=yes and the other is SENDFILES=call, then no work will be performed in either case. Allowing Anonymous UUCP Access Where there is a need for anonymous UUCP access, potential security problems can be minimized with a proper Permissions entry. To allow anonymous UUCP access and make sure that appropriate security is in effect, first define a generic entry in Permissions:
# # For ANONYMOUS LOGINS # LOGNAME=nuucp
Make sure there is an nuucp account on your system that runs the uucico program as its shell. By defining only the LOGNAME option, you say that for any system that calls and uses the login name nuucp, only the DEFAULT permissions will be granted:
READ=/usr/spool/uucppublic WRITE=/usr/spool/uucppublic REQUEST=no SENDFILES=call COMMANDS=rmail
As a result, what the anonymous system can get is limited. If your reason for granting anonymous UUCP is to allow people to retrieve things from your system, you may want to set REQUEST=yes. Second, you must modify a file in the /usr/lib/uucp /directory called remote.unknown. The normal mode of operation in BNU is that machines must exist in each other's Systems files in order for the conversation to be successful. If they do not, then the system looks for remote.unknown. If it is found and is executable, the call is connected, the contents of the file are executed, and the call is then terminated. Systems calling with the nuucp entry will be treated in this fashion. To prevent this, use chmod to remove the execute bits. Calls from unknown systems will then be permitted. (See Listing 3 for a sample remote.unknown file.) UUCP Log Files To track what is happening on a system, UUCP keeps records of its transactions in a number of different log files. The log file used depends on which command is performing the work. All UUCP log files are stored in the /usr/spool/uucp/.Log subdirectory, with the hierarchy described in Figure 8. This structure has a directory for each of the uucp commands to be tracked -- uucp, uucico, uux, uuxqt -- and a file in each subdirectory for each system UUCP interacts with. As a result, you can see a record of the transactions for a given system at any time. The most commonly examined log file is probably that for the uucico command. Entries for that file look like the following (this example shows each of the entries that would be present to show a conversation):
user machine date time PID seq comment uucp gateway (12/30-22:04:06,1429,0) \ SUCCEEDED (call to gateway ) uucp gateway (12/30-22:04:12,1429,0) \ OK (startup) chare gateway gatewayN7bd0 \ (12/30-22:04:12,1429,0) REQUEST (unilabs!D.unila9309b03 --> \ gateway!D.unila9309b03 (chare)) chare gateway gatewayN7bd0 \ (12/30-22:04:30,1429,1) REQUEST \ (unilabs!D.gatew7bd0b03 --> \ gateway!X.gatewayN7bd0 (chare)) uucp gateway (12/30-22:04:37,1429,2) \ OK (conversation complete tty01 75)
The log file indicates that a call to machine gateway began at 22:04 on 12/30 and that connection was established (OK (startup)). A REQUEST was made to transfer a file (unilabs!unila9309b03) to gateway for user chare. A second file was transferred (notice that the SEQ number following the PID has incremented by one), and, finally, the call was terminated with the files having been successfully transferred. The log files also show trouble spots, as in the following:
uucp thumper (12/30-20:41:03,1213,0) \ CONN FAILED (CAN'T ACCESS DEVICE) uucp thumper (12/30-21:11:03,1280,0) \ FAILED (generic open) uucp thumper \ (12/30-21:11:03,1280,0) \ CONN FAILED (CAN'T ACCESS \ DEVICE) uucp thumper \ (12/30-21:41:03,1351,0) \ FAILED (generic open) uucp thumper \ (12/30-21:41:03,1351,0) \ CONN FAILED (CAN'T ACCESS \ DEVICE) uucp thumper (12/30-22:11:04,1464,0) \ FAILED (generic open) uucp thumper (12/30-22:11:04,1464,0) \ CONN FAILED (CAN'T ACCESS DEVICE)
This file reveals that there have been a number of unsuccessful attempts to contact the remote machine thumper. The error messages indicate that there is a problem accessing the device, which could mean a problem with permissions, a problem with ownership, or even an honest-to-goodness hardware problem. The log for the uux command shows which requests were queued on the local system to be dealt with, as in the following example:
user machine jobid date time \ pid SEQ comment news gateway gatewayd7bcf \ (12/30-18:30:18,926,0) QUEUED (rnews ) chare gateway gatewayN7bd0 \ (12/30-22:03:22,1425,0) QUEUED \ (rmail rdpub.com!martha )
Typically, few error messages would be written to this file. The log for uuxqt is quite similar, simply recording which commands were executed at the request of a remote system. The error messages, described in Table 4, would most commonly show up in the .Log/uucico/system file. (If you would like an awk program and related shell scripts to perform some reporting on the uucico log files, email me at chare@unilabs.org or chare@choreo.ca -- they are much to large too publish.) Maintenance Once you have UUCP running, you must take care of it. The log files just described are a constant source of disk consumption. Unless you clean them out regularly, they will expand to fill your disk. To help with this task, a crontab file is usually supplied for use by the uucp owner. Figure 9 shows a sample uucp crontab, with text explaining each of the entries. UNIX vendors provide the shell scripts uudemon.poll, uucleanup, uudemon.cleanu, and uudemon.hour to help system administrators maintain their UUCP systems. In practice, each of these programs is called at various intervals to perform some specific maintenace task. uudemon.poll looks at the Poll file (a sample of which is shown in Figure 10) to determine which (if any) systems should be called. If it finds that a system is to be called, it schedules a dummy job to trick uucico into thinking that there's work to be done. You would use this primarily to "poll" other UUCP systems which do not regularly call you. uucleanup, typically started by uudemon.cleanup, is used to clean up the UUCP spool directory (/usr/spool/uucp usually) in a somewhat intelligent way. For systems which cannot be reached, uucleanup sends a mail message back to the originator, deletes locally created rnews files, executes remotely created rnews files, and removes everything which shouldn't be there. A number of options are available for managing the processing done by uucleanup -- consult your vendor's documentation to see what your system offers. The uustat command (discussed in "UUCP -- A User's Perspective," in the Jan/Feb 1993 issue of Sys Admin) allows the user or the system administrator to obtain information about how the UUCP system is operating. With the -k option, uustat can also be used to cancel individual UUCP jobs. What uustat cannot do is cancel multiple UUCP jobs based on a user, system, or cancel-all-requests specification. Listing 3 contains a Perl program called uucancel.pl, which will cancel all UUCP requests, all requests for a specified system, or all requests made by a specified user. (A Bourne shell script companion program is scheduled to be published in Wizard's Grabbag column in the April issue of UNIXWorld.) Conclusion This article has briefly described the issues involved in configuring BNU UUCP -- it was not intended to be a complete tutorial. In fact, entire books have been dedicated to this subject, and if you are responsible for administering a UUCP network, I strongly recommend that you pick up one or more of these. Bibliography For more reading on UUCP, I suggest the following books, some of which were used as references for this series. Todino, Grace. Using UUCP and USENET. Sebastopol, CA: O'Reilly and Associates, 1989. Todino, Grace, and Tim O'Reilly. Managing UUCP and USENET. Sebastopol, CA: O'Reilly and Associates, 1989. Anderson, Costales, Henderson. UNIX Communications. Corte Madera, CA: The Waite Group, 1988. Thomas, Rebecca, and Rik Farrow. UNIX Administration Guide for System V. Englewood Cliffs, NJ: Prentice-Hall, 1989. Farrow, Rik. UNIX System Security. Reading, MA: Addison-Wesley, 1991.
About the Author
Chris Hare is Ottawa Technical Services Manager for Choreo Systems, Inc. He has worked in the UNIX environment since 1986 and in 1988 became one of the first SCO authorized instructors in Canada. He teaches UNIX introductory, system administration, and programming classes. His current focus is on networking, Perl, and X. Chris can be reached at chare@choreo.ca, or chare@unilabs.org, which is his home.
|