The UUCP package consists of a group of programs that provide remote file transfer (uucp), remote command execution (uux), and mail to and from remote sites.
See also:
To set up the standard UUCP system, you need:
To set up the connection, edit the /usr/lib/uucp/Systems and /usr/lib/uucp/Devices files. You can use the UUCP Manager/uuinstall utility to help you do this.
The Systems file in /usr/lib/uucp contains a list of the systems that UUCP knows about, and specifies the device and method used to contact each system. The Devices file identifies the usable devices, speed to use, and the serial ports that the devices are connected to.
To configure UUCP on a computer called topaz:
UUCP Administration Utility
===========================
1. Display or update site name
2. Display or update list of remote sites (Systems)
3. Display or update direct- or dial-out lines (Devices)
4. Display or update direct- or dial-in lines (/etc/inittab)
5. Check consistency of UUCP files
6. Test connection with remote site
7. Convert old UUCP files to new format
Choose an option (1-7), or q to quit :
Display or update list of remote sites (Systems)
================================================
1. Display the Systems file
2. Add a new site entry
3. Delete a site entry
4. Change a site entry
Choose an option (1-4), or q to quit :
Select Add a new site entry. uuinstall prompts you to
enter information about the new site a line at a time:
Site name : emerald Schedule : Any Device type : ACU Speed range : 2400 Phone number : 0123456789 Expect login : ogin:-@-ogin:-@-ogin: Send login : topaz Expect login : ssword: Send login : bbsuucpThese fields are described in detail in ``Adding entries for remote sites to the Systems file''.
You should see a menu like this:
Display or update direct- or dial-out lines (Devices) =====================================================Having defined a site to contact, it is necessary to configure the device used to contact the site. In the Systems file (step 4) you specified that the device ACU should be used. So it is necessary to add (or change) the device entry for ACU:1. Display the Devices file 2. Add a new device entry 3. Delete a device entry 4. Change a device entry
Choose an option (1-4), or q to quit :
Device type ? ACU Tty line ? tty1A Dialer line ? - Speed range ? 2400 Dialer ? hayes2400 Switch token ? New entry is accepted :These fields are described in detail in ``Specifying dial-up parameters with the Devices file''. (If you are not using a Hayes compatible modem, you may need to change the ``Dialer'' field, and optionally the ``Speed range'' field.) Use the dialer same dialer name that you used when you configured your modem. The dialers provided are described in ``Using dialers'' in the SCO OpenServer Handbook.
After adding or updating the ACU device, you should return to the main menu.
Display or update direct- or dial-in lines (/etc/inittab) =========================================================Select Enable login on a line to enable login on a line, and enter the name of the line. (Display the inittab file for a list of acceptable lines.) Note that if the kernel is subsequently relinked, it is necessary to reenable any lines allocated for UUCP logins.1. Display inittab file 2. Enable login on a line 3. Disable login on a line
These fields are described in ``Limiting access with the Permissions file''.
See ``How a UUCP transmission proceeds'' for a discussion of the output from uutry.
For information on these procedures, see:
See
``How UUCP works''
for a description of the functions of the UUCP configuration
files mentioned in
``Setting up a simple UUCP connection''.
Read
``How UUCP works''
carefully before running uuinstall so that you
understand the UUCP database.
Setting up maintenance scripts
There are several aspects of system operation that are governed by
shell scripts running as daemons. These scripts must be set up
by the system administrator. See the
uudemon(ADM)
manual page for complete instructions.
Use uudemon.poll2 to set up the polling schedule. To run uudemon.poll2, you need an entry for the daily daemon and an entry for the hourly daemon in the /usr/spool/cron/crontabs/uucp file as follows:
0 0 * * * /usr/lib/uucp/uudemon.poll2 -d 0 * * * * /usr/lib/uucp/uudemon.poll2The -d flag refers to the daily daemon. The hourly daemon has no flags. The above example has the daemon run at midnight. You can change the time the daemon runs by altering the second field using a 24-hour clock.
To establish the hours and days that uudemon.poll2 runs, create two files: /usr/lib/uucp/Poll.hour and /usr/lib/uucp/Poll.day. These files contain the systems to be polled and the times and days they are polled.
A sample Poll.hour file follows:
hanna 12 1 3 raven 2 6 10wIf the hour is followed by a ``w'', uudemon.poll2 calls the site only if there is work to be done.
A sample Poll.day file follows:
hanna 1 3 6 raven 1 2 3 4 5The days of the week are integers, with Sunday being 0.
A UUCP login account is the same as an ordinary user account but it has a special login directory and login program instead of the normal user directory and shell.
To create a UUCP login entry:
Make sure the name and ID are unique. A UUCP login entry must not have the same name or ID as any other login entry.
Passwords are optional, but recommended, for UUCP logins. For information about what happens when a UUCP system with no account tries to dial in, see ``Preventing unknown sites from logging in''.
UUCP login accounts are created with no password expiration. To alter this, see ``Controlling password expiration''.
If you have difficulties with UUCP accounts being locked
(messages like dead account are displayed), you can change
the number of login attempts by selecting
as described in
``Locking or unlocking a user account''.
In addition, the Systems file can be configured to prevent any computer that does not appear in this file from logging in on your computer. More than one entry may be present for a particular computer. The additional entries represent alternative communication paths that can be tried in sequential order.
guardian Never
Each entry in the
Systems
file has the following format
(each field must be separated by a space):
sitename schedule device speed phone login-script
where:
The schedule field consists of three subfields. The first, day, is required. The other two, time and retry, are optional. The syntax is as follows:
day[time][;retry]
The day subfield can contain the following keywords:
For example, the following permits calls on Mondays, Wednesdays, and Fridays between the hours of 9:00am and noon (the schedule field is in boldface for clarity):
grebe MoWeFr0900-1200 ACU D1200 14087672676 ogin:
nuucp ssword: Crested
You can also specify more than one set of day and time
entries by separating them with commas.
This is useful for more complex specifications.
The following example allows calls from 5:00pm to 8:00pm, Monday
through Thursday, and calls any time
on Saturday and Sunday.
This example would be an effective way to call only when
phone rates are low, if immediate transfer is not critical:
gorgon Wk1700-0800,SaSu ACU D1200 14087672676 ogin:
nuucp ssword: DontLook
The optional subfield, retry,
is available to specify the minimum time (in minutes)
before a retry following a failed attempt.
The subfield separator is a semicolon (;). For example,
the following is interpreted as ``call any time, but wait at
least 9 minutes before retrying after a failure occurs'':
Any;9By default, UUCP uses a method called exponential backoff to allow retry of failed calls. UUCP does not allow another call to go through until after the retry time has elapsed. This interval expands exponentially as the number of unsuccessful attempts increases. The retry field overrides the exponential backoff algorithm. If you set the retry field to 9, for example, UUCP allows another attempt to connect 9 minutes after each failure. The retry field cannot be set lower than 5 minutes.
UUCP does not automatically try a failed call again.
You must have polling set up as described in
``Setting up polling''
or manually invoke
uucico(ADM).
Any files not transferred due to a connection failure are
transferred at the next successful connection to that system.
The device field selects the device type, in most cases
an ACU (Automatic Call Unit).
For example, the keyword used in the following field is
matched against the first field of
Devices
file entries:
Systems: gorgon Any ACU D1200 14087672676 ogin:
nuucp ssword: DontLook
Devices: ACU tty2A - 1200 /usr/lib/uucp/dialHA12
Additional documentation on the device field is located in the /usr/lib/uucp/Systems file supplied with your system.
This field can contain a letter
and speed (for example, C1200, D1200)
to differentiate between classes of dialers -- refer to
``The speed field''.
Some devices can be used at any speed, so the keyword
Any can be used.
However, we recommend that you specify the actual range of speeds
that can be used. (If Any
is used in both Systems and Devices
entries, 1200 is assumed.) For example, this field must intersect the
speed field in the associated Devices file entry:
Systems: gorgon Any ACU D2400-9600 14087672676 ogin:
nuucp ssword: DontLook
Devices: ACU tty1A - D2400-9600 /usr/lib/uucp/dialHA9600
If information is not required for this field, use a hyphen (-) as a place holder for the field.
Some modems can determine the connection baud rate from the carrier sent by a remote system. These modems inform the local system of the connection baud rate before issuing the Carrier Detect (CD) signal. The Hayes 2400 dialer supplied with UUCP detects different connection baud rates and informs UUCP and cu when it exits with a successful connection.
The speed fields in Devices and Systems can specify a range
of baud rates for a connection. If a dialer supports baud rates from 300
to 2400 baud, enter the baud rate range in the speed field of Devices
as follows:
300--2400
If a dialer or modem does not allow variable baud rates, place a single baud rate in the speed field. If a remote system supports several different speeds, place the range of baud rates in the speed field of Systems. If the remote system connects at a single baud rate, place that number in Systems. UUCP passes the highest common speed of the Systems and Devices baud rate ranges to the dialer when connecting. If the dialer connects outside of the baud range in the Systems file, it returns a bad baud rate error. Otherwise, it returns the baud rate of the connection.
This field provides the phone
number used for the modem dialer.
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.
(See
``Creating a portable UUCP Systems file''
for details.)
For example:
Systems: gorgon Any ACU D1200 CA2676 ogin:
nuucp ssword: DontLook
Dialcodes: CA 9=408767
In this string, an equal sign (=) tells the ACU to wait for a secondary dial tone before dialing the remaining digits. A dash in the string (-) instructs the ACU to pause 2 seconds before dialing the next digit.
Do not use the comma (from the Hayes command set) in a Systems file entry when you wish to indicate a pause. Use hyphens instead.
If your computer is connected to a LAN switch or port selector, you can access other computers that are connected to that switch. The Systems file entries for these computers do 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 knows which computer your computer wishes to communicate with. (This is usually just the system name.) The associated Devices file entry should have a ``\D'' at the end of the entry to prevent translation using the Dialcodes entry.
The login-script opens communications between modems,
and also recognizes and sends proper login and password sequences.
The script a series of space-separated fields and subfields
of the following format:
expect send
where expect is the string that is received, and send is the string that is sent when the expect string is received.
The expect field can be made up of subfields of the following form:
expect[-subsend-subexpect]...
where the subsend is sent if the prior expect is not successfully read and the subexpect following the subsend is the next expected string. To make this distinction clear: the send-expect sequence sends a string if the expect string is received; the subsend-subexpect sends only if the prior expect string is not received within 10 seconds.
For example, with ``login:--login:'', the UUCP program expects ``login:''. If a ``login:'' is received, it goes on to the next field. If it does not get ``login:'', it sends nothing followed by a carriage return, then looks for ``login:'' again. If no characters are initially expected from the remote computer, the null string ("") should be used in the first expect field. Note that all send fields are sent followed by a carriage return unless the send string is terminated with a ``\c''.
If an expect string starts with a dash, it is interpreted as a null expect string followed by a subsend string. For example, ``--login:'' sends a carriage return and then expects a ``login:''.
The expect string need not be complete; only the trailing characters must be specified, as in ``ogin:''. This avoids difficulties with login strings that use an uppercase letter as in ``Login:'' or ``Password:'', and also difficulties when the line is shared by dial-in and dial-out.
This section explains in greater detail how to create a login (``chat'') script.
Consider the following sample Systems file entry:
terps Any ACU 1200 18005211980 "" \r ogin:-BREAK-ogin:
uucpx word: ichore
This is how this script would work during connection:
Table 7-1 Login (Chat) script escape sequences
------------------------------------------------------
Character Description
------------------------------------------------------
\N sends a null character (ASCII NULL).
\b sends or expects a backspace character.
\c if at the end of a string, suppresses the
carriage return that is normally sent.
Ignored otherwise.
\d delays two seconds before sending or
reading more characters.
\p pauses for approximately ¼ to ½ second.
\E starts echo checking. (After this sequence
is used, whenever a character is
transmitted, the system waits for the
character to be received before doing
anything else.)
\e turns echo check off.
\n sends or expects a newline character.
\r sends or expects a carriage-return.
\s sends or expects a space character.
\t sends or expects a tab character.
\\ sends or expects a ``\'' character.
EOT sends EOT (end of transmission or <Ctrl>d)
BREAK sends a BREAK signal.
\K same as BREAK.
\ddd collapses the octal digits (ddd) into a
single character whose value is the ASCII
character represented by that number (for
example: \007).
"" expects a null string.
Each entry in the Devices file has the following format:
type ttyline dialerline speed dialer-token
where:
This field usually contains one of two keywords (Direct or ACU) the name of a Local Area Network switch, or a system name.
gorgon tty1a - 1200 direct
Systems: gorgon Any gorgon 1200 - ogin: nuucp ssword: DontLook
You can designate a protocol to use for a device within this field. For more information, see ``Defining a communications protocol''.
In most cases, this is simply the speed of the device,
if the keyword ACU or Direct is used in the type field.
However, speed
can contain a letter and a speed
(for example, C1200, D1200) to differentiate between
classes of dialers (Centrex or Dimension PBX).
This is necessary because many larger offices
may have more than one type of telephone network:
one network may be dedicated to serving only
internal office communications, while another handles the external
communications.
It is necessary to distinguish which lines
are used for internal communications and
which are used for
external communications. The keyword used in the
speed field of the Devices file
is matched against the fourth field of the Systems file entries,
for example:
Devices: ACU tty1A - D1200 hayes1200
Systems: gorgon Any ACU D1200 3251 ogin: nuucp ssword: DontLook
Some devices can be used at any speed, so the keyword Any can be used in the speed field. If Any is used, the line matches any speed requested in a Systems file entry. If this field is Any and the Systems file speed field is Any, the speed defaults to 1200bps. If a device can be used at a range of speeds, then the speed field can specify this range (for example, 1200--9600 or D1200--9600). This is preferable to the use of Any.
This field has the following format:
dialer [ token dialer token ... ]
For a direct line, this field contains simply the word direct, and no token is required.
For a simple connection to a dialer, this field contains the name of the dialer, and the token is omitted; by default it is taken from the phone number field of the Systems file entry.
For a dialer or a network dataswitch, this field contains the name of an entry found in the Dialers file (develcon and micom are examples of network data switches). Other dialer types are supported by binaries instead of Dialers entries. (Support for 801-type dialers is provided through use of separate lines for data and the dialer. See the Devices file for details.) UUCP recognizes a dialer as a binary if the name begins with a ``/'' or if there is an executable file by that name in /usr/lib/uucp.
For more information on Dialers entries and binaries, see ``Using dialers'' in the SCO OpenServer Handbook.
The dialer-token can be structured four different ways, depending on the device associated with the entry:
If an automatic dialing modem is connected directly to
a port on your computer, the dialer-token field of the associated
Devices file entry only has one pair.
This pair would normally be the name of the modem.
This name matches the particular Devices
file entry with an entry in the Dialers file.
Therefore, the dialer field must match the first field of
the following Dialers file entry:
Devices: ACU tty1A - 1200 ventel
Dialers: ventel =&-% "" \r\p\r\c $ <K\T%%\r>\c ONLINE!
Notice that only the dialer portion (ventel) is present in the dialer-token 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. ``\D'' is implied; see Modems used with a local network switch . Backslash sequences are described later.
If a direct-link is established to a particular computer, the dialer-token field of the associated entry contains the keyword direct. This is true for both types of direct link entries, direct and sysname (refer to discussion on the type field).
If a computer that you wish to communicate with is
on the same local network switch as your
computer, your computer must first access the switch
and the switch can then make the connection to the other
computer.
In this type of entry, there is only one pair.
The dialer portion matches a Dialers file entry, as
shown in the following example:
Devices: develcon tty13 - 1200 develcon \D
Dialers: develcon "" "" \pr\ps\c est:\007 \E\D\e \007
Systems: obie develcon ACU 1200 obie --ogin:-BREAK-ogin:
nuucp ssword: mavra
The token portion is ``\D'', which indicates that it is retrieved from the Systems file without translation. The Systems file entry for this particular computer contains the token in the phone field, which is normally reserved for the phone number of the computer (refer to Systems file, phone field). The ``\D'' ensures that the contents of the phone field is not interpreted as a valid entry in the Dialcodes file.
If an automatic dialing modem is connected to a switch,
your computer must first access the switch and the
switch makes the connection to the automatic dialing modem.
This type of entry requires two dialer-token pairs.
The following dialer
portion of each pair (fifth and seventh fields of entry)
are used to match entries in the Dialers file:
Devices: ACU tty14 - 1200 develcon vent ventel
Dialers: develcon "" "" \pr\ps\c est:\007 \E\D\e \007
ventel =&-% "" \r\p\r\c $ <K\T%%\r>\c ONLINE!
In the first pair, develcon is the switch and vent is the token that is passed to the develcon switch to tell it which device to connect to your computer. This token would be unique for each LAN switch because each switch can be set up differently. Once the modem is connected, the second pair is accessed, where ventel is the dialer and the token is retrieved from the Systems file.
Each entry is a logical line with physical lines
terminated by a ``\'' to indicate continuation.
Entries are made up of options delimited by spaces.
Each option is a name-value pair in the following format:
name=value
Comment lines begin with a number sign (#) and they 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:
When using the Permissions file to restrict the level of access granted to remote computers:
This section describes each option, specifies how it is used, and lists its default values.
REQUEST=yesThe following string specifies that the remote computer cannot request files from your computer:
REQUEST=nowhich is the default value (it is 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.
The following string specifies that your computer can send the work that is queued for the remote computer as long as the remote computer is logged in as one of the names in the LOGNAME option:
SENDFILES=yesThis string is mandatory if your computer is in a passive mode with respect to the remote computer.
The following string specifies that files queued in your computer be sent only when your computer calls the remote computer:
SENDFILES=callThe call value is the default for the SENDFILES option. This option is only significant in LOGNAME entries because MACHINE entries apply when calls are made out to remote computers. If this option is used with a MACHINE entry, it is ignored.
The default for both the READ and WRITE options is the uucppublic directory as shown in the following strings:
READ=/usr/spool/uucppublic WRITE=/usr/spool/uucppublicThe following strings specify permission to access any file that can be read or written by UUCP.
READ=/ WRITE=/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/tmp as well as the public directory, the following values would be used with the WRITE option:
WRITE=/usr/spool/uucppublic:/usr/tmpIt should be pointed out that if the READ and WRITE options are used, all pathnames must be specified because the pathnames are not added to the default list. For instance, if the /usr/news pathname was 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 systems.
For example, you probably do not want remote computers to be able
to write over your /etc/passwd file so /etc
should not be open to writes.
READ=/ WRITE=/usr/spool/uucppublic NOREAD=/etc NOWRITE=/etcNOWRITE works in the same manner as the NOREAD option. The NOREAD and NOWRITE options can be used in both LOGNAME and MACHINE entries.
The following string specifies that your computer must call the remote computer back before any file transfers take place:
CALLBACK=yesThe default for the CALLBACK option is:
CALLBACK=noThe CALLBACK option is rarely used. If two sites have this option set for each other, a conversation never gets started.
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. Note that COMMANDS is not used in a LOGNAME entry; COMMANDS in MACHINE entries define command permissions whether you call the remote system or it calls you.
The default command that a remote computer can execute on your computer is:
COMMANDS=rmailIf a command string is used in a MACHINE entry, the default commands are overridden. For instance, the following entry overrides the COMMAND default so that the computers owl, raven, hawk, and dove can now execute rmail, rnews, and lp on your computer:
MACHINE=owl:raven:hawk:dove \ COMMANDS=rmail:rnews:lpFull pathnames of commands can also be used. For example, the following command specifies that command rmail uses the default path:
COMMANDS=rmail:/usr/lbin/rnews:/usr/bin/lpThe default paths for your computer are /bin, /usr/bin, and /usr/lbin. When the remote machine specifies rnews or /usr/lbin/rnews for the command to be executed, /usr/lbin/rnews is executed regardless of the default path. Similarly, /usr/bin/lp is the lp command that is executed.
Including the ALL value in the list means that any command from the remote computer specified in the entry is executed. If you use this value, you give the remote computer full access to your computer. Be careful, this allows far more access than normal users have.
The following string illustrates two points:
COMMANDS=/usr/local/bin/lc:ALL:/usr/bin/lp
Careful consideration should be given to providing a remote computer with a privileged login and password for UUCP transactions. Giving a remote computer a special login and password with file access and remote execution capability is like giving anyone on that computer a normal login and password on your computer. Therefore, if you cannot trust someone on the remote computer, do not provide that computer with a privileged login and password.
The following LOGNAME entry specifies that if one of the remote computers that claims to be eagle, owl, or hawk logs in on your computer, it must have used the login uucpfriend.
LOGNAME=uucpfriend VALIDATE=eagle:owl:hawkAs can be seen, if an outsider gets the uucpfriend login or password, masquerading is trivial.
VALIDATE increases security by linking 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 machine is logged in. In fact, it is an asynchronous process with no knowledge of what machine sent the execution request. How does your system 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 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. 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:
MACHINE=eagle:owl:hawk REQUEST=yes \ COMMANDS=rmail:/usr/local/bin/lc \ READ=/ WRITE=/The COMMANDS option line shows that remote mail and /usr/local/bin/lc can be executed by remote users.LOGNAME=uucpz VALIDATE=eagle:owl:hawk \ REQUEST=yes SENDFILES=yes \ READ=/ WRITE=/
In the MACHINE entry, you must make the assumption that when you want to call one of the computers listed, you are really calling eagle, owl, or hawk. 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 are also put in the privileged spool directory. You should validate that the computer has the privileged login uucpz.
MACHINE=OTHER \ COMMANDS=rmail:/usr/local/bin/lcAll options that can be set for specific machines or logins can be used with the OTHER value, although the use of the VALIDATE option makes little sense.LOGNAME=OTHER \ REQUEST=yes SENDFILES=yes \ READ=/usr/spool/uucppublic \ WRITE=/usr/spool/uucppublic
MACHINE=eagle:owl:hawk REQUEST=yes \
READ=/ WRITE=/
LOGNAME=uucpz REQUEST=yes SENDFILES=yes \
READ=/ WRITE=/
These two entries can be merged as follows:
MACHINE=eagle:owl:hawk REQUEST=yes \
LOGNAME=uucpz SENDFILES=yes \
READ=/ WRITE=/
The uucp traffic is managed by three daemons (supervisory programs) which run in the background, handling file transfers and command executions. (The daemons can also be executed manually as commands.)
When you enter a UUCP command, the program creates a work file and (usually) a data file for the requested transfer. The work file contains information required for transferring the file. The data file is a copy of the specified source file. After these files are created in the spool directory, the uucico daemon is started.
The uucico daemon attempts to establish a connection to the remote computer. See ``A sample UUCP transaction'' for an example of a session.
When uucico logs in on the remote computer, the remote computer starts a uucico daemon. The two uucico daemons then negotiate the line protocol to be used in the file transfer. The local uucico daemon then transfers the file that you are sending to the remote computer. The remote uucico places the file in the specified pathname on the remote computer. After your local computer finishes sending files, the remote computer may take over and send queued files to your local computer.
If the remote computer or the device selected to make the connection to the remote computer is unavailable, the request remains queued in the spool directory. If set up to run by cron each hour, uudemon.hour starts the uusched daemon. When the uusched daemon starts, it searches the spool directory for the remaining work files, generates the random order in which these requests are to be processed, and then starts the transfer process (uucico) described in the previous paragraphs.
The following steps trace the execution of a uucp command:
Note that obie\!\
A UUCP session consists of four parts: connection, an initial handshake that establishes the protocol to use, a series of file transfers, and a final handshake. All four parts produce different characteristic debugging output, and it is possible to deduce which element of the session is failing by scrutinizing the output.
When the connection stage begins, uucico scans the Systems file for the system to connect to. Using the device field for the specified system, it opens the Devices file and connects to the named device.
A single example session is documented in the following sections.
The command to invoke this session is uutry -x9 scolon, which sets the debugging level to 9 and makes uutry attempt to connect to system scolon. The beginning of the output shows uucico reading the Systems and Devices files in an attempt to set up a connection:
01: mchFind called (scolon) 02: list (rmail) num = 1 03: name (scolon) not found; return FAIL 04: list (rmail) num = 1 05: name (OTHER) not found; return FAIL 06: _Request (FALSE), _Switch (TRUE), _CallBack (FALSE), _MyName (), _Commands rmail 07: chdir(/usr/spool/uucp/scolon) 08: conn(scolon) 09: Device Type ACU wanted 10: mlock tty1A succeeded 11: fixline(6, 2400) 12: processdev: calling setdevcfg(uucico, ACU) 13: gdial(hayes2400) called
Line 01 indicates that uucico is looking for
scolon in Systems. The next six lines are internal
debugging information from uucico: on line 08 it finds
scolon and attempts to connect to it. From the
Systems file uucico determines that it needs a
device of type ACU. Checking the Devices file,
uucico determines that tty1A is such a device
(line 10) and takes it over (line 11), setting it to the speed stated
in Devices.
Having obtained a suitable device, uucico invokes the dialer hayes2400 to place the call (line 13), and enters the connection script:
14: expect: ("")
15: got it
16: sendthem (ATQ0E0T&D2&C1S0=0X4S2=043^M)
17: expect: (OK^M)
18: ^M^JOK^Mgot it
19: sendthem (ATDT9222681^M)
20: expect: (Speed)
21: ^J^M^JCONNECT 2400got it
22: getto ret 6
23: expect: ("")
24: got it
25: sendthem (^M^M)
26: expect: (ogin:)
27: le /usr/spool/uucppublic/info contains a roadmap of ^J^Mthe bulletin board
areas.^J^M^J^MWARNING: Unauthorized access will be prosecuted.^J^M^J^M^M^Jscolo
n!login:got it
28: sendthem (uusls^M)
29: expect: (ssword:)
30: ic/info contains a roadmap of ^J^Mthe bulletin board areas.^J^M^J^MWARNING:
Unauthorized access will be prosecuted.^J^M^J^M^M^Jscolon!login: uusls^M^JPass
word:got it
31: sendthem (bbsuucp^M)
32: ISTRIP cleared
First the dialer talks to the modem. The standard Hayes modem response
to a successful command is to echo OK; line 16 shows the
dialer sending an initialization string (specified in
/usr/lib/uucp/Dialcodes, or programmed into the dialer
binary) to the modem. (A Hayes ATDT command causes the modem
to tone-dial the following number.) When the modem establishes a
connection, the dialer waits for the modem to return the connection
speed: in this case the standard message CONNECT 2400
indicating a 2400-baud link. (Faster modems may return CONNECT
9600 or CONNECT 14400.)
At this point, the dialer follows the login script given in Systems:
scolon Any ACU 2400-9600 0923 222681 "" \r ogin:-@-ogin:-@-ogin: uusls ssword: bbsuucpFirst, a return is sent. Then, uucico waits for the string "ogin". This is received, and uucico sends "uusls", the appropriate login. (The remote host prints the text of /etc/issue, a message file used for remote logins. uucico ignores the message.) Finally, uucico sees the password prompt, sends a password, and clears the login sequence.
If you run a sample uutry session and encounter problems during this phase, then it is probably due to one of the following conditions:
-BREAK-, replace each
instance of -BREAK- with -@-, this prevents the
UUCP programs from cycling the serial port speed.
Now that the dialer has established a connection, the uucico daemon on the local host starts to negotiate a protocol with the remote uucico.
The ^J^M character pairs appearing in the uutry
output are carriage return and line feed pairs. In DOS,
both characters are needed to indicate the end of a
line: in the Macintosh system a ``^M'' indicates the end of a
line: and in the UNIX system a ``^J'' indicates the end of a
line. Many online services transmit both characters at the end of every
line, in case a different type of system tries to connect and cannot
recognize the local newline format. When reading the uutry
output, a ^M^J character pair should therefore be taken as
indicating a new line.
omsg in the uucico debugging output means that the
local uucico outputs a message: imsg means that the
local uucico reads a message.
uucico ignores the incoming text until it sees a ``^P'' (byte with octal value \020). All messages in the initial handshake begin with a ``^P'' and end with a null byte (represented in this listing as ``^@'').
The first packet is ^PShere=scolon^@.
The Shere= message indicates the remote uucico
is running on scolon.
Here is the protocol negotiation phase:
CB + "protocol" 33 : imsg >^M^JLast successful login for uusls: Wed Aug 11 14:28:58 BST 1993 on tty8C^M^JLast unsuccessful login for uusls: Tue Aug 10 19:41:17 BST 199ik3 on tty8D^M^JSCO UNIX System V/386 Release 3.2^M^JCopyright (C) 1976-1989 UNIX System Laboratories, Inc.^M^JCopyright (C) 1980-1989 Microsoft Corporation^M^J Copyright (C) 1983-1996 The Santa Cruz Operation, Inc.^M^J All Rights Reserved ^M^Jscolon^M^J^PShere=scolon^@Login Successful: System=scolon 34 : omsg "Sjocksco -Q0 -x9" 35 : imsg >^PROK^@msg-ROK 36 : Rmtname scolon, Role MASTER, Ifn - 6, Loginuser - root 37 : rmesg - 'P' imsg >^PPgetxf^@got Pgetxf 38 : wmesg 'U'g 39 : omsg "Ug" 40 : Protocol: g 41 : g window size set to 7 42 : g variable packets set to true 43 : g packet size set to 64 44 : Protocol: G 45 : G window size set to 7 46 : G packet size set to 512After receiving the first packet,
^PShere=scolon^@,
the originating host replies with an outgoing message:
34 : omsg "Sjocksco -Q0 -x9"The second message packet in any transaction is:
^PShostname -Qseqnum -xdebug^@where hostname is the local hosts name, seqnum is the sequence number for this conversation, and debug is the debugging level in use.
The sequence number is stored at both sites, and is incremented each time a conversation takes place via UUCP. If they do not match up, it is likely that security has been broken (or a disk backup restored following a crash). This feature is not used by all UUCP implementations.
The third packet is an acknowledgement from the remote uucico (which sends ROK -- see below.) A number of different responses are possible at this stage; these may indicate various error conditions:
^PPgetxf^@. The ``P'' prefix
indicates that the subsequent letters are the protocols supported by
the remote system. In this case, the ``g'', ``e'',
``t'', ``x'', and ``f'' protocols are supported, in
decreasing order of preference.
The local uucico reads /usr/lib/uucp/Configuration to obtain its own protocol setup, and sends a packet in response:
38 : wmesg 'U'gto indicate the protocol (in this case, ``g'') to be used. (uucico uses the first protocol it finds listed against the appropriate system or device in Configuration that it has in common with the protocols listed in the remote uucico's protocol string.)
The protocol is then established, and the rest of the UUCP debugging
session consists of transfers.
The debugging output from the file transfer stage is heavily dependent on the protocol being used to control the transfers. See ``Defining a communications protocol'' for a brief introduction to the protocols.
At all times during a session, one uucico daemon acts as a master, issuing commands, while the other is a slave, obeying orders. Initially, the calling UUCP is master, although the roles may change during the session. If a protocol error occurs while commands are being exchanged, both uucico's switch immediately to the final handshake.
The following commands can be sent by a master:
47 : send 77 48 : pkgetpack: Connodata=1 49 : rec h->cntl 73 50 : send 61 51 : state - [INIT code a] (1) 52 : pkgetpack: Connodata=2 53 : rec h->cntl 61 54 : send 57 55 : state - [INIT code a]&[INIT code b] (3) 56 : pkgetpack: Connodata=3 57 : rec h->cntl 53 58 : state - [O.K.] (10) 59 : Proto started g 60 : *** TOP *** - role=1, setline - X 61 : gtwvec: dir /usr/spool/uucp/scolon 62 : wmesg 'H' 63 : pkwrite: icount = 64 64 : send 37777777610 65 : send 64 byte packet. 66 : rmesg - 'H' pkgetpack: Connodata=4 67 : rec h->cntl 41 68 : pkcntl: RR/RJ: Connodata=0 69 : state - [O.K.] (10) 70 : pkgetpack: Connodata=1 71 : rec h->cntl 37777777611 72 : send 41 73 : got HY 74 : PROCESS: msg - HY 75 : HUP: 76 : wmesg 'H'Y 77 : pkwrite: icount = 64 78 : send 37777777621 79 : send 64 byte packet. 80 : send 10 81 : send 10
The closing handshake is used to confirm that the UUCP session has completed successfully. The calling uucico sends a packet of six zeros, and the remote host responds with a packet of seven zeros. (Line 86 is just a series of trailing nulls appended to the final response packet.)
82 : cntrl - 0 83 : omsg "OOOOOO" 84 : send OO 0,omsg "OOOOOO" 85 : imsg >^P^I^H*"^I^P^B!l^R]HY^@omsg "OOOOOO" 86 : imsg >^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@exit code 0 87 : Conversation Complete: Status SUCCEEDED 88 : 89 : TM_cnt: 0
Different protocols produce different debugging output during the file transfer phase. The output in the preceding example uses the ``g'' protocol. The ``G'' protocol produces largely similar output, while the non-error correcting protocols (``e'', ``f'', ``x'') produce different output.
In general, the debugging output from uucico once a
protocol has been negotiated consists of a list of packets sent,
and any errors or resend attempts made. The ``g'' and
``G'' protocols are particularly verbose: the other
protocols tend to be less informative.
Advanced UUCP configuration
This section contains several options that are used only in special
circumstances and can be ignored in most cases:
Alternatively, you can set up a Configuration file for your system. This file (/usr/lib/uucp/Configuration) contains the protocol configuration information used for contacting a specific system, or for use with a given device. You can specify different protocols in order of preference, and uucico will negotiate with the daemon at the other end of the session for the first protocol they have in common. In addition, the `g' and `G' protocols have configurable options. These are discussed in detail in the Configuration(F) manual page.
Table 7-2 UUCP communications protocols
---------------------------------------------------
Protocol Description
---------------------------------------------------
g standard UUCP protocol for connection
over serial lines and modems. Uses error
correction, provides variable packet and
window size support and dynamic packet
size adjustment.
G variant on ``g'' protocol used by SVR4
systems. Provides variable packet and
window size support. (This is disabled
on some old fashioned ``g'' protocol
implementations.)
e protocol for 8-bit error-free links
(example: TCP, TLI, TLIS). No error
correction.
t protocol for 8-bit error-free links
(example: TCP, TLI, TLIS). Checks
received file size. This protocol is
provided for compatibility with BSD-
derived systems.
f protocol for 7-bit only error-free links
(for example, some X.25 PADs). Does a
checksum on the entire file.
x protocol for 8-bit X.25 error-free
links. Does not work on some X.25 packet
switched networks (see t protocol).
Creating a portable UUCP Systems file
The Dialcodes file (/usr/lib/uucp/Dialcodes) contains the
dial-code abbreviations that can be used in the ``Phone''
field of the Systems file.
This feature is intended primarily for those who wish to create a
standard Systems file for distribution among several sites
that have different phone systems and area codes. As such, the
Dialcodes file is probably not necessary for most sites.
See the
dialcodes(F)
manual page for more information, and
``How UUCP works''
for general background on how the Dialcodes file is used.
Specifying alternate UUCP configuration files
The /usr/lib/uucp/Sysfiles file lets you assign different files to be
used by uucp and cu as Systems, Devices,
and Dialers files.
This feature s useful for cases where UUCP and cu require
different dialers.
See the
sysfiles(F)
manual page for more information.
Preventing unknown sites from logging in
The script remote.unknown is executed when a site whose name
does not appear in your Systems file dials into your system.
It logs the conversation attempt and fails to make a connection.
If you wish to allow such ``unknown'' systems to log in to your
system, you can change the permissions of this file so it cannot execute
and your system accepts any communication requests. To do so, enter
the following commands while logged in as root:
cd /usr/lib/uucp
chmod 000 remote.unknown
Configuring UUCP for 7-bit systems
Most UUCP systems use 8 data bits, one stop bit, and no parity
for communicating over serial links. However, some
implementations use 7 data bits, one stop bit, and one parity
bit. Parity may be even, odd, or ignored.
To permit outgoing UUCP connections to a 7-bit system, you must modify the Systems file entry for that system. Two special keywords are recognized: PEVEN and PODD. PEVEN means even parity is to be used; PODD means odd parity is to be used. If both are specified, no parity is used. For example:
7-bit even:
remote Any ACU 2400 4253502 PEVEN -\r\d-ogin:-\K\d-ogin:-\K\d-ogin: uusys7-bit odd:
remote Any ACU 2400 4253502 PODD -\r\d-ogin:-\K\d-ogin:-\K\d-ogin: uusys7-bit none:
remote Any ACU 2400 4253502 PEVEN PODD -\r\d-ogin:-\K\d-ogin:-\K\d-ogin: uusysTo receive incoming calls from a 7-bit system, specify an appropriate /etc/gettydefs entry in the /etc/inittab entry for the modem port. As no 7-bit configurations are provided, you will need to add one. Be sure to leave blank lines above and below the new entry. For full details of a gettydefs entry, see the gettydefs(F) manual page.
The /etc/gettydefs file recognizes three special keywords:
7-bit even:
/etc/inittab
Se1A:2:respawn:/etc/getty -t60 tty1A 24E
/etc/gettydefs
24E#B2400HUPCL#B2400CS7PARENBHUPCLTAB3ECHOEIXANY#\r\n@!login:#24E
7-bit odd:
/etc/inittab
Se1A:2:respawn:/etc/getty -t60 tty1A 240
/etc/gettydefs
24O#B2400HUPCL#B2400CS7PARODDHUPCLTAB3ECHOEIXANY#\r\n@!login:#24O
7-bit none:
/etc/inittab
Se1A:2:respawn:/etc/getty -t60 tty1A 2DN
/etc/gettydefs
24N#B2400HUPCL#B2400CS7IGNPARHUPCLTAB3ECHOEIXANY#\r\n@!login:#24N
For more information about parity settings, see the
stty(C)
manual page.
Connecting two local systems using a direct wire
If you are using UUCP to connect remote machines, you can skip this section.
To connect two computers with a direct wire, you need to
choose a serial port on each machine,
connect a serial wire (RS-232) between the two machines
using the chosen serial ports,
and edit the UUCP configuration files.
Find the name of the device special file associated with the line.
The device name should have the form:
/dev/ttynn
where nn is the number of the corresponding line. For example, /dev/tty1a usually corresponds to COM1. You need the name of the actual line for later steps. Be sure and use the non-modem control port (for example, /dev/tty1a instead of /dev/tty1A).
The serial port should be owned by uucp.
To make sure the line is owned by uucp, enter this command:
chown uucp /dev/ttynn
where nn is the number of the corresponding line.
The cable should connect pins 2, 3, and 7 on one computer to the same pins on the second computer. Typically, the cable must be nulled, which means that pin 2 on one machine is connected to pin 3 on the other, and 3 to 2. Because the connections can vary, check the hardware manuals for each computer to determine the proper pin connections.
where nn is the serial port you are using.
where nn is the serial port you are using.
where nn is the port of the main machine.
Press the <Bksp> key until the lines are synchronized and you get a login prompt. To log in, you must have an account on the remote machine.
If you do not get a login prompt, read the cu -x9 output for any clues of what could be wrong. See ``Common UUCP error messages''.
If the hardware is correctly configured but a session is repeatedly failing for no known reason, the first troubleshooting step should be to run uutry and save the output log. The log (stored in /tmp/hostname, where hostname is the remote host's name) contains a listing of the steps uucico went through, and may indicate where the failure occurred.
uucico produces 11 levels of debugging output, from 0 to 10. Level 9 is the most verbose standard mode, and is generated when uucico receives the command line option -x9 (you can also pass this option to uutry when testing the uucico connection to a given site). Level 10 is identical to level 9, except that the output from the ``g'' or ``G'' protocols is written to a file in /tmp for future reference.
See also:
Checking for a faulty ACU or modem
The following are two methods for checking whether the
ACU (Automatic Call Unit) or modems are working correctly:
See also
``Troubleshooting modems'' in the SCO OpenServer Handbook.
Errors when testing the connection with cu
This section suggests hot to respond to the messages displayed when
testing the connection with the cu command fails.
If the connection fails and the system displays
the CANNOT ACCESS DEVICE message,
check the permissions on the device file.
For example, to check the device file for tty1a, enter:
l /dev/tty1a
The ownership and permissions settings should look like the following:
crw--w--w- 1 uucp uucp 5, 0 Feb 14 12:00 /dev/tty1aIf, instead, the ownership and permissions for the device file look like this:
crw------- 1 bin terminal 5, 0 Feb 14 12:00 /dev/tty1averify that the line for the port in the /etc/inittab looks similar to the following:
t1A:23:respawn:/etc/getty -t60 tty1A 3If it does not, edit /etc/inittab and /etc/conf/init.d/sio and change the lines for the appropriate port.
To make your changes to inittab effective immediately, enter:
telinit q
If the /usr/lib/uucp/Systems file on your computer does not contain an entry for the system that you are trying to access, cu displays this message.
To display a list of all the systems that
your system is connected to, enter:
uuname
The system may display this error message if you used the -l option to specify a serial port and you entered the wrong line number. Verify that the line is configured properly.
If cu
fails to connect and displays the
NO DEVICES AVAILABLE message,
check to see that the /usr/lib/uucp/Devices
file is set up correctly.
Verify that the line that corresponds to the device that you are using is uncommented. For example, the entry in Devices for a direct line using tty1a at 9600 baud looks like this:
Direct tty1a - 9600 directThere should be no leading spaces. If the Device file looks correct, the remote line may be busy. Try again later.
If cu displays the Connected
message, but not the login prompt,
the line for the remote system may be busy.
To exit cu, enter
If everything appears to be working on your system but the login prompt for the remote machine does not appear, check with the remote system administrator to verify that the getty on the remote system is set up with the same communications parameters that you are using.
If you connect to the remote system, but your
screen displays garbage, see
``Problems dialing out'' in the SCO OpenServer Handbook
for more information.
You should confirm that the communication settings on your
system match those of the remote system.
If the condition persists, the connection may be bad.
Exit cu by entering Common ``UUCP failed'' messages
Errors that UUCP displays immediately after you
enter the uucp command are generally syntax
or permissions errors, and include either of the following messages:
uucp failed completely uucp failed partiallyHere are some common problems and the error messages that the system displays:
can't read file (filename) uucp failed partiallyChange the permissions on the source file to allow all users read permissions.
usage uucp from ... to uucp failed completely
bad system name: sitename uucp failed completelyUse uuname to display a list of the sites to which your system is connected.
Use the uustat command to display the status
of the currently queued uucp requests or
display the status of connections to other systems.
For example, to display a list of all the queued jobs
for the user robertm, enter:
uustat -u robertm
The uustat utility displays user status information in the following format:
couscousN266 01/26-15:43 S couscous robertm rmail edwardaTo list the status of the accessibility of all the remote machines, use the following command:
The following example shows the output from the uustat command:
scooter 01/26-15:43 CAN'T ACCESS DEVICE disco 01/27-12:01 SUCCESSFUL obie 01/25-05:12 CALL FAILED, JOB DELETEDFor more information on the options to uustat, see the uustat(C) manual page.
The uulog command displays the status messages (most recent last) that the UUCP programs write to the files uucp/sys, uux/sys, uucico/sys, and uuxqt/sys, in the /usr/spool/uucp/.Log directory (sys is the name of the system that uucp is trying to access).
For example, to display status information about
file transfers involving the system scooter,
enter the following:
uulog -s scooter
The uulog utility displays information about the system in the following format:
uucp scooter (01/26-15:43:00, 304, 5) COPY (SUCCEEDED)
Alarms in UUCP audit output, data is not transferring
When sending data, UUCP expects a certain packet
size and checksum on the packet.
If it does not receive a full packet in a certain amount of time,
a timeout occurs, which generates an alarm.
A problem can sometimes occur once UUCP has begun sending data,
in that part way through the transfer, alarms are generated
and UUCP attempts to resend the packets. There are a couple
of possible reasons for this problem.
First, check that
mapchan(M)
is not being used on the
line that uucico is using. If it is, enter:
mapchan -n ttyxx
to turn mapping off for that port. If mapchan is not running on that port, there is probably some kind of line noise or modem problem that is corrupting the data being sent.
Alternatively, the problem may occur if you are using
UUCP with MNP 5 or some other error checking
protocol that is specific to the modems.
Error checking on a modem also sends a certain packet
size with a checksum. The problem is that the sending modem
waits to get a certain amount of data before it sends the packet,
which can cause problems with UUCP
because it is also waiting for a packet.
The solution is to not use error checking on the modem
when using UUCP (UUCP has its own error checking).
Generating log reports on usage: uulog
The uulog
program displays log information on UUCP usage according to
the remote machine. All usage of the programs uucp,
uuto, and uux
are logged in special log files, one per machine.
The uulog command has the following options:
During execution of the uulog program, the files from the following directories are examined:
The following sections suggest responses to common error messages that UUCP programs write to these files.
The uucico creates a lock file named LCK..sitename for the remote system in the /usr/spool/uucp directory. If a file for the system that you are trying to call exists, uucico assumes that the device is in use.
To use the device, enter the following command on the
remote system, substituting the name of the
remote system for sitename:
rm /usr/spool/uucp/LCK.sitename
If this error message appears, one of several things may be wrong:
If the system displays this message, one of several things may be wrong:
If the system displays this message, the /usr/lib/uucp/Systems file on the machine that you are trying to call does not contain an entry for your machine. Check the Systems file on the remote machine.
If your system displays this message, either the remote system is trying to call your system or there is a lock file for your system on the remote system.
If the /usr/lib/uucp/Systems file on your system does not contain an entry for the system that you are trying to access, this error message is displayed. Use the uuname command to verify that the system name is in the Systems file.
When UUCP requests fail, retries are not executed immediately. After an attempt to contact a remote system, a status file remains in /usr/spool/uucp/.Status/nodename (nodename is the name of the remote system that you are trying to reach). This file contains information about the last request and does not allow another request until the minimum retry period (specified in the /usr/lib/uucp/Systems file) is reached. If you try to use UUCP again, the system displays an error message like the following:
RETRY TIME NOT REACHEDTo enable another call attempt immediately, remove the status file for the remote system from the /usr/spool/uucp/.Status directory:
If the system displays this message,
it cannot access the calling device port.
Check the permissions and ownership on the device file:
l /dev/ttyxx
Where xx is the tty number. The ownership and permissions settings should look like the following:
crw-r--r-- 1 uucp uucp 5, 0 Feb 14 12:00 /dev/ttyxxSee ``Connect failed: CANNOT ACCESS DEVICE'' for information on changing the permissions.
The /usr/lib/uucp/Systems
file may restrict outgoing calls at this time.
Common UUCP error messages
This section lists the error messages associated with
UUCP. There are two types of error
messages. ASSERT errors are recorded in the
/usr/spool/uucp/.Admin/errors file. STATUS errors are
recorded in individual machine files found in the
/usr/spool/uucp/.Status directory.
Error messages are also stored in
/usr/spool/uucp/.Log/uucico/sysname.
When a process is aborted, ASSERT error messages are recorded in /usr/spool/uucp/.Admin/errors. These messages include the filename, SCCS ID, line number, and text. In most cases, these errors are the result of filesystem problems. Use errno (when present) to investigate the problem. If errno is present in a message, it is shown as ``()'' in this list.
Table 7-3 ASSERT error messages
--------------------------------------------------------------
Error message Description or action
--------------------------------------------------------------
CAN'T OPEN An open() or fopen() failed. Check for
the presence of the file and incorrect
permissions.
CAN'T WRITE A write(), fwrite(), fprint(), and so on
failed. Check for the presence of the
file and incorrect permissions.
CAN'T READ A read(), fgets(), and so on failed.
Check for the presence of the file and
incorrect permissions.
CAN'T CREATE A create() call failed. Check permissions.
CAN'T ALLOCATE A dynamic allocation failed.
CAN'T LOCK An attempt to make a LCK (lock) file
failed. In some cases, this is a fatal
error.
CAN'T STAT A stat() call failed. Check for the
presence of the file and incorrect
permissions.
CAN'T CHMOD A chmod() call failed. Check for the
presence of the file and incorrect
permissions.
CAN'T LINK A link() call failed. Check for the
presence of the file and incorrect
permissions.
CAN'T CHDIR A chdir() call failed. Check for the
presence of the file and incorrect
permissions.
CAN'T UNLINK An unlink() call failed.
WRONG ROLE This is an internal logic problem.
CAN'T MOVE TO An attempt to move some bad C. or X. files
CORRUPTDIR to the /usr/spool/uucp/.Corrupt directory
failed. The directory is probably missing
or has wrong modes or owner.
CAN'T CLOSE A close() or fclose() call failed.
FILE EXISTS The creation of a C. or D. file is
attempted, but the file exists. This
occurs when there is a problem with the
sequence file access. Usually indicates a
software error.
No uucp server A TCP/IP call is attempted, but there is
no server for UUCP.
BAD UID 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 is not attempted.
BAD LINE There is a bad line in the Devices file;
there are not enough arguments on one or
more lines.
FSTAT FAILED There is something wrong with the Ethernet
IN EWRDATA media.
SYSLST OVERFLOW An internal table in gename.c overflowed.
A big or strange request was attempted.
TOO MANY SAVED Same as previous message.
C FILES
RETURN FROM An ioctl, which should never fail, failed.
fixline ioctl There is a system driver problem.
BAD SPEED A bad line speed appears in the Devices or
Systems file (``Class'' field).
PERMISSIONS file: There is a bad line or option in the
BAD OPTION Permissions file.
PKCGET READ The remote machine probably hung up. No
action need be taken.
PKXSTART The remote machine aborted in a non-
recoverable way. This can generally be
ignored.
SYSTAT OPEN FAIL There is a problem with the modes of
/usr/lib/uucp/.Status, or there is a file
with bad modes in the directory.
TOO MANY LOCKS There is an internal problem!
XMV ERROR There is a problem with some file or
directory. It is probably the spool
directory, because the modes of the
destinations were supposed to be checked
before this process was attempted.
CAN'T FORK An attempt to fork(S) and exec(S) failed.
The current job should not be lost, but is
attempted later (uuxqt). No action need be
taken.
UUCP STATUS error messages are messages that are stored in the
/usr/spool/uucp/.Status directory. This directory
contains a separate file for each remote machine that
your system attempts to communicate with. These individual
machine files contain status information on the attempted
communication, and whether it was successful or not.
A list of the most common error messages
that can appear in these files follows.
Table 7-4 STATUS error messages
--------------------------------------------------------------
Error message Description or action
--------------------------------------------------------------
OK Self explanatory.
NO DEVICES AVAILABLE There is currently no device available
for the call. Check to see that there
is a valid device in the Devices file
for the particular system. Check the
Systems file for the device to be used
to call the system.
WRONG TIME TO CALL A call was placed to the system at a
time other than what is specified in
the Systems file.
TALKING Self explanatory.
LOGIN FAILED The login for the given machine
failed. It could be a wrong login or
password, wrong number, a very slow
machine, or failure in getting through
the dialer-token script.
CONVERSATION FAILED The conversation failed after
successful startup. This usually
means that one side went down, the
program aborted, or the line (link)
was dropped.
DIAL FAILED The remote machine never answered. It
could be a bad dialer or the wrong
phone number.
BAD LOGIN/MACHINE The machine called us with a login or
COMBINATION machine name that does not agree with
the Permissions file. This could be
an attempt to masquerade!
DEVICE LOCKED The calling device to be used is
currently locked and in use by another
process.
ASSERT ERROR An ASSERT error occurred. Check the
/usr/spool/uucp/.Admin/errors file for
the error message and refer to
``Common UUCP error messages''
SYSTEM NOT IN Systems The system is not in the Systems file.
CAN'T ACCESS DEVICE The device tried does not exist or the
modes are wrong. Check the
appropriate entries in the Systems and
Devices files.
DEVICE FAILED The opening of the device failed.
WRONG MACHINE NAME The called machine is reporting a
different name than expected.
CALLBACK REQUIRED The called machine requires that it
calls your system.
REMOTE HAS A LCK The remote site has a lock file for
FILE FOR ME your system. They could be trying to
call your machine. If they have an
older version of UUCP, the process
that was talking to your machine may
have failed leaving the lock file. If
they have the new version of UUCP and
they are not communicating with your
system, then the process that has a
lock file is hung. This can also be
caused by incorrect permissions in the
/usr/spool/uucp path on the remote
system, or cleared uucico SUID bit.
REMOTE DOES NOT The remote machine does not have the
KNOW ME node name of your system in its
Systems file.
REMOTE REJECT The login used by your system to log
AFTER LOGIN in does not agree with what the remote
machine was expecting. Check the
Permissions file on the remote system.
REMOTE REJECT, The remote machine rejected the
UNKNOWN MESSAGE communication with your system for an
unknown reason. The remote machine
may not be running a standard version
of UUCP.
STARTUP FAILED Login succeeded, but initial handshake
failed. Check communication
parameters: data word size, parity,
stop bits, and so on.
CALLER SCRIPT FAILED This is usually the same as DIAL
FAILED. However, if it occurs often,
suspect the caller script in the
Dialers file. Use uutry to check.
To check the permissions of the UUCP files, use the Software Manager or custom(ADM) as described in ``Verifying software'' in the SCO OpenServer Handbook. Select Expand Fully from the View menu and then select ``UUCP Utilities'' from the list of components. Then select Verify Software from the Software menu. This verifies the UUCP distribution files and fixes any incorrect permissions.
Use the uucheck(ADM) command to check for the presence of the required files and directories.
Verifying that your site name is unique
Make sure that the first seven characters of your
sitename name are unique.
If your machine is connected directly to a machine with the
same sitename, UUCP
does not allow communication with that machine.
If both your machine and another machine with the
same name are not directly connected, but are on the same
UUCP network, electronic mail may go to the wrong machine.
To check the sitename use the
uname(C)
command.
To change the sitename, see
``Changing the system name'' in the Mail and Messaging Guide.
UUCP truncates system names to seven characters
By default, UUCP truncates system names to seven
characters to ensure compatibility with all versions of
UUCP. Although disabling this feature is not
recommended, it can be done.
In the file /usr/lib/uucp/Permissions, add the variable MYNAME=name to each entry in this file, where name is the actual system name that contains more than seven characters. Also, add a new entry in /usr/lib/uucp/Permissions as follows:
MACHINE=OTHER \ READ=/usr/spool/uucppublic:/usr/tmp \ WRITE=/usr/spool/uucpppublic:/usr/tmp \ COMMANDS=rmail:rnews:uucp \ SENDFILES=yes REQUEST=yes \ MYNAME=namewhere name is the actual system name.
The MYNAME variable supersedes the truncated name. This procedure should be done on every machine in the UUCP network that has a name more than seven characters long.
What to check if UUCP is abnormally slow
Because UUCP is a batching network, requests are not executed immediately.
Therefore, when users report that UUCP does not work,
the problem may be that the system is slow.
If the system is slower than usual, check for the following problems:
To fix this problem, add the MACHINE entry with the name of the remote system, to Permissions. For example, if your local machine, goanna is set up to call obie, the entry for goanna in the Permissions file on obie should look like this:
LOGNAME=uugoanna MACHINE=goanna \
COMMANDS=ALL \
READ=/ \
WRITE=/ \
SENDFILES=yes REQUEST=yes
UUCP troubleshooting utilities
There are several commands you can use to check
for basic communications information.
Table 7-5 UUCP troubleshooting tools
-----------------------------------------------------------------
Command Description
-----------------------------------------------------------------
uucheck Checks for the presence of files and directories
required by uucp. This command also checks the
Permissions file for obvious errors.
uulog Displays the contents of the log directories for
specific hosts.
uuname Lists the machines that you are set up to contact.
uustat Displays the status of the currently queued uucp
requests or connections to other systems.
uutry Invokes uucico with debugging, saves the information to
the file /tmp/machine, and directs the last 10 lines of
the output to the terminal. The -x option changes the
debugging level (default is level 5).
These data files are created by UUCP processes under the
spool directory
(that is, /usr/spool/uucp/system) when a file is received from
another computer.
The system directory has the same name as the
remote computer that is sending the file.
The names of the temporary data files have the format:
TM.pid.ddd
where 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 below) that caused the transmission. If processing is abnormally terminated, the TM.pid.ddd file may remain in the system directory. These files should be automatically removed by uuclean.
Lock files are created in the /usr/spool/uucp 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 the format:
LCK..str
where str is either a device or computer name. These files may remain in the spool directory if the communications link is unexpectedly dropped (usually on computer crashes). The lock files are ignored (removed) after the parent process is no longer active. The lock file contains the process ID of the process that created the lock. The lock file is always named by converting the last letter to lowercase (meaning non-modem control) to avoid possible conflicts if the same line is specified both as modem-control and non-modem-control. For example, the lock on /dev/tty1A is named LCK..tty1a.
Work files are created in a spool directory on the local computer when
work (file transfer or remote command execution) is
queued for a remote computer.
The names of work files have the format:
C.sysnxxxx
where 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:
Data files are created in the spool directory on both
the local and remote computers when it is specified in the
command line to copy the source file to the spool directory.
The names of data files have the following format:
D.systmxxxxyyy
where systm is the first five characters in the name of the remote computer, 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 which is used when there are several D. files created for a work (C.) file.
Execute files are created in the spool directory on the remote computer
prior to remote command executions.
The names of execute files have the following format:
X.sysnxxxx
where 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: