Part III Administering UUCP Communications

The UUCP file transfer system enables you to send files and electronic mail from one UNIX-based system to another. This part explains how to administer the complex UUCP system.

The materials in this part assume that you are a very experienced network administrator with some practical knowledge of modem administration and wide-area networks. The text assumes that if you are going to use UUCP over a telephone line, you are familiar with the procedures for adding hardware to your computer, have already connected modems to your machines, and are able to use tip or cu to dial out.

• "UUCP Software"

• "Introducing the UUCP Database Files"

• "Running UUCP Over TCP/IP"

• "UUCP Error Messages"

Chapter 12 UUCP Databases and Programs

This chapter introduces the UUCP programs and daemons. It then provides complete information for setting up the UUCP database files as part of UUCP configuration. Chapter 13, Configuring and Maintaining UUCP explains how to configure UUCP after the databases have been created.

• "UUCP Hardware Configurations"

• "UUCP Software"

• "Introducing the UUCP Database Files"

• "/etc/uucp/Systems File"

• "/etc/uucp/Devices File"

• "/etc/uucp/Dialers File"

• "Other Basic Configuration Files"

• "/etc/uucp/Permissions File"

The UNIX-to-UNIX Copy Program (UUCP) enables computers to transfer files and exchange mail with each other. It also enables computers to participate in large networks such as Usenet.

The Solaris environment provides the Basic Network Utilities (BNU) version of UUCP, also known as HoneyDanBer UUCP. The term UUCP denotes the complete range of files and utilities that make up the system, of which the program uucp is only a part. The UUCP utilities range from those used to copy files between computers (uucp and uuto) to those used for remote login and command execution (cu and uux).

UUCP Hardware Configurations

UUCP supports the following hardware configurations:

• Direct links - You can create a direct link to another computer by running RS-232 cables between serial ports on the two machines. Direct links are useful where two computers communicate regularly and are physically close--within 50 feet of each other. You can use a limited distance-modem to increase this distance somewhat.

• Telephone lines - Using an automatic call unit (ACU), such as a high-speed modem, your machine can communicate with other computers over standard phone lines. The modem dials the telephone number requested by UUCP. The recipient machine must have a modem capable of answering incoming calls.

• Network - UUCP can also communicate over a network running TCP/IP or other protocol family. After your computer has been established as a host on a network, it can contact any other host connected to the network.

This chapter assumes that your UUCP hardware has already been assembled and configured. If you need to set up a modem, refer to System Administration Guide, Volume I and the manuals that came with the modem for assistance.

UUCP Software

The UUCP software is automatically included when you run the Solaris installation program and select the entire distribution. Alternatively, you can add it using pkgadd. The UUCP programs can be divided into three categories: daemons, administrative programs, and user programs.

Daemons

The UUCP system has four daemons: uucico, uuxqt, uusched and in.uucpd. These daemons handle UUCP file transfers and command executions. You can also run them manually from the shell, if necessary.

• uucico - Selects the device used for the link, establishes the link to the remote computer, performs the required login sequence and permission checks, transfers data and execute files, logs results, and notifies the user by mail of transfer completions. uucico acts as the "login shell" for UUCP login accounts. When the local uucico daemon calls a remote machine, it communicates directly with the remote uucico daemon during the session.

  uucp, uuto, and uux programs execute the uucico daemon after all the required files have been created, to contact the remote computer. uusched and Uutry all execute uucico. (See the uucico(1M) man page for details.)

• uuxqt - Executes remote execution requests. It searches the spool directory for execute files (always named X.file) that have been sent from a remote computer. When an X.file file is found, uuxqt opens it to get the list of data files that are required for the execution. It then checks to see if the required data files are available and accessible. If the files are available, uuxqt checks the Permissions file to verify that it has permission to execute the requested command. The uuxqt daemon is executed by the uudemon.hour shell script, which is started by cron. (See the uuxqt(1M) man page for details.)

• uusched - Schedules the queued work in the spool directory. uusched is initially run at boot time by the uudemon.hour shell script, which is started by cron. (See the uusched(1M) man page for details.) Before starting the uucico daemon, uusched randomizes the order in which remote computers are called.

• in.uucpd - Supports UUCP connections over networks. The inetd on the remote host invokes in.uucpd whenever a UUCP connection is established. uucpd then prompts for a login name. uucico on the calling host must respond with a login name. in.uucpd then prompts for a password, unless one is not required. (See the in.uucpd(1M) man page for details.)

Administrative Programs

Most UUCP administrative programs are in /usr/lib/uucp. Most basic database files are in /etc/uucp. The only exception is uulog, which is in /usr/bin. The home directory of the uucp login ID is /usr/lib/uucp. When running the administrative programs through su or login, use the uucp user ID. It owns the programs and spooled data files.

• uulog - Displays the contents of a specified computer's log files. Log files are created for each remote computer with which your machine communicates. The log files record each use of uucp, uuto, and uux. (See the uucp(1C) man page for details.)

• uucleanup - Cleans up the spool directory. It is normally executed from the uudemon.cleanup shell script, which is started by cron. (See the uucleanup(1M) man page for details.)

• Uutry - Tests call-processing capabilities and does moderate debugging. It invokes the uucico daemon to establish a communication link between your machine and the remote computer you specify. (See the Uutry(1M) man page for details.)

• uucheck - Checks for the presence of UUCP directories, programs, and support files. It can also check certain parts of the /etc/uucp/Permissions file for obvious syntactic errors. (See the uucheck(1M) man page for details.)

User Programs

The UUCP user programs are in /usr/bin. You do not need special permission to use these programs.

• cu - Connects your machine to a remote computer so that you can log in to both at the same time. cu enables you to transfer files or execute commands on either machine without dropping the initial link. (See the cu(1C) man page for details.)

• uucp - Lets you copy a file from one machine to another. It creates work files and data files, queues the job for transfer, and calls the uucico daemon, which in turn attempts to contact the remote computer. (See the uucp(1C) man page for details.)

• uuto - Copies files from the local machine to the public spool directory /var/spool/uucppublic/receive on the remote machine. Unlike uucp, which lets you copy a file to any accessible directory on the remote machine, uuto places the file in an appropriate spool directory and tells the remote user to pick it up with uupick. (See the uuto(1C) man page for details.)

• uupick - Retrieves files in /var/spool/uucppublic/receive when files are transferred to a computer using uuto. (See the uuto(1C) man page.)

• uux - Creates the work, data, and execute files needed to execute commands on a remote machine. (See the uux(1C) man page for details.)

• uustat - Displays the status of requested transfers (uucp, uuto, or uux). It also provides a means of controlling queued transfers. (See the uustat(1C) man page for details.)

Introducing the UUCP Database Files

A major part of UUCP setup is the configuration of the files making up the UUCP database. These files are in the /etc/uucp directory. You need to edit them to set up UUCP or PPP on your machine. The files include:

• Config - Contains a list of variable parameters. You can manually set these parameters to configure the network.

• Devconfig - Used to configure network communications.

• Devices - Contains information concerning the location and line speed of automatic call unit (modem), direct links, and network devices. It is used by PPP as well as UUCP.

• Dialers - Contains character strings required to negotiate with modems to establish connections with remote computers. It is used by PPP as well as UUCP.

• Dialcodes - Contains dial-code abbreviations that can be used in the phone number field of Systems file entries. Though not required, it can be used by PPP as well as UUCP.

• Grades - Defines job grades, and the permissions associated with each job grade, that users can specify to queue jobs to a remote computer.

• Limits - Defines the maximum number of simultaneous uucicos, uuxqts, and uuscheds permitted on your machine.

• Permissions - Defines the level of access granted to remote hosts that attempt to transfer files or execute commands on your machine.

• Poll - Defines machines that are to be polled by your system and when they are polled.

• Sysfiles - Assigns different or multiple files to be used by uucico and cu as Systems, Devices, and Dialers files.

• Sysname - Enables you to define a unique UUCP name for a machine in addition to its TCP/IP host name.

• Systems - Contains information needed by the uucico daemon, cu, and PPP to establish a link to a remote computer. This information includes the name of the remote host, the name of the connecting device associated with the remote host, time when the host can be reached, telephone number, login ID, and password.

Several other files can be considered part of the supporting database but are not directly involved in establishing a link and transferring files.

Configuring UUCP Files

The UUCP database consists of the files shown in "Introducing the UUCP Database Files". However, basic UUCP configuration involves only the following critical files:

• /etc/uucp/Systems

• /etc/uucp/Devices

• /etc/uucp/Dialers

Because PPP uses some of the UUCP databases, you should understand at least these critical database files if you plan to configure PPP. After these databases are configured, UUCP administration is fairly straightforward. Typically, you edit the Systems file first, then edit the Devices file. You can usually use the default /etc/uucp/Dialers file, unless you plan to add dialers that aren't in the default file. In addition, you might also want to use the following files for basic UUCP and PPP configuration:

• /etc/uucp/Sysfiles

• /etc/uucp/Dialcodes

• /etc/uucp/Sysname

Because these files work closely with one another, you should understand the contents of them all before you change any one of them. A change to an entry in one file might require a change to a related entry in another file. The remaining files listed in "Introducing the UUCP Database Files" are not as critically intertwined.

PPP uses only the files described in this section. It does not use the other UUCP database files.

The rest of this chapter explains the UUCP databases in detail.

/etc/uucp/Systems File

The /etc/uucp/Systems file contains the information needed by the uucico daemon to establish a communication link to a remote computer. It is the first file you need to edit to configure UUCP.

Each entry in the Systems file represents a remote computer with which your host communicates. A particular host can have more than one entry. The additional entries represent alternative communication paths that are tried in sequential order. In addition, by default UUCP prevents any computer that does not appear in /etc/uucp/Systems from logging in to your host.

Using the Sysfiles file, you can define several files to be used as Systems files. See the description of the Sysfiles file for details.

Each entry in the Systems file has the following format:

System-Name

 Time

 Type 

Speed 

Phone  

Chat-Script 

Example 12-1 shows the fields of the Systems file.

Example 12-1 Fields in /etc/uucp/Systems

System-Name Time Type  Speed Phone   Chat-Script
Arabian     Any  ACUEC 38400 111222  Login: Puucp ssword:beledi  

System-Name Field

This field contains the node name of the remote computer. On TCP/IP networks, this can be the machine's host name or a name created specifically for UUCP communications through the /etc/uucp/Sysname file. See "/etc/uucp/Sysname File". In Example 12-1, the System-Name field contains an entry for remote host arabian.

Time Field

This field specifies 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 can be a list containing some of the following entries:

Example 12-1 shows Any in the Time field, indicating that host arabian can be called at any time.

The time portion should be a range of times specified in 24-hour notation. (Example: 0800-1230 for 8:30 a.m. to 12:30 p.m.) 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 times between 6 a.m. and 8 a.m.

Retry Subfield

The Retry subfield enables you to specify the minimum time (in minutes) before a retry, following a failed attempt. The default wait is 60 minutes. 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.

If you do not specify a retry entry, an exponential back-off algorithm is used. What this means is that UUCP starts with a default wait time that grows larger as the number of failed attempts increases. For example, suppose the initial retry time is 5 minutes. If there is no response, the next retry is 10 minutes later. The next retry is 20 minutes later, and so on until the maximum retry time of 23 hours is reached. If retry is specified, that is always the retry time. Otherwise, the back-off algorithm is used.

Type Field

This field contains the device type that should be used to establish the communication link to the remote computer. The keyword used in this field is matched against the first field of Devices file entries as shown in Example 12-2. (Note that the fields listed in the table heading are for the Systems file and do not apply to the Devices file. For a table showing the same correspondences to fields in the Devices file, see Example 12-6.)

Example 12-2 Type Field and /etc/uucp/Devices File

File Name System-Name  Time  Type     Speed  Phone     Chap-Script
 
Systems   arabian      Any   ACUEC, g 38400  1112222   ogin: Puucp ssword:beledi
 
Device    ACUEC        cua/a -        38400  usrv32bis-ec

You can define the protocol used to contact the system by adding it on to the Type field. The example above shows how to attach the protocol g to the device type ACUEC. (For information on protocols, see "Protocol Definitions in the Devices File".)

Speed Field

This field (also known as the Class field) specifies the transfer speed of the device used in establishing the communication link. It can contain a letter and speed (for example, C1200, D1200) to differentiate between classes of dialers (refer to "Class Field").

Some devices can be used at any speed, so the keyword Any can be used. This field must match the Class field in the associated Devices file entry as shown in Example 12-3:

Example 12-3 Speed Field and /etc/uucp/Devices File

File Name System-Name Time  Type    Speed  Phone   Chap-Script
 
Systems   eagle       Any   ACU, g  D1200  NY3251  ogin: nuucp ssword: Oakgrass
 
Device    ACU         tty11 --      D1200  penril

If information is not required for this field, use a dash (-) as a place holder for the field.

Phone Field

This field allows you to specify the telephone number (token) of the remote computer for automatic dialers (port selectors). The telephone number consists 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, as shown in Example 12-4:

Example 12-4 Phone Field Correspondence

File Name System-Name  Time  Type  Speed  Phone     Chap-Script
 
Systems   nubian       Any   ACU   2400   NY5551212 ogin: Puucp ssword:Passuan
 
Dialcodes NY 1-1212

In the System-Name string, an equals 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 four seconds before dialing the next digit.

If your computer is connected to a port selector, you can access other computers connected to that selector. The Systems file entries for these remote machines should not have a telephone number in the Phone field. Instead, this field should contain the token to be passed on to the switch. In this way, the port selector knows the remote machine with which your host wants to communicate. (This is usually just the system name.) The associated Devices file entry should have a \D at the end of the entry to ensure that this field is not translated using the Dialcodes file.

Chat-Script Field

This field (also called the Login field) contains a string of characters called a chat-script. The chat-script contains the characters the local and remote machines must pass to each other in their initial conversation. Chat-scripts have the format:

expect send [expect send] ....

expect represents the string that the local host expects to get from the remote host to initiate conversation. send is the string the local host sends after it receives the expect string from the remote host. A chat-script can have more than one expect-send sequence.

A basic chat-script might contain:

• Login prompt that the local host expects to get from the remote machine

• Login name that the local host sends to the remote machine in order to log in

• Password prompt that the local host expects to get from the remote machine

• Password that the local host sends to the remote machine

The expect field can be made up of subfields of the form:

expect[-send-expect]...

where -send is sent if the prior expect is not successfully read, and -expect following the send is the next expected string.

For example, with strings login--login, the UUCP on the local host expects login. If UUCP gets login from the remote machine, it goes to the next field. If it does not get login, it sends a carriage return, then looks for login again. If the local computer initially does not expect any characters, use the characters "" (NULL string) in the expect field. All send fields are sent followed by a carriage-return unless the send string is terminated with a \c.

Here is an example of a Systems file entry that uses an expect-send string:

sonora Any ACUEC 9600 2223333 "" \r \r ogin:-BREAK-ogin: Puucpx ssword: xyzzy

This example tells UUCP on the local host to send two carriage-returns and wait for ogin: (for Login:). If ogin: is not received, send a BREAK. When you do get ogin: send the login name Puucpx. When you get ssword: (for Password:), send the password xyzzy.

Table 12-2 lists some useful escape characters.

Enabling Dialback Through the Chat-Script

Some companies set up dial-in servers to handle calls from remote computers. For example, your company might have a dial-in server with a dialback modem that employees can call from their home computers. After the dial-in server identifies the remote machine, it disconnects the link to the remote machine and then calls the remote machine back. The communications link is then reestablished.

You can facilitate dialback by using the \H option in the Systems file chat-script at the place where dialback should occur. Include the \H as part of an expect string at the place where the dial-in server is expected to hang up.

For example, suppose the chat-script that calls a dial-in server contains the following string:

INITIATED\Hogin:

The UUCP dialing facility on the local machine expects to get the characters INITIATED from the dial-in server. After the INITIATED characters have been matched, the dialing facility flushes any subsequent characters it receives until the dial-in server hangs up. The local dialing facility then waits until it receives the next part of the expect string, the characters ogin:, from the dial-in server. When it receives the ogin:, the dialing facility then continues through the chat-script.

You need not have a string of characters directly preceding or following the \H, as shown in the sample string above.

Hardware Flow Control

You can also use the pseudo-send STTY=value string to set modem characteristics. For instance, STTY=crtscts enables hardware flow control. STTY accepts all stty modes. See the stty(1) and termio(7I) man pages for complete details.

The following example would enable hardware flow control in a Systems file entry:

unix Any ACU 2400 12015551212 "" \r login:-\r-login:-\r-login: 
nuucp password: xxx "" \ STTY=crtscts 

This pseudo-send string can also be used in entries in the Dialers file.

Setting Parity

In some cases, you have to reset the parity because the system that you are calling checks port parity and drops the line if it is wrong. The expect-send couplet "" P_ZERO sets the high-order bit (parity bit) to 0. For example:

unix Any ACU 2400 12015551212 "" P_ZERO "" \r login:-\r-login:-\r-login: 
nuucp password: xxx 

In the same manner, P_EVEN sets parity to even (the default), P_ODD sets odd parity, and P_ONE sets the parity bit to 1.

The parity couplet can be inserted anywhere in the chat-script. It applies to all information in the chat-script following the "" P_ZERO. It can also be used in entries in the Dialers file.

/etc/uucp/Devices File

The /etc/uucp/Devices file contains information for all the devices that can be used to establish a link to a remote computer. These devices include ACUs--which includes modern, high-speed modems--direct links, and network connections.

Each entry in the Devices file has the following format:

Here is an entry in /etc/uucp/Devices for a US Robotics V.32bis modem attached to port A and running at 38,400 bps.

ACUEC cua/a - 38400 usrv32bis-ec

Each field is described below.

Type Field

This field describes the type of link that the device establishes. It can contain one of the keywords described in the sections that follow:

Direct Keyword

The Direct keyword appears mainly in entries for cu connections. This keyword indicates that the link is a direct link to another computer or a port selector. Make a separate entry for each line that you want to reference through the -l option of cu.

ACU Keyword

The ACU keyword indicates that the link to a remote computer (whether through cu, UUCP, or PPP) is made through a modem. This modem can be connected either directly to your computer or indirectly through a port selector.

Port Selector

This is a variable that is replaced in the Type field by the name of a port selector. Port selectors are devices attached to a network that prompt for the name of a calling modem, then grant access. The file /etc/uucp/Dialers contains caller scripts only for the micom and develcon port selectors. You can add your own port selector entries to the Dialers file. (See "/etc/uucp/Dialers File" for more information.)

Sys-Name

This variable is replaced by the name of a machine in the Type field, indicating that the link is a direct link to this particular computer. This naming scheme is used to associate the line in this Devices entry to an entry in /etc/uucp/Systems for the computer Sys-Name.

Type Field and /etc/uucp/Systems File

Example 12-5 shows a comparison between the fields in /etc/uucp/Devices and fields in /etc/uucp/Systems. The titles of each column apply only to fields in the Devices file.

The keyword used in the Type field of the Devices file is matched against the third field of the Systems file entries, as indicated in Example 12-5. In the Devices file, the Type field has the entry ACUEC, indicating an automatic call unit, in this case a V.32bis modem. This value is matched against the third field in the Systems file, which also contains the entry ACUEC. (See "/etc/uucp/Systems File" for more information.)

Example 12-5 Type Field and /etc/uucp/Systems File Equivalent

File Name Type   Line  Line2 Class Dialer-Token-Pairs
 
Devices   ACUEC  cua/a -     38400 usrv32bis-ec
 
System    nubian Any   ACUEC 38400 9998888 "" \d\d\r\n\c-ogin-\r\n\c-ogin.......      
 

Line Field

This field contains the device name of the line (port) associated with the Devices entry. For instance, if the modem associated with a particular entry were attached to the /dev/cua/a device (serial port A), the name entered in this field would be cua/a. There is an optional modem control flag, M, that can be used in the Line field to indicate that the device should be opened without waiting for a carrier. For example:

cua/a,M

Line2 Field

This field is a placeholder. Always use a dash (-) here. 801 type dialers, which are not supported in the Solaris environment, use the Line2 field. Non-801 dialers do not normally use this configuration, but still require a hyphen in this field.

Class Field

The Class field contains the speed of the device, if the keyword ACU or Direct is used in the Type field. However, it 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 can have more than one type of telephone network: one network might be dedicated to serving only internal office communications while another handles the external communications. In such a case, it becomes necessary to distinguish which line(s) should be used for internal communications and which should be used for external communications.

The keyword used in the Class field of the Devices file is matched against the Speed field of Systems file as shown in Example 12-6. Note that the titles of each column apply only to fields in the Devices file.

Example 12-6 Class Field and /etc/uucp/Systems Correspondence

File Name  Type   Line  Line2  Class  Dialer-Token-Pairs
 
Devices    ACU    cua/a -      D2400  hayes
 
System     gobi   Any   ACUEC  D2400  3251 ogin: nuucp ssword: taheya
 

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 matches any speed requested in the Speed field of the Systems file. If this field is Any and the Systems file Speed field is Any, the speed defaults to 2400 bps.

Dialer-Token-Pairs Field

The Dialer-Token-Pairs (DTP) field contains the name of a dialer and the token to pass it. The DTP field has this syntax:

dialer token [dialer token]

The dialer portion can be the name of a modem, a port monitor, or it can be direct or uudirect for a direct-link device. You can have any number of dialer-token pairs; if not present, it is taken from a related entry in the Systems file. The token portion can be supplied immediately following the dialer portion.

The last dialer token pair might not be present, depending on the associated dialer. In most cases, the last pair contains only a dialer portion. The token portion is retrieved from the Phone field of the associated Systems file entry.

A valid entry in the dialer portion can be defined in the Dialers file or can be one of several special dialer types. These special dialer types are compiled into the software and are therefore available without having entries in the Dialers file. Table 12-3 shows the special dialer types which include:

See "Protocol Definitions in the Devices File" for more information.

Structure of the Dialer-Token-Pairs Field

The DTP field can be structured four different ways, depending on the device associated with the entry:

• Directly connected modem

  If a modem is connected directly to a port on your computer, the DTP field of the associated Devices file entry has only 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 as shown in Example 12-7. (The titles of each column apply only to fields in the Devices file.)

Example 12-7 Dialers Field and /etc/uucp/Dialers Correspondence

File Name Type  Line  Line2 Class Dialer-Token-Pairs
 
Devices   ACU   cua/b -     2400  hayes
 
Dialers   hayes =,-,  ""          \\dA\pTE1V1X1Q0S2=255S12=255\r\c 
                                  \EATDT\T\r\c CONNECT

Notice that only the dialer portion (hayes) 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, as described in Example 12-9.)

• Direct link - For a direct link to a particular computer, the DTP field of the associated entry would contain the keyword direct. This is true for both types of direct-link entries, Direct and Sys-Name (refer to "Type Field").

• Computers on the same port selector - If a computer with which you want to communicate is on the same port selector switch as your computer, your computer must first access the switch. The switch then makes the connection to the other computer. This type of entry has only one pair. The dialer portion is used to match a Dialers file entry as shown in Example 12-8. (The titles of each column apply only to fields in the Devices file.)

Example 12-8 Dialers Field and /etc/uucp/Dialers Correspondence

File Name  Type     Line  Line2  Class  Dialer-Token-Pairs
 
Devices    develcon cua/a -      1200   develcon
 
Dialers    develcon ,""   ""            \pr\ps\c est:\007 \E\D\e \007

As shown, the token portion is left blank. This indicates that it is retrieved from the Systems file. The Systems file entry for this computer contains the token in the Phone field, which is normally reserved for the phone number of the computer. (Refer to "/etc/uucp/Systems File".) This type of DTP contains an escape character (\D), which ensures that the contents of the Phone field not interpreted as a valid entry in the Dialcodes file.

• Modems connected to port selector - If a high-speed modem is connected to a port selector, your computer must first access the port selector switch. The switch 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, as shown in Example 12-7. (Notice that the titles of each column apply only to fields in the Devices file.)

Example 12-9 Dialers Field and /etc/uucp/Dialers Correspondence

File Name  Type     Line  Line2  Class     Dialer-Token-Pairs
 
Devices    ACU      cua/b -      1200      develcon    vent        ventel
 
Dialers    develcon ""    ""     \pr\ps\c  est:\007    \E\D\e      \007
 
Dialers    ventel   =&-%   t""   \r\p\r\c  $           <K\T%\r>\c  ONLINE!

In the first pair, develcon is the dialer and vent is the token that is passed to the Develcon switch to tell it which device (such as Ventel modem) to connect to your computer. This token is unique for each port selector since each switch can be set up differently. After the Ventel modem has been connected, the second pair is accessed, where Ventel is the dialer and the token is retrieved from the Systems file.

Two escape characters can appear in a DTP field:

• \T - Indicates that the Phone (token) field should be translated using the /etc/uucp/Dialcodes file. This escape character is normally placed in the /etc/uucp/Dialers file for each caller script associated with a modem (Hayes, US Robotics, and so on). Therefore, the translation does not take place until the caller script is accessed.

• \D - Indicates that the Phone (token) field should not be translated using the /etc/uucp/Dialcodes file. If no escape character is specified at the end of a Devices entry, the \D is assumed (default). A \D is also used in the /etc/uucp/Dialers file with entries associated with network switches (develcon and micom).

Protocol Definitions in the Devices File

You can define the protocol to use with each device in /etc/uucp/Devices. This is usually unnecessary because you can use the default or define the protocol with the particular system you are calling. (Refer to "/etc/uucp/Systems File".) If you do specify the protocol, you must use the form:

Type,Protocol [parameters]

For example, you can use TCP,te to specify the TCP/IP protocol.

Table 12-4 shows the available protocols for the Devices file:

Here is an example showing a protocol designation for a device entry:

TCP,te - - Any TCP - 

This example indicates that, for device TCP, try to use the t protocol. If the other end refuses, use the e protocol.

Neither e nor t is appropriate for use over modems. Even if the modem assures error-free transmission, data can still be dropped between the modem and the CPU.

/etc/uucp/Dialers File

The /etc/uucp/Dialers file contains dialing instructions for many commonly used modems. You probably do not need to change or add entries to this file unless you plan to use a nonstandard modem or plan to customize your UUCP environment. Nevertheless, you should understand what is in the file and how it relates to the Systems and Devices file.

The text specifies the initial conversation that must take place on a line before it can be made available for transferring data. This conversation, often referred to as a chat-script, is usually a sequence of ASCII strings that is transmitted and expected, and it is often used to dial a phone number.

As shown in the examples in "/etc/uucp/Devices File" the fifth field in a Devices file entry is an index into the Dialers file or a special dialer type (TCP, TLI, or TLIS). The uucico daemon attempts 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 conversation.

Each entry in the Dialers file has the following format:

dialer 

substitutions 

expect-send

Example 12-10 shows the entry for a US Robotics V.32bis modem.

Example 12-10 /etc/uucp/Dialers File Entry

Dialer       Substitution  Expaec-Send
usrv32bis-e  =,-,  ""      dA\pT&FE1V1X1Q0S2=255S12=255&A1&H1&M5&B2&W\r\c OK\r 
                           \EATDT\T\r\c CONNECT\s14400/ARQ STTY=crtscts

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 is usually used to translate = and - into whatever the dialer requires for "wait for dial tone" and "pause."

The remaining expect-send fields are character strings.

Example 12-11 shows some sample entries in the Dialers file, as distributed when you install UUCP as part of the Solaris installation program.

Example 12-11 Excerpts From /etc/uucp/Dialers

penril	=W-P "" \d > Q\c : \d- > s\p9\c )-W\p\r\ds\p9\c-) y\c : \E\TP > 9\c OK 
 
ventel	=&-%	"" \r\p\r\c $ <K\T%%\r>\c ONLINE! 
 
vadic	=K-K	"" \005\p *-\005\p-*\005\p-* D\p BER? \E\T\e \r\c LINE 
 
develcon	""	"" \pr\ps\c est:\007 
 
\E\D\e \n\007 micom	""	"" \s\c NAME? \D\r\c GO 
 
hayes	=,-,	"" \dA\pTE1V1X1Q0S2=255S12=255\r\c OK\r \EATDT\T\r\c CONNECT 
 
#   Telebit TrailBlazer 
tb1200	=W-,	"" \dA\pA\pA\pTE1V1X1Q0S2=255S12=255S50=2\r\c OK\r \EATDT\T\r\c CONNECT\s1200   
tb2400	=W-,	"" \dA\pA\pA\pTE1V1X1Q0S2=255S12=255S50=3\r\c OK\r \EATDT\T\r\c CONNECT\s2400   
tbfast	=W-,	"" \dA\pA\pA\pTE1V1X1Q0S2=255S12=255S50=255\r\c OK\r \EATDT\T\r\c CONNECT\sFAST 
 
# USrobotics, Codes, and DSI modems 
 
dsi-ec  =,-,    "" \dA\pTE1V1X5Q0S2=255S12=255*E1*F3*M1*S1\r\c OK\r \EATDT\T\r\c 
CONNECT\sEC STTY=crtscts,crtsxoff 
 
dsi-nec =,-,    "" \dA\pTE1V1X5Q0S2=255S12=255*E0*F3*M1*S1\r\c OK\r \EATDT\T\r\c CONNECT 
STTY=crtscts,crtsxoff 
 
usrv32bis-ec =,-,  "" \dA\pT&FE1V1X1Q0S2=255S12=255&A1&H1&M5&B2&W\r\c OK\r \EATDT\T\r\c 
CONNECT\s14400/ARQ STTY=crtscts,crtsxoff 
 
usrv32-nec =,-, "" \dA\pT&FE1V1X1Q0S2=255S12=255&A0&H1&M0&B0&W\r\c OK\r \EATDT\T\r\c 
CONNECT STTY=crtscts,crtsxoff 
 
codex-fast =,-, "" \dA\pT&C1&D2*MF0*AA1&R1&S1*DE15*FL3S2=255S7=40S10=40*TT5&W\r\c OK\r 
\EATDT\T\r\c CONNECT\s38400 STTY=crtscts,crtsxoff 
 
tb9600-ec =W-,  "" \dA\pA\pA\pTE1V1X1Q0S2=255S12=255S50=6\r\c OK\r 
\EATDT\T\r\cCONNECT\s9600 STTY=crtscts,crtsxoff 
 
tb9600-nec =W-, "" \dA\pA\pA\pTE1V1X1Q0S2=255S12=255S50=6S180=0\r\c OK\r \EATDT\T\r\c 
CONNECT\s9600 STTY=crtscts,crtsxoff

Table 12-5 lists escape characters commonly used in the send strings in the Dialers file:

Here is a penril entry in the Dialers file:

penril =W-P "" \d > Q\c : \d- > s\p9\c )-W\p\r\ds\p9\c-) y\c : \E\TP > 9\c OK 

First, the substitution mechanism for the phone number argument is established, so that any = is replaced with a W (wait for dial tone) and any - with a P (pause).

The handshake given by the remainder of the line works as listed:

• "" - Wait for nothing. (that is, proceed to the next thing)

• \d - Delay 2 seconds, then send a carriage-return

• > - Wait for a >

• Q\c - Send a Q without a carriage-return

• : - Expect a :

• \d- - Delay 2 seconds, send a - and a carriage-return

• > - Wait for a >

• s\p9\c - Send an s, pause, send a 9 with no carriage-return

• )-W\p\r\ds\p9\c-) - Wait for a ). If it is not received, process the string between the - characters as follows. Send a W, pause, send a carriage-return, delay, send an s, pause, send a 9, without a carriage-return, then wait for the ).

• y\c - Send a y with no carriage-return

• : - Wait for a :

• \E\TP - Enable echo checking. (From this point on, whenever a character is transmitted, it waits for the character to be received before doing anything else.) Then, send the phone number. The \T means take the phone number passed as an argument and apply the Dialcodes translation and the modem function translation specified by field 2 of this entry. Then send a P and a carriage-return.

• > - Wait for a >

• 9\c - Send a 9 without a newline

• OK - Wait for the string OK

Hardware Flow Control

You can also use the pseudo-send STTY=value string to set modem characteristics. For instance, STTY=crtscts enables outbound hardware flow control, STTY=crtsxoff enables inbound hardware flow control, and STTY=crtscts,crtsxoff enables both outbound and inbound hardware flow control.

STTY accepts all the stty modes. See the stty(1) and termio(7I) man pages.

The following example would enable hardware flow control in a Dialers entry:

dsi =,-, "" \dA\pTE1V1X5Q0S2=255S12=255*E1*F3*M1*S1\r\c OK\r \EATDT\T\r\c 
CONNECT\sEC STTY=crtscts 

This pseudo-send string can also be used in entries in the Systems file.

Setting Parity

In some cases, you have to reset the parity because the system that you are calling checks port parity and drops the line if it is wrong. The expect-send couplet ~~ P_ZERO sets parity to zero:

foo =,-, "" P_ZERO "" \dA\pTE1V1X1Q0S2=255S12=255\r\c OK\r\EATDT\T\r\c CONNECT 

In the same manner, P_EVEN sets it to even (the default); P_ODD sets it to odd; and P_ONE sets it to one. This pseudo-send string can also be used in entries in the Systems file.

Other Basic Configuration Files

The files in this section can be used in addition to the Systems, Devices, and Dialers file when doing basic UUCP configuration.

/etc/uucp/Dialcodes File

The /etc/uucp/Dialcodes file enables you to define dial-code abbreviations that can be used in the Phone field in the /etc/uucp/Systems file. You can use the Dialcodes files to provide additional information about a basic phone number that is used by several systems at the same site.

Each entry has the format:

abbreviation dial-sequence

where abbreviation represents the abbreviation used in the Phone field of the Systems file and dial-sequence represents the dial sequence passed to the dialer when that particular Systems file entry is accessed. Table 12-6 shows the correspondences between the two files.

Table 12-7 contains sample entries in a Dialcodes file.

In the first row, NY is the abbreviation to appear in the Phone field of the Systems file. For example, the Systems file might have the entry:

NY5551212

When uucico reads NY in the Systems file, it searches the Dialcodes file for NY and obtains the dialing sequence 1=212. This is the dialing sequence needed for any phone call to New York City. It includes the number 1, an equal sign (=) meaning pause and wait for a secondary dial tone, and the area code 212. uucico sends this information to the dialer, then returns to the Systems file for the remainder of the phone number, 5551212.

The entry jt 9=847- would work with a Phone field in the Systems file such as jt7867. When uucico reads the entry containing jt7867 in the Systems file, it sends the sequence 9=847-7867 to the dialer, if the token in the dialer-token pair is \T.

/etc/uucp/Sysfiles File

The /etc/uucp/Sysfiles file lets you assign different files to be used by uucp and cu as Systems, Devices, and Dialers files. (For more information on cu, see the cu(1C) man page.) You might want to use Sysfiles for:

• Different Systems files, so that requests for login services can be made to different addresses than uucp services.

• Different Dialers files, so that you can assign different handshaking for cu and uucp.

• Multiple Systems, Dialers, and Devices files. The Systems file in particular can 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 

w represents uucico, cu, or both separated by a colon. x represents 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 represents one or more files to be used as the Dialers file. z is one or more files to be used as the Devices file.

Each file name is assumed to be relative to the /etc/uucp directory, unless a full path is given.

Below is a sample /etc/uucp/Sysfiles that defines a local Systems file (Local_Systems) in addition to the standard /etc/uucp/Systems file:

service=uucico:cu systems=Systems :Local_Systems 

When this entry is in /etc/uucp/Sysfiles, both uucico and cu first look in the standard /etc/uucp/Systems. If the system they are trying to call doesn't have an entry in that file, or if the entries in the file fail, then they look in /etc/uucp/Local_Systems.

Given the above entry, cu and uucico share the Dialers and Devices files.

When different Systems files are defined for uucico and cu services, your machine stores two different lists of Systems. You can print the uucico list using the uuname command or the cu list using the uuname -C command. Another example of the file, where the alternate files are consulted first and the default files are consulted in case of need is:

service=uucico systems=Systems.cico:Systems   
  dialers=Dialers.cico:Dialers \ 
devices=Devices.cico:Devices   
  service=cu systems=Systems.cu:Systems \ 
dialers=Dialers.cu:Dialers \   
  devices=Devices.cu:Devices

/etc/uucp/Sysname File

Every machine that uses UUCP must have an identifying name, often referred to as the node name. This is the name that appears in the remote machine's /etc/uucp/Systems file along with the chat-script and other identifying information. Normally, UUCP uses the same node name as is returned by the uname -n command, which is also used by TCP/IP.

You can specify a UUCP node name independent of the TCP/IP host name by creating the /etc/uucp/Sysname file. The file has a one-line entry containing the UUCP node name for your system.

/etc/uucp/Permissions File

The /etc/uucp/Permissions file 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 machine. Another option is available that specifies the commands that a remote machine can execute on the local computer.

Structuring Entries

Each entry is a logical line, with physical lines terminated by a backslash (\) to indicate continuation. Entries are made up of options delimited by blank space. Each option is a name-value pair in the following format:

name=value

Values can be colon-separated lists. No blank space is allowed within an option assignment.

Comment lines begin with a pound sign (#), and they occupy the entire line up to a newline character. Blank lines are ignored (even within multiple-line entries).

There types of Permissions file entries are:

• LOGNAME - Specifies the permissions that take effect when a remote computer logs in to (calls) your computer.

When a remote machine calls you, its identity is questionable unless it has a unique login and verifiable password.

• MACHINE - Specifies permissions that take effect when your computer logs in to (calls) a remote computer.

LOGNAME entries contain a LOGNAME option and MACHINE entries contain a MACHINE option. One entry can contain both options.

Considerations

When using the Permissions file to restrict the level of access granted to remote computers, you should consider the following:

• All login IDs used by remote computers 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, has the following default permissions or restrictions:

  • Local send and receive requests are executed.

  • The remote computer can send files to your computer's /var/spool/uucppublic directory.

  • The commands sent by the remote computer for execution on your computer must be one of the default commands, usually rmail.

REQUEST Option

When a remote computer calls your computer and requests to receive a file, this request can be granted or denied. The REQUEST option specifies whether the remote computer can request to set up file transfers from your computer. The string REQUEST=yes specifies that the remote computer can request to transfer files from your computer. The string REQUEST=no specifies that the remote computer cannot request to receive files from your computer. This is the default value; it is used if the REQUEST option is not specified. The REQUEST option can appear in either a LOGNAME (remote computer calls you) entry or a MACHINE (you call remote computer) entry.

SENDFILES Option

When a remote computer calls your computer and completes its work, it can attempt to take work your computer has queued for it. The SENDFILES option specifies whether your computer can send the work queued for the remote computer.

The string SENDFILES=yes specifies that your computer can send the work that is queued for the remote computer as long as itis logged in as one of the names in the LOGNAME option. This string is mandatory if you have entered Never in the Time field of /etc/uucp/Systems. This designation sets up your local machine in passive mode; it is not allowed to initiate a call to this particular remote computer. (See "/etc/uucp/Systems File" for more information.)

The string SENDFILES=call specifies that files queued in your computer are sent only when your computer calls the remote computer. The call value is the default for the SENDFILES option. This option is only significant in LOGNAME entries since MACHINE entries apply when calls are made out to remote computers. If the option is used with a MACHINE entry, it is ignored.

MYNAME Option

This option enables you to designate a unique UUCP node name for your computer in addition to its TCP/IP host name, as returned by the hostname command. For instance, if you have unknowingly given your host the same name as that of some other system, you might want to set the MYNAME option of the Permissions file. Or if you want your organization to be known as widget but all your modems are connected to a machine with the host name gadget, you can have an entry in gadget's Permissions file that says:

service=uucico systems=Systems.cico:Systems   
  dialers=Dialers.cico:Dialers \ 
  devices=Devices.cico:Devices   
service=cu systems=Systems.cu:Systems \ 
  dialers=Dialers.cu:Dialers \   
  devices=Devices.cu:Devices

Now the system world can log in to the machine gadget as if it were logging in to widget. In order for machine world to know you also by the aliased name widget when you call it, you can have an entry that says:

MACHINE=world MYNAME=widget

You can also use the MYNAME option for testing purposes, since it allows your machine to call itself. However, since this option could be used to mask the real identity of a machine, you should use the VALIDATE option, as described in "VALIDATE Option".

READ and WRITE Options

These options specify the various parts of the file system that uucico can read from or write to. You can designate READ and WRITE options with either MACHINE or LOGNAME entries.

The default for both the READ and WRITE options is the uucppublic directory, as shown in the following strings:

READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic 

The strings READ=/ and WRITE=/ specify permission to access any file that can be accessed by a local user with Other permissions.

The value of these entries is a colon-separated list of path names. The READ option is for requesting files, and the WRITE option is for depositing files. One of the values must be the prefix of any full path name of a file coming in or going out. To grant permission to deposit files in /usr/news as well as the public directory, use the following values with the WRITE option:

WRITE=/var/spool/uucppublic:/usr/news 

If the READ and WRITE options are used, all path names must be specified because the path names are not added to the default list. For instance, if the /usr/news path name were the only one specified in a WRITE option, permission to deposit files in the public directory would be denied.

You should be careful which directories you make accessible for reading and writing by remote systems. For example, the /etc directory contains many critical system files; remote users should not have permission to deposit files in this directory.

NOREAD and NOWRITE Options

The NOREAD and NOWRITE options specify exceptions to the READ and WRITE options or defaults. The entry:

READ=/ NOREAD=/etc WRITE=/var/spool/uucppublic 

permits reading any file except those in the /etc directory (and its subdirectories--remember, these are prefixes). It permits writing only to the default /var/spool/uucppublic directory. NOWRITE works in the same manner as the NOREAD option. You can use the NOREAD and NOWRITE options in both LOGNAME and MACHINE entries.

CALLBACK Option

You can use the CALLBACK option in LOGNAME entries to specify that no transaction takes place until the calling system is called back. There are two reasons to set up CALLBACK: For security purposes, if you call back a machine, you can be sure it is the right machine. For accounting purposes, if you are doing long data transmissions, you can choose the machine that is billed for the longer call.

The string CALLBACK=yes specifies that your computer must call the remote computer back before any file transfers can take place.

The default for the CALLBACK option is CALLBACK=no. If you set CALLBACK to yes, then the permissions that affect the rest of the conversation must be specified in the MACHINE entry corresponding to the caller. Do not specify these permissions in the LOGNAME, or in the LOGNAME entry that the remote machine might have set for your host.

If two sites have the CALLBACK option set for each other, a conversation never gets started.

COMMANDS Option

The COMMANDS option can compromise the security of your system. Use it with extreme care.

You can use the COMMANDS option in MACHINE entries to specify the commands that a remote computer can execute on your machine. The uux program generates remote execution requests and queue them to be transferred to the remote computer. Files and commands are sent to the target computer for remote execution. This is an exception to the rule that MACHINE entries apply only when your system calls out.

Note that COMMANDS is not used in a LOGNAME entry; COMMANDS in MACHINE entries defines command permissions, whether you call the remote system or it calls you.

The string COMMANDS=rmail specifies the default commands that a remote computer can execute on your computer. If a command string is used in a MACHINE entry, the default commands are overridden. For instance, the entry:

MACHINE=owl:raven:hawk:dove COMMANDS=rmail:rnews:lp 

overrides the COMMAND default so that the computers named owl, raven, hawk, and dove can now execute rmail, rnews, and lp on your computer.

In addition to the names as specified above, there can be full path names of commands. For example:

COMMANDS=rmail:/usr/local/rnews:/usr/local/lp 

specifies that command rmail uses the default search path. The default search path for UUCP is /bin and /usr/bin. When the remote computer specifies rnews or /usr/local/rnews for the command to be executed, /usr/local/rnews is executed regardless of the default path. Likewise, /usr/local/lp is the lp command that is executed.

Including the ALL value in the list means that any command from the remote computers specified in the entry will be executed. If you use this value, you give the remote computers full access to your machine.

This allows far more access than normal users have. You should use this value only when both machines are at the same site, are closely connected, and the users are trusted.

The string:

COMMANDS=/usr/local/rnews:ALL:/usr/local/lp 

illustrates two points:

• The ALL value can appear anywhere in the string.

• The path names specified for rnews and lp are used (instead of the default) if the requested command does not contain the full path names for rnews or lp.

You should use the VALIDATE option whenever you specify potentially dangerous commands like cat and uucp with the COMMANDS option. Any command that reads or writes files is potentially dangerous to local security when executed by the UUCP remote execution daemon (uuxqt).

VALIDATE Option

Use the VALIDATE option in conjunction with the COMMANDS option whenever you specify commands that are potentially dangerous to your machine's security. (VALIDATE is merely an added level of security on top of the COMMANDS option, though it is a more secure way to open command access than ALL.)

VALIDATE provides a certain degree of verification of the caller's identity by cross-checking the host name of a calling machine against the login name it uses. The string:

LOGNAME=Uwidget VALIDATE=widget:gadget 

ensures that if any machine other than widget or gadget tries to log in as Uwidget, the connection is refused. The VALIDATE option requires privileged computers to have a unique login and password for UUCP transactions. An important aspect of this validation is that the login and password associated with this entry are protected. If an outsider gets that information, that particular VALIDATE option can no longer be considered secure.

Carefully consider which remote computers you will grant privileged logins and passwords 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 LOGNAME entry:

LOGNAME=uucpfriend VALIDATE=eagle:owl:hawk 

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. If an outsider gets the uucpfriend login and password, masquerading is easy.

But what does this have to do with the COMMANDS option, which appears only in MACHINE entries? It links the MACHINE entry (and COMMANDS option) with a LOGNAME entry associated with a privileged login. This link is needed because the execution daemon is not running while the remote computer is logged in. In fact, it is an asynchronous process that does not know which computer sent the execution request. Therefore, the real question is, how does your computer know where the execution files came from?

Each remote computer has its own spool directory on your local machine. These spool directories have write permission given only to the UUCP programs. The execution files from the remote computer are put in its spool directory after being transferred to your computer. When the uuxqt daemon runs, it can use the spool directory name to find the MACHINE entry in the Permissions file and get the COMMANDS list. Or, if the computer name does not appear in the Permissions file, the default list is used.

This example shows the relationship between the MACHINE and LOGNAME entries:

MACHINE=eagle:owl:hawk REQUEST=yes \ 
COMMANDS=rmail:/usr/local/rnews \ 
READ=/ WRITE=/ 
LOGNAME=uucpz VALIDATE=eagle:owl:hawk \ 
REQUEST=yes SENDFILES=yes \ 
READ=/ WRITE=/ 

The value in the COMMANDS option means that remote users can execute rmail and /usr/local/rnews.

In the first entry, you must assume that when you want to call one of the computers listed, you are really calling either eagle, owl, or hawk. Therefore, any files put into one of the eagle, owl, or hawk spool directories is put there by one of those computers. If a remote computer logs in and says that it is one of these three computers, its execution files are also put in the privileged spool directory. You therefore have to validate that the computer has the privileged login uucpz.

MACHINE Entry for OTHER

You might want to specify different option values for remote machines that are not mentioned in specific MACHINE entries. The need might arise when many computers are calling your host, and the command set changes from time to time. The name OTHER for the computer name is used for this entry as shown in this example:

MACHINE=OTHER \ 
COMMANDS=rmail:rnews:/usr/local/Photo:/usr/local/xp 

All other options available for the MACHINE entry can also be set for the computers that are not mentioned in other MACHINE entries.

Combining MACHINE and LOGNAME

You can combine MACHINE and LOGNAME entries into a single entry where the common options are the same. For example, the two entries:

MACHINE=eagle:owl:hawk REQUEST=yes \ 
READ=/ WRITE=/

and:

LOGNAME=uupz REQUEST=yes SENDFILES=yes \ 
READ=/ WRITE=/

share the same REQUEST, READ, and WRITE options. You can merge them, as shown:

MACHINE=eagle:owl:hawk REQUEST=yes \ 
logname=uucpz SENDFILES-yes \ 
READ=/ WRITE=/

Combining MACHINE and LOGNAME entries makes the Permissions file more manageable and efficient.

Forwarding

When sending files through a series of machines, the intermediary machines must have the command uucp among their COMMANDS options. That is, if you type the command:

% uucp sample.txt oak\!willow\!pine\!/usr/spool/uucppublic

This forwarding operation works only if machine willow permits oak to execute the program uucp, and if oak permits your machine to do the same. The machine pine, being the last machine designated, does not have to permit the command uucp. Machines are not normally set up this way.

/etc/uucp/Poll File

The /etc/uucp/Poll file 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 or a space, and finally the hours the computer should be called. The format of entries in the Poll file are:

sys-name hour ...

For example, the entry

eagle 0 4 8 12 16 20 

provides polling of computer eagle every four hours.

The uudemon.poll script processes the Poll file but does not actually perform the poll. It merely sets up a polling work file (always named C.file) in the spool directory. The uudemon.poll script starts the scheduler, and the scheduler examines all work files in the spool directory.

/etc/uucp/Config File

The /etc/uucp/Config file enables you to override certain parameters manually. Each entry in the Config file has this format:

parameter=value

See the Config file provided with your system for a complete list of configurable parameter names.

The following Config entry sets the default protocol ordering to Gge and changes the G protocol defaults to 7 windows and 512-byte packets.

Protocol=G(7,512)ge

/etc/uucp/Grades File

The /etc/uucp/Grades file contains the definitions for the job grades that can be used to queue jobs to a remote computer. It also contains the permissions for each job grade. Each entry in this file represents a definition of an administrator-defined job grade that lets users queue jobs.

Each entry in the Grades file has the following format:

User-job-grade System-job-grade Job-size Permit-type ID-list

Each entry contains fields that are separated by blank space. The last field in the entry is made up of subfields also separated by spaces. If a entry takes up more than one physical line, then you can use a backslash to continue the entry onto the following line. Comment lines begin with a pound sign (#) and occupy the entire line. Blank lines are always ignored.

User-job-grade Field

This field contains an administrative-defined user job grade name of up to 64 characters.

System-job-grade Field

This field contains a one-character job grade to which User-job-grade is mapped. The valid list of characters is A-Z, a-z, with A having the highest priority and z the lowest.

Relationship Between User and System Job Grades

The user job grade can be bound to more than one system job grade. It is important to note that the Grades file is searched sequentially for occurrences of a user job grade. Therefore, any multiple occurrences of a system job grade should be listed according to the restriction on the maximum job size.

While there is no maximum number for the user job grades, the maximum number of system job grades allowed is 52. The reason is that more than one User-job-grade can be mapped to a System-job-grade, but each User-job-grade must be on a separate line in the file. Here is an example:

mail N Any User Any netnews N Any User Any 

Given this configuration in a Grades file, these two User-job-grade will share the same System-job-grade. Since the permissions for a Job-grade are associated with a User-job-grade and not a System-job-grade, two User-job-grades can share the same System-job-grades and have two different sets of permissions.

Default Grade

You can define the binding of a default User-job-grade to a system job grade. You must use the keyword default as user job grade in the User-job-grade field of the Grades file and the system job grade that it is bound to. The Restrictions and ID fields should be defined as Any so that any user and any size job can be queued to this grade. Here is an example:

default a Any User Any 

If you do not define the default user job grade, then the built-in default grade Z is used. Because the restriction field default is Any, multiple occurrences of the default grade are not checked.

Job-size Field

This field specifies the maximum job size that can be entered in the queue. Job-size is measured in bytes and can be a list of the options listed in Table 12-8:

Here are some examples:

• 5000 represents 5000 bytes

• 10K represents 10 Kbytes

• 2M represents 2 Mbytes

Permit-type Field

This field contains a keyword that denotes how to interpret the ID list. Table 12-9 lists the keywords and their meanings:

ID-list Field

This field contains a list of login names or group names that are to be permitted or denied queuing to this job grade. The list of names are separated by blank space and terminated by a newline character. The keyword Any is used to denote that anyone is permitted to queue to this job grade.

Other UUCP Configuration Files

This section describes three less-frequently modified files that impact the use of UUCP facilities.

/etc/uucp/Devconfig File

The /etc/uucp/Devconfig file enables you to configure devices by service--uucp or cu. Devconfig entries define the STREAMS modules that are used for a particular device. They have the format:

service=x device=y push=z[:z...]

x can be cu, uucico, or both separated by a colon. y is the name of a network and must match an entry in the Devices file. z is replaced by the names of STREAMS modules in the order that they are to be pushed onto the Stream. Different modules and devices can be defined for cu and uucp services.

The following entries are for a STARLAN network and would most commonly be used in the file:

service=cu       device=STARLAN     push=ntty:tirdwr 
service=uucico   device=STARLAN     push=ntty:tirdwr 

This example pushes ntty, then tirdwr.

/etc/uucp/Limits File

The /etc/uucp/Limits file controls the maximum number of simultaneous uucicos, uuxqts, and uuscheds that are running in the uucp networking. In most cases, the default values are fine and no changes are needed. If you want to change them, however, use any text editor.

The format of the Limits file is:

service=x max=y:

x can be uucico, uuxqt or uusched, and y is the limit permitted for that service. The fields can be in any order and in lowercase.

The following entries should most commonly be used in the Limits file:

service=uucico max=5 
service=uuxqt max=5 
service=uusched max=2 

The example allows five uucicos, five uuxqts, and two uuscheds running on your machine.

remote.unknown File

The other file that affects the use of communication facilities is the remote.unknown file. This file is a binary program that executes when a machine not found in any of the Systems files starts a conversation. It logs the conversation attempt and drop the connection.

If you change the permissions of the remote.unknown file so it cannot execute, your system accepts connections from any system.

This program executes when a machine that is not in any of the Systems starts a conversation. It logs the conversation attempt but fails to make a connection. If you change the permissions of this file so it cannot execute (chmod 000 remote.unknown), your system accepts any conversation requests. This is not a trivial change, and you should have very good reasons for doing it.

Administrative Files

The UUCP administrative files are described below. These files are created in spool directories to lock devices, hold temporary data, or keep information about remote transfers or executions.

• Temporary data files (TM) - These data files are created by UUCP processes under the spool directory /var/spool/uucp/x when a file is received from another computer. The directory x has the same name as the remote computer that is sending the file. The names of the temporary data files have the 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 path name specified in the C.sysnxxxx file (discussed below) that caused the transmission. If processing is abnormally terminated, the TM.pid.ddd file can remain in the x directory. These files should be automatically removed by uucleanup.

• Lock files (LCK) - Lock files are created in the /var/spool/locks directory for each device in use. Lock files prevent duplicate conversations and multiple attempts to use the same calling device. Table 12-10 shows the different types of UUCP lock files.

These files can remain in the spool directory if the communications link is unexpectedly dropped (usually on computer crashes). The lock files is ignored (removed) after the parent process is no longer active. The lock file contains the process ID of the process that created the lock.

• Work file (C.) - Work files are created in a spool directory when work (file transfers or remote command executions) has been queued for a remote computer. The names of work files have the 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:

  • Full path name of the file to be sent or requested

  • Full path name 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

  • Remote user's login name to be notified upon completion of the transfer

• Data file (D.) - Data files are created when you specify on 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 can be followed by a subsequence number, yyy that is used when there are several D. files created for a work (C.) file.

• X. (execute file) - Execute files are created in the spool directory prior to remote command executions. The names of execute files have the following format:

  X.sysnxxxx

  sys is the name of the remote computer. n is the character representing the grade (priority) of the work. xxxx is a four-digit sequence number assigned by UUCP. Execute files contain the following information:

  • Requester's login and computer name

  • Names of files 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

Chapter 13 Configuring and Maintaining UUCP

This chapter explains how to start up UUCP operations afteryou have modified the database file relevant to your machines. The chapter contains procedures and troubleshooting information for setting up and maintaining UUCP on machines running the Solaris environment.

• "Adding UUCP Logins"

• "Running UUCP Over TCP/IP"

• "Setting Up UUCP Security"

• "Regular UUCP Maintenance"

• "UUCP Error Messages"

Adding UUCP Logins

For incoming UUCP (uucico) requests from remote machines to be handled properly, each machine has to have a login on your system.

Here is a typical entry that you might put into the /etc/passwd file for a remote machine permitted to access your system with a UUCP connection:

Ugobi:*:5:5:gobi:/var/spool/uucppublic:/usr/lib/uucp/uucico 

By convention, the login name of a remote machine is the machine name preceded by the uppercase letter U. Note that the name should not exceed eight characters, so that in some cases you might have to truncate or abbreviate it.

The previous entry shows that a login request by Ugobi is answered by /usr/lib/uucp/uucico. The home directory is /var/spool/uucppublic. The password is obtained from the /etc/shadow file. You must coordinate the password and the login name with the UUCP administrator of the remote machine. The remote administrator must then add an appropriate entry, with login name and unencrypted password, in the remote machine's Systems file.

Similarly, you must coordinate your machine's name and password with the UUCP administrators of all machines that you want to reach through UUCP.

Starting UUCP

UUCP comes with four shell scripts that poll remote machines, reschedule transmissions, and clean up old log files and unsuccessful transmissions. The scripts are:

• uudemon.poll

• uudemon.hour

• uudemon.admin

• uudemon.cleanup

These shell scripts should execute regularly to keep UUCP running smoothly. The crontab file to run the scripts is automatically created in /usr/lib/uucp/uudemon.crontab as part of the Solaris installation process, if you select the full installation. Otherwise, it is created when you install the UUCP package.

You can also run the UUCP shell scripts manually. The following is the prototype uudemon.crontab file that you can tailor for a particular machine:

#
#ident  "@(#)uudemon.crontab    1.5     97/12/09 SMI"
#
# This crontab is provided as a sample. For systems
# running UUCP edit the time schedule to suit, uncomment 
# the following lines, and use crontab(1) to activate the
# new schedule.
#
#48 8,12,16 * * * /usr/lib/uucp/uudemon.admin
#20 3 * * * /usr/lib/uucp/uudemon.cleanup
#0 * * * * /usr/lib/uucp/uudemon.poll
#11,41 * * * * /usr/lib/uucp/uudemon.hour

By default, UUCP operations are disabled. To enable UUCP, edit the time schedule and uncomment the appropriate lines in the uudemon.crontab file.

To activate the uudemon.crontab file, become superuser and type:

# su uucp
# crontab < /usr/lib/uucp/uudemon.crontab

uudemon.poll Shell Script

The default uudemon.poll shell script reads the /etc/uucp/Poll file once an hour. If any machines in the Poll file are scheduled to be polled, a work file (C.sysnxxxx) is placed in the /var/spool/uucp/nodename directory, where nodename represents the UUCP node name of the machine.

The shell script is scheduled to run once an hour, before uudemon.hour, so that the work files are there when uudemon.hour is called.

uudemon.hour Shell Script

The default uudemon.hour shell script:

• Calls the uusched program to search the spool directories for work files (C.) that have not been processed and schedules these files for transfer to a remote machine.

• Calls the uuxqt daemon to search the spool directories for execute files (X.) that have been transferred to your computer and were not processed at the time they were transferred.

By default, uudemon.hour runs twice an hour. You might want it to run more often if you expect high failure rates of calls to remote machines.

uudemon.admin Shell Script

The default uudemon.admin shell script does the following:

1. Runs the uustat command with p and q options. The q reports on the status of work files (C.), data files (D.), and execute files (X.) that are queued. The p prints process information for networking processes listed in the lock files (/var/spool/locks).

2. Sends resulting status information to the uucp administrative login via mail.

uudemon.cleanup Shell Script

The default uudemon.cleanup shell script does the following:

1. Takes log files for individual machines from the /var/uucp/.Log directory, merges them, and places them in the /var/uucp/.Old directory with other old log information.

2. Removes work files (C.) seven days old or older, data files (D.) Seven days old or older, and execute files (X.) two days old or older from the spool files.

3. Returns mail that cannot be delivered to the sender.

4. Mails a summary of the status information gathered during the current day to the UUCP administrative login (uucp).

Running UUCP Over TCP/IP

To run UUCP on a TCP/IP network, you need to make a few modifications, as described in this section.

Activating UUCP in /etc/inetd.conf

Make sure that the following entry in /etc/inetd.conf is not preceded by a comment mark (#):

uucp stream tcp nowait root /usr/sbin/in.uucpd in.uucpd 

Tailoring Systems File Entries for TCP/IP

Entries in the /etc/uucp/Systems file should have the following fields:

System-Name Time TCP Port networkname Standard-Login-Chat

A typical entry would look like this:

rochester Any TCP - ur-seneca login: Umachine password: xxx

Notice that the networkname field permits you to specify explicitly the TCP/IP host name. This is important for some sites. In the example above, the site has the UUCP node name rochester is different from its TCP/IP host name ur-seneca. Moreover, there could easily be a completely different machine running UUCP that has the TCP/IP host name of rochester.

The Port field in the Systems file should have the entry -. This is equivalent to listing it as uucp. In almost every case, the networkname is the same as the system name, and the Port field is -, which says to use the standard uucp port from the services database. The in.uucpd daemon expects the remote machine to send its login and password for authentication, and it prompts for them much as getty and login do.

Checking /etc/inet/services for UUCP

The following entry in /etc/inet/services sets up a port for UUCP:

uucp 540/tcp uucpd # uucp daemon

You should not have to change the entry. However, if your machine runs NIS or NIS+ as its name service, you should change the /etc/nsswitch.conf entry for /etc/services to check files first, then check nis or nisplus.

Security, Maintenance, and Troubleshooting

After you have set up UUCP, maintenance is straightforward. This section explains ongoing UUCP tasks with regard to security, maintenance, and troubleshooting.

Setting Up UUCP Security

The default /etc/uucp/Permissions file provides the maximum amount of security for your UUCP links. The default Permissions file contains no entries.

You can set additional parameters for each machine to define:

• Ways it can receive files from your machine

• Directories for which it has read and write permission

• Commands it can use for remote execution

A typical Permissions entry is:

MACHINE=datsun LOGNAME=Udatsun VALIDATE=datsun 
COMMANDS=rmail REQUEST=yes SENDFILES=yes

This entry allows files to be sent and received (to and from the "normal" UUCP directories, not from anywhere in the system) and causes the UUCP user name to be validated at login time.

Regular UUCP Maintenance

UUCP does not require much maintenance. Apart from making sure that the crontab file is in place, as described in the section "uudemon.poll Shell Script", all you have to worry about is the growth of mail files and the public directory.

Email for UUCP

All email messages generated by the UUCP programs and scripts go to the user ID uucp. If you do not log in frequently as that user, you might not realize that mail is accumulating (and consuming disk space). To solve this, make an alias in /etc/aliases and redirect that email either to root or to yourself and others responsible for maintaining UUCP. Don't forget to run the newaliases command after modifying the aliases file.

Public Directory

The directory /var/spool/uucppublic is the one place in every system to which UUCP by default is able to copy files. Every user has permission to change to /var/spool/uucppublic and read and write files in it. However, its sticky bit is set, so its mode is 01777. As a result, users cannot remove files that have been copied to it and that belong to uucp. Only you, as UUCP administrator logged in as root or uucp, can remove files from this directory. To prevent the uncontrolled accumulation of files in this directory, you should make sure to clean it up periodically.

If this is inconvenient for users, encourage them to use uuto and uupick rather than removing the sticky bit, which is set for security reasons. (See the uuto(1C) man page for instructions for using uuto and uupick.) You can also restrict the mode of the directory to only one group of people. If you do not want to run the risk of someone filling your disk, you can even deny UUCP access to it.

Troubleshooting UUCP

These procedures describe how to solve common UUCP problems.

Checking for Faulty Modems or ACUs

You can check if the modems or other ACUs are not working properly in several ways.

• Run uustat -q. This will give counts and reasons for contact failure.

• Run cu -d -lline, where line is /dev/cua/a. This lets you call over a particular line and print debugging information on the attempt. The line must be defined as direct in the /etc/uucp/Devices file. (You must add a telephone number to the end of the command line if the line is connected to an autodialer or the device must be set up as direct.)

Checking the /etc/uucp/Systems File

Verify that you have up-to-date information in your Systems file if you are having trouble contacting a particular machine. Some things that might be out of date for a machine are its:

• Phone number

• Login ID

• Password

Debugging Transmissions

If you cannot contact a particular machine, you can check out communications to that machine with Uutry and uucp.

1. To try to make contact, type /usr/lib/uucp/Uutry -r machine and press Return.

   Replace machine with the host name of the machine you are having problems contacting. This command:

   1. Starts the transfer daemon (uucico) with debugging. You can get more debugging information if you are root.

   2. Directs the debugging output to /tmp/machine.

   3. Prints the debugging output to your terminal (tail -f).

      Press Control-c to end output. You can copy the output from /tmp/machine if you want to save it.

2. If Uutry doesn't isolate the problem, try to queue a job by typing uucp --r file machine\!/dir/file and press Return.

   Replace file by the file you want to transfer, machine by the machine you want to copy to, and /dir/file where the file will be placed on the other machine. The r option queues a job but does not start the transfer.

3. Now use Uutry again.

   If you still cannot solve the problem, you might need to call your local support representative. Save the debugging output; it will help diagnose the problem.

You might also want to decrease or increase the level of debugging provided by Uutry through the -x n option, where n indicates the debug level. The default debug level for Uutry is 5.

Debug level 3 provides basic information as to when and how the connection is established, but not much information about the transmission itself. Debug level 9, on the other hand, provides exhaustive information about the transmission process. Be aware that debugging occurs at both ends of the transmission. If you intend to use a level higher than 5 on a moderately large text, get in touch with the administrator of the other site and agree on a time for doing so.

Checking Error Messages

UUCP has two types of error messages: ASSERT and STATUS.

When a process is aborted, ASSERT error messages are recorded in /var/uucp/.Admin/errors. These messages include the file name, sccsid, line number, and text. These messages usually result from system problems.

STATUS error messages are stored in the /var/uucp/.Status directory. The directory contains a separate file for each remote machine your computer attempts to communicate with. These files contain status information on the attempted communication and whether it was successful.

Checking Basic Information

Several commands are available for checking basic networking information:

• uuname - Use this command to list those machines your machine can contact.

• uulog - Use this command to display the contents of the log directories for particular hosts.

• uucheck -v - Run this command to check for the presence of files and directories needed by uucp. This command also checks the Permissions file and outputs information on the permissions you have set up.

UUCP Error Messages

This section lists the error messages associated with UUCP.

UUCP ASSERT Error Messages

Table 13-1 lists ASSERT error messages.

UUCP STATUS Error Messages

Table 13-2 is a list of the most common STATUS error messages.

UUCP Numerical Error Messages

Table 13-3 lists the exit code numbers of error status messages produced by the /usr/include/sysexits.h file. Not all are currently used by uucp.