1130 lines
50 KiB
Plaintext
1130 lines
50 KiB
Plaintext
Info file uucp.info, produced by Makeinfo, -*- Text -*- from input
|
||
file uucp.texi.
|
||
|
||
This file documents Taylor UUCP, beta version 1.03.
|
||
|
||
Copyright (C) 1992 Free Software Foundation, Inc.
|
||
|
||
Permission is granted to make and distribute verbatim copies of this
|
||
manual provided the copyright notice and this permission notice are
|
||
preserved on all copies.
|
||
|
||
Permission is granted to copy and distribute modified versions of
|
||
this manual under the conditions for verbatim copying, provided also
|
||
that the section entitled "Copying" are included exactly as in the
|
||
original, and provided that the entire resulting derived work is
|
||
distributed under the terms of a permission notice identical to this
|
||
one.
|
||
|
||
Permission is granted to copy and distribute translations of this
|
||
manual into another language, under the above conditions for modified
|
||
versions, except that the section entitled "Copying" may be included
|
||
in a translation approved by the author instead of in the original
|
||
English.
|
||
|
||
|
||
File: uucp.info, Node: sys file, Next: port file, Prev: config file, Up: Configuration files
|
||
|
||
The system configuration file
|
||
=============================
|
||
|
||
These files describe all remote systems known to the UUCP package.
|
||
|
||
The first set of commands in the file, up to the first `system'
|
||
command, specify defaults to be used for all systems in that file.
|
||
Each different system file uses a different set of defaults.
|
||
|
||
Subsequently, each set of commands from the first `system' up to
|
||
the next `system' command describe a particular system (default values
|
||
may be overridden for specific systems).
|
||
|
||
There is then another level of defaults, in that the first set of
|
||
commands for a particular system, up to the first `alternate' command,
|
||
specify defaults.
|
||
|
||
Subsequently, each set of commands from `alternate' up to the next
|
||
`alternate' command describe an alternate means of calling out or
|
||
calling in.
|
||
|
||
When a system is called, the commands before the first `alternate'
|
||
are used to select a phone number, port and so forth; if the call fails
|
||
for some reason, the commands between the first `alternate' and the
|
||
second are used, and so forth. Well, not quite. Actually, each
|
||
succeeding alternate will only be used if it is different in some
|
||
relevant way (different phone number, different chat script, etc.). If
|
||
you want to force the same alternate to be used again (to retry a phone
|
||
call more than once, for example), entering the phone number (or any
|
||
other relevant field) again will make it appear different.
|
||
|
||
When a call is received the various alternates are checked to
|
||
permit the login name to specify different permissions (this will only
|
||
be done if the first set of commands, before the first `alternate'
|
||
command, use the `called-login' command). In this case, the only
|
||
command relevant to whether an alternate is considered is
|
||
`called-login'.
|
||
|
||
The `alternate' command may also be used in the file wide defaults
|
||
(the set of commands before the first `system' command). This might
|
||
be used to specify a list of ports which are available for all systems
|
||
or to specify permissions based on the login name used by the remote
|
||
system when it calls in. If it is used, then the first alternate for
|
||
each system will default to the first alternate for the default (as
|
||
modified by the commands used before the first `alternate' command for
|
||
this system), the second alternate for each system to the second
|
||
alternate for the default (as modified the same way), and so forth. If
|
||
a system specifies more alternates than the default, the trailing ones
|
||
will default to the last default alternate. If a system specifies
|
||
fewer alternates than the default, the trailing default alternates
|
||
will be used unmodified. The `default-alternates' command may be used
|
||
to modify this behaviour.
|
||
|
||
This can all get rather confusing, although it's easier to use than
|
||
to describe concisely; the `uuchk' program may be used to ensure that
|
||
you are getting what you want.
|
||
|
||
`system STRING'
|
||
Specify the remote system name. Subsequent commands up to the
|
||
next `system' command refer to this system.
|
||
|
||
`alternate'
|
||
Start an alternate set of commands, as described above.
|
||
|
||
`default-alternates BOOLEAN'
|
||
If the argument is false, any remaining default alternates (from
|
||
the defaults specified at the top of the current system file)
|
||
will not be used. The default is true.
|
||
|
||
`alias STRING'
|
||
Specify an alias for the current system. The alias may be used
|
||
by local `uucp' and `uux' commands. The default is to have no
|
||
aliases.
|
||
|
||
`debug STRING ...'
|
||
Set additional debugging for calls to or from the system. This
|
||
may be used to debug a connection with a specific system. It is
|
||
particularly useful when debugging incoming calls, since
|
||
debugging information will be generated whenever the call comes
|
||
in. See the `debug' command in the main configuration file
|
||
(*note config file::.) for more details. The debugging
|
||
information specified here is in addition to that specified in
|
||
the main configuration file or on the command line.
|
||
|
||
`max-remote-debug STRING ...'
|
||
When the system calls in, it may request that the debugging level
|
||
be set to a certain value. This command may be used to put a
|
||
limit on the debugging level which the system may request, to
|
||
avoid filling up the disk with debugging information. Only the
|
||
debugging types named in the `max-remote-debug' command may be
|
||
turned on by the remote system. To prohibit any debugging, use
|
||
`max-remote-debug none'. The default is `chat,handshake'; to
|
||
turn off these default entries, you must use `max-remote-debug
|
||
none' followed by other `max-remote-debug' commands specifying
|
||
the settings you want.
|
||
|
||
`time STRING [NUMBER]'
|
||
Specify when the system may be called. Each time specification
|
||
must begin with a list containing `Su', `Mo', `Tu', `We', `Th',
|
||
`Fr', `Sa' or `Wk' for any weekday or `Any' for any day.
|
||
Following the day may be a range of hours separated with a hyphen
|
||
using 24 hour time. The range of hours may cross 0; for example
|
||
`2300-0700' means any time except 7 AM to 11 PM. If no time is
|
||
given, calls may be made at any time on the specified day(s).
|
||
Multiple time specifications may be separated with a vertical bar
|
||
`|' or a comma `,'.
|
||
|
||
The time specification may also consist of the single word
|
||
`Never', which means to never call the system (although the
|
||
system may be able to call in) or a single word with a name
|
||
defined in a previous `timetable' (q.v.) command.
|
||
|
||
The optional third argument specifies a retry time in minutes.
|
||
If a call made during a time that matches the time string fails,
|
||
no more calls are permitted until the retry time has passed. By
|
||
default an exponentially increasing retry time is used: after
|
||
each failure the next retry period is longer. A retry time
|
||
specified in the `time' command is always a fixed amount of time.
|
||
|
||
The `time' command may appear multiple times in a single
|
||
alternate, in which case if any time string matches the system
|
||
may be called. The default value is `Never'.
|
||
|
||
`timegrade CHARACTER STRING [NUMBER]'
|
||
The CHARACTER is a single character `A' to `Z', `a' to `z', or
|
||
`0' to `9' and specifies a grade. The STRING is a time string as
|
||
described under the `time' command. All jobs of grade CHARACTER
|
||
or higher (`0' > `9' > `A' > `Z' > `a' > `z') may be run at the
|
||
specified time. An ordinary `time' command is equivalent to
|
||
using `timegrade' with a grade of `z', permitting all jobs. If
|
||
there are no jobs of a sufficiently high grade according to the
|
||
time string, the system will not be called. Using the `-s'
|
||
switch to `uucico' to force it to call a system causes it to
|
||
assume there is a job of grade `0' waiting to be run.
|
||
|
||
The optional fourth argument specifies a retry time in minutes.
|
||
See the `time' command for more details.
|
||
|
||
Note that the `timegrade' command serves two purposes: 1) if there
|
||
is no job of sufficiently high grade the system will not be
|
||
called, and 2) if the system is called anyway (because the `-s'
|
||
switch was given to `uucico') only jobs of sufficiently high
|
||
grade will be transferred. However, if the other system calls
|
||
in, the `timegrade' commands are ignored, and jobs of any grade
|
||
may be transferred (but see `call-timegrade' below). Also, the
|
||
`timegrade' command will not prevent the other system from
|
||
executing any job it chooses, regardless of who placed the call.
|
||
|
||
The `timegrade' command may appear multiple times without using
|
||
`alternate'. If this command does not appear, there are no
|
||
restrictions on what grade of work may be done at what time.
|
||
|
||
`call-timegrade CHARACTER STRING'
|
||
The CHARACTER is a single character `A' to `Z', `a' to `z', or
|
||
`0' to `9' and specifies a grade. The STRING is a time string as
|
||
described under the `time' command. If a call is placed to the
|
||
other system during a time which matches the time string, the
|
||
remote system will be requested to only run jobs of grade
|
||
CHARACTER or higher. Unfortunately, there is no way to guarantee
|
||
that the other system will obey the request (this UUCP package
|
||
will, but there are others which will not); moreover historically
|
||
job grades are somewhat arbitrary so specifying a grade will only
|
||
be meaningful if the other system cooperates in assigning grades.
|
||
This grade restriction only applies when the other system is
|
||
called, not when the other system calls in.
|
||
|
||
The `call-timegrade' command may appear multiple times without
|
||
using `alternate'. If this command does not appear, or if none of
|
||
the time strings match, the remote system will be allowed to send
|
||
whatever grades of work it chooses.
|
||
|
||
`call-local-size NUMBER STRING'
|
||
The STRING is a time string as described under the `time'
|
||
command. The NUMBER is the size in bytes of the largest file that
|
||
should be transferred at a time matching the time string if the
|
||
local system placed the call and the request was made by the
|
||
local system. This command may appear multiple times in a single
|
||
alternate. If this command does not appear, or if none of the
|
||
time strings match, there are no size restrictions.
|
||
|
||
With all the size control commands, the size of a file from the
|
||
remote system (as opposed to a file from the local system) will
|
||
only be checked if the other system is running this package
|
||
(other UUCP packages will not understand a maximum size request,
|
||
nor will they inform this package of the size of remote files).
|
||
|
||
`call-remote-size NUMBER STRING'
|
||
Specify the size in bytes of the largest file that should be
|
||
transferred at a given time by remote request when the local
|
||
system placed the call. This command may appear multiple times
|
||
in a single alternate. If this command does not appear, there
|
||
are no size restrictions.
|
||
|
||
`called-local-size NUMBER STRING'
|
||
Specify the size in bytes of the largest file that should be
|
||
transferred at a given time by local request when the remote
|
||
system placed the call. This command may appear multiple times
|
||
in a single alternate. If this command does not appear, there are
|
||
no size restrictions.
|
||
|
||
`called-remote-size NUMBER STRING'
|
||
Specify the size in bytes of the largest file that should be
|
||
transferred at a given time by remote request when the remote
|
||
system placed the call. This command may appear multiple times
|
||
in a single alternate. If this command does not appear, there are
|
||
no size restrictions.
|
||
|
||
`timetable STRING STRING'
|
||
This is actually not specific to a system. It can appear
|
||
anywhere in the file, and defines a timetable that may be used in
|
||
subsequently appearing time commands. The first string names the
|
||
timetable entry; the second is a time string as described in the
|
||
`time' command.
|
||
|
||
The following timetable commands are predefined (note that the
|
||
NonPeak timetable is for compatibility, and no longer has any
|
||
particular meaning):
|
||
|
||
timetable Evening Wk1705-0755,Sa,Su
|
||
timetable Night Wk2305-0755,Sa,Su2305-1655
|
||
timetable NonPeak Wk1805-0655,Sa,Su
|
||
|
||
If this command does not appear, then obviously no additional
|
||
timetables will be defined.
|
||
|
||
`baud NUMBER'
|
||
`speed NUMBER'
|
||
Specify the speed (baud is technically incorrect, but widely
|
||
understood) at which to call the system. This will try all
|
||
available ports with that baud rate until an unlocked port is
|
||
found. The ports are defined in the port file. If both the baud
|
||
and the port commands appear, both are used when selecting a
|
||
port. To allow calls at more than one baud rate, the `alternate'
|
||
command must be used. If this command does not appear, there is
|
||
no default; the baud rate may be specified in the port file, but
|
||
if it is not the natural baud rate of the port will be used
|
||
(whatever that means on the system).
|
||
|
||
`port STRING'
|
||
Name a particular port or type of port to use when calling the
|
||
system. The information for this port is obtained from the port
|
||
file. If this command does not appear, there is no default; a
|
||
port must somehow be specified in order to call out (it may be
|
||
specified implicitly using the `baud' command or explicitly using
|
||
the next version of `port'). There may be many ports with the
|
||
same name; each will be tried in turn until an unlocked one is
|
||
found which matches the desired baud rate.
|
||
|
||
`port STRING ...'
|
||
If more than one string follows the `port' command, the subsequent
|
||
strings are treated as commands that might appear in the port
|
||
file (see the description of the port file, below). If a port is
|
||
named (by using a single string following `port') these commands
|
||
are ignored; their purpose is to permit specifying the port
|
||
directly in simple cases without having to make entries in two
|
||
different files. In order to call out, a port must be specified
|
||
using some version of the `port' command, or by using the `baud'
|
||
command to select ports from the port file.
|
||
|
||
`phone STRING'
|
||
`address STRING'
|
||
Give a phone number to call (when using a modem port) or a remote
|
||
host to contact (when using a TCP port). The commands `phone' and
|
||
`address' are equivalent, but are intended to be more mnemonic
|
||
depending on the type of port in use.
|
||
|
||
When used with a modem port, an `=' character in the phone number
|
||
means to wait for a secondary dial tone (although only some modems
|
||
support this); a `-' character means to pause while dialing for 1
|
||
second (again, only some modems support this). To use more than
|
||
one phone number the `alternate' command must be used. This
|
||
command must appear in order to call out on a modem; there is no
|
||
default.
|
||
|
||
When used with a TCP port, the string names the host to contact.
|
||
It may be a domain name or a numeric Internet address. If no
|
||
address is specified, the system name is used.
|
||
|
||
When used with any other port, this command is ignored.
|
||
|
||
`chat STRINGS'
|
||
This command is used to specify a chat script to use when logging
|
||
on to a remote system; see the `chat-program' command as well.
|
||
The `chat' command specifies a sequence of pairs of strings
|
||
separated by whitespace. The first string of each pair is an
|
||
"expect" string, the second is a "send" string. The `uucico'
|
||
program will wait for the expect string to appear from a port;
|
||
when it does, the send string will be sent. If the expect string
|
||
does not appear within a certain number of seconds (as set by the
|
||
`chat-timeout' command) the chat script fails and the call is
|
||
aborted. If the final expect string is seen (and the optional
|
||
final send string has been sent), the chat script is successful
|
||
and protocol negotiation begins.
|
||
|
||
An expect string may contain additional subsend and subexpect
|
||
strings, separated by hyphens. If the expect string is not seen,
|
||
the subsend string is sent and the chat script continues by
|
||
waiting for the subexpect string. This means that a hyphen may
|
||
not appear in an expect string (use `\055' instead).
|
||
|
||
An expect string may simply be `""', meaning to skip the expect
|
||
phase. Otherwise, the following escape characters may appear in
|
||
expect strings:
|
||
|
||
`\b'
|
||
a backspace character (`\b')
|
||
|
||
`\n'
|
||
a newline character (`\n')
|
||
|
||
`\N'
|
||
a null character (for BNU compatibility)
|
||
|
||
`\r'
|
||
a carriage return character (`\r')
|
||
|
||
`\s'
|
||
a space character (` ')
|
||
|
||
`\t'
|
||
a tab character (`\t')
|
||
|
||
`\\'
|
||
a slash character (`\\')
|
||
|
||
`\DDD'
|
||
character DDD, where DDD are up to three octal digits
|
||
|
||
`\xDDD'
|
||
character DDD, where DDD are hexadecimal digits.
|
||
|
||
As in C, there may be up to three octal digits following a slash,
|
||
but the hexadecimal escape sequence continues as far as possible.
|
||
To follow a hexadecimal escape sequence with a hex digit,
|
||
interpose a send string of `""'.
|
||
|
||
A send string may also simply be `""' to skip the send phase.
|
||
Otherwise, all of the escape characters legal for expect strings
|
||
may be used, and the following escape characters are also
|
||
permitted:
|
||
|
||
`EOT'
|
||
send an end of transmission character (`^D')
|
||
|
||
`BREAK'
|
||
send a break character (may not work on all systems)
|
||
|
||
`\c'
|
||
suppress trailing carriage return at end of send string
|
||
|
||
`\d'
|
||
delay sending for 1 second
|
||
|
||
`\e'
|
||
disable echo checking
|
||
|
||
`\E'
|
||
enable echo checking (wait for echo before continuing)
|
||
|
||
`\K'
|
||
same as `BREAK' (for BNU compatibility)
|
||
|
||
`\p'
|
||
pause sending for a fraction of a second
|
||
|
||
`\L'
|
||
send the login name
|
||
|
||
`\P'
|
||
send the password
|
||
|
||
A carriage return `\r' will be sent at the end of each send
|
||
string, unless the `\c' escape sequence appears in the string.
|
||
Note that some UUCP packages use `\b' for break, but here it
|
||
means backspace.
|
||
|
||
Echo checking means that after writing each character the program
|
||
will wait until the character is echoed. Echo checking must be
|
||
turned on separately for each send string for which it is
|
||
desired; it will be turned on for characters following `\E' and
|
||
turned off for characters following `\e'.
|
||
|
||
The default chat script is:
|
||
|
||
chat "" \r\c ogin:-BREAK-ogin:-BREAK-ogin: \L word: \P
|
||
|
||
This will send a carriage return (the `\c' suppresses the
|
||
additional trailing carriage return that would otherwise be sent)
|
||
and waits for the string `ogin:' (which would be the last part of
|
||
the `login:' prompt supplied by a Unix system). If it doesn't
|
||
see `ogin:', it sends a break and waits for `ogin:' again. If it
|
||
still doesn't see `ogin:', it sends another break and waits for
|
||
`ogin:' again. If it still doesn't see `ogin:', the chat script
|
||
aborts and hangs up the phone. If it does see `ogin:' at some
|
||
point, it sends the login name (as specified by the `call-login'
|
||
command) followed by a carriage return (since all send strings
|
||
are followed by a carriage return unless `\c' is used) and waits
|
||
for the string `word:' (which would be the last part of the
|
||
`Password:' prompt supplied by a Unix system). If it sees
|
||
`word:', it sends the password and a carriage return, completing
|
||
the chat script. The program will then enter the handshake phase
|
||
of the UUCP protocol.
|
||
|
||
This chat script will work for most systems, so you will only be
|
||
required to use the `call-login' and `call-password' commands.
|
||
In fact, you could use defaults of `call-login *' and
|
||
`call-password *' and then you would just have to make an entry
|
||
for the system in the call out login file. Some systems seem to
|
||
flush input after the `login:' prompt, so they may need a copy of
|
||
this chat script with a `\d' before the `\L'.
|
||
|
||
`chat-timeout NUMBER'
|
||
The number of seconds to wait for an expect string in the chat
|
||
script before timing out and sending the next subsend or failing
|
||
the chat script entirely. The default value is 10 for a login
|
||
chat or 60 for any other type of chat.
|
||
|
||
`chat-fail STRING'
|
||
If the STRING is seen at any time during a chat script, the chat
|
||
script is aborted. The string may not contain any whitespace
|
||
characters; escape sequences must be used for them. Multiple
|
||
`chat-fail' commands may appear in a single alternate. The
|
||
default is to have none. The corresponding command in the
|
||
dialers file has some examples where this is useful.
|
||
|
||
`chat-seven-bit BOOLEAN'
|
||
If the argument is true, all incoming characters are stripped to
|
||
seven bits when being compared to the expect string. Otherwise
|
||
all eight bits are used in the comparison. The default is true
|
||
because some Unix systems generate parity bits during the login
|
||
prompt which must be ignored while running the chat script. This
|
||
has no effect on any `chat-program', which must ignore parity by
|
||
itself if necessary.
|
||
|
||
`chat-program STRINGS'
|
||
Specify a program to run when calling up the system. This
|
||
program is expected to run its own version of a chat script, but
|
||
it may do whatever it wants. If both `chat-program' and `chat'
|
||
are specified, the program is executed first followed by the chat
|
||
script.
|
||
|
||
The first argument to the `chat-program' command is the program
|
||
name to run. The remaining arguments are passed to the program.
|
||
The following escape sequences are recognized in the arguments:
|
||
|
||
`\L'
|
||
login name
|
||
|
||
`\P'
|
||
password
|
||
|
||
`\Y'
|
||
port name
|
||
|
||
`\Z'
|
||
system name
|
||
|
||
`\S'
|
||
port speed
|
||
|
||
`\\'
|
||
backslash
|
||
|
||
Arguments other than escape sequences are passed exactly as they
|
||
appear in the configuration file, except that sequences of
|
||
whitespace are compressed to a single space character (this
|
||
exception may be removed in the future).
|
||
|
||
If the `chat-program' command is not used, no program is run.
|
||
|
||
On Unix, the standard input and standard output of the program
|
||
will be attached to the port which is being used to call out on.
|
||
Anything written on the standard error will be written to the log
|
||
file marked as an error. If the program does not exit with a
|
||
status of 0, it will be assumed to have failed and the call will
|
||
be aborted; this means that the dialing programs used by some
|
||
versions of BNU may not be used directly, although of course a
|
||
shell script could be used as an interface. The program will be
|
||
run as the `uucp' user, so care must be taken to maintain
|
||
security. A full path name should be used to name the program.
|
||
|
||
For example, a shell script intended to record when each system
|
||
was called might be specified in the defaults listed at the top
|
||
of the file as:
|
||
|
||
chat-program /bin/sh /usr/lib/uucp/called \Z
|
||
|
||
`call-login STRING'
|
||
Specify the login name to send with `\L' in the chat script. If
|
||
the string is `*' (e.g. `call-login *') the login name will be
|
||
fetched from the call out login name and password file. There is
|
||
no default.
|
||
|
||
`call-password STRING'
|
||
Specify the password to send with `\P' in the chat script. If the
|
||
string is `*' (e.g. `call-password *') the password will be
|
||
fetched from the call-out login name and password file. There is
|
||
no default.
|
||
|
||
`called-login STRINGS'
|
||
The first STRING specifies the login name that the system must use
|
||
when calling in. If it is `ANY' (e.g. `called-login ANY') any
|
||
login name may be used (this is useful to override a default
|
||
specified in this file, and to indicate that future alternates
|
||
may have different login names). Case is significant. The
|
||
default value is `ANY'. Different alternates may use different
|
||
`called-login' commands, in which case the login name will be
|
||
used to select which alternate is in effect; this will only work
|
||
if the first alternate (before the first `alternate' command)
|
||
uses the `called-login' command.
|
||
|
||
Additional strings may be specified after the login name; they
|
||
are a list of which machines are permitted to use this login
|
||
name. This is primarily useful when defining defaults if some
|
||
machines do not specify the `called-login' command. Any machine
|
||
with an explicit `called-login' command is permitted to use the
|
||
login name, whether it is explicitly mentioned in the list or not.
|
||
|
||
`callback BOOLEAN'
|
||
If BOOLEAN is true, then when the remote system calls `uucico'
|
||
will hang up the connection and prepare to call it back. This is
|
||
false by default.
|
||
|
||
`sequence BOOLEAN'
|
||
If BOOLEAN is true, then conversation sequencing is automatically
|
||
used for the remote system, so that if somebody manages to spoof
|
||
as the remote system, it will be detected the next time the
|
||
remote system actually calls. This is false by default.
|
||
|
||
`protocol STRING'
|
||
Specifies which protocols to use for the other system, and in
|
||
which order to use them. This would not normally be used. For
|
||
example, `protocol tfg'.
|
||
|
||
The default depends on the characteristics of the port and the
|
||
dialer, as specified by the `seven-bit' and `reliable' commands
|
||
described below. If neither the port nor the dialer use either
|
||
of these commands, the default is to assume an eight-bit reliable
|
||
connection. The commands `seven-bit true' or `reliable false'
|
||
might be used in either the port or the dialer to change this.
|
||
Each protocol has particular requirements that must be met before
|
||
it will be considered during negotiation with the remote side.
|
||
|
||
The `t' and `e' protocols are intended for use over TCP or some
|
||
other communication path with end to end reliability, as they do
|
||
no checking of the data at all. They will only be considered on
|
||
a TCP port which is both reliable and eight bit.
|
||
|
||
The `g' protocol is robust, but requires an eight-bit connection.
|
||
|
||
The `f' protocol is intended for use with X.25 connections; it
|
||
checksums each file as a whole, so any error causes the entire
|
||
file to be retransmitted. It requires a reliable connection, but
|
||
only uses seven-bit transmissions. It is a streaming protocol,
|
||
so while it can be used on a serial port the port must be
|
||
completely reliable and flow controlled; many aren't.
|
||
|
||
The protocols will be considered in the order shown above. This
|
||
means that if neither the `seven-bit' nor the `reliable' command
|
||
are used, the `t' protocol will be used over a TCP connection and
|
||
the `g' protocol will be used over any other type of connection
|
||
(subject, of course, to what is supported by the remote system;
|
||
it may be assumed that all systems support the `g' protocol).
|
||
|
||
Note that currently specifying both `seven-bit true' and
|
||
`reliable false' will not match any protocol. If this occurs
|
||
through a combination of port and dialer specifications, you will
|
||
have to use the `protocol' command for the system or no protocol
|
||
will be selected at all (the only reasonable choice would be
|
||
`protocol f').
|
||
|
||
A protocol list may also be specified for a port (*note port
|
||
file::.) but if there is a list for the system it is used and the
|
||
list for the port is ignored.
|
||
|
||
`protocol-parameter CHARACTER STRING ...'
|
||
CHARACTER is a single character specifying a protocol; the
|
||
remaining strings are a command specific to that protocol which
|
||
will be executed if that protocol is used. The typical command
|
||
will be something like `window 7', hence the name
|
||
protocol-parameter. The particular commands are protocol
|
||
specific.
|
||
|
||
The `g' protocol, supports the following commands, all of which
|
||
take numeric arguments:
|
||
|
||
`window'
|
||
The window size to request the remote system to use. This
|
||
must be between 1 and 7 inclusive. The default is 7.
|
||
|
||
`packet-size'
|
||
The packet size to request the remote system to use. This
|
||
must be a power of 2 between 32 and 4096 inclusive. The
|
||
default is 64, which is the only packet size supported by
|
||
many older UUCP packages.
|
||
|
||
`startup-retries'
|
||
The number of times to retry the initialization sequence.
|
||
The default is 8.
|
||
|
||
`init-retries'
|
||
The number of times to retry one phase of the initialization
|
||
sequence (there are three phases). The default is 4.
|
||
|
||
`init-timeout'
|
||
The timeout in second for one phase of the initialization
|
||
sequence. The default is 10.
|
||
|
||
`retries'
|
||
The number of times to retry sending either a data packet or
|
||
a request for the next packet. The default is 6.
|
||
|
||
`timeout'
|
||
The timeout in seconds when waiting for either a data packet
|
||
or an acknowledgement. The default is 10.
|
||
|
||
`garbage'
|
||
The number of unrecognized bytes to permit before dropping
|
||
the connection. This must be larger than the packet size.
|
||
The default is 10000.
|
||
|
||
`errors'
|
||
The number of errors to permit before dropping the
|
||
connection. The default is 100.
|
||
|
||
`remote-window'
|
||
If this is between 1 and 7 inclusive the window size
|
||
requested by the remote system is ignored and this is used
|
||
instead. This can be useful when dealing with some poor
|
||
UUCP packages. The default is 0, which means that remote
|
||
system's request is honored.
|
||
|
||
`remote-packet-size'
|
||
If this is between 32 and 4096 inclusive the packet size
|
||
requested by the remote system is ignored and this is used
|
||
instead. There is probably no good reason to use this. The
|
||
default is 0, which means that the remote system's request
|
||
is honored.
|
||
|
||
The `f' protocol is intended for use with error-correcting modems
|
||
only; it checksums each file as a whole, so any error causes the
|
||
entire file to be retransmitted. It supports the following
|
||
commands, both of which take numeric arguments:
|
||
|
||
`timeout'
|
||
timeout in seconds before giving up; default 120
|
||
|
||
`retries'
|
||
how often to retry sending a file; default 2
|
||
|
||
The `t' and `e' protocols are intended for use over TCP or some
|
||
other communication path with end to end reliability, as they do
|
||
no checking of the data at all. They both support a single
|
||
command, which takes a numeric argument:
|
||
|
||
`timeout'
|
||
timeout in seconds before giving up; default 120
|
||
|
||
`called-chat STRINGS'
|
||
`called-chat-timeout NUMBER'
|
||
`called-chat-fail STRING'
|
||
`called-chat-seven-bit BOOLEAN'
|
||
`called-chat-program STRINGS'
|
||
These commands may be used to define a chat script that is run
|
||
whenever the local system is called by the system being defined.
|
||
The chat script defined by the `chat' command, on the other hand,
|
||
is used when the remote system is called. This called chat
|
||
script might be used to set special modem parameters that are
|
||
appropriate to a particular system. It is run after protocol
|
||
negotiation is complete, but before the protocol has been
|
||
started. See the `chat' command for details of how the chat
|
||
script is defined, and what the various commands mean. There is
|
||
no default called chat script. If the called chat script fails,
|
||
the call will be aborted.
|
||
|
||
`call-request BOOLEAN'
|
||
The BOOLEAN indicates whether when the local system places the
|
||
call the remote system may request file transfers (in either
|
||
direction). The default is yes.
|
||
|
||
`called-request BOOLEAN'
|
||
Whether when the remote system places the call it may request file
|
||
transfers (in either direction). The default is yes.
|
||
|
||
`request BOOLEAN'
|
||
Identical to `call-request BOOLEAN\ncalled-request BOOLEAN'.
|
||
|
||
`call-transfer BOOLEAN'
|
||
Whether when the local system places the call it may do file
|
||
transfers queued up for the remote system. The default is yes.
|
||
|
||
`called-transfer BOOLEAN'
|
||
Whether when the other system places the call the local system
|
||
may do queued up file transfers. The default is yes.
|
||
|
||
`transfer BOOLEAN'
|
||
Identical to `call-transfer BOOLEAN\ncalled-transfer BOOLEAN'.
|
||
|
||
`local-send STRINGS'
|
||
Specifies that files in the directories named by the STRINGS may
|
||
be sent to the remote system when requested locally (using `uucp'
|
||
or `uux'). The directories in the list should be separated by
|
||
whitespace. A `~' may be used for the public directory (on a UNIX
|
||
system, this is typically `/usr/spool/uucppublic'; it may modified
|
||
with `pubdir'). For example:
|
||
|
||
local-send ~ /usr/spool/ftp/pub
|
||
|
||
Listing a directory allows all files within the directory and all
|
||
subdirectories to be sent. Directories may be excluded by
|
||
preceding them with an exclamation point. For example:
|
||
|
||
local-send /usr/ftp !/usr/ftp/private ~
|
||
|
||
means that all files in `/usr/ftp' or the public directory may be
|
||
sent, except those files in `/usr/ftp/private'. The list of
|
||
directories is read from left to right, and the last directory to
|
||
apply takes effect; this means that directories should be listed
|
||
from top down. The default is the root directory (i.e. any file
|
||
at all may be sent by local request).
|
||
|
||
`remote-send STRINGS'
|
||
Specifies that files in the named directories may be sent to the
|
||
remote system when requested by the remote system. The default
|
||
is `~'.
|
||
|
||
`local-receive STRINGS'
|
||
Specifies that files may be received into the named directories
|
||
when requested by a local user. The default is `~'. On Unix,
|
||
files may only be received into directories that are writeable by
|
||
the world, regardless of how this is set.
|
||
|
||
`remote-receive STRINGS'
|
||
Specifies that files may be received into the named directories
|
||
when requested by the remote system. The default is `~'. On
|
||
Unix, files may only be received into directories that are
|
||
writeable by the world, regardless of how this is set.
|
||
|
||
`command-path STRING'
|
||
Specifies the path (a list of whitespace separated directories)
|
||
to be searched to locate commands to execute. The default is
|
||
from the system dependent header file.
|
||
|
||
`commands STRINGS'
|
||
The list of commands which the remote system is permitted to
|
||
execute locally. For example: `commands rnews rmail'. If the
|
||
value is `ALL' (case significant), all commands may be executed.
|
||
The default is `rnews rmail'.
|
||
|
||
`free-space NUMBER'
|
||
Specify the minimum amount of file system space (in bytes) to
|
||
leave free when receiving a file. If the incoming file will not
|
||
fit, it will be rejected. This will only work when talking to
|
||
another instance of this package, since older UUCP packages do
|
||
not provide the file size of incoming files. There is no
|
||
provision for reserving space, so it is still possible for
|
||
multiple `uucico' daemons to use up all available file space; a
|
||
sufficiently large value for `free-space' will avoid this problem
|
||
to some extent. The default is from the system dependent header
|
||
file. Not all systems may be able to provide the amount of
|
||
available space.
|
||
|
||
`pubdir STRING'
|
||
Specifies the public directory that is used when `~' is specifed
|
||
in a file transfer or a list of directories. This essentially
|
||
overrides the public directory specified in the main
|
||
configuration file for this system only. The default is the
|
||
public directory specified in the main configuration file (which
|
||
defaults to a value from the system dependent header file).
|
||
|
||
`myname STRING'
|
||
Specifies the system name to use when calling the remote system.
|
||
Also, if `called-login' is used and is not `ANY', then when a
|
||
system logs in with the specified login name STRING is used as
|
||
the system name (because the local system name must be determined
|
||
before the remote system has identified itself, using `myname' and
|
||
`called-login' together for any system will set the local name for
|
||
that login; this means that each locally used system name must
|
||
have a unique login name associated with it). This allows a
|
||
system to have different names for an external and an internal
|
||
network. The default is to not use a special local name.
|
||
|
||
The following are used as default values for all systems; they can
|
||
be considered as appearing before the start of the file.
|
||
|
||
timetable Evening Wk1705-0755,Sa,Su
|
||
timetable Night Wk2305-0755,Sa,Su2305-1655
|
||
timetable NonPeak Wk1805-0655,Sa,Su
|
||
time Never
|
||
chat "" \r\c ogin:-BREAK-ogin:-BREAK-ogin: \L word: \P
|
||
chat-timeout 10
|
||
callback n
|
||
sequence n
|
||
request y
|
||
transfer y
|
||
local-send ~
|
||
remote-send ~
|
||
local-receive ~
|
||
remove-receive ~
|
||
command-path [ system dependent ]
|
||
commands rnews rmail
|
||
|
||
|
||
File: uucp.info, Node: port file, Next: dial file, Prev: sys file, Up: Configuration files
|
||
|
||
The port configuration files
|
||
============================
|
||
|
||
The port files may be used to name and describe ports. The first
|
||
command in each file must be `port'. All command up to the next
|
||
`port' command then describe that port. There are different types of
|
||
ports, and each type supports its own set of commands. Each command
|
||
indicates which types of ports support it. There may be many ports
|
||
with the same name; if a system requests a port by name each port with
|
||
that name will be tried until an unlocked one is found.
|
||
|
||
`port STRING'
|
||
Introduces and names a port.
|
||
|
||
`type STRING'
|
||
Define the type of port. The default is `modem'. If this command
|
||
appears, it must immediately follow the port command. The type
|
||
defines what commands are subsequently allowed. Currently the
|
||
types are `modem' (for a modem hookup), `stdin' (for a connection
|
||
through stdin and stdout, as when `uucico' is run as a login
|
||
shell), `direct' (for a direct connection to another system) and
|
||
`tcp' (for a connection using TCP).
|
||
|
||
`protocol STRING'
|
||
Specify a list of protocols to use for this port. This is just
|
||
like the corresponding command for a system (*note sys file::.).
|
||
A protocol list for a system takes precedence over a list for a
|
||
port.
|
||
|
||
`protocol-parameter CHARACTER STRINGS [ any type ]'
|
||
The same command as the `protocol-parameter' command used for
|
||
systems. This one takes precedence.
|
||
|
||
`seven-bit BOOLEAN [ any type ]'
|
||
If the argument is `true', the port is marked as only supporting
|
||
seven bit transfers. This is only used during protocol
|
||
negotiation to force selection of a protocol which works across a
|
||
seven-bit link -- it will not prevent eight bit characters from
|
||
being transmitted. The default is `false'.
|
||
|
||
`reliable BOOLEAN [ any type ]'
|
||
If the argument is `true' (the default), the port is marked as
|
||
being reliable; if the argument is `false', the port is marked as
|
||
being not reliable. This is only used during protocol
|
||
negotiation to force selection of a protocol which works across
|
||
an unreliable communication link. The default is `true'. It
|
||
would be more common to specify this for a dialer rather than a
|
||
port.
|
||
|
||
`device STRING [ modem and direct only ]'
|
||
Names the device associated with this port. If the device is not
|
||
named, the port name is taken as the device. Device names are
|
||
system dependent, but a Unix example would be `/dev/ttyd0'.
|
||
|
||
`baud NUMBER [ modem and direct only ]'
|
||
`speed NUMBER [modem and direct only ]'
|
||
The speed this port runs at. If a system specifies a speed but
|
||
no port name, then all ports which match the speed will be tried
|
||
in order. If the speed is not specified here and is not
|
||
specified by the system, the natural speed of the port will be
|
||
used by default.
|
||
|
||
`baud-range NUMBER NUMBER [ modem only ]'
|
||
`speed-range NUMBER NUMBER [ modem only ]'
|
||
Specify a range of speeds this port can run at. The first number
|
||
is the minimum speed, the second number is the maximum speed.
|
||
These numbers will be used when matching a system which specifies
|
||
a desired speed. The simple `speed' (or `speed') command is
|
||
still used to determine the speed to run at if the system does not
|
||
specify a speed.
|
||
|
||
`carrier BOOLEAN [ modem only ]'
|
||
The argument indicates whether the port supports carrier. If it
|
||
does not, carrier will never be required on this port, regardless
|
||
of what the modem chat script indicates. The default is `true'.
|
||
|
||
`dial-device STRING [ modem only ]'
|
||
Dialing instructions should be output to the named device, rather
|
||
than to the normal port device. The default is to output to the
|
||
normal port device.
|
||
|
||
`dialer STRING [ modem only ]'
|
||
Name a dialer to use. The information is looked up in the dialer
|
||
file. There is no default, and some sort of dialer information
|
||
must be specified to call out on a modem.
|
||
|
||
`dialer STRING ... [ modem only ]'
|
||
Execute a dialer command. If a dialer is named (by using the
|
||
first form of this command, described just above), these commands
|
||
are ignored. They may be used to specify dialer information
|
||
directly in simple situations without needing to go to a separate
|
||
file. There is no default, and some sort of dialer information
|
||
must be specified to call out on a modem.
|
||
|
||
`dialer-sequence STRINGS [ modem only ]'
|
||
Name a sequence of dialers and tokens (phone numbers) to use.
|
||
The first argument names a dialer, and the second argument names
|
||
a token. Then the third argument names another dialer, and so
|
||
on. If there are an odd number of arguments, the phone number
|
||
specified in the system file is used as the final token. The
|
||
token is what is used for `\D' or `\T' in the dialer chat script.
|
||
If the token in this string is `\D', the system phone number
|
||
will be used; if it is `\T', the system phone number will be used
|
||
after undergoing dialcodes translation (a missing final token is
|
||
taken as `\D'). This will currently not work if `dial-device' is
|
||
specified; to handle this correctly will require a more
|
||
systematic notion of chat scripts. Moreover, only the `complete'
|
||
and `abort' chat scripts from the first dialer specified are
|
||
used; also, only the protocol parameters from the first dialer are
|
||
used.
|
||
|
||
`lockname STRING [ modem and direct only ]'
|
||
Give the name to use when locking this port. On UNIX, this is
|
||
the name of the file that will be created in the lock directory.
|
||
It is used as is, so on UNIX it should generally start with
|
||
`LCK..'. For example, if a single port were named both
|
||
`/dev/ttycu0' and `/dev/tty0' (perhaps with different
|
||
characteristics keyed on the minor device number), then the
|
||
command `lockname LCK..ttycu0' could be used to force the latter
|
||
to use the same lock file name as the former.
|
||
|
||
`service STRING [ tcp only ]'
|
||
Name the TCP port number to use. This may be a number. If not,
|
||
it will be looked up in `/etc/services'. If this is not
|
||
specified, the string `uucp' is looked up in `/etc/services'. If
|
||
it is not found, port number 540 (the standard UUCP-over-TCP port
|
||
number) will be used.
|
||
|
||
|
||
File: uucp.info, Node: dial file, Next: Example, Prev: port file, Up: Configuration files
|
||
|
||
The dialer configuration files
|
||
==============================
|
||
|
||
The dialer configuration files define dialers. The first command in
|
||
each file must be a `dialer' command which names the dialer.
|
||
Subsequent commands up to the next `dialer' command are associated
|
||
with the named dialer.
|
||
|
||
`dialer STRING'
|
||
Introduces and names a dialer.
|
||
|
||
`chat STRINGS'
|
||
Specify a chat script to be used to dial the phone. This will be
|
||
read from and sent to the port specified by the `dial-device'
|
||
command for the port, if there is one. The chat script is
|
||
specified just like that for the system file (q.v.) except that
|
||
in send strings the escape sequences `\L' and `\P' may not appear
|
||
and the following escape sequences may appear:
|
||
|
||
`\D'
|
||
send phone number without dialcode translation
|
||
|
||
`\T'
|
||
send phone number with dialcode translation
|
||
|
||
`\M'
|
||
do not require carrier
|
||
|
||
`\m'
|
||
require carrier (fail if not present)
|
||
|
||
See the description of the dialcodes file under the `dialcodefile'
|
||
file above for a description of dialcode translation. If the
|
||
port does not support carrier (as set by the `carrier' command in
|
||
the port file) `\M' and `\m' are ignored. If both the port and
|
||
the dialer support carrier (as set by the `carrier' command in
|
||
the port file and the `carrier' command in the dialer file) every
|
||
chat script implicitly begins with `\M' and ends with `\m'.
|
||
There is no default chat script for dialers.
|
||
|
||
`chat-timeout NUMBER'
|
||
`chat-fail STRING'
|
||
`chat-seven-bit BOOLEAN'
|
||
These commands work just like the corresponding commands in the
|
||
system file. The `chat-fail' command is useful for strings such
|
||
as `chat-fail BUSY' or `chat-fail NO\sDIALTONE'.
|
||
|
||
`chat-program STRINGS'
|
||
Specify a program to run when dialing out on a phone. See the
|
||
`chat-program' command in the system file for more details. The
|
||
following escape sequences may be used:
|
||
|
||
`\D'
|
||
phone number without dialcode translation
|
||
|
||
`\T'
|
||
phone number with dialcode translation
|
||
|
||
`\Y'
|
||
port name
|
||
|
||
`\S'
|
||
port speed
|
||
|
||
`\\'
|
||
backslash
|
||
|
||
In other words, `\L', `\P' and `\Z' may not be used, but `\D' and
|
||
`\T' may be. If the program changes the port in any way (e.g.
|
||
sets parity) the changes will be preserved during protocol
|
||
negotiation, but once the protocol is selected it will change the
|
||
port settings.
|
||
|
||
If both `chat-program' and `chat' are specified, the program is
|
||
run before the chat script. If `chat-program' is not used, no
|
||
program is run.
|
||
|
||
`dialtone STRING'
|
||
A string to output when dialing the phone number which causes the
|
||
modem to wait for a secondary dial tone. This is used to
|
||
translate the `=' character in a phone number. If it is not
|
||
defined, the `=' character is dropped. The default is a comma.
|
||
|
||
`pause STRING'
|
||
A string to output when dialing the phone number which causes the
|
||
modem to wait for 1 second. This is used to translate the `-'
|
||
character in a phone number. If it is not defined, the `-'
|
||
character is dropped. The default is a comma.
|
||
|
||
`carrier BOOLEAN'
|
||
If the argument is `true', the dialer supports the modem carrier
|
||
signal. After the phone number is dialed, `uucico' will insist
|
||
that carrier is on. One some systems, it will be able to wait
|
||
for it. If the argument is `false', carrier will not be
|
||
required. The default is `true'.
|
||
|
||
`carrier-wait NUMBER'
|
||
If the port is supposed to wait for carrier, this may be used to
|
||
indicate how many seconds to wait. The default is 60 seconds.
|
||
Only some systems support waiting for carrier.
|
||
|
||
`dtr-toggle BOOLEAN BOOLEAN'
|
||
If the first argument is `true', then DTR is toggled before using
|
||
the modem. This is only supported on some systems and some
|
||
ports. The second BOOLEAN need not be present; if it is, and it
|
||
is `true', the program will sleep for 1 second after toggling DTR.
|
||
The default is not to toggle DTR.
|
||
|
||
`complete-chat STRINGS'
|
||
`complete-chat-timeout NUMBER'
|
||
`complete-chat-fail STRING'
|
||
`complete-chat-seven-bit BOOLEAN'
|
||
`complete-chat-program STRINGS'
|
||
These commands define a chat script which is run when a call is
|
||
finished normally. This allows the modem to be reset. There is
|
||
no default. The chat script may use any of the normal escape
|
||
sequences, but not `\L', `\P', `\D', `\T', `\M' or `\m'. The
|
||
program string may use only `\Y', `\S', and `\\'.
|
||
|
||
`complete STRING'
|
||
This is a simple use of `complete-chat'. It is equivalent to
|
||
`complete-chat "" STRING'; this has the effect of sending STRING
|
||
to the modem when a call finishes normally.
|
||
|
||
`abort-chat STRINGS'
|
||
`abort-chat-timeout NUMBER'
|
||
`abort-chat-fail STRING'
|
||
`abort-chat-seven-bit BOOLEAN'
|
||
`abort-chat-program STRINGS'
|
||
These commands define a chat script to be run when a call is
|
||
aborted. They may be used to interrupt and reset the modem.
|
||
There is no default. The set of escape sequences permitted are
|
||
those that are permitted for the `complete-chat' set of commands.
|
||
|
||
`abort STRING'
|
||
If the call is somehow aborted, STRING is sent to the modem. If
|
||
this is not defined, the dialer complete string is sent instead.
|
||
The string may contain any escape sequences defined for the `send'
|
||
command. The default is to send nothing when the program is
|
||
aborted.
|
||
|
||
This is a simple use of `abort-chat'. It is equivalent to
|
||
`abort-chat "" STRING'; this has the effect of sending STRING to
|
||
the modem when a call is aborted.
|
||
|
||
`protocol-parameter CHARACTER STRINGS'
|
||
Set protocol parameters, as the similar command in the system
|
||
configuration file or the port configuration file. These
|
||
parameters take precedence, then those for the port, then those
|
||
for the system.
|
||
|
||
`seven-bit BOOLEAN'
|
||
If the argument is `true', the dialer is marked as only supporting
|
||
seven bit transfers. This is only used during protocol
|
||
negotiation to force selection of a protocol which works across a
|
||
seven-bit link -- it will not prevent eight bit characters from
|
||
being transmitted. The default is `false'. It would be more
|
||
common to specify this for a port rather than a dialer.
|
||
|
||
`reliable BOOLEAN'
|
||
If the argument is `true' (the default), the dialer is marked as
|
||
being reliable; if the argument is `false', the dialer is marked
|
||
as being not reliable. This is only used during protocol
|
||
negotiation to force selection of a protocol which works across
|
||
an unreliable communication link. The default is `true'.
|
||
|
||
|