UUCP stands for “UNIX to UNIX Copy Program.” It is a set of utilities that lets computers using versions of the UNIX operating system (such as IRIX) communicate with each other and with remote terminals. These utilities range from those used to copy files between computers (uucp and uuto), to those used for simple encoding and decoding (uuencode and uudecode), to those used for remote login and command execution (cu and uux).
The following topics are covered in this chapter:
The UUCP system is contained in the eoe subsystem of your IRIX distribution, in the package called eoe.sw.uucp. Use the versions command to determine if you have this subsystem installed.
UUCP connections using telephone lines and modems are used to distribute electronic mail and “net news” among thousands of computers in the USENET network.
As an administrator, you need to be familiar with the administrative tools, logs, and database files used by UUCP. This chapter provides details about the UUCP files, directories, daemons, and commands.
This section compares UUCP and the TCP/IP protocol suite for various purposes. You can use them together, each for the tasks for which it is best suited. Both UUCP and TCP/IP software are standard features of the IRIX operating system. To use the TCP/IP software, you must have one of these communications mechanisms:
a connection to an Ethernet network
the optional FDDI hardware and software
the Serial Line Internet Protocol (SLIP) software
To use UUCP, you must be connected to a serial network or to any TCP/IP network.
TCP/IP provides reliable interactive and batch services. UUCP is a batch-mode service; when you enter a uucp command, it is placed in a queue with other commands. The system checks the queue at regular intervals and executes the commands that it finds. After your command is carried out, UUCP reports the results of the command. The time it takes to carry out a command on a remote station varies on different stations. Table 8-1 shows a comparison of features of TCP/IP and UUCP.
Table 8-1. Comparison of TCP/IP and UUCP
Runs on Ethernet and FDDI, and over serial lines
Runs over serial lines or over TCP/IP links
Transfers files interactively
Transfers files in batch mode
Executes commands on remote stations interactively
Executes commands on remote stations in batch mode
Sends mail interactively or in batch mode
Sends mail in batch mode
Starts a shell on a remote station
Starts a shell on a remote station
Provides remote login facilities with rlogin/telnet
Provides remote login facilities with cu
Transfers data to any station running TCP/IP
Transfers data to any station running UUCP
Before your computer can communicate with other computers through UUCP, you must set up the hardware to complete the communications link. The cables and other hardware you need depend on how you want to connect the computers: direct links, telephone lines, or local area networks.
|Note: Refer to IRIX Admin: Peripheral Devices and the Personal System Administration Guide for information on setting up modems and other hardware.|
You can create a direct link to another computer by running cables between serial ports on the two computers. Direct links are useful if two computers communicate regularly and are physically close—within 50 feet of each other. You can use a limited-distance modem to increase this distance somewhat. Transfer rates of up to 38,400 bits per second (bps) are possible when computers are directly linked. Such direct links are now rarely used because local area networks provide faster, easier-to-use connections.
Using a modem capable of dialing telephone numbers, your computer can communicate with other computers over standard phone lines. The modem dials the telephone number requested by the networking utilities. The computer it is trying to contact must have a modem capable of answering incoming calls.
UUCP programs can be divided into two categories: user programs and administrative programs. The subsections that follow describe the programs in each category.
The UUCP user programs are in /usr/bin. No special permission is needed to use these programs; they are all described in the reference pages.
Connects your computer to a remote computer so you can log in to that computer, allowing you to transfer some files or execute commands on either computer without dropping the initial link.
Lets you copy a file from one computer to another. This program creates work files and data files, queues the job for transfer, and calls the uucico daemon, which in turn attempts to contact the remote computer.
Copies files from one computer to a public spool directory on another computer (/var/spool/uucppublic/receive). Unlike uucp, which lets you copy a file to any accessible directory on the remote computer, uuto places the file in an appropriate spool directory and sends mail to the remote user who requested that it be picked up with uupick.
Retrieves the files placed under /var/spool/uucppublic/receive when files are transferred to a computer that is using uuto.
Creates the work, data, and execute files needed to execute commands on a remote computer. The work file contains the same information as work files created by uucp and uuto. The execute files contain the command string to be executed on the remote computer and a list of the data files. The data files are those files required for the command's execution.
Displays the status of requested transfers (uucp, uuto, or uux). This program also provides a way to control queued transfers.
Most of the administrative programs are in /usr/lib/uucp, though the UUCP database files reside in /etc/uucp. The only exception is uulog, which is in /usr/bin. These commands are described in their respective reference pages.
You should use the uucp login ID when you administer UUCP because it owns the basic networking and spooled data files. The home directory of the uucp login ID is /usr/lib/uucp. The other UUCP login ID is nuucp, used by remote computers that do not have their own login IDs to access your computer. A computer that logs in with nuucp receives uucico as its shell.
The following programs are the administrative utilities of UUCP:
Displays the contents of a specified computer's log files. A log file is created for each remote computer with which your computer communicates. The log files contain records of each use of uucp, uuto, and uux.
Cleans up the spool directory. This command is normally executed from a shell script called uudemon.cleanup, which is started by cron.
Tests call-processing capabilities and does a moderate amount of debugging. This command invokes the uucico daemon, in debug mode, to establish a communications link between your computer and the remote computer that you specify.
Checks for the presence of UUCP directories, programs, and support files. This program can also check certain parts of the Permissions file for obvious syntactic errors.
Generates the Permissions file for stations that assign each remote station its own login ID.
The following programs are used for initializing different types of modems. The use of these programs is described in IRIX Admin: Peripheral Devices , Chapter 1, “Terminals and Modems.”
This program initializes DSI modems
This program initializes Hayes modems.
This program initializes Intel modems.
This program initializes Telebit modems.
This program initializes U. S. Robotics modems.
This program initializes Telebit modems.
There are several daemons in UUCP. These daemons handle file transfers and command executions. They can also be run manually from the shell.
Selects the device used for the link, establishes the link to the remote computer, performs the required login sequence and permission checks, transfers data and execute files, logs results, and notifies the user by mail of transfer completions. It also starts uuxqt to execute any requested commands. When the local uucico daemon calls a remote computer, it “talks” to the uucico daemon on the remote computer during the session.
The uucico daemon is executed by the uucp, uuto, and uux programs, after all the required files have been created, to contact the remote computer. It is also executed by the uusched and Uutry programs.
Executes remote execution requests. This daemon searches the spool directory for execute files (always named X.file) that have been sent from a remote computer. When an X.file file is found, uuxqt opens it to get the list of data files that are required for the execution. It then checks to see if the required data files are available and accessible. If the files are present and can be accessed, uuxqt checks the Permissions file to verify that it has permission to execute the requested command. The uuxqt daemon is executed by the uudemon.hour shell script, which is started by cron.
Schedules the queued work in the spool directory. Before starting the uucico daemon, uusched randomizes the order in which remote computers are called. uusched is executed by a shell script called uudemon.hour, which is started by cron.
This program is very similar to the getty program, except that it permits a line (port) to be used in both directions. uugetty is assigned to a port in the /etc/inittab file if you want a port to be bi-directional. uugetty is described on the uugetty(1M) reference page.
The UUCP support files are in the /etc/uucp directory.
Contains information concerning the location and line speed of the automatic call units (modems) and direct links. Details are in “UUCP Devices File” .
Contains character strings required to negotiate with automatic call units (ACUs) or modems in establishing connections to remote computers. Details are in “UUCP Dialers File”.
Contains information needed by the uucico daemon and the cu program to establish a link to a remote computer. This file contains information such as the name of the remote computer, the name of the connecting device associated with the remote computer, when the computer can be reached, the telephone number, the login ID, and the password. Details are in “UUCP Systems File”.
Contains dial-code abbreviations that can be used in the phone number field of Systems file entries. Details are in “UUCP Dialcodes File”.
Defines the level of access that is granted to remote users using uucp or uux when they attempt to transfer files or remotely execute commands on your computer. Details are in “UUCP Permissions File”.
Defines computers that are to be polled by your station and when they are polled. Details are in “UUCP Poll File”.
Assigns different or multiple files to be used by uucico and cu, such as Systems, Devices, and Dialers files. Details are in “UUCP Sysfiles File”.
There are several other files that can be considered part of the supporting database; these files are not directly related to the process of establishing a link and transferring files. The files, Maxuuxqts, Maxuuscheds, and remote.unknown, are described briefly in “Other UUCP Files”.
The Devices file (/etc/uucp/Devices) contains information for all the devices that can be used to establish a link to a remote computer, such as automatic call units, direct links, and network connections.
|Note: This file works interdependently with the Dialers, Systems, and Dialcodes files. Before you make changes in any of these files, you should be familiar with them all. A change to an entry in one file may require a change to a related entry in another file.|
Each entry in the Devices file has the following format:
Type Line Line2 Class Dialer-Token-Pairs
Entries for use with modems should always have the form
Name device null speed 212 x dialer
Entries for use over TCP/IP network connections have the form
TCP - - Any TCP uucp
Devices file fields are defined in the following sections:
The keyword used in the Type field is matched against the third field of Systems file entries. The Type field can contain one of these keywords: Direct, ACU, or a system name.
This keyword indicates a direct link to another computer or a switch (for cu connections only).
This keyword indicates that the link to a remote computer is made through an automatic call unit (automatic-dial modem).
This value indicates a direct link to a particular computer. (Sys-Name is replaced by the name of the computer.) This naming scheme is used to convey the fact that the line associated with this Devices entry is for a particular computer in the Systems file.
You can designate a protocol to use for a device within this field. See the “Protocols” section at the end of the description of this file.
This field contains the device name of the line (port) associated with the Devices entry. For instance, if the automatic dial modem for a particular entry is attached to the /dev/ttyf5 line, the name entered in this field is ttyf5.
You should always use the ttyf devices when working with modems. These devices support hardware flow control, which is used by all modems that support V.32 or V.32bis.
If the keyword ACU is used in the Type field and the ACU is an 801-type dialer, the Line2 field contains the device name of the 801 dialer. (801-type ACUs do not contain a modem. Therefore, a separate modem is required and must be connected to a different line, defined in the Line field.) The need for a separate modem line means that one line would be allocated to the modem and another to the dialer. Because non-801 dialers do not normally use this configuration, they ignore the Line2 field, but it must still contain a hyphen (-) or the word null as a place holder. A place holder is necessary for most modems.
The keyword used in the Class field of the Devices file is matched against the fourth field of Systems file entries:
Devices: ACU ttyf5 null D9600 212 x telebit Systems: eagle Any ACU D9600 14155551212 login:nuucp password:Oakgrass
Some devices can be used at any speed, so the keyword Any can be used in the Class field. If Any is used, the line will match any speed requested in a Systems file entry. If this field is Any and the Systems file Class field is Any, the speed defaults to 9600 bps. If the keyword ACU or Direct is used in the Type field, the Class field might contain only the speed of the device. However, the speed can also be preceded by a letter (for example, C9600, D9600) to differentiate between classes of dialers (Centrex or Dimension PBX). Including the dialer class is necessary in larger offices that have more than one type of telephone network: One network may be dedicated to serving only internal communications while another handles external. In such a case, it becomes necessary to distinguish which line(s) should be used for internal and which for external.
This field contains pairs of dialers and tokens. The Dialer portion may be the name of an automatic-dial modem, or ``Direct'' for a direct-link device. You can have any number of Dialer-Token-Pair (DTP) fields. The Token portion may be supplied immediately following the Dialer portion; if not present, the Token portion will be taken from a related entry in the Systems file.
This field has the format
dialer token dialer token
The last pair may or may not be present, depending on the associated device (dialer). In most cases, the last pair contains only a Dialer portion and the Token portion is retrieved from the Phone field of the Systems file entry. A valid entry in the Dialer portion may be defined in the Dialers file.
The DTP field can be structured in different ways, depending on the device associated with the entry.
If an automatic-dial modem is connected directly to a port on your computer, the DTP field of the associated Devices file entry will have only one pair. This pair is normally the name of the modem. This name is used to match the particular Devices file entry with an entry in the Dialers file. Therefore, the Dialer field must match the first field of a Dialers file entry:
Devices: ACU ttyf2 null 9600 212 x telebit Dialers: telebit =&-% "" \r\p\r\c $ <K\T%%\r>\c ONLINE!
Notice that only the Dialer portion (telebit) is present in the DTP field of the Devices file entry. This means that the token to be passed on to the dialer (in this case the phone number) is taken from the Phone field of a Systems file entry. (\T is implied)
If a direct link is established to a particular computer, the DTP field of the associated entry contains the keyword Direct. This is true for both types of direct-link entries, Direct and System-Name.
If an automatic-dial modem is connected to a switch, your computer must first access the switch; the switch then makes the connection to the modem. This type of entry requires two Dialer-Token-Pairs. The Dialer portion of each pair (fifth and seventh fields of entry) is used to match entries in the Dialers file:
Devices: ACU ttyf2 null 9600 212 x t2500 telebit T25 Dialers: telebit "" "" \pr\ps\c est:\007 \E\D\e \007 Dialers: T25 =&-% "" \r\p\r\c $ <K\T%%\r>\c ONLINE!
In the first pair, t2500 is the Dialer and telebit is the token that is passed to the Develcon switch to tell it which device (telebit modem) to connect to your computer. This token is unique for each modem switch since each switch may be set up differently. Once the telebit modem has been connected, the second pair is accessed, where T25 is the dialer and the token (the telephone number) is retrieved from the Systems file. (See the discussion of the Systems file's Phone field in “UUCP Systems File”.)
Two escape characters can appear in a DTP field:
Indicates that the Phone (Token) field should be translated by means of the Dialcodes file.
Indicates that the Phone (Token) field should not be translated by means of the Dialcodes file. If no escape character is specified at the end of a Devices entry, the \D is assumed (default).
You can define the protocol to use with each device. In most cases it is not needed because you can use the default or define the protocol with the particular station you are calling. (See the discussion of the Systems file, specifically the Type field.) If you do specify the protocol, you must do it in the form Type, Protocol. Available protocols are
This protocol is slower and more reliable than e. It is good for transmission over noisy telephone lines. This is the default protocol.
This protocol is faster than g, but it assumes error-free transmission, such as over a TCP/IP network connection.
This protocol, like e, is for use in an error-free environment, such as a TCP/IP network connection. The t protocol is used by systems running BSD UNIX operating systems.
The Dialers file (/etc/uucp/Dialers) specifies the initial conversation that must take place on a line before it can be made available for transferring data. This conversation is usually a sequence of ASCII strings that is transmitted and expected, and it is often used to dial a phone number with an ASCII dialer (such as an automatic-dial modem).
As shown in the preceding section, the fifth field in a Devices file entry is an index into the Dialers file or a special dialer type. An attempt is made to match the fifth field in the Devices file with the first field of each Dialers file entry. In addition, each odd-numbered Devices field, starting with the seventh position, is used as an index into the Dialers file. If the match succeeds, the Dialers entry is interpreted to perform the dialer negotiations.
Each entry in the Dialers file has the following format:
dialer substitutions expect-send ...
The Dialer field matches the fifth and additional odd-numbered fields in the Devices file.
The substitutions field is a translate string: The first of each pair of characters is mapped to the second character in the pair. This technique is usually used to translate the equal sign (=) and the hyphen (-) characters into whatever the dialer requires for “wait for dial tone” and “pause.”
The expect-send fields are character strings.
Details of the UUCP Dialers file are in the next subsections:
The list in Table 8-2 describes some of the escape characters used in the Dialers file and the escape sequences used by UUCP.
Table 8-2. UUCP Escape Sequences
Send or expect a null character (ASCII NUL).
Send or expect a backspace character.
If at the end of a string, suppress the newline that is normally sent. Ignored otherwise.
Delay two seconds before sending or reading more characters.
Pause for approximately .25 to .5 seconds.
Start echo checking. (From this point on, whenever a character is transmitted, login processing will wait for the character to be received before proceeding.)
Turn off echo checking.
Send a newline character.
Send or expect a carriage return.
Send or expect a space character.
Send or expect a tab character.
Send or expect a backslash (\) character.
Send or expect EOT newline twice.
Send or expect a break character.
Same as BREAK.
Send or expect the character represented by the octal digits ddd.
Here is a sample line from the Dialers file:
penril =W-P "" \d > Q\c : \d- > s\p9\c )-W\p\r\ds\p9\c-) y\c : \E\TP > 9\c OK
The penril entry in the Dialers file is executed as follows. The phone number argument is translated, replacing any equal sign with a W (wait for dial tone) and replacing any hyphen with a P (pause).
The handshake given by the remainder of the line works as follows:
Wait for nothing; in other words, proceed to the next step.
Delay for two seconds.
Wait for a “greater than” sign (>).
Send a Q with no terminating new line.
Wait for a colon (:).
Delay for two seconds.
Wait for a “greater than” sign (>).
Send an s, pause for 0.5 second, send a 9, send no terminating new line.
Wait for a closing parenthesis [)]; if it is not received, process the string between the hyphens as follows: Send a W, pause, send a carriage return, delay, send an s, pause, send a 9 without a new line, and then wait for the closing parenthesis.
Send a y without a new line.
Wait for a colon (:)
Enable echo checking. (From this point on, whenever a character is transmitted, handshake processing waits for the character to be received before proceeding.) Then send the phone number. The \T instructs the program to take the phone number passed as an argument, apply the Dialcodes translation and the modem function translation specified by field two of this entry, then send a P.
Send a 9 without a new line.
Wait for the string OK.
The Systems file (/etc/uucp/Systems) contains the information needed by the uucico daemon to establish a communications link to a remote computer. Each entry in the file represents a computer that can call or be called by your computer. In addition, UUCP software by default is configured to prevent any computer that does not appear in this file from logging in to your computer. (Refer to “Other UUCP Files”, for a description of the remote.unknown file.) More than one entry may be present for a particular computer. The additional entries represent alternative communications paths that are tried in sequential order.
Using the Sysfiles file, you can define several files to be used as Systems files. See “UUCP Sysfiles File”, for details.
Each entry in the Systems file has the following format:
System-name Time Type Class Phone Login
These fields are defined in the following sections:
This field is a string that indicates the day-of-week and time-of-day when the remote computer can be called. The format of the Time field is
The day portion is a list of one or more day specifiers. These specifiers are listed below.
|Su, Mo, Tu, We, Th, Fr, Sa|
These abbreviations stand for individual days of the week: Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday.
Specifies any weekday, Monday through Friday.
Specifies any day.
Specifies that this station never initiates calls to the remote computer. If the Time field is Never, your computer will never initiate a call to the remote computer. The call must be initiated by the remote computer. In other words, your computer is in a passive mode with respect to the remote computer. (For more information on permissions, see “UUCP Permissions File”.)
Here is an example of a Time field:
This example allows calls from 5:00 p.m. to 8:00 a.m., Monday through Friday, and any time Saturday and Sunday. The example would be an effective way to call only when phone rates are low, if immediate transfer is not critical.
The time portion should be a range of times such as 0800–1230. If no time portion is specified, any time of day is assumed to be allowed for the call. A time range that spans 0000 is permitted. For example, 0800-0600 means all times are allowed other than at times between 6 a.m. and 8 a.m.
An optional subfield, retry, is available to specify the minimum time (in minutes) before a retry, following a failed attempt. The default wait is 5 minutes after the first failure, 10 after the second, and so on until a delay of about 24 hours. If the retry subfield is present, that wait is used after every failure. The subfield separator is a semicolon (;). For example, “Any;9” is interpreted as “call any time, but wait at least 9 minutes before retrying after a failure occurs.”
This field contains the device type that should be used to establish the communications link to the remote computer. The keyword used in this field is matched against the first field of Devices file entries:
Systems: eagle Any ACU,g D1200 3251 login:nuucp password: Oakgrass Devices: ACU ttym2 - D1200 penril
You can define the protocol used to contact the station by adding it on to the Type field. The example just given shows how to attach the protocol g to the device type ACU. For direct connects, use the name of the station to which you are connecting. See “UUCP Device Protocols”.
This field is used to indicate the transfer speed of the device used to establish the communications link. It may contain a letter and speed (for example, C1200, D1200) to differentiate between classes of dialers. (See the discussion of the Class field in “UUCP Devices File”.) Some devices can be used at any speed, so the keyword Any may be used. This field must match the Class field in the associated Devices file entry as shown here:
Systems: eagle Any ACU D1200 NY3251 login:nuucp password:Oakgrass Devices: ACU ttym2 - D1200 penril
If information is not required for this field, use a hyphen as a place holder for the field.
This field is used to provide the phone number (token) of the remote computer for automatic dialers. The phone number is made up of an optional alphabetic abbreviation and a numeric part. If an abbreviation is used, it must be one that is listed in the Dialcodes file. For example:
Systems: eagle Any ACU D1200 NY3251 login:nuucp password: Oakgrass Dialcodes: NY 9=1212555
In this string, an equal sign (=) tells the ACU to wait for a secondary dial tone before dialing the remaining digits. A hyphen (-) in the string instructs the ACU to pause four seconds before dialing the next digit.
If your computer is connected to a modem switch, you may access other computers that are connected to that switch. The Systems file entries for these computers does not have a phone number in the Phone field. Instead, this field contains the token that must be passed on to the switch so it will know which computer your computer wishes to communicate with. This token is usually just the station name. The associated Devices file entry should have a \D at the end of the entry to ensure that this field is not translated by means of the Dialcodes file.
This field contains login information given as a series of fields and subfields of this format:
The send string is sent when the expect string is received. The expect field may be made up of subfields of this form:
The send field is sent if the prior expect is not successfully read and the expect following the send is the next expected string. For example, with login--login, UUCP expects the string login. If UUCP receives that string, it goes on to the next field. If it does not receive the string, it sends nothing, followed by a new line, then looks for login again. If no characters are initially expected from the remote computer, the characters " " (null string) should be used in the first expect field. Note that all send fields are sent followed by a newline unless the send string is terminated with a \c.
Here is an example of a Systems file entry that uses an expect-send string:
owl Any ACU 1200 NY6013 "" \r login:-BREAK-login: uucpx word: xyzzy
This example means causes UUCP to send a carriage return and wait for the string login:. If it doesn't receive the string, it sends a break character and waits for login: again. When it does receive the string login, it sends the login name uucpx; waits to receive the string word: (the last part of “Password:”); and sends the password xyzzy.
Several escape sequences cause specific actions when they are a part of a string sent during the login sequence. These are the same escape sequences used in the Dialers file, listed in Table 8-2.
The Dialcodes file (/etc/uucp/Dialcodes) contains the dial-code abbreviations that can be used in the Phone field of the Systems file. Each entry has the following format:
abb is the abbreviation used in the Systems file Phone field and dial-seq is the dial sequence that is passed to the dialer when that Systems file entry is accessed.
For example, the following entry would work with a Phone field in the Systems file such as jt7867:
When the entry containing jt7867 was encountered, the sequence 9=555-7867 would be sent to the dialer if the token in the dialer-token-pair was \T.
The Permissions file (/etc/uucp/Permissions) specifies the permissions that remote computers have with respect to login, file access, and command execution. There are options that restrict the remote computer's ability to request files and its ability to receive files queued by the local site. Another option specifies the commands that a remote site can execute on the local computer.
The program /etc/uucp/genperm is recommended for creating a sample or default Permissions file from the Systems file.
These subsections explain details of the Permissions file:
Each entry is a logical line with physical lines terminated by a backslash (\) to indicate continuation. (Note that such continuations are not possible in most other UUCP files.) Entries are made up of options delimited by white space. Each option is a name/value pair in the following format:
Note that no white space is allowed within an option assignment.
Comment lines begin with a number sign (#) and occupy the entire line up to a newline character. Blank lines are ignored (even within multi-line entries).
There are two types of Permissions file entries:
Specifies the permissions that take effect when a remote computer logs in to (calls) your computer.
Specifies the permissions that take effect when your computer logs in to (calls) a remote computer.
LOGNAME entries begin with a LOGNAME option and MACHINE entries begin with a MACHINE option.
Keep these rules in mind when using the Permissions file to restrict the level of access granted to remote computers:
Any login ID used by a remote computer to log in for UUCP communications must appear in one and only one LOGNAME entry.
Any site that is called whose name does not appear in a MACHINE entry will have the following default permissions and restrictions:
Local send and receive requests are executed.
The remote computer can send files to your computer's /var/spool/uucppublic directory.
The command sent by the remote computer for execution on your computer must be one of the default commands, usually rmail.
This section describes each option, specifies how it is used, and lists its default value.
When a remote computer calls your computer and requests to receive a file, this request can be granted or denied. The REQUEST option specifies whether the remote computer can request to set up file transfers from your computer.
The string that follows specifies that the remote computer can request to transfer files from your computer:
The following string specifies that the remote computer cannot request to receive files from your computer:
This is the default value. It will be used if the REQUEST option is not specified. The REQUEST option can appear in either a LOGNAME (remote calls you) entry or a MACHINE (you call remote) entry.
A note on security: When a remote computer calls you, you cannot verify its identity unless you have a unique login and password for that computer.
When a remote computer calls your computer and completes its work, it may attempt to take work your computer has queued for it. The SENDFILES option specifies whether your computer can send the work queued for the remote computer.
The string shown here specifies that your computer may send the work that is queued for the remote computer as long as it logged in as one of the names in the LOGNAME option:
This string is mandatory if your computer is in a “passive mode” with respect to the remote computer.
The string that follows specifies that files queued in your computer will be sent only when your computer calls the remote computer:
The call value is the default for the SENDFILE option. This option is significant only in LOGNAME entries, because MACHINE entries apply when calls are made to remote computers. If the option is used with a MACHINE entry, it will be ignored.
|READ and WRITE|
These options specify the various parts of the filesystem that uucico can read from or write to. The READ and WRITE options can be used with either MACHINE or LOGNAME entries.
The default for both the READ and WRITE options is the uucppublic directory, as shown in the following strings:
These strings specify permission to access any file that can be accessed by a local user with “other” permissions:
Because this suggestion may compromise security, use it only if required.
The value of these entries is a colon-separated list of pathnames. The READ option is for requesting files, and the WRITE option for depositing files. One of the values must be the prefix of any full pathname of a file coming in or going out. To grant permission to deposit files in /usr/news as well as in the public directory, the following values would be used with the WRITE option:
Note that if you use the READ and WRITE options, you must specify all pathnames because the pathnames are not added to the default list. For instance, if the /usr/news pathname were the only one specified in a WRITE option, permission to deposit files in the public directory would be denied.
You should be careful which directories you make accessible for reading and writing by remote stations. For example, you probably wouldn't want remote computers to be able to write over your /etc/passwd file, so /etc shouldn't be open to writes.
|NOREAD and NOWRITE|
The NOREAD and NOWRITE options specify exceptions to the READ and WRITE options or defaults. The strings shown here would permit one remote computer to read any file except those in the /etc directory (and its subdirectories—remember, these are prefixes) and to write only to the default /var/spool/uucppublic directory:
NOWRITE works in the same manner as the NOREAD option. NOREAD and NOWRITE can be used in both LOGNAME and MACHINE entries.
The CALLBACK option is used in LOGNAME entries to specify that no transaction will take place until the calling station is called back. You would use CALLBACK for two reasons: From a security standpoint, if you call back a station you can be sure it is the station it says it is. If you are doing long data transmissions, you can choose the station that will be billed for the longer call.
The string that follows specifies that your computer must call the remote computer back before any file transfers will take place:
The default for the CALLBACK option is
The CALLBACK option is very rarely used. Note that if two sites have this option set for each other, a conversation cannot be started.
The COMMANDS option can be hazardous to the security of your station. Use it with extreme care.
The uux program generates remote execution requests and queues them to be transferred to the remote computer. Files and a command are sent to the target computer for remote execution.
The COMMANDS option can be used in MACHINE entries to specify the commands that a remote computer can execute on your computer. Note that COMMANDS is not used in a LOGNAME entry; COMMANDS in MACHINE entries defines command permissions, whether you call the remote station or it calls you.
This string indicates the default commands that a remote computer can execute on your computer:
If a command string is used in a MACHINE entry, the default commands are overridden. For instance, in the following example, the entry overrides the COMMANDS default so that the computers eagle, owl, and hawk can now execute rmail and rnews on your computer:
In addition to the names as specified above, there can be full pathnames of commands. For example, this line specifies that command rmail use the default path:
The default paths for your computer are /bin /usr/sbin, /usr/bsd, and /usr/bin. When the remote computer specifies rnews or /usr/bin/rnews for the command to be executed, /usr/bin/rnews is executed, regardless of the default path. Likewise, /usr/local/lp is the lp command that is executed.
This string illustrates the greater access:
Two points about this string should be noted. The ALL value can appear anywhere in the string, and the pathnames specified for rnews and lp will be used (instead of the default) if the requested command does not contain the full pathnames for rnews or lp.
The VALIDATE option should be used with the COMMANDS option whenever potentially dangerous commands like cat and uucp are specified with the COMMANDS option. Any command that reads or writes files is potentially dangerous to local security when executed by the UUCP remote execution daemon (uuxqt).
The VALIDATE option is used in conjunction with the COMMANDS option when specifying commands that are potentially dangerous to your computer's security. It is used to provide a certain degree of verification of the caller's identity. The use of the VALIDATE option requires that privileged computers have a unique login and password for UUCP transactions. An important aspect of this validation is that the login and password associated with this entry be protected. If an outsider gets that information, that particular VALIDATE option can no longer be considered secure. (VALIDATE is merely an added level of security on top of the COMMANDS option, though it is a more secure way to open command access than ALL.)
Give careful consideration to providing a remote system with a privileged login and password for UUCP transactions. Giving another system these privileges is like giving anyone on that computer a normal login and password on your computer. Therefore, if you cannot trust everyone at the remote site, do not provide that system with a privileged login and password.
The LOGNAME option ensures that remote stations attempting to log in to your computer have login privileges. The following LOGNAME entry specifies that if one of the remote computers that claims to be eagle, owl, or hawk logs in to your computer, it must have used the login uucpfriend:
As can be seen, if an outsider gets the uucpfriend login and password, marauding is trivial.
But what does this have to do with the COMMANDS option, which appears only in MACHINE entries? It links the MACHINE entry (and COMMANDS option) with a LOGNAME entry associated with a privileged login. This link is needed because the execution daemon is not running while the remote computer is logged in. In fact, it is an asynchronous process with no knowledge of which computer sent the execution request. Therefore, the real question is, how does your computer know where the execution files came from?
Each remote computer has its own “spool” directory on your computer. These spool directories have write permission given only to the UUCP programs. The execution files from the remote computer are put in its spool directory after being transferred to your computer. When the uuxqt daemon runs, it can use the spool directory name to find the MACHINE entry in the Permissions file and get the COMMANDS list or, if the computer name does not appear in the Permissions file, the default list is used.
The following example shows the relationship between the MACHINE and LOGNAME entries:
The value in the COMMANDS option means that remote mail and /usr/bin/rnews can be executed by remote users.
In the first entry, you must make the assumption that when you want to call one of the computers listed, you are really calling either eagle, owl, or hawk. Therefore, any files put into one of the eagle, owl, or hawk spool directories is put there by one of those computers. If a remote computer logs in and says that it is one of these three computers, its execution files will also be put in the privileged spool directory. You therefore have to validate that the computer has the privileged login uucpz.
|MACHINE Entry for “Other” Systems|
You may want to specify different option values for computers your computer calls that are not mentioned in specific MACHINE entries. This situation may occur when there are many computers calling in, and the command set changes from time to time. The name OTHER for the computer name is used for this entry:
All other options available for the MACHINE entry may also be set for the computers that are not mentioned in other MACHINE entries.
|Combining MACHINE and LOGNAME Entries|
It is possible to combine MACHINE and LOGNAME entries into a single entry where the common options are the same. For example, the two entries that follow share the same REQUEST, READ, and WRITE options:
These two entries can be merged:
The MYNAME option is used to override the name of the local computer, when the local computer identifies itself to the remote computer. This facility is useful when a computer is replaced or renamed, and its neighbors need to process old traffic to the old name.
The Poll file (/etc/uucp/Poll) contains information for polling remote computers. Each entry in the Poll file contains the name of a remote computer to call, followed by a Tab character (a space won't work), and finally the hours at which the computer should be called. The format of entries in the Poll file is
sys-name hour ...
For example, the following entry provides polling of computer eagle every four hours:
eagle 0 4 8 12 16 20
The uudemon.poll script does not actually perform the poll. It merely sets up a polling work file (always named C.file) in the spool directory that will be seen by the scheduler, which is started by uudemon.hour.
The /etc/uucp/Sysfiles file lets you assign different files to be used by uucp and cu as Systems, Devices, and Dialers files. Here are some cases where this optional file may be useful:
You may want to use different Systems files so that requests for login services can be made to phone numbers different from those used for requests for uucp services.
You may want to use Dialers files that have different handshaking for cu and uucp.
You may want to have multiple Systems, Dialers, and Devices files. The Systems file in particular may become large, making it more convenient to split it into several smaller files.
The format of the Sysfiles file is
service=w systems=x:x dialers=y:y devices=z:z
The w parameter is replaced by uucico, cu, or both separated by a colon; x is one or more files to be used as the Systems file, with each filename separated by a colon and read in the order presented; y is one or more files to be used as the Dialers file; and z is one or more files to be used as the Devices file. Each file is assumed to be relative to the /etc/uucp directory, unless a full path is given. A backslash-carriage return (\Return) can be used to continue an entry to the next line.
Here is an example using a local Systems file in addition to the usual Systems file:
If this line is in /etc/uucp/Sysfiles, then both uucico and cu will first look in /etc/uucp/Systems. If the station they're trying to call doesn't have an entry in that file, or if the entries in the file fail, then they'll look in /etc/uucp/Local_Systems.
When different Systems files are defined for uucico and cu services, your station will store two different lists of stations. You can print the uucico list by using the uuname command, or the cu list by using the uuname -c command.
Three files, in addition to those described in the preceding subsections, have an impact on the use of basic networking facilities. In most cases, the default values are fine and no changes are needed. If you want to change the default values, however, use any standard IRIX text editor (ed, vi, or jot).
This file defines the maximum number of uuxqt programs that can run at once. The default number is two.
This file defines the maximum number of uusched programs that can run at once. The default number is two.
This file is a program that executes when a station that is not in any of the Systems files starts a conversation. The program logs the conversation attempt and refuses the connection. If you change the permissions of this file so it cannot execute (chmod 000 unknown), your station will accept any conversation requests.
The UUCP administrative files are created in spool directories to lock devices, hold temporary data, or keep information about remote transfers or executions.
|TM (temporary data file)|
These data files are created by UUCP processes under the spool directory (for example, /var/spool/uucp/X) when a file is received from another computer. The directory X has the same name as the remote computer that is sending the file. The names of the temporary data files have the following format:
pid is a process-ID and ddd is a sequential, three-digit number starting at 0.
When the entire file is received, the TM.pid.ddd file is moved to the pathname specified in the C.sysnxxxx file (discussed later in this section) that caused the transmission. If processing is abnormally terminated, the TM.pid.ddd file may remain in the X directory. These files should be automatically removed by uucleanup.
|LCK (lock file)|
Lock files are created in the /var/spool/locks directory for each device in use. Lock files prevent duplicate conversations and multiple attempts to use the same calling device. The names of lock files have this format:
str is either a device or computer name. These files may remain in the spool directory if the communications link is unexpectedly dropped (usually because of a computer crash). Lock files are ignored (removed) after the parent process is no longer active. Each lock file contains the process ID of the process that created the lock.
|C. (work file)|
Work files are created in a spool directory when work (file transfers or remote command executions) has been queued for a remote computer. The names of work files have the following format:
sys is the name of the remote computer, n is the ASCII character representing the grade (priority) of the work, and xxxx is the four-digit job sequence number assigned by UUCP. Work files contain the following information:
|D. (data file)|
Data files are created when the command line specifies that the source file should be copied to the spool directory. The names of data files have the following format:
systm is the first five characters in the name of the remote computer and xxxx is a four-digit job sequence number assigned by UUCP. The four-digit job sequence number may be followed by a subsequence number, yyy, used when several D. files are created for a work (C.) file.
|X. (execute file)|
Execute files are created in the spool directory prior to remote command executions. The names of execute files have the following format:
sys is the name of the remote computer, n is the character representing the grade (priority) of the work, and xxxx is a four-digit sequence number assigned by UUCP. Execute files contain the following information:
Setting up UUCP involves five steps:
Determine the remote and local stations. See “Determining the Remote and Local Stations for a UUCP Connection”.
Make the physical connection. See “Making the Physical Connection for UUCP”.
Configure the local (calling) station. See “Configuring the Local Station for UUCP”.
Configure the remote (called) station. See “Configuring the Remote Station for UUCP”.
Test the UUCP connection. See “Testing the UUCP Connection”.
You can also use UUCP on a TCP/IP network. See “Setting Up UUCP on a TCP/IP Connection”.
Typically, the local station is the station that initiates the UUCP connection. The remote station is the station that responds to UUCP connection requests. However, with the arrival of uugetty (a program that allows bi-directional line usage), the distinction between the local and remote station is usually only the station name.
UUCP supports physical connections for TCP/IP local area network connections, direct links, or telephone lines. This example assumes a direct link. The procedure for running UUCP over telephone line or local area networks is similar, requiring minor adjustments to the various configuration files.
A direct link constitutes a connection between two Data Terminal Equipment (DTE) devices. The devices must be fooled into thinking that they are communicating with a Data Communication Equipment (DCE) device. The way to get around this is with a null modem.
The minimum pinning configuration shown in Table 8-3.
Table 8-3. Three-Wire Null-Modem Pinning Configuration
2 Transmit Data
3 Receive Data
3 Receive Data
2 Transmit Data
7 Signal Ground
7 Signal Ground
Attach the null modem cable to serial port two (ttyf2) on the local and remote workstations.
|Note: For more information on cables and modems, see IRIX Admin: Peripheral Devices , Chapter 1, “Terminals and Modems.”|
The remote station name in our example is us, and the local station name is japan. There are two steps in configuring the local station:
Update standard system files—for /etc/passwd, see “Updating /etc/passwd on the Local Station for UUCP ”; for /etc/group, see “Updating /etc/group on the Local Station for UUCP”; for /etc/inittab, see “Updating /etc/inittab on the Local Station for UUCP”.
Modify the UUCP configuration files—for /etc/uucp/Systems, see “Modifying /etc/uucp/Systems on the Local Station for UUCP”; for etc/uucp/Devices, see “Modifying /etc/uucp/Devices on the Local Station for UUCP”; for /etc/uucp/Dialers, see “Modifying /etc/uucp/Dialers on the Local Station for UUCP”; for /etc/uucp/Permissions, see “Modifying /etc/uucp/Permissions on the Local Station for UUCP”.
To ensure proper security and access, you need to ensure that the user entries for uucp and nuucp are both present and correct. The uucp entry in the passwd file is for ownership purposes, and the nuucp entry is for remote UUCP access. Ensure that your password file has both entries and that they are the same as the following example. If the uucp and nuucp entries don't match the following, edit those accounts so they do match.
uucp:*:3:5:UUCP Owner:/usr/lib/uucp:/bin/csh nuucp::10:10:Remote UUCP User:/var/spool/uucppublic:/usr/lib/uucp/uucico
In the above example, the passwd entry for nuucp is split across two lines due to formatting constraints. In the actual file, the entry appears on a single line.
On a newly installed station, neither uucp nor nuucp has a password. It is a good idea to put an asterisk (*) in the password field for uucp, because no one should log in as uucp. You need to assign nuucp a valid password that matches the password you assign for nuucp in the Systems file. (See “UUCP Systems File”. For example, assign nuucp the password “secret.”)
New password: secret Re-enter new password: secret
Check this file to ensure that there are valid groups for both uucp and nuucp. Compare your uucp and nuucp group entries with the following. If there is a discrepancy, correct it now.
This sample entry is for the local station. It allows calls to be initiated on port two, but does not allow incoming calls on the port. Edit your /etc/inittab entry for “t2” as follows:
t2:23:off:/usr/lib/uucp/uugetty -Nt 60 ttyf2 co_9600 # port 2
For complete information on the uugetty command, see the uugetty(1M) reference page. As usual, any time you make a change to the /etc/inittab, you must tell init to read the file again with the telinit q command. Enter the following command:
The Systems file contains information describing the station(s) that the local station knows about. Add the following line to the bottom of the file:
us Any systemx 9600 unused ogin:--ogin: nuucp ssword: \ secret
|Note: The Systems file is read only, so if you are using vi you must force this change to be written out by exiting vi with the :wq! option.|
The first field specifies the name of the station that can call (the remote station). The second field indicates that the specified station can call at any time. The third field tells uucp the name of the device to use (systemx). The third field must match one of the first field entries found in /etc/uucp/Devices. The fourth field specifies the transfer speed (9600). The fifth field is normally used for a phone number, but unused for direct links. The rest of the line handles the login sequence; it is the chat script negotiated between the local station and the remote station. This chat script is very important for a successful uucp connection.
The Devices file contains information about the physical connection between the two stations. Remove the pound sign from the systemx device entry so it looks like the following:
# ---A direct connection to a system systemx ttyf2 - Any direct
|Note: If you have another direct connection to a station on another port, copy the systemx device entry and modify the port number accordingly.|
The first field in the Devices file links the device to the Systems file (third field entry). The second field tells uucp which port to access. The third field is used with an Automatic Call Unit (ACU). Direct links use a dash in the third field. The fourth field specifies the line speed. The “Any” entry allows the speed to be determined by the /etc/inittab file for that particular device. The fifth field contains the dialer name. It must be a valid entry in the /etc/uucp/Dialers file.
This file contains the chat script for the uucp device. Because this is a direct connection, the chat script is picked up from the Systems file. However, there still has to be a valid dialers entry for the direct connection. Verify that the Dialers file has an entry for the “direct” dialer. Enter the following command:
grep direct /etc/uucp/Dialers
The system responds with
direct # The following entry is for use with direct connections uudirect "" "" \r\d in:--in:
The Permissions file controls remote uucp access with regard to remote users and stations. (See “UUCP Permissions File”, for descriptions of all of the options.) For this example, edit the Permissions file to look like the following:
#dent"@(#)uucp:Permissions2.2" # This entry for public login. # It provides the default permissions. # See the Basic Networking Utilities Guide for more information. LOGNAME=nuucp MACHINE=us READ=/var/spool/uucp/uucppublic \ WRITE=/var/spool/uucppublic REQUEST=yes SENDFILES=yes \ COMMANDS=rmail
|Note: This entry must be interpreted as a single line, even if it exceeds more than one physical line.|
This entry specifies that the user, nuucp, is allowed to log in from the remote station (us). The nuucp user on us may read any files that reside in /var/spool/uucp/uucppublic directory and write to the general public directory /var/spool/uucppublic. The users on us may make requests. Users on japan can send files.
The remote station name in our example is japan. The local station name in our example is us. There are two steps in configuring the remote station:
Update standard system files—For /etc/passwd see “Updating /etc/passwd on the Remote Station for UUCP”; for etc/group, see “Updating /etc/group on the Remote Station for UUCP”; for /etc/inittab see “Updating /etc/inittab on the Remote Station for UUCP”.
Modify the UUCP configuration files—For /etc/uucp/Systems see “Modifying /etc/uucp/Systems on the Remote Station for UUCP”; for /etc/uucp/Permissions see “Modifying /etc/uucp/Permissions on the Remote Station for UUCP”.
To ensure proper security and access, you need to ensure that the user entries for uucp and nuucp are both present and correct. The uucp entry in the passwd file is for ownership purposes and the nuucp entry is for remote UUCP access. Ensure that your password file has both entries and that they are the same as the following example. If the uucp and nuucp entries don't match the following, edit them so they do match:
uucp:*:3:5:UUCP Owner:/usr/lib/uucp:/bin/csh nuucp::10:10:Remote UUCP User:/var/spool/uucppublic:/usr/lib/uucp/uucico
On a newly installed station, neither uucp nor nuucp has a password. It is a good idea to put an asterisk (*) in the password field for uucp, because no one should log in as uucp. You need to assign nuucp a valid password that matches the password you assign for nuucp in the Systems file. (See “UUCP Systems File”.) Assign nuucp the password “secret” with this command:
New password: secret Re-enter new password: secret
Check this file to ensure that there are valid groups for both uucp and nuucp. Compare your uucp and nuucp group entries with the following example. If there is a discrepancy, correct it now.
This sample entry is for the remote station. It allows calls to be received on serial port 2, but does not allow outgoing calls on the port. Edit your /etc/inittab entry for “t2” as follows:
t2:23:respawn:/usr/lib/uucp/uugetty -Nt 60 ttyf2 co_9600#pt 2
For complete information on the uugetty command, see the uugetty(1M) reference page. As usual, any time you make a change to the /etc/inittab, you must use the telinit q command to tell init to read the file again. Enter the following command:
The Systems file contains information describing the station(s) that the remote station knows about. Add this line to the bottom of the Systems file:
|Note: The permission of the Systems file is read only. If you edit this file, you may have to use a forced write in order to save your changes. Consult the jot or vi reference page for more information.|
The first field specifies the name of a station that can call the local station. The second field indicates the times this station can make the call. The value Never in this field indicates that this station may receive calls, but never initiate them.
The Permissions file controls remote uucp access with regard to remote users and stations. (See “UUCP Permissions File”, for descriptions of all the options.) For this example, edit the Permissions file to look like the following:
#ident"@(#)uucp:Permissions2.2" # This entry for public login. # It provides the default permissions. # See the Basic Networking Utilities Guide for more information. LOGNAME=nuucp MACHINE=japan READ=/var/spool/uucp/uucppublic\ WRITE=/var/spool/uucppublic REQUEST=yes SENDFILES=yes \ COMMANDS=rmail
|Note: This entry must be interpreted as a single line, even if it expands to more than one physical line.|
This entry specifies that the user, nuucp, is allowed to log in from the local station (japan). The nuucp user on japan may read any files that reside in /var/spool/uucp/uucppublic directory and write to the general public directory /var/spool/uucppublic. The users on japan may request files. The users on us can send files.
There are two basic tools for testing a UUCP connection:
the cu program described in “Testing the UUCP Connection With cu”
the Uutry program described in “Testing the UUCP Connection With Uutry ”
The cu program is used to test the basic functionality of the UUCP connection. When you use cu directly, you are performing the login process as if you were the uucp programs. The cu command is also used for direct modem connections for terminal emulation. The -d option to cu is used for diagnostics and causes traces of information to be printed out to the standard output (your shell window). You should always use this mode when testing a UUCP connection.
The cu command tests the physical connection to the remote station, UUCP configuration files, operating system files, and the uucico daemon on the remote station.
|Note: The default permissions on devices (/dev/ttyf2) are set to 622. For cu to access your device, you need to change the permissions to 666.|
The cu command must be run from the local (calling) station. Enter the cu command from the local station (japan) as follows:
/usr/bin/cu -d us
You see output similar to the following:
conn(us) Device Type us wanted mlock ttyf2 succeeded filelock: ok fixline(5, 9600) processdev: calling setdevcfg(cu, us) gdial(direct) called getto ret 5 device status for fd=5 F_GETFL=2,iflag=`12045',oflag=`0',cflag=`6275',lflag=`0',line=`1' cc=`177',=`34',=`10',=`25',=`1',=`0',=`0',=`0', call _mode(1) Connected _receive started transmit started
When the system pauses, press Enter.
When you see the login prompt, log in as nuucp and supply the password for nuucp (in this case, the password is secret):
Break your connection with a tilde(~) dot(.) and a carriage return (<CR>). us login: nuucp Password: secret IRIX Release 6.2 IP22 us Copyright (c) 1987-1996 Silicon Graphics, Inc. All Rights Reserved. Last login: Thu Aug 8 09:14:29 MDT 1996 on ttyf2 here=japan~[us]. call tilda(.)
Uutry is the program that tests the copy-in/copy-out program (uucico). uucico must be functioning properly before you can actually transfer data. Enter the Uutry command from the local station (japan) to the remote station (us):
You should see output similar to the following:
/usr/lib/uucp/uucico -r1 -sus -x5 >/tmp/us 2>&1& tmp=/tmp/us mchFind called (us) conn(us) Device Type us wanted mlock ttyf2 succeeded processdev: calling setdevcfg(uucico, us) gdial(direct) called getto ret 5 expect: (ogin:)
|Note: The system may pause here for several minutes.|
sendthem (^M) expect: (ogin:) ^M^M^J^M^J^Jus login:got it sendthem (nuucp^M) expect: (ssword:) nuucp^M^JPassword:got it sendthem (secret^M) Login Successful: System=us msg-ROK Rmtname us, Role MASTER, Ifn - 5, Loginuser - root rmesg - 'P' got Pg wmesg 'U'g Proto started g *** TOP *** - role=1, setline - X wmesg 'H' rmesg - 'H' got HY PROCESS: msg - HY HUP: wmesg 'H'Y cntrl - 0 send OO 0,exit code 0 Conversation Complete: Status SUCCEEDED
When you see Status SUCCEEDED, Uutry has successfully tested uucico. Press Ctrl+C to break out of Uutry.
In many cases, you may decide to use the UUCP tools over conventional TCP/IP network connections. There are entries in the Devices file provided for this, but you must make some changes in the /usr/etc/inetd.conf and /etc/uucp/Systems files. Follow these steps:
Edit the /usr/etc/inetd.conf file on the remote host and find this line:
#uucp stream tcp nowait root /usr/lib/uucp/uucpd uucpd
Remove the leading hashmark (#) to uncomment the line, and use these commands to make the change take effect:
/etc/init.d/network stop /etc/init.d/network start
This change tells the remote system to run the uucpd daemon when a request comes in for UUCP transfer.
Add a line similar to the following to your local /etc/uucp/Systems file:
remotehost Any TCP Any
The name remotehost should be replaced with the name of the remote host you will be calling.
Run the /etc/uucp/genperm command as root on the local host to generate the UUCP Permissions file.
Enter the following command to check that everything is set up correctly:
There is a great deal of output. You should see output similar to the following for the specific entry you made:
When we call system(s): (remotehost) We DO allow them to request files. They can send files to /var/spool/uucppublic (DEFAULT) They can request files from /var/spool/uucppublic /usr/lib/mail /usr/people/ftp Myname for the conversation will be MyName. PUBDIR for the conversation will be /var/spool/uucppublic. Machine(s): (remotehost) CAN execute the following commands: command (rmail), fullname (/bin/rmail) command (rnews), fullname (/usr/bin/rnews) command (cunbatch), fullname (/usr/lib/news/cunbatch)
The cu command does not work for UUCP over a TCP connection. Use the /usr/lib/uucp/Uutry command instead. Uutry is documented completely in the Uutry(1M) reference page and in “Testing the UUCP Connection With Uutry ”.
This section describes common error messages associated with the UUCP environment. UUCP error messages can be divided into two categories: ASSERT error messages described on “ASSERT Error Messages”; and STATUS error messages, described on “STATUS Error Messages”.
When a process is aborted, the station records ASSERT error messages in /var/spool/uucp/.Admin/errors. These messages include the filename, the sccsid, the line number, and the text listed in Table 8-4. In most cases, these errors are the result of file system problems.
Table 8-4. Assert Error Messages
An open() or fopen() failed.
A write(), fwrite(), fprint(), or other call failed.
A read(), fgets(), or other call failed.
A create() call failed.
A dynamic allocation failed.
An attempt to make an LCK (lock) file failed. In some cases, this is a fatal error.
A stat() call failed.
A chmod() call failed.
A link() call failed.
A chdir() call failed.
An unlink() call failed.
This is an internal logic problem.
CAN'T MOVE TO CORRUPT DIR
An attempt to move some bad C. or X. files to the /var/spool/uucp/.Corrupt directory failed. The directory is probably missing or has wrong modes or owner.
A close() or fclose() call failed.
The creation of a C. or D. file was attempted, but the file already exists. This situation occurs when there is a problem with the sequence-file access. This usually indicates a software error.
NO UUCP SERVER
A TCP/IP call was attempted, but there is no server for UUCP.
The uid cannot be found in the /etc/passwd file. The filesystem is in trouble, or the /etc/passwd file is inconsistent.
The uid cannot be found in the /etc/passwd file. The filesystem is in trouble, or the /etc/passwd file is inconsistent.
ULIMIT TOO SMALL
The ulimit for the current user process is too small. File transfers may fail, so transfer will not be attempted.
There is a bad line in the Devices file; there are not enough arguments on one or more lines.
FSTAT FAILED IN EWRDATA
There is something wrong with the Ethernet media.
An internal table in gename.c overflowed. A big or strange request was attempted.
TOO MANY SAVED C FILES
An internal table in gename.c overflowed. A big or strange request was attempted.
RETURN FROM FIXLINE IOCTL
An ioctl, which should never fail, failed. There is likely a system driver problem.
PERMISSIONS file: BAD OPTION
There is a bad line or option in the Permissions file. Fix it immediately.
A bad line-speed appears in the Devices or Systems file (Class field).
The remote station probably hung up. No action is required.
The remote station aborted in a nonrecoverable way. This message can generally be ignored.
There is a problem with the modes of /var/spool/uucp/.Status, or there is a file with bad modes in the directory.
TOO MANY LOCKS
There is an internal problem.
There is a problem with some file or directory. The problem is likely caused by the spool directory, because the modes of the destinations should have been checked before this process was attempted.
An attempt to fork and execute failed. The current job should not be lost, but will be attempted later (uuxqt). No action need be taken.
Status error messages are stored in the /var/spool/uucp/.Status directory. This directory contains a separate file for each remote station that your station attempts to communicate with. These files contain status information on the attempted communication, indicating whether it was successful or not. Table 8-5 lists the most common error messages that can appear in these files.
Table 8-5. STATUS Error Messages
System status is normal
NO DEVICES AVAILABLE
There is currently no device available for the call. Make sure that there is a valid device in the Devices file for the particular station. Check the Systems file for the device to be used to call the station.
WRONG TIME TO CALL
A call was placed to the station at a time other than that specified in the Systems file.
The login for the given station failed. The problem could be a wrong login and password, wrong number, a very slow station, or failure in getting through the Dialer-Token-Pairs script.
The conversation failed after successful startup. This situation usually means that one side went down, the program aborted, or the line (link) was dropped.
The remote station never answered. The problem could be a bad dialer or the wrong phone number.
BAD LOGIN/MACHINE COMBINATION
The station called you with a login or station name that does not agree with the Permissions file. This could be an attempt to breach system security.
The calling device to be used is currently locked and in use by another process.
An ASSERT error occurred. Check the /var/spool/uucp/.Admin/errors file for the error message and refer to “Other UUCP Files”.
SYSTEM NOT IN Systems
The station is not in the Systems file.
CAN'T ACCESS DEVICE
Typically, this message means that the permissions on the device file (/dev/tty*) are not set correctly. Some programs set these permissions, and if terminated abnormally, do not reset them to correct states. Also, check the appropriate entries in the Systems and Devices files.
The attempt to open the device failed.
WRONG MACHINE NAME
The called station is reporting a name different from the one expected.
The called station requires that it call your computer back to start a connection.
REMOTE HAS A LCK FILE FOR ME
The remote site has a LCK file for your computer. The remote station could be trying to call your computer. If they have an older version of UUCP, the process that was talking to your station may have failed earlier, leaving the LCK file. If the remote site has the new version of UUCP and they are not communicating with your computer, then the process that has a LCK file is hung.
REMOTE DOES NOT KNOW ME
The remote computer does not have the node name of your computer in its Systems file.
REMOTE REJECT AFTER LOGIN
The ID used by your computer to log in does not agree with what the remote computer was expecting.
REMOTE REJECT, UNKNOWN MESSAGE
The remote computer rejected the communication with your computer for an unknown reason. The remote computer may not be running a standard version of UUCP.
Login succeeded, but initial handshake failed.
CALLER SCRIPT FAILED
The problem indicated by this message is usually the same as that indicated by DIAL FAILED. However, if it occurs often, suspect the caller script in the Dialers file. Use uutry to check the caller script.