unx43.htm

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

<P>Send a tab</P>

<TR>

<TD>

<P>\\</P>

<TD>

<P>Send a backslash</P>

<TR>

<TD>

<P>\xxx</P>

<TD>

<P>Send the ASCII character with the octal value xxx</P></TABLE>

<P>A complete sample of Systems file entries is included here. Note that the sensitive data is changed, but reflects accurately my Systems file on sagarmatha.com:

<BR></P>

<PRE>machine1 Any ACU 9600 9899685 in:&#151;in: uduke word: mypass

mach Never ACU 9600 9895690 in:&#151;in: jca

tyler Any ACU 9600 5565935 &quot;&quot; \K\d\r :&#151;: mygate &quot;&quot; \d\d &gt;-\r-&gt;\

<BR> mylog &gt; rlogin\styler in:&#151;in: uduke word: Strange1</PRE>

<P>I have three machines registered. All are within my local area code. I have set the machine to never call mach. Instead, I use that as an entry for the cu command. Also note that both machine1 and tyler have given me the UUCP account name uduke.

<BR></P>

<P>The machine tyler is an interesting case. I have to go through a switch to reach that machine. The first expect says that I don't expect anything, so the machine immediately sends the control characters \K\d\r. This means send a break, wait a second, 
and send a carriage return. UUCP then expects a colon, and to access this switch, I enter mygate. I then need to wait two seconds, with \d\d, to get the &gt; character. I send mylog. I expect another &gt;, and I send rlogin tyler. Here, I begin a more 
recognizable login session.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B> In the early days of UNIX networking, the need for unique system names was great, as this was the only way to identify a machine for electronic mail and network news. As there was no registry, 
conflicts sometimes did occur. In the mid-1980s, I administered a machine named terminus while working for AT&amp;T. At one point, I started receiving some very odd mail to the administrative accounts; it turns out that somebody else, in Colorado, had 
named a system terminus. Once the problem was identified, the name conflict was resolved.

<BR>

<BR>Currently, the Internet has fully qualified domains, which separate our machines and networks. These domains are registered to prevent conflicts. My home machine is registered in the domain sagarmatha.com, but its UUCP name is duke. Because my service 

provider does not connect to Duke University or anyone else by this name, there is no name conflict.

<BR>

<BR>Interestingly, this is not the hostname. My UUCP machine at home has a hostname of krzyzewski, after Duke University's head basketball coach. Other machines at home have names of assistant coaches, amaker, gaudet, and brey. Because of the 
seven-character restriction on the UUCP name, I opted for duke, rather than abbreviating the hostname.

<BR></NOTE>

<HR ALIGN=CENTER>

<H5 ALIGN="CENTER">

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

<FONT SIZE=3><B>Testing the Connection</B>

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

<P>Once the Systems file is complete, you have to test the entry to see if the connection is actually being made, and if not, you need to figure out what is wrong. For this you use the command Uutry.

<BR></P>

<P>Uutry is a shell script that calls uucico with a debugging flag set, and then performs a tail on the output. You can press the Delete key any time to terminate Uutry. The default debug level is 5, but this can be changed with the -x option.

<BR></P>

<P>The example in Listing 43.2 shows what happens when the password is incorrect.

<BR></P>

<UL>

<LH><B>Listing 43.1. A failed UUCP call.</B></LH></UL>

<PRE>$ /usr/lib/uucp/Uutry machine1

/usr/lib/uucp/uucico -r1 -smachine1 -x5 &gt;/tmp/machine1 2&gt;&amp;1&amp;

tmp=/tmp/machine1

mchFind called (machine1)

conn(machine1)

Device Type ACU wanted

mlock ttya succeeded

processdev: calling setdevcfg(uucico, ACU)

gdial(tb9600) called

expect: (&quot;&quot;)

got it

sendthem (????????)

expect: (OK)

AT^M^M^JOKgot it

sendthem (DELAY

????????PAUSE

????????PAUSE

????????PAUSE

&lt;NO CR&gt;????????)

expect: (OK^M)

^M^JAAATE1V1X1Q0S2=255S12=255S50=6S58=2S68=2S7=80^M^M^JOK^Mgot it

sendthem (ECHO CHECK ON

&lt;NO CR&gt;?????????????????????????)

expect: (CONNECT 9600)

^M^JCONNECT 9600got it

getto ret 6

expect: (in:)

^M^Jsendthem (????????)

expect: (in:)

^M^Jmachine1 login:got it

sendthem (????????)

expect: (word:)

 uduke^M^JPassword:got it

sendthem (????????)

LOGIN FAILED - failed

exit code 101

Conversation Complete: Status FAILED</PRE>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B> Please note that a lot of what is sent is not visible to the user. This is not the case if Uutry is run as root. In that case, the send information, including the password, would be echoed in the 
parentheses. Because Uutry leaves files in /tmp, I prefer to use it with my own account and just use root to edit the administrative files.

<BR></NOTE>

<HR ALIGN=CENTER>

<P>You can only see what is echoed back to you&#151;your commands that are not echoed, such as your password, are not visible. By correcting the password in the Systems file and rerunning Uutry, you get the output in Listing 43.2.

<BR></P>

<UL>

<LH><B>Listing 43.2. A successful UUCP call.</B></LH></UL>

<PRE>$ /usr/lib/uucp/Uutry machine1

mchFind called (machine1)

conn(machine1)

Device Type ACU wanted

mlock ttya succeeded

processdev: calling setdevcfg(uucico, ACU)

gdial(tb9600) called

expect: (&quot;&quot;)

got it

sendthem (????????)

expect: (OK)

AT^M^M^JOKgot it

sendthem (DELAY

????????PAUSE

????????PAUSE

????????PAUSE

&lt;NO CR&gt;????????)

expect: (OK^M)

^M^JAAATE1V1X1Q0S2=255S12=255S50=6S58=2S68=2S7=80^M^M^JOK^Mgot it

sendthem (ECHO CHECK ON

&lt;NO CR&gt;?????????????????????????)

expect: (CONNECT 9600)

^M^JCONNECT 9600got it

getto ret 6

expect: (in:)

^M^J^M^Jmachine1 login:got it

sendthem (????????)

expect: (word:)

 uduke^M^JPassword:got it

sendthem (????????)

Login Successful: System=machine1

msg-ROK

 Rmtname machine1, Role MASTER, Ifn - 6, Loginuser - james

rmesg - 'P' got Pgetxf

wmesg 'U'g

Proto started g

*** TOP ***  -  role=1, setline - X

Request: duke!D.dukeb2ee40e &#151;&gt; machine1!D.dukeb2ee40e (james)

wrktype - S

 wmesg 'S' D.dukeb2ee40e D.dukeb2ee40e james - D.dukeb2ee40e 0666 james

rmesg - 'S' got SY

 PROCESS: msg - SY

SNDFILE:

-&gt; 835 / 0.972 secs, 859 bytes/sec

rmesg - 'C' got CY

 PROCESS: msg - CY

RQSTCMPT:

mailopt 0, statfopt 0</PRE>

<P>Another debugging tool is cu. This command also uses the UUCP files to try to connect to the remote machine, but when you are connected to the remote machine, cu terminates and you must complete the login yourself. This is very useful for debugging 
telephone numbers and Dialer scripts. Also, by using cu to connect to the modem itself, you can alter the modem parameters that may have been set incorrectly.

<BR></P>

<P>Another debugging tool is uucico. By calling uucico with the option -x and a single number, you will get output showing the steps for the UUCP call. This, however, cannot be interrupted, so you should use it sparingly.

<BR></P>

<H4 ALIGN="CENTER">

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

<FONT SIZE=3><B>More on Chat Scripts</B>

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

<P>Chat scripts are the heart of UUCP communication. The concept of a chat script is phenomenally simple&#151;read a port until you match a string, then send a response. It is found in two UUCP-related files, the Systems file and the Dialers file. The 
concept is rather portable, although it could have supported regular expressions for pattern matching.

<BR></P>

<P>Any number of expect/send pairs could be present. When attempting to navigate UUCP through a network of data switches to reach a destination, you may need a large number of pairs before you reach the login prompt.

<BR></P>

<P>The longer the chat script, the greater the chance that an error may occur. Normally, an error in the chat will result in the call failing; however, there are some error correction techniques. The uucico command will take a time-out after 30 seconds if 

an expected pattern is not seen. At that time, an alternate send sequence can be issued, and a new pattern expected. This alternate send is enclosed in dashes, with the new expect pattern following the second dash. There can be no spaces in this pattern, 
or UUCP will see it as a new member of an expect/send pair.

<BR></P>

<P>Often, this is seen with the login prompt and looks like this:

<BR></P>

<PRE>in:&#151;in:</PRE>

<P>This pattern means, wait for in:, and if it is not found, send a carriage return and wait again for in:. (Remember that each send pattern is followed by a carriage return, even if it is an alternate send.)

<BR></P>

<P>Another frequent alternate sequence is \K. Sometimes, when calling a modem that operates at multiple speeds, sending a break down the line will allow the modem to change its speed to match yours. When you see a sequence like this:

<BR></P>

<PRE>in:-\K-in:&#151;in:-\K-in:</PRE>

<P>there are four separate instances of an expected login prompt. If not found the first time, send a break, then a carriage return, then another break. Although this may look excessive, it is sometimes necessary.

<BR></P>

<H4 ALIGN="CENTER">

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

<FONT SIZE=3><B>Administering the Files</B>

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

<P>Besides the files already mentioned, there are six important UUCP files that need regular administration. They are the Devices, Dialers, Dialcodes, Permissions, Sysfiles, and Poll files. Each has its own format and usage.

<BR></P>

<H5 ALIGN="CENTER">

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

<FONT SIZE=3><B>Devices</B>

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

<P>The Devices file is just a list of the devices found on the system, with an identification of their use. The purpose of this file is to tie the device specification in the Systems file to a physical device with a known means of access. Each entry in the 

Devices file is a single line long, must start in the first column, and has five fields. The file permits comments, identified by the # character in the first column. It ignores lines with no entry in that column.

<BR></P>

<P>The first field is the device type. It must match exactly the device specified in the Systems file. Devices will be tried in order down the file until one is found to be available. This way, a system with multiple modems can have one entry in the 
Systems file. Some devices have standard identifiers. An <I>ACU</I> is an &quot;automated call unit,&quot; better known as a modem. direct signifies that the link to the device is a direct link.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B> For you to use cu -l, the line specified must have a direct entry in the Devices file.

<BR></NOTE>

<HR ALIGN=CENTER>

<P>The second field is the data port. This is the filename of the special file in the /dev directory that matches the physical device, and will be the port through which the data communication is made.