Path:
senator-bedfellow.mit.edu!bloom-beacon.mit.edu!cambridge-news.cygnus.com!comton.airs.com!ian
From: ian{at}airs.com (Ian Lance Taylor)
Newsgroups: comp.mail.uucp,comp.answers,news.answers
Subject: UUCP Internals Frequently Asked Questions
Keywords: UUCP, protocol, FAQ
Message-ID: 
Date: 8 May 97 08:30:02 GMT
Expires: 19 Jun 97 08:30:01 GMT
Reply-To: ian{at}airs.com (Ian Lance Taylor)
Followup-To: comp.mail.uucp
Organization: Infinity Development, Waltham, MA
Lines: 1966
Approved: news-answers-request{at}MIT.Edu
Supersedes: 
Xref: senator-bedfellow.mit.edu comp.mail.uucp:19608 comp.answers:25900
news.answers:101992

Archive-name: uucp-internals
Version: $Revision: 1.105 $
Last-modified: $Date: 1995/07/16 16:09:52 $

UUCP Protocol Internals
***********************

Recent changes:
   * Conversion to Texinfo format.

   * Description of the `E' command.

   * Description of optional number following `-N' and `ROKN' in UUCP
     protocol startup.

   * Detailed description of the `y' protocol.

   * Mention the name uuxqt uses for lock files.

This article was written by Ian Lance Taylor `' and I
may even update it periodically.  Please send me mail about suggestions or
inaccuracies.

This article describes how the various UUCP protocols work, and discusses
some other internal UUCP issues.  It does not describe how to configure
UUCP, nor how to solve UUCP connection problems, nor how to deal with UUCP
mail.  I do not know of any FAQ postings on these topics. There are some
documents on the net describing UUCP configuration, but I can not keep an
up to date list here; try using archie.

If you haven't read the `news.announce.newusers' articles, read them.

This article is in digest format.  Some newsreaders will be able to break
it apart into separate articles.  Please don't ask me how to do this,
though.

This article covers the following topics.  If questions about one of these
topics is posted to `comp.mail.uucp', please send mail to the poster
referring her or him to this FAQ.  There is no reason to post a followup,
as most of us know the answer already.


UUCP Protocol Sources
Alarm in Debugging Output
UUCP Grades
UUCP Lock Files
Execution File Format
UUCP Protocol
UUCP `g' Protocol
UUCP `f' Protocol
UUCP `t' Protocol
UUCP `e' Protocol
UUCP `G' Protocol
UUCP `i' Protocol
UUCP `j' Protocol
UUCP `x' Protocol
UUCP `y' Protocol
UUCP `d' Protocol
UUCP `h' Protocol
UUCP `v' Protocol
Thanks

----------------------------------------------------------------------

From: UUCP Protocol Sources
Subject: UUCP Protocol Sources

UUCP Protocol Sources
=====================

     "Unix-to-Unix Copy Program," said PDP-1.  "You will never find a
     more wretched hive of bugs and flamers.  We must be cautious."
                                                              --DECWars

I took a lot of the information from Jamie E. Hanrahan's paper in the Fall
1990 DECUS Symposium, and from `Managing UUCP and Usenet' by Tim O'Reilly
and Grace Todino (with contributions by several other people). The latter
includes most of the former, and is published by
     O'Reilly & Associates, Inc.
     103 Morris Street, Suite A
     Sebastopol, CA 95472
It is currently in its tenth edition.  The ISBN number is `0-937175-93-5'.

Some information is originally due to a Usenet article by Chuck Wegrzyn.
The information on execution files comes partially from Peter Honeyman. The
information on the `g' protocol comes partially from a paper by G.L.
Chesson of Bell Laboratories, partially from Jamie E. Hanrahan's
paper, and partially from source code by John Gilmore.  The information on
the `f' protocol comes from the source code by Piet Berteema.  The
information on the `t' protocol comes from the source code by Rick Adams. 
The information on the `e' protocol comes from a Usenet article by Matthias
Urlichs.  The information on the `d' protocol comes from Jonathan Clark,
who also supplied information about QFT.  The UUPlus information comes
straight from Christopher J. Ambler, of UUPlus Development; it applies to
version 1.52 and up of the shareware version of UUPlus Utilities, called
FSUUCP 1.52, but referred to in this article as UUPlus.

Although there are few books about UUCP, there are many about networks and
protocols in general.  I recommend two non-technical books which describe
the sorts of things that are available on the network: `The Whole
Internet', by Ed Krol, and `Zen and the Art of the Internet', by Brendan P.
Kehoe.  Good technical discussions of networking issues can be found in
`Internetworking with TCP/IP', by Douglas E. Comer and David L. Stevens and
in `Design and Validation of Computer Protocols'
by Gerard J. Holzmann.

------------------------------

From: Alarm in Debugging Output
Subject: Alarm in Debugging Output

Alarm in Debugging Output
=========================

The debugging output of many versions of UUCP will include messages like
`alarm 1' or `pkcget: alarm 1'.  Taylor UUCP does not use the word `alarm',
but will instead log messages like `Timed out waiting for packet'.

These types of messages mean that the UUCP package has timed out while
waiting for some sort of response from the remote system.  If it happens
consistently when trying to transfer a particular file, then the most
likely problem is that one of the modems will not transmit the XON or XOFF
characters.  Several UUCP protocols require an eight bit clean connection,
which means that the modems must treat XON or XOFF as normal data
characters, not as flow control signals.  This should always be checked
first.

Other possible problems are that the modems have simply dropped their
connection, or perhaps on one side or the other the serial buffer is
overflowing and dropping characters.  Another possibility is that the
UUCP packages disagree about some aspect of the UUCP protocol, which is
uncommon but does happen occasionally.

Using the information in the following sections, you should be able to
figure out what type of data your UUCP was expecting to receive.  This may
give some indication as to exactly what the problem is.  It is
difficult to be more specific, since there are many possiblities.

------------------------------

From: UUCP Grades
Subject: UUCP Grades

UUCP Grades
===========

Modern UUCP packages support a priority grade for each command.  The grades
generally range from `A' (the highest) to `Z' followed by `a' to `z'.  Some
UUCP packages (including Taylor UUCP) also support `0' to `9' before `A'. 
Some UUCP packages may permit any ASCII character as a grade.

On Unix, these grades are encoded in the name of the command file created
by `uucp' or `uux'.  A command file name generally has the form
`C.nnnngssss' where `nnnn' is the remote system name for which the command
is queued, `g' is a single character grade, and `ssss' is a four character
sequence number.  For example, a command file created for the system `airs'
at grade `Z' might be named `C.airsZ2551'.

The remote system name will be truncated to seven characters, to ensure
that the command file name will fit in the 14 character file name limit of
the traditional Unix file system.  UUCP packages which have no other means
of distinguishing which command files are intended for which systems thus
require all systems they connect to to have names that are unique in the
first seven characters.  Some UUCP packages use a variant of this format
which truncates the system name to six characters.  HDB
and Taylor UUCP use a different spool directory format, which allows up to
fourteen characters to be used for each system name.

The sequence number in the command file name may be a decimal integer, or
it may be a hexadecimal integer, or it may contain any alphanumeric
character.  Different UUCP packages are different.

UUPlus Utilities (as FSUUCP, a shareware DOS based UUCP and news package)
uses up to 8 characters for file names in the spool (this is a DOS file
system limitation; actually, with the extension, 11 characters are
available, but FSUUCP reserves that for future use).  FSUUCP defaults mail
to grade `D', and news to grade `N', except that when the grade of incoming
mail can be determined, that grade is preserved if the mail is forwarded to
another system. The default grades may be changed by editing the
`LIB/MAILRC' file for mail, or the `UUPLUS.CFG' file for news.

UUPC/extended for DOS, OS/2 and Windows NT handles mail at grade `C', news
at grade `d', and file transfers at grade `n'.  The UUPC/extended `UUCP'
and `RMAIL' commands accept grades to override the default, the others do
not.

I do not know how command grades are handled in other non-Unix UUCP packages.

Modern UUCP packages allow you to restrict file transfer by grade depending
on the time of day.  Typically this is done with a line in the `Systems'
(or `L.sys') file like this:
         airs Any/Z,Any2305-0855 ...
This allows grades `Z' and above to be transferred at any time.  Lower
grades may only be transferred at night.  I believe that this grade
restriction applies to local commands as well as to remote commands,
but I am not sure.  It may only apply if the UUCP package places the call,
not if it is called by the remote system.

Taylor UUCP can use the `timegrade' and `call-timegrade' commands to
achieve the same effect.  It supports the above format when reading
`Systems' or `L.sys'.

UUPC/extended provides the `symmetricgrades' option to announce the current
grade in effect when calling the remote system.

UUPlus allows specification of the highest grade accepted on a per-call
basis with the `-g' option in `UUCICO'.

This sort of grade restriction is most useful if you know what grades are
being used at the remote site.  The default grades used depend on the UUCP
package.  Generally `uucp' and `uux' have different defaults. A particular
grade can be specified with the `-g' option to `uucp' or `uux'.  For
example, to request execution of `rnews' on `airs' with grade `d', you
might use something like
         uux -gd - airs!rnews < article

Uunet queues up mail at grade `C', but increases the grade based on the
size.  News is queued at grade `d', and file transfers at grade `n'. The
example above would allow mail (below some large size) to be
received at any time, but would only permit news to be transferred at night.

------------------------------

From: UUCP Lock Files
Subject: UUCP Lock Files

UUCP Lock Files
===============

This discussion applies only to Unix.  I have no idea how UUCP locks ports
on other systems.

UUCP creates files to lock serial ports and systems.  On most, if not all,
systems, these same lock files are also used by `cu' to coordinate access
to serial ports.  On some systems `getty' also uses these lock
files, often under the name `uugetty'.

The lock file normally contains the process ID of the locking process. This
makes it easy to determine whether a lock is still valid.  The algorithm is
to create a temporary file and then link it to the name
that must be locked.  If the link fails because a file with that name
already exists, the existing file is read to get the process ID.  If the
process still exists, the lock attempt fails.  Otherwise the lock file
is deleted and the locking algorithm is retried.

Older UUCP packages put the lock files in the main UUCP spool directory,
`/usr/spool/uucp'.  HDB UUCP generally puts the lock files in a directory
of their own, usually `/usr/spool/locks' or `/etc/locks'.

The original UUCP lock file format encodes the process ID as a four byte
binary number.  The order of the bytes is host-dependent.  HDB UUCP stores
the process ID as a ten byte ASCII decimal number, with a trailing newline.
 For example, if process 1570 holds a lock file, it would contain the
eleven characters space, space, space, space, space, space, one, five,
seven, zero, newline.  Some versions of UUCP add a second line indicating
which program created the lock (`uucp', `cu', or `getty/uugetty').  I have
also seen a third type of UUCP lock file which does not contain the process
ID at all.

The name of the lock file is traditionally `LCK..' followed by the base
name of the device.  For example, to lock `/dev/ttyd0' the file
`LCK..ttyd0' would be created.  On SCO Unix, the lock file name is always
forced to lower case even if the device name has upper case letters.

System V Release 4 UUCP names the lock file using the major and minor
device numbers rather than the device name.  The file is named
`LK.XXX.YYY.ZZZ', where XXX, YYY and ZZZ are all three digit decimal
numbers.  XXX is the major device number of the device holding the
directory holding the device file (e.g., `/dev').  YYY is the major device
number of the device file itself.  ZZZ is the minor device number of the
device file itself.  If `s' holds the result of passing the device to the
stat system call (e.g., `stat ("/dev/ttyd0", &s)'), the
following line of C code will print out the corresponding lock file name:
         printf ("LK.%03d.%03d.%03d", major (s.st_dev),
                 major (s.st_rdev), minor (s.st_rdev));
The advantage of this system is that even if there are several links to the
same device, they will all use the same lock file name.

When two or more instances of `uuxqt' are executing, some sort of locking
is needed to ensure that a single execution job is only started once.  I
don't know how most UUCP packages deal with this.  Taylor UUCP uses a lock
file for each execution job.  The name of the lock file is the same as the
name of the `X.*' file, except that the initial `X' is changed to an `L'. 
The lock file holds the process ID as described above.

------------------------------

From: Execution File Format
Subject: Execution File Format

Execution File Format
=====================

UUCP `X.*' files control program execution.  They are created by `uux'.
They are transferred between systems just like any other file.  The `uuxqt'
daemon reads them to figure out how to execute the job
requested by `uux'.

An `X.*' file is simply a text file.  The first character of each line is a
command, and the remainder of the line supplies arguments.  The following
commands are defined:

`C command'
     This gives the command to execute, including the program and all  arguments. 
     For example, `rmail ian{at}airs.com'.

`U user system'
     This names the user who requested the command, and the system from
which the request came.

`I standard-input'
     This names the file from which standard input is taken.  If no
standard input file is given, the
     standard input will probably be attached to `/dev/null'.  If the
standard input file is not from
     the system on which the execution is to occur, it will also appear in
an `F' command.

`O standard-output [system]'
     This names the standard output file.  The optional second argument 
names the system to which the
     file should be sent.  If there is no second argument, the file should
be created on the executing
     system.

`F required-file [filename-to-use]'
     The `F' command can appear multiple times.  Each `F' command names a
file which must exist 
     before the execution can proceed.  This will usually be a file which
is transferred from the system on 
     which `uux' was executed, but it can also be a file from the local
system or some other system.  If the
     file is not from the local system, then the command will usually name
a file in the spool directory.  If 
     the optional second argument appears, then the file should be copied
to the execution directory 
     under that name.  This is necessary for any file other than the
standard input file.  If  the standard 
     input file is not from the local system, it will appear in both an `F'
command and an `I' command.

`R requestor-address'
     This is the address to which mail about the job should be sent. It is
relative to the system named in
     the `U' command.  If the `R' command does not appear, then mail is
sent to the user named in the `U' 
    command.

`Z'
     This command takes no arguments.  It means that a mail message should
be sent if the command 
     failed.  This is the default behaviour for most modern UUCP packages,
and for them the `Z' 
     command does not actually do anything.

`N'
     This command takes no arguments.  It means that no mail message should
be sent, even if the
     command failed.

`n'
     This command takes no arguments.  It means that a mail message should
be sent if the command 
     succeeded.  Normally a message is sent only if the command failed.

`B'
     This command takes no arguments.  It means that the standard input 
should be returned with any 
     error message.  This can be useful in cases where the input would
otherwise be lost.

`e'
     This command takes no arguments.  It means that the command should be
processed with `/bin/sh'.
     For some packages this is the default anyhow.  Most packages will
refuse to execute complex 
     commands or commands containing wildcards, because of the security
holes this opens.

`E'
     This command takes no arguments.  It means that the command should be
processed with the 
     `execve' system call.  For some packages this is the default anyhow.

`M status-file'
     This command means that instead of mailing a message, the message
should be copied to the named 
     file on the system named by the `U' command.

`# comment'
     This command is ignored, as is any other unrecognized command.

Here is an example.  Given the following command executed on system test1
         uux - test2!cat - test2!~ian/bar !qux '>~/gorp'
(this is only an example, as most UUCP systems will not permit the cat
command to be executed) Taylor UUCP will produce something like the
following `X.'  file:
     U ian test1
     F D.test1N003r qux
     O /usr/spool/uucppublic test1
     F D.test1N003s
     I D.test1N003s
     C cat - ~ian/bar qux
The standard input will be read into a file and then transferred to the
file `D.test1N003s' on system `test2'.  The file `qux' will be transferred
to `D.test1N003r' on system `test2'.  When the command is
executed, the latter file will be copied to the execution directory under
the name `qux'.  Note that since the file `~ian/bar' is already on the
execution system, no action need be taken for it.  The standard
output will be collected in a file, then copied to the directory
`/usr/spool/uucppublic' on the system `test1'.


@EOT:

--- WinPoint 0.2.08 Alpha