The keyword used in the Type field is matched against the third field of Systems file entries. The Type field can contain one of these keywords: Direct, ACU, or a system name.

You can designate a protocol to use for a device within this field. See the “Protocols” section at the end of the description of this file.

This field contains the device name of the line (port) associated with the Devices entry. For instance, if the automatic dial modem for a particular entry is attached to the /dev/ttyf5 line, the name entered in this field is ttyf5.

You should always use the ttyf devices when working with modems. These devices support hardware flow control, which is used by all modems that support V.32 or V.32bis.

If the keyword ACU is used in the Type field and the ACU is an 801-type dialer, the Line2 field contains the device name of the 801 dialer. (801-type ACUs do not contain a modem. Therefore, a separate modem is required and must be connected to a different line, defined in the Line field.) The need for a separate modem line means that one line would be allocated to the modem and another to the dialer. Because non-801 dialers do not normally use this configuration, they ignore the Line2 field, but it must still contain a hyphen (-) or the word null as a place holder. A place holder is necessary for most modems.

The keyword used in the Class field of the Devices file is matched against the fourth field of Systems file entries:

Devices: ACU ttyf5 null D9600 212 x telebit
Systems: eagle Any ACU D9600 14155551212 login:nuucp password:Oakgrass

Some devices can be used at any speed, so the keyword Any can be used in the Class field. If Any is used, the line will match any speed requested in a Systems file entry. If this field is Any and the Systems file Class field is Any, the speed defaults to 9600 bps. If the keyword ACU or Direct is used in the Type field, the Class field might contain only the speed of the device. However, the speed can also be preceded by a letter (for example, C9600, D9600) to differentiate between classes of dialers (Centrex or Dimension PBX). Including the dialer class is necessary in larger offices that have more than one type of telephone network: One network may be dedicated to serving only internal communications while another handles external. In such a case, it becomes necessary to distinguish which line(s) should be used for internal and which for external.

This field contains pairs of dialers and tokens. The Dialer portion may be the name of an automatic-dial modem, or ``Direct'' for a direct-link device. You can have any number of Dialer-Token-Pair (DTP) fields. The Token portion may be supplied immediately following the Dialer portion; if not present, the Token portion will be taken from a related entry in the Systems file.

This field has the format

dialer   token   dialer   token

The last pair may or may not be present, depending on the associated device (dialer). In most cases, the last pair contains only a Dialer portion and the Token portion is retrieved from the Phone field of the Systems file entry. A valid entry in the Dialer portion may be defined in the Dialers file.

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

If an automatic-dial modem is connected directly to a port on your computer, the DTP field of the associated Devices file entry will have only one pair. This pair is normally the name of the modem. This name is used to match the particular Devices file entry with an entry in the Dialers file. Therefore, the Dialer field must match the first field of a Dialers file entry:

Devices: ACU ttyf2 null 9600 212 x telebit
Dialers: telebit =&-% "" \r\p\r\c $ <K\T%%\r>\c ONLINE!

Notice that only the Dialer portion (telebit) is present in the DTP field of the Devices file entry. This means that the token to be passed on to the dialer (in this case the phone number) is taken from the Phone field of a Systems file entry. (\T is implied)

If a direct link is established to a particular computer, the DTP field of the associated entry contains the keyword Direct. This is true for both types of direct-link entries, Direct and System-Name.

If an automatic-dial modem is connected to a switch, your computer must first access the switch; the switch then makes the connection to the modem. This type of entry requires two Dialer-Token-Pairs. The Dialer portion of each pair (fifth and seventh fields of entry) is used to match entries in the Dialers file:

Devices: ACU ttyf2 null 9600 212 x t2500 telebit T25
Dialers: telebit "" "" \pr\ps\c est:\007 \E\D\e \007
Dialers: T25 =&-% "" \r\p\r\c $ <K\T%%\r>\c ONLINE!

In the first pair, t2500 is the Dialer and telebit is the token that is passed to the Develcon switch to tell it which device (telebit modem) to connect to your computer. This token is unique for each modem switch since each switch may be set up differently. Once the telebit modem has been connected, the second pair is accessed, where T25 is the dialer and the token (the telephone number) is retrieved from the Systems file. (See the discussion of the Systems file's Phone field in “UUCP Systems File”.)

Two escape characters can appear in a DTP field:

You can define the protocol to use with each device. In most cases it is not needed because you can use the default or define the protocol with the particular station you are calling. (See the discussion of the Systems file, specifically the Type field.) If you do specify the protocol, you must do it in the form Type, Protocol. Available protocols are

The list in Table 8-2 describes some of the escape characters used in the Dialers file and the escape sequences used by UUCP.

Here is a sample line from the Dialers file:

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

The penril entry in the Dialers file is executed as follows. The phone number argument is translated, replacing any equal sign with a W (wait for dial tone) and replacing any hyphen with a P (pause).

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

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

day[time][;retry]

The day portion is a list of one or more day specifiers. These specifiers are listed below.

Here is an example of a Time field:

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 0800–1230. If no time portion is specified, any time of day is assumed to be allowed for the call. A time range that spans 0000 is permitted. For example, 0800-0600 means all times are allowed other than at times between 6 a.m. and 8 a.m.

An optional subfield, retry, is available to specify the minimum time (in minutes) before a retry, following a failed attempt. The default wait is 5 minutes after the first failure, 10 after the second, and so on until a delay of about 24 hours. If the retry subfield is present, that wait is used after every failure. The subfield separator is a semicolon (;). For example, “Any;9” is interpreted as “call any time, but wait at least 9 minutes before retrying after a failure occurs.”

This field contains the device type that should be used to establish the communications link to the remote computer. The keyword used in this field is matched against the first field of Devices file entries:

Systems: eagle Any ACU,g D1200 3251 login:nuucp password: Oakgrass
Devices: ACU ttym2 - D1200 penril

You can define the protocol used to contact the station by adding it on to the Type field. The example just given shows how to attach the protocol g to the device type ACU. For direct connects, use the name of the station to which you are connecting. See “UUCP Device Protocols”.

This field is used to indicate the transfer speed of the device used to establish the communications link. It may contain a letter and speed (for example, C1200, D1200) to differentiate between classes of dialers. (See the discussion of the Class field in “UUCP Devices File”.) Some devices can be used at any speed, so the keyword Any may be used. This field must match the Class field in the associated Devices file entry as shown here:

Systems: eagle Any ACU D1200 NY3251 login:nuucp password:Oakgrass
Devices:  ACU ttym2 - D1200 penril

If information is not required for this field, use a hyphen as a place holder for the field.

This field is used to provide the phone number (token) of the remote computer for automatic dialers. The phone number is made up of an optional alphabetic abbreviation and a numeric part. If an abbreviation is used, it must be one that is listed in the Dialcodes file. For example:

Systems: eagle Any ACU D1200 NY3251 login:nuucp password: Oakgrass
Dialcodes:  NY 9=1212555

In this string, an equal sign (=) tells the ACU to wait for a secondary dial tone before dialing the remaining digits. A hyphen (-) in the string instructs the ACU to pause four seconds before dialing the next digit.

If your computer is connected to a modem switch, you may access other computers that are connected to that switch. The Systems file entries for these computers does not have a phone number in the Phone field. Instead, this field contains the token that must be passed on to the switch so it will know which computer your computer wishes to communicate with. This token is usually just the station name. The associated Devices file entry should have a \D at the end of the entry to ensure that this field is not translated by means of the Dialcodes file.

This field contains login information given as a series of fields and subfields of this format:

expect send

The send string is sent when the expect string is received. The expect field may be made up of subfields of this 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 the string login. If UUCP receives that string, it goes on to the next field. If it does not receive the string, it sends nothing, followed by a new line, then looks for login again. If no characters are initially expected from the remote computer, the characters " " (null string) should be used in the first expect field. Note that all send fields are sent followed by a newline unless the send string is terminated with a \c.

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

owl Any ACU 1200 NY6013 "" \r login:-BREAK-login: uucpx word: xyzzy

This example means causes UUCP to send a carriage return and wait for the string login:. If it doesn't receive the string, it sends a break character and waits for login: again. When it does receive the string login, it sends the login name uucpx; waits to receive the string word: (the last part of “Password:”); and sends the password xyzzy.

Several escape sequences cause specific actions when they are a part of a string sent during the login sequence. These are the same escape sequences used in the Dialers file, listed in Table 8-2.

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:

This section describes each option, specifies how it is used, and lists its default value.

REQUEST		When a remote computer calls your computer and requests to receive a file, this request can be granted or denied. The REQUEST option specifies whether the remote computer can request to set up file transfers from your computer. The string that follows specifies that the remote computer can request to transfer files from your computer: REQUEST=yes The following string specifies that the remote computer cannot request to receive files from your computer: REQUEST=no This is the default value. It will be used if the REQUEST option is not specified. The REQUEST option can appear in either a LOGNAME (remote calls you) entry or a MACHINE (you call remote) entry. A note on security: When a remote computer calls you, you cannot verify its identity unless you have a unique login and password for that computer.
SENDFILES		When a remote computer calls your computer and completes its work, it may attempt to take work your computer has queued for it. The SENDFILES option specifies whether your computer can send the work queued for the remote computer. The string shown here specifies that your computer may send the work that is queued for the remote computer as long as it logged in as one of the names in the LOGNAME option: SENDFILES=yes This string is mandatory if your computer is in a “passive mode” with respect to the remote computer. The string that follows specifies that files queued in your computer will be sent only when your computer calls the remote computer: SENDFILES=call The call value is the default for the SENDFILE option. This option is significant only in LOGNAME entries, because MACHINE entries apply when calls are made to remote computers. If the option is used with a MACHINE entry, it will be ignored.
READ and WRITE		These options specify the various parts of the filesystem that uucico can read from or write to. The READ and WRITE options can be used with either MACHINE or LOGNAME entries. The default for both the READ and WRITE options is the uucppublic directory, as shown in the following strings: READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic These strings specify permission to access any file that can be accessed by a local user with “other” permissions: READ=/ WRITE=/ Because this suggestion may compromise security, use it only if required. The value of these entries is a colon-separated list of pathnames. The READ option is for requesting files, and the WRITE option for depositing files. One of the values must be the prefix of any full pathname of a file coming in or going out. To grant permission to deposit files in /usr/news as well as in the public directory, the following values would be used with the WRITE option: WRITE=/var/spool/uucppublic:/usr/news Note that if you use the READ and WRITE options, you must specify all pathnames because the pathnames are not added to the default list. For instance, if the /usr/news pathname were the only one specified in a WRITE option, permission to deposit files in the public directory would be denied. You should be careful which directories you make accessible for reading and writing by remote stations. For example, you probably wouldn't want remote computers to be able to write over your /etc/passwd file, so /etc shouldn't be open to writes.
NOREAD and NOWRITE		The NOREAD and NOWRITE options specify exceptions to the READ and WRITE options or defaults. The strings shown here would permit one remote computer to read any file except those in the /etc directory (and its subdirectories—remember, these are prefixes) and to write only to the default /var/spool/uucppublic directory: READ=/ NOR EAD=/etc WRITE=/var/spool/uucppublic NOWRITE works in the same manner as the NOREAD option. NOREAD and NOWRITE can be used in both LOGNAME and MACHINE entries.
CALLBACK		The CALLBACK option is used in LOGNAME entries to specify that no transaction will take place until the calling station is called back. You would use CALLBACK for two reasons: From a security standpoint, if you call back a station you can be sure it is the station it says it is. If you are doing long data transmissions, you can choose the station that will be billed for the longer call. The string that follows specifies that your computer must call the remote computer back before any file transfers will take place: CALLBACK=yes The default for the CALLBACK option is CALLBACK=no The CALLBACK option is very rarely used. Note that if two sites have this option set for each other, a conversation cannot be started.
COMMANDS		The COMMANDS option can be hazardous to the security of your station. Use it with extreme care. The uux program generates remote execution requests and queues them to be transferred to the remote computer. Files and a command are sent to the target computer for remote execution. The COMMANDS option can be used in MACHINE entries to specify the commands that a remote computer can execute on your computer. Note that COMMANDS is not used in a LOGNAME entry; COMMANDS in MACHINE entries defines command permissions, whether you call the remote station or it calls you. This string indicates the default commands that a remote computer can execute on your computer: COMMANDS=rmail If a command string is used in a MACHINE entry, the default commands are overridden. For instance, in the following example, the entry overrides the COMMANDS default so that the computers eagle, owl, and hawk can now execute rmail and rnews on your computer: MACHINE=eagle:owl:hawk REQUEST=yes COMMANDS=rmail:/usr/bin/rnews READ=/ WRITE=/ In addition to the names as specified above, there can be full pathnames of commands. For example, this line specifies that command rmail use the default path: COMMANDS=rmail:/usr/bin/rnews:/usr/local/lp The default paths for your computer are /bin /usr/sbin, /usr/bsd, and /usr/bin. When the remote computer specifies rnews or /usr/bin/rnews for the command to be executed, /usr/bin/rnews is executed, regardless of the default path. Likewise, /usr/local/lp is the lp command that is executed. Note: Including the ALL value in the list means that any command from the remote computer(s) specified in the entry is 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. This string illustrates the greater access: COMMANDS=/usr/bin/rnews:ALL:/usr/local/lp Two points about this string should be noted. The ALL value can appear anywhere in the string, and the pathnames specified for rnews and lp will be used (instead of the default) if the requested command does not contain the full pathnames for rnews or lp. The VALIDATE option should be used with the COMMANDS option whenever potentially dangerous commands like cat and uucp are specified with the COMMANDS option. Any command that reads or writes files is potentially dangerous to local security when executed by the UUCP remote execution daemon (uuxqt).
VALIDATE		The VALIDATE option is used in conjunction with the COMMANDS option when specifying commands that are potentially dangerous to your computer's security. It is used to provide a certain degree of verification of the caller's identity. The use of the VALIDATE option requires that privileged computers have a unique login and password for UUCP transactions. An important aspect of this validation is that the login and password associated with this entry be protected. If an outsider gets that information, that particular VALIDATE option can no longer be considered secure. (VALIDATE is merely an added level of security on top of the COMMANDS option, though it is a more secure way to open command access than ALL.) Give careful consideration to providing a remote system with a privileged login and password for UUCP transactions. Giving another system these privileges is like giving anyone on that computer a normal login and password on your computer. Therefore, if you cannot trust everyone at the remote site, do not provide that system with a privileged login and password.
LOGNAME		The LOGNAME option ensures that remote stations attempting to log in to your computer have login privileges. The following LOGNAME entry specifies that if one of the remote computers that claims to be eagle, owl, or hawk logs in to your computer, it must have used the login uucpfriend: LOGNAME=uucpfriend VALIDATE=eagle:owl:hawk As can be seen, if an outsider gets the uucpfriend login and password, marauding is trivial. But what does this have to do with the COMMANDS option, which appears only in MACHINE entries? It links the MACHINE entry (and COMMANDS option) with a LOGNAME entry associated with a privileged login. This link is needed because the execution daemon is not running while the remote computer is logged in. In fact, it is an asynchronous process with no knowledge of which computer sent the execution request. Therefore, the real question is, how does your computer know where the execution files came from? Each remote computer has its own “spool” directory on your computer. These spool directories have write permission given only to the UUCP programs. The execution files from the remote computer are put in its spool directory after being transferred to your computer. When the uuxqt daemon runs, it can use the spool directory name to find the MACHINE entry in the Permissions file and get the COMMANDS list or, if the computer name does not appear in the Permissions file, the default list is used. The following example shows the relationship between the MACHINE and LOGNAME entries: 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=/ The value in the COMMANDS option means that remote mail and /usr/bin/rnews can be executed by remote users. In the first entry, you must make the assumption that when you want to call one of the computers listed, you are really calling either eagle, owl, or hawk. Therefore, any files put into one of the eagle, owl, or hawk spool directories is put there by one of those computers. If a remote computer logs in and says that it is one of these three computers, its execution files will also be put in the privileged spool directory. You therefore have to validate that the computer has the privileged login uucpz.
MACHINE Entry for “Other” Systems		You may want to specify different option values for computers your computer calls that are not mentioned in specific MACHINE entries. This situation may occur when there are many computers calling in, and the command set changes from time to time. The name OTHER for the computer name is used for this entry: MACHINE=OTHER \ COMMANDS=rmail:rnews:/usr/bin/Photo:/usr/bin/xp All other options available for the MACHINE entry may also be set for the computers that are not mentioned in other MACHINE entries.
Combining MACHINE and LOGNAME Entries		It is possible to combine MACHINE and LOGNAME entries into a single entry where the common options are the same. For example, the two entries that follow share the same REQUEST, READ, and WRITE options: MACHINE=eagle:owl:hawk REQUEST=yes \ READ=/ WRITE=/ LOGNAME=uucpz REQUEST=yes SENDFILES=yes \ READ=/ WRITE=/ These two entries can be merged: MACHINE=eagle:owl:hawk REQUEST=yes \ LOGNAME=uucpz SENDFILES=yes \ READ=/ WRITE=/
MYNAME		The MYNAME option is used to override the name of the local computer, when the local computer identifies itself to the remote computer. This facility is useful when a computer is replaced or renamed, and its neighbors need to process old traffic to the old name.

To ensure proper security and access, you need to ensure that the user entries for uucp and nuucp are both present and correct. The uucp entry in the passwd file is for ownership purposes, and the nuucp entry is for remote UUCP access. Ensure that your password file has both entries and that they are the same as the following example. If the uucp and nuucp entries don't match the following, edit those accounts so they do match.

uucp:*:3:5:UUCP Owner:/usr/lib/uucp:/bin/csh
nuucp::10:10:Remote UUCP User:/var/spool/uucppublic:/usr/lib/uucp/uucico

In the above example, the passwd entry for nuucp is split across two lines due to formatting constraints. In the actual file, the entry appears on a single line.

On a newly installed station, neither uucp nor nuucp has a password. It is a good idea to put an asterisk (*) in the password field for uucp, because no one should log in as uucp. You need to assign nuucp a valid password that matches the password you assign for nuucp in the Systems file. (See “UUCP Systems File”. For example, assign nuucp the password “secret.”)

New password: secret 
Re-enter new password: secret 

Check this file to ensure that there are valid groups for both uucp and nuucp. Compare your uucp and nuucp group entries with the following. If there is a discrepancy, correct it now.

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, any time you make a change to the /etc/inittab, you must tell init to read the file again with the telinit q command. Enter the following command:

/etc/telinit q 

The Systems file contains information describing the station(s) that the local station knows about. Add the following line to the bottom of the file:

us Any systemx 9600 unused ogin:--ogin: nuucp ssword: \ secret

---

Note: The Systems file is read only, so if you are using vi you must force this change to be written out by exiting vi with the :wq! option.

---

The first field specifies the name of the station that can call (the remote station). The second field indicates that the specified station can call at any time. The third field tells uucp the name of the device to use (systemx). The third field must match one of the first field entries found in /etc/uucp/Devices. The fourth field specifies the transfer speed (9600). The fifth field is normally used for a phone number, but unused for direct links. The rest of the line handles the login sequence; it is the chat script negotiated between the local station and the remote station. This chat script is very important for a successful uucp connection.

The Devices file contains information about the physical connection between the two stations. Remove the pound sign from the systemx device entry so it looks like the following:

# ---A direct connection to a system
systemx ttyf2 - Any direct

---

Note: If you have another direct connection to a station on another port, copy the systemx device entry and modify the port number accordingly.

---

The first field in the Devices file links the device to the Systems file (third field entry). The second field tells uucp which port to access. The third field is used with an Automatic Call Unit (ACU). Direct links use a dash in the third field. The fourth field specifies the line speed. The “Any” entry allows the speed to be determined by the /etc/inittab file for that particular device. The fifth field contains the dialer name. It must be a valid entry in the /etc/uucp/Dialers file.

This file contains the chat script for the uucp device. Because this is a direct connection, the chat script is picked up from the Systems file. However, there still has to be a valid dialers entry for the direct connection. Verify that the Dialers file has an entry for the “direct” dialer. Enter the following command:

grep direct /etc/uucp/Dialers

The system responds with

direct
#   The following entry is for use with direct connections
uudirect ""   "" \r\d in:--in:

The Permissions file controls remote uucp access with regard to remote users and stations. (See “UUCP Permissions File”, for descriptions of all of the options.) For this example, edit the Permissions file to look like the following:

#dent"@(#)uucp:Permissions2.2" 
# This entry for public login. 
# It provides the default permissions. 
# See the Basic Networking Utilities Guide for more information. 
LOGNAME=nuucp MACHINE=us READ=/var/spool/uucp/uucppublic \ 
WRITE=/var/spool/uucppublic REQUEST=yes SENDFILES=yes \ 
COMMANDS=rmail 

---

Note: This entry must be interpreted as a single line, even if it exceeds more than one physical line.

---

This entry specifies that the user, nuucp, is allowed to log in from the remote station (us). The nuucp user on us may read any files that reside in /var/spool/uucp/uucppublic directory and write to the general public directory /var/spool/uucppublic. The users on us may make requests. Users on japan can send files.

To ensure proper security and access, you need to ensure that the user entries for uucp and nuucp are both present and correct. The uucp entry in the passwd file is for ownership purposes and the nuucp entry is for remote UUCP access. Ensure that your password file has both entries and that they are the same as the following example. If the uucp and nuucp entries don't match the following, edit them so they do match:

uucp:*:3:5:UUCP Owner:/usr/lib/uucp:/bin/csh
nuucp::10:10:Remote UUCP User:/var/spool/uucppublic:/usr/lib/uucp/uucico

On a newly installed station, neither uucp nor nuucp has a password. It is a good idea to put an asterisk (*) in the password field for uucp, because no one should log in as uucp. You need to assign nuucp a valid password that matches the password you assign for nuucp in the Systems file. (See “UUCP Systems File”.) Assign nuucp the password “secret” with this command:

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, any time you make a change to the /etc/inittab, you must use the telinit q command to tell init to read the file again. Enter the following command:

/etc/telinit q 

The Systems file contains information describing the station(s) that the remote station knows about. Add this line to the bottom of the Systems file:

japan Never 

---

Note: The permission of the Systems file is read only. If you edit this file, you may have to use a forced write in order to save your changes. Consult the jot or vi reference page for more information.

---

The first field specifies the name of a station that can call the local station. The second field indicates the times this station can make the call. The value Never in this field indicates that this station may receive calls, but never initiate them.

The Permissions file controls remote uucp access with regard to remote users and stations. (See “UUCP Permissions File”, for descriptions of all the options.) For this example, edit the Permissions file to look like the following:

#ident"@(#)uucp:Permissions2.2" 
# This entry for public login. 
# It provides the default permissions. 
# See the Basic Networking Utilities Guide for more 
                                                 information. 
LOGNAME=nuucp MACHINE=japan READ=/var/spool/uucp/uucppublic\ 
WRITE=/var/spool/uucppublic REQUEST=yes SENDFILES=yes \ 
COMMANDS=rmail 

---

Note: This entry must be interpreted as a single line, even if it expands to more than one physical line.

---

This entry specifies that the user, nuucp, is allowed to log in from the local station (japan). The nuucp user on japan may read any files that reside in /var/spool/uucp/uucppublic directory and write to the general public directory /var/spool/uucppublic. The users on japan may request files. The users on us can send files.

The cu program is used to test the basic functionality of the UUCP connection. When you use cu directly, you are performing the login process as if you were the uucp programs. The cu command is also used for direct modem connections for terminal emulation. The -d option to cu is used for diagnostics and causes traces of information to be printed out to the standard output (your shell window). You should always use this mode when testing a UUCP connection.

The cu command tests the physical connection to the remote station, UUCP configuration files, operating system files, and the uucico daemon on the remote station.

---

Note: The default permissions on devices (/dev/ttyf2) are set to 622. For cu to access your device, you need to change the permissions to 666.

---

Uutry is the program that tests the copy-in/copy-out program (uucico). uucico must be functioning properly before you can actually transfer data. Enter the Uutry command from the local station (japan) to the remote station (us):

/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.