![[Previous Section]](b_prev.gif){kind=small}
![[Back to Table of Contents]](b_toc.gif){kind=small}
![[Next Section]](b_next.gif){kind=small}
IRIX Advanced Site and Server Administration Guide |
UUCP stands for ``UNIX to UNIX copy program,'' and 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:
How to decide which networking software to use. See "Choosing
TCP/IP or UUCP".
What hardware is necessary to use UUCP. See "Networking
Hardware".
A list of UUCP commands. See "UUCP
Commands".
A list of UUCP daemons. See "UUCP
Daemons".
The UUCP supporting database. See "Supporting
Databases".
A list of UUCP administrative files. See "UUCP
Administrative Files".
Directions for setting up UUCP. See "Setting
Up UUCP".
Directions for setting up UUCP over a TCP/IP network connection. See
"Setting
up UUCP on a TCP/IP Connection".
A list of UUCP Error Messages. See "UUCP Error Messages".
The UUCP system is contained in the eoe2 subsystem of your IRIX distribution, in the package called eoe2.sw.uucp. Use the versions(1M) 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 both 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 issue 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 21-1 shows a comparison of features of TCP/IP and UUCP.
| TCP/IP Features | UUCP Features |
|---|---|
| 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 will need depend on how you want to connect the computers: direct links, telephone lines, or local area networks.
Note: Refer to Chapter 10, "Terminals and Modems," and the Personal System Administration Guide for information on setting up modems and other hardware.
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 online reference pages.
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 gets uucico as its shell.
The following programs are the administrative utilities of UUCP:
There are several daemons in UUCP. These daemons handle file transfers and command executions. They can also be run manually from the shell.
The following three programs are also used:
The UUCP support files are in the /etc/uucp directory.
The subsections that follow provide details on the structure of these files so you can edit them.
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 station name.
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. Since non-801 dialers do not normally use this configuration, the Line2 field is ignored by them, 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 only have one pair. This pair would normally be 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 "The Systems File".)
Two escape characters can appear in a DTP field:
You can define the protocol to use with each device. In most cases it is not needed since 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:
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.
The following list describes some of the escape characters used in the Dialers file. A sequence beginning with a backslash (\) is an escape sequence.
Additional escape characters that can be used are listed in "The Systems File".
The penril entry in the Dialers file is executed as follows. First, 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:
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 will be tried in sequential order.
Using the Sysfiles file, you can define several files to be used as Systems files. See "The 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 contains the node name of the remote computer.
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:
DayTime[;retry]
The Day portion may be a list containing some of the following options, possibly compounded with comma delimiters:
Su Mo Tu We Th Fr Sa
for individual days;
Wk
for any weekday (Mo Tu We Th Fr);
Any
for any day; and
Never
for a passive arrangement with 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 "The Permissions File".)
Here is an example:
Wk1700-0800,Sa,Su
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 08001230. 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 "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 "The 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 the format:
expect send
The expect string is received and the send string is sent when the expect string is received.
The expect field may be made up of subfields of the form:
expect[-send-expect]...
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 login. If UUCP gets login, it goes on to the next field. If it does not get login, 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 "send a carriage return and wait for ogin: (for Login:). If you do not get ogin:, send a <BREAK>. When you do get ogin:, send the login name uucpx; then, when you see word:(the last part of Password:), send the password xyzzy."
Several escape sequences cause specific actions when they are a part of a string sent during the login sequence. The following escape sequences are useful in UUCP communications:
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 dial-seq
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:
jt 9=555-
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.
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:
name=value
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:
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/restrictions:
Local send and receive requests will be executed.
The remote computer will be able to 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.
REQUEST=yes
REQUEST=no
SENDFILES=yes
SENDFILES=call
READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic
READ=/ WRITE=/
WRITE=/var/spool/uucppublic:/usr/news
READ=/ NOR EAD=/etc WRITE=/var/spool/uucppublic
CALLBACK=yes
CALLBACK=no
COMMANDS=rmail
MACHINE=eagle:owl:hawk REQUEST=yes COMMANDS=rmail:/usr/bin/rnews READ=/ WRITE=/
COMMANDS=rmail:/usr/bin/rnews:/usr/local/lp
Note: Including the ALL value in the list means that any command from the remote computer(s) specified in the entry will be executed. If you use this value, you give the remote computer full access to your computer. Be careful. This value allows far more access than normal users have.
COMMANDS=/usr/bin/rnews:ALL:/usr/local/lp
LOGNAME=uucpfriend VALIDATE=eagle:owl:hawk
MACHINE=eagle:owl:hawk REQUEST=yes \
COMMANDS=rmail:/usr/bin/rnews \ READ=/ WRITE=/ LOGNAME=uucpz VALIDATE=eagle:owl:hawk \ REQUEST=yes SENDFILES=yes \ READ=/ WRITE=/
MACHINE=OTHER \ COMMANDS=rmail:rnews:/usr/bin/Photo:/usr/bin/xp
MACHINE=eagle:owl:hawk REQUEST=yes \ READ=/ WRITE=/ LOGNAME=uucpz REQUEST=yes SENDFILES=yes \ READ=/ WRITE=/
MACHINE=eagle:owl:hawk REQUEST=yes \ LOGNAME=uucpz SENDFILES=yes \ READ=/ WRITE=/
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 requests for login
services can be made to different phone numbers than 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 file name 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:
service=uucico:cu systems=Systems:Local_Systems
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).
The UUCP administrative files are created in spool directories to lock devices, hold temporary data, or keep information about remote transfers or executions.
TM.pid.ddd
LCK..str
C.sysnxxxx
Full pathname of the file to be sent or requested.
Full pathname of the destination or user or file name.
User login name.
List of options.
Name of associated data file in the spool directory. If the uucp
-c or uuto -p option was specified, a dummy name (D.0)
is used.
Mode bits of the source file.
Login name of the remote user to be notified upon completion of the transfer.
D.systmxxxxyyy
X.sysnxxxx
Requester's login and computer name.
Name of file(s) required for execution.
Input to be used as the standard input to the command string.
Computer and file name to receive standard output from the command execution.
Command string.
Option lines for return status requests.
Setting up UUCP involves five steps:
Determining the remote and local stations.
Making the physical connection
Configuring the local (calling) station
Configuring the remote (called) station
Testing the UUCP 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.
For our example, japan is the local station and us is the remote station.
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 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 21-2.
| IRIS A | IRIS B |
|---|---|
| 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: The preferred cable for use with the serial ports on your system connects more pins than the minimum configuration. This cable is available from Silicon Graphics. Contact your sales representative or SGI Express. This cable can be used with a null modem adapter. The commercially available MAC SE to modem cable (``off the shelf ''') will not work properly with SGI software.
The preferred serial cable pinning configuration for both Mini-DIN8 and DB25 serial ports is described in Table 21-3:
| Function | Mini-DIN8-Male | DB25-Male |
|---|---|---|
| DTR | 1 | 9 |
| CTS | 2 | 5 |
| TXD | 3 | 2 |
| GND | 4 | 7 |
| RXD | 5 | 3 |
| RTS | 6 | 4 |
| DCD | 7 | 8 |
| GND | 8 | 7 |
Note: All pins not shown are no connects (nc). For additional information see the serial(7) reference page.
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:
Updating standard system files
Modifying the UUCP configuration files
The three system files that you need to be concerned with are:
/etc/passwd
/etc/group
/etc/inittab
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 will have a password. It is a good idea to put a ``*'' in the password field for uucp, since 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 "The 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.
uucp::5:uucp nuucp::10:nuucp
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, anytime you make a change to the /etc/inittab, you must tell init to read the file again with the telinit q command. Issue the following command:
/etc/telinit q
The UUCP configuration files to be modified are:
/etc/uucp/Systems
/etc/uucp/Devices
/etc/uucp/Dialers
/etc/uucp/Permissions
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: As the Systems file is read-only, if using vi you will have to 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 forth field specifies the transfer speed (9600). The fifth field is normally used for a phone number, 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. Since 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. Type 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 "The Permissions File" for descriptions on all 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 expands more than one physical line.
This entry specifies that the user, nuucp, is allowed to login 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 request. 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:
Updating standard system files
Modifying the UUCP configuration files
The three system files that you need to be concerned with are:
/etc/passwd
/etc/group
/etc/inittab
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 a "* "in the password field for uucp, since 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 "The Systems File". Assign nuucp the password "secret" with the command:
passwd nuucp 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.
uucp::5:uucp nuucp::10:nuucp
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, anytime you make a change to the /etc/inittab, you must tell init to read the file again with the telinit q command. Issue the following command:
/etc/telinit q
The UUCP configuration files to be modified are:
/etc/uucp/Systems
/etc/uucp/Permissions
The Systems file contains information describing the station(s) the remote station knows about. Give the following commands and add the given line to the bottom of the file.
cd /etc/uucp
vi Systems
Add the line:
japan Never
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 make the call. Since japan is a remote station which always receives calls and never calls out, Never indicates that the other station always calls this station.
The Permissions file controls remote uucp access with regard to remote users and stations. See "The Permissions File" for descriptions on all 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 login 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.
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 the commands:
/etc/init.d/network stop /etc/init.d/network start
to make the change take effect.
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.
Then, give the command:
/usr/lib/uucp/uucheck -v
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(1C) 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 with Uutry".
There are two basic tools for testing a UUCP connection:
The cu program
The Uutry program
The cu program is used to test 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 following 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 executed from the local (calling) station. Execute the cu command from the local station (japan) as follows:
/usr/bin/cu -d us
You get 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[0]=`177',[1]=`34',[2]=`10',[3]=`25',[4]=`1',[5]=`0',[6]=`0',[7]=`0', call _mode(1) Connected _receive started transmit started
There is a pause at this point. Follow these steps now:
Press <Return> now.
You should see a login prompt.
Log in as nuucp and supply the password for nuucp. (In this case, the password is secret).
Now, uucico starts up on the remote station and displays the following prompts. (Your expected input is in bold:
Break your connection with a tilde(~) dot(.) and a carriage return (<CR>). us login: nuucp Password: secret IRIX System V Release 3.3.2 us Copyright (c) 1988,1989,1990 Silicon Graphics, Inc. All Rights Reserved. here=japan~[us]. call tilda(.) call _quit(0) call _bye(0) Disconnected call cleanup(0) call _mode(0)
Uutry is the program that tests the copy-in/copy-out program (uucico). uucico must be functioning properly before you can actually transfer data. Issue the Uutry command from the local station (japan) to the remote station (us):
/usr/lib/uucp/Uutry 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.
This section describes common error messages associated with the UUCP environment. UUCP error messages can be divided into two categories: ASSERT Error Messages and STATUS Error Messages.
When a process is aborted, the station records ASSERT error messages in /var/spool/uucp/.Admin/errors. These messages include the file name, sccsid, line number, and the text listed in Table 21-4. In most cases, these errors are the result of file system problems.
| Error Message | Description/Action |
|---|---|
| CAN'T OPEN | An open() or fopen() failed. |
| CAN'T WRITE | A write(), fwrite(), fprint(), or other call failed. |
| CAN'T READ | A read(), fgets(), or other call failed. |
| CAN'T CREATE | A create() call failed. |
| CAN'T ALLOCATE | A dynamic allocation failed. |
| CAN'T LOCK | An attempt to make an LCK (lock) file failed. In some cases, this is a fatal error. |
| CAN'T STAT | A stat() call failed. |
| CAN'T CHMOD | A chmod() call failed. |
| CAN'T LINK | A link() call failed. |
| CAN'T CHDIR | A chdir() call failed. |
| CAN'T UNLINK | An unlink() call failed. |
| WRONG ROLE | 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. |
| CAN'T CLOSE | A close() or fclose() call failed. |
| FILE EXISTS | 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. |
| BAD UID | The uid cannot be found in the /etc/passwd file. The file system is in trouble, or the / etc/passwd file is inconsistent. |
| BAD LOGIN_UID | The uid cannot be found in the /etc/passwd file. The file system 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. |
| BAD LINE | 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. |
| SYSLST OVERFLOW | 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. |
| BAD SPEED | A bad line-speed appears in the Devices/ Systems files (Class field). |
| PKCGET READ | The remote station probably hung up. No action is required. |
| PKXSTART | The remote station aborted in a nonrecoverable way. This message can generally be ignored. |
| SYSTAT OPENFAIL | 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. |
| XMV ERROR | There is a problem with some file or directory. The problem is likely caused by the spool directory, since the modes of the destinations should have been checked before this process was attempted. |
| CAN'T FORK | 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 21-5 lists the most common error messages that can appear in these files.
| Error Message | Description/Action |
|---|---|
| OK | 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. |
| TALKING | Self-explanatory. |
| LOGIN FAILED | 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. |
| CONVERSATION FAILED | The conversation failed after successful startup. This situation usually means that one side went down, the program aborted, or the line (link) was dropped. |
| DIAL FAILED | 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. |
| 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 / 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. |
| DEVICE FAILED | The attempt to open the device failed. |
| WRONG MACHINE NAME | The called station is reporting a different name than expected. |
| CALLBACK REQUIRED | 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. |
| STARTUP FAILED | 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. |
|
|
Copyright © 1997, Silicon Graphics, Inc. All Rights Reserved. Trademark Information