unx43.htm

Unix Unleashed, Third Edition is written with the power user and system administrator in mind. This

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="caution.gif" WIDTH = 37 HEIGHT = 35><B>CAUTION: </B>Permissions to see the UUCP chat scripts should be restricted. One of the limitations of UUCP is that the remote machine passwords must be listed in the chat script and must be clear ASCII text. 

Anyone with the correct permissions can look at the file and steal the passwords for UUCP. None of the passwords indicated in this chapter are real.

<BR></NOTE>

<HR ALIGN=CENTER>

<H5 ALIGN="CENTER">

<CENTER><A ID="I9" NAME="I9">

<FONT SIZE=3><B>Connection Files</B>

<BR></FONT></A></CENTER></H5>

<P>The first task of uucico is to determine the target machine for the connection. When it determines the machine name, it examines the Systems file. This includes the system name, the connect times, devices, and speeds, the connection address, and the 
chat script to make the connection. This is not enough to make the connection.

<BR></P>

<P>Given the device type and speed, uucico must next examine the Devices file. This provides a list of devices and speeds, and associates them with actual ports and dialers to connect with those ports.

<BR></P>

<P>The dialers to connect to the port need to be looked up in the Dialers file, where a specific dialer can be associated with a chat script. That chat script should set up the modem in the proper format, and then dial the address provided by the Systems 
file. Sometimes, this address may need further expanding. The Dialcodes file provides some expansion for the address.

<BR></P>

<P>Addresses need not be telephone numbers. UUCP is capable of handling telephone calls via modems, as well as connections via local area networks such as Starlan, and even direct connections between machines. Each one requires different devices and dialer 

chat scripts to make the connection.

<BR></P>

<H3 ALIGN="CENTER">

<CENTER><A ID="I10" NAME="I10">

<FONT SIZE=4><B>Setting Up UUCP</B>

<BR></FONT></A></CENTER></H3>

<P>UUCP requires two sites willing to set up a connection. In the early days of UNIX, this was simply a matter of calling local UNIX sites and asking if they would be willing to transfer data for you. In those days, often the answer was yes, and you'd set 

up a link. With the development of the Internet, these connections are becoming less frequent, and many main sites no longer even use UUCP.

<BR></P>

<P>For my home machine, I sought a service provider. The local provider with a decent reputation was Netcom, based in the San Francisco Bay area. Netcom offers a UUCP service for a reasonable amount each month, including registering a domain name for 
Internet addressing. Netcom is not the only provider, but it's local for me.

<BR></P>

<P>When you've found a partner for exchanging UUCP, you'll need to determine how the connections will be made. There are three options: Your site could make all the calls to the provider's site (this is fairly standard with paid service providers), your 
site could receive calls only from the remote site, or the calls could go both ways. This results in two different administrative tasks for UUCP: setting up your system to receive calls and setting up your system to place calls.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I11" NAME="I11">

<FONT SIZE=3><B>Receiving UUCP Calls</B>

<BR></FONT></A></CENTER></H4>

<P>Since UUCP accesses a system in the same way as a user&#151;by logging in&#151;you'll need to set up your system to allow UUCP to log in. One of your serial ports will need a modem attached. One action you'll need to take is to establish an account for 

UUCP to use. You'll need to use your administrative tools to edit the /etc/passwd file. You'll need root permissions to create the account. Some UNIX systems come with a default entry, nuucp, for UUCP connections. I prefer to set up a different account for 

each machine, prefixing the machine name with a U. That way I know just by using the who command who is logging in to transfer data at what times.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="imp.gif" WIDTH = 68 HEIGHT = 35><B>TIP: </B>Prefixing UUCP accounts with U also increases the administrative trail of user logins; although UUCP does give excellent logs, by keeping different login names the /etc/wtmp file will also keep a record 

that can identify call times and durations.

<BR></NOTE>

<HR ALIGN=CENTER>

<P>The /etc/passwd entry should have the same owner and group as your uucp account. This way, the remote site will be able to write correctly to the designated files; UUCP does not run in any privileged mode&#151;it is just another user on the system. You 

should also make the home directory /var/spool/uucppublic. This directory is a standard UNIX directory, designated for file transfers. It should be owned by uucp, it should be of group uucp, and it should have permissions set to 777. That way, any user 
desiring to transfer files can write to the directory.

<BR></P>

<P>The unique aspect of the /etc/passwd entry is the default shell. Most users will have something like /bin/sh, /bin/csh, or some other command shell. Your UUCP entry should have /usr/lib/uucp/uucico, which is the command for data transfer. This means 
that when your UUCP successfully logs in, it will immediately start to transfer files.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B> You may have noticed that the same transfer command is used both for sending and receiving data. So how do you know which is which? It's simple&#151;you don't. The same uucico command will both send 
and receive files during a single phone call. The two commands stay synchronized because of the master/slave role. The command that is sending is considered the master, the command receiving is the slave. The slave role is the default. To be the master 
uucico, the uucico command must receive the flag -r1. Master and slave roles can switch during a phone call, and there is no limit to the number of times this switch happens.

<BR></NOTE>

<HR ALIGN=CENTER>

<P>You will also need to set a password for the UUCP account. To do this, you need to be root. Run the passwd command on the account and enter a password. After you have done this, you can notify the other site of its UUCP account and password.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="imp.gif" WIDTH = 68 HEIGHT = 35><B>TIP: </B>For the password you can use any combination of characters that are valid, and because this is not one you'll need to keep memorized, it can be any random sequence desired.

<BR></NOTE>

<HR ALIGN=CENTER>

<P>This is not all that's needed to set up the connection, however. You'll need to run the command that gives the UNIX prompt, /etc/getty. This command is kept in the file /etc/inittab. You'll need to include an entry that looks like this:

<BR></P>

<PRE>ucp:23:respawn:/etc/getty ttya 9600</PRE>

<P>Each field is separated by colons, so this has four fields. The first is a unique identifier in the inittab and can be anything. The second field specifies run states, the third is an action, and the fourth is a command. This file is monitored by the 
init daemon. The respawn action indicates that when a command is finished, a new getty command should be run. The run states indicate that the command should be run only in multiuser mode.

<BR></P>

<P>getty is the standard UNIX command for providing a login prompt. The two arguments indicate which port is used and the expected speed. Here the modem is on ttya and is 9600 baud. Your port and numbers may be different. For more details on the inittab 
and getty, see the section &quot;Boot States.&quot;

<BR></P>

<P>There is a problem with getty: It can only receive calls. If you intend for your modem to have two-way traffic, you'll need to use the uugetty command. This command will know not to put up a login prompt when you are using the port to make outgoing 
calls. To use it, replace /etc/getty with /usr/lib/uucp/uugetty -r. The -r option tells uugetty not to put up a login prompt until it gets a character, which is usually a carriage return.

<BR></P>

<P>Permissions also need to be set, restricting what the calling system can do to your system. These will be covered later in the chapter, but for starters, consider restricting read and write access to /var/spool/uucppublic, and allow only the execution 
of rmail, and if you want netnews, rnews.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I12" NAME="I12">

<FONT SIZE=3><B>Initiating UUCP Calls</B>

<BR></FONT></A></CENTER></H4>

<P>Initiating UUCP connections is a proactive job. The simplest way to set up a system to make UUCP calls is for the administrator to modify a single file, the Systems file. This file contains the specific information needed to contact a remote system. 
Each line is a separate entry, and each line must have six entries. The first entry on a line is the remote system's name. UUCP expects the first seven letters to be unique, so the system names newyorkcity and newyorkstate would be considered the same. 
Each system can have any number of entries&#151;they are tried in the order found in the file, until one is successful.

<BR></P>

<P>The second field is a schedule field. Normally, the word Any will be here, meaning that the connection can be made at any time. Never means don't call; this entry is usually made when a system is polled; this means that a remote system will call to get 

what it wants. The schedule field Wk means weekdays only. A schedule field can be quite complicated. The schedule field can have an unlimited number of comma-separated schedule descriptions. Each description has a day code, an optional time code, and an 
option grade code. The day codes are easy to understand&#151;Su, Mo, Tu, We, Th, Fr, and Sa. Any number and combination can be present. So if you only want to call a site on Fridays, Saturdays, and Sundays, you'd have FrSaSu as the schedule field. The 
start time can be after the end time, which would seem to include midnight, but that is not true. Instead, it means from midnight on the specified days to the end time, and the start time to midnight on the same day. So Wk1900-0700 means any weekday before 

7 AM or after 7 PM.

<BR></P>

<P>Finally, the grade is a restriction on priority of transfers. By limiting the grade, only transfers of that grade or higher are made during that time. The grade is identified by a slash followed by a number or letter.

<BR></P>

<P>A full schedule specification may look like this:

<BR></P>

<PRE>SaSu,Wk0900-1700/C,Wk1700-0900</PRE>

<P>This means that transfers may occur at any time on Saturdays and Sundays, between 9 AM and 5 PM weekdays, only items grade C and above, and any time between 5 PM and 9 AM. This effectively says it's possible to transfer anything at any time except 
during work hours, when you move only priority material.

<BR></P>

<P>Finally, if a comma and number follow the schedule, this sets a minimum retry time. UUCP will make retry attempts based on its own internal formula, but that formula can be overridden in the schedule field.

<BR></P>

<P>The third field is the device field. This field is a lot simpler than the schedule field. It consists of a pointer to a device type. The devices are kept in the file Devices, usually in the same directory as Systems. UUCP will look up the device name in 

the Devices file and use the first free device found. The only option is that protocols may be specified after the device, preceded by a comma. Supported protocols include UUCP's g protocol for communication on a telephone line, as well as an x and an e 
protocol for devices that support those protocols.

<BR></P>

<P>The fourth field is the speed, or baud rate, of the connection. This is usually your modem's top speed, but different values may be present for different numbers, and different speeds also apply for direct connections.

<BR></P>

<P>The fifth field is the connection number. Usually it is a telephone number, but for UUCP connections over direct lines or for data switches, it is a connection address or path. For telephone numbers, it is the sequence of numbers needed to dial the 
remote modem. Note that an optional alphanumeric string can precede the phone number (this will be interpreted in the Dialcodes file).

<BR></P>

<P>The last field is the chat script. These are a sequence of text patterns that are expect/send pairs. The uucp command will read the data coming in from the remote site and attempt to match the expected text with the incoming text. When a match is found, 

the send text is transmitted with a new line, and a new expect pattern is found, until the entire chat script is completed. If successfully completed, the UUCP process starts; otherwise, an error is recorded and the connection is terminated.

<BR></P>

<P>Chat scripts can be filled with special character escapes. Table 43.1 shows Chat script escape sequences.

<BR></P>

<UL>

<LH><B>Table 43.1. Chat Script Escape Sequences.</B>

<BR></LH></UL>

<TABLE BORDER>

<TR>

<TD>

<PRE><I>Escape Sequence</I>

<BR></PRE>

<TD>

<PRE><I>Meaning</I>

<BR></PRE>

<TR>

<TD>

<P>&quot;&quot;</P>

<TD>

<P>Expect a null string</P>

<TR>

<TD>

<P>EOT</P>

<TD>

<P>End of transmission</P>

<TR>

<TD>

<P>BREAK</P>

<TD>

<P>Cause a break signal</P>

<TR>

<TD>

<P>\b</P>

<TD>

<P>Backspace</P>

<TR>

<TD>

<P>\c</P>

<TD>

<P>Suppress a new line at the end of the send string</P>

<TR>

<TD>

<P>\d</P>

<TD>

<P>Delay for one second</P>

<TR>

<TD>

<P>\K</P>

<TD>

<P>Insert a Break</P>

<TR>

<TD>

<P>\n</P>

<TD>

<P>Send a new line</P>

<TR>

<TD>

<P>\N</P>

<TD>

<P>Send a null</P>

<TR>

<TD>

<P>\p</P>

<TD>

<P>Pause for a fraction of a second</P>

<TR>

<TD>

<P>\r</P>

<TD>

<P>Carriage return</P>

<TR>

<TD>

<P>\s</P>

<TD>

<P>Send a space</P>

<TR>

<TD>

<P>\t</P>

<TD>