Serial Line−Related Issues

• Create entries in the Systems or L.sys file that describes when and how to reach other UNIX systems. • Create entries in the Devices or L−devices file that describes communication devices hardware issues. • For modems unknown to the system, create dialing instructions. • Apply security mechanisms. • Some systems provide menu−driven installation utilities that make the task easier. However, the discussion that follows assumes managing from the command line.

24.6.1 Serial Line−Related Issues

The baseline of the UUCP network is a physical communication link; a proper communication link is a basic requirement for UUCP to work at all. Until the link has been established, nothing else matters. There are three types of communication links: Direct hardwired RS−232 link 1. A modem used via telephone line 2. A network TCPIP 3. When a direct or a modem communication link is in question, they both relate to the systems serial lines; from the UNIX standpoint, they target the serial ports. UNIX addresses serial ports, as any other device, via the corresponding special device files special device files point further to the corresponding drivers that are parts of the kernel. For the serial ports, these are terminal−related device files, specified as devttynn where nn identifies the ports number. Basically, it was supposed to use serial ports to connect the systems terminals, to provide regular users communication with the system. The getty program has monitored the serial lines and started a login process as soon as it detected any activity on the line. When it happened, the getty program would immediately send back the login prompt and exec the login program to continue the login process. Such an approach seems to be OK if only a terminal could be at the other side of the serial line, and the only possible sender is a user who wants to log in to the system. However, for another kind of communication which is not login related, the gettys behavior seems to be an obstacle. Actually, it is appropriate for getty to monitor dial−in lines; but for dial−out lines, getty should be disabled. This is the well−known problem with serial lines monitored by the getty program, when they are not used for an exclusive login into the UNIX system. However, to realize a different bidirectional serial communication, the alternatives are: Use two ports one for in and the other for out • Use a single port in two ways • In both cases, additional administrative work must be done. UUCP assumes the second approach. BNU UUCP provides a bidirectional program called uugetty an improved version of the getty program that could be used instead of getty. The uugetty program is wise enough not to respond with a login prompt when the line is in use for outgoing 612 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