The UUCP Systems Data

To enable the start of the uugetty program on the System V platform during the system startup, the etcinittab table should include a corresponding UUCP entry like this one: uu:2:respawn:usrlibuucpuugetty −r tty07 19200 where r option tells uugetty to wait to read for a character before putting up a login prompt tty07 is the supposed serial port terminal line 19200 is a modems speed uugetty is a common replacement for the getty program to enable the bidirectional communication required by UUCP over the corresponding serial line. However, this is not a must; on Solaris 2.x the regular terminal line monitoring program ttymon is smart enough to know how to handle the UUCP related bidirectional communication. Solaris 2.x does not even provide the program uugetty.

24.6.2 UUCP Configuration Files

Once a serial link has been set, a number of other configuration and description data must also be provided. These data define the UUCP behavior on the system and are located in the several UUCP configuration files. Two examples follow. ls −C etcuucp HP−UX 10.20 Devices Dialers Maxuuxqts Poll Dialcodes Maxuuscheds Permissions Systems ls −C etcuucp Solaris 2.x Config Dialcodes Limits Sysfiles Devconfig Dialers Permissions Systems Devices Grades Poll remote.unknown

24.6.2.1 The UUCP Systems Data

First, the appropriate configuration data about assumed remote systems hosts should be provided: A remote system name • Convenient time to call • Phone number of attached remote modem • UUCP login name on the remote system • UUCP password on the remote system • Both sides in a UUCP communication need these data, and they always relate to the remote system on the other side. If we recall the example from the beginning of this section, we can easily recognize these configuration data. The data are placed into the UUCP systems configuration file: Systems on BNU UUCP or L.sys on Version 2 UUCP. An entry in the file describes one link; multiple links with the same system are described with multiple entries. The generic format of an entry is: sys_name schedule device_type speed phone_number chat_script where 613 schedule The time schedule when the local system can call the remote one: Any the system can call on any day Never the system should never call but should just wait to be called Wk any weekday any weekday could be also specified: Su, Mo, Tu, We, Th, Fr, and Sa; the time subfield is specified by two 24−hour clock times separated by a dash: 1900–2300 specifies time between 7 and 11 p.m device_type The type of a device to be used for the call: ACU for Automatic Call Unit ttynn for direct links ttynn is the name of a special device file in the dev directory TCP for TCPIP connection the port for uucp service is specified in the etcservices file speed The speed in bps for a device some systems also allow the speed range. phone_number The dialer sequence to be used by the modem to call the remote system. chat_script A string describing the initial conversation between two systems. More details follow. The chat_script presents a text string of the remainder of the entry, after the phone_number. It consists of expect−send pairs, separated by spaces, with optional subexpect−subsend pairs separated by hyphens, as in the following example: The expect and subexpect fields specify literally what the system expects to receive from the remote system. This is the reason why loginpassword expect fields are specified as ogin: and ssword:. These words are sufficient for unique loginpassword identification and also cover a number of possible Login: and Password: prompting from the remote system; they even allow the additional leading text. By the way, the subsend field BREAK enables adjustment of the modem speed between two systems of course if the device supports it — see Chapter 11, Terminals. When uucico is invoked, it scans the UUCP systems configuration file for the name of the system to call, as well as for a valid time to call. If it is a time to call, it checks the device type and speed fields, and other device−related configuration data. The next step is to check for locked files for that device type in the spool directory; if locked files exist, it means this device type is already in use. Then, uucico checks if there is another device of the requested type and speed to use it. If no device is available, uucico returns to the UUCP system configuration file to see if there is another configuration entry for the same system. If not, the call is terminated and postponed until later.

24.6.2.2 The UUCP Devices Data