Configuration files for new UUCP package (long)
Ian Lance Taylor
for beta test in a week or two (I'll solicit beta testers when I'm
ready; no need to volunteer now). The package will be released under
the GNU Public License.
In the meantime, I am looking for some feedback on the system of
configuration files that I am using. I don't find either the
traditional L.sys L-devices L.cmds or the HDB Systems Dialers
Permissions configuration files particularly easy to understand or
sufficiently flexible to specify everything that is useful for a UUCP
system; they are good, but I arrogantly think I can do better. I
therefore set up my own system. I hope to write AWK scripts to
convert the traditional styles into my style.
The rest of this post describes the configuration files that I have
implemented. My goal here, as for anybody who designs configuration
files, is to allow a simple setup to be implemented simply while also
allowing a complex setup to be handled completely. I welcome any
comments. I intend to keep a list of people who have made helpful
suggestions or contributions; if you prefer to be anonymous, please
let me know.
*** The configuration files
All the configuration files follow a simple line-oriented keyword
value format. The first word on each line is a keyword of some sort
(empty lines are ignored). The rest of the line is interpreted
according to the keyword. Most keywords are followed by numbers,
boolean values or simple strings (with no embedded spaces). The '#'
character is used for comments, and everything from a '#' to the end
of the line is ignored. Everything after the keyword must be on the
same line. A BOOLEAN may be specified as 'y', 'n', 'Y', 'N', 't',
'f', 'T', or 'F'.
*** The main configuration file
The main configuration file may be specified by the -I option to
uucico. The default file location is set in the system dependent
header file (sysdep.h). As all the values that may be specified in it
also have defaults, there need not be a main configuration file at
all.
nodename STRING
hostname STRING
uuname STRING
These keywords are identical. They specify the UUCP name of the local
host. If there is no configuration file, an appropriate function will
be used to get the host name, if possible.
spool STRING
Specify the spool directory. The default is from sysdep.h. Command
files, work files, temporary files, log files, etc., are stored in
this directory and in subdirectories of it.
sysfile STRING
Specify the system file. The default is from sysdep.h. This file
holds information about other systems with which this system
communicates, and is described further below.
portfile STRING
Specify the port file. The default is from sysdep.h. This file
describes ports which are used to call other systems and accept calls
from other systems. It is described further below. It is optional.
dialfile STRING
Specify the dial file. The default is from sysdep.h. This file
describes dialing devices (modems). It is described further below.
It is optional.
dialcodefile STRING
Specify the dialcode file. The default is from sysdep.h. This file
specifies dialcodes that may be used when sending phone numbers to a
modem. This permits using the same set of phone numbers in different
area-codes and phone systems, by using dialcodes to specify the
calling sequence. When a phone number goes through dialcode
translation, the leading alphabetic characters are stripped off. The
dialcode file is read line by line, just like any other configuration
file, and when a line is found whose first word is the same as the
leading characters from the phone number, the second word on the line
(which would normally consist of numbers) replaces the dialcode in the
phone number. This file is optional.
pubdir STRING
Specify the public directory. The default is from sysdep.h. On Unix,
when a file is named using a leading ~/, it is taken from or to the
public directory.
callfile STRING
Specify the call out login name and password file. The default is
from sysdep.h. If the call out login name or password for a system
are given as "*" (see the description of the system configuration
file, below), this file is read to get the real login name or
password. Each line in the file has three words: the system name, the
login name, and the password. The intention is to permit the system
file to be publically readable; this file must obviously be kept
secure. This file is optional.
passwdfile STRING
Specify the password to use for login names when uucico is doing its
own login prompting. The default is from sysdep.h. Each line in the
file has two words: the login name and the password. This file is
optional, although it must exist if uucico is to present its own login
prompts.
logfile STRING
Name the log file. The default is from sysdep.h. Logging information
is written to this file.
statfile STRING
Name the statistics file. The default is from sysdep.h. Statistical
information about file transfers is written to this file.
debug NUMBER
Set the debugging level. The default is 0. Numbers between 0 and 9
are relevant; the larger the number, the more debugging information is
output. This may be overridden by the -x switch to uucico.
unknown STRING ...
The STRING and subsequent arguments are treated as though they
appeared in the system file (see below for a full description). They
are used to apply to any unknown systems that may call in, probably to
set file transfer permissions and the like. If the ``unknown''
command is not used, unknown systems are not permitted to call.
*** The system configuration file
This file describes 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. 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 command 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. 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).
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.
alias STRING
Specify an alias for the current system. The alias may be used by
local uucp and uux commands. This will also be used when a system
calls in, so that the name used when spooling commands from a system
may be different from the one the system claims for itself. The
default is to have no aliases.
time STRING
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 ``time'' command may appear multiple times in a single alternate.
The default value is ``Never''.
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 in 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. 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.
Note that the ``timegrade'' command serves two purposes: 1) if there
is no job of sufficiently high grade the system will not be called 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. 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 in 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 other 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 be appear multiple times without
using ``alternate''. If this command does not appear, 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. The
size of a file requested from the remote system (as opposed to a file
sent to the remote system) will only be checked if the other system is
running this package (older UUCP code can not handle a maximum size
request). This command may appear multiple times in a single
alternate. If this command does not appear, there are no size
restrictions.
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.
[ The timetable command doesn't really belong here; perhaps it should
be in the general configuration file? ]
baud NUMBER
Specify the baud rate to use when calling 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, the baud rate is used to open the port at a
specified baud. 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 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'').
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
Give a phone number to call. A '=' 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). The ``phone'' command
is ignored for a non-modem port. 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.
chat STRINGS
Specify the chat script to use when calling the system. The chat
script is a series of expect/send pairs. The first expect may be "",
meaning to begin by sending. The pairs are separated by blank space;
to include blank space in the string, an escape sequence must be used.
An expect string may include subsend and subexpect strings separated
by hyphens; if the expect string is not seen, the subsend string will
be sent and the next subexpect string will be searched for. To
include a hyphen in an expect string, an escape sequence must be used.
A carriage return ('\r') is sent after each send string, unless \c
appears at the end. A sample chat script appears below. The
following escape sequences are defined in chat scripts:
"" -- expect a null string (i.e. skip the expect phase)
EOT -- send an end of transmission character (^D)
BREAK -- send a break character (may not work on all systems)
\b -- a backspace character ('\b')
\c -- suppress trailing carriage return at end of send string
\d -- delay sending for 1 second
\K -- same as BREAK (for BNU compatibility)
\n -- a newline character ('\n')
\N -- a null character (for BNU compatibility)
\p -- pause sending for a fraction of a second
\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.
\L -- send the login name
\P -- send the password
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, use "" as the
next expect or send string (e.g. \x0d "" dave).
Note that in some versions of UUCP, \b denotes a break character.
The default chat script is:
"" \r\c ogin:-BREAK-ogin:-BREAK-ogin: \L word: \P
Note that carriage return characters are sent after the break
characters, and after the login name and the password.
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 60.
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 STRING
Specify the login name that the system must use when calling in. If
STRING is "ANY" (e.g. ``called-login ANY'') any login name may be used
(this is only useful to override a default specified in this file).
The case of STRING 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.
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 off 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 off by default.
protocols 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,
``protocols g''. By default the set of protocols compiled into the
uucico daemon is used.
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. Currently the 'g' protocol [ which is
the only one implemented anyhow ] supports ``window'',
``packet-size'', ``startup-retries'', ``init-retries'',
``init-timeout'', ``retries'', ``timeout'' and ``garbage'' all of
which take numeric arguments.
call-request BOOLEAN
The BOOLEAN indicates whether when the local system places the call it
may request file transfers (in either direction). The default is yes.
called-request BOOLEAN
Whether when the other 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 ~.
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 ~.
remote-receive STRINGS
Specifies that files may be received into the named directories when
requested by the remote system. The default is ~.
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
``ANY'' (case significant), any commands may be executed. The default
is from the system dependent header file.
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.
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 not use to 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 60
callback n
sequence n
request y
transfer y
local-send ~
remote-send ~
local-receive ~
remove-receive ~
command-path [ system dependent ]
commands rnews rmail
*** The port configuration file
The port file may be used to name and describe ports. The first
command in the 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.
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
``modem'' (for a modem hookup), ``stdin'' (for a connection through
stdin and stdout, as when uucico is run as a login shell) and
``direct'' (for a direct connection to another system) are defined.
[ In the future types ``tcp'' and ``ftp'' should be added. The type
``ftp'' should allow use of uucp to perform FTP transfers, which would
be convenient to do the transfers late at night, for example. ]
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 ]
The baud rate this port runs at. If a system specifies a baud rate
but no port name, then all ports which match the baud rate will be
tried in order. If the baud rate is not specified here and is not
specified by the system, the natural baud rate of the port will be
used by default.
carrier BOOLEAN [ modem only ]
If the argument is TRUE, then after dialing the phone number uucico
will wait for carrier to come on. This is only supported on a few
systems. If the argument is FALSE, soft carrier is forced if the
system supports it. The default is FALSE.
carrier-wait NUMBER [ modem only ]
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.
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.
protocol-parameter CHARACTER STRINGS [ any type ]
The same command as the protocol-parameter command used for systems.
This one takes precedence.
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, 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.
*** The dialer configuration file
The dialer configuration file defines dialers. The first command in
the 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
A set of expect/send pairs, just like a login script, used to dial the
phone. All the escape sequences defined for the login script may be
used (except for \L and \P) and the following escape sequences may
also be used:
\D -- send phone number without dialcode translation
\e -- disable echo checking on send
\E -- enable echo checking (wait for echo before continuing)
\T -- send phone number with dialcode translation
When echo checking is enabled then after writing each character to the
dialer the program will wait until the character is echoed. There is
no default.
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 is 60.
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.
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.
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 STRING
When the call is finished normally, STRING is sent to the modem. The
string may contain escape sequences just as a send string in a chat
script. The default is to send nothing on completion.
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 escape sequences just as a send string in a chat
script. The default is to send nothing when the program 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.
[ Currently these only take effect when dialing out, not when
accepting a call ]
*** Brief example
Here is the main configuration file and the system configuration file
actually used here to call uunet. There is also a call out password
file which, for obvious reasons, is not shown.
The main configuration file (this would be needed if the local name of
this system were airs or airs.airs.com):
nodename airs
The system configuration file (this controls a Telebit 2500 which
calls uunet; uunet tends to have slow response time, so the timeouts
are forced to higher values; the window and packet sizes used for the
'g' protocol are the defaults anyhow, and are the correct values to
trigger Telebit UUCP spoofing).
system uunet
call-login *
call-password *
time night
phone 7389449
chat-timeout 120
port type modem
port device /dev/ttyd0
port baud 19200
port carrier true
port dialer chat "" ATZ\r\d\c OK ATDT\D
port dialer complete \d\d+++\d\dATH\r\c
port dialer abort \d\d+++\d\dATH\r\c
protocol-parameter g window 3
protocol-parameter g packet-size 64
protocol-parameter g timeout 20
protocol-parameter g retries 10
--
Ian Taylor | i...@airs.com | First to identify quote wins free e-mail message:
``Learning is not like a coin, which remains physically whole even through
the most infamous transactions; it is, rather, like a very handsome dress,
which is worn out through use and ostentation.''
Wolfgang S. Rupprecht
>I am nearing completion of a new UUCP package, which I hope to release
>for beta test in a week or two (I'll solicit beta testers when I'm
>ready; no need to volunteer now). The package will be released under
>the GNU Public License.
Some things that you might want to have:
1) a chat/dialer failed string.
Often modems will respond with ERROR, NO DIAL TONE,
VOICE, NO CARRIER, etc if something goes wrong.
If the error isn't detected directly, then uucp sits
waiting for its expect string. If the char string as
several wait-send-wait-send's then uucp can be waiting
for a number of timeouts. During this time the modem
will answer the phone, but the remote system won't be
allowed to log in because a dialout uucp is still on
the modem line (as opposed to a getty as the remote is
expecting). If the remote is clever enough to
identify and exploit this condition it can lead to
some nasty security problems...
In short, if uucp aborts cleanly at the modem's
failure string one can solve several problems.
2) slave-mode modem setting commands.
If the connection is from a certain site then an
optional chat script is run. This, for example,
allows one to set special per-system PEP packet
parameters in the receiving modem.
-wolfgang
--
Wolfgang Rupprecht wolf...@wsrcc.com (or) uunet!wsrcc!wolfgang
Snail Mail Address: Box 6524, Alexandria, VA 22306-0524
Guy Harris
> Often modems will respond with ERROR, NO DIAL TONE,
> VOICE, NO CARRIER, etc if something goes wrong.
...
> In short, if uucp aborts cleanly at the modem's
> failure string one can solve several problems.
And it'd be especially nice if either the string itself, or some string
specified as being the string to log when that "dialer failed" string is
seen, were put in UUCP's log as the reason for the failure of the call,
so that inspecting the log can tell you if you were having trouble
getting dial tone, or if the phone just kept ringing, or if you got a
busy signal, or....
Leslie Mikesell
>In the meantime, I am looking for some feedback on the system of
>configuration files that I am using. I don't find either the
>traditional L.sys L-devices L.cmds or the HDB Systems Dialers
>Permissions configuration files particularly easy to understand or
>sufficiently flexible to specify everything that is useful for a UUCP
>system; they are good, but I arrogantly think I can do better. I
>therefore set up my own system. I hope to write AWK scripts to
>convert the traditional styles into my style.
No! No! A thousand times NO! If you feel you *must* invent a new
syntax for something that is already fairly well done, please
do it the other way around. Make the program able to parse existing
Sysfiles, System, Devices, Permissions, etc. (noting that there may
be more than one of some of these files as specified in Sysfiles). Allow
people to create files in your "new and improved" syntax and provide
a translation program back to the HDB style files.
There are a few things lacking in normal HDB which be fixed by adding to
the chat script escape codes:
modem control: already exists in recent versions as \M to ignore carrier and
\m to require carrier at specific places in the chat.
settable timeouts: could be \w{sec} to control how long to wait for the
current "expect" string(s).
multi-way branching: could be \o{expect send ...} to specify an alternative
continuation of the chat if this "expect" string is seen before the
primary one, or \O{expect label} to branch to a completely different
entry in the Dialers file. A variation of this could allow "calling"
the other script and returning to the current one. More than one
alternative "expect" could be pending at once.
some additional ioctl() type functions, notably setting the speed: could
be \S{speed}. In combination with the above branching you could observe
the CONNECT nnnn messages from modems and switch the port speed to
match on machines that don't do hardware flow control.
an explicit FAIL: could be \F for use in the alternative branching to
bail out on BUSY, NO CARRIER, etc. without waiting for a timeout.
In addition, there should be some way to execute a chat script as a received
call is answered and again as uucico starts up on a received call to allow
putting the modem/network/whatever into the optimal mode.
Les Mikesell
l...@chinet.chi.il.us
Ian Lance Taylor
>In article <23...@airs.com> i...@airs.com (Ian Lance Taylor) writes:
>>In the meantime, I am looking for some feedback on the system of
>>configuration files that I am using. I don't find either the
>>traditional L.sys L-devices L.cmds or the HDB Systems Dialers
>>Permissions configuration files particularly easy to understand or
>>sufficiently flexible to specify everything that is useful for a UUCP
>>system; they are good, but I arrogantly think I can do better. I
>>therefore set up my own system. I hope to write AWK scripts to
>>convert the traditional styles into my style.
>No! No! A thousand times NO! If you feel you *must* invent a new
>syntax for something that is already fairly well done, please
>do it the other way around. Make the program able to parse existing
>Sysfiles, System, Devices, Permissions, etc. (noting that there may
>be more than one of some of these files as specified in Sysfiles). Allow
>people to create files in your "new and improved" syntax and provide
>a translation program back to the HDB style files.
Supporting all of the features permitted by my ``new and improved''
syntax would require a number of extensions to HDB files, which I feel
are already sufficiently cryptic. Adding a number of switches to chat
scripts, as you suggest, is not going to make the files any easier to
understand and edit. I mean, I can understand and modify termcap and
terminfo entries, but I don't enjoy it. In this day and age, I would
rather force the computer to understand a syntax that is easy for me
to create and understand even if I only look at the files every six
months. That was my goal with my configuration files, although I
doubt I succeeded as well as I hoped.
A more appropriate use of a translation program, in any case, would be
to some sort of database format that could be read very quickly. I
don't know how uunet handles their massive number of systems, but I
hope they do something more clever than looking through Systems and
then Devices for every call they place.
What I might do at some point is make my program read standard files
AS WELL AS my configuration files. This won't happen before the beta
test, though.
I am open to persuasion though; so far only a couple of people have
complained about the general format I suggested.
> modem control: already exists in recent versions as \M to ignore carrier and
> \m to require carrier at specific places in the chat.
I allow checking for carrier, but only after the chat is complete;
making this more flexible is probably worth considering.
> settable timeouts: could be \w{sec} to control how long to wait for the
> current "expect" string(s).
I support a single chat timeout, but not an adjustable one. Another
idea worth considering.
> multi-way branching: could be \o{expect send ...} to specify an alternative
> continuation of the chat if this "expect" string is seen before the
> primary one, or \O{expect label} to branch to a completely different
> entry in the Dialers file. A variation of this could allow "calling"
> the other script and returning to the current one. More than one
> alternative "expect" could be pending at once.
This could get very complex. Guy Harris suggested creating enough
auxiliary programs to let a shell file run the chat. I think I might
prefer to pursue that (eventually) rather than slowly head toward a
chat programming language.
> some additional ioctl() type functions, notably setting the speed: could
> be \S{speed}. In combination with the above branching you could observe
> the CONNECT nnnn messages from modems and switch the port speed to
> match on machines that don't do hardware flow control.
This is certainly a good argument for branching of some sort.
Following a suggestion by John Cowan I have added chat script commands
``send'', ``expect'', ``subsend'' and ``subexpect'' to allow chat
scripts to be written on several lines and without the special
treatment of '-'. This would make it possible to add commands at any
point, although at the moment none are supported.
> an explicit FAIL: could be \F for use in the alternative branching to
> bail out on BUSY, NO CARRIER, etc. without waiting for a timeout.
I've already implemented this, as a ``chat-fail'' command; it was
suggested by several people.
>In addition, there should be some way to execute a chat script as a received
>call is answered and again as uucico starts up on a received call to allow
>putting the modem/network/whatever into the optimal mode.
This is also been suggested, and should get in.
Thanks for the comments.
The Squire, Phish
completely disregarding it is foolish, at best, IMHO. Personally, my attitude
is that the best standard you can hope to achieve is allowing a BNU control
fileset (systems, permissions, et. al.) to run unadultrated as imported over,
and then ADD your enhancements thereafter. A program to make this simple
(full screen configure, for example) would be the way to go.
Making your own standard from scratch is going to find a lot of people asking
"how do I _________" to their feeds, and the BNU running admins saying, "Huh?
What the hell are you running?!"
My 2 cents.
--
++Christopher(The Squire, Phish); (805) 542-0336/H | Home of the 21K .plan
ch...@zeus.calpoly.edu (129.65.16.21) 756-2005/W | Finger at your own risk!
-----------------------------------------------------^-------------------------
I hereby disclaim EVERYTHING. Flames to /dev/pooperscooper.
Peter da Silva
> No! No! A thousand times NO! If you feel you *must* invent a new
> syntax for something that is already fairly well done, please
> do it the other way around.
Yes! Yes! A thousand times yes!
The syntax he is using is more general than the HDB files, and while he
might be able to use the HDB files to get the same effect, it'd be pretty
kludgey.
The chat script syntax you're describing might cover some of the problems,
but how about the connect script (and I would suggest a terminate script
as well)? Or the wide variety of alternates?
--
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
Leslie Mikesell
>Supporting all of the features permitted by my ``new and improved''
>syntax would require a number of extensions to HDB files, which I feel
>are already sufficiently cryptic. Adding a number of switches to chat
>scripts, as you suggest, is not going to make the files any easier to
>understand and edit. I mean, I can understand and modify termcap and
>terminfo entries, but I don't enjoy it. In this day and age, I would
>rather force the computer to understand a syntax that is easy for me
>to create and understand even if I only look at the files every six
>months. That was my goal with my configuration files, although I
>doubt I succeeded as well as I hoped.
Fine: write an interactive program to chat with the naive user and
generate the config files for him. I'll ignore it just like I do
the ones that come with SysVr3's FACE package because it probably
won't do what I want and even if it does I won't know how to diagnose
any problems later. If I look at the debug output from a failing
chat script that I wrote myself I can usually tell why it doesn't
work.
I have ports connected to things that look like X.25 PADs, a variety of
modems, some of which can call other modems connected to things that
look like X.25 PADS, and some network and direct-connect links. The
current HDB setup supports all of this, and allows cu, uucico and
some of my own programs to dial using some of the same and some
different devices and dialer scripts using the multiple configuration
file definitions in Sysfiles. I have multiple Systems files entries
for many of the machines, and multiple dialer scripts per device (selected
by the "modem-class" feature. My Permissions file allows me to pretend to
be several different machines depending on the hostname of outbound calls
or the login name of inbound calls. It's not clear to me how your
"new-and-impoved" syntax would support, much less enhance this kind of
setup. Besides, the problem is not particularly technical, its a matter
of what the existing uucp user (currently running at the other end of
the connection the new user is trying to make) knows. You are throwing
this out the window by inventing a totally new setup convention. The
new things can be added as sub-fields if they are call-related (as
some recent versions do with the grade info) or put in a different file
altogether if they are protocol-related.
>A more appropriate use of a translation program, in any case, would be
>to some sort of database format that could be read very quickly. I
>don't know how uunet handles their massive number of systems, but I
>hope they do something more clever than looking through Systems and
>then Devices for every call they place.
I can't imagine a machine where parsing the data would consume measurable
time compared to reading it from disk in the first place, so I'd consider
the storage format to be irrelevant. The one thing that strikes me as
inefficient on a busy machine (and where else do you care?) is the way
that outbound jobs are found and then an available device is sought.
On a busy machine you are likely to do a lot of work before finding
out that the appropriate devices are all busy, especially if you are
configured to use several different device types for different groups
of machines. I'd like to see a way to make an exiting uucico go find
another job that can be delivered over the device it is just finished
with. Perhaps the information needed to do that could be cached on
the initial pass through the files so a quick check for files queued
for the relevant machines would be all that is required, or a dedicated
scheduler could match things up.
>> multi-way branching: could be \o{expect send ...} to specify an alternative
>This could get very complex. Guy Harris suggested creating enough
>auxiliary programs to let a shell file run the chat.
I forgot about that one, \!{cmd}, of course. I'd still like branching,
though. Pretty much everything else can be built around a single
test-and-branch primitive. And throw in an explicit write-log-entry.
Maybe \L{text}, with some %escape substitutions if you are ambititious,
to fill in the current time, file size, last line of chat input received,
current "expect" and the like.
Also, it wasn't clear from your config file description how you tie
the permissions of an inbound caller to the password that was given
when they log in. In HDB, this is the use for the LOGNAME= entry in
the Permissions file. You really don't want to trust the machine
name given after the protocol starts up.
Les Mikesell
l...@chinet.chi.il.us
Chip Salzenberg
> some additional ioctl() type functions, notably setting the speed: could
> be \S{speed}.
SCO UUCP understands the expect string "Speed" to have this meaning.
--
Chip Salzenberg at Teltronics/TCT <ch...@tct.com>, <uunet!pdn!tct!chip>
"He's alive; he's fat; and he's fighting crime. He's Elvis: FBI."
Leslie Mikesell
>The syntax he is using is more general than the HDB files, and while he
>might be able to use the HDB files to get the same effect, it'd be pretty
>kludgey.
I wouldn't say it is more general than HDB because it lacks the concept
of modem classes. Consider what you would have to do to describe the
possible connections with a group of ports connected something like
an X.25 PAD and another group connected to modems running at the same
speed, with some systems reachable by only one or the other group, some
by both. In HDB you can add a letter to the speed to qualify the class
and the Devices file ties particular devices to one or several of the
modem class entries and thus to the associated Dialer script.
This could be added easily by making the "baud" entry in the Systems
entries symbolic and matching it with something in the ports section where
the real baud would be defined. But that's not what I want...
I'll admit to having a hidden agenda here. I'm perfectly happy with
the way HDB uucp, uux, and uuxqt work, but I have a few bones to pick
with uucico and cu. So, what I'm really after is a drop-in replacement
for uucico that won't require duplicating all my setup files in a different
syntax.
>The chat script syntax you're describing might cover some of the problems,
>but how about the connect script (and I would suggest a terminate script
>as well)? Or the wide variety of alternates?
The syntax for the dialing and login scripts should be identical, and it
should be possible to split out a dial() library routine that could be
used by other programs. This was half-heartedly attempted in sysV but
not in a way that was useful with HDB (and the dial interface used by
that routine doesn't provide enough information to do it right).
The reason that most of the enhancements need to be done within the
chat script syntax is that we need to be able to respond to what our
increasingly intelligent devices tell us. A disconnect script is a
good idea - as it happens, everything I'm using resets itself when DTR
is dropped, but now that I think about it I recall throwing out everything
that didn't because it wouldn't work with uucp.
Les Mikesell
l...@chinet.chi.il.us
Peter da Silva
> In article <56F...@xds13.ferranti.com> pe...@ficc.ferranti.com (Peter da Silva) writes:
> >The syntax he is using is more general than the HDB files, and while he
> >might be able to use the HDB files to get the same effect, it'd be pretty
> >kludgey.
> I wouldn't say it is more general than HDB because it lacks the concept
> of modem classes.
Point to you. He could, however, add modem classes wuite easily.
On the other hand it *is* easily extensible to handle various problems I
have with modems that need to be "put back to normal mode" after a transfer.
And it does resolve some of the problems I have with systems that can be
accessed via a lot of different numbers at the same speed, some of which might
be busy or dead. HDB handles part of that but extensing it to deal with the
systems I talk to cleanly would be really gross.
Plus, I'm not enamoured of the existing UUCP files, either set. The chat script
syntax is too simple... I'd like to be able to say (TCL syntax):
send AAAAAA
sleep 1
send AT\r
expect OK continue
timeout 30 {
send "+++"
sleep 1
send ATH\r
expect OK
timeout 30 fail
}
send ATDT$NUMBER\r
expect BUSY fail
expect "NO CARRIER" fail
expect "CONNECT 300" { baud 300 }
expect "CONNECT 1200" { baud 1200 }
expect "CONNECT 2400" { baud 2400 }
expect "CONNECT 9600" { baud 9600 }
expect "CONNECT FAST/COMP/UUCP" { baud 19200; window 3 }
expect "CONNECT V32" { baud 19200 }
expect "CONNECT"
timeout 30 fail
Then, on login:
send \r
expect ogin:
expect host: {
send uucp
expect ogin:
expect "not found" fail
timeout 30 fail
}
timeout 30 {
send \r
expect ogin:
expect host: {
send uucp
expect ogin:
expect "not found" fail
timeout 30 fail
}
timeout 30 fail
}
send $LOGIN
expect word: { send $PASSWORD }
expect telnet> {
send "quit\r"
expect ogin: { send $LOGIN }
timeout 10 fail
expect word: { send $PASSWORD }
timeout 30 fail
}
timeout 30 fail
Personally, I'd rather specify a modem *class* as a separate field or
keyword, instead of patching it onto the speed string. Or, rather, I'd like
what is currently the 'speed string' to be replaced by an additional level
of indirection like gettydefs.
> This could be added easily by making the "baud" entry in the Systems
> entries symbolic and matching it with something in the ports section where
> the real baud would be defined. But that's not what I want...
that is *exactly* what I want.
> >The chat script syntax you're describing might cover some of the problems,
> >but how about the connect script (and I would suggest a terminate script
> >as well)? Or the wide variety of alternates?
> The syntax for the dialing and login scripts should be identical, and it
> should be possible to split out a dial() library routine that could be
> used by other programs.
Sounds like a good idea, but how do you specify those suckers in the HDB files?
That's the problem.
> A disconnect script is a
> good idea - as it happens, everything I'm using resets itself when DTR
> is dropped, but now that I think about it I recall throwing out everything
> that didn't because it wouldn't work with uucp.
I'd like to have that luxury. Right now we usually don't have problems, but
we had to do gross things in the dial string (ATDTxxxxxxx;ATE0Q1O) to make
it work.
Rich Salz
look at the scripting language that comes with the BBN dialupip package.
Look at src/diald/runscript.c. It's fairly nice, giving timeouts logging,
parameter substitution, and alternates. Source is freely
redistributable. Among other places, on UUNET:
networking/dialupip2.0.tar.Z
Do NOT ask me for copies.
/r$
--
Please send comp.sources.unix-related mail to rs...@uunet.uu.net.
Use a domain-based address or give alternate paths, or you may lose out.
Ralf E. Stranzenbach
uucico connects/disconnects a systen. I do not mean shell scripts for dial/in.
I would like to do some accounting and batching when the connection
establishes.
- ralf
--
Ralf E.Stranzenbach - (NeXT)-Mail: ra...@reswi.ruhr.de
Fido: via 2:241/5800.12
(Voice)-Phone: +49 2302 / 68403
Ian Lance Taylor
>I have ports connected to things that look like X.25 PADs, a variety of
>modems, some of which can call other modems connected to things that
>look like X.25 PADS, and some network and direct-connect links. The
>current HDB setup supports all of this, and allows cu, uucico and
>some of my own programs to dial using some of the same and some
>different devices and dialer scripts using the multiple configuration
>file definitions in Sysfiles. I have multiple Systems files entries
>for many of the machines, and multiple dialer scripts per device (selected
>by the "modem-class" feature. My Permissions file allows me to pretend to
>be several different machines depending on the hostname of outbound calls
>or the login name of inbound calls. It's not clear to me how your
>"new-and-impoved" syntax would support, much less enhance this kind of
>setup.
I don't see how this particular argument addresses the issues of
configuration files at all. Either my code supports this stuff or it
doesn't; if it supports it, it could be specified either however HDB
does it or using the configuration style presented earlier. Since my
``new-and-improved'' syntax is extensible, it can be extended.
My code does not support modem classes, although they sound like a
good idea. You can get the same effect by tediously listing the ports
that are permissible for each system. Obviously, I should add modem
classes. My code does support changing the name of the local system,
using the ``myname'' command.
>Also, it wasn't clear from your config file description how you tie
>the permissions of an inbound caller to the password that was given
>when they log in. In HDB, this is the use for the LOGNAME= entry in
>the Permissions file. You really don't want to trust the machine
>name given after the protocol starts up.
You use the ``called-login'' command. That will let you set
permissions according to the login name used; there is no way to set
permissions according to the password used, but HDB doesn't support
that either.
Leslie Mikesell
>I don't see how this particular argument addresses the issues of
>configuration files at all. Either my code supports this stuff or it
>doesn't; if it supports it, it could be specified either however HDB
>does it or using the configuration style presented earlier. Since my
>``new-and-improved'' syntax is extensible, it can be extended.
Right - as I said earlier, the problem isn't particularly technical.
I'll try again with a more focused argument. There are two reasons
to stick with the HDB syntax as closely as possible. One is the
ability to continue using portions of the HDB package (uux, uuxqt,
uustat, uusched, cu, etc.) while replacing uucico as the transport
agent without having to maintain parallel files that need to be
syncronized. And in my case there are unrelated programs that do
outbound calling that share the devices and dialers files. The
other is the existing base of knowledge about the HDB format.
A new user is most likely going to be trying to connect with an
existing site where the person helping set up the login script
will know the HDB style entries needed to get in.
The most-needed extensions are in the dialer scripts anyway. I haven't
seen any other complaints that couldn't be resolved with the HDB
setup files and extending the chat syntax wouldn't affect any of the
other utilities.
By the way, does "extensible" mean that your parser ignores unknown
keywords? If not, does it just mean that you feel free
to change it whenever you like?
>My code does not support modem classes, although they sound like a
>good idea. You can get the same effect by tediously listing the ports
>that are permissible for each system. Obviously, I should add modem
>classes.
You'll need something similar if you want to support networks the
way the HDB system does anyway.
>You use the ``called-login'' command. That will let you set
>permissions according to the login name used; there is no way to set
>permissions according to the password used, but HDB doesn't support
>that either.
That's already done for you by login if you give each calling machine
a unique login name. That is, they can't be executing a program with
that login name unless they gave the correct password to get logged in.
I don't think this is well understood though.
Using your syntax, can you group a list of login names to associate
with the same set of permissions or do you have to repeat everything
for each one? How about the outbound side? Can you tie them together
in groups. Can you specify that on inbound calls the login name (from
a group) should be validated against a group of machine names? Do you
have an equivalent to NOWRITE in HDB permissions? (I like to specifically
exclude /usr/lib/uucp even to systems that are otherwise trusted to
do anything).
I'm raising the issue of groupings because I feel that the HDB files use
a good database-like approach, where you store the information about
each detail only once and essentially join the files on the appropriate
fields to produce the possible combinations. The one failing, as I
mentioned before, is the difficulty in working backwards starting from
an available device which sometimes should be the basis for scheduling.
Les Mikesell
l...@chinet.chi.il.us
Ian Lance Taylor
>In article <24...@airs.com> i...@airs.com (Ian Lance Taylor) writes:
>By the way, does "extensible" mean that your parser ignores unknown
>keywords? If not, does it just mean that you feel free
>to change it whenever you like?
The parser generally warns about unknown keywords and otherwise
ignores them. The same parsing code is used for a number of different
things (including reading the execution files) so warning on
unrecognized keywords is an argument to the parsing routine.
>>You use the ``called-login'' command. That will let you set
>>permissions according to the login name used; there is no way to set
>>permissions according to the password used, but HDB doesn't support
>>that either.
>That's already done for you by login if you give each calling machine
>a unique login name. That is, they can't be executing a program with
>that login name unless they gave the correct password to get logged in.
>I don't think this is well understood though.
I do understand it. I mentioned the password because you did in your
earlier post. I was just nit-picking because it's possible to have
several different login names with the same password and then switch
off on the password rather than the login name. Obviously nobody
would want to set things up this way.
>Using your syntax, can you [...]
First of all, my syntax tends to associate permissions with specific
machines, rather than login names. You can specify defaults for all
the machines listed in one file. I feel that distinguishing LOGNAME
entries and MACHINE entries in a Permissions file leads to confusion;
when I am configuring UUCP, I think in terms of what permissions I
want to grant to specific machines. LOGNAME entries are used to set
up defaults for a set of systems. My configuration files do this by
declaring defaults at the top of the file, instead.
That said:
>can you group a list of login names to associate
>with the same set of permissions or do you have to repeat everything
>for each one?
You can group using ``alternate'' when declaring the defaults. For
example:
request yes
transfer no
local-send ~
[ and so on ]
called-login "uucp1"
alternate
called-login "uucp2"
alternate
called-login "uucp3"
[ and so on ]
>How about the outbound side?
If by this you mean ``can you associate the same set of permissions
with several machines without repeating them'' the answer is yes, you
can use defaults. This case is simpler, since you don't need to use
alternates.
>Can you tie them together
>in groups.
For this you have to use different system files.
>Can you specify that on inbound calls the login name (from
>a group) should be validated against a group of machine names?
At the moment, not directly. You can require a machine to be logged
in under a set of names, but there is currently no requirement that a
login name only be permitted for certain machines. This will change
before the release, although as a security feature it is somewhat
dubious anyhow.
>Do you
>have an equivalent to NOWRITE in HDB permissions? (I like to specifically
>exclude /usr/lib/uucp even to systems that are otherwise trusted to
>do anything).
Yes, you precede the directory with an exclamation point. For
example:
local-send /usr/spool/uucppublic !/usr/spool/uucpublic/private
The directories are searched from left to right, and the last one to
match determines whether the file may be sent or not. This is
slightly more general than NOWRITE, since it permits a public
directory within a private directory within a public directory,
although probably nobody will ever want that.
>I'm raising the issue of groupings because I feel that the HDB files use
>a good database-like approach, where you store the information about
>each detail only once and essentially join the files on the appropriate
>fields to produce the possible combinations. The one failing, as I
>mentioned before, is the difficulty in working backwards starting from
>an available device which sometimes should be the basis for scheduling.
My code suffers from the same failing. As I mentioned above, I don't
like the HDB approach of distinguishing between the login name and the
machine when assigning permissions. I've tried pretty hard to allow
information to be specified only once.
In any case, I've given up. I've started working on routines to parse
BNU configuration files. It's a bit depressing, since I really had
hoped to get this program done soon (in fact, since I'm rapidly going
broke, I had better finish soon), but I would prefer to write a
program that people will actually use. I will continue to support the
configuration files I described earlier, though.
Ronald S. Karr
I, personally, think that there can be value in coming up with a new
format. I don't much like the existing setup. The fact that chat
strings are in the Systems file means that the systems file can be
read only by setuid programs. The Permissions file is split out for
no particular reason. The interaction between the Permissions file
and the Systems file isn't very clear.
If you intend to come up with a new program for doing UUCP, then write
a new program for doing UUCP. Compatibility is necessary only at the
protocol layer. An existing site that is tied to the Systems file and
Permissions file can continue to use its existing UUCP.
To contrast with the last paragraph, though, I do believe that there
is value in being able to maintain a Systems file and Permissions file
for existing programs, such as cu. These could, perhaps, be generated
from the new configuration files, leaving out information which is not
representable. There is also value in being able to take existing
Systems and Permissions files and generate the new configuration file
formats. These two things would aid in sites that wish to transition
to using your new UUCP.
--
tron |-<=>-| ARPAnet: veritas!tr...@apple.com
tr...@veritas.com UUCPnet: {amdahl,apple,pyramid}!veritas!tron
Peter da Silva
> The most-needed extensions are in the dialer scripts anyway. I haven't
> seen any other complaints that couldn't be resolved with the HDB
> setup files and extending the chat syntax wouldn't affect any of the
> other utilities.
I would rather replace the "chat" syntax completely. I don't think it's
possible to extend it ad-hoc much further without making it uninteligable.
I would also like to be able to say "If I don't get a login at 2400 baud,
switch to 1200 baud and send return... maybe it's having trouble syncing...
if that fails then hang up and call back at the alternate number". One big
problem I have is when a hung modem answers (so dial returns success and it
won't try any more) but it's otherwise hung on that line.
--
Peter da Silva
Ferranti International Controls Corporation
Sugar Land, TX 77487-5012; +1 713 274 5180
"Have you hugged your wolf today?"
Leslie Mikesell
>First of all, my syntax tends to associate permissions with specific
>machines, rather than login names. You can specify defaults for all
>the machines listed in one file. I feel that distinguishing LOGNAME
>entries and MACHINE entries in a Permissions file leads to confusion;
>when I am configuring UUCP, I think in terms of what permissions I
>want to grant to specific machines.
Yes it's confusing, but the machine name is trivial to fake on inbound
calls. If I have a connection to your machine I can easily present
any machine name I want when I call you, and I will probably know
most of the other machine names that you talk to. If each machine
has its own login/password combination I can't fake LOGNAME without
knowing the correct password or having a non-uucico shell login to
do it. Thus you really have to associate permissions on inbound
calls with the login name.
>You can group using ``alternate'' when declaring the defaults. For
>example:
I usually have about 3 different "levels" of access allowed. One
very permissive for the other machines that I administer myself,
one slightly restricted for associated machines in other areas and
one very restricted for others. I'd expect this to be a common
setup.
>>Can you specify that on inbound calls the login name (from
>>a group) should be validated against a group of machine names?
>At the moment, not directly. You can require a machine to be logged
>in under a set of names, but there is currently no requirement that a
>login name only be permitted for certain machines. This will change
>before the release, although as a security feature it is somewhat
>dubious anyhow.
It's all you've got in the way of security. If you associate a set
of permissions with a machine and allow inbound calls you have to
be able to tell that the machine used the password you gave it. The
best you can do is to validate the machine name and logname pairs.
>local-send /usr/spool/uucppublic !/usr/spool/uucpublic/private
>
>The directories are searched from left to right, and the last one to
>match determines whether the file may be sent or not. This is
>slightly more general than NOWRITE, since it permits a public
>directory within a private directory within a public directory,
>although probably nobody will ever want that.
Interesting... The obvious enhancement is to generalize to shell-like
wild cards for the READ/WRITE/COMMANDS entries.
>In any case, I've given up. I've started working on routines to parse
>BNU configuration files. It's a bit depressing, since I really had
>hoped to get this program done soon (in fact, since I'm rapidly going
>broke, I had better finish soon), but I would prefer to write a
>program that people will actually use. I will continue to support the
>configuration files I described earlier, though.
Thanks - perhaps it would make the most sense to just provide automatic
translation between the two, but there may be cases where you want
to run both HDB and your version in parallel. In fact, I anticipate
trying to do that so that I can play with protocol changes to speed
up transfers via satellite links, but the same machine will need to
continue doing 'e' protocol over a starlan TLI streams connection.
Maybe you can come up with some magic to decide which program would
run for a particular machine.
Les Mikesell
l...@chinet.chi.il.us
Leslie Mikesell
>I, personally, think that there can be value in coming up with a new
>format. I don't much like the existing setup. The fact that chat
>strings are in the Systems file means that the systems file can be
>read only by setuid programs. The Permissions file is split out for
>no particular reason. The interaction between the Permissions file
>and the Systems file isn't very clear.
The interactions aren't very clear but it's also not clear that a
new format would help. Like any database, groups of things that
would otherwise need to be repeated for each entry need to be isolated
and joined on their common field when you want them. Since the same
permissions could apply to many systems (and on inbound calls should
be determined by logname), it makes some sense to split it out. Also
I'd expect uuxqt to be interested in the Permissions file but not the
Systems file. Maybe the chat scripts should be moved elsewhere and
referenced symbolically, maybe not. I doubt that there would be much
overlap when you get down to login names and passwords. The Systems
file on my machine wouldn't be much use to any other program unless it
also knows about Sysfiles. The uuname program does the "right thing"
though, so other programs can get this information without being
setuid. If your concern is about the way smail3 finds neighboring
uucp sites, I'd prefer to see an option that would automatically
generate the appropriate entries and force them into the paths lookup
so it doesn't take two different steps.
The piece of informataion that is really missing to tie mailers and
uucp together is something to allow the mailer to decide whether
it would be a good idea to start up a uucico to deliver any
particular message. If you have about 10x the number of neighboring
sites as you have devices to service them and mailing lists that
generate mail to everyone, you currently have to either delay delivery
of everything until uusched gets around to handling it or you fire off
thousands of uucico's that die with DEVICE LOCKED after doing a fair amount
of work.
Les Mikesell
l...@chinet.chi.il.us
Ian Lance Taylor
>In article <24...@airs.com> i...@airs.com (Ian Lance Taylor) writes:
>>First of all, my syntax tends to associate permissions with specific
>>machines, rather than login names. You can specify defaults for all
>>the machines listed in one file. I feel that distinguishing LOGNAME
>>entries and MACHINE entries in a Permissions file leads to confusion;
>>when I am configuring UUCP, I think in terms of what permissions I
>>want to grant to specific machines.
>Yes it's confusing, but the machine name is trivial to fake on inbound
>calls. If I have a connection to your machine I can easily present
>any machine name I want when I call you, and I will probably know
>most of the other machine names that you talk to. If each machine
>has its own login/password combination I can't fake LOGNAME without
>knowing the correct password or having a non-uucico shell login to
>do it. Thus you really have to associate permissions on inbound
>calls with the login name.
As I see it, this just means that you have to specify the login name
permitted for a specific machine (in my syntax, this is the
``called-login'' command). Using LOGNAME makes it easy to give
different permissions to the same machine based on the login name; I
don't think this is very useful (although my syntax does permit it, in
an awkward sort of way). If you restrict the permissions for the
machine, then all you have to do is make sure that each machine has a
unique login, or at least that when several machines share a login
they have similar permissions.
>>>Can you specify that on inbound calls the login name (from
>>>a group) should be validated against a group of machine names?
>>At the moment, not directly. You can require a machine to be logged
>>in under a set of names, but there is currently no requirement that a
>>login name only be permitted for certain machines. This will change
>>before the release, although as a security feature it is somewhat
>>dubious anyhow.
>It's all you've got in the way of security. If you associate a set
>of permissions with a machine and allow inbound calls you have to
>be able to tell that the machine used the password you gave it. The
>best you can do is to validate the machine name and logname pairs.
I feel as though I'm missing something; I said that I could require a
machine to be logged in under a specific login name (or a specific
set, if desired for some reason). The security feature I don't have,
but will add, is ``only permit this set of machines to use this login
name''. But I can get this exact effect by specifying the login name
permitted for each machine. Where's the problem?
Perhaps you are referring to the fact that forgetting to use the
``called-login'' command could lead to granting excessive permissions;
this is a problem (although I don't consider it a critical one), and
is where it would be convenient to validate the login name against a
specific list of machines (the VALIDATE command in Permissions). One
way to handle this might be to allow a list of machine names to follow
the login name in a ``called-login'' command, with the current machine
(if any) added automatically; then if ``called-login'' were used in
the defaults (the only time this feature would be useful) a list of
machines could be specified limiting the scope of the permissions.
>Interesting... The obvious enhancement is to generalize to shell-like
>wild cards for the READ/WRITE/COMMANDS entries.
Interesting idea, filed for later consideration.
Leslie Mikesell
>As I see it, this just means that you have to specify the login name
>permitted for a specific machine (in my syntax, this is the
>``called-login'' command). Using LOGNAME makes it easy to give
>different permissions to the same machine based on the login name; I
>don't think this is very useful (although my syntax does permit it, in
>an awkward sort of way).
The thing that *is* useful is the ability to pretend to be a different
machine yourself depending on the login name used by the remote machine
that is calling you. It is very handy for testing things between
machines where a screwup in the production environment would be expensive.
I also use it for a connection to attmail where an account was originally
set up using a "real" machine name and it was later decided that we should
have something more symbolic as a mail address for outsiders. Two attmail
accounts set up with the same phone number but different login names
takes care of it using a Permissions file that pairs LOGNAME= and MYNAME=
the way we want. Such a setup might also be useful to provide alternative
time-to-call or connections to be specified for what are really different
types of transfers between the same machines. Enhancing the "grade"
mechanism might be a better approach for this, but it won't work unless
you change the software at both ends.
>I feel as though I'm missing something; I said that I could require a
>machine to be logged in under a specific login name (or a specific
>set, if desired for some reason). The security feature I don't have,
>but will add, is ``only permit this set of machines to use this login
>name''. But I can get this exact effect by specifying the login name
>permitted for each machine. Where's the problem?
If you look up machine name, then pair with the login name you can only
participate in spoofing with the help of the other end, and then only
if they have HDB and know how to set up MYNAME= in the permissions file.
Les Mikesell
l...@chinet.chi.il.us
Ian Lance Taylor
>In article <24...@airs.com> i...@airs.com (Ian Lance Taylor) writes:
>The thing that *is* useful is the ability to pretend to be a different
>machine yourself depending on the login name used by the remote machine
>that is calling you.
Fair enough, and this does work. I have a ``myname'' command. The
code will look through all the machines to see if any of them specify
the login name being used with a ``myname'' command before deciding
which local name to present.
>>I feel as though I'm missing something; I said that I could require a
>>machine to be logged in under a specific login name (or a specific
>>set, if desired for some reason). The security feature I don't have,
>>but will add, is ``only permit this set of machines to use this login
>>name''. But I can get this exact effect by specifying the login name
>>permitted for each machine. Where's the problem?
>If you look up machine name, then pair with the login name you can only
>participate in spoofing with the help of the other end, and then only
>if they have HDB and know how to set up MYNAME= in the permissions file.
Right, and for this to work they also have to know the password for
that login name or have a writable /etc/utmp (I've heard that some
systems have a writable /etc/utmp, but if so they have more serious
security problems than just uucp). Even if they do know the password,
sequence numbers (conversation counts, traditionally kept in SQFILE)
could be used to slow them down and detect that a problem occurred
(speaking of sequence numbers, does anybody know what the maximum
count is? Or do people use longs and assume that 2 billion is an
unreasonably large number (which it is)?).