LDP
/
old-www
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
old-www/LDP/nag2/x-087-2-uucp.config.files.html

2322 lines
48 KiB
HTML
Raw Permalink Blame History

<HTML
><HEAD
><TITLE
>UUCP Configuration Files</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.57"><LINK
REL="HOME"
TITLE="Linux Network Administrators Guide"
HREF="index.html"><LINK
REL="UP"
TITLE="ManagingTaylor UUCP"
HREF="x-087-2-uucp.html"><LINK
REL="PREVIOUS"
TITLE="UUCP Transfers and Remote Execution"
HREF="x-087-2-uucp.intro.grades.html"><LINK
REL="NEXT"
TITLE="Controlling Access to UUCP Features"
HREF="x-087-2-uucp.permissions.html"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Linux Network Administrators Guide</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x-087-2-uucp.intro.grades.html"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 16. ManagingTaylor UUCP</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x-087-2-uucp.permissions.html"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="X-087-2-UUCP.CONFIG.FILES"
>16.2. UUCP Configuration Files</A
></H1
><P
>&#13;
In contrast to simpler file transfer programs, UUCP was designed to be
able to handle all transfers automatically. Once it is set up
properly, interference by the administrator should not be necessary on
a day-to-day basis. The information required for automated transfer is
kept in a couple of configuration files that reside in the
<TT
CLASS="FILENAME"
>/usr/lib/uucp</TT
> directory. Most of these files are
used only when dialing out.</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN12735"
>16.2.1. A Gentle Introduction to Taylor UUCP</A
></H2
><P
>To say that UUCP configuration is difficult would be an understatement. It
is really a hairy subject, and the sometimes terse format of the
configuration files doesn't make things easier (although the Taylor format is
almost easy reading compared to the older formats in HDB or Version 2).</P
><P
>To give you a feel for how all the configuration files interact, we will
introduce you to the most important ones and have a look at sample entries
from these files. We won't explain everything in detail now; a more accurate
account is given in separate sections that follow. If you want to set up your
machine for UUCP, you had best start with some sample files and adapt
them gradually. You can pick either those shown below or those included in
your favorite Linux distribution.</P
><P
>All files described in this section are kept in
<TT
CLASS="FILENAME"
>/etc/uucp</TT
> or a subdirectory thereof. Some Linux
distributions contain UUCP binaries that have support for both HDB and Taylor
configuration enabled, and use different subdirectories for each configuration
file set. There will usually be a <TT
CLASS="FILENAME"
>README</TT
> file in
<TT
CLASS="FILENAME"
>/usr/lib/uucp</TT
>.</P
><P
>For UUCP to work properly, these files must be owned by the
<SPAN
CLASS="SYSTEMITEM"
>uucp</SPAN
> user. Some of them contain
passwords and telephone numbers, and therefore should have permissions
of 600. Note that although most UUCP commands must be setuid to
<SPAN
CLASS="SYSTEMITEM"
>uucp</SPAN
>, you must make sure the
<B
CLASS="COMMAND"
>uuchk</B
> program is
<I
CLASS="EMPHASIS"
>not</I
>. Otherwise, users will be able to display
system passwords even though the files have mode 600.</P
><P
>The central UUCP configuration file is
<TT
CLASS="FILENAME"
>/etc/uucp/config</TT
>, which is used to set general
parameters. The most important of them (and for now, the only one) is
your host's UUCP name. At the Virtual Brewery, they use <SPAN
CLASS="SYSTEMITEM"
>vstout</SPAN
> as their UUCP gateway:</P
><P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
># /etc/uucp/config - UUCP main configuration file
nodename vstout</PRE
></TD
></TR
></TABLE
></P
><P
>The <TT
CLASS="FILENAME"
>sys</TT
> file is the next important configuration file. It
contains all the system-specific information of sites to which you are linked.
This includes the site's name and information on the link itself, such as the
telephone number when using a modem link. A typical entry for a
modem-connected site called <SPAN
CLASS="SYSTEMITEM"
>pablo</SPAN
>
would look like this:</P
><P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
># /usr/lib/uucp/sys - name UUCP neighbors
# system: pablo
system pablo
time Any
phone 555-22112
port serial1
speed 38400
chat ogin: vstout ssword: lorca</PRE
></TD
></TR
></TABLE
></P
><P
><SPAN
CLASS="SYSTEMITEM"
>time</SPAN
> specifies the times at
which the remote system may be called. <SPAN
CLASS="SYSTEMITEM"
>chat</SPAN
> describes the login chat
scripts&#8212;the sequence of strings that must be exchanged to allow
<B
CLASS="COMMAND"
>uucico</B
> to log into <SPAN
CLASS="SYSTEMITEM"
>pablo</SPAN
>. We will get back to chat scripts
later. The <SPAN
CLASS="SYSTEMITEM"
>port</SPAN
> keyword simply
names an entry in the <TT
CLASS="FILENAME"
>port</TT
> file. (Refer to <A
HREF="x-087-2-uucp.config.files.html#X-087-2-UUCP.FIG.FILES"
>Figure 16-1</A
>.) You can assign whatever name you
like as long as it refers to a valid entry in
<TT
CLASS="FILENAME"
>port</TT
>.</P
><P
>The <TT
CLASS="FILENAME"
>port</TT
> file holds information specific to the
link itself. For modem links, it describes the device special file to
be used, the range of speeds supported, and the type of dialing
equipment connected to the port. The following entry describes
<TT
CLASS="FILENAME"
>/dev/ttyS1</TT
> (a.k.a. COM 2), to which the
administrator has connected a NakWell modem capable of running at
speeds up to 38,400 bps. The port's name is chosen to match the port
name given in the <TT
CLASS="FILENAME"
>sys</TT
> file:</P
><P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
># /etc/uucp/port - UUCP ports
# /dev/ttyS1 (COM2)
port serial1
type modem
device /dev/ttyS1
speed 38400
dialer nakwell</PRE
></TD
></TR
></TABLE
></P
><P
>The information pertaining to the dialers is kept in yet another file
called&#8212;you guessed it&#8212;<TT
CLASS="FILENAME"
>dial</TT
>. For each dialer
type, it basically contains the sequence of commands that are issued to dial up
a remote site, given the telephone number. Again, this is specified as a chat
script. For example, the entry for NakWell might look like this:</P
><P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
># /etc/uucp/dial - per-dialer information
# NakWell modems
dialer nakwell
chat "" AT&#38;F OK ATDT\T CONNECT</PRE
></TD
></TR
></TABLE
></P
><P
>The line starting with <SPAN
CLASS="SYSTEMITEM"
>chat</SPAN
>
specifies the modem chat, which is the sequence of commands sent to
and received from the modem to initialize it and make it dial the
desired number. The <SPAN
CLASS="SYSTEMITEM"
>\T</SPAN
>
sequence will be replaced with the phone number by
<B
CLASS="COMMAND"
>uucico</B
>.</P
><P
>To give you a rough idea how <B
CLASS="COMMAND"
>uucico</B
> deals with these
configuration files, assume you issue the following command:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>$ <TT
CLASS="USERINPUT"
><B
>uucico -s pablo</B
></TT
></PRE
></TD
></TR
></TABLE
></P
><P
>The first thing <B
CLASS="COMMAND"
>uucico</B
> does is look up <SPAN
CLASS="SYSTEMITEM"
>pablo</SPAN
> in the <TT
CLASS="FILENAME"
>sys</TT
>
file. From the <TT
CLASS="FILENAME"
>sys</TT
> file entry for <SPAN
CLASS="SYSTEMITEM"
>pablo</SPAN
>, it sees that it should use the
<SPAN
CLASS="SYSTEMITEM"
>serial1</SPAN
> port to establish the
connection. The <TT
CLASS="FILENAME"
>port</TT
> file tells
<B
CLASS="COMMAND"
>uucico</B
> that this is a modem port, and that it has a
NakWell modem attached.</P
><P
><B
CLASS="COMMAND"
>uucico</B
> now searches <TT
CLASS="FILENAME"
>dial</TT
> for
the entry describing the NakWell modem, and having found one, opens
the serial port <TT
CLASS="FILENAME"
>/dev/cua1</TT
> and executes the dialer
chat. That is, it sends <B
CLASS="COMMAND"
>AT&#38;F</B
>, waits for the
<B
CLASS="COMMAND"
>OK</B
> response, etc. When encountering the string
<SPAN
CLASS="SYSTEMITEM"
>\T</SPAN
>, it substitutes the phone
number (555-22112) extracted from the <TT
CLASS="FILENAME"
>sys</TT
> file.</P
><P
>After the modem returns <B
CLASS="COMMAND"
>CONNECT</B
>, the connection has been
established, and the modem chat is complete. <B
CLASS="COMMAND"
>uucico</B
> now
returns to the <TT
CLASS="FILENAME"
>sys</TT
> file and executes the login chat. In
our example, it would wait for the <B
CLASS="COMMAND"
>login:</B
> prompt, then send
its username (<I
CLASS="EMPHASIS"
>vstout</I
>), wait for the
<B
CLASS="COMMAND"
>password:</B
> prompt, and send its password
(<B
CLASS="COMMAND"
>lorca</B
>).</P
><P
>After completing authorization, the remote end is assumed to fire up its own
<B
CLASS="COMMAND"
>uucico</B
>. The two then enter the handshake phase
described in the previous section.</P
><P
><A
HREF="x-087-2-uucp.config.files.html#X-087-2-UUCP.FIG.FILES"
>Figure 16-1</A
> illustrates the dependencies among
configuration files.</P
><DIV
CLASS="FIGURE"
><A
NAME="X-087-2-UUCP.FIG.FILES"
></A
><P
><B
>Figure 16-1. Interaction of Taylor UUCP configuration files</B
></P
><P
><IMG
SRC="lag2_1601.jpg"></P
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="X-087-2-UUCP.STARTING.PARAMETERS"
>16.2.2. What UUCP Needs to Know</A
></H2
><P
>Before you start writing the UUCP configuration files, you have to gather some
information that UUCP requires.</P
><P
>First, you have to figure out what serial device your modem is
attached to. Usually, the (DOS) ports COM1: through COM4: map to the
device special files <TT
CLASS="FILENAME"
>/dev/ttyS0</TT
> through
<TT
CLASS="FILENAME"
>/dev/ttyS3</TT
>. Some distributions, such as
Slackware, create a link called <TT
CLASS="FILENAME"
>/dev/modem</TT
> to the
appropriate <TT
CLASS="FILENAME"
>ttyS*</TT
> device file, and configure
<B
CLASS="COMMAND"
>kermit</B
>, <B
CLASS="COMMAND"
>seyon</B
>, and any other
communication programs to use this generic file. In this case, you
should use <TT
CLASS="FILENAME"
>/dev/modem</TT
> in your UUCP configuration,
too.</P
><P
>The reason for using a symbolic link is that all dial-out programs use
so-called <I
CLASS="EMPHASIS"
>lock files</I
> to signal when a serial port is
in use. The names of these lock files are a concatenation of the string
<TT
CLASS="FILENAME"
>LCK..</TT
> and the device filename, for instance
<TT
CLASS="FILENAME"
>LCK..ttyS1</TT
>. If programs use different names for the
same device, they will fail to recognize each other's lock files. As a
consequence, they will disrupt each other's session when started at the
same time. This is quite possible when you schedule your UUCP calls
using a <TT
CLASS="FILENAME"
>crontab</TT
> entry.
For details on serial port setup, please refer to
<A
HREF="x-087-2-serial.html"
>Chapter 4</A
>.</P
><P
>Next, you must find out at what speed your modem and Linux will communicate.
You have to set this speed to the maximum effective transfer rate you expect
to get. The effective transfer rate may be much higher than the raw physical
transfer rate your modem is capable of. For instance, many modems send and
receive data at 56 kbps. Using compression protocols such as V.42bis, the
actual transfer rate may climb over 100 kbps.</P
><P
>Of course, if UUCP is to do anything at all, you need the phone number
of a system to call. Also, you need a valid login ID and possibly a
password for the remote machine.<A
NAME="X-087-2-FNUU04"
HREF="#FTN.X-087-2-FNUU04"
>[1]</A
>&#13;</P
><P
>&#13;You also have to know <I
CLASS="EMPHASIS"
>exactly</I
> how to log into the
system. Do you have to press the Enter key before the login prompt appears?
Does it display <TT
CLASS="LITERAL"
>login:</TT
> or <TT
CLASS="LITERAL"
>user:</TT
>? This
is necessary for composing the <I
CLASS="EMPHASIS"
>chat script</I
>. If you don't
know, or if the usual chat script fails, try to call the system with a terminal
program like <B
CLASS="COMMAND"
>kermit</B
> or <B
CLASS="COMMAND"
>minicom</B
> and
record exactly what you have to do.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="X-087-2-UUCP.STARTING.SITENAME"
>16.2.3. Site Naming</A
></H2
><P
>&#13;
As with TCP/IP-based networking, your host has to have a name for UUCP
networking. As long as you simply want to use UUCP for file transfers to or
from sites you dial up directly, or on a local network, this name does not
have to meet any standards.<A
NAME="X-087-2-FNUU05"
HREF="#FTN.X-087-2-FNUU05"
>[2]</A
>&#13;</P
><P
>However, if you use UUCP for a mail or news link, you should think
about having the name registered with the UUCP Mapping Project.<A
NAME="X-087-2-FNUU06"
HREF="#FTN.X-087-2-FNUU06"
>[3]</A
> The UUCP Mapping Project is described in
<A
HREF="x-087-2-mail.html"
>Chapter 17</A
>. Even if you participate in a domain,
you might consider having an official UUCP name for your site.</P
><P
>Frequently, people choose their UUCP name to match the first component of
their fully qualified domain name. Suppose your site's domain address is
<SPAN
CLASS="SYSTEMITEM"
>swim.twobirds.com</SPAN
>; then your UUCP
hostname would be <SPAN
CLASS="SYSTEMITEM"
>swim</SPAN
>. Think of UUCP
sites as knowing each other on a first-name basis. Of course, you can also
use a UUCP name completely unrelated to your fully qualified domain name.</P
><P
>&#13;However, make sure not to use the unqualified site name in mail addresses
unless you have registered it as your official UUCP
name. At the very best, mail to an unregistered UUCP host will vanish in some big black bit bucket. If you use a name already held by some other site, this
mail will be routed to that site and cause its postmaster a lot of headaches.</P
><P
>By default, the UUCP suite uses the name set by <B
CLASS="COMMAND"
>hostname</B
> as
the site's UUCP name. This name is commonly set by a command on the boot
time <TT
CLASS="FILENAME"
>rc</TT
> scripts, and is usually stored in the
<TT
CLASS="FILENAME"
>/etc/hostname</TT
>. If your UUCP name is different from what
you set your hostname to, you have to use the
<B
CLASS="COMMAND"
>hostname</B
> option in the
<TT
CLASS="FILENAME"
>config</TT
> file to tell <B
CLASS="COMMAND"
>uucico</B
> about your
UUCP name. This is described next.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN12885"
>16.2.4. Taylor Configuration Files</A
></H2
><P
>
We now return to the configuration files. Taylor UUCP gets its information
from the following files:
<P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><TT
CLASS="FILENAME"
>config</TT
></DT
><DD
><P
>This is the main configuration file. You can define your site's UUCP name here.</P
></DD
><DT
><TT
CLASS="FILENAME"
>sys</TT
></DT
><DD
><P
>This file describes all known sites. For each site, it specifies its
name, what times to call it, which number to dial (if any), what type of device
to use, and how to log on.</P
></DD
><DT
><TT
CLASS="FILENAME"
>port</TT
></DT
><DD
><P
>This file contains entries describing each available port, together with the line speed
supported and the dialer to be used.</P
></DD
><DT
><TT
CLASS="FILENAME"
>dial</TT
></DT
><DD
><P
>This file describes dialers used to establish a telephone connection.</P
></DD
><DT
><TT
CLASS="FILENAME"
>dialcode</TT
></DT
><DD
><P
>This file contains expansions for symbolic dial codes.</P
></DD
><DT
><TT
CLASS="FILENAME"
>call</TT
></DT
><DD
><P
>This file contains the login name and password to be used when calling a system.
Rarely used.</P
></DD
><DT
><TT
CLASS="FILENAME"
>passwd</TT
></DT
><DD
><P
>This file contains login names and passwords that systems may use when logging in. It is used only when <B
CLASS="COMMAND"
>uucico</B
> does its own password
checking.</P
></DD
></DL
></DIV
></P
><P
>Taylor configuration files are generally made up of lines containing
keyword-value pairs. A hash sign introduces a comment that extends to the
end of the line. To use a hash sign to mean itself, escape it with a
backslash like this: <TT
CLASS="LITERAL"
>\#</TT
>.</P
><P
>There are quite a number of options you can tune with these configuration
files. We can't go into all the parameters, but we will cover the
most important ones here. Then you should be able to configure a modem-based
UUCP link. Additional sections describe the modifications necessary if you
want to use UUCP over TCP/IP or over a direct serial line. A complete
reference is given in the Texinfo documents that accompany the Taylor UUCP
sources.</P
><P
>&#13;
When you think you have configured your UUCP system completely, you can check
your configuration using the <B
CLASS="COMMAND"
>uuchk</B
> tool (located in
<TT
CLASS="FILENAME"
>/usr/lib/uucp</TT
>). <B
CLASS="COMMAND"
>uuchk</B
> reads your
configuration files and prints out a detailed report of the configuration
values used for each system.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN12944"
>16.2.5. General Configuration Options Using the config File</A
></H2
><P
>&#13;
You won't generally use this file to describe much beside your UUCP hostname.
By default, UUCP will use the name you set with the <B
CLASS="COMMAND"
>hostname</B
>
command, but it is generally a good idea to set the UUCP name explicitly. Here's a sample <TT
CLASS="FILENAME"
>config</TT
> file:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
># /usr/lib/uucp/config - UUCP main configuration file
hostname vstout</PRE
></TD
></TR
></TABLE
></P
><P
>A number of miscellaneous parameters can be set here too, such as the name of
the spool directory or access rights for anonymous UUCP. The latter will be
described later in this chapter in the section &#8220;Anonymous UUCP.&#8221;</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="X-087-2-UUCP.SYSTEMS.FILE"
>16.2.6. How to Tell UUCP About Other Systems Using the sys File</A
></H2
><P
>&#13;
The <TT
CLASS="FILENAME"
>sys</TT
> file describes the systems that your
machine knows about. An entry is introduced by the <SPAN
CLASS="SYSTEMITEM"
>system</SPAN
> keyword; the subsequent lines up to
the next <SPAN
CLASS="SYSTEMITEM"
>system</SPAN
> directive
detail the parameters specific to that site. Commonly, a system entry
defines parameters such as the telephone number and login chat.</P
><P
>Parameters before the very first <SPAN
CLASS="SYSTEMITEM"
>system</SPAN
> line set default values used for
all systems. Usually, you set protocol parameters and the like in
the defaults section.</P
><P
>&#13;The most prominent fields are discussed in detail in the following sections.</P
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN12972"
>16.2.6.1. System name</A
></H3
><P
>&#13;The <I
CLASS="EMPHASIS"
>system</I
> command names the remote
system. You must specify the correct name of the remote system, not an alias
you invented, because <B
CLASS="COMMAND"
>uucico</B
> will check it against what
the remote system says it is called when you log
on.<A
NAME="X-087-2-FNUU07"
HREF="#FTN.X-087-2-FNUU07"
>[4]</A
>&#13;</P
><P
>Each system name can appear only once. If you want to use several sets of
configurations for the same system (such as different telephone numbers
<B
CLASS="COMMAND"
>uucico</B
> should try in turn), you can specify
<I
CLASS="EMPHASIS"
>alternates</I
>, which we'll describe after the basic
configuration options.</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN12985"
>16.2.6.2. Telephone number</A
></H3
><P
>&#13;If the remote system is to be reached over a telephone line, the
<SPAN
CLASS="SYSTEMITEM"
>phone</SPAN
> field specifies the number the
modem should dial. It may contain several tokens interpreted by
<B
CLASS="COMMAND"
>uucico</B
>'s dialing procedure. An equal sign (=) means wait
for a secondary dial tone, and a dash (-) generates a one-second pause. Some
telephone installations choke when you don't pause between
dialing a special access code and the telephone
number.<A
NAME="X-087-2-FNUU08"
HREF="#FTN.X-087-2-FNUU08"
>[5]</A
>&#13;</P
><P
>&#13;It is often convenient to use names instead of numbers to describe
area dialing codes. The <TT
CLASS="FILENAME"
>dialcode</TT
> file allows you to
associate a name with a code that you may subsequently use when specifying
telephone numbers for remote hosts. Suppose you have the following
<TT
CLASS="FILENAME"
>dialcode</TT
> file:</P
><P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
># /usr/lib/uucp/dialcode - dialcode translation
Bogoham 024881
Coxton 035119</PRE
></TD
></TR
></TABLE
></P
><P
>With these translations, you can use a phone number such as
<SPAN
CLASS="SYSTEMITEM"
>Bogoham7732</SPAN
> in the
<TT
CLASS="FILENAME"
>sys</TT
> file, which will probably make things a little more
legible and a whole lot easier to update should the dialing code for
Bogoham ever change.</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN13006"
>16.2.6.3. port and speed</A
></H3
><P
>&#13;The <SPAN
CLASS="SYSTEMITEM"
>port</SPAN
> and <SPAN
CLASS="SYSTEMITEM"
>speed</SPAN
> options are used to select the
device used for calling the remote system and the maximum speed to
which the device should be set.<A
NAME="X-087-2-FNUU09"
HREF="#FTN.X-087-2-FNUU09"
>[6]</A
>
A <SPAN
CLASS="SYSTEMITEM"
>system</SPAN
> entry may
use either option alone or both options in conjunction. When looking
up a suitable device in the <TT
CLASS="FILENAME"
>port</TT
> file, only ports that have a matching port name and/or speed range are selected.</P
><P
>Generally, using the <SPAN
CLASS="SYSTEMITEM"
>speed</SPAN
>
option only should suffice. If you have only one serial device defined
in <TT
CLASS="FILENAME"
>port</TT
>, <B
CLASS="COMMAND"
>uucico</B
> always picks the right one anyway, so you only have to give it the desired
speed. If you have several modems attached to your systems, you still
often don't want to name a particular port, because if
<B
CLASS="COMMAND"
>uucico</B
> finds that there are several matches, it
tries each device in turn until it finds an unused one.</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN13024"
>16.2.6.4. The login chat</A
></H3
><P
>&#13;
We already encountered the login chat script, which tells
<B
CLASS="COMMAND"
>uucico</B
> how to log in to the remote system. It
consists of a list of tokens specifying strings expected and sent by
the local <B
CLASS="COMMAND"
>uucico</B
> process. <B
CLASS="COMMAND"
>uucico</B
>
waits until the remote machine sends a login prompt, then returns the
login name, waits for the remote system to send the password prompt,
and sends the password. Expect and send strings appear in alternation
in the script. <B
CLASS="COMMAND"
>uucico</B
> automatically appends a
carriage return character (<SPAN
CLASS="SYSTEMITEM"
>\r</SPAN
>)
to any send string. Thus, a simple chat script would look like:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
> ogin: vstout ssword: catch22</PRE
></TD
></TR
></TABLE
></P
><P
>You will probably notice that the expect fields don't contain the
whole prompts. This ensures that the login succeeds, even if the
remote system transmits <B
CLASS="COMMAND"
>Login:</B
> instead of
<B
CLASS="COMMAND"
>login:</B
>. If the string you are expecting or sending
contains spaces or other white-space characters, you must use quotes
to surround the text.</P
><P
><B
CLASS="COMMAND"
>uucico</B
> also allows for some sort of conditional execution.
Let's say the remote machine's <B
CLASS="COMMAND"
>getty</B
>
needs to be reset before sending a prompt. For this, you can attach a subchat
to an expect string, set off by a dash. The subchat is executed only if the
main expect fails, i.e., a timeout occurs. One way to use this feature is to
send a BREAK if the remote site doesn't display a login prompt. The following
example gives a general-purpose chat script that should also work in case you
have to press Enter before the login appears. The empty first argument,
<TT
CLASS="LITERAL"
>""</TT
>, tells UUCP to not wait for anything, but to continue
with the next send string:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
> "" \n\r\d\r\n\c ogin:-BREAK-ogin: vstout ssword: catch22</PRE
></TD
></TR
></TABLE
></P
><P
>A couple of special strings and escape characters can occur in the chat
script. The following is a partial list of characters legal in expect strings:
<P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><TT
CLASS="LITERAL"
>""</TT
></DT
><DD
><P
>The empty string. It tells <B
CLASS="COMMAND"
>uucico</B
> to not wait for anything,
but to proceed with the next send string immediately.</P
></DD
><DT
><SPAN
CLASS="SYSTEMITEM"
>\t</SPAN
></DT
><DD
><P
>Tab character.</P
></DD
><DT
><SPAN
CLASS="SYSTEMITEM"
>\r</SPAN
></DT
><DD
><P
>Carriage return character.</P
></DD
><DT
><SPAN
CLASS="SYSTEMITEM"
>\s</SPAN
></DT
><DD
><P
>Space character. You need this to embed spaces in a chat string.</P
></DD
><DT
><SPAN
CLASS="SYSTEMITEM"
>\n</SPAN
></DT
><DD
><P
>Newline character.</P
></DD
><DT
><SPAN
CLASS="SYSTEMITEM"
>\\</SPAN
></DT
><DD
><P
>Backslash character.</P
></DD
></DL
></DIV
></P
><P
>On send strings, the following escape characters and strings are legal in
addition to the above:
<P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><SPAN
CLASS="SYSTEMITEM"
>EOT</SPAN
></DT
><DD
><P
>End of transmission character (<B
CLASS="COMMAND"
>^D</B
>).</P
></DD
><DT
><SPAN
CLASS="SYSTEMITEM"
>BREAK</SPAN
></DT
><DD
><P
>Break character.</P
></DD
><DT
><SPAN
CLASS="SYSTEMITEM"
>\c</SPAN
></DT
><DD
><P
>Suppress sending of carriage return at end of string.</P
></DD
><DT
><SPAN
CLASS="SYSTEMITEM"
>\d</SPAN
></DT
><DD
><P
>Delay sending for 1 second.</P
></DD
><DT
><SPAN
CLASS="SYSTEMITEM"
>\E</SPAN
></DT
><DD
><P
>Enable echo checking. This requires <B
CLASS="COMMAND"
>uucico</B
> to wait for the
echo of everything it writes to be read back from the device before it can
continue with the chat. It is primarily useful when used in modem chats
(which we will encounter later). Echo checking is off by default.</P
></DD
><DT
><SPAN
CLASS="SYSTEMITEM"
>\e</SPAN
></DT
><DD
><P
>Disable echo checking.</P
></DD
><DT
><SPAN
CLASS="SYSTEMITEM"
>\K</SPAN
></DT
><DD
><P
>Same as <SPAN
CLASS="SYSTEMITEM"
>BREAK</SPAN
>.</P
></DD
><DT
><SPAN
CLASS="SYSTEMITEM"
>\p</SPAN
></DT
><DD
><P
>Pause for fraction of a second.</P
></DD
></DL
></DIV
></P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN13131"
>16.2.6.5. Alternates</A
></H3
><P
>&#13;Sometimes you want to have multiple entries for a single system, for
instance if the system can be reached on different modem lines. With Taylor
UUCP, you can do this by defining a so-called <I
CLASS="EMPHASIS"
>alternate</I
>.</P
><P
>An alternate entry retains all settings from the main system entry and
specifies only those values that should be overridden in the default system
entry or added to it. An alternate is offset from the system entry by a
line containing the keyword <SPAN
CLASS="SYSTEMITEM"
>alternate</SPAN
>.</P
><P
>To use two phone numbers for <SPAN
CLASS="SYSTEMITEM"
>pablo</SPAN
>,
you would modify its <TT
CLASS="FILENAME"
>sys</TT
> entry in the following way:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>system pablo
phone 123-456
.. entries as above ...
alternate
phone 123-455</PRE
></TD
></TR
></TABLE
></P
><P
>When calling <SPAN
CLASS="SYSTEMITEM"
>pablo</SPAN
>,
<B
CLASS="COMMAND"
>uucico</B
> will first dial 123-456, and if this fails, it will
try the alternate. The alternate entry retains all settings from the main
system entry and overrides the telephone number only.</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="AEN13147"
>16.2.6.6. Restricting call times</A
></H3
><P
>&#13;
Taylor UUCP provides a number of ways you may restrict the times when calls
can be placed to a remote system. You might do this either because of
limitations the remote host places on its services during business hours, or
simply to avoid times with high call rates. Note that it is always possible
to override call-time restrictions by giving <B
CLASS="COMMAND"
>uucico</B
> the
<TT
CLASS="OPTION"
>&#8211;S</TT
> or <TT
CLASS="OPTION"
>&#8211;f</TT
> option.</P
><P
>By default, Taylor UUCP disallows connections at any time, so you
<I
CLASS="EMPHASIS"
>have</I
> to use some sort of time specification in the
<TT
CLASS="FILENAME"
>sys</TT
> file. If you don't care about call time restrictions,
you can specify the <B
CLASS="COMMAND"
>time</B
> option with a
value of <SPAN
CLASS="SYSTEMITEM"
>Any</SPAN
> in your
<TT
CLASS="FILENAME"
>sys</TT
> file.</P
><P
>The simplest way to restrict call time is to include a
<SPAN
CLASS="SYSTEMITEM"
>time</SPAN
> entry, followed by a string made
up of a day and a time subfield. Day may be any combination of
<SPAN
CLASS="SYSTEMITEM"
>Mo, Tu, We, Th, Fr, Sa,</SPAN
> and <SPAN
CLASS="SYSTEMITEM"
>Su</SPAN
>. You can
also specify <SPAN
CLASS="SYSTEMITEM"
>Any</SPAN
>,
<SPAN
CLASS="SYSTEMITEM"
>Never</SPAN
>, or
<SPAN
CLASS="SYSTEMITEM"
>Wk</SPAN
> for weekdays. The time consists of
two 24-hour clock values, separated by a dash. They specify the range during
which calls may be placed. The combination of these tokens is written without
white space in between. Any number of day and time specifications may be
grouped together with commas, as this line shows:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>time MoWe0300-0730,Fr1805-2200</PRE
></TD
></TR
></TABLE
></P
><P
>This example allows calls on Mondays and Wednesdays from 3:00 a.m. to 7:30 a.m.,
and on Fridays between 6:05 p.m. and 10:00 p.m. When a time field spans
midnight, say <SPAN
CLASS="SYSTEMITEM"
>Mo1830-0600</SPAN
>, it actually
means Monday, between midnight and 6:00 a.m. and between 6:30 p.m. and midnight.</P
><P
>The special time strings <SPAN
CLASS="SYSTEMITEM"
>Any</SPAN
> and
<SPAN
CLASS="SYSTEMITEM"
>Never</SPAN
> mean what they say: calls may be
placed at any or no time, respectively.</P
><P
>Taylor UUCP also has a number of special tokens you may use in time strings,
such as <SPAN
CLASS="SYSTEMITEM"
>NonPeak</SPAN
> and
<SPAN
CLASS="SYSTEMITEM"
>Night</SPAN
>. These special tokens are shorthand for
<SPAN
CLASS="SYSTEMITEM"
>Any2300-0800,SaSu0800-1700</SPAN
> and
<SPAN
CLASS="SYSTEMITEM"
>Any1800-0700,SaSu</SPAN
>, respectively.</P
><P
>&#13;The <I
CLASS="EMPHASIS"
>time</I
> command takes an optional
second argument that describes a retry time in minutes. When an attempt to
establish a connection fails, <B
CLASS="COMMAND"
>uucico</B
> will not allow another
attempt to dial up the remote host within a certain interval. For instance,
when you specify a retry time of 5 minutes, <B
CLASS="COMMAND"
>uucico</B
> will
refuse to call the remote system within 5 minutes after the last failure. By
default, <B
CLASS="COMMAND"
>uucico</B
> uses an exponential backoff scheme, where
the retry interval increases with each repeated failure.</P
><P
>&#13;
The <B
CLASS="COMMAND"
>timegrade</B
> command allows you to
attach a maximum spool grade to a schedule. For instance, assume you have the
following <B
CLASS="COMMAND"
>timegrade</B
> commands in a
<SPAN
CLASS="SYSTEMITEM"
>system</SPAN
> entry:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>timegrade N Wk1900-0700,SaSu
timegrade C Any</PRE
></TD
></TR
></TABLE
></P
><P
>This allows jobs with a spool grade of C or higher (usually mail is queued
with grade B or C) to be transferred whenever a call is established, while
news (usually queued with grade N) are transferred only during the night
and at weekends.</P
><P
>Just like <B
CLASS="COMMAND"
>time</B
>, the <B
CLASS="COMMAND"
>timegrade</B
> command takes a retry interval in minutes as an optional third argument.</P
><P
>However, a caveat about spool grades is in order here. First, the
<B
CLASS="COMMAND"
>timegrade</B
> option applies only to what
<I
CLASS="EMPHASIS"
>your</I
> systems sends; the remote system may still transfer
anything it likes. You can use the
<B
CLASS="COMMAND"
>call-timegrade</B
> option to explicitly
request it to send only jobs above some given spool grade; but there's no
guarantee it will obey this request.<A
NAME="X-087-2-FNUU10"
HREF="#FTN.X-087-2-FNUU10"
>[7]</A
></P
><P
>Similarly, the <TT
CLASS="REPLACEABLE"
><I
>timegrade</I
></TT
> field is not
checked when a remote system calls in, so any jobs queued for the calling
system will be sent. However, the remote system can explicitly request your
<B
CLASS="COMMAND"
>uucico</B
> to restrict itself to a certain spool grade.&#13;</P
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN13217"
>16.2.7. Identifying Available Devices Through the port File</A
></H2
><P
>&#13;
The <TT
CLASS="FILENAME"
>port</TT
> file tells <B
CLASS="COMMAND"
>uucico</B
> about the
available ports. These are usually modem ports, but other types, such as direct
serial lines and TCP sockets, are supported as well.</P
><P
>Like the <TT
CLASS="FILENAME"
>sys</TT
> file, <TT
CLASS="FILENAME"
>port</TT
>
consists of separate entries starting with the keyword
<SPAN
CLASS="SYSTEMITEM"
>port</SPAN
> followed by the port name. This
name may be used in the <TT
CLASS="FILENAME"
>sys</TT
> file's
<SPAN
CLASS="SYSTEMITEM"
>port</SPAN
> statement. The name need not
be unique; if there are several ports with the same name,
<B
CLASS="COMMAND"
>uucico</B
> will try each in turn until it finds one that
is not currently being used.</P
><P
>The <B
CLASS="COMMAND"
>port</B
> command should be followed
immediately by the <SPAN
CLASS="SYSTEMITEM"
>type</SPAN
> statement,
which indicates what type of port is described. Valid types are
<SPAN
CLASS="SYSTEMITEM"
>modem</SPAN
>,
<SPAN
CLASS="SYSTEMITEM"
>direct</SPAN
> for direct connections, and
<SPAN
CLASS="SYSTEMITEM"
>tcp</SPAN
> for TCP sockets. If the
<B
CLASS="COMMAND"
>port</B
> command is missing, the port
type defaults to modem.</P
><P
>In this section, we cover only modem ports; TCP ports and direct lines are
discussed in a later section.</P
><P
>For modem and direct ports, you have to specify the device for calling out
using the <SPAN
CLASS="SYSTEMITEM"
>device</SPAN
> directive. Usually,
this is the name of a device special file in the <TT
CLASS="FILENAME"
>/dev</TT
>
directory, like <TT
CLASS="FILENAME"
>/dev/ttyS1</TT
>.</P
><P
>In the case of a modem device, the port entry also determines what type of
modem is connected to the port. Different types of modems have to be
configured differently. Even modems that claim to be Hayes-compatible aren't
always really compatible with one another. Therefore, you have to tell
<B
CLASS="COMMAND"
>uucico</B
> how to initialize the modem and make it dial
the desired number. Taylor UUCP keeps the descriptions of all dialers in a
file named <TT
CLASS="FILENAME"
>dial</TT
>. To use any of these, you have to specify
the dialer's name using the <B
CLASS="COMMAND"
>dialer</B
>
command.</P
><P
>Sometimes, you will want to use a modem in different ways, depending on which
system you call. For instance, some older modems don't understand when a
high-speed modem attempts to connect at 56 kbps; they simply drop the line
instead of negotiating a connect at 9,600 bps, for instance. When you know site
<SPAN
CLASS="SYSTEMITEM"
>drop</SPAN
> uses such a dumb modem, you have
to set up your modem differently when calling them. For this, you need an
additional port entry in the <TT
CLASS="FILENAME"
>port</TT
> file that specifies a
different dialer. Now you can give the new port a different name, such as
<SPAN
CLASS="SYSTEMITEM"
>serial1-slow</SPAN
>, and use the
<SPAN
CLASS="SYSTEMITEM"
>port</SPAN
> directive in the
<SPAN
CLASS="SYSTEMITEM"
>drop</SPAN
> system entry in
<TT
CLASS="FILENAME"
>sys</TT
>.</P
><P
>A better to distinguish the ports is by the speeds they support. For
instance, the two port entries for the above situation may look like this:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
># NakWell modem; connect at high speed
port serial1 # port name
type modem # modem port
device /dev/ttyS1 # this is COM2
speed 115200 # supported speed
dialer nakwell # normal dialer
# NakWell modem; connect at low speed
port serial1 # port name
type modem # modem port
device /dev/ttyS1 # this is COM2
speed 9600 # supported speed
dialer nakwell-slow # don't attempt fast connect</PRE
></TD
></TR
></TABLE
></P
><P
>The system entry for site <SPAN
CLASS="SYSTEMITEM"
>drop</SPAN
> would
now give <SPAN
CLASS="SYSTEMITEM"
>serial1</SPAN
> as the port name, but
request to use it at only 9,600 bps. <B
CLASS="COMMAND"
>uucico</B
> then
automatically uses the second port entry. All remaining sites that have a
speed of 115,200 bps in the system entry will be called using the first port
entry. By default, the first entry with a matching speed will be used.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN13267"
>16.2.8. How to Dial a Number Using the dial File</A
></H2
><P
>&#13;
The <TT
CLASS="FILENAME"
>dial</TT
> file describes the way various dialers are used.
Traditionally, UUCP talks of dialers rather than modems, because in earlier
times, it was usual practice to have one (expensive) automatic dialing device
serve a whole bank of modems. Today, most modems have dialing support built
in, so this distinction gets a little blurred.</P
><P
>Nevertheless, different dialers or modems may require a different
configuration. You can describe each of them in the
<TT
CLASS="FILENAME"
>dial</TT
> file. Entries in <TT
CLASS="FILENAME"
>dial</TT
>
start with the <B
CLASS="COMMAND"
>dialer</B
> command
that gives the dialer's name.</P
><P
>The most important entry besides <B
CLASS="COMMAND"
>dialer</B
> is the modem chat, specified by the <B
CLASS="COMMAND"
>chat</B
> command. Similar to the
login chat, it consists of a sequence of strings
<B
CLASS="COMMAND"
>uucico</B
> sends to the dialer and the responses it
expects in return. It is commonly used to reset the modem to some
known state and dial the number. The following sample <SPAN
CLASS="SYSTEMITEM"
>dialer</SPAN
> entry shows a typical modem chat
for a Hayes-compatible modem:</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
># NakWell modem; connect at high speed
dialer nakwell # dialer name
chat "" AT&#38;F OK\r ATH1E0Q0 OK\r ATDT\T CONNECT
chat-fail BUSY
chat-fail ERROR
chat-fail NO\sCARRIER
dtr-toggle true</PRE
></TD
></TR
></TABLE
><P
>The modem chat begins with <TT
CLASS="LITERAL"
>""</TT
>, the empty expect
string. <B
CLASS="COMMAND"
>uucico</B
> therefore sends the first
command <B
CLASS="COMMAND"
>AT&#38;F</B
> right
away. <B
CLASS="COMMAND"
>AT&#38;F</B
> is the Hayes command to reset the
modem to factory default configuration. <B
CLASS="COMMAND"
>uucico</B
>
then waits until the modem has sent <TT
CLASS="LITERAL"
>OK</TT
> and sends
the next command, which turns off local echo and the like. After the
modem returns <TT
CLASS="LITERAL"
>OK</TT
> again, <B
CLASS="COMMAND"
>uucico</B
>
sends the dialing command <B
CLASS="COMMAND"
>ATDT</B
>. The escape
sequence <TT
CLASS="LITERAL"
>\T</TT
> in this string is replaced with the
phone number taken from the system entry <TT
CLASS="FILENAME"
>sys</TT
>
file. <B
CLASS="COMMAND"
>uucico</B
> then waits for the modem to return the
string <TT
CLASS="LITERAL"
>CONNECT</TT
>, which signals that a connection
with the remote modem has been established successfully.</P
><P
>Sometimes the modem fails to connect to the remote system; for instance,
if the other system is talking to someone else and the line is busy. In this
case, the modem returns an error message indicating the reason. Modem
chats are not capable of detecting such messages; <B
CLASS="COMMAND"
>uucico</B
>
continues to wait for the expected string until it times out. The UUCP
log file therefore only shows a bland &#8220;timed out in chat
script&#8221; instead of the specific reason.</P
><P
>However, Taylor UUCP allows you to tell <B
CLASS="COMMAND"
>uucico</B
> about these
error messages using the <B
CLASS="COMMAND"
>chat-fail</B
>
command as shown above. When <B
CLASS="COMMAND"
>uucico</B
> detects a chat-fail
string while executing the modem chat, it aborts the call and logs the error
message in the UUCP log file.</P
><P
>The last command in the example shown above tells UUCP to toggle the Data Terminal Ready (DTR) control line before starting the modem chat. Normally,
the serial driver raises DTR when a process opens the device to tell the
attached modem that someone wants to talk to it. The
<SPAN
CLASS="SYSTEMITEM"
>dtr-toggle</SPAN
> feature then drops DTR,
waits a moment, and raises it again. Many modems can be configured
to react to a drop of DTR by going off-hook, entering command state, or
resetting themselves.<A
NAME="X-087-2-FNUU11"
HREF="#FTN.X-087-2-FNUU11"
>[8]</A
>&#13;</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN13312"
>16.2.9. UUCP Over TCP</A
></H2
><P
>&#13;
Absurd as it may sound, using UUCP to transfer data over TCP is not that bad
an idea, especially when transferring large amounts of data such as Usenet
news. On TCP-based links, news is generally exchanged using the NNTP
protocol, through which articles are requested and sent individually without
compression or any other optimization. Although adequate for large sites
with several concurrent newsfeeds, this technique is very unfavorable for
small sites that receive their news over a relatively slow connection such
as ISDN. These sites will usually want to combine the qualities of TCP with
the advantages of sending news in large batches, which can be compressed and
thus transferred with very low overhead. A common way to transfer these
batches is to use UUCP over TCP.</P
><P
>In <TT
CLASS="FILENAME"
>sys</TT
>, you would specify a system to be called via TCP
like this:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>system gmu
address news.groucho.edu
time Any
port tcp-conn
chat ogin: vstout word: clouseau</PRE
></TD
></TR
></TABLE
></P
><P
>The <B
CLASS="COMMAND"
>address</B
> command gives the
IP address of the host or its fully qualified domain name. The
corresponding <TT
CLASS="FILENAME"
>port</TT
> entry would read:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>port tcp-conn
type tcp
service 540</PRE
></TD
></TR
></TABLE
></P
><P
>The entry states that a TCP connection should be used when a
<TT
CLASS="FILENAME"
>sys</TT
> entry references
<SPAN
CLASS="SYSTEMITEM"
>tcp-conn</SPAN
>, and that
<B
CLASS="COMMAND"
>uucico</B
> should attempt to connect to the TCP network port
540 on the remote host. This is the default port number of the UUCP service.
Instead of the port number, you may also give a symbolic port name to the
<B
CLASS="COMMAND"
>service</B
> command. The port number
corresponding to this name will be looked up in
<TT
CLASS="FILENAME"
>/etc/services</TT
>. The common name for the UUCP service is
<SPAN
CLASS="SYSTEMITEM"
>uucpd</SPAN
>.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN13335"
>16.2.10. Using a Direct Connection</A
></H2
><P
>&#13;Assume you use a direct line to connect your system
<SPAN
CLASS="SYSTEMITEM"
>vstout</SPAN
> to
<SPAN
CLASS="SYSTEMITEM"
>tiny</SPAN
>. Much like in the modem case,
you have to write a system entry in the <TT
CLASS="FILENAME"
>sys</TT
> file. The
<B
CLASS="COMMAND"
>port</B
> command identifies the serial port
<SPAN
CLASS="SYSTEMITEM"
>tiny</SPAN
> is hooked up to:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>system tiny
time Any
port direct1
speed 38400
chat ogin: cathcart word: catch22</PRE
></TD
></TR
></TABLE
></P
><P
>In the <TT
CLASS="FILENAME"
>port</TT
> file, you have to describe the serial port
for the direct connection. A <SPAN
CLASS="SYSTEMITEM"
>dialer</SPAN
>
entry is not needed because there's no need for dialing:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="SCREEN"
>port direct1
type direct
speed 38400
device /dev/ttyS1</PRE
></TD
></TR
></TABLE
></P
></DIV
></DIV
><H3
CLASS="FOOTNOTES"
>Notes</H3
><TABLE
BORDER="0"
CLASS="FOOTNOTES"
WIDTH="100%"
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.X-087-2-FNUU04"
HREF="x-087-2-uucp.config.files.html#X-087-2-FNUU04"
>[1]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>If you're just going to try out UUCP, get the number of an archive site near
you. Write down the login and password&#8212;they're public to make anonymous
downloads possible. In most cases, they're something like
<SPAN
CLASS="SYSTEMITEM"
>uucp/uucp</SPAN
> or
<SPAN
CLASS="SYSTEMITEM"
>nuucp/uucp</SPAN
>.</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.X-087-2-FNUU05"
HREF="x-087-2-uucp.config.files.html#X-087-2-FNUU05"
>[2]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>The only limitation is that it shouldn't be longer than seven characters, so
as to not confuse UUCP implementations that run on an operating system that
imposes a narrow limit on filenames. Names that are longer than seven
characters are often truncated by UUCP. Some versions even limit the name to
six characters.</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.X-087-2-FNUU06"
HREF="x-087-2-uucp.config.files.html#X-087-2-FNUU06"
>[3]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
> The UUCP Mapping Project
registers all UUCP hostnames worldwide and makes sure they are
unique. </P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.X-087-2-FNUU07"
HREF="x-087-2-uucp.config.files.html#X-087-2-FNUU07"
>[4]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>Older Version 2 UUCPs don't broadcast their name when being called; however,
newer implementations often do, and so does Taylor UUCP.</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.X-087-2-FNUU08"
HREF="x-087-2-uucp.config.files.html#X-087-2-FNUU08"
>[5]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>For instance, most companies' private installations require you to dial a 0 or
9 to get a line to the outside.</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.X-087-2-FNUU09"
HREF="x-087-2-uucp.config.files.html#X-087-2-FNUU09"
>[6]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>The bit rate of the <I
CLASS="EMPHASIS"
>tty</I
> must be at least as high as the maximum
transfer speed.</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.X-087-2-FNUU10"
HREF="x-087-2-uucp.config.files.html#X-087-2-FNUU10"
>[7]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>If the remote system runs Taylor UUCP, it will obey.</P
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="5%"
><A
NAME="FTN.X-087-2-FNUU11"
HREF="x-087-2-uucp.config.files.html#X-087-2-FNUU11"
>[8]</A
></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="95%"
><P
>Some modems don't seem to like this and occasionally hang.</P
></TD
></TR
></TABLE
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="x-087-2-uucp.intro.grades.html"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="x-087-2-uucp.permissions.html"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>UUCP Transfers and Remote Execution</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="x-087-2-uucp.html"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Controlling Access to UUCP Features</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
Reference in New Issue View Git Blame Copy Permalink