![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to uucp.texi CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [MW Coherent from dump] / coherent / g / usr / lib / uucp / tay104|
Return to uucp.texi CVS log | Up to [MW Coherent from dump] / coherent / g / usr / lib / uucp / tay104 |
1.1 root 1: \input texinfo @c -*-texinfo-*-
2: @c %**start of header
3: @setfilename uucp.info
4: @settitle Taylor UUCP
5: @setchapternewpage odd
6: @c %**end of header
7:
8: @iftex
9: @finalout
10: @end iftex
11:
12: @ignore
13: ---------------------------------------------------------------------->
14: Franc,ois Pinard says:
15:
16: Hi, Ian! This is the promised merging of the current documents from
17: Taylor UUCP 1.01, plus the patches to documentation you sent to me, into
18: a taylor.texi file. Many things remain to do, among which:
19:
20: - merging in the Taylor UUCP program man pages.
21: ----------------------------------------------------------------------<
22: @end ignore
23:
24: @ifinfo
25: This file documents Taylor UUCP, version 1.04.
26:
27: Copyright @copyright{} 1992, 1993 Ian Lance Taylor
28:
29: Permission is granted to make and distribute verbatim copies of this
30: manual provided the copyright notice and this permission notice are
31: preserved on all copies.
32:
33: @ignore
34: Permission is granted to process this file through TeX and print the
35: results, provided the printed document carries a copying permission
36: notice identical to this one except for the removal of this paragraph
37: (this paragraph not being relevant to the printed manual).
38:
39: @end ignore
40: Permission is granted to copy and distribute modified versions of this
41: manual under the conditions for verbatim copying, provided also that the
42: section entitled ``Copying'' are included exactly as in the original, and
43: provided that the entire resulting derived work is distributed under the
44: terms of a permission notice identical to this one.
45:
46: Permission is granted to copy and distribute translations of this manual
47: into another language, under the above conditions for modified versions,
48: except that the section entitled ``Copying'' may be included in a
49: translation approved by the author instead of in the original English.
50: @end ifinfo
51:
52: @titlepage
53: @title Taylor UUCP
54: @subtitle Version 1.04
55: @author Ian Lance Taylor @code{<ian@@airs.com>}
56:
57: @page
58: @vskip 0pt plus 1filll
59: Copyright @copyright{} 1992, 1993 Ian Lance Taylor
60:
61: Published by Ian Lance Taylor @code{<ian@@airs.com>}.
62:
63: Permission is granted to make and distribute verbatim copies of this
64: manual provided the copyright notice and this permission notice are
65: preserved on all copies.
66:
67: Permission is granted to copy and distribute modified versions of this
68: manual under the conditions for verbatim copying, provided also that the
69: section entitled ``Copying'' are included exactly as in the original, and
70: provided that the entire resulting derived work is distributed under the
71: terms of a permission notice identical to this one.
72:
73: Permission is granted to copy and distribute translations of this manual
74: into another language, under the above conditions for modified versions,
75: except that the section entitled ``Copying'' may be included in a
76: translation approved by the author instead of in the original English.
77: @end titlepage
78:
79: @node Top, Copying, (dir), (dir)
80: @top Taylor UUCP 1.04
81:
82: This is the documentation for the Taylor UUCP package, version 1.04.
83: The programs were written by Ian Lance Taylor. The author can be
84: reached at @code{<ian@@airs.com>}, or @samp{c/o Cygnus Support, 4th
85: Floor, Building 200, 1 Kendall Square, Cambridge, MA, 02139}.
86:
87: There is a mailing list for discussion of the package. To join (or get
88: off) the list, send mail to
89: @code{<taylor-uucp-request@@gnu.ai.mit.edu>}. Mail to this address is
90: answered by a person, not a program. When joining the list, please give
91: the address at which you wish to receive mail; do not rely on the
92: message headers. To send a message to the list, send it to
93: @code{<taylor-uucp@@gnu.ai.mit.edu>}.
94:
95: @menu
96: * Copying:: Taylor UUCP copying conditions
97: * Introduction:: Introduction to Taylor UUCP
98: * Overall Installation:: Taylor UUCP installation
99: * Configuration Files:: Taylor UUCP configuration files
100: * Protocols:: UUCP protocol internals
101: * Hacking:: Hacking Taylor UUCP
102: * Acknowledgements:: Acknowledgements
103:
104: * Index (concepts):: Concept index
105: * Index (configuration file):: Index to new configuration files
106:
107: --- The Detailed Node Listing ---
108:
109: Taylor UUCP Overall Installation
110:
111: * Configuration:: Configuring Taylor UUCP
112: * Compilation:: Compiling Taylor UUCP
113: * Testing:: Testing Taylor UUCP
114: * Installation:: Installing Taylor UUCP
115: * TCP:: TCP together with Taylor UUCP
116:
117: Installing Taylor UUCP
118:
119: * Running uucico:: Running uucico
120: * Using UUCP for mail and news:: Using UUCP for mail and news.
121: * Trimming UUCP Log Files:: Trimming UUCP Log Files
122:
123: Using UUCP for mail and news.
124:
125: * Sending mail or news:: Sending mail or news via UUCP
126: * Receiving mail or news:: Receiving mail or news via UUCP
127:
128: Taylor UUCP Configuration Files
129:
130: * Configuration File Format:: Configuration file format
131: * Configuration Examples:: Examples of configuration files
132: * Time Strings:: How to write time strings
133: * Chat Scripts:: How to write chat scripts
134: * config File:: The main configuration file
135: * sys File:: The system configuration file
136: * port File:: The port configuration files
137: * dial File:: The dialer configuration files
138: * Security:: Security issues
139:
140: Examples of Configuration Files
141:
142: * config File Examples:: Examples of the main configuration file
143: * Leaf Example:: Call a single remote site
144: * Gateway Example:: The gateway for several local systems
145:
146: The Main Configuration File
147:
148: * Miscellaneous (config):: Miscellaneous config file commands
149: * Configuration File Names:: Using different configuration files
150: * Log File Names:: Using different log files
151: * Debugging Levels:: Debugging levels
152:
153: The System Configuration File
154:
155: * Defaults and Alternates:: Using defaults and alternates
156: * Naming the System:: Naming the system
157: * Calling Out:: Calling out
158: * Accepting a Call:: Accepting a call
159: * Protocol Selection:: Protocol selection
160: * File Transfer Control:: File transfer control
161: * Miscellaneous (sys):: Miscellaneous sys file commands
162: * Default sys File Values:: Default values
163:
164: Calling Out
165:
166: * When to Call:: When to call
167: * Placing the Call:: Placing the call
168: * Logging In:: Logging in
169:
170: UUCP protocol internals
171:
172: * Grades:: UUCP grades
173: * Lock Files:: UUCP lock file format
174: * UUCP Protocol:: The common UUCP protocol
175: * g Protocol:: The UUCP @samp{g} protocol
176: * f Protocol:: The UUCP @samp{f} protocol
177: * t Protocol:: The UUCP @samp{t} protocol
178: * e Protocol:: The UUCP @samp{e} protocol
179: * x Protocol:: The UUCP @samp{x} protocol
180: * d Protocol:: The UUCP @samp{d} protocol
181: * Capital G Protocol:: The UUCP @samp{G} protocol
182: * Documentation References:: Documentation references
183:
184: The Common UUCP Protocol
185:
186: * Initial Handshake:: Initial handshake
187: * File Requests:: File requests
188: * Final Handshake:: Final handshake
189:
190: File Requests
191:
192: * S Request:: S request
193: * R Request:: R request
194: * X Request:: X request
195: * H Request:: H request
196:
197: Hacking Taylor UUCP
198:
199: * System Dependence:: System Dependence
200: * Naming Conventions:: Naming Conventions
201: * Patches:: Patches
202: @end menu
203:
204: @node Copying, Introduction, Top, Top
205: @unnumbered Taylor UUCP Copying Conditions
206:
207: This package is covered by the GNU Public License. See the file
208: @file{COPYING} for details. If you would like to do something with this
209: package that you feel is reasonable, but you feel is prohibited by the
210: license, contact me to see if we can work it out.
211:
212: Here is some propaganda from the Free Software Foundation. If you find
213: this stuff offensive or annoying, remember that you probably did not
214: spend any money to get this code. I did not write this code to make
215: life easier for developers of UUCP packages, I wrote it to help end
216: users, and I believe that these are the most appropriate conditions for
217: distribution.
218:
219: All the programs, scripts and documents relating to Taylor UUCP are
220: @dfn{free}; this means that everyone is free to use them and free to
221: redistribute them on a free basis. The Taylor UUCP-related programs are
222: not in the public domain; they are copyrighted and there are
223: restrictions on their distribution, but these restrictions are designed
224: to permit everything that a good cooperating citizen would want to do.
225: What is not allowed is to try to prevent others from further sharing any
226: version of these programs that they might get from you.
227:
228: Specifically, we want to make sure that you have the right to give away
229: copies of the programs that relate to Taylor UUCP, that you receive
230: source code or else can get it if you want it, that you can change these
231: programs or use pieces of them in new free programs, and that you know
232: you can do these things.
233:
234: To make sure that everyone has such rights, we have to forbid you to
235: deprive anyone else of these rights. For example, if you distribute
236: copies of the Taylor UUCP related programs, you must give the recipients
237: all the rights that you have. You must make sure that they, too,
238: receive or can get the source code. And you must tell them their
239: rights.
240:
241: Also, for our own protection, we must make certain that everyone finds
242: out that there is no warranty for the programs that relate to Taylor
243: UUCP. If these programs are modified by someone else and passed on, we
244: want their recipients to know that what they have is not what we
245: distributed, so that any problems introduced by others will not reflect
246: on our reputation.
247:
248: The precise conditions of the licenses for the programs currently being
249: distributed that relate to Taylor UUCP are found in the General Public
250: Licenses that accompany them.
251:
252: @node Introduction, Overall Installation, Copying, Top
253: @chapter Introduction to Taylor UUCP
254:
255: General introductions to UUCP are available, and perhaps one day I will
256: write one. In the meantime, here is a very brief one that concentrates
257: on the programs provided by Taylor UUCP.
258:
259: Taylor UUCP is a complete UUCP package. It is covered by the GNU Public
260: License, which means that the source code is always available. It is
261: composed of several programs; most of the names of these programs are
262: based on earlier UUCP packages.
263:
264: @table @code
265:
266: @item uucp
267:
268: The @code{uucp} program is used to copy file between systems. It is
269: similar to the standard Unix @code{cp} program, except that you can
270: refer to a file on a remote system by using @samp{system!} before the
271: file name. For example, to copy the file @file{notes.txt} to the system
272: @samp{airs}, you would say @samp{uucp notes.txt airs!~/notes.txt}. In
273: this example @samp{~} is used to name the UUCP public directory on
274: @samp{airs}.
275:
276: @item uux
277:
278: The @code{uux} program is used to request a program to be executed on a
279: remote system. This is how mail and news are transferred over UUCP. As
280: with @code{uucp}, programs and files on remote systems may be named by
281: using @samp{system!}. For example, to run the @code{rnews} program on
282: @samp{airs} passing it standard input, you would say @samp{uux -
283: airs!rnews}. The @samp{-} means to read standard input and set things
284: up such that when @code{rnews} runs on @samp{airs} it will receive the
285: same standard input.
286:
287: @end table
288:
289: Neither @code{uucp} nor @code{uux} actually do any work immediately.
290: Instead, they queue up requests for later processing. They then start a
291: daemon process which processes the requests and calls up the appropriate
292: systems. Normally the system will also start the daemon periodically to
293: check if there is any work to be done. The advantage of this approach
294: is that it all happens automatically. You don't have to sit around
295: waiting for the files to be transferred. The disadvantage is that if
296: anything goes wrong it might be a while before anybody notices.
297:
298: @table @code
299:
300: @item uustat
301:
302: The @code{uustat} program does many things. By default it will simply
303: list all the jobs you have queued with @code{uucp} or @code{uux} that
304: have not yet been processed. You can use @code{uustat} to remove any of
305: your jobs from the queue. You can also it use it to show the status of
306: the UUCP system in various ways, such as showing the connection status
307: of all the remote systems your system knows about. The system
308: administrator can use @code{uustat} to automatically discard old jobs
309: while sending mail to the user who requested them.
310:
311: @item uuname
312:
313: The @code{uuname} program by default lists all the remote systems your
314: system knows about. You can also use it to get the name of your local
315: system. It is mostly useful for shell scripts.
316:
317: @item uulog
318:
319: The @code{uulog} program can be used to display entries in the UUCP log
320: file. It can select the entries for a particular system or a particular
321: user. You can use it to see what has happened to your queued jobs in
322: the past.
323:
324: @item uuto
325: @item uupick
326:
327: @code{uuto} is a simple shell script interface to @code{uucp}. It will
328: transfer a file, or the contents of a directory, to a remote system, and
329: notify a particular user on the remote system when it arrives. The
330: remote user can then retrieve the file(s) with @code{uupick}.
331:
332: @item cu
333:
334: The @code{cu} program can be used to call up another system and
335: communicate with it as though you were directly connected. It can also
336: do simple file transfers, though it does not provide any error checking.
337:
338: @end table
339:
340: These eight programs just described, @code{uucp}, @code{uux},
341: @code{uuto}, @code{uupick}, @code{uustat}, @code{uuname}, @code{uulog},
342: and @code{cu} are the user programs provided by Taylor UUCP@.
343: @code{uucp}, @code{uux}, and @code{uuto} add requests to the work queue,
344: @code{uupick} extracts files from the UUCP public directory,
345: @code{uustat} examines the work queue, @code{uuname} examines the
346: configuration files, @code{uulog} examines the log files, and @code{cu}
347: just uses the UUCP configuration files.
348:
349: The real work is actually done by two daemon processes, which are
350: normally run automatically rather than by a user.
351:
352: @table @code
353:
354: @item uucico
355:
356: The @code{uucico} daemon is the program which actually calls the remote
357: system and transfers files and requests. @code{uucico} is normally
358: started automatically by @code{uucp} and @code{uux}. Most systems will
359: also start it periodically to make sure that all work requests are
360: handled. @code{uucico} checks the queue to see what work needs to be
361: done, and then calls the appropriate systems. If the call fails,
362: perhaps because the phone line is busy, @code{uucico} leaves the
363: requests in the queue and goes on to the next system to call. It is
364: also possible to force @code{uucico} to call a remote system even if
365: there is no work to be done for it, so that it can pick up any work that
366: may be queued up remotely.
367:
368: @item uuxqt
369:
370: The @code{uuxqt} daemon processes execution requests made by the
371: @code{uux} program on remote systems. It also processes requests made
372: on the local system which require files from a remote system. It is
373: normally started by @code{uucico}.
374:
375: @end table
376:
377: Suppose you, on the system @samp{bantam}, want to copy a file to the
378: system @samp{airs}. You would run the @code{uucp} command locally, with
379: a command like @samp{uucp notes.txt airs!~/notes.txt}. This would queue
380: up a request on @samp{bantam} for @samp{airs}, and would then start the
381: @code{uucico} daemon. @code{uucico} would see that there was a request
382: for @samp{airs} and attempt to call it. When the call succeeded,
383: another copy of @code{uucico} would be started on @samp{airs}. The two
384: copies of @code{uucico} would tell each other what they had to do and
385: transfer the file from @samp{bantam} to @samp{airs}. When the file
386: transfer was complete the @code{uucico} on @samp{airs} would move it
387: into the UUCP public directory.
388:
389: UUCP is often used to transfer mail. This is normally done
390: automatically by mailer programs. When @samp{bantam} has a mail message
391: to send to @samp{ian} at @samp{airs}, it executes @samp{uux - airs!rmail
392: ian} and writes the mail message to the @code{uux} process as standard
393: input. The @code{uux} program, running on @samp{bantam}, will read the
394: standard input and store it, as well as the @code{rmail} request itself,
395: on the work queue for @samp{airs}. @code{uux} will then start the
396: @code{uucico} daemon. The @code{uucico} daemon will call up
397: @samp{airs}, just as in the @code{uucp} example, and transfer the work
398: request and the mail message. The @code{uucico} daemon on @samp{airs}
399: will put the files on a local work queue. When the communication
400: session is over, the @code{uucico} daemon on @samp{airs} will start the
401: @code{uuxqt} daemon. @code{uuxqt} will see the request to run, and will
402: run @samp{rmail ian} with the mail message as standard input. The
403: @code{rmail} program, which is not part of the UUCP package, is then
404: responsible for either putting the message in the right mailbox on
405: @samp{airs} or forwarding the message on to another system.
406:
407: Taylor UUCP comes with a few other programs that are useful when
408: installing and configuring UUCP.
409:
410: @table @code
411:
412: @item uuchk
413:
414: The @code{uuchk} program reads the UUCP configuration files and displays
415: a rather lengthy description of what it finds. This is useful when
416: configuring UUCP to make certain that the UUCP package will do what you
417: expect it to do.
418:
419: @item uuconv
420:
421: The @code{uuconv} program can be used to convert UUCP configuration
422: files from one support format to another. This can be useful for
423: administrators converting from an older UUCP. Taylor UUCP is able to
424: read and use old configuration file formats, but some new features can
425: not be selected using the old formats.
426:
427: @item uusched
428:
429: The @code{uusched} script is just provided for compatibility with older
430: UUCP releases. It starts @code{uucico} to call, one at a time, all the
431: systems for which work has been queued.
432:
433: @item tstuu
434:
435: The @code{tstuu} program is a test harness for the UUCP package, which
436: will help ensure that it has been configured and compiled correctly. It
437: does not test everything, however. It only runs on Unix systems which
438: support Berkeley style pseudo-terminals or STREAMS style
439: pseudo-terminals. It can be useful when initially installing Taylor
440: UUCP.
441:
442: @end table
443:
444: @node Overall Installation, Configuration Files, Introduction, Top
445: @chapter Taylor UUCP Overall Installation
446:
447: These are the installation instructions for the Taylor UUCP package.
448:
449: @menu
450: * Configuration:: Configuring Taylor UUCP
451: * Compilation:: Compiling Taylor UUCP
452: * Testing:: Testing Taylor UUCP
453: * Installation:: Installing Taylor UUCP
454: * TCP:: TCP together with Taylor UUCP
455: @end menu
456:
457: @node Configuration, Compilation, Overall Installation, Overall Installation
458: @section Configuring Taylor UUCP
459:
460: You will have to decide what types of configuration files you want to
461: use. This package supports a new sort of configuration file; see
462: @ref{Configuration Files}. It also supports V2 configuration files
463: (@file{L.sys}, @file{L-devices}, etc.) and HDB configuration files
464: (@file{Systems}, @file{Devices}, etc.). No documentation is provided
465: for V2 or HDB configuration files. All types of configuration files can
466: be used at once, if you are so inclined. Currently using just V2
467: configuration files is not really possible, because there is no way to
468: specify a dialer (there are no built in dialers, and the program does
469: not know how to read @file{acucap} or @file{modemcap}); however, V2
470: configuration files can be used with a new style dialer file
471: (@pxref{dial File}), or with a HDB @file{Dialers} file.
472:
473: Use of HDB configuration files has two known bugs. A blank line in the
474: middle of an entry in the @file{Permissions} file will not be ignored as
475: it should be. Dialer programs, as found in some versions of HDB, are
476: not recognized directly. If you must use a dialer program, rather than
477: an entry in @file{Devices}, you must use the @code{chat-program} command
478: in a new style dialer file; see @ref{dial File}. You will have to
479: invoke the dialer program via a shell script, since an exit code of 0 is
480: required to recognize success.
481:
482: The @code{uuconv} program can be used to convert from V2 or HDB
483: configuration files to the new style (it can also do the reverse
484: translation, if you are so inclined). It will not do all of the work,
485: and the results should be carefully checked, but it can be quite useful.
486:
487: If you are installing a new system, you will, of course, have to write
488: the configuration files; see @ref{Configuration Files}.
489:
490: You must also decide what sort of spool directory you want to use. If
491: you will only be using these programs, I recommend
492: @samp{SPOOLDIR_TAYLOR}; otherwise select the spool directory
493: corresponding to your existing UUCP package. The details of the spool
494: directory choices are described at somewhat tedious length in
495: @file{unix/spool.c}.
496:
497: @node Compilation, Testing, Configuration, Overall Installation
498: @section Compiling Taylor UUCP
499:
500: @enumerate
501:
502: @item
503: Take a look at the top of @file{Makefile.in} and set the appropriate
504: values for your system. These control where the programs are installed
505: and which user on the system owns them (normally they will be owned by a
506: special user @code{uucp} rather than a real person; they should probably
507: not be owned by @code{root}).
508:
509: @item
510: Run the shell script @code{configure}. This script was generated using
511: the @code{autoconf} program written by David MacKenzie of the Free
512: Software Foundation. It takes a while to run. It will generate the
513: file @file{conf.h} based on @file{conf.h.in}, and, for each source code
514: directory, will generate @file{Makefile} based on @file{Makefile.in}.
515:
516: You can pass certain arguments to @code{configure} in the environment.
517: Because @code{configure} will compile little test programs to see what
518: is available on your system, you must tell it how to run your compiler.
519: It recognizes the following environment variables:
520:
521: @table @samp
522: @item CC
523: The C compiler. If this is not set, then if @code{configure} can find
524: @samp{gcc} it will use it, otherwise it will use @samp{cc}.
525: @item CFLAGS
526: Flags to pass to the C compiler when compiling the actual code. If this
527: is not set, @code{configure} will use @samp{-g}.
528: @item LDFLAGS
529: Flags to pass to the C compiler when only linking, not compiling. If
530: this is not set, @code{configure} will use the empty string.
531: @item LIBS
532: Libraries to pass to the C compiler. If this is not set,
533: @code{configure} will use the empty string.
534: @item INSTALL
535: The program to run to install UUCP in the binary directory. If this is
536: not set, then if @code{configure} finds the BSD @code{install} program,
537: it will set this to @samp{install -c}; otherwise, it will use @samp{cp}.
538: @item INSTALLDATA
539: The program to run to install UUCP data files, such as the man pages and
540: the info pages. If this is not set, then if @code{configure} finds the
541: BSD @code{install} program, it will set this to @samp{install -c -m
542: 644}; otherwise, it will use @samp{cp}.
543: @end table
544:
545: Suppose you want to set the environment variable @samp{CC} to
546: @samp{rcc}. If you are using @code{sh} or @code{bash}, invoke
547: @code{configure} as @samp{CC=rcc configure}. If you are using
548: @code{csh}, do @samp{setenv CC rcc; sh configure}.
549:
550: On some systems you will want to use @samp{LIBS=-lmalloc}. On Xenix
551: derived versions of Unix do not use @samp{LIBS=-lx} because this will
552: bring in the wrong versions of certain routines; if you want to use
553: @samp{-lx} you must specify @samp{LIBS=-lc -lx}.
554:
555: If @code{configure} fails for some reason, or if you have a very wierd
556: system, you may have to configure the package by hand. To do this, copy
557: the file @file{conf.h.in} to @file{conf.h} and edit it for your system.
558: Then for each source directory (the top directory, and the
559: subdirectories @file{lib}, @file{unix}, and @file{uuconf}) copy
560: @file{Makefile.in} to @file{Makefile}, find the words within @kbd{@@}
561: characters, and set them correctly for your system.
562:
563: @item
564: Igor V. Semenyuk provided this (lightly edited) note about ISC Unix 3.0.
565: The @code{configure} script will default to passing @samp{-posix} to
566: @code{gcc}. However, using @samp{-posix} changes the environment to
567: POSIX, and on ISC 3.0, at least, the default for POSIX_NO_TRUNC is 1.
568: This means nothing for uucp, but can lead to a problem when uuxqt
569: executes rmail. IDA sendmail has dbm configuration files named
570: @file{mailertable.@{dir,pag@}}. Notice these names are 15 characters
571: long. When uuxqt compiled with @samp{-posix} executes rmail, which in
572: turn executes sendmail, the later is run under POSIX environment too!
573: This leads to sendmail bombing out with @samp{'error opening 'M'
574: database: name too long' (mailertable.dir)}. It's rather obscure
575: behaviour, and it took me a day to find out the cause. I don't use
576: @samp{-posix}, instead I run @code{gcc} with @samp{-D_POSIX_SOURCE}, and
577: add @samp{-lcposix} to @samp{LIBS}.
578:
579: @item
580: You should verify that @code{configure} worked correctly by checking
581: @file{conf.h} and the instances of @file{Makefile}.
582:
583: @item
584: Edit @file{policy.h} for your local system. The comments should explain
585: the various choices. The default values are intended to be reasonable,
586: so you may not have to make any changes.
587:
588: @item
589: Type @samp{make} to compile everything. The @file{tstuu.c} file is not
590: particularly portable; if you can't figure out how to compile it you can
591: safely ignore it, as it is only used for testing (to use STREAMS
592: pseudo-terminals, tstuu.c must be compiled with
593: @samp{-DHAVE_STREAMS_PTYS}; this is not automatically determined at the
594: moment). If you have any other problems there is probably a bug in the
595: @code{configure} script.
596:
597: @item
598: Please report any problems you have. That is the only way they will get
599: fixed for other people. Supply a patch if you can (@pxref{Patches}), or
600: just ask for help.
601:
602: @end enumerate
603:
604: @node Testing, Installation, Compilation, Overall Installation
605: @section Testing Taylor UUCP
606:
607: This package is in use at many sites, and has been running at
608: @file{airs.com} for over a year. However, it will doubtless fail in
609: some situations. Do not rely on this code until you have proven to
610: yourself that it will work.
611:
612: You can use the @code{uuchk} program to test your configuration files.
613: It will read them and print out a verbose description. This program
614: should not be made setuid, because it will display passwords if it can
615: read them.
616:
617: If your system supports pseudo-terminals, and you compiled the code to
618: support the new style of configuration files, you should be able to use
619: the @code{tstuu} program to test the @code{uucico} daemon (if your
620: system supports STREAMS based pseudo-terminals, you must compile tstuu.c
621: with @samp{-DHAVE_STREAMS_PTYS}, at least at the moment; the STREAMS
622: based code was contributed by Marc Boucher).
623:
624: To run @code{tstuu}, just type @samp{tstuu} with no arguments while
625: logged in to the compilation directory (since it runs @file{./uucp},
626: @file{./uux} and @file{./uucico}). It will run a lengthy series of
627: tests (it takes over ten minutes on a slow VAX). You will need a fair
628: amount of space available in @file{/usr/tmp}. You will probably want to
629: put it in the background. Do not use @kbd{^Z}, because the program
630: traps on @code{SIGCHLD} and winds up dying. It will create a directory
631: @file{/usr/tmp/tstuu} and fill it with configuration files, and create
632: spool directories @file{/usr/tmp/tstuu/spool1} and
633: @file{/usr/tmp/tstuu/spool2}.
634:
635: If your system does not support the @code{FIONREAD} call, the
636: @samp{tstuu} program will run very slowly. This may or may not get
637: fixed in a later version.
638:
639: The @samp{tstuu} program does not seem to work under SunOS 4.1.1. This
640: seems to be due to a bug in the implementation of ptys.
641:
642: The program will finish with an execute file named
643: @file{X.@var{something}} and a data file named @file{D.@var{something}}
644: in the directory @file{/usr/tmp/tstuu/spool1} (or, more likely, in
645: subdirectories, depending on the choice of @code{SPOOLDIR} in
646: @file{policy.h}). Two log files will be created in the directory
647: @file{/usr/tmp/tstuu}. They will be named @file{Log1} and @file{Log2},
648: or, if you have selected @code{HAVE_HDB_LOGGING} in @file{policy.h},
649: @file{Log1/uucico/test2} and @file{Log2/uucico/test1}. You can test
650: @code{uuxqt} by running the command @samp{./uuxqt -I
651: /usr/tmp/tstuu/Config1}. This should leave a command file
652: @file{C.@var{something}} and a data file @file{D.@var{something}} in
653: @file{/usr/tmp/tstuu/spool1} or in subdirectories. Again, there should
654: be no errors in the log file.
655:
656: Assuming you compiled the code with debugging enabled, the @samp{-x}
657: switch can be used to set debugging modes; see the @code{debug} command
658: for details (@pxref{Debugging Levels}). Use @samp{-x all} to turn on
659: all debugging and generate far more output than you will ever want to
660: see. The @code{uucico} daemons will put debugging output in the files
661: @file{Debug1} and @file{Debug2} in the directory @file{/usr/tmp/tstuu}.
662: After that, you're pretty much on your own.
663:
664: On some systems you can also use @code{tstuu} to test @code{uucico}
665: against the system @code{uucico}, by using the @samp{-u} switch. For
666: this to work, change the definitions of @code{ZUUCICO_CMD} and
667: @code{UUCICO_EXECL} at the top of @file{tstuu.c} to something
668: appropriate for your system. The definitions in @file{tstuu.c} are what
669: I used for Ultrix 4.0, on which @file{/usr/lib/uucp/uucico} is
670: particularly obstinate about being run as a child; I was only able to
671: run it by creating a login name with no password whose shell was
672: @file{/usr/lib/uucp/uucico}. Calling login in this way will leave fake
673: entries in @file{wtmp} and @file{utmp}; if you compile @file{tstout.c}
674: (in the @file{contrib} directory) as a setuid @code{root} program,
675: @code{tstuu} will run it to clear those entries out. On most systems,
676: such hackery should not be necessary, although on SCO I had to su to
677: @code{root} (@code{uucp} might also have worked) before I could run
678: @file{/usr/lib/uucp/uucico}.
679:
680: You can test @code{uucp} and @code{uux} (give them the @samp{-r} switch
681: to keep them from starting @code{uucico}) to make sure they create the
682: right sorts of files. Unfortunately, if you don't know what the right
683: sorts of files are, I'm not going to tell you here.
684:
685: If @code{tstuu} passes, or you can't run it for some reason or other,
686: move on to testing with some other system. Set up the configuration
687: files (@pxref{Configuration Files}), or use an existing configuration.
688: Tell @code{uucico} to dial out to the system by using the @samp{-s}
689: system switch (e.g. @samp{uucico -s uunet}). The log file should tell
690: you what happens.
691:
692: If you compiled the code with debugging enabled, you can use debugging
693: mode to get a great deal of information about what sort of data is
694: flowing back and forth; the various possibilities are described under
695: the @code{debug} command (@pxref{Debugging Levels}). When initially
696: setting up a connection @samp{-x chat} is probably the most useful (e.g.
697: @samp{uucico -s uunet -x chat}); you may also want to use @samp{-x
698: handshake,incoming,outgoing}. You can use @samp{-x} multiple times on
699: one command line, or you can give it comma separated arguments as in the
700: last example. Use @samp{-x all} to turn on all possible debugging
701: information. The debugging information is written to a file, normally
702: @file{/usr/spool/uucp/Debug}, although the default can be changed in
703: @file{policy.h} and the configuration file can override the name with
704: the @code{debugfile} command. The debugging file may contain passwords
705: and some file contents as they are transmitted over the line, so the
706: debugging file is only readable by the @code{uucp} user.
707:
708: You can use the @samp{-f} switch to force @code{uucico} to call out even
709: if the last call failed recently; using @samp{-S} when naming a system
710: has the same effect. Otherwise the status file (in the @file{.Status}
711: subdirectory of the main spool directory, normally
712: @file{/usr/spool/uucp}) will prevent too many attempts from occurring in
713: rapid succession.
714:
715: Again, please let me know about any problems you have and how you got
716: around them. If you do report a problem, please include the version
717: number of the package you are using, and a sample of the debugging file
718: showing the problem. General questions such as ``why doesn't uucico
719: dial out'' are impossible to answer without much more information.
720:
721: @node Installation, TCP, Testing, Overall Installation
722: @section Installing Taylor UUCP
723:
724: You can install the executable files by becoming @code{root} and typing
725: @samp{make install}. Or you can look at what @samp{make install} does
726: and do it by hand. It tries to preserve your old programs, if any, but
727: it only does this the first time Taylor UUCP is installed (so that if
728: you install several versions of Taylor UUCP, you can still go back to
729: your original UUCP programs). You can retrieve the original programs by
730: typing @samp{make uninstall}.
731:
732: Simply installing the executable files is not enough, however. You must
733: also arrange for them to be used correctly.
734:
735: @menu
736: * Running uucico:: Running uucico
737: * Using UUCP for mail and news:: Using UUCP for mail and news.
738: * Trimming UUCP Log Files:: Trimming UUCP Log Files
739: @end menu
740:
741: @node Running uucico, Using UUCP for mail and news, Installation, Installation
742: @subsection Running uucico
743:
744: By default @code{uucp} and @code{uux} will automatically start up
745: @code{uucico} to call another system whenever work is queued up.
746: However, the call may fail, or there may be time restrictions which
747: prevent the call at that time (perhaps because telephone rates are high)
748: (@pxref{When to Call}). Also, a remote system may have work queued up
749: for your system, but may not be calling you for some reason (perhaps you
750: have agreed that your system should always place the call). To make
751: sure that works get transferred between the systems withing a reasonable
752: time period, you should arrange to periodically invoke @code{uucico}.
753:
754: These periodic invocations are normally caused by entries in the
755: @file{crontab} file. The exact format of @file{crontab} files, and how
756: new entries are added, varies from system to system; check your local
757: documentation (try @samp{man cron}).
758:
759: To attempt to call all systems with outstanding work, use the command
760: @samp{uucico -r1}. To attempt to call a particular system, use the
761: command @samp{uucico -s SYSTEM}.
762:
763: A common case is to want to try to call a system at a certain time, with
764: periodic retries if the call fails. A simple way to do this is to
765: create an UUCP command file, known as a @dfn{poll file}. If a poll
766: file exists for a system, then @samp{uucico -r1} will place a call to
767: it. If the call succeeds, the poll file will be deleted.
768:
769: The file can be easily created using the @samp{touch} command. The name
770: of a poll file currently depends on the type of spool directory you are
771: using, as set in @file{policy.h}. If you are using
772: @code{SPOOLDIR_TAYLOR} (the default), put something like this in your
773: @file{crontab} file:
774: @example
775: touch /usr/spool/uucp/@var{sys}/C./C.A0000
776: @end example
777: In this example @var{sys} is the system you wish to call, and
778: @samp{/usr/spool/uucp} is your UUCP spool directory.
779: If you are using @code{SPOOLDIR_HDB}, use
780: @example
781: touch /usr/spool/uucp/@var{sys}/C.@var{sys}A0000
782: @end example
783:
784: For example, I use the following crontab entries locally:
785:
786: @example
787: 45 * * * * /bin/echo /usr/lib/uucp/uucico -r1 | /bin/su uucpa
788: 40 4,10,15 * * * touch /usr/spool/uucp/uunet/C./C.A0000
789: @end example
790:
791: Every hour, at 45 minutes past, this will check if there is any work to
792: be done, and, if there is, will call the appropriate system. Also, at
793: 4:40am, 10:40am and 3:40pm this will create a poll file file for
794: @samp{uunet}, forcing the next check to call @samp{uunet}.
795:
796: @node Using UUCP for mail and news, Trimming UUCP Log Files, Running uucico, Installation
797: @subsection Using UUCP for mail and news.
798:
799: Taylor UUCP does not include a mail package. All Unix systems come with
800: some sort of mail delivery agent, typically @code{sendmail} or
801: @code{MMDF}. Source code is available for some mail delivery agents,
802: such as @code{IDA sendmail} and @code{smail}.
803:
804: Taylor UUCP also does not include a news package. The two major Unix
805: news packages are @code{C-news} and @code{INN}. Both are available in
806: source code form.
807:
808: Configuring and using mail delivery agents is a notoriously complex
809: topic, and I will not be discussing it here. Configuring news systems
810: is usually simpler, but I will not be discussing that either. I will
811: merely describe the interactions between the mail and news systems and
812: UUCP.
813:
814: A mail or news system interacts with UUCP in two ways.
815:
816: @menu
817: * Sending mail or news:: Sending mail or news via UUCP
818: * Receiving mail or news:: Receiving mail or news via UUCP
819: @end menu
820:
821: @node Sending mail or news, Receiving mail or news, Using UUCP for mail and news, Using UUCP for mail and news
822: @unnumberedsubsubsec Sending mail or news via UUCP
823:
824: When mail is to be sent from your machine to another machine via UUCP,
825: the mail delivery agent will invoke @code{uux}. It will generally run a
826: command such as @samp{uux - @var{system}!rmail}, where @var{system} is
827: the remote system to which the mail is being sent. It may pass other
828: options to @code{uux}, such as @samp{-r} or @samp{-g}.
829:
830: News also invokes @code{uux} in order to transfer articles to another
831: system. The only difference is that news will use @code{uux} to invoke
832: @code{rnews} on the remote system, rather than @code{rmail}.
833:
834: You should arrange for your mail and news systems to invoke the Taylor
835: UUCP version of @code{uux} when sending mail via UUCP. If you simply
836: replace any existing version of @code{uux} with the Taylor UUCP version,
837: this will probably happen automatically. However, if both versions
838: exist on your system, you will probably have to modify the mail and news
839: configuration files in some way.
840:
841: Actually, if both the system UUCP and Taylor UUCP are using the same
842: spool directory format, the system @code{uux} will probably work fine
843: with the Taylor @code{uucico} (the reverse is not the case: the Taylor
844: @code{uux} requires the Taylor @code{uucico}). However, data transfer
845: will be somewhat more efficient if the Taylor @code{uux} is used.
846:
847: @node Receiving mail or news, , Sending mail or news, Using UUCP for mail and news
848: @unnumberedsubsubsec Receiving mail or news via UUCP
849:
850: As noted in @ref{Sending mail or news}, mail is sent by requesting a
851: remote execution of @code{rmail}. To receive mail, then, all that is
852: necessary is for UUCP to invoke @code{rmail} itself.
853:
854: Any mail delivery agent will provide an appropriate version of
855: @code{rmail}; you must simply make sure that it is in the command path
856: used by UUCP (it almost certainly already is). The default command path
857: is set in @file{policy.h}, and it may be overridden for a particular
858: system by the @code{command-path} command (@pxref{Miscellaneous (sys)}).
859:
860: Similarly, for news UUCP must be able to invoke @code{rnews}. Any news
861: system will provide a version of @code{rnews}, and you must ensure that
862: is in a directory on the path that UUCP will search.
863:
864: @node Trimming UUCP Log Files, , Using UUCP for mail and news, Installation
865: @subsection Trimming UUCP Log Files
866:
867: You should also periodically trim the log files, as they will otherwise
868: continue to grow without limit. The names of the log files are set in
869: @file{policy.h}, and may be overridden in the configuration file
870: (@pxref{config File}). By default they are are
871: @file{/usr/spool/uucp/Log} and @file{/usr/spool/uucp/Stats}.
872:
873: You may find the @code{savelog} program in the @file{contrib} directory
874: may be of use. There is a manual page for it in @file{contrib} as well.
875:
876: @node TCP, , Installation, Overall Installation
877: @section TCP together with Taylor UUCP
878:
879: If your system has a Berkeley style socket library, or a System V style
880: TLI interface library, you can compile the code to permit making
881: connections over TCP. Specifying that a system should be reached via
882: TCP is easy, but nonobvious.
883:
884: If you are using the new style configuration files, see
885: @ref{Configuration Files}. Basically, you can just add the line
886: @samp{port type tcp} to the entry in the system configuration file. By
887: default UUCP will get the port number by looking up @samp{uucp} in
888: @file{/etc/services}; if @samp{uucp} is not found, port 540 will be
889: used. You can set the port number to use with the command @samp{port
890: service @var{xxx}}, where @var{xxx} can be either a number or a name to
891: look up in @file{/etc/services}. You can specify the address of the
892: remote host with @samp{address @var{a.b.c}}; if you don't give an
893: address, the remote system name will be used. You should give an
894: explicit chat script for the system when you use TCP; the default chat
895: script begins with a carriage return, which will not work with some UUCP
896: TCP servers.
897:
898: If you are using V2 configuration files, add a line like this to
899: @file{L.sys}:
900:
901: @example
902: @var{sys} Any TCP uucp @var{host}.@var{domain} chat-script
903: @end example
904:
905: This will make an entry for system @var{sys}, to be called at any time,
906: over TCP, using port number @samp{uucp} (as found in
907: @file{/etc/services}; this may be specified as a number), using remote
908: host @file{@var{host}.@var{domain}}, with some chat script.
909:
910: If you are using HDB configuration files, add a line like this to
911: Systems:
912:
913: @example
914: @var{sys} Any TCP - @var{host}.@var{domain} chat-script
915: @end example
916:
917: and a line like this to Devices:
918:
919: @example
920: TCP uucp - -
921: @end example
922:
923: You only need one line in Devices regardless of how many systems you
924: contact over TCP. This will make an entry for system @var{sys}, to be
925: called at any time, over TCP, using port number @samp{uucp} (as found in
926: @file{/etc/services}; this may be specified as a number), using remote
927: host @file{@var{host}.@var{domain}}, with some chat script.
928:
929: The @code{uucico} daemon can also be run as a TCP server. To use the
930: default port number, which is a reserved port, @code{uucico} must be
931: invoked by root (or it must be set user ID to root, but I don't
932: recommend doing that).
933:
934: Basically, you must define a port, either using the port file
935: (@pxref{port File}) if you are using the new configuration method or
936: with an entry in Devices if you are using HDB; there is no way to define
937: a port using V2. If you are using HDB the port must be named
938: @samp{TCP}; a line as shown above will suffice. You can then start
939: @code{uucico} as @samp{uucico -p TCP} (after the @samp{-p}, name the
940: port; in HDB it must be @samp{TCP}). This will wait for incoming
941: connections, and fork off a child for each one. Each connection will be
942: prompted with @samp{login:} and @samp{Password:}; the results will be
943: checked against the UUCP (not the system) password file
944: (@pxref{Configuration File Names}).
945:
946: Of course, you can get a similar effect by using the BSD @code{uucpd}
947: program.
948:
949: You can also have @code{inetd} start up @code{uucico} with the @samp{-l}
950: switch, which will cause it to prompt with @samp{login:} and
951: @samp{Password:} and check the results against the UUCP (not the system)
952: password file. This may be used in place of @code{uucpd}.
953:
954: @node Configuration Files, Protocols, Overall Installation, Top
955: @chapter Taylor UUCP Configuration Files
956:
957: This chapter describes the configuration files accepted by the Taylor
958: UUCP package if compiled with @code{HAVE_TAYLOR_CONFIG} defined in
959: @file{policy.h}.
960:
961: The configuration files are normally found in the directory
962: @var{newconfigdir}, which is defined by the @file{Makefile} variable
963: @file{newconfigdir}; by default @var{newconfigdir} is
964: @file{/usr/local/conf/uucp}. However, the main configuration file,
965: @file{config}, is the only one which must be in that directory, since it
966: may specify a different location for any or all of the other files. You
967: may run any of the UUCP programs with a different main configuration
968: file by using the @samp{-I} option; this can be useful when testing a
969: new configuration. When you use the @samp{-I} option the programs will
970: revoke any setuid privileges.
971:
972: @menu
973: * Configuration File Format:: Configuration file format
974: * Configuration Examples:: Examples of configuration files
975: * Time Strings:: How to write time strings
976: * Chat Scripts:: How to write chat scripts
977: * config File:: The main configuration file
978: * sys File:: The system configuration file
979: * port File:: The port configuration files
980: * dial File:: The dialer configuration files
981: * Security:: Security issues
982: @end menu
983:
984: @node Configuration File Format, Configuration Examples, Configuration Files, Configuration Files
985: @section Configuration File Format
986:
987: All the configuration files follow a simple line-oriented
988: @samp{@var{keyword} @var{value}} format. Empty lines are ignored, as
989: are leading spaces; unlike HDB, lines with leading spaces are read. The
990: first word on each line is a keyword. The rest of the line is
991: interpreted according to the keyword. Most keywords are followed by
992: numbers, boolean values or simple strings with no embedded spaces.
993:
994: The @kbd{#} character is used for comments. Everything from a @kbd{#}
995: to the end of the line is ignored unless the @kbd{#} is preceded by a
996: @kbd{\} (backslash); if the @kbd{#} is preceeded by a @kbd{\}, the
997: @kbd{\} is removed but the @kbd{#} remains in the line. This can be
998: useful for a phone number containing a @kbd{#}. To enter the sequence
999: @samp{\#}, use @samp{\\#}.
1000:
1001: The backslash character may be used to continue lines. If the last
1002: character in a line is a backslash, the backslash is removed and the
1003: line is continued by the next line. The second line is attached to the
1004: first with no intervening characters; if you want any whitespace between
1005: the end of the first line and the start of the second line, you must
1006: insert it yourself.
1007:
1008: However, the backslash is not a general quoting character. For example,
1009: you cannot use it to get an embedded space in a string argument.
1010:
1011: Everything after the keyword must be on the same line. A @var{boolean}
1012: may be specified as @kbd{y}, @kbd{Y}, @kbd{t}, or @kbd{T} for true and
1013: @kbd{n}, @kbd{N}, @kbd{f}, or @kbd{F} for false; any trailing characters
1014: are ignored, so @code{true}, @code{false}, etc., are also acceptable.
1015:
1016: @node Configuration Examples, Time Strings, Configuration File Format, Configuration Files
1017: @section Examples of Configuration Files
1018:
1019: All the configuration commands are explained in the following sections.
1020: However, I'll start by giving a few examples of configuration files.
1021: For a more complete description of any of the commands used here see the
1022: appropriate section of this chapter. There are also sample
1023: configuration files in the @file{sample} subdirectory of the
1024: distribution.
1025:
1026: @menu
1027: * config File Examples:: Examples of the main configuration file
1028: * Leaf Example:: Call a single remote site
1029: * Gateway Example:: The gateway for several local systems
1030: @end menu
1031:
1032: @node config File Examples, Leaf Example, Configuration Examples, Configuration Examples
1033: @subsection config File Examples
1034: @cindex config file examples
1035:
1036: To start with, here are some examples of uses of the main configuration
1037: file, @file{config}. For a complete description of the commands that
1038: are permitted in @file{config}, see @ref{config File}.
1039:
1040: In many cases you will not need to create a @file{config} file at all.
1041: The most common reason to create one is to give your machine a special
1042: UUCP name. Other reasons might be to change the UUCP spool directory or
1043: to permit any remote system to call in.
1044:
1045: If you have an internal network of machines, then it is likely that the
1046: internal name of your UUCP machine is not the name you want to use when
1047: calling other systems. For example, here at @file{airs.com} our
1048: mail/news gateway machine is named @file{elmer.airs.com} (it is one of
1049: several machines all named @file{@var{localname}.airs.com}). If we did
1050: not provide a @file{config} file, then our UUCP name would be
1051: @file{elmer}; however, we actually want it to be @file{airs}.
1052: Therefore, we use the following line in @file{config}:
1053:
1054: @example
1055: nodename airs
1056: @end example
1057:
1058: @cindex changing spool directory
1059: @cindex spool directory (changing)
1060: The UUCP spool directory name is set in @file{policy.h} when the code is
1061: compiled. You might at some point decide that it is appropriate to move
1062: the spool directory, perhaps to put it on a different disk partition.
1063: You would use the following commands in @file{config} to change to
1064: directories on the partition @file{/uucp}:
1065:
1066: @example
1067: spool /uucp/spool
1068: pubdir /uucp/uucppublic
1069: logfile /uucp/spool/Log
1070: debugfile /uucp/spool/Debug
1071: @end example
1072:
1073: You would then move the contents of the current spool directory to
1074: @file{/uucp/spool}. If you do this, make sure that no UUCP processes
1075: are running while you change @file{config} and move the spool directory.
1076:
1077: @cindex anonymous UUCP
1078: Suppose you wanted to permit any system to call in to your system and
1079: request files. This is generally known as @dfn{anonymous UUCP}, since
1080: the systems which call in are effectively anonymous. By default,
1081: unknown systems are not permitted to call in. To permit this you must
1082: use the @code{unknown} command in @file{config}. The @code{unknown}
1083: command is followed by any command that may appear in the system file;
1084: for full details, see @ref{sys File}.
1085:
1086: I will show two possible anonymous UUCP configurations. The first will
1087: let any system call in and download files, but will not permit them to
1088: upload files to your system.
1089:
1090: @example
1091: # No files may be transferred to this system
1092: unknown receive-request no
1093: # The public directory is /usr/spool/anonymous
1094: unknown pubdir /usr/spool/anonymous
1095: # Only files in the public directory may be sent (the default anyhow)
1096: unknown remote-send ~
1097: @end example
1098:
1099: @noindent
1100: Setting the public directory is convenient for the systems which call
1101: in. It permits to request a file by prefixing it with @file{~/}. For
1102: example, assuming your system is known as @samp{server}, then to
1103: retrieve the file @file{/usr/spool/anonymous/INDEX} a user on a remote
1104: site could just enter @samp{uucp server!~/INDEX ~}; this would transfer
1105: @file{INDEX} from @samp{server}'s public directory to the user's local
1106: public directory. Note that when using @samp{csh} or @samp{bash} the
1107: @kbd{!} and the second @kbd{~} must be quoted.
1108:
1109: The next example will permit remote systems to upload files to a special
1110: directory named @file{/usr/spool/anonymous/upload}. Permitting a remote
1111: system to upload files permits it to send work requests as well; this
1112: example is careful to prohibit commands from unknown systems.
1113:
1114: @example
1115: # No commands may be executed (the list of permitted commands is empty)
1116: unknown commands
1117: # The public directory is /usr/spool/anonymous
1118: unknown pubdir /usr/spool/anonymous
1119: # Only files in the public directory may be sent; users may not download
1120: # files from the upload directory
1121: unknown remote-send ~ !~/upload
1122: # May only upload files into /usr/spool/anonymous/upload
1123: unknown remote-receive ~/upload
1124: @end example
1125:
1126: @node Leaf Example, Gateway Example, config File Examples, Configuration Examples
1127: @subsection Leaf Example
1128:
1129: @cindex leaf site
1130: @cindex sys file example (leaf)
1131: A relatively common simple case is a @dfn{leaf site}, a system which
1132: only calls or is called by a single remote site. Here is a typical
1133: @file{sys} file that might be used in such a case. For full details on
1134: what commands can appear in the @file{sys} file, see @ref{sys File}.
1135:
1136: This is the @file{sys} file that is used at @file{airs.com}. We use a
1137: single modem to dial out to @file{uunet}. This example shows how you
1138: can specify the port and dialer information directly in the @file{sys}
1139: file for simple cases. It also shows the use of the following:
1140:
1141: @table @code
1142:
1143: @item call-login
1144: Using @code{call-login} and @code{call-password} allows the default
1145: login chat script to be used. In this case, the login name is specified
1146: in the call-out login file (@pxref{Configuration File Names}).
1147:
1148: @item call-timegrade
1149: @file{uunet} is requested to not send us news during the daytime.
1150:
1151: @item chat-fail
1152: If the modem returns @samp{BUSY} or @samp{NO CARRIER} the call is
1153: immediately aborted.
1154:
1155: @item protocol-parameter
1156: Since @file{uunet} tends to be slow, the default timeout has been
1157: increased.
1158:
1159: @end table
1160:
1161: This @file{sys} file relies on certain defaults. It will allow
1162: @file{uunet} to queue up @samp{rmail} and @samp{rnews} commands. It
1163: will allow users to request files from @file{uunet} into the UUCP public
1164: directory. It will also @file{uunet} to request files from the UUCP
1165: public directory; in fact @file{uunet} never requests files, but for
1166: additional security we could add the line @samp{request false}.
1167:
1168: @example
1169: # The following information is for uunet
1170: system uunet
1171:
1172: # The login name and password are kept in the callout password file
1173: call-login *
1174: call-password *
1175:
1176: # We can send anything at any time.
1177: time any
1178:
1179: # During the day we only accept grade `Z' or above; at other times
1180: # (not mentioned here) we accept all grades. uunet queues up news
1181: # at grade `d', which is lower than `Z'.
1182: call-timegrade Z Wk0755-2305,Su1655-2305
1183:
1184: # The phone number.
1185: phone 7389449
1186:
1187: # uunet tends to be slow, so we increase the timeout
1188: chat-timeout 120
1189:
1190: # We are using a preconfigured Telebit 2500.
1191: port type modem
1192: port device /dev/ttyd0
1193: port baud 19200
1194: port carrier true
1195: port dialer chat "" ATZ\r\d\c OK ATDT\D CONNECT
1196: port dialer chat-fail BUSY
1197: port dialer chat-fail NO\sCARRIER
1198: port dialer complete \d\d+++\d\dATH\r\c
1199: port dialer abort \d\d+++\d\dATH\r\c
1200:
1201: # Increase the timeout and the number of retries.
1202: protocol-parameter g timeout 20
1203: protocol-parameter g retries 10
1204: @end example
1205:
1206: @node Gateway Example, , Leaf Example, Configuration Examples
1207: @subsection Gateway Example
1208:
1209: @cindex gateway
1210: @cindex sys file example (gateway)
1211: Many organizations have several local machines which are connected by
1212: UUCP, and a single machine which connects to the outside world. This
1213: single machine is often referred to as a @dfn{gateway} machine.
1214:
1215: For this example I will assume a fairly simple case. It should still
1216: provide a good general example. There are three machines, @file{elmer},
1217: @file{comton} and @file{bugs}. @file{elmer} is the gateway machine for
1218: which I will show the configuration file. @file{elmer} calls out to
1219: @file{uupsi}. As an additional complication, @file{uupsi} knows
1220: @file{elmer} as @file{airs}; this will show how a machine can have one
1221: name on an internal network but a different name to the external world.
1222: @file{elmer} has two modems. It also has an TCP/IP connection to
1223: @file{uupsi}, but since that is supposed to be reserved for interactive
1224: work (it is, perhaps, only a 9600 baud SLIP line) it will only use it if
1225: the modems are not available.
1226:
1227: A network this small would normally use a single @file{sys} file.
1228: However, for pedagogical purposes I will show two separate @file{sys}
1229: files, one for the local systems and one for @file{uupsi}. This is done
1230: with the @code{sysfile} command in the @file{config} file. Here is the
1231: @file{config} file.
1232:
1233: @example
1234: # This is config
1235: # The local sys file
1236: sysfile /usr/local/lib/uucp/sys.local
1237: # The remote sys file
1238: sysfile /usr/local/lib/uucp/sys.remote
1239: @end example
1240:
1241: Using the defaults feature of the @file{sys} file can greatly simplify
1242: the listing of local systems. Here is @file{sys.local}. Note that this
1243: assumes that the local systems are trusted; they are permited to request
1244: any world readable file and to write files into any world writable
1245: directory.
1246:
1247: @example
1248: # This is sys.local
1249: # Get the login name and password to use from the call-out file
1250: call-login *
1251: call-password *
1252:
1253: # The systems must use a particular login
1254: called-login Ulocal
1255:
1256: # Permit sending any world readable file
1257: local-send /
1258: remote-send /
1259:
1260: # Permit requesting into any world writable directory
1261: local-receive /
1262: remote-receive /
1263:
1264: # Call at any time
1265: time any
1266:
1267: # Use port1, then port2
1268: port port1
1269:
1270: alternate
1271:
1272: port port2
1273:
1274: # Now define the systems themselves. Because of all the defaults we
1275: # used, there is very little to specify for the systems themselves.
1276:
1277: system comton
1278: phone 5551212
1279:
1280: system bugs
1281: phone 5552424
1282: @end example
1283:
1284: The @file{sys.remote} file describes the @file{uupsi} connection. The
1285: @code{myname} command is used to change the UUCP name to @file{airs}
1286: when talking to @file{uupsi}.
1287:
1288: @example
1289: # This is sys.remote
1290: # Define uupsi
1291: system uupsi
1292:
1293: # The login name and password are in the call-out file
1294: call-login *
1295: call-password *
1296:
1297: # We can call out at any time
1298: time any
1299:
1300: # uupsi uses a special login name
1301: called-login Uuupsi
1302:
1303: # uuspi thinks of us as `airs'
1304: myname airs
1305:
1306: # The phone number
1307: phone 5554848
1308:
1309: # We use port2 first, then port1, then TCP
1310:
1311: port port2
1312:
1313: alternate
1314:
1315: port port1
1316:
1317: alternate
1318:
1319: # We don't bother to make a special entry in the port file for TCP, we
1320: # just describe the entire port right here. We use a special chat
1321: # script over TCP because the usual one confuses some TCP servers.
1322: port type TCP
1323: address uu.psi.com
1324: chat ogin: \L word: \P
1325: @end example
1326:
1327: The ports are defined in the file @file{port} (@pxref{port File}). For
1328: this example they are both connected to the same type of 2400 baud
1329: Hayes-compatible modem.
1330:
1331: @example
1332: # This is port
1333:
1334: port port1
1335: type modem
1336: device /dev/ttyd0
1337: dialer hayes
1338: speed 2400
1339:
1340: port port2
1341: type modem
1342: device /dev/ttyd1
1343: dialer hayes
1344: speed 2400
1345: @end example
1346:
1347: Dialers are described in the @file{dial} file (@pxref{dial File}).
1348:
1349: @example
1350: # This is dial
1351:
1352: dialer hayes
1353:
1354: # The chat script used to dial the phone. \D is the phone number.
1355: chat "" ATZ\r\d\c OK ATDT\D CONNECT
1356:
1357: # If we get BUSY or NO CARRIER we abort the dial immediately
1358: chat-fail BUSY
1359: chat-fail NO\sCARRIER
1360:
1361: # When the call is over we make sure we hangup the modem.
1362: complete \d\d+++\d\dATH\r\c
1363: abort \d\d+++\d\dATH\r\c
1364: @end example
1365:
1366: @node Time Strings, Chat Scripts, Configuration Examples, Configuration Files
1367: @section Time Strings
1368: @cindex time strings
1369:
1370: Several commands use time strings to specify a range of times. This
1371: section describes how to write time strings.
1372:
1373: A time string may be a list of simple time strings separated with a
1374: vertical bar @kbd{|} or a comma @kbd{,}.
1375:
1376: Each simple time string must begin with @samp{Su}, @samp{Mo}, @samp{Tu},
1377: @samp{We}, @samp{Th}, @samp{Fr}, or @samp{Sa}, or @samp{Wk} for any
1378: weekday, or @samp{Any} for any day.
1379:
1380: Following the day may be a range of hours separated with a hyphen using
1381: 24 hour time. The range of hours may cross 0; for example
1382: @samp{2300-0700} means any time except 7 AM to 11 PM. If no time is
1383: given, calls may be made at any time on the specified day(s).
1384:
1385: The time string may also consist of the single word @samp{Never}, which
1386: does not match any time, or a single word with a name defined in a
1387: previous @code{timetable} command (@pxref{Miscellaneous (config)}).
1388:
1389: Here are a few sample time strings with an explanation of what they
1390: mean.
1391:
1392: @table @samp
1393:
1394: @item Wk2305-0855,Sa,Su2305-1655
1395:
1396: This means weekdays before 8:55 AM or after 11:05 PM, any time Saturday,
1397: or Sunday before 4:55 PM or after 11:05 PM. These are approximately the
1398: times during which night rates apply to phone calls in the U.S.A. Note
1399: that this time string uses, for example, @samp{2305} rather than
1400: @samp{2300}; this will ensure a cheap rate phone call even if the
1401: computer clock is running up to five minutes ahead of the real time.
1402:
1403: @item Wk0905-2255,Su1705-2255
1404:
1405: This means weekdays from 9:05 AM to 10:55 PM, or Sunday from 5:05 PM to
1406: 10:55 PM. This is approximately the opposite of the previous example.
1407:
1408: @item Any
1409:
1410: This means any day. Since no time is specified, it means any time on
1411: any day.
1412:
1413: @end table
1414:
1415: @node Chat Scripts, config File, Time Strings, Configuration Files
1416: @section Chat Scripts
1417: @cindex chat scripts
1418:
1419: Chat scripts are used in several different places, such as dialing out
1420: on modems or logging in to remote systems. Chat scripts are made up of
1421: pairs of strings. The program waits until it sees the first string,
1422: known as the @dfn{expect} string, and then sends out the second string,
1423: the @dfn{send} string.
1424:
1425: Each chat script is defined using a set of commands. These commands
1426: always end in a string beginning with @code{chat}, but may start with
1427: different strings. For example, in the @file{sys} file there is one set
1428: of commands beginning with @code{chat} and another set beginning with
1429: @code{called-chat}. The prefixes are only used to disambiguate
1430: different types of chat scripts, and this section ignores the prefixes
1431: when describing the commands.
1432:
1433: @table @code
1434:
1435: @item chat @var{strings}
1436: @findex chat
1437:
1438: Specify a chat script. The arguments to the @code{chat} command are
1439: pairs of strings separated by whitespace. The first string of each pair
1440: is an expect string, the second is a send string. The program will wait
1441: for the expect string to appear; when it does, the program will send the
1442: send string. If the expect string does not appear within a certain
1443: number of seconds (as set by the @code{chat-timeout} command) the chat
1444: script fails and, typically, the call is aborted. If the final expect
1445: string is seen (and the optional final send string has been sent), the
1446: chat script is successful.
1447:
1448: An expect string may contain additional subsend and subexpect strings,
1449: separated by hyphens. If the expect string is not seen, the subsend
1450: string is sent and the chat script continues by waiting for the
1451: subexpect string. This means that a hyphen may not appear in an expect
1452: string; on an ASCII system, use @samp{\055} instead.
1453:
1454: An expect string may simply be @samp{""}, meaning to skip the expect
1455: phase. Otherwise, the following escape characters may appear in expect
1456: strings:
1457:
1458: @table @samp
1459: @item \b
1460: a backspace character
1461: @item \n
1462: a newline or line feed character
1463: @item \N
1464: a null character (for HDB compatibility)
1465: @item \r
1466: a carriage return character
1467: @item \s
1468: a space character
1469: @item \t
1470: a tab character
1471: @item \\
1472: a backslash character
1473: @item \@var{ddd}
1474: character @var{ddd}, where @var{ddd} are up to three octal digits
1475: @item \x@var{ddd}
1476: character @var{ddd}, where @var{ddd} are hexadecimal digits.
1477: @end table
1478:
1479: As in C, there may be up to three octal digits following a backslash,
1480: but the hexadecimal escape sequence continues as far as possible. To
1481: follow a hexadecimal escape sequence with a hex digit, interpose a send
1482: string of @samp{""}.
1483:
1484: A send string may simply be @samp{""} to skip the send phase.
1485: Otherwise, all of the escape characters legal for expect strings may be
1486: used, and the following escape characters are also permitted:
1487:
1488: @table @samp
1489: @item EOT
1490: send an end of transmission character (@kbd{^D})
1491: @item BREAK
1492: send a break character (may not work on all systems)
1493: @item \c
1494: suppress trailing carriage return at end of send string
1495: @item \d
1496: delay sending for 1 or 2 seconds
1497: @item \e
1498: disable echo checking
1499: @item \E
1500: enable echo checking
1501: @item \K
1502: same as @samp{BREAK} (for HDB compatibility)
1503: @item \p
1504: pause sending for a fraction of a second
1505: @end table
1506:
1507: Some specific types of chat scripts also define additional escape
1508: sequences that may appear in the send string. For example, the login
1509: chat script defines @samp{\L} and @samp{\P} to send the login name and
1510: password, respectively.
1511:
1512: A carriage return will be sent at the end of each send string, unless
1513: the @kbd{\c} escape sequence appears in the string. Note that some UUCP
1514: packages use @kbd{\b} for break, but here it means backspace.
1515:
1516: Echo checking means that after writing each character the program will
1517: wait until the character is echoed. Echo checking must be turned on
1518: separately for each send string for which it is desired; it will be
1519: turned on for characters following @kbd{\E} and turned off for characters
1520: following @kbd{\e}.
1521:
1522: @item chat-timeout @var{number}
1523: @findex chat-timeout
1524:
1525: The number of seconds to wait for an expect string in the chat script
1526: before timing out and sending the next subsend or failing the chat
1527: script entirely. The default value is 10 for a login chat or 60 for
1528: any other type of chat.
1529:
1530: @item chat-fail @var{string}
1531: @findex chat-fail
1532:
1533: If the @var{string} is seen at any time during a chat script, the chat
1534: script is aborted. The string may not contain any whitespace
1535: characters; escape sequences must be used for them. Multiple
1536: @code{chat-fail} commands may appear in a single chat script. The
1537: default is to have none.
1538:
1539: This permits a chat script to be quickly aborted if an error string is
1540: seen. For example, a script used to dial out on a modem might use the
1541: command @samp{chat-fail BUSY} to stop the chat script immediately if the
1542: string @samp{BUSY} was seen.
1543:
1544: @item chat-seven-bit @var{boolean}
1545: @findex chat-seven-bit
1546:
1547: If the argument is true, all incoming characters are stripped to seven
1548: bits when being compared to the expect string. Otherwise all eight bits
1549: are used in the comparison. The default is true, because some Unix
1550: systems generate parity bits during the login prompt which must be
1551: ignored while running a chat script. This has no effect on any
1552: @code{chat-program}, which must ignore parity by itself if necessary.
1553:
1554: @item chat-program @var{strings}
1555: @findex chat-program
1556:
1557: Specify a program to run before executing the chat script. This program
1558: could run its own version of a chat script, or it could do whatever it
1559: wants. If both @code{chat-program} and @code{chat} are specified, the
1560: program is executed first followed by the chat script.
1561:
1562: The first argument to the @code{chat-program} command is the program
1563: name to run. The remaining arguments are passed to the program. The
1564: following escape sequences are recognized in the arguments:
1565:
1566: @table @kbd
1567: @item \Y
1568: port device name
1569: @item \S
1570: port speed
1571: @item \\
1572: backslash
1573: @end table
1574:
1575: Some specific uses of @code{chat-program} define additional escape
1576: sequences.
1577:
1578: Arguments other than escape sequences are passed exactly as they appear
1579: in the configuration file, except that sequences of whitespace are
1580: compressed to a single space character (this exception may be removed in
1581: the future).
1582:
1583: If the @code{chat-program} command is not used, no program is run.
1584:
1585: On Unix, the standard input and standard output of the program will be
1586: attached to the port in use. Anything the program writes to standard
1587: error will be written to the UUCP log file. No other file descriptors
1588: will be open. If the program does not exit with a status of 0, it will
1589: be assumed to have failed; this means that the dialing programs used by
1590: some versions of HDB may not be used directly, although of course a
1591: shell script could be used as an interface.
1592:
1593: The program will be run as the @code{uucp} user, and the environment
1594: will be that of the process that started @code{uucico}, so care must be
1595: taken to maintain security.
1596:
1597: No search path is used to find the program; a full path name must be
1598: given. If the program is an executable shell script, it will be passed
1599: to @file{/bin/sh} even on systems which are unable to execute shell
1600: scripts. It is also easy to invoke @file{/bin/sh} directly.
1601:
1602: @end table
1603:
1604: Here is a simple example of a chat script that might be used to reset a
1605: Hayes compatible modem.
1606:
1607: @example
1608: chat "" ATZ OK-ATZ-OK
1609: @end example
1610:
1611: The first expect string is @samp{""}, so it is ignored. The chat script
1612: then sends @samp{ATZ}. If the modem responds with @samp{OK}, the chat
1613: script finishes. If 60 seconds (the default timeout) pass before seeing
1614: @samp{OK}, the chat script sends another @samp{ATZ}. If it then sees
1615: @samp{OK}, the chat script succeeds. Otherwise, the chat script fails.
1616:
1617: For a more complex chat script example, see @ref{Logging In}.
1618:
1619: @node config File, sys File, Chat Scripts, Configuration Files
1620: @section The Main Configuration File
1621: @cindex config file
1622: @cindex main configuration file
1623: @cindex configuration file (config)
1624:
1625: The main configuration file is named @file{config}.
1626:
1627: Since all the values that may be specified in the main configuration
1628: file also have defaults, there need not be a main configuration file at
1629: all.
1630:
1631: @menu
1632: * Miscellaneous (config):: Miscellaneous config file commands
1633: * Configuration File Names:: Using different configuration files
1634: * Log File Names:: Using different log files
1635: * Debugging Levels:: Debugging levels
1636: @end menu
1637:
1638: @node Miscellaneous (config), Configuration File Names, config File, config File
1639: @subsection Miscellaneous config File Commands
1640:
1641: @table @code
1642:
1643: @item nodename @var{string}
1644: @findex nodename
1645: @itemx hostname @var{string}
1646: @findex hostname
1647: @itemx uuname @var{string}
1648: @findex uuname
1649: @cindex UUCP system name
1650: @cindex system name
1651:
1652: These keywords are equivalent. They specify the UUCP name of the local
1653: host. If there is no configuration file, an appropriate system function
1654: will be used to get the host name, if possible.
1655:
1656: @item spool @var{string}
1657: @findex spool
1658: @cindex spool directory
1659: @cindex /usr/spool/uucp
1660:
1661: Specify the spool directory. The default is from @file{policy.h}. This
1662: is where UUCP files are queued. Status files and various sorts of
1663: temporary files are also stored in this directory and subdirectories of
1664: it.
1665:
1666: @item pubdir @var{string}
1667: @findex pubdir in config file
1668: @cindex public directory
1669: @cindex uucppublic
1670: @cindex /usr/spool/uucppublic
1671:
1672: Specify the public directory. The default is from @file{policy.h}.
1673: When a file is named using a leading @kbd{~/}, it is taken from or to
1674: the public directory. Each system may use a separate public directory
1675: by using the @code{pubdir} command in the system configuration file; see
1676: @ref{Miscellaneous (sys)}.
1677:
1678: @item lockdir @var{string}
1679: @findex lockdir
1680: @cindex lock directory
1681:
1682: Specify the directory to place lock files in. The default is from
1683: @file{policy.h}; see the information in that file. Normally the lock
1684: directory should be set correctly in @file{policy.h}, and not changed
1685: here. However, changing the lock directory is sometimes useful for
1686: testing purposes.
1687:
1688: @item unknown @var{string} @dots{}
1689: @findex unknown
1690: @cindex unknown systems
1691:
1692: The @var{string} and subsequent arguments are treated as though they
1693: appeared in the system file (@pxref{sys File}). They are used to apply
1694: to any unknown systems that may call in, probably to set file transfer
1695: permissions and the like. If the @code{unknown} command is not used,
1696: unknown systems are not permitted to call in.
1697:
1698: @item max-uuxqts @var{number}
1699: @findex max-uuxqts
1700:
1701: Specify the maximum number of @code{uuxqt} processes which may run at
1702: the same time. Having several @code{uuxqt} processes running at once
1703: can significantly slow down a system, but since @code{uuxqt} is
1704: automatically started by @code{uucico}, it can happen quite easily. The
1705: default for @code{max-uuxqts} is 0, which means that there is no limit.
1706: If HDB configuration files are being read and the code was compiled
1707: without @code{HAVE_TAYLOR_CONFIG}, then if the file @file{Maxuuxqts} in
1708: the configuration directory contains a readable number it will be used as
1709: the value for @code{max-uuxqts}.
1710:
1711: @item timetable @var{string} @var{string}
1712: @findex timetable
1713:
1714: The @code{timetable} defines a timetable that may be used in
1715: subsequently appearing time strings; @ref{Time Strings}. The first
1716: string names the timetable entry; the second is a time string.
1717:
1718: The following @code{timetable} commands are predefined. The NonPeak
1719: timetable is included for compatibility. It originally described the
1720: offpeak hours of Tymnet and Telenet, but both have since changed their
1721: schedules.
1722:
1723: @example
1724: timetable Evening Wk1705-0755,Sa,Su
1725: timetable Night Wk2305-0755,Sa,Su2305-1655
1726: timetable NonPeak Wk1805-0655,Sa,Su
1727: @end example
1728:
1729: If this command does not appear, then obviously no additional timetables
1730: will be defined.
1731:
1732: @item v2-files @var{boolean}
1733: @findex v2-files
1734:
1735: If the code was compiled to be able to read V2 configuration files, a
1736: false argument to this command will prevent them from being read.
1737: This can be useful while testing. The default is true.
1738:
1739: @item hdb-files @var{boolean}
1740: @findex hdb-files
1741:
1742: If the code was compiled to be able to read HDB configuration files, a
1743: false argument to this command will prevent them from being read.
1744: This can be useful while testing. The default is true.
1745:
1746: @end table
1747:
1748: @node Configuration File Names, Log File Names, Miscellaneous (config), config File
1749: @subsection Configuration File Names
1750:
1751: @table @code
1752:
1753: @item sysfile @var{strings}
1754: @findex sysfile
1755:
1756: Specify the system file(s). The default is the file @file{sys} in the
1757: directory @var{newconfigdir}. These files hold information about other
1758: systems with which this system communicates; see @ref{sys File}.
1759: Multiple system files may be given on the line, and the @code{sysfile}
1760: command may be repeated; each system file has its own set of defaults.
1761:
1762: @item portfile @var{strings}
1763: @findex portfile
1764:
1765: Specify the port file(s). The default is the file @file{port} in the
1766: directory @var{newconfigdir}. These files describe ports which are used
1767: to call other systems and accept calls from other systems; see @ref{port
1768: File}. No port files need be named at all. Multiple port files may be
1769: given on the line, and the @code{portfile} command may be repeated.
1770:
1771: @item dialfile @var{strings}
1772: @findex dialfile
1773:
1774: Specify the dial file(s). The default is the file @file{dial} in the
1775: directory @var{newconfigdir}. These files describe dialing devices
1776: (modems); @xref{dial File}. No dial files need be named at all.
1777: Multiple dial files may be given on the line, and the @code{dialfile}
1778: command may be repeated.
1779:
1780: @item dialcodefile @var{strings}
1781: @findex dialcodefile
1782: @cindex configuration file (dialcode)
1783: @cindex dialcode file
1784: @cindex dialcode configuration file
1785:
1786: Specify the dialcode file(s). The default is the file @file{dialcode}
1787: in the directory @var{newconfigdir}. These files specify dialcodes that
1788: may be used when sending phone numbers to a modem. This permits using
1789: the same set of phone numbers in different area-codes or with different
1790: phone systems, by using dialcodes to specify the calling sequence. When
1791: a phone number goes through dialcode translation, the leading alphabetic
1792: characters are stripped off. The dialcode files are read line by line,
1793: just like any other configuration file, and when a line is found whose
1794: first word is the same as the leading characters from the phone number,
1795: the second word on the line (which would normally consist of numbers)
1796: replaces the dialcode in the phone number. No dialcode file need be
1797: used. Multiple dialcode files may be specified on the line, and the
1798: @code{dialcodefile} command may be repeated; all the dialcode files will
1799: be read in turn until a dialcode is located.
1800:
1801: @item callfile @var{strings}
1802: @findex callfile
1803: @cindex call out file
1804: @cindex call configuration file
1805: @cindex call out login name
1806: @cindex call out password
1807: @cindex configuration file (call)
1808:
1809: Specify the call out login name and password file(s). The default is
1810: the file @file{call} in the directory @var{newconfigdir}. If the call
1811: out login name or password for a system are given as @kbd{*}
1812: (@pxref{Logging In}), these files are read to get the real login name or
1813: password. Each line in the file(s) has three words: the system name,
1814: the login name, and the password. This file is only used when placing
1815: calls to remote systems; the password file described under
1816: @code{passwdfile} below is used for incoming calls. The intention of
1817: the call out file is to permit the system file to be publically
1818: readable; the call out files must obviously be kept secure. These files
1819: need not be used. Multiple call out files may be specified on the line,
1820: and the @code{callfile} command may be repeated; all the files will be
1821: read in turn until the system is found.
1822:
1823: @item passwdfile @var{strings}
1824: @findex passwdfile
1825: @cindex passwd file
1826: @cindex passwd configuration file
1827: @cindex configuration file (passwd)
1828: @cindex call in login name
1829: @cindex call in password
1830:
1831: Specify the password file(s) to use for login names when @code{uucico}
1832: is doing its own login prompting, which it does when given the
1833: @samp{-e}, @samp{-l} or @samp{-w} switches. The default is the file
1834: @file{passwd} in the directory @var{newconfigdir}. Each line in the
1835: file(s) has two words: the login name and the password (e.g. @code{Ufoo
1836: foopas}). The login name is accepted before the system name is known,
1837: so these are independent of which system is calling in; a particular
1838: login may be required for a system by using the @code{called-login}
1839: command in the system file (@pxref{Accepting a Call}). These password
1840: files are optional, although one must exist if @code{uucico} is to
1841: present its own login prompts. Multiple password files may be specified
1842: on the line, and the @code{passwdfile} command may be repeated; all the
1843: files will be read in turn until the login name is found.
1844:
1845: @end table
1846:
1847: @node Log File Names, Debugging Levels, Configuration File Names, config File
1848: @subsection Log File Names
1849:
1850: @table @code
1851:
1852: @item logfile @var{string}
1853: @findex logfile
1854: @cindex log file
1855:
1856: Name the log file. The default is from @file{policy.h}. Logging
1857: information is written to this file. If @code{HAVE_HDB_LOGGING} is
1858: defined in @file{conf.h}, then by default a separate log file is used
1859: for each system. Using this command to name a log file will cause all
1860: the systems to use it.
1861:
1862: @item statfile @var{string}
1863: @findex statfile
1864: @cindex statistics file
1865:
1866: Name the statistics file. The default is from @file{policy.h}.
1867: Statistical information about file transfers is written to this file.
1868:
1869: @item debugfile @var{string}
1870: @findex debugfile
1871: @cindex debugging file
1872:
1873: Name the file to which debugging information is written. The default is
1874: from @file{policy.h}. This command is only effective if the code has
1875: been compiled to include debugging (this is controlled by the
1876: @code{DEBUG} variable in @file{policy.h}). After the first debugging
1877: message has been written, messages written to the log file are also
1878: written to the debugging file to make it easier to keep the order of
1879: actions straight. The debugging file is different from the log file
1880: because information such as passwords can appear in it, so it must be
1881: not be publically readable.
1882:
1883: @end table
1884:
1885: @node Debugging Levels, , Log File Names, config File
1886: @subsection Debugging Levels
1887:
1888: @table @code
1889:
1890: @item debug @var{string} @dots{}
1891: @findex debug in config file
1892:
1893: Set the debugging level. This command is only effective if the code has
1894: been compiled to include debugging. The default is to have no
1895: debugging. The arguments are strings which name the types of debugging
1896: to be turned on. The following types of debugging are defined:
1897:
1898: @table @samp
1899: @item abnormal
1900: Output debugging messages for abnormal situations, such as recoverable errors.
1901: @item chat
1902: Output debugging messages for chat scripts.
1903: @item handshake
1904: Output debugging messages for the initial handshake.
1905: @item uucp-proto
1906: Output debugging messages for the UUCP session protocol.
1907: @item proto
1908: Output debugging messages for the individual link protocols.
1909: @item port
1910: Output debugging messages for actions on the communication port.
1911: @item config
1912: Output debugging messages while reading the configuration files.
1913: @item spooldir
1914: Output debugging messages for actions in the spool directory.
1915: @item execute
1916: Output debugging messages whenever another program is executed.
1917: @item incoming
1918: List all incoming data in the debugging file.
1919: @item outgoing
1920: List all outgoing data in the debugging file.
1921: @item all
1922: All of the above.
1923: @end table
1924:
1925: The debugging level may also be specified as a number. A 1 will set
1926: @samp{chat} debugging, a 2 will set both @samp{chat} and
1927: @samp{handshake} debugging, and so on down the possibilities. Currently
1928: an 11 will turn on all possible debugging, since there are 11 types of
1929: debugging messages listed above; more debugging types may be added in
1930: the future. The @code{debug} command may be used several times in the
1931: configuration file; every debugging type named will be turned on. When
1932: running any of the programs, the @samp{-x} switch (actually, for
1933: @code{uulog} it's the @samp{-X} switch) may be used to turn on
1934: debugging. The argument to the @samp{-x} switch is one of the strings
1935: listed above, or a number as described above, or a comma separated list
1936: of strings (e.g. @samp{-x chat,handshake}). The @samp{-x} switch may
1937: also appear several times on the command line, in which case all named
1938: debugging types will be turned on. The @samp{-x} debugging is in
1939: addition to any debugging specified by the @code{debug} command; there
1940: is no way to cancel debugging information. The debugging level may also
1941: be set specifically for calls to or from a specific system with the
1942: @code{debug} command in the system file (@pxref{Miscellaneous (sys)}).
1943:
1944: The debugging messages are somewhat idiosyncratic; it may be necessary
1945: to refer to the source code for additional information in some cases.
1946:
1947: @end table
1948:
1949: @node sys File, port File, config File, Configuration Files
1950: @section The System Configuration File
1951: @cindex sys file
1952: @cindex system configuration file
1953: @cindex configuration file (sys)
1954:
1955: By default there is a single system configuration, named @file{sys} in
1956: the directory @var{newconfigdir}. This may be overridden by the
1957: @code{sysfile} command in the main configuration file; see
1958: @ref{Configuration File Names}.
1959:
1960: These files describe all remote systems known to the UUCP package.
1961:
1962: @menu
1963: * Defaults and Alternates:: Using defaults and alternates
1964: * Naming the System:: Naming the system
1965: * Calling Out:: Calling out
1966: * Accepting a Call:: Accepting a call
1967: * Protocol Selection:: Protocol selection
1968: * File Transfer Control:: File transfer control
1969: * Miscellaneous (sys):: Miscellaneous sys file commands
1970: * Default sys File Values:: Default values
1971: @end menu
1972:
1973: @node Defaults and Alternates, Naming the System, sys File, sys File
1974: @subsection Defaults and Alternates
1975:
1976: The first set of commands in the file, up to the first @code{system}
1977: command, specify defaults to be used for all systems in that file. Each
1978: system file uses a different set of defaults.
1979:
1980: Subsequently, each set of commands from @code{system} up to the next
1981: @code{system} command describe a particular system. Default values may
1982: be overridden for specific systems.
1983:
1984: Each system may then have a series of alternate choices to use when
1985: calling out or calling in. The first set of commands for a particular
1986: system, up to the first @code{alternate} command, provide the first
1987: choice. Subsequently, each set of commands from @code{alternate} up to
1988: the next @code{alternate} command describe an alternate choice for
1989: calling out or calling in.
1990:
1991: When a system is called, the commands before the first @code{alternate}
1992: are used to select a phone number, port, and so forth; if the call fails
1993: for some reason, the commands between the first @code{alternate} and the
1994: second are used, and so forth. Well, not quite. Actually, each
1995: succeeding alternate will only be used if it is different in some
1996: relevant way (different phone number, different chat script, etc.). If
1997: you want to force the same alternate to be used again (to retry a phone
1998: call more than once, for example), enter the phone number (or any other
1999: relevant field) again to make it appear different.
2000:
2001: The alternates can also be used to give different permissions to an
2002: incoming call based on the login name. This will only be done if the
2003: first set of commands, before the first @code{alternate} command, uses
2004: the @code{called-login} command. The list of alternates will be
2005: searched, and the first alternate with a matching @code{called-login}
2006: command will be used. If no alternates match, the call will be
2007: rejected.
2008:
2009: The @code{alternate} command may also be used in the file-wide defaults
2010: (the set of commands before the first @code{system} command). This
2011: might be used to specify a list of ports which are available for all
2012: systems (for an example of this, see @ref{Gateway Example}) or to
2013: specify permissions based on the login name used by the remote system
2014: when it calls in. The first alternate for each system will default to
2015: the first alternate for the file-wide defaults (as modified by the
2016: commands used before the first @code{alternate} command for this
2017: system), the second alternate for each system to the second alternate
2018: for the file-wide defaults (as modified the same way), and so forth. If
2019: a system specifies more alternates than the file-wide defaults, the
2020: trailing ones will default to the last file-wide default alternate. If
2021: a system specifies fewer alternates than the file-wide defaults, the
2022: trailing file-wide default alternates will be used unmodified. The
2023: @code{default-alternates} command may be used to modify this behaviour.
2024:
2025: This can all get rather confusing, although it's easier to use than to
2026: describe concisely; the @code{uuchk} program may be used to ensure that
2027: you are getting what you want.
2028:
2029: @node Naming the System, Calling Out, Defaults and Alternates, sys File
2030: @subsection Naming the System
2031:
2032: @table @code
2033:
2034: @item system @var{string}
2035: @findex system
2036:
2037: Specify the remote system name. Subsequent commands up to the next
2038: @code{system} command refer to this system.
2039:
2040: @item alternate [@var{string}]
2041: @findex alternate
2042:
2043: Start an alternate set of commands (@pxref{Defaults and Alternates}).
2044: An optional argument may be used to name the alternate. This name will
2045: be put in the log file if the alternate is used to call the system.
2046: There is no way to name the first alternate (the commands before the
2047: first @code{alternate} command).
2048:
2049: @item default-alternates @var{boolean}
2050: @findex default-alternates
2051:
2052: If the argument is false, any remaining default alternates (from the
2053: defaults specified at the top of the current system file) will not be
2054: used. The default is true.
2055:
2056: @item alias @var{string}
2057: @findex alias
2058:
2059: Specify an alias for the current system. The alias may be used by local
2060: @code{uucp} and @code{uux} commands, as well as by the remote system
2061: (which can be convenient if a remote system changes its name). The
2062: default is to have no aliases.
2063:
2064: @item myname @var{string}
2065: @findex myname
2066:
2067: Specifies a different system name to use when calling the remote system.
2068: Also, if @code{called-login} is used and is not @samp{ANY}, then, when a
2069: system logs in with that login name, @var{string} is used as the system
2070: name. Because the local system name must be determined before the
2071: remote system has identified itself, using @code{myname} and
2072: @code{called-login} together for any system will set the local name for
2073: that login; this means that each locally used system name must have a
2074: unique login name associated with it. This allows a system to have
2075: different names for an external and an internal network. The default is
2076: to not use a special local name.
2077:
2078: @end table
2079:
2080: @node Calling Out, Accepting a Call, Naming the System, sys File
2081: @subsection Calling Out
2082:
2083: This section describes commands used when placing a call to another
2084: system.
2085:
2086: @menu
2087: * When to Call:: When to call
2088: * Placing the Call:: Placing the call
2089: * Logging In:: Logging in
2090: @end menu
2091:
2092: @node When to Call, Placing the Call, Calling Out, Calling Out
2093: @subsubsection When to Call
2094:
2095: @table @code
2096:
2097: @item time @var{string} [@var{number}]
2098: @findex time
2099:
2100: Specify when the system may be called. The first argument is a time
2101: string; see @ref{Time Strings}. The optional second argument specifies
2102: a retry time in minutes. If a call made during a time that matches the
2103: time string fails, no more calls are permitted until the retry time has
2104: passed. By default an exponentially increasing retry time is used:
2105: after each failure the next retry period is longer. A retry time
2106: specified in the @code{time} command is always a fixed amount of time.
2107:
2108: The @code{time} command may appear multiple times in a single alternate,
2109: in which case if any time string matches the system may be called. When
2110: the @code{time} command is used for a particular system, any @code{time}
2111: or @code{timegrade} commands that appeared in the system defaults are
2112: ignored.
2113:
2114: The default time string is @samp{Never}.
2115:
2116: @item timegrade @var{character} @var{string} [@var{number}]
2117: @findex timegrade
2118:
2119: The @var{character} specifies a grade. It must be a single letter or
2120: digit. The @var{string} is a time string (@pxref{Time Strings}). All
2121: jobs of grade @var{character} or higher (where @kbd{0} > @kbd{9} >
2122: @kbd{A} > @kbd{Z} > @kbd{a} > @kbd{z}) may be run at the specified time.
2123: An ordinary @code{time} command is equivalent to using @code{timegrade}
2124: with a grade of @kbd{z}, permitting all jobs. If there are no jobs of a
2125: sufficiently high grade according to the time string, the system will
2126: not be called. Giving the @samp{-s} switch to @code{uucico} to force it
2127: to call a system causes it to assume there is a job of grade @kbd{0}
2128: waiting to be run.
2129:
2130: The optional third argument specifies a retry time in minutes. See the
2131: @code{time} command, above, for more details.
2132:
2133: Note that the @code{timegrade} command serves two purposes: 1) if there
2134: is no job of sufficiently high grade the system will not be called, and
2135: 2) if the system is called anyway (because the @samp{-s} switch was
2136: given to @code{uucico}) only jobs of sufficiently high grade will be
2137: transferred. However, if the other system calls in, the
2138: @code{timegrade} commands are ignored, and jobs of any grade may be
2139: transferred (but see @code{call-timegrade} below). Also, the
2140: @code{timegrade} command will not prevent the other system from
2141: transferring any job it chooses, regardless of who placed the call.
2142:
2143: The @code{timegrade} command may appear multiple times without using
2144: @code{alternate}. When the @code{timegrade} command is used for a
2145: particular system, any @code{time} or @code{timegrade} commands that
2146: appeared in the system defaults are ignored.
2147:
2148: If this command does not appear, there are no restrictions on what grade
2149: of work may be done at what time.
2150:
2151: @item max-retries @var{number}
2152: @findex max-retries
2153:
2154: Gives the maximum number of times this system may be retried. If this
2155: many calls to the system fail, it will be called at most once a day
2156: whatever the retry time is. The default is 26.
2157:
2158: @item success-wait @var{number}
2159:
2160: A retry time, in seconds, which applies after a successful call. This
2161: can be used to put a limit on how frequently the system is called. For
2162: example, an argument of 1800 means that the system will not be called
2163: more than once every half hour. The default is 0, which means that
2164: there is no limit.
2165:
2166: @item call-timegrade @var{character} @var{string}
2167: @findex call-timegrade
2168:
2169: The @var{character} is a single character @kbd{A} to @kbd{Z}, @kbd{a} to
2170: @kbd{z}, or @kbd{0} to @kbd{9} and specifies a grade. The @var{string}
2171: is a time string as described under the @code{time} command. If a call
2172: is placed to the other system during a time which matches the time
2173: string, the remote system will be requested to only run jobs of grade
2174: @var{character} or higher. Unfortunately, there is no way to guarantee
2175: that the other system will obey the request (this UUCP package will, but
2176: there are others which will not); moreover job grades are historically
2177: somewhat arbitrary, so specifying a grade will only be meaningful if the
2178: other system cooperates in assigning grades. This grade restriction
2179: only applies when the other system is called, not when the other system
2180: calls in.
2181:
2182: The @code{call-timegrade} command may appear multiple times without
2183: using @code{alternate}. If this command does not appear, or if none of
2184: the time strings match, the remote system will be allowed to send
2185: whatever grades of work it chooses.
2186:
2187: @end table
2188:
2189: @node Placing the Call, Logging In, When to Call, Calling Out
2190: @subsubsection Placing the Call
2191:
2192: @table @code
2193:
2194: @item baud @var{number}
2195: @findex baud in sys file
2196: @itemx speed @var{number}
2197: @findex speed in sys file
2198:
2199: Specify the speed (the term @dfn{baud} is technically incorrect, but
2200: widely understood) at which to call the system. This will try all
2201: available ports with that baud rate until an unlocked port is found.
2202: The ports are defined in the port file. If both @code{baud} and
2203: @code{port} commands appear, both are used when selecting a port. To
2204: allow calls at more than one baud rate, the @code{alternate} command
2205: must be used (@pxref{Defaults and Alternates}). If this command does
2206: not appear, there is no default; the baud rate may be specified in the
2207: port file, but if it is not then the natural baud rate of the port will
2208: be used (whatever that means on the system). Specifying an explicit
2209: baud rate of 0 will request the natural baud rate of the port,
2210: overriding any default baud rate from the defaults at the top of the
2211: file.
2212:
2213: @item port @var{string}
2214: @findex port in sys file
2215:
2216: Name a particular port or type of port to use when calling the system.
2217: The information for this port is obtained from the port file. If this
2218: command does not appear, there is no default; a port must somehow be
2219: specified in order to call out (it may be specified implicitly using the
2220: @code{baud} command or explicitly using the next version of
2221: @code{port}). There may be many ports with the same name; each will be
2222: tried in turn until an unlocked one is found which matches the desired
2223: baud rate.
2224:
2225: @item port @var{string} @dots{}
2226:
2227: If more than one string follows the @code{port} command, the strings are
2228: treated as a command that might appear in the port file (@pxref{port
2229: File}). If a port is named (by using a single string following
2230: @code{port}) these commands are ignored; their purpose is to permit
2231: defining the port completely in the system file rather than always
2232: requiring entries in two different files. In order to call out, a port
2233: must be specified using some version of the @code{port} command, or by
2234: using the @code{baud} command to select ports from the port file.
2235:
2236: @item phone @var{string}
2237: @findex phone
2238: @itemx address @var{string}
2239: @findex address
2240:
2241: Give a phone number to call (when using a modem port) or a remote host
2242: to contact (when using a TCP or TLI port). The commands @code{phone}
2243: and @code{address} are equivalent; the duplication is intended to
2244: provide a mnemonic choice depending on the type of port in use.
2245:
2246: When used with a modem port, an @kbd{=} character in the phone number
2247: means to wait for a secondary dial tone (although only some modems
2248: support this); a @kbd{-} character means to pause while dialing for 1
2249: second (again, only some modems support this). If the system has more
2250: than one phone number, each one must appear in a different alternate.
2251: The @code{phone} command must appear in order to call out on a modem;
2252: there is no default.
2253:
2254: When used with a TCP port, the string names the host to contact. It may
2255: be a domain name or a numeric Internet address. If no address is
2256: specified, the system name is used.
2257:
2258: When used with a TLI port, the string is treated as though it were an
2259: expect string in a chat script, allowing the use of escape characters
2260: (@pxref{Chat Scripts}). The @code{dialer-sequence} command in the port
2261: file may override this address (@pxref{port File}).
2262:
2263: When used with a port that not a modem or TCP or TLI, this command is
2264: ignored.
2265:
2266: @end table
2267:
2268: @node Logging In, , Placing the Call, Calling Out
2269: @subsubsection Logging In
2270: @table @code
2271:
2272: @item chat @var{strings}
2273: @findex chat in sys file
2274: @item chat-timeout @var{number}
2275: @findex chat-timeout in sys file
2276: @item chat-fail @var{string}
2277: @findex chat-fail in sys file
2278: @item chat-seven-bit @var{boolean}
2279: @findex chat-seven-bit in sys file
2280: @item chat-program @var{strings}
2281: @findex chat-program in sys file
2282:
2283: These commands describe a chat script to use when logging on to a remote
2284: system. Chat scripts are explained in @ref{Chat Scripts}.
2285:
2286: Two additional escape sequences may be used in send strings.
2287:
2288: @table @samp
2289: @item \L
2290: Send the login name, as set by the @code{call-login} command.
2291: @item \P
2292: Send the password, as set by the @code{call-password} command.
2293: @end table
2294:
2295: Three additional escape sequences may be used with the
2296: @code{chat-program} command. These are @samp{\L} and @samp{\P}, which
2297: become the login name and password, respectively, and @samp{\Z}, which
2298: becomes the name of the system of being called.
2299:
2300: The default chat script is:
2301:
2302: @example
2303: chat "" \r\c ogin:-BREAK-ogin:-BREAK-ogin: \L word: \P
2304: @end example
2305:
2306: This will send a carriage return (the @kbd{\c} suppresses the additional
2307: trailing carriage return that would otherwise be sent) and waits for the
2308: string @samp{ogin:} (which would be the last part of the @samp{login:}
2309: prompt supplied by a Unix system). If it doesn't see @samp{ogin:}, it
2310: sends a break and waits for @samp{ogin:} again. If it still doesn't see
2311: @samp{ogin:}, it sends another break and waits for @samp{ogin:} again.
2312: If it still doesn't see @samp{ogin:}, the chat script aborts and hangs
2313: up the phone. If it does see @samp{ogin:} at some point, it sends the
2314: login name (as specified by the @code{call-login} command) followed by a
2315: carriage return (since all send strings are followed by a carriage
2316: return unless @kbd{\c} is used) and waits for the string @samp{word:}
2317: (which would be the last part of the @samp{Password:} prompt supplied by
2318: a Unix system). If it sees @samp{word:}, it sends the password and a
2319: carriage return, completing the chat script. The program will then
2320: enter the handshake phase of the UUCP protocol.
2321:
2322: This chat script will work for most systems, so you will only be
2323: required to use the @code{call-login} and @code{call-password} commands.
2324: In fact, in the file-wide defaults you could set defaults of
2325: @samp{call-login *} and @samp{call-password *}; you would then just have
2326: to make an entry for each system in the call-out login file.
2327:
2328: Some systems seem to flush input after the @samp{login:} prompt, so they
2329: may need a version of this chat script with a @kbd{\d} before the
2330: @kbd{\L}. When using UUCP over TCP, some servers will not be handle the
2331: initial carriage return sent by this chat script; in this case you may
2332: have to specify the simple chat script @samp{ogin: \L word: \P}.
2333:
2334: @item call-login @var{string}
2335: @findex call-login
2336:
2337: Specify the login name to send with @kbd{\L} in the chat script. If the
2338: string is @samp{*} (e.g. @samp{call-login *}) the login name will be
2339: fetched from the call out login name and password file
2340: (@pxref{Configuration File Names}). There is no default.
2341:
2342: @item call-password @var{string}
2343: @findex call-password
2344:
2345: Specify the password to send with @kbd{\P} in the chat script. If the
2346: string is @samp{*} (e.g. @samp{call-password *}) the password will be
2347: fetched from the call-out login name and password file
2348: (@pxref{Configuration File Names}). There is no default.
2349:
2350: @end table
2351:
2352: @node Accepting a Call, Protocol Selection, Calling Out, sys File
2353: @subsection Accepting a Call
2354:
2355: @table @code
2356:
2357: @item called-login @var{strings}
2358: @findex called-login
2359:
2360: The first @var{string} specifies the login name that the system must use
2361: when calling in. If it is @samp{ANY} (e.g. @samp{called-login ANY}) any
2362: login name may be used; this is useful to override a file-wide default
2363: and to indicate that future alternates may have different login names.
2364: Case is significant. The default value is @samp{ANY}.
2365:
2366: Different alternates (@pxref{Defaults and Alternates}) may use different
2367: @code{called-login} commands, in which case the login name will be used
2368: to select which alternate is in effect; this will only work if the first
2369: alternate (before the first @code{alternate} command) uses the
2370: @code{called-login} command.
2371:
2372: Additional strings may be specified after the login name; they are a
2373: list of which systems are permitted to use this login name. If this
2374: feature is used, then normally the login name will only be given in a
2375: single @code{called-login} command. Only systems which appear on the
2376: list, or which use an explicit @code{called-login} command, will be
2377: permitted to use that login name. If the same login name is used more
2378: than once with a list of systems, all the lists are concatenated
2379: together. This feature permits you to restrict a login name to a
2380: particular set of systems without requiring you to use the
2381: @code{called-login} command for every single system; you can achieve a
2382: similar effect by using a different system file for each permitted login
2383: name with an appropriate @code{called-login} command in the file-wide
2384: defaults.
2385:
2386: @item callback @var{boolean}
2387: @findex callback
2388:
2389: If @var{boolean} is true, then when the remote system calls
2390: @code{uucico} will hang up the connection and prepare to call it back.
2391: The default is false.
2392:
2393: @item called-chat @var{strings}
2394: @findex called-chat
2395: @item called-chat-timeout @var{number}
2396: @findex called-chat-timeout
2397: @item called-chat-fail @var{string}
2398: @findex called-chat-fail
2399: @item called-chat-seven-bit @var{boolean}
2400: @findex called-chat-seven-bit
2401: @item called-chat-program @var{strings}
2402: @findex called-chat-program
2403:
2404: These commands may be used to define a chat script (@pxref{Chat
2405: Scripts}) that is run whenever the local system is called by the system
2406: being defined. The chat script defined by the @code{chat} command
2407: (@pxref{Logging In}), on the other hand, is used when the remote system
2408: is called. This called chat script might be used to set special modem
2409: parameters that are appropriate to a particular system. It is run after
2410: protocol negotiation is complete, but before the protocol has been
2411: started. See @ref{Logging In} for additional escape sequence which may
2412: be used besides those defined for all chat scripts. There is no default
2413: called chat script. If the called chat script fails, the incoming call
2414: will be aborted.
2415:
2416: @end table
2417:
2418: @node Protocol Selection, File Transfer Control, Accepting a Call, sys File
2419: @subsection Protocol Selection
2420:
2421: @table @code
2422:
2423: @item protocol @var{string}
2424: @findex protocol in sys file
2425:
2426: Specifies which protocols to use for the other system, and in which
2427: order to use them. This would not normally be used. For example,
2428: @samp{protocol tfg}.
2429:
2430: The default depends on the characteristics of the port and the dialer,
2431: as specified by the @code{seven-bit} and @code{reliable} commands. If
2432: neither the port nor the dialer use either of these commands, the
2433: default is to assume an eight-bit reliable connection. The commands
2434: @samp{seven-bit true} or @samp{reliable false} might be used in either
2435: the port or the dialer to change this. Each protocol has particular
2436: requirements that must be met before it will be considered during
2437: negotiation with the remote side.
2438:
2439: The @samp{t} and @samp{e} protocols are intended for use over TCP or
2440: some other communication path with end to end reliability, as they do no
2441: checking of the data at all. They will only be considered on a TCP port
2442: which is both reliable and eight bit.
2443:
2444: The @samp{i} protocol is a bidirectional protocol. It requires an
2445: eight-bit connection. It will run over a half-duplex link, such as
2446: Telebit modems in PEP mode, but for efficient use of such a connection
2447: you must use the @code{half-duplex} command (@pxref{port File}).
2448:
2449: The @samp{g} protocol is robust, but requires an eight-bit connection.
2450:
2451: The @samp{G} protocol is the System V Release 4 version of the @samp{g}
2452: protocol.
2453:
2454: The @samp{a} protocol is a Zmodem like protocol, contributed by Doug
2455: Evans. It requires an eight-bit connection, but unlike the @samp{g} or
2456: @samp{i} protocol it will work if certain control characters may not be
2457: transmitted.
2458:
2459: The @samp{j} protocol is a variant of the @samp{i} protocol which can
2460: avoid certain control characters. The set of characters it avoids can
2461: be set by a parameter. While it technically does not require an eight
2462: bit connection (it could be configured to avoid all characters with the
2463: high bit set) it would be very inefficient to use it over one. It is
2464: useful over a eight-bit connection that will not transmit certain
2465: control characters.
2466:
2467: The @samp{f} protocol is intended for use with X.25 connections; it
2468: checksums each file as a whole, so any error causes the entire file to
2469: be retransmitted. It requires a reliable connection, but only uses
2470: seven-bit transmissions. It is a streaming protocol, so, while it can
2471: be used on a serial port, the port must be completely reliable and flow
2472: controlled; many aren't.
2473:
2474: The protocols will be considered in the order shown above. This means
2475: that if neither the @code{seven-bit} nor the @code{reliable} command are
2476: used, the @samp{t} protocol will be used over a TCP connection and the
2477: @samp{i} protocol will be used over any other type of connection
2478: (subject, of course, to what is supported by the remote system; it may
2479: be assumed that all systems support the @samp{g} protocol).
2480:
2481: Note that currently specifying both @samp{seven-bit true} and
2482: @samp{reliable false} will not match any protocol. If this occurs
2483: through a combination of port and dialer specifications, you will have
2484: to use the @code{protocol} command for the system or no protocol will be
2485: selected at all (the only reasonable choice would be @samp{protocol f}).
2486:
2487: A protocol list may also be specified for a port (@pxref{port File}),
2488: but if there is a list for the system the list for the port is ignored.
2489:
2490: @item protocol-parameter @var{character} @var{string} @dots{}
2491: @findex protocol-parameter in sys file
2492:
2493: @var{character} is a single character specifying a protocol. The
2494: remaining strings are a command specific to that protocol which will be
2495: executed if that protocol is used. A typical command is something like
2496: @samp{window 7}. The particular commands are protocol specific.
2497:
2498: The @samp{i} protocol supports the following commands, all of which take
2499: numeric arguments:
2500:
2501: @table @code
2502: @item window
2503: The window size to request the remote system to use. This must be
2504: between 1 and 31 inclusive. The default is 16.
2505: @item packet-size
2506: The packet size to request the remote system to use. This must be
2507: between 1 and 4095 inclusive. The default is 1024.
2508: @item remote-window
2509: If this is between 1 and 31 inclusive, the window size requested by the
2510: remote system is ignored and this is used instead. The default is 0,
2511: which means that the remote system's request is honored.
2512: @item remote-packet-size
2513: If this is between 1 and 4095 inclusive, the packet size requested by
2514: the remote system is ignored and this is used instead. The default is
2515: 0, which means that the remote system's request is honored.
2516: @item sync-timeout
2517: The length of time, in seconds, to wait for a SYNC packet from the remote
2518: system. SYNC packets are exchanged when the protocol is started. The
2519: default is 10.
2520: @item sync-retries
2521: The number of times to retry sending a SYNC packet before giving up.
2522: The default is 6.
2523: @item timeout
2524: The length of time, in seconds, to wait for an incoming packet before
2525: sending a negative acknowledgement. The default is 10.
2526: @item retries
2527: The number of times to retry sending a packet or a negative
2528: acknowledgement before giving up and closing the connection. The
2529: default is 6.
2530: @item errors
2531: The maximum number of errors to permit before closing the connection.
2532: The default is 100.
2533: @item error-decay
2534: The rate at which to ignore errors. Each time this many packets are
2535: received, the error count is decreased by one, so that a long connection
2536: with an occasional error will not exceed the limit set by @code{errors}.
2537: The default is 10.
2538: @end table
2539:
2540: The @samp{g} and @samp{G} protocols support the following commands, all
2541: of which take numeric arguments, except @code{short-packets} which takes
2542: a boolean argument:
2543:
2544: @table @code
2545: @item window
2546: The window size to request the remote system to use. This must be
2547: between 1 and 7 inclusive. The default is 7.
2548: @item packet-size
2549: The packet size to request the remote system to use. This must be a
2550: power of 2 between 32 and 4096 inclusive. The default is 64, which is
2551: the only packet size supported by many older UUCP packages. Some UUCP
2552: packages will even dump core if a larger packet size is requested.
2553: @item startup-retries
2554: The number of times to retry the initialization sequence. The default
2555: is 8.
2556: @item init-retries
2557: The number of times to retry one phase of the initialization sequence
2558: (there are three phases). The default is 4.
2559: @item init-timeout
2560: The timeout in seconds for one phase of the initialization sequence. The
2561: default is 10.
2562: @item retries
2563: The number of times to retry sending either a data packet or a request
2564: for the next packet. The default is 6.
2565: @item timeout
2566: The timeout in seconds when waiting for either a data packet or an
2567: acknowledgement. The default is 10.
2568: @item garbage
2569: The number of unrecognized bytes to permit before dropping the
2570: connection. This must be larger than the packet size. The default is
2571: 10000.
2572: @item errors
2573: The number of errors (malformed packets, out of order packets, bad
2574: checksums, or packets rejected by the remote system) to permit before
2575: dropping the connection. The default is 100.
2576: @item error-decay
2577: The rate at which to ignore errors. Each time this many packets are
2578: received, the error count is decreased by one, so that a long connection
2579: with an occasional error will not exceed the limit set by @code{errors}.
2580: The default is 10.
2581: @item remote-window
2582: If this is between 1 and 7 inclusive, the window size requested by the
2583: remote system is ignored and this is used instead. This can be useful
2584: when dealing with some poor UUCP packages. The default is 0, which
2585: means that the remote system's request is honored.
2586: @item remote-packet-size
2587: If this is between 32 and 4096 inclusive the packet size requested by
2588: the remote system is ignored and this is used instead. There is
2589: probably no good reason to use this. The default is 0, which means that
2590: the remote system's request is honored.
2591: @item short-packets
2592: If this is true, then the code will optimize by sending shorter packets
2593: when there is less data to send. This confuses some UUCP packages, such
2594: as System V Release 4 (when using the @samp{G} protocol) and Waffle;
2595: when connecting to such a package, this parameter must be set to false.
2596: The default is true for the @samp{g} protocol and false for the @samp{G}
2597: protocol.
2598: @end table
2599:
2600: The @samp{a} protocol is a Zmodem like protocol contributed by Doug
2601: Evans. It supports the following commands, all of which take numeric
2602: arguments except for @code{escape-control}, which takes a boolean
2603: argument:
2604:
2605: @table @code
2606: @item timeout
2607: Number of seconds to wait for a packet to arrive. The default is 10.
2608: @item retries
2609: The number of times to retry sending a packet. The default is 10.
2610: @item startup-retries
2611: The number of times to retry sending the initialization packet. The
2612: default is 4.
2613: @item garbage
2614: The number of garbage characters to accept before closing the
2615: connection. The default is 2400.
2616: @item send-window
2617: The number of characters that may be sent before waiting for an
2618: acknowledgement. The default is 1024.
2619: @item escape-control
2620: Whether to escape control characters. If this is true, the protocol may
2621: be used over a connection which does not transmit certain control
2622: characters, such as @code{XON} or @code{XOFF}. The connection must
2623: still transmit eight bit characters other than control characters. The
2624: default is false.
2625: @end table
2626:
2627: The @samp{j} protocol can be used over an eight bit connection that will
2628: not transmit certain control characters. It accepts the same protocol
2629: parameters that the @samp{i} protocol accepts, as well as one more:
2630:
2631: @table @code
2632: @item avoid
2633: A list of characters to avoid. This is a string which is interpreted as
2634: an escape sequence (@pxref{Chat Scripts}). The protocol does not have a
2635: way to avoid printable ASCII characters (byte values from 32 to 126,
2636: inclusive); only ASCII control characters and eight-bit characters may
2637: be avoided. The default value is @samp{\021\023}; these are the
2638: characters @code{XON} and @code{XOFF} which many connections use for
2639: flow control. If the package is configured to use @code{HAVE_BSD_TTY},
2640: then on some versions of Unix you may have to avoid @samp{\377} as well,
2641: due to the way some implementations of the BSD terminal driver handle
2642: signals.
2643: @end table
2644:
2645: The @samp{f} protocol is intended for use with error-correcting modems
2646: only; it checksums each file as a whole, so any error causes the entire
2647: file to be retransmitted. It supports the following commands, both of
2648: which take numeric arguments:
2649:
2650: @table @code
2651: @item timeout
2652: The timeout in seconds before giving up. The default is 120.
2653: @item retries
2654: How many times to retry sending a file. The default is 2.
2655: @end table
2656:
2657: The @samp{t} and @samp{e} protocols are intended for use over TCP or
2658: some other communication path with end to end reliability, as they do no
2659: checking of the data at all. They both support a single command, which
2660: takes a numeric argument:
2661:
2662: @table @code
2663: @item timeout
2664: The timeout in seconds before giving up. The default is 120.
2665: @end table
2666:
2667: The protocol parameters are reset to their default values after each
2668: call.
2669:
2670: @end table
2671:
2672: @node File Transfer Control, Miscellaneous (sys), Protocol Selection, sys File
2673: @subsection File Transfer Control
2674:
2675: @table @code
2676:
2677: @item send-request @var{boolean}
2678: @findex send-request
2679:
2680: The @var{boolean} determines whether the remote system is permitted to
2681: request files from the local system. The default is yes.
2682:
2683: @item receive-request @var{boolean}
2684: @findex receive-request
2685:
2686: The @var{boolean} determines whether the remote system is permitted to
2687: send files to the local system. The default is yes.
2688:
2689: @item request @var{boolean}
2690: @findex request
2691:
2692: A shorthand command, equivalent to specifying both @samp{send-request
2693: @var{boolean}} and @samp{receive-request @var{boolean}}.
2694:
2695: @item call-transfer @var{boolean}
2696: @findex call-transfer
2697:
2698: The @var{boolean} is checked when the local system places the call. It
2699: determines whether the local system may do file transfers queued up for
2700: the remote system. The default is yes.
2701:
2702: @item called-transfer @var{boolean}
2703: @findex called-transfer
2704:
2705: The @var{boolean} is checked when the remote system calls in. It
2706: determines whether the local system may do file transfers queued up for
2707: the remote system. The default is yes.
2708:
2709: @item transfer @var{boolean}
2710: @findex transfer
2711:
2712: Equivalent to specifying both @samp{call-transfer @var{boolean}}
2713: @samp{called-transfer @var{boolean}}.
2714:
2715: @item call-local-size @var{number} @var{string}
2716: @findex call-local-size
2717:
2718: The @var{string} is a time string (@pxref{Time Strings}). The
2719: @var{number} is the size in bytes of the largest file that should be
2720: transferred at a time matching the time string if the local system
2721: placed the call and the request was made by the local system. This
2722: command may appear multiple times in a single alternate. If this
2723: command does not appear, or if none of the time strings match, there are
2724: no size restrictions.
2725:
2726: With all the size control commands, the size of a file from the remote
2727: system (as opposed to a file from the local system) will only be checked
2728: if the other system is running this package; other UUCP packages will
2729: not understand a maximum size request, nor will they inform this package
2730: of the size of remote files.
2731:
2732: @item call-remote-size @var{number} @var{string}
2733: @findex call-remote-size
2734:
2735: Specify the size in bytes of the largest file that should be
2736: transferred at a given time by remote request when the local system
2737: placed the call. This command may appear multiple times in a single
2738: alternate. If this command does not appear, there are no size
2739: restrictions.
2740:
2741: @item called-local-size @var{number} @var{string}
2742: @findex called-local-size
2743:
2744: Specify the size in bytes of the largest file that should be transferred
2745: at a given time by local request when the remote system placed the call.
2746: This command may appear multiple times in a single alternate. If this
2747: command does not appear, there are no size restrictions.
2748:
2749: @item called-remote-size @var{number} @var{string}
2750: @findex called-remote-size
2751:
2752: Specify the size in bytes of the largest file that should be transferred
2753: at a given time by remote request when the remote system placed the
2754: call. This command may appear multiple times in a single alternate. If
2755: this command does not appear, there are no size restrictions.
2756:
2757: @item local-send @var{strings}
2758: @findex local-send
2759:
2760: Specifies that files in the directories named by the @var{strings} may
2761: be sent to the remote system when requested locally (using @code{uucp}
2762: or @code{uux}). The directories in the list should be separated by
2763: whitespace. A @kbd{~} may be used for the public directory. On a Unix
2764: system, this is typically @file{/usr/spool/uucppublic}; the public
2765: directory may be set with the @code{pubdir} command. Here is an example
2766: of @code{local-send}:
2767:
2768: @example
2769: local-send ~ /usr/spool/ftp/pub
2770: @end example
2771:
2772: Listing a directory allows all files within the directory and all
2773: subdirectories to be sent. Directories may be excluded by preceding
2774: them with an exclamation point. For example:
2775:
2776: @example
2777: local-send /usr/ftp !/usr/ftp/private ~
2778: @end example
2779:
2780: @noindent
2781: means that all files in @file{/usr/ftp} or the public directory may be
2782: sent, except those files in @file{/usr/ftp/private}. The list of
2783: directories is read from left to right, and the last directory to apply
2784: takes effect; this means that directories should be listed from top
2785: down. The default is the root directory (i.e., any file at all may be
2786: sent by local request).
2787:
2788: @item remote-send @var{strings}
2789: @findex remote-send
2790:
2791: Specifies that files in the named directories may be sent to the remote
2792: system when requested by the remote system. The default is @kbd{~}.
2793:
2794: @item local-receive @var{strings}
2795: @findex local-receive
2796:
2797: Specifies that files may be received into the named directories when
2798: requested by a local user. The default is @kbd{~}.
2799:
2800: @item remote-receive @var{strings}
2801: @findex remote-receive
2802:
2803: Specifies that files may be received into the named directories when
2804: requested by the remote system. The default is @kbd{~}. On Unix, the
2805: remote system may only request that files be received into directories
2806: that are writeable by the world, regardless of how this is set.
2807:
2808: @item forward-to @var{strings}
2809: @findex forward-to
2810:
2811: Specifies a list of systems to which files may be forwarded. The remote
2812: system may forward files through the local system on to any of the
2813: systems in this list. The string @samp{ANY} may be used to permit
2814: forwarding to any system. The default is to not permit forwarding to
2815: other systems. Note that if the remote system is permitted to execute
2816: the @code{uucp} command, it effectively has the ability to forward to
2817: any system.
2818:
2819: @item forward-from @var{strings}
2820: @findex forward-from
2821:
2822: Specifies a list of systems from which files may be forwarded. The
2823: remote system may request files via the local system from any of the
2824: systems in this list. The string @samp{ANY} may be used to permit
2825: forwarding to any system. The default is to not permit forwarding from
2826: other systems. Note that if a remote system is permitted to execute the
2827: @code{uucp} command, it effectively has the ability to request files
2828: from any system.
2829:
2830: @item forward @var{strings}
2831: @findex forward
2832:
2833: Equivalent to specifying both @samp{forward-to @var{strings}} and
2834: @samp{forward-from @var{strings}}. This would normally be used rather
2835: than either of the more specific commands.
2836:
2837: @end table
2838:
2839: @node Miscellaneous (sys), Default sys File Values, File Transfer Control, sys File
2840: @subsection Miscellaneous sys File Commands
2841:
2842: @table @code
2843:
2844: @item sequence @var{boolean}
2845: @findex sequence
2846:
2847: If @var{boolean} is true, then conversation sequencing is automatically
2848: used for the remote system, so that if somebody manages to spoof as the
2849: remote system, it will be detected the next time the remote system
2850: actually calls. This is false by default.
2851:
2852: @item command-path @var{string}
2853: @findex command-path
2854:
2855: Specifies the path (a list of whitespace separated directories) to be
2856: searched to locate commands to execute. This is only used for commands
2857: requested by @code{uux}, not for chat programs. The default is from
2858: @file{policy.h}.
2859:
2860: @item commands @var{strings}
2861: @findex commands
2862:
2863: The list of commands which the remote system is permitted to execute
2864: locally. For example: @samp{commands rnews rmail}. If the value is
2865: @samp{ALL} (case significant), all commands may be executed. The
2866: default is @samp{rnews rmail}.
2867:
2868: @item free-space @var{number}
2869: @findex free-space
2870:
2871: Specify the minimum amount of file system space (in bytes) to leave free
2872: after receiving a file. If the incoming file will not fit, it will be
2873: rejected. This initial rejection will only work when talking to another
2874: instance of this package, since older UUCP packages do not provide the
2875: file size of incoming files. Also, while a file is being received,
2876: @code{uucico} will periodically check the amount of free space. If it
2877: drops below the amount given by the @code{free-space} command, the file
2878: transfer will be aborted. The default amount of space to leave free is
2879: from @file{policy.h}. This file space checking may not work on all
2880: systems.
2881:
2882: @item pubdir @var{string}
2883: @findex pubdir in sys file
2884:
2885: Specifies the public directory that is used when @kbd{~} is specifed in
2886: a file transfer or a list of directories. This essentially overrides
2887: the public directory specified in the main configuration file for this
2888: system only. The default is the public directory specified in the main
2889: configuration file (which defaults to a value from @file{policy.h}).
2890:
2891: @item debug @var{string} @dots{}
2892: @findex debug in sys file
2893:
2894: Set additional debugging for calls to or from the system. This may be
2895: used to debug a connection with a specific system. It is particularly
2896: useful when debugging incoming calls, since debugging information will
2897: be generated whenever the call comes in. See the @code{debug} command
2898: in the main configuration file (@pxref{Debugging Levels}) for more
2899: details. The debugging information specified here is in addition to
2900: that specified in the main configuration file or on the command line.
2901:
2902: @item max-remote-debug @var{string} @dots{}
2903: @findex max-remote-debug
2904:
2905: When the system calls in, it may request that the debugging level be set
2906: to a certain value. This command may be used to put a limit on the
2907: debugging level which the system may request, to avoid filling up the
2908: disk with debugging information. Only the debugging types named in the
2909: @code{max-remote-debug} command may be turned on by the remote system.
2910: To prohibit any debugging, use @samp{max-remote-debug none}. The
2911: default is @samp{abnormal,chat,handshake}; to turn off these default
2912: entries, you must use @samp{max-remote-debug none} followed by other
2913: @code{max-remote-debug} commands specifying the settings you want.
2914:
2915: @end table
2916:
2917: @node Default sys File Values, , Miscellaneous (sys), sys File
2918: @subsection Default sys File Values
2919:
2920: The following are used as default values for all systems; they can be
2921: considered as appearing before the start of the file.
2922:
2923: @example
2924: time Never
2925: chat "" \r\c ogin:-BREAK-ogin:-BREAK-ogin: \L word: \P
2926: chat-timeout 10
2927: callback n
2928: sequence n
2929: request y
2930: transfer y
2931: local-send /
2932: remote-send ~
2933: local-receive ~
2934: remove-receive ~
2935: command-path [ from @file{policy.h} ]
2936: commands rnews rmail
2937: max-remote-debug abnormal,chat,handshake
2938: @end example
2939:
2940: @node port File, dial File, sys File, Configuration Files
2941: @section The Port Configuration File
2942: @cindex port file
2943: @cindex port configuration file
2944: @cindex configuration file (port)
2945:
2946: The port files may be used to name and describe ports. Any commands in
2947: the file before the first @code{port} command specify defaults for all
2948: ports in the file. All commands after a @code{port} command up to the
2949: next @code{port} command then describe that port. There are different
2950: types of ports; each type supports its own set of commands. Each
2951: command indicates which types of ports support it. There may be many
2952: ports with the same name; if a system requests a port by name then each
2953: port with that name will be tried until an unlocked one is found.
2954:
2955: @table @code
2956:
2957: @item port @var{string}
2958: @findex port in port file
2959:
2960: Introduces and names a port.
2961:
2962: @item type @var{string}
2963: @findex type
2964:
2965: Define the type of port. The default is @samp{modem}. If this command
2966: appears, it must immediately follow the @code{port} command. The type defines
2967: what commands are subsequently allowed. Currently the types are:
2968:
2969: @table @samp
2970: @item modem
2971: For a modem hookup.
2972: @item stdin
2973: For a connection through standard input and standard output, as when
2974: @code{uucico} is run as a login shell.
2975: @item direct
2976: For a direct connection to another system.
2977: @item tcp
2978: For a connection using TCP.
2979: @item tli
2980: For a connection using TLI.
2981: @end table
2982:
2983: @item protocol @var{string}
2984: @findex protocol in port file
2985:
2986: Specify a list of protocols to use for this port. This is just like the
2987: corresponding command for a system (@pxref{Protocol Selection}). A
2988: protocol list for a system takes precedence over a list for a port.
2989:
2990: @item protocol-parameter @var{character} @var{strings} [ any type ]
2991: @findex protocol-parameter in port file
2992:
2993: The same command as the @code{protocol-parameter} command used for
2994: systems (@pxref{Protocol Selection}). This one takes precedence.
2995:
2996: @item seven-bit @var{boolean} [ any type ]
2997: @findex seven-bit in port file
2998:
2999: This is only used during protocol negotiation; if the argument is true,
3000: it forces the selection of a protocol which works across a seven-bit
3001: link. It does not prevent eight bit characters from being transmitted.
3002: The default is false.
3003:
3004: @item reliable @var{boolean} [ any type ]
3005: @findex reliable in port file
3006:
3007: This is only used during protocol negotiation; if the argument is
3008: false, it forces the selection of a protocol which works across
3009: an unreliable communication link. The default is true. It would
3010: be more common to specify this for a dialer rather than a port.
3011:
3012: @item half-duplex @var{boolean} [ any type ]
3013: @findex half-duplex in port file
3014:
3015: If the argument is true, it means that the port only supports
3016: half-duplex connections. This only affects bidirectional protocols, and
3017: causes them to not do bidirectional transfers.
3018:
3019: @item device @var{string} [ modem, direct and tli only ]
3020: @findex device
3021:
3022: Names the device associated with this port. If the device is not named,
3023: the port name is taken as the device. Device names are system
3024: dependent. On Unix, a modem or direct connection might be something
3025: like @file{/dev/ttyd0}; a TLI port might be @file{/dev/inet/tcp}.
3026:
3027: @item baud @var{number} [ modem and direct only ]
3028: @findex baud in port file
3029: @itemx speed @var{number} [modem and direct only ]
3030: @findex speed in port file
3031:
3032: The speed this port runs at. If a system specifies a speed but no port
3033: name, then all ports which match the speed will be tried in order. If
3034: the speed is not specified here and is not specified by the system, the
3035: natural speed of the port will be used by default.
3036:
3037: @item baud-range @var{number} @var{number} [ modem only ]
3038: @findex baud-range
3039: @itemx speed-range @var{number} @var{number} [ modem only ]
3040: @findex speed-range
3041:
3042: Specify a range of speeds this port can run at. The first number is the
3043: minimum speed, the second number is the maximum speed. These numbers
3044: will be used when matching a system which specifies a desired speed.
3045: The simple @code{speed} (or @code{baud}) command is still used to
3046: determine the speed to run at if the system does not specify a speed.
3047: For example, the command @samp{speed-range 300 19200} means that the
3048: port will match any system which uses a speed from 300 to 19200 baud
3049: (and will use the speed specified by the system); this could be combined
3050: with @samp{speed 2400}, which means that when this port is used with a
3051: system that does not specify a speed, the port will be used at 2400
3052: baud.
3053:
3054: @item carrier @var{boolean} [ modem only ]
3055: @findex carrier in port file
3056:
3057: The argument indicates whether the port supports carrier. If it does
3058: not, carrier will never be required on this port, regardless of what the
3059: modem chat script indicates. The default is true.
3060:
3061: @item dial-device @var{string} [ modem only ]
3062: @findex dial-device
3063:
3064: Dialing instructions should be output to the named device, rather than
3065: to the normal port device. The default is to output to the normal port
3066: device.
3067:
3068: @item dialer @var{string} [ modem only ]
3069: @findex dialer in port file
3070:
3071: Name a dialer to use. The information is looked up in the dialer file.
3072: There is no default. Some sort of dialer information must be specified
3073: to call out on a modem.
3074:
3075: @item dialer @var{string} @dots{} [ modem only ]
3076:
3077: Execute a dialer command. If a dialer is named (by using the first form
3078: of this command, described just above), these commands are ignored.
3079: They may be used to specify dialer information directly in simple
3080: situations without needing to go to a separate file. There is no
3081: default. Some sort of dialer information must be specified to call out
3082: on a modem.
3083:
3084: @item dialer-sequence @var{strings} [ modem or tli only ]
3085: @findex dialer-sequence
3086:
3087: Name a sequence of dialers and tokens (phone numbers) to use. The first
3088: argument names a dialer, and the second argument names a token. The
3089: third argument names another dialer, and so on. If there are an odd
3090: number of arguments, the phone number specified with a @code{phone}
3091: command in the system file is used as the final token. The token is
3092: what is used for @kbd{\D} or @kbd{\T} in the dialer chat script. If the
3093: token in this string is @kbd{\D}, the system phone number will be used;
3094: if it is @kbd{\T}, the system phone number will be used after undergoing
3095: dialcodes translation. A missing final token is taken as @kbd{\D}.
3096:
3097: This command currently does not work if @code{dial-device} is specified;
3098: to handle this correctly will require a more systematic notion of chat
3099: scripts. Moreover, only the @code{complete} and @code{abort} chat
3100: scripts from the first dialer specified are used, and only the protocol
3101: parameters from the first dialer are used.
3102:
3103: This command basically lets you specify a sequence of chat scripts to
3104: use. For example, the first dialer might get you to a local network and
3105: the second dialer might describe how to select a machine from the local
3106: network. This lets you break your dialing sequence into simple modules,
3107: and may make it easier to share dialer entries between machines.
3108:
3109: When this command is used with a TLI port, then if the first dialer is
3110: @samp{TLI} or @samp{TLIS} the first token is used as the address to
3111: connect to. If the first dialer is something else, or if there is no
3112: token, the address given by the @code{address} command is used
3113: (@pxref{Placing the Call}). Escape sequences in the address are
3114: expanded as they are for chat script expect strings (@pxref{Chat
3115: Scripts}). The different between @samp{TLI} and @samp{TLIS} is that the
3116: latter implies the command @samp{stream true}. These contortions are
3117: all for HDB compatibility. Any subsequent dialers are treated as they
3118: are for a modem.
3119:
3120: @item lockname @var{string} [ modem and direct only ]
3121: @findex lockname
3122:
3123: Give the name to use when locking this port. On Unix, this is the name
3124: of the file that will be created in the lock directory. It is used as
3125: is, so on Unix it should generally start with @samp{LCK..}. For
3126: example, if a single port were named both @file{/dev/ttycu0} and
3127: @file{/dev/tty0} (perhaps with different characteristics keyed on the
3128: minor device number), then the command @code{lockname LCK..ttycu0} could
3129: be used to force the latter to use the same lock file name as the
3130: former.
3131:
3132: @item service @var{string} [ tcp only ]
3133: @findex service
3134:
3135: Name the TCP port number to use. This may be a number. If not, it will
3136: be looked up in @file{/etc/services}. If this is not specified, the
3137: string @samp{uucp} is looked up in @file{/etc/services}. If it is not
3138: found, port number 540 (the standard UUCP-over-TCP port number) will be
3139: used.
3140:
3141: @item push @var{strings} [ tli only ]
3142: @findex push
3143:
3144: Give a list of modules to push on to the TLI stream.
3145:
3146: @item stream @var{boolean} [ tli only ]
3147: @findex stream
3148:
3149: If this is true, and the @code{push} command was not used, the
3150: @samp{tirdwr} module is pushed on to the TLI stream.
3151:
3152: @item server-address @var{string} [ tli only ]
3153:
3154: Give the address to use when running as a TLI server. Escape sequences
3155: in the address are expanded as they are for chat script expect strings
3156: (@pxref{Chat Scripts}).
3157:
3158: @end table
3159:
3160: @node dial File, Security, port File, Configuration Files
3161: @section The Dialer Configuration File
3162: @cindex dial file
3163: @cindex dialer configuration file
3164: @cindex configuration file (dial)
3165:
3166: The dialer configuration files define dialers. Any commands in the file
3167: before the first @code{dialer} command specify defaults for all the
3168: dialers in the file. All commands after a @code{dialer} command up to
3169: the next @code{dialer} command are associated with the named dialer.
3170:
3171: @table @code
3172:
3173: @item dialer @var{string}
3174: @findex dialer in dial file
3175:
3176: Introduces and names a dialer.
3177:
3178: @item chat @var{strings}
3179: @findex chat in dial file
3180: @item chat-timeout @var{number}
3181: @findex chat-timeout in dial file
3182: @item chat-fail @var{string}
3183: @findex chat-fail in dial file
3184: @item chat-seven-bit @var{boolean}
3185: @findex chat-seven-bit in dial file
3186: @item chat-program @var{strings}
3187: @findex chat-program in dial file
3188:
3189: Specify a chat script to be used to dial the phone. See @ref{Chat
3190: Scripts} for full details on chat scripts.
3191:
3192: Taylor UUCP will sleep for one second between attempts to dial out on a
3193: modem. If your modem requires a longer wait period, you must start your
3194: chat script with delays (@samp{\d} in a send string).
3195:
3196: The chat script will be read from and sent to the port specified by the
3197: @code{dial-device} command for the port, if there is one.
3198:
3199: The following escape addition escape sequences may appear in send
3200: strings:
3201:
3202: @table @kbd
3203: @item \D
3204: send phone number without dialcode translation
3205: @item \T
3206: send phone number with dialcode translation
3207: @item \M
3208: do not require carrier
3209: @item \m
3210: require carrier (fail if not present)
3211: @end table
3212:
3213: See the description of the dialcodes file (@pxref{Configuration File
3214: Names}) for a description of dialcode translation. If the port does not
3215: support carrier (as set by the @code{carrier} command in the port file)
3216: @kbd{\M} and @kbd{\m} are ignored. If both the port and the dialer
3217: support carrier (as set by the @code{carrier} command in the port file
3218: and the @code{carrier} command in the dialer file), then every chat
3219: script implicitly begins with @kbd{\M} and ends with @kbd{\m}. There is
3220: no default chat script for dialers.
3221:
3222: The following additional escape sequences may be used in
3223: @code{chat-program}:
3224:
3225: @table @kbd
3226: @item \D
3227: phone number without dialcode translation
3228: @item \T
3229: phone number with dialcode translation
3230: @end table
3231:
3232: If the program changes the port in any way (e.g., sets parity) the
3233: changes will be preserved during protocol negotiation, but once the
3234: protocol is selected it will change the port settings.
3235:
3236: @item dialtone @var{string}
3237: @findex dialtone
3238:
3239: A string to output when dialing the phone number which causes the modem
3240: to wait for a secondary dial tone. This is used to translate the
3241: @kbd{=} character in a phone number. The default is a comma.
3242:
3243: @item pause @var{string}
3244: @findex pause
3245:
3246: A string to output when dialing the phone number which causes the modem
3247: to wait for 1 second. This is used to translate the @kbd{-} character
3248: in a phone number. The default is a comma.
3249:
3250: @item carrier @var{boolean}
3251: @findex carrier in dial file
3252:
3253: If the argument is true, the dialer supports the modem carrier signal.
3254: After the phone number is dialed, @code{uucico} will require that
3255: carrier be on. One some systems, it will be able to wait for it. If
3256: the argument is false, carrier will not be required. The default is
3257: true.
3258:
3259: @item carrier-wait @var{number}
3260: @findex carrier-wait
3261:
3262: If the port is supposed to wait for carrier, this may be used to
3263: indicate how many seconds to wait. The default is 60 seconds. Only
3264: some systems support waiting for carrier.
3265:
3266: @item dtr-toggle @var{boolean} @var{boolean}
3267: @findex dtr-toggle
3268:
3269: If the first argument is true, then DTR is toggled before using
3270: the modem. This is only supported on some systems and some ports. The
3271: second @var{boolean} need not be present; if it is, and it is
3272: true, the program will sleep for 1 second after toggling DTR.
3273: The default is not to toggle DTR.
3274:
3275: @item complete-chat @var{strings}
3276: @findex complete-chat
3277: @item complete-chat-timeout @var{number}
3278: @findex complete-chat-timeout
3279: @item complete-chat-fail @var{string}
3280: @findex complete-chat-fail
3281: @item complete-chat-seven-bit @var{boolean}
3282: @findex complete-chat-seven-bit
3283: @item complete-chat-program @var{strings}
3284: @findex complete-chat-program
3285:
3286: These commands define a chat script (@pxref{Chat Scripts}) which is run
3287: when a call is finished normally. This allows the modem to be reset.
3288: There is no default. No additional escape sequences may be used.
3289:
3290: @item complete @var{string}
3291: @findex complete
3292:
3293: This is a simple use of @code{complete-chat}. It is equivalent to
3294: @code{complete-chat "" @var{string}}; this has the effect of sending
3295: @var{string} to the modem when a call finishes normally.
3296:
3297: @item abort-chat @var{strings}
3298: @findex abort-chat
3299: @item abort-chat-timeout @var{number}
3300: @findex abort-chat-timeout
3301: @item abort-chat-fail @var{string}
3302: @findex abort-chat-fail
3303: @item abort-chat-seven-bit @var{boolean}
3304: @findex abort-chat-seven-bit
3305: @item abort-chat-program @var{strings}
3306: @findex abort-chat-program
3307:
3308: These commands define a chat script (@pxref{Chat Scripts}) to be run
3309: when a call is aborted. They may be used to interrupt and reset the
3310: modem. There is no default. No additional escape sequences may be
3311: used.
3312:
3313: @item abort @var{string}
3314: @findex abort
3315:
3316: This is a simple use of @code{abort-chat}. It is equivalent to
3317: @code{abort-chat "" @var{string}}; this has the effect of sending
3318: @var{string} to the modem when a call is aborted.
3319:
3320: @item protocol-parameter @var{character} @var{strings}
3321: @findex protocol-parameter in dial file
3322:
3323: Set protocol parameters, just like the @code{protocol-parameter} command
3324: in the system configuration file or the port configuration file; see
3325: @ref{Protocol Selection}. These parameters take precedence, then those
3326: for the port, then those for the system.
3327:
3328: @item seven-bit @var{boolean}
3329: @findex seven-bit in dial file
3330:
3331: This is only used during protocol negotiation; if it is true, it
3332: forces selection of a protocol which works across a seven-bit link. It
3333: does not prevent eight bit characters from being transmitted. The
3334: default is false. It would be more common to specify this for a
3335: port than for a dialer.
3336:
3337: @item reliable @var{boolean}
3338: @findex reliable in dial file
3339:
3340: This is only used during protocol negotiation; if it is false, it
3341: forces selection of a protocol which works across an unreliable
3342: communication link. The default is true.
3343:
3344: @item half-duplex @var{boolean} [ any type ]
3345: @findex half-duplex in dial file
3346:
3347: If the argument is true, it means that the dialer only supports
3348: half-duplex connections. This only affects bidirectional protocols, and
3349: causes them to not do bidirectional transfers.
3350:
3351: @end table
3352:
3353: @node Security, , dial File, Configuration Files
3354: @section Security
3355:
3356: This discussion of UUCP security applies only to Unix. It is a bit
3357: cursory; suggestions for improvement are solicited.
3358:
3359: UUCP is traditionally not very secure. Taylor UUCP addresses some
3360: security issues, but is still far from being a secure system.
3361:
3362: If security is very important to you, then you should not permit any
3363: external access to your computer, including UUCP. Any opening to the
3364: outside world is a potential security risk.
3365:
3366: By default Taylor UUCP provides few mechanisms to secure local users of
3367: the system from each other. You can allow increased security by putting
3368: the owner of the UUCP programs (normally @code{uucp}) into a separate
3369: group; the use of this is explained in the following paragraphs, which
3370: refer to this separate group as @code{uucp-group}.
3371:
3372: When the @code{uucp} program is invoked to copy a file to a remote
3373: system, it will by default copy the file into the UUCP spool directory.
3374: When the @code{uux} program is used, the @samp{-C} switch must be used
3375: to copy the file into the UUCP spool directory. In any case, once the
3376: file has been copied into the spool directory, other local users will
3377: not be able to access it.
3378:
3379: When a file is requested from a remote system, UUCP will only permit it
3380: to be placed in a directory which is writable by the requesting user.
3381: The directory must also be writable by UUCP. A local user can create a
3382: directory with a group of @code{uucp-group} and set the mode to permit
3383: group write access. This will allow the file be requested without
3384: permitting it to be viewed by any other user.
3385:
3386: There is no provision for security for @code{uucp} requests (as opposed
3387: to @code{uux} requests) made by a user on a remote system. A file sent
3388: over by a remote request may only be placed in a directory which is
3389: world writable, and the file will be world readable and writable. This
3390: will permit any local user to destroy or replace the contents of the
3391: file. A file requested by a remote system must be world readable, and
3392: the directory it is in must be world readable. Any local user will be
3393: able to examine, although not necessarily modify, the file before it is
3394: sent.
3395:
3396: There are some security holes and race conditions that apply to the
3397: above discussion which I will not elaborate on. They are not hidden
3398: from anybody who reads the source code, but they are somewhat technical
3399: and difficult (though scarcely impossible) to exploit. Suffice it to
3400: say that even under the best of conditions UUCP is not completely
3401: secure.
3402:
3403: For many sites, security from remote sites is a more important
3404: consideration. Fortunately, Taylor UUCP does provide some support in
3405: this area.
3406:
3407: The greatest security is provided by always dialing out to the other
3408: site. This prevents anybody from pretending to be the other site. Of
3409: course, only one side of the connection can do this.
3410:
3411: If remote dialins must be permitted, then it is best if the dialin line
3412: is used only for UUCP. If this is the case, then you should create a
3413: call-in password file (@pxref{Configuration File Names}) and let
3414: @code{uucico} do its own login prompting. For example, to let remote
3415: sites log in on a port named @samp{entry} in the port file (@pxref{port
3416: File}) you might invoke @samp{uucico -p entry}. This would cause
3417: @code{uucico} to enter an endless loop of login prompts and daemon
3418: executions. The advantage of this approach is that even if remote users
3419: break into the system by guessing or learning the password, they will
3420: only be able to do whatever @code{uucico} permits them to do. They will
3421: not be able to start a shell on your system.
3422:
3423: If remote users can dial in and log on to your system, then you have a
3424: security hazard more serious than that posed by UUCP. But then, you
3425: probably knew that already.
3426:
3427: Once your system has connected with the remote UUCP, there is a fair
3428: amount of control you can exercise. You can use the @code{remote-send}
3429: and @code{remote-receive} commands to control the directories the remote
3430: UUCP can access. You can use the @code{request} command to prevent the
3431: remote UUCP from making any requests of your system at all; however, if
3432: you do this it will not even be able to send you mail or news. If you
3433: do permit remote requests, you should be careful to restrict what
3434: commands may be executed at the remote system's request. The default is
3435: @code{rmail} and @code{rnews}, which will suffice for most systems.
3436:
3437: If different remote systems call in and they must be granted different
3438: privileges (perhaps some systems are within the same organization and
3439: some are not) then the @code{called-login} command should be used for
3440: each system to require that they different login names. Otherwise it
3441: would be simple for a remote system to use the @code{myname} command and
3442: pretend to be a different system. The @code{sequence} command can be
3443: used to detect when one system pretended to be another, but since the
3444: sequence numbers must be reset manually after a failed handshake this
3445: can sometimes be more trouble than it's worth.
3446:
3447: @node Protocols, Hacking, Configuration Files, Top
3448: @chapter UUCP protocol internals
3449:
3450: This chapter describes how the various UUCP protocols work, and
3451: discusses some other internal UUCP issues.
3452:
3453: This chapter is quite technical. You do not need to understand it, or
3454: even read it, in order to use Taylor UUCP. It is intended for people
3455: who are interested in how UUCP code works.
3456:
3457: This chapter is also, unfortunately, somewhat out of date, although I
3458: believe that is incomplete rather than inaccurate. I post this
3459: information to the newsgroups @samp{comp.mail.uucp} and
3460: @samp{news.answers} each month; if you want to write code based on this
3461: information, please get the most recent copy.
3462:
3463: Most of the discussion covers the protocols used by all UUCP packages,
3464: not just Taylor UUCP. Any information specific to Taylor UUCP is
3465: indicated as such. There are some pointers to the actual functions in
3466: the Taylor UUCP source code, for those who are extremely interested in
3467: actual UUCP implementation.
3468:
3469: @menu
3470: * Grades:: UUCP grades
3471: * Lock Files:: UUCP lock file format
3472: * UUCP Protocol:: The common UUCP protocol
3473: * g Protocol:: The UUCP @samp{g} protocol
3474: * f Protocol:: The UUCP @samp{f} protocol
3475: * t Protocol:: The UUCP @samp{t} protocol
3476: * e Protocol:: The UUCP @samp{e} protocol
3477: * x Protocol:: The UUCP @samp{x} protocol
3478: * d Protocol:: The UUCP @samp{d} protocol
3479: * Capital G Protocol:: The UUCP @samp{G} protocol
3480: * Documentation References:: Documentation references
3481: @end menu
3482:
3483: @node Grades, Lock Files, Protocols, Protocols
3484: @section UUCP Grades
3485: @cindex grades
3486:
3487: Modern UUCP packages support grades for each command. The grades
3488: generally range from @samp{A} (the highest) to @samp{Z} followed by
3489: @samp{a} to @samp{z}. Taylor UUCP also supports @samp{0} to @samp{9}
3490: before @samp{A}. Some UUCP packages may permit any ASCII character as a
3491: grade.
3492:
3493: On Unix, these grades are encoded in the name of the command file. A
3494: command file name generally has the form
3495:
3496: @example
3497: C.nnnngssss
3498: @end example
3499:
3500: @noindent
3501: where @var{nnnn} is the remote system name for which the command is
3502: queued, @var{g} is a single character grade, and @var{ssss} is a four
3503: character sequence number. For example, a command file created for the
3504: system @file{airs} at grade @samp{Z} might be named
3505:
3506: @example
3507: C.airsZ2551
3508: @end example
3509:
3510: The remote system name will be truncated to seven characters, to ensure
3511: that the command file name will fit in the 14 character file name limit
3512: of the traditional Unix file system. UUCP packages which have no other
3513: means of distinguishing which command files are intended for which
3514: systems thus require all @emph{systems they connect to} to have names
3515: that are unique in the first seven characters. Some UUCP packages use a
3516: variant of this format which truncates the system name to six
3517: characters. HDB uses a different spool directory format, which allows
3518: up to fourteen characters to be used for each system name. The Taylor
3519: UUCP spool directory format is configurable. The new Taylor spool
3520: directory format permits system names to be as long as file names; the
3521: maximum length of a file name depends on the particular Unix file system
3522: being used.
3523:
3524: The sequence number in the command file name may be a decimal integer,
3525: or it may be a hexadecimal integer, or it may contain any alphanumeric
3526: character. Different UUCP packages are different.
3527:
3528: Taylor UUCP creates command files in the function
3529: @code{zsysdep_spool_commands}. The file name is constructed by the
3530: function @code{zsfile_name}, which knows about all the different types
3531: of spool directories supported by Taylor UUCP. The Taylor UUCP sequence
3532: number can contain any alphanumeric character; the next sequence number
3533: is determined by the function @code{fscmd_seq}.
3534:
3535: I do not know how command grades are handled in non-Unix UUCP
3536: packages.
3537:
3538: Modern UUCP packages allow you to restrict file transfer by grade
3539: depending on the time of day. Typically this is done with a line in
3540: the @file{Systems} (or @file{L.sys}) file like this:
3541:
3542: @example
3543: airs Any/Z,Any2305-0855 ...
3544: @end example
3545:
3546: This allows only grades @samp{Z} and above to be transferred at any
3547: time. Lower grades may only be transferred at night. I believe that
3548: this grade restriction applies to local commands as well as to remote
3549: commands, but I am not sure. It may only apply if the UUCP package
3550: places the call, not if it is called by the remote system. Taylor UUCP
3551: can use the @code{timegrade} and @code{call-timegrade} commands
3552: (@pxref{When to Call}) to achieve the same effect (and supports the
3553: above format when reading @file{Systems} or @file{L.sys}).
3554:
3555: This sort of grade restriction is most useful if you know what grades
3556: are being used at the remote site. The default grades used depend on
3557: the UUCP package. Generally @code{uucp} and @code{uux} have different
3558: defaults. A particular grade can be specified with the @samp{-g} option
3559: to @code{uucp} or @code{uux}. For example, to request execution of
3560: rnews on airs with grade @samp{d}, you might use something like
3561:
3562: @example
3563: uux -gd - airs!rnews <article
3564: @end example
3565:
3566: @samp{uunet} queues up mail at grade @samp{Z} and news at grade
3567: @samp{d}. The example above would allow mail to be received at any
3568: time, but would only permit news to be transferred at night.
3569:
3570: @node Lock Files, UUCP Protocol, Grades, Protocols
3571: @section UUCP Lock File Format
3572: @cindex lock files
3573:
3574: This discussion applies only to Unix. I have no idea how UUCP locks
3575: ports on other systems.
3576:
3577: UUCP creates files to lock serial ports and systems. On most (if not
3578: all) systems, these same lock files are also used by cu to coordinate
3579: access to serial ports. On some systems getty also uses these lock
3580: files.
3581:
3582: The lock file normally contains the process ID of the locking process.
3583: This makes it easy to determine whether a lock is still valid. The
3584: algorithm is to create a temporary file and then link it to the name
3585: that must be locked. If the link fails because a file with that name
3586: already exists, the existing file is read to get the process ID. If the
3587: process still exists, the lock attempt fails. Otherwise the lock file
3588: is deleted and the locking algorithm is retried.
3589:
3590: Older UUCP packages put the lock files in the main UUCP spool
3591: directory, /usr/spool/uucp. HDB UUCP generally puts the lock files in
3592: a directory of their own, usually /usr/spool/locks or /etc/locks.
3593:
3594: The original UUCP lock file format encoded the process ID as a four byte
3595: binary number. The order of the bytes was host-dependent. HDB UUCP
3596: stores the process ID as a ten byte ASCII decimal number, with a
3597: trailing newline. For example, if process 1570 holds a lock file, it
3598: would contain the eleven characters space, space, space, space, space,
3599: space, one, five, seven, zero, newline. Some versions of UUCP add a
3600: second line indicating which program created the lock (uucp, cu, or
3601: getty). I have also seen a third type of UUCP lock file which did not
3602: contain the process ID at all.
3603:
3604: The name of the lock file is generally "LCK.." followed by the base name
3605: of the device. For example, to lock /dev/ttyd0 the file LCK..ttyd0
3606: would be created. There are various exceptions. On SCO Unix, the lock
3607: file name is always forced to lower case even if the device name has
3608: upper case letters. System V Release 4 UUCP forms the lock file name
3609: using the major and minor device numbers rather than the device name
3610: (this is pretty sensible if you think about it).
3611:
3612: Taylor UUCP can be configured to use various different types of locking.
3613: The actual locking code is in the function @code{fsdo_lock}.
3614:
3615: @node UUCP Protocol, g Protocol, Lock Files, Protocols
3616: @section The Common UUCP Protocol
3617: @cindex UUCP protocol
3618: @cindex handshake
3619: @cindex protocol (UUCP)
3620:
3621: The UUCP protocol is a conversation between two UUCP packages. A UUCP
3622: conversation consists of three parts: an initial handshake, a series
3623: of file transfer requests, and a final handshake.
3624:
3625: Before the initial handshake, the caller will usually have logged in the
3626: called machine and somehow started the UUCP package there. On Unix this
3627: is normally done by setting the shell of the login name used to
3628: @file{uucico}.
3629:
3630: @menu
3631: * Initial Handshake:: Initial handshake
3632: * File Requests:: File requests
3633: * Final Handshake:: Final handshake
3634: @end menu
3635:
3636: @node Initial Handshake, File Requests, UUCP Protocol, UUCP Protocol
3637: @subsection Initial Handshake
3638:
3639: All messages in the initial handshake begin with a @samp{^P} (a byte
3640: with the octal value \020) and end with a null byte (\000).
3641:
3642: Taylor UUCP implements the initial handshake for the calling machine in
3643: @code{fdo_call}, and for the called machine in @code{faccept_call}.
3644:
3645: The initial handshake goes as follows. It is begun by the called
3646: machine.
3647:
3648: @table @asis
3649:
3650: @item called: @samp{\020Shere=@var{hostname}\000}
3651: The @var{hostname} is the UUCP name of the called machine. Older UUCP
3652: packages do not output it, and simply send @samp{\020Shere\000}.
3653:
3654: @item caller: @samp{\020S@var{hostname} @var{options}\000}
3655: The @var{hostname} is the UUCP name of the calling machine. The
3656: following @var{options} may appear (or there may be none):
3657:
3658: @table @samp
3659:
3660: @item -Q@var{seq}
3661: Report sequence number for this conversation. The sequence number is
3662: stored at both sites, and incremented after each call. If there is a
3663: sequence number mismatch, something has gone wrong (somebody may have
3664: broken security by pretending to be one of the machines) and the call is
3665: denied. If the sequence number changes on one of the machines, perhaps
3666: because of an attempted breakin or because a disk backup was restored,
3667: the sequence numbers on the two machines must be reconciled manually.
3668:
3669: @item -x@var{level}
3670: Requests the called system to set its debugging level to the specified
3671: value. This is not supported by all systems. Taylor UUCP currently
3672: never generates this switch. When it sees it, it restricts the value
3673: according to @code{max-remote-debug} (@pxref{Miscellaneous (sys)}).
3674:
3675: @item -p@var{grade}
3676: @itemx -vgrade=@var{grade}
3677: Requests the called system to only transfer files of the specified grade
3678: or higher. This is not supported by all systems. Some systems support
3679: @samp{-p}, some support @samp{-vgrade=}. Taylor UUCP supports both.
3680:
3681: @item -R
3682: Indicates that the calling UUCP understands how to restart failed file
3683: transmissions. Supported only by System V Release 4 UUCP.
3684:
3685: @item -U@var{limit}
3686: Reports the @code{ulimit} value of the calling UUCP. The limit is
3687: specified as a base 16 number in C notation (e.g., @samp{-U0x1000000}).
3688: This number is the number of 512 byte blocks in the largest file which
3689: the calling UUCP can create. The called UUCP may not transfer a file
3690: larger than this. Supported by System V Release 4 UUCP. Taylor UUCP
3691: understands this option, but never generates it.
3692:
3693: @item -N
3694: Indicates that the calling UUCP understands the Taylor UUCP size
3695: limiting extensions. Supported only by Taylor UUCP.
3696:
3697: @end table
3698:
3699: @item called: @samp{\020ROK\000}
3700: There are actually several possible responses.
3701:
3702: @table @samp
3703:
3704: @item ROK
3705: The calling UUCP is acceptable, and the handshake proceeds to the
3706: protocol negotiation. Some options may also appear; see below.
3707:
3708: @item ROKN
3709: The calling UUCP is acceptable, it specified @samp{-N}, and the called
3710: UUCP also understands the Taylor UUCP size limiting extensions.
3711: Supported only by Taylor UUCP.
3712:
3713: @item RLCK
3714: The called UUCP already has a lock for the calling UUCP, which normally
3715: indicates the two machines are already communicating.
3716:
3717: @item RCB
3718: The called UUCP will call back. This may be used to avoid impostors.
3719: Note that only one machine out of each pair should call back, or no
3720: conversation will ever begin.
3721:
3722: @item RBADSEQ
3723: The call sequence number is wrong (see the @samp{-Q} discussion above).
3724:
3725: @item RLOGIN
3726: The calling UUCP is using the wrong login name.
3727:
3728: @item RYou are unknown to me
3729: The calling UUCP is not known to the called UUCP, and the called UUCP
3730: does not permit connections from unknown systems.
3731:
3732: @end table
3733:
3734: If the response is @samp{ROK}, the following options are supported by
3735: System V Release 4 UUCP.
3736:
3737: @table @samp
3738:
3739: @item -R
3740: The called UUCP knows how to restart failed file transmissions.
3741:
3742: @item -U@var{limit}
3743: Reports the ulimit value of the called UUCP. The limit is specified as
3744: a base 16 number in C notation. This number is the number of 512 byte
3745: blocks in the largest file which the called UUCP can create. The
3746: calling UUCP may not send a file larger than this.
3747:
3748: @item -x@var{level}
3749: I'm told that this is sometimes sent by SVR4 UUCP, but I'm not sure
3750: exactly what it means. It may request the calling UUCP to set its
3751: debugging level to the specified value.
3752:
3753: @end table
3754:
3755: If the response is not @samp{ROK} (or @samp{ROKN}) both sides hang up
3756: the phone, abandoning the call.
3757:
3758: @item called: @samp{\020P@var{protocols}\000}
3759: The @kbd{P} is a literal character. Note that the called UUCP outputs
3760: two strings in a row. The @var{protocols} string is a list of UUCP
3761: protocols supported by the caller. Each UUCP protocol has a single
3762: character name. For example, the called UUCP might send
3763: @samp{\020Pgf\000}.
3764:
3765: @item caller: @samp{\020U@var{protocol}\000}
3766: The @kbd{U} is a literal character. The calling UUCP selects which
3767: @var{protocol} to use out of the protocols offered by the called UUCP.
3768: If there are no mutually supported protocols, the calling UUCP sends
3769: @samp{\020UN\000} and both sides hang up the phone. Otherwise the
3770: calling UUCP sends something like @samp{\020Ug\000}.
3771:
3772: @end table
3773:
3774: Most UUCP packages will consider each locally supported protocol in turn
3775: and select the first one supported by the called UUCP. With some
3776: versions of HDB UUCP, this can be modified by giving a list of protocols
3777: after the device name in the Devices file or the @file{Systems} file.
3778: Taylor UUCP provides the @code{protocol} command which may be used
3779: either for a system (@pxref{Protocol Selection}) or a port (@pxref{port
3780: File}).
3781:
3782: After the protocol has been selected and the initial handshake has been
3783: completed, both sides turn on the selected protocol. For some protocols
3784: (notably @samp{g}) a further handshake is done at this point.
3785:
3786: Each protocol supports a method for sending a command to the remote
3787: system. This method is used to transmit a series of commands between
3788: the two UUCP packages. At all times, one package is the master and the
3789: other is the slave. Initially, the calling UUCP is the master.
3790:
3791: If a protocol error occurs during the exchange of commands, both sides
3792: move immediately to the final handshake.
3793:
3794: @node File Requests, Final Handshake, Initial Handshake, UUCP Protocol
3795: @subsection File Requests
3796:
3797: The master will send one of four commands: @samp{S}, @samp{R}, @samp{X}
3798: or @samp{H}.
3799:
3800: Any file name referred to below is either an absolute pathname beginning
3801: with @samp{/}, a public directory pathname beginning with @samp{~/}, a
3802: pathname relative to a user's home directory beginning with
3803: @samp{~@var{user}/}, or a spool directory file name. File names in the
3804: spool directory are not pathnames, but instead are converted to
3805: pathnames within the spool directory by UUCP. They always begin with
3806: @samp{C.} (for a command file created by @code{uucp} or @code{uux}),
3807: @samp{D.} (for a data file created by @code{uucp}, @code{uux} or by an
3808: execution, or received from another system for an execution), or
3809: @samp{X.} (for an execution file created by @code{uux} or received from
3810: another system).
3811:
3812: Taylor UUCP chooses which request to send next in the function
3813: @code{fuucp}. This is also where Taylor UUCP processes incoming
3814: commands from the remote system.
3815:
3816: @menu
3817: * S Request:: S request
3818: * R Request:: R request
3819: * X Request:: X request
3820: * H Request:: H request
3821: @end menu
3822:
3823: @node S Request, R Request, File Requests, File Requests
3824: @subsubsection S Request
3825:
3826: master: @samp{S @var{from} @var{to} @var{user} -@var{options} @var{temp}
3827: @var{mode} @var{notify} @var{size}}
3828:
3829: The @samp{S} and the @samp{-} are literal characters. This is a request
3830: by the master to send a file to the slave. Taylor UUCP handles the
3831: @samp{S} request in the file @file{send.c}.
3832:
3833: @table @var
3834:
3835: @item from
3836: The name of the file to send. If the @samp{C} option does not appear in
3837: @var{options}, the master will actually open and send this file.
3838: Otherwise the file has been copied to the spool directory, where it is
3839: named @var{temp}. The slave ignores this field unless @var{to} is a
3840: directory, in which case the basename of @var{from} will be used as the
3841: file name. If @var{from} is a spool directory filename, it must be a
3842: data file created for or by an execution, and must begin with @samp{D.}.
3843:
3844: @item to
3845: The name to give the file on the slave. If this field names a directory
3846: the file is placed within that directory with the basename of
3847: @var{from}. A name ending in @samp{/} is taken to be a directory even
3848: if one does not already exist with that name. If @var{to} begins with
3849: @samp{X.}, an execution file will be created on the slave. Otherwise,
3850: if @var{to} begins with @samp{D.} it names a data file to be used by
3851: some execution file. Otherwise, @var{to} should not be in the spool
3852: directory.
3853:
3854: @item user
3855: The name of the user who requested the transfer.
3856:
3857: @item options
3858: A list of options to control the transfer. The following options are
3859: defined (all options are single characters):
3860:
3861: @table @samp
3862:
3863: @item C
3864: The file has been copied to the spool directory (the master should use
3865: @var{temp} rather than @var{from}).
3866:
3867: @item c
3868: The file has not been copied to the spool directory (this is the
3869: default).
3870:
3871: @item d
3872: The slave should create directories as necessary (this is the default).
3873:
3874: @item f
3875: The slave should not create directories if necessary, but should fail
3876: the transfer instead.
3877:
3878: @item m
3879: The master should send mail to @var{user} when the transfer is complete.
3880:
3881: @item n
3882: The slave should send mail to @var{notify} when the transfer is
3883: complete.
3884:
3885: @end table
3886:
3887: @item temp
3888: If the @samp{C} option appears in @var{options}, this names the file to
3889: be sent. Otherwise if @var{from} is in the spool directory, @var{temp}
3890: is the same as @var{from}. Otherwise @var{temp} is a dummy string,
3891: normally @samp{D.0}. After the transfer has been succesfully completed,
3892: the master will delete the file @var{temp}.
3893:
3894: @item mode
3895: This is an octal number giving the mode of the file on the master. If
3896: the file is not in the spool directory, the slave will always create it
3897: with mode 0666, except that if (@var{mode} & 0111) is not zero (the file
3898: is executable), the slave will create the file with mode 0777. If the
3899: file is in the spool directory, some UUCP packages will use the
3900: algorithm above and some will always create the file with mode 0600
3901: (Taylor UUCP does the latter).
3902:
3903: @item notify
3904: This field is only used if the @samp{n} option appears in @var{options}.
3905: Otherwise, it may not appear, or it may be the string @samp{dummy}, or
3906: it may simply be a pair of double quotes. If the @samp{n} option is
3907: specified, then when the transfer is successfully completed the slave
3908: will send mail to @var{notify}, which must be a legal mailing address on
3909: the slave.
3910:
3911: @item size
3912: This field is only present when doing size negotiation, either with
3913: Taylor UUCP or SVR4 UUCP. It is the size of the file in bytes. SVR4
3914: UUCP sends the size in base 16 as 0x@dots{} while Taylor UUCP sends the
3915: size as a decimal integer (a later version of Taylor UUCP will probably
3916: change to the SVR4 behaviour).
3917:
3918: @end table
3919:
3920: The slave then responds with an S command response.
3921:
3922: @table @samp
3923:
3924: @item SY @var{start}
3925: The slave is willing to accept the file, and file transfer begins. The
3926: @var{start} field will only be present when using SVR4 file restart. It
3927: specifies the byte offset into the file at which to start sending. If
3928: this is a new file, @var{start} will be 0x0.
3929:
3930: @item SN2
3931: The slave denies permission to transfer the file. This can mean that
3932: the destination directory may not be accessed, or that no requests are
3933: permitted. It implies that the file transfer will never succeed.
3934:
3935: @item SN4
3936: The slave is unable to create the necessary temporary file. This
3937: implies that the file transfer might succeed later.
3938:
3939: @item SN6
3940: This is only used by Taylor UUCP size negotiation. It means that the
3941: slave considers the file too large to transfer at the moment, but it may
3942: be possible to transfer it at some other time.
3943:
3944: @item SN7
3945: This is only used by Taylor UUCP size negotiation. It means that the
3946: slave considers the file too large to ever transfer.
3947:
3948: @end table
3949:
3950: If the slave responds with @samp{SY}, a file transfer begins. When the
3951: file transfer is complete, the slave sends a @samp{C} command response.
3952: Taylor UUCP generates this confirmation in @code{fprecfile_confirm} and
3953: checks it in @code{fpsendfile_confirm}.
3954:
3955: @table @samp
3956:
3957: @item CY
3958: The file transfer was successful.
3959:
3960: @item CN5
3961: The temporary file could not be moved into the final location. This
3962: implies that the file transfer will never succeed.
3963:
3964: @end table
3965:
3966: After the @samp{C} command response has been received (in the @samp{SY}
3967: case) or immediately (in an @samp{SN} case) the master will send another
3968: command.
3969:
3970: @node R Request, X Request, S Request, File Requests
3971: @subsubsection R Request
3972:
3973: master: @samp{R @var{from} @var{to} @var{user} -@var{options}
3974: @var{size}}
3975:
3976: The @samp{R} and the @samp{-} are literal characters. This is a request
3977: by the master to receive a file from the slave. I do not know how SVR4
3978: UUCP implements file transfer restart in this case. Taylor UUCP
3979: implements the @samp{R} request in the file @file{rec.c}.
3980:
3981: @table @var
3982:
3983: @item from
3984: This is the name of the file on the slave which the master wishes to
3985: receive. It must not be in the spool directory, and it may not contain
3986: any wildcards.
3987:
3988: @item to
3989: This is the name of the file to create on the master. I do not believe
3990: that it can be a directory. It may only be in the spool directory if
3991: this file is being requested to support an execution either on the
3992: master or on some system other than the slave.
3993:
3994: @item user
3995: The name of the user who requested the transfer.
3996:
3997: @item options
3998: A list of options to control the transfer. The following options are
3999: defined (all options are single characters):
4000:
4001: @table @samp
4002:
4003: @item d
4004: The master should create directories as necessary (this is the default).
4005:
4006: @item f
4007: The master should not create directories if necessary, but should fail
4008: the transfer instead.
4009:
4010: @item m
4011: The master should send mail to @var{user} when the transfer is complete.
4012:
4013: @end table
4014:
4015: @item size
4016: This only appears if Taylor UUCP size negotiation is being used. It
4017: specifies the largest file which the master is prepared to accept (when
4018: using SVR4 UUCP, this was specified in the @samp{-U} option during the
4019: initial handshake).
4020:
4021: @end table
4022:
4023: The slave then responds with an @samp{R} command response.
4024:
4025: @table @samp
4026:
4027: @item RY @var{mode}
4028: The slave is willing to send the file, and file transfer begins.
4029: @var{mode} is the octal mode of the file on the slave. The master uses
4030: this to set the mode of the file on the master's system just as the
4031: slave does the @var{mode} argument in the send command (@pxref{S
4032: Request}).
4033:
4034: @item RN2
4035: The slave is not willing to send the file, either because it is not
4036: permitted or because the file does not exist. This implies that the
4037: file request will never succeed.
4038:
4039: @item RN6
4040: This is only used by Taylor UUCP size negotiation. It means that the
4041: file is too large to send, either because of the size limit specifies by
4042: the master or because the slave considers it too large. The file
4043: transfer might succeed later, or it might not (this will be cleared up
4044: in a later release of Taylor UUCP).
4045:
4046: @end table
4047:
4048: If the slave responds with @samp{RY}, a file transfer begins. When the
4049: file transfer is complete, the master sends a @samp{C} command. The
4050: slave pretty much ignores this, although it may log it. Taylor UUCP
4051: sends this confirmation in @code{fprecfile_confirm} and checks it in
4052: @code{fpsendfile_confirm}.
4053:
4054: @table @samp
4055:
4056: @item CY
4057: The file transfer was successful.
4058:
4059: @item CN5
4060: The temporary file could not be moved into the final
4061: location.
4062:
4063: @end table
4064:
4065: After the @samp{C} command response has been sent (in the @samp{RY}
4066: case) or immediately (in an @samp{RN} case) the master will send another
4067: command.
4068:
4069: @node X Request, H Request, R Request, File Requests
4070: @subsubsection X Request
4071:
4072: master: @samp{X @var{from} @var{to} @var{user} -@var{options}}
4073:
4074: The @samp{X} and the @samp{-} are literal characters. This is a request
4075: by the master to, in essence, execute @code{uucp} on the slave. The
4076: slave should execute @samp{uucp @var{from} @var{to}}. Taylor UUCP
4077: handles the @samp{X} request in the file @file{xcmd.c}.
4078:
4079: @table @var
4080:
4081: @item from
4082: This is the name of the file or files on the slave which the master
4083: wishes to transfer. Any wildcards are expanded on the slave. If the
4084: master is requesting that the files be transferred to itself, the
4085: request would normally contain wildcard characters, since otherwise an
4086: @samp{R} command would suffice. The master can also use this command to
4087: request that the slave transfer files to a third system.
4088:
4089: @item to
4090: This is the name of the file or directory to which the files should be
4091: transferred. This will normally use a UUCP name. For example, if the
4092: master wishes to receive the files itself, it would use
4093: @file{@var{master}!@var{path}}.
4094:
4095: @item user
4096: The name of the user who requested the transfer.
4097:
4098: @item options
4099: A list of options to control the transfer. It is not clear which, if
4100: any, options are supported by most UUCP packages. Taylor UUCP ignores
4101: the options field.
4102:
4103: @end table
4104:
4105: The slave then responds with an X command response.
4106:
4107: @table @samp
4108:
4109: @item XY
4110: The request was accepted, and the appropriate file transfer commands
4111: have been queued up for later processing.
4112:
4113: @item XN
4114: The request was denied. No particular reason is given.
4115:
4116: @end table
4117:
4118: In either case, the master will then send another command.
4119:
4120: @node H Request, , X Request, File Requests
4121: @subsubsection H Request
4122:
4123: master: @samp{H}
4124:
4125: This is used by the master to hang up the connection. The slave will
4126: respond with an @samp{H} command response.
4127:
4128: @table @samp
4129:
4130: @item HY
4131: The slave agrees to hang up the connection. In this case the master
4132: sends another @samp{HY} command. In some UUCP packages, including
4133: Taylor UUCP, the slave will then send a third @samp{HY} command. At
4134: this point the protocol is shut down, and the final handshake is begun.
4135:
4136: @item HN
4137: The slave does not agree to hang up. In this case the master and the
4138: slave exchange roles. The next command will be sent by the former
4139: slave, which is the new master. The roles may be reversed several times
4140: during a single connection.
4141:
4142: @end table
4143:
4144: @node Final Handshake, , File Requests, UUCP Protocol
4145: @subsection Final Handshake
4146:
4147: After the protocol has been shut down, the final handshake is
4148: performed. This handshake has no real purpose, and some UUCP packages
4149: simply drop the connection rather than do it (in fact, some will drop
4150: the connection immediately after both sides agree to hangup, without
4151: even closing down the protocol).
4152:
4153: @table @asis
4154:
4155: @item caller: @samp{\020OOOOOO\000}
4156:
4157: @item called: @samp{\020OOOOOOO\000}
4158:
4159: @end table
4160:
4161: That is, the calling UUCP sends six letter O's and the called UUCP
4162: replies with seven letter O's. Some UUCP packages always send six O's.
4163:
4164: @node g Protocol, f Protocol, UUCP Protocol, Protocols
4165: @section The UUCP @samp{g} Protocol
4166: @cindex g protocol
4167: @cindex protocol (g)
4168:
4169: The @samp{g} protocol is a packet based flow controlled error correcting
4170: protocol that requires an eight bit clear connection. It is the
4171: original UUCP protocol, and is supported by all UUCP implementations.
4172: Many implementations of it are only able to support small window and
4173: packet sizes, specifically a window size of 3 and a packet size of 64
4174: bytes, but the protocol itself can support up to a window size of 7 and
4175: a packet size of 4096 bytes. Complaints about the inefficiency of the
4176: @samp{g} protocol generally refer to specific implementations, rather
4177: than the correctly implemented protocol.
4178:
4179: The @samp{g} protocol was originally designed for general packet drivers,
4180: and thus contains some features that are not used by UUCP, including
4181: an alternate data channel and the ability to renegotiate packet and
4182: window sizes during the communication session.
4183:
4184: The @samp{g} protocol is spoofed by many Telebit modems. When spoofing is
4185: in effect, each Telebit modem uses the @samp{g} protocol to communicate
4186: with the attached computer, but the data between the modems is sent
4187: using a Telebit proprietary error correcting protocol. This allows
4188: for very high throughput over the Telebit connection, which, because
4189: it is half-duplex, would not normally be able to handle the @samp{g}
4190: protocol very well at all.
4191:
4192: This discussion of the @samp{g} protocol explains how it works, but does
4193: not discuss useful error handling techniques. Some discussion of this
4194: can be found in Jamie E. Hanrahan's paper (@pxref{Documentation
4195: References}). A detailed examination of the source code would also be
4196: profitable.
4197:
4198: The Taylor UUCP code to handle the @samp{g} protocol is in the file
4199: @file{protg.c}. There are a number of functions; the most important
4200: ones are @code{fgstart}, @code{fgsend_control}, @code{fgsenddata}, and
4201: @code{fgprocess_data}.
4202:
4203: All @samp{g} protocol communication is done with packets. Each packet
4204: begins with a six byte header. Control packets consist only of the
4205: header. Data packets contain additional data.
4206:
4207: The header is as follows:
4208:
4209: @table @asis
4210:
4211: @item @samp{\020}
4212: Every packet begins with a @samp{^P}.
4213:
4214: @item @var{k} (1 <= @var{k} <= 9)
4215: @ifinfo
4216: The @var{k} value is always 9 for a control packet. For a data packet,
4217: the @var{k} value indicates how must data follows the six byte header.
4218: The amount of data is 2 ** (@var{k} + 4), where ** indicates
4219: exponentiation. Thus a @var{k} value of 1 means 32 data bytes and a
4220: @var{k} value of 8 means 4096 data bytes. The @var{k} value for a data
4221: packet must be between 1 and 8 inclusive.
4222: @end ifinfo
4223: @iftex
4224: The @var{k} value is always 9 for a control packet. For a data packet,
4225: the @var{k} value indicates how must data follows the six byte header.
4226: The amount of data is @math{2^{@var{k} + 4}}. Thus a @var{k} value of 1
4227: means 32 data bytes and a @var{k} value of 8 means 4096 data bytes. The
4228: @var{k} value for a data packet must be between 1 and 8 inclusive.
4229: @end iftex
4230:
4231: @item checksum low byte
4232: @itemx checksum high byte
4233: The checksum value is described below.
4234:
4235: @item control byte
4236: The control packet indicates the type of packet, and is described below.
4237:
4238: @item xor byte
4239: This byte is the xor of @var{k}, the checksum low byte, the checksum
4240: high byte and the control byte (i.e. the second, third, fourth and fifth
4241: header bytes). It is used to ensure that the header data is valid.
4242:
4243: @end table
4244:
4245: The control byte in the header is composed of three bit fields, referred
4246: to here as @var{tt} (two bits), @var{xxx} (three bits) and @var{yyy}
4247: (three bits). The complete byte is @var{ttxxxyyy}, or (@var{tt} << 6) +
4248: (@var{xxx} << 3) + @var{yyy}.
4249:
4250: The @var{tt} field takes on the following values:
4251:
4252: @table @asis
4253:
4254: @item 0
4255: This is a control packet. In this case the @var{k} byte in the header
4256: must be 9. The @var{xxx} field indicates the type of control packet;
4257: the types are described below.
4258:
4259: @item 1
4260: This is an alternate data channel packet. This is not used by UUCP.
4261:
4262: @item 2
4263: This is a data packet, and the entire contents of the attached data
4264: field (whose length is given by the @var{k} byte in the header) are
4265: valid. The @var{xxx} and @var{yyy} fields are described below.
4266:
4267: @item 3
4268: This is a short data packet. Let the length of the data field (as given
4269: by the @var{k} byte in the header) be @code{l}. Let the first byte in
4270: the data field be @code{b1}. If @code{b1} is less than 128 (if the most
4271: significant bit of @code{b1} is 0), then there are @code{l - b1} valid
4272: bytes of data in the data field, beginning with the second byte. If
4273: @code{b1 >= 128}, let @code{b2} be the second byte in the data field.
4274: Then there are @code{l - ((b1 & 0x7f) + (b2 << 7))} valid bytes of data
4275: in the data field, beginning with the third byte. In all cases @code{l}
4276: bytes of data are sent (and all data bytes participate in the checksum
4277: calculation) but some of the trailing bytes may be dropped by the
4278: receiver. The @var{xxx} and @var{yyy} fields are described below.
4279:
4280: @end table
4281:
4282: In a data packet (short or not) the @var{xxx} field gives the sequence
4283: number of the packet. Thus sequence numbers can range from 0 to 7,
4284: inclusive. The @var{yyy} field gives the sequence number of the last
4285: correctly received packet.
4286:
4287: Each communication direction uses a window which indicates how many
4288: unacknowledged packets may be transmitted before waiting for an
4289: acknowledgement. The window may range from 1 to 7 packets, and may be
4290: different in each direction. For example, if the window is 3 and the
4291: last packet acknowledged was packet number 6, packet numbers 7, 0 and 1
4292: may be sent but the sender must wait for an acknowledgement before
4293: sending packet number 2. This acknowledgement could come as the
4294: @var{yyy} field of a data packet or as the @var{yyy} field of a
4295: @code{RJ} or @code{RR} control packet (described below).
4296:
4297: Each packet must be transmitted in order (the sender may not skip
4298: sequence numbers). Each packet must be acknowledged, and each packet
4299: must be acknowledged in order.
4300:
4301: In a control packet, the @var{xxx} field takes on the following values:
4302:
4303: @table @asis
4304:
4305: @item 1 @code{CLOSE}
4306: The connection should be closed immediately. This is typically sent
4307: when one side has seen too many errors and wants to give up. It is also
4308: sent when shutting down the protocol. If an unexpected @code{CLOSE}
4309: packet is received, a @code{CLOSE} packet should be sent in reply and
4310: the @samp{g} protocol should halt, causing UUCP to enter the final
4311: handshake.
4312:
4313: @item 2 @code{RJ} or @code{NAK}
4314: The last packet was not received correctly. The @var{yyy} field
4315: contains the sequence number of the last correctly received packet.
4316:
4317: @item 3 @code{SRJ}
4318: Selective reject. The @var{yyy} field contains the sequence number of a
4319: packet that was not received correctly, and should be retransmitted.
4320: This is not used by UUCP, and most implementations will not recognize
4321: it. Taylor UUCP will recognize it but not generate it.
4322:
4323: @item 4 @code{RR} or @code{ACK}
4324: Packet acknowledgement. The @var{yyy} field contains the sequence
4325: number of the last correctly received packet.
4326:
4327: @item 5 @code{INITC}
4328: Third initialization packet. The @var{yyy} field contains the maximum
4329: window size to use.
4330:
4331: @item 6 @code{INITB}
4332: @ifinfo
4333: Second initialization packet. The @var{yyy} field contains the packet
4334: size to use. It requests a size of 2 ** (@var{yyy} + 5). Note that
4335: this is not the same coding used for the @var{k} byte in the packet
4336: header (it is 1 less). Some UUCP implementations can handle any packet
4337: size up to that specified; some can only handled exactly the size
4338: specified. Taylor UUCP will always accept any packet size.
4339: @end ifinfo
4340: @iftex
4341: Second initialization packet. The @var{yyy} field contains the packet
4342: size to use. It requests a size of @math{2^{@var{yyy}+5}}. Note that
4343: this is not the same coding used for the @var{k} byte in the packet
4344: header (it is 1 less). Some UUCP implementations can handle any packet
4345: size up to that specified; some can only handled exactly the size
4346: specified. Taylor UUCP will always accept any packet size.
4347: @end iftex
4348:
4349: @item 7 @code{INITA}
4350: First initialization packet. The @var{yyy} field contains the maximum
4351: window size to use.
4352:
4353: @end table
4354:
4355: To compute the checksum, call the control byte (the fifth byte in the
4356: header) @code{c}.
4357:
4358: The checksum of a control packet is simply @code{0xaaaa - c}.
4359:
4360: The checksum of a data packet is @code{0xaaaa - (@var{check} ^ c)}
4361: (@code{^} denotes exclusive or, as in C), and @code{@var{check}} is the
4362: result of the following routine run on the contents of the data field
4363: (every byte in the data field participates in the checksum, even for a
4364: short data packet). Below is the routine used by Taylor UUCP; it is a
4365: slightly modified version of a routine which John Gilmore patched from
4366: G.L. Chesson's original paper. The @code{z} argument points to the
4367: data and the @code{c} argument indicates how much data there is.
4368:
4369: @example
4370: int
4371: igchecksum (z, c)
4372: register const char *z;
4373: register int c;
4374: @{
4375: register unsigned int ichk1, ichk2;
4376:
4377: ichk1 = 0xffff;
4378: ichk2 = 0;
4379:
4380: do
4381: @{
4382: register unsigned int b;
4383:
4384: /* Rotate ichk1 left. */
4385: if ((ichk1 & 0x8000) == 0)
4386: ichk1 <<= 1;
4387: else
4388: @{
4389: ichk1 <<= 1;
4390: ++ichk1;
4391: @}
4392:
4393: /* Add the next character to ichk1. */
4394: b = *z++ & 0xff;
4395: ichk1 += b;
4396:
4397: /* Add ichk1 xor the character position in the buffer
4398: counting from the back to ichk2. */
4399: ichk2 += ichk1 ^ c;
4400:
4401: /* If the character was zero, or adding it to ichk1
4402: caused an overflow, xor ichk2 to ichk1. */
4403: if (b == 0 || (ichk1 & 0xffff) < b)
4404: ichk1 ^= ichk2;
4405: @}
4406: while (--c > 0);
4407:
4408: return ichk1 & 0xffff;
4409: @}
4410: @end example
4411:
4412: When the @samp{g} protocol is started, the calling UUCP sends an INITA
4413: control packet with the window size it wishes the called UUCP to use.
4414: The called UUCP responds with an INITA packet with the window size it
4415: wishes the calling UUCP to use. Pairs of INITB and INITC packets are
4416: then similarly exchanged. When these exchanges are completed, the
4417: protocol is considered to have been started. The window size is sent
4418: twice, with both the INITA and the INITC packets.
4419:
4420: When a UUCP package transmits a command, it sends one or more data
4421: packets. All the data packets will normally be complete, although some
4422: UUCP packages may send the last one as a short packet. The command
4423: string is sent with a trailing null byte, to let the receiving package
4424: know when the command is finished. Some UUCP packages require the last
4425: byte of the last packet sent to be null, even if the command ends
4426: earlier in the packet. Some packages may require all the trailing bytes
4427: in the last packet to be null, but I have not confirmed this.
4428:
4429: When a UUCP package sends a file, it will send a sequence of data
4430: packets. The end of the file is signalled by a short data packet
4431: containing zero valid bytes (it will normally be preceeded by a short
4432: data packet containing the last few bytes in the file).
4433:
4434: Note that the sequence numbers cover the entire communication session,
4435: including both command and file data.
4436:
4437: When the protocol is shut down, each UUCP package sends a @code{CLOSE}
4438: control packet.
4439:
4440: @node f Protocol, t Protocol, g Protocol, Protocols
4441: @section The UUCP @samp{f} Protocol
4442: @cindex f protocol
4443: @cindex protocol (f)
4444:
4445: The @samp{f} protocol is a seven bit protocol which checksums an entire
4446: file at a time. It only uses the characters between \040 and \176
4447: (ASCII space and @samp{~}) inclusive as well as the carriage return
4448: character. It can be very efficient for transferring text only data,
4449: but it is very inefficient at transferring eight bit data (such as
4450: compressed news). It is not flow controlled, and the checksum is fairly
4451: insecure over large files, so using it over a serial connection requires
4452: handshaking (@code{XON}/@code{XOFF} can be used) and error correcting
4453: modems. Some people think it should not be used even under those
4454: circumstances.
4455:
4456: I believe the @samp{f} protocol originated in BSD versions of UUCP. It was
4457: originally intended for transmission over X.25 PAD links.
4458:
4459: The Taylor UUCP code for the @samp{f} protocol is in @file{protf.c}.
4460:
4461: The @samp{f} protocol has no startup or finish protocol. However, both
4462: sides typically sleep for a couple of seconds before starting up,
4463: because they switch the terminal into @code{XON}/@code{XOFF} mode and
4464: want to allow the changes to settle before beginning transmission.
4465:
4466: When a UUCP package transmits a command, it simply sends a string
4467: terminated by a carriage return.
4468:
4469: When a UUCP package transmits a file, each byte b of the file is
4470: translated according to the following table:
4471:
4472: @example
4473: 0 <= b <= 037: 0172, b + 0100 (0100 to 0137)
4474: 040 <= b <= 0171: b ( 040 to 0171)
4475: 0172 <= b <= 0177: 0173, b - 0100 ( 072 to 077)
4476: 0200 <= b <= 0237: 0174, b - 0100 (0100 to 0137)
4477: 0240 <= b <= 0371: 0175, b - 0200 ( 040 to 0171)
4478: 0372 <= b <= 0377: 0176, b - 0300 ( 072 to 077)
4479: @end example
4480:
4481: That is, a byte between \040 and \171 inclusive is transmitted as is,
4482: and all other bytes are prefixed and modified as shown.
4483:
4484: When all the file data is sent, a seven byte sequence is sent: two bytes
4485: of \176 followed by four ASCII bytes of the checksum as printed in base
4486: 16 followed by a carriage return. For example, if the checksum was
4487: 0x1234, this would be sent: "\176\1761234\r".
4488:
4489: The checksum is initialized to 0xffff. For each byte that is sent it is
4490: modified as follows (where @code{b} is the byte before it has been
4491: transformed as described above):
4492:
4493: @example
4494: /* Rotate the checksum left. */
4495: if ((ichk & 0x8000) == 0)
4496: ichk <<= 1;
4497: else
4498: @{
4499: ichk <<= 1;
4500: ++ichk;
4501: @}
4502:
4503: /* Add the next byte into the checksum. */
4504: ichk += b;
4505: @end example
4506:
4507: When the receiving UUCP sees the checksum, it compares it against its
4508: own calculated checksum and replies with a single character followed
4509: by a carriage return.
4510:
4511: @table @samp
4512:
4513: @item G
4514: The file was received correctly.
4515:
4516: @item R
4517: The checksum did not match, and the file should be resent from the
4518: beginning.
4519:
4520: @item Q
4521: The checksum did not match, but too many retries have occurred and the
4522: communication session should be abandoned.
4523:
4524: @end table
4525:
4526: The sending UUCP checks the returned character and acts accordingly.
4527:
4528: @node t Protocol, e Protocol, f Protocol, Protocols
4529: @section The UUCP @samp{t} Protocol
4530: @cindex t protocol
4531: @cindex protocol (t)
4532:
4533: The @samp{t} protocol is intended for TCP links. It does no error
4534: checking or flow control, and requires an eight bit clear channel.
4535:
4536: I believe the @samp{t} protocol originated in BSD versions of UUCP.
4537:
4538: The Taylor UUCP code for the @samp{t} protocol is in @file{prott.c}.
4539:
4540: When a UUCP package transmits a command, it first gets the length of the
4541: command string, @var{c}. It then sends ((@var{c} / 512) + 1) * 512
4542: bytes (the smallest multiple of 512 which can hold @var{c} bytes plus a
4543: null byte) consisting of the command string itself followed by trailing
4544: null bytes.
4545:
4546: When a UUCP package sends a file, it sends it in blocks. Each block
4547: contains at most 1024 bytes of data. Each block consists of four bytes
4548: containing the amount of data in binary (most significant byte first,
4549: the same format as used by the Unix function @code{htonl}) followed by
4550: that amount of data. The end of the file is signalled by a block
4551: containing zero bytes of data.
4552:
4553: @node e Protocol, x Protocol, t Protocol, Protocols
4554: @section The UUCP @samp{e} Protocol
4555: @cindex e protocol
4556: @cindex protocol (e)
4557:
4558: The @samp{e} protocol is similar to the @samp{t} protocol. It does no
4559: flow control or error checking and is intended for use over TCP.
4560:
4561: The @samp{e} protocol originated in versions of HDB UUCP.
4562:
4563: The Taylor UUCP code for the @samp{e} protocol is in @file{prote.c}.
4564:
4565: When a UUCP package transmits a command, it simply sends the command as
4566: an ASCII string terminated by a null byte.
4567:
4568: When a UUCP package transmits a file, it sends the complete size of the
4569: file as an ASCII decimal number. The ASCII string is padded out to 20
4570: bytes with null bytes (i.e., if the file is 1000 bytes long, it sends
4571: @samp{1000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0}). It then sends the entire
4572: file.
4573:
4574: @node x Protocol, d Protocol, e Protocol, Protocols
4575: @section The UUCP @samp{x} Protocol
4576:
4577: I believe that the @samp{x} protocol was intended for use over X.25
4578: virtual circuits. It relies on a write of zero bytes being read as zero
4579: bytes without stopping communication. I have heard that it does not
4580: work correctly. If someone would care to fill this in more, I would be
4581: grateful. Taylor UUCP does not implement the @samp{x} protocol.
4582:
4583: @node d Protocol, Capital G Protocol, x Protocol, Protocols
4584: @section The UUCP @samp{d} Protocol
4585:
4586: This is apparently used for DataKit connections, and relies on a write
4587: of zero bytes being read as zero bytes, much as the @samp{x} protocol
4588: does. I don't really know anything else about it. Taylor UUCP does not
4589: implement the @samp{d} protocol.
4590:
4591: @node Capital G Protocol, Documentation References, d Protocol, Protocols
4592: @section The UUCP @samp{G} Protocol
4593:
4594: The @samp{G} protocol is apparently simply the @samp{g} protocol, except
4595: that it is known to support all possible window and packet sizes. It
4596: was introduced by SVR4 UUCP; the SVR4 implementation of the @samp{g}
4597: protocol is apparently fixed at a packet size of 64 and a window size of
4598: 7. Taylor UUCP does not recognize the @samp{G} protocol. It does
4599: support all window and packet sizes for the @samp{g} protocol.
4600:
4601: @node Documentation References, , Capital G Protocol, Protocols
4602: @section Documentation References
4603:
4604: I took a lot of the information from Jamie E. Hanrahan's paper in the
4605: Fall 1990 DECUS Symposium, and from Managing UUCP and Usenet by Tim
4606: O'Reilly and Grace Todino (with contributions by several other people).
4607: The latter includes most of the former, and is published by O'Reilly &
4608: Associates, Inc.
4609:
4610: Some information is originally due to a Usenet article by Chuck Wegrzyn.
4611: The information on the @samp{g} protocol comes partially from a paper by
4612: G.L. Chesson of Bell Laboratories, partially from Jamie E. Hanrahan's
4613: paper, and partially from source code by John Gilmore. The information
4614: on the @samp{f} protocol comes from the source code by Piet Berteema.
4615: The information on the @samp{t} protocol comes from the source code by
4616: Rick Adams. The information on the @samp{e} protocol comes from a
4617: Usenet article by Matthias Urlichs.
4618:
4619: @node Hacking, Acknowledgements, Protocols, Top
4620: @chapter Hacking Taylor UUCP
4621:
4622: This chapter provides the briefest of guides to the Taylor UUCP source
4623: code itself.
4624:
4625: @menu
4626: * System Dependence:: System Dependence
4627: * Naming Conventions:: Naming Conventions
4628: * Patches:: Patches
4629: @end menu
4630:
4631: @node System Dependence, Naming Conventions, Hacking, Hacking
4632: @section System Dependence
4633:
4634: The code is carefully segregated into a system independent portion and a
4635: system dependent portion. The system dependent code is in the
4636: @file{unix} subdirectory, and also in the files @file{tcp.c},
4637: @file{tli.c} and @file{sysh.unx} (also known as @file{sysdep.h}).
4638:
4639: With the right configuration parameters, the system independent code
4640: calls only ANSI C functions. Some of the less common ANSI C functions
4641: are also provided in the @file{lib} directory. The replacement function
4642: @code{strtol} in @file{lib/strtol.c} assumes that the characters @kbd{A}
4643: to @kbd{F} and @kbd{a} to @kbd{f} appear in strictly sequential order.
4644: The function @code{igradecmp} in @file{uuconf/grdcmp.c} assumes that the
4645: upper and lower case letters appear in order. Both assumptions are true
4646: for ASCII and EBCDIC, but neither is guaranteed by ANSI C. Disregarding
4647: these caveats, I believe that the system independent portion of the code
4648: is strictly conforming.
4649:
4650: That's not too exciting, since all the work is done in the system
4651: dependent code. I think that this code can conform to POSIX 1003.1,
4652: given the right compilation parameters. I'm a bit less certain about
4653: this, though.
4654:
4655: The code is in use on a 16 bit segmented system with no function
4656: prototypes, so I'm certain that all casts to long and pointers are done
4657: when necessary.
4658:
4659: @node Naming Conventions, Patches, System Dependence, Hacking
4660: @section Naming Conventions
4661:
4662: I use a modified Hungarian naming convention for my variables and
4663: functions. As with all naming conventions, the code is rather opaque if
4664: you are not familiar with it, but becomes clear and easy to use with
4665: time.
4666:
4667: The first character indicates the type of the variable (or function
4668: return value). Sometimes additional characters are used. I use the
4669: following type prefixes:
4670:
4671: @table @samp
4672: @item a
4673: array; the next character is the type of an element
4674: @item b
4675: byte or character
4676: @item c
4677: count of something
4678: @item e
4679: stdio FILE *
4680: @item f
4681: boolean
4682: @item i
4683: generic integer
4684: @item l
4685: double
4686: @item o
4687: file descriptor (as returned by open, creat, etc.)
4688: @item p
4689: generic pointer
4690: @item q
4691: pointer to structure
4692: @item s
4693: structure
4694: @item u
4695: void (function return values only)
4696: @item z
4697: character string
4698: @end table
4699:
4700: A generic pointer ('p') is sometimes a @code{void *}, sometimes a
4701: function pointer in which case the prefix is pf, and sometimes a pointer
4702: to another type, in which case the next character is the type to which
4703: it points (pf is overloaded).
4704:
4705: An array of strings (@code{char *[]}) would be named @code{az} (array of
4706: string). If this array were passed to a function, the function
4707: parameter would be named @code{paz} (pointer to array of string).
4708:
4709: Note that the variable name prefixes do not necessarily indicate the
4710: type of the variable. For example, a variable prefixed with i may be
4711: int, long or short. Similarly, a variable prefixed with b may be a char
4712: or an int; for example, the return value of getchar would be caught in
4713: an int variable prefixed with b.
4714:
4715: For a non-local variable (extern or file static), the first character
4716: after the type prefix is capitalized.
4717:
4718: Most static variables and functions use another letter after the type
4719: prefix to indicate which module they come from. This is to help
4720: distinguish different names in the debugger. For example, all static
4721: functions in @file{protg.c}, the @samp{g} protocol source code, use a
4722: module prefix of @samp{g}. This isn't too useful, as a number of
4723: modules use a module prefix of @samp{s}.
4724:
4725: @node Patches, , Naming Conventions, Hacking
4726: @section Patches
4727:
4728: I am always grateful for any patches sent in. Much of the flexibility
4729: and portability of the code is due to other people. Please do not
4730: hesitate to send me any changes you have found necessary or useful.
4731:
4732: When sending a patch, please send the output of the Unix @code{diff}
4733: program invoked with the @samp{-c} option (if you have the GNU version
4734: of @code{diff}, use the @samp{-p} option). Always invoke @code{diff}
4735: with the original file first and the modified file second.
4736:
4737: If your @code{diff} does not support @samp{-c} (or you don't have
4738: @code{diff}), send a complete copy of the modified file (if you have
4739: just changed a single function, you can just send the new version of the
4740: function). In particular, please do not send @code{diff} output without
4741: the @samp{-c} option, as it is useless.
4742:
4743: If you have made a number of changes, it is very convenient for me if
4744: you send each change as a separate mail message. Sometimes I will think
4745: that one change is useful but another one is not. If they are in
4746: different messages it is much easier for me to apply one but not the
4747: other.
4748:
4749: I rarely apply the patches directly. Instead I work my way through the
4750: hunks and apply each one separately. This ensures that the naming
4751: remains consistent, and that I understand all the code.
4752:
4753: If you can not follow all these rules, then don't. But if you do, it
4754: makes it more likely that I will incorporate your changes. I am not
4755: paid for my UUCP work, and my available time is unfortunately very
4756: restricted. The package is important to me, and I do what I can, but I
4757: can not do all that I would like, much less all that everybody else
4758: would like.
4759:
4760: Finally, please do not be offended if I do not reply to messages for
4761: some time, even a few weeks. I am often behind on my mail, and if I
4762: think your message deserves a considered reply I will often put it aside
4763: until I have time to deal with it.
4764:
4765: @node Acknowledgements, Index (concepts), Hacking, Top
4766: @chapter Acknowledgements
4767:
4768: This is a list of people who gave help or suggestions while I was
4769: working on the Taylor UUCP project. Appearance on this list does not
4770: constitute endorsement of the program, particularly since some of the
4771: comments were criticisms. I've probably left some people off, and I
4772: apologize for any oversight; it does not mean your contribution was
4773: unappreciated.
4774:
4775: @ifinfo
4776: First of all, I would like to thank the people at Infinity Development
4777: Systems (formerly AIRS, which lives on in the domain name, at least for
4778: now) for permitting me to use their computers and @file{uunet} access.
4779: I would also like to thank Richard Stallman @code{<rms@@gnu.ai.mit.edu>}
4780: for founding the Free Software Foundation and John Gilmore
4781: @code{<gnu@@cygnus.com>} for writing the initial version of gnuucp which
4782: was a direct inspiration for this somewhat larger project. Chip
4783: Salzenberg @code{<chip@@tct.com>} has contributed many patches.
4784: Franc,ois Pinard @code{<pinard@@iro.umontreal.ca>} tirelessly tested the
4785: code and suggested many improvements. He also put together the initial
4786: version of this document. Doug Evans contributed the zmodem protocol.
4787: Finally, Verbus M. Counts @code{<verbus@@westmark.com>} and Centel
4788: Federal Systems, Inc. deserve special thanks, since they actually paid
4789: me money to port this code to System III.
4790: @end ifinfo
4791: @iftex
4792: First of all, I would like to thank the people at Infinity Development
4793: Systems (formerly AIRS, which lives on in the domain name, at least for
4794: now) for permitting me to use their computers and @file{uunet} access.
4795: I would also like to thank Richard Stallman @code{<rms@@gnu.ai.mit.edu>}
4796: for founding the Free Software Foundation and John Gilmore
4797: @code{<gnu@@cygnus.com>} for writing the initial version of gnuucp which
4798: was a direct inspiration for this somewhat larger project. Chip
4799: Salzenberg @code{<chip@@tct.com>} has contributed many patches.
4800: @tex
4801: Fran\c cois Pinard
4802: @end tex
4803: @code{<pinard@@iro.umontreal.ca>} tirelessly tested the code and
4804: suggested many improvements. He also put together the initial version
4805: of this document. Doug Evans contributed the zmodem protocol. Finally,
4806: Verbus M. Counts @code{<verbus@@westmark.com>} and Centel Federal
4807: Systems, Inc. deserve special thanks, since they actually paid me money
4808: to port this code to System III.
4809: @end iftex
4810:
4811: In alphabetical order:
4812:
4813: @example
4814: "Earle F. Ake - SAIC" @code{<ake@@Dayton.SAIC.COM>}
4815: @code{mra@@searchtech.com} (Michael Almond)
4816: @code{cambler@@zeus.calpoly.edu} (Christopher J. Ambler)
4817: Brian W. Antoine @code{<briana@@tau-ceti.isc-br.com>}
4818: @code{jantypas@@soft21.s21.com} (John Antypas)
4819: @code{nba@@sysware.DK} (Niels Baggesen)
4820: @code{uunet!hotmomma!sdb} (Scott Ballantyne)
4821: Zacharias Beckman @code{<zac@@dolphin.com>}
4822: @code{mike@@mbsun.ann-arbor.mi.us} (Mike Bernson)
4823: @code{bob@@usixth.sublink.org} (Roberto Biancardi)
4824: @code{statsci!scott@@coco.ms.washington.edu} (Scott Blachowicz)
4825: @code{bag%wood2.cs.kiev.ua@@relay.ussr.eu.net} (Andrey G Blochintsev)
4826: Gregory Bond @code{<gnb@@bby.com.au>}
4827: Marc Boucher @code{<marc@@CAM.ORG>}
4828: @code{dean@@coplex.com} (Dean Brooks)
4829: @code{dave@@dlb.com} (Dave Buck)
4830: @code{gordon@@sneaky.lonestar.org} (Gordon Burditt)
4831: @code{mib@@gnu.ai.mit.edu} (Michael I Bushnell)
4832: Brian Campbell @code{<brianc@@quantum.on.ca>}
4833: Andrew A. Chernov @code{<ache@@astral.msk.su>}
4834: @code{mafc!frank@@bach.helios.de} (Frank Conrad)
4835: Ed Carp @code{<erc@@apple.com>}
4836: @code{verbus@@westmark.westmark.com} (Verbus M. Counts)
4837: @code{cbmvax!snark.thyrsus.com!cowan} (John Cowan)
4838: Bob Cunningham @code{<bob@@soest.hawaii.edu>}
4839: @code{hubert@@arakis.fdn.org} (Hubert Delahaye)
4840: @code{denny@@dakota.alisa.com} (Bob Denny)
4841: @code{ssd@@nevets.oau.org} (Steven S. Dick)
4842: @code{gert@@greenie.gold.sub.org} (Gert Doering)
4843: Hans-Dieter Doll @code{<hd2@@Insel.DE>}
4844: Andrew Evans @code{<andrew@@airs.com>}
4845: @code{dje@@cygnus.com} (Doug Evans)
4846: Marc Evans @code{<marc@@synergytics.com>}
4847: @code{kksys!kegworks!lfahnoe@@cs.umn.edu} (Larry Fahnoe)
4848: @code{fenner@@jazz.psu.edu} (Bill Fenner)
4849: "David J. Fiander" @code{<golem!david@@news.lsuc.on.ca>}
4850: Thomas Fischer @code{<batman@@olorin.dark.sub.org>}
4851: @code{erik@@eab.retix.com} (Erik Forsberg)
4852: Lele Gaifax @code{<piggy@@idea.sublink.org>}
4853: @code{Peter.Galbavy@@micromuse.co.uk}
4854: @code{hunter@@phoenix.pub.uu.oz.au} (James Gardiner [hunter])
4855: Terry Gardner @code{<cphpcom!tjg01>}
4856: @code{ol@@infopro.spb.su} (Oleg Girko)
4857: @code{jimmy@@tokyo07.info.com} (Jim Gottlieb)
4858: @code{ryan@@cs.umb.edu} (Daniel R. Guilderson)
4859: @code{greg@@gagme.chi.il.us} (Gregory Gulik)
4860: Richard H. Gumpertz @code{<rhg@@cps.com>}
4861: Michael Haberler @code{<mah@@parrot.prv.univie.ac.at>}
4862: @code{jh@@moon.nbn.com} (John Harkin)
4863: @code{guy@@auspex.auspex.com} (Guy Harris)
4864: Petri Helenius @code{<pete@@fidata.fi>}
4865: Bob Hemedinger @code{<bob@@dalek.mwc.com>}
4866: Andrew Herbert @code{<andrew@@werple.pub.uu.oz.au>}
4867: Peter Honeyman @code{<honey@@citi.umich.edu>}
4868: @code{pmcgw!personal-media.co.jp!ishikawa} (Chiaki Ishikawa)
4869: @code{bei@@dogface.austin.tx.us} (Bob Izenberg)
4870: Rob Janssen @code{<cmgit!rob@@relay.nluug.nl>}
4871: @code{harvee!esj} (Eric S Johansson)
4872: Alan Judge @code{<aj@@dec4ie.IEunet.ie>}
4873: @code{chris@@cj_net.in-berlin.de} (Christof Junge)
4874: @code{tron@@Veritas.COM} (Ronald S. Karr)
4875: Brendan Kehoe @code{<brendan@@cs.widener.edu>}
4876: @code{kersing@@nlmug.nl.mugnet.org} (Jac Kersing)
4877: @code{rob@@pact.nl} (Rob Kurver)
4878: @code{kent@@sparky.IMD.Sterling.COM} (Kent Landfield)
4879: @code{lebaron@@inrs-telecom.uquebec.ca} (Gregory LeBaron)
4880: @code{karl@@sugar.NeoSoft.Com} (Karl Lehenbauer)
4881: @code{merlyn@@digibd.com} (Merlyn LeRoy)
4882: @code{clewis@@ferret.ocunix.on.ca} (Chris Lewis)
4883: @code{gdonl@@ssi1.com} (Don Lewis)
4884: @code{libove@@libove.det.dec.com} (Jay Vassos-Libove)
4885: @code{bruce%blilly@@Broadcast.Sony.COM} (Bruce Lilly)
4886: Ted Lindgreen @code{<tlindgreen@@encore.nl>}
4887: @code{andrew@@cubetech.com} (Andrew Loewenstern)
4888: "Arne Ludwig" @code{<arne@@rrzbu.hanse.de>}
4889: Matthew Lyle @code{<matt@@mips.mitek.com>}
4890: @code{djm@@eng.umd.edu} (David J. MacKenzie)
4891: John R MacMillan @code{<chance!john@@sq.sq.com>}
4892: Giles D Malet @code{<shrdlu!gdm@@provar.kwnet.on.ca>}
4893: @code{mem@@mv.MV.COM} (Mark E. Mallett)
4894: @code{pepe@@dit.upm.es} (Jose A. Manas)
4895: @code{martelli@@cadlab.sublink.org} (Alex Martelli)
4896: Yanek Martinson @code{<yanek@@mthvax.cs.miami.edu>}
4897: @code{jm@@aristote.univ-paris8.fr} (Jean Mehat)
4898: @code{les@@chinet.chi.il.us} (Leslie Mikesell)
4899: @code{mmitchel@@digi.lonestar.org} (Mitch Mitchell)
4900: @code{rmohr@@infoac.rmi.de} (Rupert Mohr)
4901: @code{ianm@@icsbelf.co.uk} (Ian Moran)
4902: @code{brian@@ilinx.wimsey.bc.ca} (Brian J. Murrell)
4903: @code{service@@infohh.rmi.de} (Dirk Musstopf)
4904: @code{lyndon@@cs.athabascau.ca} (Lyndon Nerenberg)
4905: @code{rolf@@saans.north.de} (Rolf Nerstheimer)
4906: @code{tom@@smart.bo.open.de} (Thomas Neumann)
4907: @code{mnichols@@pacesetter.com}
4908: @code{nolan@@helios.unl.edu} (Michael Nolan)
4909: david nugent @code{<david@@csource.oz.au>}
4910: Petri Ojala @code{<ojala@@funet.fi>}
4911: @code{abekas!dragoman!mikep@@decwrl.dec.com} (Mike Park)
4912: Tim Peiffer @code{peiffer@@cs.umn.edu}
4913: @code{don@@blkhole.resun.com} (Don Phillips)
4914: "Mark Pizzolato 415-369-9366" @code{<mark@@infocomm.com>}
4915: @code{dplatt@@ntg.com} (Dave Platt)
4916: @code{eldorado@@tharr.UUCP} (Mark Powell)
4917: Mark Powell @code{<mark@@inet-uk.co.uk>}
4918: @code{pozar@@kumr.lns.com} (Tim Pozar)
4919: @code{putsch@@uicc.com} (Jeff Putsch)
4920: Jarmo Raiha @code{<jarmo@@ksvltd.FI>}
4921: Scott Reynolds @code{<scott@@clmqt.marquette.Mi.US>}
4922: @code{mcr@@Sandelman.OCUnix.On.Ca} (Michael Richardson)
4923: @code{arnold@@cc.gatech.edu} (Arnold Robbins)
4924: @code{ross@@sun490.fdu.edu} (Jeff Ross)
4925: Aleksey P. Rudnev @code{<alex@@kiae.su>}
4926: "Heiko W.Rupp" @code{<hwr@@pilhuhn.ka.sub.org>}
4927: @code{wolfgang@@wsrcc.com} (Wolfgang S. Rupprecht)
4928: @code{tbr@@tfic.bc.ca} (Tom Rushworth)
4929: @code{rsalz@@bbn.com} (Rich Salz)
4930: @code{sojurn!mike@@hobbes.cert.sei.cmu.edu} (Mike Sangrey)
4931: Nickolay Saukh @code{<nms@@ussr.EU.net>}
4932: Eric Schnoebelen @code{<eric@@cirr.com>}
4933: @code{scott@@geom.umn.edu}
4934: Igor V. Semenyuk @code{<iga@@argrd0.argonaut.su>}
4935: @code{uunet!gold.sub.org!root} (Christian Seyb)
4936: @code{s4mjs!mjs@@nirvo.nirvonics.com} (M. J. Shannon Jr.)
4937: @code{peter@@ficc.ferranti.com} (Peter da Silva)
4938: @code{frumious!pat} (Patrick Smith)
4939: @code{roscom!monty@@bu.edu} (Monty Solomon)
4940: Harlan Stenn @code{<harlan@@mumps.pfcs.com>}
4941: Ralf Stephan @code{<ralf@@ark.abg.sub.org>}
4942: @code{chs@@antic.apu.fi} (Hannu Strang)
4943: @code{ralf@@reswi.ruhr.de} (Ralf E. Stranzenbach)
4944: Shigeya Suzuki @code{<shigeya@@dink.foretune.co.jp>}
4945: @code{swiers@@plains.NoDak.edu}
4946: Oleg Tabarovsky @code{<olg@@olghome.pccentre.msk.su>}
4947: John Theus @code{<john@@theus.rain.com>}
4948: Karsten Thygesen @code{<karthy@@dannug.dk>}
4949: Graham Toal @code{<gtoal@@pizzabox.demon.co.uk>}
4950: @code{rmtodd@@servalan.servalan.com} (Richard Todd)
4951: Len Tower @code{<tower-prep@@ai.mit.edu>}
4952: Mark Towfiq @code{<justice!towfiq@@Eingedi.Newton.MA.US>}
4953: @code{mju@@mudos.ann-arbor.mi.us} (Marc Unangst)
4954: Tomi Vainio @code{<tomppa@@fidata.fi>}
4955: @code{vogel@@omega.ssw.de} (Andreas Vogel)
4956: @code{jv@@mh.nl} (Johan Vromans)
4957: @code{steve@@nshore.org} (Stephen J. Walick)
4958: @code{gerben@@rna.indiv.nluug.nl} (Gerben Wierda)
4959: @code{frnkmth!twwells.com!bill} (T. William Wells)
4960: Peter Wemm @code{<Peter_Wemm@@zeus.dialix.oz.au>}
4961: @code{mauxci!eci386!woods@@apple.com} (Greg A. Woods)
4962: Michael Yu.Yaroslavtsev @code{<mike@@yaranga.ipmce.su>}
4963: @code{jon@@console.ais.org} (Jon Zeeff)
4964: Matthias Zepf @code{<agnus@@amylnd.stgt.sub.org>}
4965: Eric Ziegast @code{<uunet!ziegast>}
4966: @end example
4967:
4968: @node Index (concepts), Index (configuration file), Acknowledgements, Top
4969: @unnumbered Concept Index
4970:
4971: @printindex cp
4972:
4973: @node Index (configuration file), , Index (concepts), Top
4974: @unnumbered Configuration File Index
4975:
4976: @printindex fn
4977:
4978: @contents
4979: @bye
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.