This document is an aid to understanding the UUCP (BNU) configuration files on your RISC System/6000. BNU (Basic Networking Utilities) is the AIX version of UUCP (UNIX-to-UNIX Copy Program). The terms "BNU" and "UUCP" are used interchangeably in this document. This document applies to AIX 3.1 and 3.2.
You can use the /usr/lib/uucp/uucpadm command to initially set up the files, and then edit them to suit your exact needs.
The following information describes the Systems, Permissions, Devices and Dialers files and the fields within them.
The /usr/lib/uucp/Systems file contains the primary information that is used by the "uucico" program (which will be described later in this guide) to connect to the various systems. Consider this file the "database" of systems to which your machine can connect. In this file you will find entries of the format:
system_name Call_time Device speed phone_no. "login_sequence" | | | | | | | | | | ------------> "Chat script" | | | | | | | --> Bits per second | | | (for serial lines only) | | | | | ----> The name of a device found in the | | BNU "Devices" file. | | | ----> The "Time of Day" that calls out may be tried | from your system to the system "system_name". | ----> The name that the remote system returns when the command "uuname -l" is issued from a shell prompt.
Note: The remote system will not be allowed access to your machine (and your machine will not be allowed access to the remote machine) if system_name does not match the output of uuname -l - this will be explained later.
system_name
This name is a "handle" that the BNU caller program (uucico) uses to associate the remote system to the dial-up and login information in your "Systems" file. When you read through a complete "Systems" file entry on your machine, you will see that it contains basically all the information you need to call a specific system and log in as a specific user. When uucico calls the remote system, it will actually log in (like any other user) into a specially set up account that will invoke as its login shell "uucico". When the remote system invokes "uucico" it will present its "uuname" to the calling host (your machine in this case). That "uuname" will need to match the name you gave the remote system in your "Systems" file. If they do not match, your system will say "WRONG MACHINE NAME" and the call will fail.
Call_time
This field indicates when your machine can call out to the specified remote site. Normally (for testing), this entry will simply read "Any", which means "I can call this system 'Any' time of the day." Other valid entries are "Never", day of the week in the format "MoTuWeThFrSaSu", weekdays only (indicated by "Wk"), time of day (specified by 24 hour times ("1800" (6:00pm) or "0800" (8:00am)), and time of day specified by ranges such as 0600-1800. (Ranges of times such as this must be preceded by a day specification, such as "Any0600=1800" or "Mo0600-1800".) Read the IBM documentation for more specific usage information on this entry.
Device
This is the name of a device that is listed in the BNU "Devices" file. Only seven significant characters will be used, and the named device must exist in the devices file. There are no other restrictions on the name. If you do not wish to use the devices file, "-" indicates a valid "NULL" device.
Speed
This is the connection speed for serial line communications. If you are using a direct-connect serial line (no modems, just one box connected serially to the other) or modem lines, this field is required. If you are using a "TCP" connection device type (a special "Devices" file type), this field should be a "-".
Chat script
The phone_no and login_sequence are the heart of all BNU Systems file entries. The UUCP "chat utility" is what allows your machine to log in to other systems and start a BNU connection without your intervention. This sequence is broken up into "send" and "expect" fields. For every send, there is a corresponding expect (until the last one). Basically it works like this: "I send", "the other end responds", "I send", "the other end responds", and so on, until I am logged in. Think about it as: "What would I type, and what would the modem and/or the remote system respond if I were going to log in to the remote system?" Normally this sequence starts with the phone number of the remote system (if the remote system is to be connected over a modem) and is then followed by the sequence used to log in to the remote system. The login sequence will look something like:
in:--in: <username> word: <password>
The login sequence usually begins: "in:--in:" which is the last three digits in the "login:" prompt separated by "--" which is used to signify, "If I do not get this within my default time-out period, send the characters between the "-"s plus a "carriage return" and then wait for "in:" again. In the following example, we wait for "in:" and if we do not see it, send "hello" and wait for "howdy:" in response:
in:-hello-howdy:
(Of course, such a sequence would probably never be used, but the emphasis is what role the "-<string>-" sequence plays in the "expect" portion of the chat sequence.)
The next part of the chat sequence is usually the "username" of the remote site's uucp account. This can be any login account the remote system administrator wants to set up to do uucp, but the default program that it calls must be uucico. Some sites accomplish this by creating a normal user and making the first line of the user's .profile call uucico, but that is risky at best. The default directory of this user is usually /usr/spool/uucppublic, but it not a requirement.
The next part of the chat sequence is the expect "word:" which is the last five characters of the "password:" prompt. If the remote system were to say "Enter your secret code:" instead of prompting for the "password:", this entry would be "code:" in the chat sequence.
The last entry in the chat sequence is usually the actual password of the account you will be using for uucp on the remote system. This entry should result in a completed login and direct access to the uucico program. Some systems have two or more passwords per account, so you would simply add more 'expect - send' entries onto the chat sequence to account for the difference.
Note: For quickest setup, it is probably easiest to copy the existing sample entry in the "Systems" file and to replace the system name, phone number, and account specific information (login name and password) from this default entry.
The /usr/lib/uucp/Permissions file is used to create security control over machines attempting to communicate with your machine. (There are limitations, but they are usually subject to common sense.) This file has two distinct entries, and each does a different job; they are not related to each other.
The first entry in the Permissions file is the "MACHINE=" entry. This entry is used to establish the base permissions for a given sitename. It will follow the format:
MACHINE=system_name REQUEST=yes READ=/ WRITE=/ COMMANDS=cmd:cmd | | | | | | | | | | ------------- | | | | | | | | | v | | | | | | | | The commands that the | | | | remote uucico program | | | | may execute on your | | | | system. | | | | | | | --> The directories | | | (separated by ":"s) that | | | the remote system may write | | | to on your system. | | | | | --> The directories (separated by ":"s) | | that the remote system may read on | | your system. | | | --> A "yes/no" toggle that indicates whether the | remote system may "REQUEST" that work files | be transfered (REQUEST=yes) or if it must wait | for your local system to initiate the request | (REQUEST=no). | --> The names of systems (separated by ":"s) that will have the same dial in/out parameters (as listed by the rest of that line). This name must match a name in the "Systems" file.
READ=/usr/spool/uucppublic:/tmp
The other type of line in the Permissions file is used to establish the permissions for the login account that the remote system is using. Several of the fields for this line are the same as the "MACHINE=" fields of the same name. The primary difference is that these entries are specific to the login account that the remote system is using, where the "MACHINE=" fields are specific to the remote system's uuname. The "LOGNAME=" line has the format:
LOGNAME=username REQUEST=yes SENDFILES=yes READ=/ WRITE=/ | | | | | | | | ---------> Same as the MACHINE | | | entry from this | | | file. | | | | | --> Can be "yes" or "call" and is used | | to indicate when the local system | | is allowed to send files to the | | remote system. | | | --> Same as the MACHINE entry for this file. | --> The usernames (separated by ":"s) that remote systems will use to login on your machine.
The /usr/lib/uucp/Devices file is used by several programs (including uucico) to determine which device on your system to use for a given connection attempt. The "cu" program uses entries in this file for "Direct" access to the tty port, serial line IP (SLIP) uses the Devices file for determining access to a tty for TCP/IP connections over serial line, and ECS (the IBMLINK connection facility) uses the Devices file to make modem connections to IBMLINK. As you can see, this file is very useful for many programs across the system. Its basic purpose is to define the device type, location, speed, and other basic communication parameters for the dial-out programs (it is only used for dial-out connections). In this file, you will see lines of the format:
device_name connection_port - speed dialer token | | | | | | | | | | | --> Determines whether the | | | | | "/usr/lib/uucp/Dialcodes" file | | | | | will be used with the phone | | | | | number string that is in the | | | | | "Systems" file. Possible | | | | | entries are "\T" and "\D" | | | | | or blank (which defaults to | | | | | "\D"). | | | | | | | | | --> The name of the entry from the | | | | "/usr/lib/uucp/Dialers" file to use. | | | | Normally set to "hayes" for modern | | | | modem use. | | | | | | | --> The speed of serial connections (in bits- | | | per-second). Will be "-" if the connection | | | is through TCP and can be "Any" if any | | | speed is supported by the communication | | | device. | | | | | --> Usually called "line2", this is the entry that | | was used (in the "old" days) for the Automatic | | Calling Unit (ACU). The "old" style modems | | could not dial the telephone, so they had an | | ACU dial for them and then connect the phone | | line to the "connection_port". | | | --> The physical port name of the outgoing connection. This | will be "-" for a TCP connection but is usually the | tty name of the port with the modem attached. | --> The name you have chosen for the dial-out device. For modems, a semi-standard has evolved to call this "ACU", but you can call the device by any name. This name is the same one that you used in the 3rd field of the "Systems" file entry (called "Device_name" earlier in this guide).
hayes, penril, ventel, rixon, vadic, micom, TCP, and direct
Each "dialer" specifies a different command set to use when attempting to dial the modem. For the most part, you will only be interested in three dialers: h ayes, direct, and TCP. The "hayes" dialer is the standard command set used by most modems. If they have their own command set, they will usually also recognize the hayes "AT" command set. The "direct" dialer is really only a "dummy" dialer, in that it does not specify any command set (because it is used for connections that do not usually have a modem attached). The "TCP" dialer is effectively the same as the "direct" dialer, but it is a keyword that the TCP/IP UUCP connections look for when making a call.
Danny Any ACU 9600 9,15551111 "" \d\d\d\r in:--in: uucp word: uucp
ACU tty0 - Any hayes \D
hayes =, -, "" \dAT\r\c
MACHINE=Danny REQUEST=yes READ=/ WRITE=/ COMMANDS=ALL
LOGNAME=uucp REQUEST=yes SENDFILES=yes READ=/ WRITE=/
Systems file: <System_name> Any ACU 9600 9,1512-555-1111 Devices file: _______________/ / ACU tty0 - Any hayes \D Dialers file: ______________________/ / hayes =, -, "" \dAt\r\c OK ATDT\T\r\c CONNECT....
With bidirectional ports, when the remote port is set for "delay" or "getty -r" and the chat script expects key input, you may find that ports set for "delay" are expecting one or more carriage returns before proceeding with the login. If this is the case, try beginning the chat script on the dialing system with the following:
""\r\d\r\d\r\d\r in:--in: ...
Interpreted, the above reads: expect nothing, send return, delay, return, delay, return, delay, return.