Return to history.ms CVS log

Up to [Research Unix] / researchv10dc / vol2 / uucp

Annotation of researchv10dc/vol2/uucp/history.ms, revision 1.1

1.1     ! root        1: .so ../ADM/mac
        !             2: .XX 45 649 "UUCP \(em The Program That Wouldn't Go Away"
        !             3: .nr dP 2
        !             4: .nr dV 3p
        !             5: .EQ
        !             6: delim @@
        !             7: .EN
        !             8: .TL
        !             9: UUCP \(em The Program That Wouldn't Go Away
        !            10: .AU
        !            11: Peter Honeyman
        !            12: .AI
        !            13: Princeton University
        !            14: Princeton, New Jersey 08544
        !            15: .AU
        !            16: Dave Nowitz
        !            17: .AI
        !            18: AT&T Bell Laboratories
        !            19: Murray Hill, New Jersey 07974
        !            20: .AU
        !            21: Brian E. Redman
        !            22: .AI
        !            23: Bell Communications Research
        !            24: Whippany, New Jersey 07981
        !            25: .AB
        !            26: .PP
        !            27: The
        !            28: .UX
        !            29: to
        !            30: .UX
        !            31: Copy Program (\fIUUCP\fP) embodies many good ideas for
        !            32: an inexpensive file transfer and remote execution network;
        !            33: however, the current implementation is over five years
        !            34: old and is troubled by many problems.
        !            35: .PP
        !            36: This paper describes a new implementation.
        !            37: The main goals were to
        !            38: make UUCP more robust, secure, powerful, and
        !            39: maintainable.
        !            40: The major activities were:
        !            41: .RS
        !            42: .RS
        !            43: .IP \(bu
        !            44: A massive code reduction.
        !            45: Four core programs comprise the system:
        !            46: .I
        !            47: uucp, uucico, uux,
        !            48: .R
        !            49: and
        !            50: .I
        !            51: uuxqt.
        !            52: .R
        !            53: Code that did not directly implement the
        !            54: purpose of these programs was excised.
        !            55: .IP \(bu
        !            56: The connection algorithm was rewritten to persevere in the face of
        !            57: adversity and to provide a mechanism that enables the administrator
        !            58: to incorporate new calling devices easily.
        !            59: .IP \(bu
        !            60: The spooling mechanism was replaced with one that hashes the queued
        !            61: files by remote system name.
        !            62: .IP \(bu
        !            63: The USERFILE syntax was discarded and replaced by an extremely flexible
        !            64: and intelligible mechanism with practical (secure) defaults.
        !            65: .IP \(bu
        !            66: The code was reviewed and modified
        !            67: to meet the authors' standards for programming style, robustness, and
        !            68: maintainability.
        !            69: .RE
        !            70: .RE
        !            71: .AE
        !            72: .2C
        !            73: .NH
        !            74: History
        !            75: .PP
        !            76: UUCP was invented by Mike Lesk
        !            77: in 1976.
        !            78: He required a transport mechanism to build an automated software distribution
        !            79: package|reference(lesk proposal 1977)|reference(lesk cohen 1977)|reference(asd koenig)
        !            80: upon.  However it became
        !            81: clear that UUCP required (and deserved) considerable follow-up
        !            82: activity and it, the tool, became the focus of attention rather than
        !            83: the original job for which it was designed.
        !            84: .PP
        !            85: The first version of UUCP was approximately 4000 lines of code.
        !            86: It was limited to transferring files, although in fact it included
        !            87: a remote execution facility to invoke \fIuucp\fR on remote systems in
        !            88: some syntactically special cases.
        !            89: Its major failing (even for its time) was that its access mechanism was too
        !            90: simplistic.  It would connect to a remote system and login
        !            91: with a standard interactive shell.  It would then issue commands
        !            92: on the remote system such as \fIcopyin\fR and \fIcopyout\fR to effect
        !            93: transfers.
        !            94: Although an attempt to hide the remote system's phone number, login and
        !            95: password was
        !            96: provided in the code, anyone
        !            97: who installed UUCP was privy to such information, and a careless
        !            98: administrator could easily make it public.
        !            99: .PP
        !           100: The second version of
        !           101: UUCP|reference(v7man nowitz lesk)|reference(nowitz v7man implementation)|reference(nowitz lesk unix network 1982)
        !           102: readdressed the security
        !           103: concerns. It also provided new features including a general
        !           104: remote execution facility, a packet driver, and administrative aids.
        !           105: This version (@approx@ 6800 lines) was distributed with Seventh Edition
        !           106: .nr FL 4i
        !           107: .UX
        !           108: and instantly
        !           109: became invaluable to the
        !           110: .nr FL 5.5i
        !           111: .UX
        !           112: user community.  The second version
        !           113: of UUCP is the version in use today with minor differences
        !           114: among various flavors of
        !           115: .UX .
        !           116: .PP
        !           117: Lots of
        !           118: .UX
        !           119: systems means lots of UUCP nodes sending lots of
        !           120: data  (mail, netnews|reference(usenet byte), and other information)
        !           121: to lots of other
        !           122: .UX
        !           123: systems.
        !           124: The sheer volume of work that
        !           125: UUCP was required to handle taxed its engineered limits
        !           126: beyond its capabilities.  Stu Feldman has compared it to a bicycle bridge
        !           127: over which tanks must now cross.
        !           128: .NH
        !           129: Introduction
        !           130: .PP
        !           131: Here we present a brief description of how UUCP works from a
        !           132: functional point of view.  Those familiar with UUCP's internals
        !           133: might skip this section. 
        !           134: .PP
        !           135: UUCP is a system composed of four principal programs and
        !           136: several administrative support programs.  The core programs
        !           137: are \fIuucp\fR, \fIuucico\fR, \fIuux\fR, and \fIuuxqt\fR*.
        !           138: .FS
        !           139: *The names are pronounced by sounding the name of each letter.
        !           140: .FE
        !           141: Administrative programs
        !           142: include \fIuuclean\fR, \fIuulog\fR, \fIuustat\fR and possibly others depending
        !           143: upon which strain of the second version you look at.
        !           144: The system provides a mechanism to
        !           145: move data among computers and optionally to invoke commands remotely
        !           146: upon the transferred data.
        !           147: .PP
        !           148: The \fIuucp\fR command behaves much like the standard
        !           149: .UX
        !           150: copy command, \fIcp\fR.
        !           151: While \fIcp\fR will only copy files on the same machine,
        !           152: \fIuucp\fR will copy files
        !           153: among machines.  \fIUucp\fR is a batch mode command that
        !           154: queues requests for copying.
        !           155: The \fIuucp\fR command
        !           156: creates files in the \fIuucp spool directory\fR that specify the
        !           157: user's request.
        !           158: \fIUucp\fR generates two types of files:
        !           159: \fIcommand file\fRs (whose names are prefixed with \fIC.\fR) and
        !           160: the \fIdata file\fRs
        !           161: (prefixed with \fID\fR.).
        !           162: Each \fIuucp\fR command will generate as few as one
        !           163: command file and a data file for each file that
        !           164: the user has requested to be transferred.
        !           165: The command file
        !           166: specifies whether this is a request to send files to a remote system
        !           167: or to receive them and contains information regarding the
        !           168: name of the target files, the user and various options.
        !           169: The data file contains the information to be transferred.
        !           170: .PP
        !           171: The \fIuux\fR command also
        !           172: queues requests in the spool directory.
        !           173: It
        !           174: generates an additional type of file, the \fIexecution
        !           175: file\fR.
        !           176: This file contains information required for
        !           177: remote command execution,
        !           178: and includes the name of the command,
        !           179: input and output specifications, and other information relevant to
        !           180: the treatment of the remotely executed command's status.
        !           181: On the local system, it is treated as a data file.
        !           182: \fIUux\fR also creates
        !           183: data files containing information required by the commands
        !           184: to be executed remotely
        !           185: and a command file to specify the transfer of the data files
        !           186: described.
        !           187: .PP
        !           188: The \fIuucico\fR program is the workhorse of UUCP.
        !           189: While \fIuux\fR and \fIuucp\fR
        !           190: merely queue work into the spool directory, \fIuucico\fR
        !           191: examines the spool directory and enacts the transfer of data
        !           192: as dictated by the command files.  A simplistic view of \fIuucico\fR is:
        !           193: .IP
        !           194: Connect to remote system.
        !           195: .IP
        !           196: Cycle through command files and send or receive data as prescribed.
        !           197: .IP
        !           198: Allow remote system to send or receive files if it has command files
        !           199: for the local system.
        !           200: .IP
        !           201: Hang up.
        !           202: .IP
        !           203: Invoke \fIuuxqt\fR to process execution files that have been received.
        !           204: .PP
        !           205: The \fIuuxqt\fR program performs the execution of remotely specified
        !           206: commands.
        !           207: We noted that \fIuux\fR creates data files to be transferred
        !           208: to the remote.
        !           209: The special data file that specifies the command to be executed
        !           210: is renamed when it is copied to the remote to indicate that it is an
        !           211: execution file. 
        !           212: \fIUuxqt\fR searches
        !           213: the spool directory for execution files
        !           214: (whose names begin with
        !           215: .CW X. )
        !           216: and operates upon them.
        !           217: These files contain the command to be executed, indicate which
        !           218: other files are to be used in conjunction with the command, and
        !           219: determine the fate of the output of said command.
        !           220: .NH
        !           221: Problems
        !           222: .PP
        !           223: The second version of UUCP served mostly as a base upon which
        !           224: many many variations were built.
        !           225: The multiplicity
        !           226: was in response to the problems associated with the second version.
        !           227: Its extraordinary use caused many bugs and design flaws to surface.
        !           228: We will discuss these problems and some earlier attempts
        !           229: to rectify them.  The section after will describe the solutions
        !           230: implemented in our (the third) version of UUCP.
        !           231: .NH 2
        !           232: Performance
        !           233: .PP
        !           234: The major issue here revolves around a problem of positive feedback.
        !           235: UUCP depends heavily upon the
        !           236: .UX
        !           237: file system.  The location of data within
        !           238: the file system and the names of the files containing data impart
        !           239: specific knowledge to UUCP.  The second version of UUCP uses a
        !           240: single directory to store its command files, data files, execution
        !           241: files, lock files, temporary files, etc.  On a smoothly running
        !           242: heavily trafficked system, the numbers of these files will typically
        !           243: range in the hundreds.  The searching of large directories is performed
        !           244: inefficiently in
        !           245: .UX *.
        !           246: .FS
        !           247: *This is representative of some of
        !           248: .UX `s
        !           249: controversial
        !           250: design decisions.  It does the job in a straightforward manner which
        !           251: is usually quite suitable.
        !           252: Although there are admittedly pathological cases
        !           253: which are problematic, the operating system was not contorted
        !           254: to handle them specially.
        !           255: Usually reevaluation of their design will indicate a more
        !           256: appropriate solution.
        !           257: .FE
        !           258: Accessing data files or information relevant to such files involved
        !           259: locating the name of the file (a directory search) and then checking
        !           260: the status of the file (another directory search).
        !           261: The time to perform these operations is then
        !           262: quadratic in the number of directory entries.
        !           263: The performance degradation due to manipulating files in very large
        !           264: directories results in the following common scenario.
        !           265: .IP
        !           266: UUCP connects to a remote system.
        !           267: .IP
        !           268: It then begins to search the spool directory for work files relevant
        !           269: to this session.  This takes an inordinate amount of time.
        !           270: .IP
        !           271: The remote system times out waiting for UUCP to indicate its intentions.
        !           272: It disconnects.
        !           273: .IP
        !           274: UUCP finally completes its task, finds that the remote is no longer
        !           275: connected and hangs up.
        !           276: .IP
        !           277: Some time later the cycle is repeated.
        !           278: .PP
        !           279: This positive feedback loop consumes large amounts of resources
        !           280: yet produces no work.
        !           281: The problem becomes worse as more and more
        !           282: requests are placed in the spool directory.
        !           283: This then fatally cripples
        !           284: UUCP.  In order to get the system working again, the administrator
        !           285: chooses between time-consuming, tedious, error-prone manipulations (create a new
        !           286: spool directory and slowly feed data and work files into it at
        !           287: a rate no greater than they are processed) and merely
        !           288: deleting all the queued files (with the obvious effects of lost data).
        !           289: .PP
        !           290: There are several reasons why the spool directory may become very large.
        !           291: A remote system may be unavailable for an extended period of time while
        !           292: work continues to be spooled for it.
        !           293: A site may act as a central distribution point for large volumes of information
        !           294: to many other systems.
        !           295: The addition of more nodes may provide the straw that breaks UUCP.
        !           296: A system may find itself short on cycles on a given day and the extended
        !           297: time required to process work may provide the stimulus to begin a positive
        !           298: feedback cycle.
        !           299: Once the syndrome is displayed, the situation deteriorates.
        !           300: As the number of UUCP sites grows and the amount of information transferred
        !           301: increases this effect becomes more probable.
        !           302: .PP
        !           303: There have been various attacks on this problem.  Some address only the
        !           304: symptoms, others merely postpone its onset.
        !           305: They include:
        !           306: .IP
        !           307: The initial approach:  To increase the amount of time a system will
        !           308: wait until it decides to give up.  This does just that.
        !           309: .IP
        !           310: The automatic recovery approach:
        !           311: A set of programs to move the spool directory, recreate it, and
        !           312: add the files back in the correct order for processing.  It typically takes
        !           313: several days to set things right again (until the next time).
        !           314: .IP
        !           315: The approach in 4.2bsd (credited to Tom Truscott):  Separate the spool
        !           316: directory into subdirectories, one each for command files, data files,
        !           317: and execution files.  This reduces the probability of a blockage or
        !           318: postpones its occurrence because each directory is somewhat smaller.
        !           319: However potential for problems remains as great.
        !           320: .IP
        !           321: A method we used on a major information distribution hub:
        !           322: We recompiled the
        !           323: UUCP programs with different spool directories for each of the
        !           324: sites to which we distribute.
        !           325: The distribution software used the appropriate version
        !           326: of \fIuucico\fR.
        !           327: The \fIlogin shell\fR for each of the affected systems was
        !           328: determined likewise.  The major drawback was the number of copies of
        !           329: UUCP programs required.
        !           330: Also, some work was spooled in special directories
        !           331: and other jobs were spooled in the main spool directory because
        !           332: of the desire not to change the programs that use UUCP.
        !           333: Although this might seem advantageous (netnews in one directory, mail
        !           334: in another) when the remote system called us, we only processed the work in
        !           335: the special spool directory.  Both spool directories were used when we called out.
        !           336: .NH 2
        !           337: Security
        !           338: .PP
        !           339: The second version of UUCP presented mechanisms that enabled
        !           340: the system to be secure, but they were poorly understood
        !           341: and were usually ignored.
        !           342: These mechanisms  were also not flexible enough
        !           343: to enforce security where it was needed and omit it from where it
        !           344: wasn't.
        !           345: .PP
        !           346: The second version dealt with security on three fronts.
        !           347: .PP
        !           348: 1)
        !           349: The login shell for UUCP was not a general purpose shell, and
        !           350: only a complex program (i.e., UUCP) could make use of this access.
        !           351: .PP
        !           352: 2)
        !           353: By previous arrangement any
        !           354: communicating systems could share a sequence number which was incremented for
        !           355: each session.
        !           356: This required that an imposter not only know the login
        !           357: and password, but the sequence number as well.
        !           358: A penetration would be discovered as the legitimate system would now be
        !           359: out of synch.
        !           360: .PP
        !           361: 3)
        !           362: The USERFILE was not administrator
        !           363: friendly.
        !           364: It provided four types of constraint.
        !           365: .IP [1]
        !           366: Files accessible by a normal user of the local system.
        !           367: .IP [2]
        !           368: Which files can be accessed from a remote system.
        !           369: .IP [3]
        !           370: Login name used by a remote system.
        !           371: .IP [4]
        !           372: Whether a remote system should be called back in order to confirm
        !           373: its identity.
        !           374: .PP
        !           375: The special login shell was the most important development.
        !           376: That allowed
        !           377: access restricted to and by the UUCP programs.
        !           378: The sequence file facility, to the best of our
        !           379: knowledge, has never been used other than to test its capabilities.
        !           380: Its lack of use must be blamed on inadequate documentation.
        !           381: We considered removing it from our rewrite but
        !           382: felt that it may still prove valuable.
        !           383: The USERFILE concept provided a good base but was not flexible enough
        !           384: for the various environments in which it would be used.
        !           385: It could not grant
        !           386: different access to files depending
        !           387: upon whether they were to be read or written (many systems are not willing
        !           388: to allow data to escape, but eagerly accept contributions).  It lacked
        !           389: an ``all but'' syntax.
        !           390: It vainly attempted to restrict local users' access.
        !           391: Normal
        !           392: .UX
        !           393: file access
        !           394: mechanisms were satisfactory in this regard.
        !           395: We provide new semantics
        !           396: and a significantly improved syntax which is discussed later on.
        !           397: .PP
        !           398: Recently another version of UUCP* was developed at AT&T Bell Labs|reference(morris try uucp)|reference(morris maintaining uucp)
        !           399: whose main thrust was to address the security aspects.
        !           400: .FS
        !           401: * It is not our purpose to completely describe it but to point to
        !           402: some examples of alternate approaches.
        !           403: .FE
        !           404: Systems may not request files nor can files be received at destinations
        !           405: other than a public directory and an additional directory provided as a
        !           406: sort of secured receiving dock.
        !           407: Although it does well in its attempt to tighten up security, it takes a
        !           408: rather severe approach that can get in the way of users in a casual
        !           409: environment.
        !           410: .NH 2
        !           411: Obsolescence
        !           412: .PP
        !           413: The second version of UUCP was designed for two types
        !           414: of communications media,
        !           415: the Bell 801C/212A type Automatic Calling Unit (ACU) and modem hardware,
        !           416: and direct hardwired lines.
        !           417: The code was simply implemented as:
        !           418: .P1 0
        !           419: if (ACU)
        !           420:    call(flds); /* use the 801/212 */
        !           421: else
        !           422:    direct(flds); /* just open the device */
        !           423: .P2
        !           424: .PP
        !           425: Code was later added for some special network apparatus
        !           426: (DATAKIT).
        !           427: This was patched in with conditional compilation.
        !           428: Incorporation of new calling hardware was messy
        !           429: and error-prone.
        !           430: .PP
        !           431: The mechanism that UUCP provided
        !           432: for negotiating a connection with a remote system (expect this, send that, ...)
        !           433: was not general enough.
        !           434: For example, each token sent out was terminated by a newline character.
        !           435: As port selectors of various
        !           436: flavors became more prevalent, their idiosyncrasies became more
        !           437: troublesome.
        !           438: It was not uncommon to be required to present them
        !           439: with arbitrary characters, delays of varying duration,
        !           440: or tokens that did not end in newline.
        !           441: One accepted only an even parity carriage return.
        !           442: These capabilities were
        !           443: difficult or impossible to provide without changing the code.
        !           444: Therefore new syntaxes and special tokens were invented as the
        !           445: need arose that led to a variety of incompatible connection descriptions.
        !           446: Even if the hardware worked properly, there was a significant
        !           447: probability that the connection would fail to be completed.
        !           448: .PP
        !           449: Most recent fixes to UUCP addressed the token problem, though
        !           450: few used the same conventions and many were lacking
        !           451: some key capability or another.  The addition of new hardware was generally
        !           452: handled with conditional compilations and new keywords were invented as
        !           453: needed.
        !           454: Several systems implemented connection routines
        !           455: as a general library function, isolating, but not resolving, the problems.
        !           456: .NH 2
        !           457: Limitations
        !           458: .PP
        !           459: When UUCP was designed several decisions had to be made based on
        !           460: anticipated usage.
        !           461: Many of the practical limits imposed have been exceeded.
        !           462: The greatest problems occur in the area of array sizes.
        !           463: UUCP handles all sorts of arrays that represent
        !           464: commands, users, files and systems.
        !           465: At a time when most sites could be easily connected with all others
        !           466: the limit of 64 characters easily accommodated an electronic mail
        !           467: address.
        !           468: But the network has grown quite wide and such addresses often
        !           469: exceed two hundred characters.
        !           470: Some versions of
        !           471: .UX
        !           472: permit login names that exceed the standard restrictions on the number
        !           473: of characters.
        !           474: These developments require changes to the limits imposed by UUCP.
        !           475: .PP
        !           476: Some limits were imposed due to system design constraints.
        !           477: The name of a site was restricted to seven characters because
        !           478: it was encoded into file names along with a two character type
        !           479: prefix, a grade consisting of one character and four characters making
        !           480: up a sequence number.
        !           481: It is becoming increasingly difficult, with thousands of sites,
        !           482: to select mnemonic names with this limitation.
        !           483: The problem is becoming more severe as
        !           484: .UX ,
        !           485: and therefore UUCP, usage grows explosively.
        !           486: .NH 2
        !           487: Error Handling
        !           488: .PP
        !           489: UUCP often becomes totally frustrated when erroneous data is
        !           490: presented to it.
        !           491: It is common that a command file will be created with invalid
        !           492: fields and \fIuucico\fR will unexpectedly abort in an attempt
        !           493: to process it.
        !           494: All subsequent invocations of \fIuucico\fR exhibit the same
        !           495: behavior until the bad file is manually removed.
        !           496: Such files are created in the first place because UUCP fails to
        !           497: check the return status of critical \fIwrite\fR system calls.
        !           498: They are allowed to impede the system because there is seldom
        !           499: any attention paid to the values returned from \fIread\fR.
        !           500: When a system runs out of disk space
        !           501: (which systems very often do),
        !           502: failing \fIwrite\fRs go unnoticed yet files appear to be transferred
        !           503: successfully.
        !           504: Data is lost with no error indication whatsoever.
        !           505: .NH 2
        !           506: Inconsistency
        !           507: .PP
        !           508: Because of the problems described above UUCP has been modified
        !           509: by many systems maintainers.
        !           510: Modifications include necessary bug fixes required for normal use,
        !           511: enhancements required by users with special needs, and changes
        !           512: to make the system more robust.
        !           513: Significant work has been 
        !           514: done at Rand, AT&T Bell Labs,
        !           515: ITT, UC Berkeley, Duke and many others.
        !           516: Unfortunately the various
        !           517: versions represent different solutions to the same problems and
        !           518: they are sometimes incompatible.
        !           519: For example the syntaxes used to specify
        !           520: scripts for connections have been vastly different.
        !           521: Since few versions are alike, enhancements
        !           522: and fixes
        !           523: won't apply to another version and
        !           524: will be of limited value to the overall community.
        !           525: This is especially frustrating when good solutions are presented
        !           526: but not widely accepted because of the cost of providing a different
        !           527: implementation.
        !           528: .NH 2
        !           529: Administration
        !           530: .PP
        !           531: The second version of UUCP is difficult to administer.
        !           532: It introduced two administrative tools, \fIuuclean\fR and \fIuulog\fR,
        !           533: and others have come about since.
        !           534: But these programs are not sufficient and there are problems with them.
        !           535: .PP
        !           536: \fIUuclean\fR was introduced to aid the administrator by
        !           537: cleaning up after UUCP.
        !           538: It would find old files (temporaries, spooled
        !           539: requests, etc.), remove them and optionally notify a user.
        !           540: However, deleting old files is not always the best approach.
        !           541: Often such files represented precious data that could not be regenerated.
        !           542: The algorithm for notification would often inform an inappropriate
        !           543: user of the deletion.
        !           544: Even if the appropriate
        !           545: person was notified, the information contained in the notification was
        !           546: cryptic and unuseful.  For example:
        !           547: .P1 0
        !           548: file D.fooAD1234 removed after two weeks.
        !           549: Could not contact remote.
        !           550: .P2
        !           551: .PP
        !           552: UUCP kept log information in a single file.
        !           553: If that file was busy, a process would use a temporary log file instead.
        !           554: The access modes of the temporaries indicated whether or not the
        !           555: process that owned them was still active.
        !           556: If they were not active, then \fIuulog\fR consolidated them into the main
        !           557: log file.
        !           558: However its purpose was often defeated because UUCP processes that terminated
        !           559: abnormally did not mark the temporaries for consolidation.
        !           560: \fIUuclean\fR would then come along and eradicate information
        !           561: that would have been useful for debugging.
        !           562: \fIUulog\fR also had options to find log information about a system or a user.
        !           563: This function is more easily performed by \fIgrep\fR and \fIsed\fR.
        !           564: With the enhanced second version of UUCP introduced with
        !           565: .UX
        !           566: 3.0
        !           567: (System III) came the \fIuustat\fR command.  This was a good attempt at a program to
        !           568: aid administration and enhance the user's capabilities for control and
        !           569: access.  Unfortunately its implementation was weak, requiring many
        !           570: hooks into UUCP and acting as another fragile link in the
        !           571: increasingly unstable system.
        !           572: .NH 2
        !           573: Code Maintenance
        !           574: .PP
        !           575: One of the problems associated with any large system is maintaining
        !           576: the source code.  This problem is aggravated in UUCP because it has
        !           577: been an extremely dynamic system (as measured by the number of Modification
        !           578: Requests entered for it).
        !           579: The coding responsibility is no longer with
        !           580: the designers, but has been assigned to programmers (over the past
        !           581: several years) with differing experience levels.  The source code is scarred
        !           582: by the many hands that have operated on it.  As early as 1980,
        !           583: individuals responsible
        !           584: for UUCP 
        !           585: were hesitant to make any changes because
        !           586: it had become ``too big a mess and was too difficult to maintain''.  Despite
        !           587: this attitude, UUCP continued to be fixed, enhanced,
        !           588: and otherwise modified, and grew ever more unmaintainable.
        !           589: .NH
        !           590: The Solutions
        !           591: .PP
        !           592: .NH 2
        !           593: Site Name Hashing
        !           594: .PP
        !           595: The rationale for reorganizing UUCP's data into separate directories
        !           596: has been described.
        !           597: However it later became apparent that this
        !           598: technique was not necessary to deal with the intended problem.
        !           599: Some technical understanding of
        !           600: .UX
        !           601: is required to fully appreciate the following.
        !           602: The culprit that caused the quadratic behavior in the second version
        !           603: of UUCP was a gratuitous \fIstat\fR system call placed in a procedure
        !           604: that searched for command files.
        !           605: This function read the name of each file from the spool directory.
        !           606: It checked that the file had the proper prefix and
        !           607: then used \fIstat\fR to determine if it was publicly readable.
        !           608: UUCP created command files write-only (mode 0200) by the uucp login and
        !           609: changed them to be publicly readable when they were complete.
        !           610: This prevented the system from using partially written files.
        !           611: Since the file was \fIwrite-only\fR, an open for reading by the
        !           612: search function would fail.
        !           613: The use of \fIstat\fR was presumably an additional check to back up
        !           614: the normal system access mechanism.
        !           615: As the code was revised, the \fIstat\fR became an \fIaccess\fR, and that
        !           616: eventually disappeared without fanfare.
        !           617: Directory searching within UUCP became virtually linear with respect
        !           618: to the size of the directory.
        !           619: (Multiple processes encountered directory locking phenomena.)
        !           620: In retrospect it
        !           621: appears obvious that that was the
        !           622: solution to the critical performance problem.
        !           623: But before that was realized separate spool directories had been
        !           624: implemented.  The other benefits of such a design justify its existence.
        !           625: .PP
        !           626: Data files representing a particular remote system are now
        !           627: placed in a directory with the same name as the remote system.
        !           628: This name is stored in a global variable.
        !           629: The UUCP programs that access these files change
        !           630: their working directory into the directory associated with
        !           631: the remote system and perform their operations there.
        !           632: This is in effect a simple hashing algorithm.
        !           633: It improves access time, especially for heavily loaded systems.
        !           634: It also provides a convenient structure for data storage that
        !           635: is taken advantage of by programs and by people.  For example if you want
        !           636: to know how many files are destined for a system named \fIsfwoo\fR,
        !           637: you could:
        !           638: .P1 0
        !           639: wc -c /usr/spool/uucp/sfwoo/C*
        !           640: .P2
        !           641: It is also advantageous to know that
        !           642: files in a system's directory were put there either by the given system or by
        !           643: the local UUCP.  This bit of knowledge will be exploited later
        !           644: in the discussion of security mechanisms.
        !           645: .PP
        !           646: Another outgrowth of separate spool directories is the notion
        !           647: of parallel remote execution processing.
        !           648: The process that executes commands on behalf of remote systems (\fIuuxqt\fR)
        !           649: finds work in separate directories.
        !           650: Multiple \fIuuxqt\fRs
        !           651: can execute simultaneously, one per remote.
        !           652: This is a reasonable compromise
        !           653: between the limit of one invocation of \fIuuxqt\fR per local system and
        !           654: the possibility of one per X. file.
        !           655: We provide
        !           656: optional limiting so that a machine can support useful work in addition to
        !           657: handling mail and netnews.
        !           658: .NH 2
        !           659: Site Name Limitations
        !           660: .PP
        !           661: The name of a site is no longer encoded in the file name.
        !           662: The location of the file in the directory structure implies the site.
        !           663: All C. files in
        !           664: .CW /usr/spool/uucp/fugit
        !           665: are work files for the system named \fIfugit\fR,
        !           666: all X. files in
        !           667: .CW /usr/spool/uucp/gummo
        !           668: are remote
        !           669: execution requests from the system named \fIgummo\fR, etc.
        !           670: This means that site names need no
        !           671: longer be limited by seven (or six in some versions) characters.
        !           672: Since the directory name is the limiting factor, site names of
        !           673: up to fourteen characters are permitted.
        !           674: We have tried to isolate this limitation to a single manifest constant.
        !           675: Thus systems which support longer file names may allow site names of greater
        !           676: length.
        !           677: Perhaps future versions will use the directory name as a pointer
        !           678: to the real site name.
        !           679: Even conservative use of the character set would allow over
        !           680: @ 64 sup 14 @ different names.
        !           681: This added flexibility (increasing
        !           682: the name space) has some controversial ramifications which are discussed
        !           683: further on.
        !           684: .NH 2
        !           685: Security
        !           686: .PP
        !           687: Our goal with respect to UUCP security was to make the mechanisms robust,
        !           688: flexible and usable.
        !           689: Robustness was achieved by fixing bugs, plugging holes,
        !           690: being careful in designing and coding our revisions,
        !           691: and thorough testing under a variety of operating conditions.
        !           692: Flexibility and usability came together in what is known as the
        !           693: \fIPermissions\fR file.
        !           694: .PP
        !           695: The \fIPermissions\fR file replaces the \fIUSERFILE\fR of the second version of
        !           696: UUCP.
        !           697: Its purpose is to support a mechanism for clearly and flexibly
        !           698: stating what restrictions apply to or what permissions are granted to
        !           699: the sites with which the local UUCP system communicates.
        !           700: It is located in the UUCP library directory and
        !           701: contains statements which customize the behavior of UUCP for any or all
        !           702: systems by identifying them with the login name they use or their site name.
        !           703: The statements described are
        !           704: used in conjunction with two basic types of entries which
        !           705: are
        !           706: .P1
        !           707: LOGNAME=
        !           708: .P2
        !           709: for remotely initiated connections and
        !           710: .P1
        !           711: MACHINE=
        !           712: .P2
        !           713: for locally initiated connections.
        !           714: There must be a LOGNAME= statement for each login that might be used
        !           715: by a remote system.
        !           716: The minimal contents of the
        !           717: \fIPermissions\fR file is:
        !           718: .P1 0
        !           719: LOGNAME=uucp
        !           720: .P2
        !           721: This specifies that a remote system may login as \fIuucp\fR and will be
        !           722: restricted by the defaults.
        !           723: .PP
        !           724: The permissions fall into three basic categories:
        !           725: file system access,
        !           726: command execution,
        !           727: and identity verification.
        !           728: .PP
        !           729: File system access permissions dictate which directories a remote system
        !           730: may access for reading, and, separately, which may be accessed for writing.
        !           731: This is done by specifying any combination of the keywords
        !           732: .CW READ ,
        !           733: .CW WRITE ,
        !           734: .CW NOREAD ,
        !           735: and
        !           736: .CW NOWRITE
        !           737: followed by a
        !           738: .CW :
        !           739: separated list of directories.
        !           740: In the example:
        !           741: .P1 0
        !           742: READ=/usr/ber:/usr/honey:/usr/dan \e
        !           743:    WRITE=/tmp NOREAD=/usr/ber/secret
        !           744: .P2
        !           745: a system can read any files
        !           746: that the UUCP login can access
        !           747: in the directories
        !           748: .CW /usr/ber ,
        !           749: .CW /usr/honey ,
        !           750: and
        !           751: .CW /usr/dan
        !           752: except those files in
        !           753: .CW /usr/ber/secret .
        !           754: It can also write into any file in
        !           755: .CW /tmp .
        !           756: .PP
        !           757: The command execution permissions specify commands that can be invoked.
        !           758: .P1 0
        !           759: COMMANDS=rnews:lpr:opr:rmail
        !           760: .P2
        !           761: shows that the site associated with this line can execute any of the
        !           762: listed commands and no others.
        !           763: If a path name is specified then it
        !           764: must match the command requested by the remote system exactly.
        !           765: .PP
        !           766: Identity verification is accomplished in a variety of ways.
        !           767: .CW CALLBACK=yes
        !           768: is most restrictive.
        !           769: It requires that when the remote system calls, it
        !           770: must hang up and wait for the local system to return the call.
        !           771: This provides 
        !           772: the greatest assurance that we are communicating with the correct party.
        !           773: .PP
        !           774: .CW SENDFILES=no
        !           775: prevents the \fImaster/slave\fR protocol from being
        !           776: reversed when the remote system calls.
        !           777: The result is that although the local site may
        !           778: have data queued for the remote site, it will not transmit it if the
        !           779: remote system originates the call.
        !           780: This is slightly less restrictive
        !           781: than
        !           782: .CW CALLBACK=yes .
        !           783: .PP
        !           784: .CW REQUEST=no
        !           785: indicates that the remote site may not request files from us under
        !           786: any circumstance.
        !           787: In order to receive files the remote user must
        !           788: have an agent on the local site to initiate the transfer.
        !           789: This restriction applies no matter who calls whom.
        !           790: .PP
        !           791: Finally, when
        !           792: .CW VALIDATE=
        !           793: appears, the specified systems must have
        !           794: logged in using one of the associated logins indicated.
        !           795: For example:
        !           796: .P1 0
        !           797: LOGNAME=Umarx VALIDATE=chico:harpo:zeppo
        !           798: .P2
        !           799: will cause UUCP to terminate the conversation if \fIchico\fR, \fIharpo\fR or
        !           800: \fIzeppo\fR log in with a name other than \fIUmarx\fR.
        !           801: .PP
        !           802: The default permissions are:
        !           803: .P1 0
        !           804: LOGNAME=uucp \e
        !           805:   WRITE=/usr/spool/uucppublic \e
        !           806:   REQUEST=no SENDFILES=no \e
        !           807:   COMMANDS=rmail:rnews
        !           808: .P2
        !           809: Note that the statement must appear as a single record.  Lengthy statements
        !           810: may be continued with
        !           811: .CW \e .
        !           812: Appendix I is a sample \fIPermissions\fR file,
        !           813: Appendix II is the description emitted from a program that checks the
        !           814: \fIPermissions\fR file (described later).
        !           815: .PP
        !           816: These mechanisms allow a site to implement secure features where
        !           817: they are needed while still allowing considerable flexibility in the
        !           818: treatment of sites based on knowledge attributed to the login method
        !           819: and remote name.
        !           820: This concept allows UUCP to be useful
        !           821: both with tightly coupled well-trusted machines and the loosely
        !           822: coupled less secure dialup network environment.
        !           823: .NH 2
        !           824: A Rational Connection Function
        !           825: .PP
        !           826: The third general area of revision is that of the connection function.
        !           827: The \fIconn\fR of UUCP is a beautiful abstraction that subsumes all the
        !           828: knowledge of setting up a connection to a remote system.
        !           829: It takes as its
        !           830: argument the name of the remote system and returns a file descriptor open for
        !           831: reading and writing to communicate with it.
        !           832: .I conn
        !           833: accounts for
        !           834: over ten percent of the UUCP code.
        !           835: Its function is applicable to
        !           836: any utility that connects to a remote system or resource.
        !           837: Several
        !           838: developers have extracted
        !           839: .I conn
        !           840: from UUCP and provided it as
        !           841: a stand alone facility (\fIdial\fR(3) in System V and \fIdialout\fR(3)
        !           842: in Eighth Edition
        !           843: .UX ).
        !           844: Our implementation is suited to that purpose as well, though
        !           845: .I conn
        !           846: remains bundled with UUCP.
        !           847: .PP
        !           848: The goals in revising
        !           849: .I conn
        !           850: were to bolster its robustness,
        !           851: handle more types of connecting hardware and to provide a
        !           852: mechanism for easily utilizing new hardware.
        !           853: This was done by splitting the hardware-dependent operations from
        !           854: .I conn
        !           855: into two routines.
        !           856: One understands the needs of
        !           857: \fIcallers\fR (e.g., how to interpret the fields in the \fISystems\fR file to them)
        !           858: and deals with locking and bookkeeping.
        !           859: The other understands how to manipulate the hardware to connect to a remote
        !           860: resource (parochially known as dialing).
        !           861: .I Conn
        !           862: uses a table containing the name of each
        !           863: caller (ACU, Micom, TCP, Sytek, etc.) and a pointer to the function
        !           864: that manipulates it.
        !           865: The caller function uses a table of \fIdialers\fR which contains their
        !           866: names (212, Penril, Vadic, etc.), and pointers to the
        !           867: functions that perform dialing.
        !           868: Not all callers have associated dialers.
        !           869: Another way to describe it is that the caller specifies the nature of the
        !           870: network and the dialer dictates the mechanism to access such a network.
        !           871: Thus we find currently that there are many dialers for the ACU caller
        !           872: because there is a variety of hardware to access the Direct Distance Dialing
        !           873: network.
        !           874: But we have only one interface to the DATAKIT network so the calling
        !           875: routine for it may as well (and indeed does) include the dialing function.
        !           876: If alternate interfaces become available then the dialing function will
        !           877: be split out and the caller will be able to choose among them.
        !           878: The enhancement procedure for hardware unknown to us at the time of
        !           879: this writing then entails supplying a new caller and
        !           880: dialer function, updating the tables, and recompiling.
        !           881: .PP
        !           882: Given these tables which contain identifiers, we provide a new
        !           883: syntax for the \fIDevices\fR file (formerly called \fIL-devices\fR) in which the
        !           884: caller hardware and dialer function are specified.  Appendix III, is a sample
        !           885: \fIDevices\fR file, Appendix IV is a sample
        !           886: \fISystems\fR file (formerly \fIL.sys\fR).
        !           887: (\fIL-dialcodes\fR has been renamed \fIDialcodes\fR but is unchanged from previous
        !           888: versions.)
        !           889: Note the existence of a \fIchat\fR script in the \fIDevices\fR file.
        !           890: This is a syntactic convenience used to isolate the differences in various
        !           891: switches so their similarities can be exploited in a
        !           892: generic caller routine.  This helps to clean up the \fISystems\fR file.
        !           893: .PP
        !           894: .I Conn
        !           895: is called with the name of the remote system and
        !           896: behaves as follows:
        !           897: .P1 0
        !           898: .ps -1
        !           899: .vs -1p
        !           900: for each entry in \fISystems\fP that matches the argument
        !           901:     for each caller in \fIDevices\fP that matches this entry
        !           902:         if this caller doesn't need a dialer
        !           903:             attempt to connect
        !           904:             if successful
        !           905:                 return file descriptor
        !           906:         else
        !           907:             for each dialer that can be used with this caller
        !           908:                 attempt a connection using the dialer function
        !           909:                 if successful
        !           910:                     return file descriptor
        !           911: try again later
        !           912: .ps
        !           913: .vs
        !           914: .P2
        !           915: .PP
        !           916: This mechanism allows us to exploit all the alternative
        !           917: hardware at our disposal in an attempt to make a connection.
        !           918: The priorities of the various alternatives are expressed in the
        !           919: ordering of the entries in the \fISystems\fR and \fIDevices\fR files.
        !           920: A subtlety of interest is the use of the \f(CWANY\fR keyword in the \fIclass\fR
        !           921: fields of the \fIDevices\fR file.  This affords more flexibility
        !           922: in determining which connection hardware to use.  For example one may
        !           923: wish to connect to some systems at lower speeds than the hardware is
        !           924: capable of to counteract deficiencies in their terminal drivers.
        !           925: .PP
        !           926: UUCP selects a protocol used to communicate with a remote system.
        !           927: Typically this is the `g' protocol which is a variant of X.25.
        !           928: It uses 64 byte packets and is quite resilient in error-rich environs
        !           929: such as the DDD network.
        !           930: There were also the `x' and `d' protocols for use over
        !           931: X.25 and DATAKIT lines.
        !           932: We have added the
        !           933: `e' protocol (ostensibly for Ethernet),
        !           934: which is suitable for error
        !           935: free transmission media.
        !           936: The packet size is in fact the file size,
        !           937: so the overhead becomes almost negligible.
        !           938: The \fISystems\fR file has been enhanced to provide the ability
        !           939: to specify a preferred protocol depending on the hardware used to initiate
        !           940: the connection.  (We attribute this idea to R. T. Morris|reference(morris maintaining uucp).)
        !           941: .PP
        !           942: A problem with the coding of
        !           943: .I conn
        !           944: is that it nests very deeply in order to
        !           945: establish a connection.
        !           946: The handling of error-returns through intermediate functions
        !           947: was clumsy and not generalized.
        !           948: The use of a single error-indicating variable (\fIUerror\fR)
        !           949: has allowed us to implement the function more cleanly.
        !           950: .NH 2
        !           951: Coping With Bad Data and Inadequate Environments
        !           952: .PP
        !           953: Although the new implementation of UUCP is laudably robust in the creation
        !           954: and transmission of data, it will still have to deal with improperly formatted
        !           955: files that are the result of lesser versions or system errors.
        !           956: When UUCP evaluates a command or execution file it checks that the contents are
        !           957: plausible.
        !           958: When corrupt files are identified, they are moved to a special directory.
        !           959: The administrative daemon checks this directory (\fI.Corrupt\fR)
        !           960: periodically and informs the administrator of its contents.
        !           961: .PP
        !           962: Previous behavior with respect to handling conditions where a system
        !           963: did not have adequate disk space was unacceptable and quite frustrating to
        !           964: the anonymous users who had their data silently lost.
        !           965: The new UUCP checks the level of the file system using the \fIustat\fR system call
        !           966: (an equivalent user level routine is provided for systems lacking \fIustat\fR).
        !           967: A special error code is transmitted to the remote system if there is
        !           968: insufficient space.
        !           969: The event is logged and the conversation is terminated.
        !           970: If UUCP receives this error indication from a system, it will disengage
        !           971: from the conversation assuming that the remote is in trouble.
        !           972: Scans of the log files will reveal these situations and the local administrator
        !           973: may wish to inform the remote counterpart.
        !           974: There has been considerable discussion among the authors about
        !           975: ways to improve the above scenarios.  It is generally agreed that
        !           976: when a system runs out of space it ought to reverse its role and attempt
        !           977: to send data.  If it had run out of space as master it ought to continue
        !           978: scanning work files performing sends and deferring receives.
        !           979: If the system notes that the remote has run out of space, then it ought
        !           980: to scan the command files looking for receives and reverse roles when
        !           981: they are completed.
        !           982: Unfortunately, implementing these actions would be quite
        !           983: complex.  They have been deferred to the wish list.
        !           984: .NH
        !           985: Getting It Up and Keeping It Running
        !           986: .NH 2
        !           987: Configuration
        !           988: .PP
        !           989: This system has been described as a tribute to the C preprocessor.
        !           990: Because our goal was to produce a sound system to which
        !           991: changes would inevitably be applied,
        !           992: compile-time parameterization is ubiquitous.
        !           993: It had to run on a variety of
        !           994: .UX
        !           995: versions and processors.
        !           996: We also found the need for extensive options to express varied
        !           997: preferences.
        !           998: .PP
        !           999: For instance, to compile a system for machines constrained by memory limitations
        !          1000: we have provided a parameter that allows only the most critical debugging
        !          1001: facilities to be included.  This idea of conditional compilation may be
        !          1002: extended to the general case of time/speed tradeoffs.   Many algorithms
        !          1003: are chosen in consideration of the environment in which they will be applied.
        !          1004: But UUCP is used on many different processors by users with varying needs.
        !          1005: Dynamic memory allocation, although costly in time and complexity, may
        !          1006: be appropriate in order to drastically reduce the memory requirements.
        !          1007: Systems running on machines with lots of memory ought to be able to have
        !          1008: larger caches and faster hashing schemes.
        !          1009: .PP
        !          1010: It was also necessary to be able to configure it
        !          1011: to interface with various user programs.
        !          1012: For example,
        !          1013: even though lock files don't belong in UUCP's spool directory, 
        !          1014: in reality some people won't change the other programs that
        !          1015: are affected.
        !          1016: We provided the option for compatibility.
        !          1017: .PP
        !          1018: Another set of problems relegated to the preprocessor concerned opinion and taste.
        !          1019: As the system was developed, there arose
        !          1020: many situations where a new idea was not immediately embraced by all.
        !          1021: Often it was not clear what the correct behavior
        !          1022: should be, as `correctness' was sometimes subjective.
        !          1023: Rather than throw out good (albeit minority opinion) ideas,
        !          1024: or force them on others,
        !          1025: they were compiled in optionally.
        !          1026: Many of these eventually found enough favor to be included unconditionally.
        !          1027: Others were blessed as the default, while some remain debatable.
        !          1028: Parameters likely to be changed out of necessity or preference
        !          1029: have been gathered in one place
        !          1030: (\fIparms.h\fR) for easy identification and manipulation.
        !          1031: .NH 2
        !          1032: Installation
        !          1033: .PP
        !          1034: UUCP has become less straightforward in its use of the file system and
        !          1035: more dependent upon various files to enhance its flexibility.
        !          1036: It is more important than ever to aid the user in the installation
        !          1037: process.
        !          1038: Although the programs have been designed to fall back
        !          1039: on sensible defaults if some files are not present (such as \fIMaxuuqts\fR
        !          1040: which potentially limits the number of simultaneous \fIuuxqt\fRs),
        !          1041: other files
        !          1042: and directories are too critical to do without (e.g., \fISystems\fR).
        !          1043: And for many the modes are quite important (imagine a spool directory only writable
        !          1044: by root).
        !          1045: Since this version is significantly different,
        !          1046: current working data must be converted to conform to the required
        !          1047: formats.  A comprehensive \fImakefile\fR provides the basis
        !          1048: for installation (we thank those who were then 6.0 developers).
        !          1049: A conversion shell script is provided as well as a program
        !          1050: (\fIuucheck\fR) that verifies the installation and the integrity of the various
        !          1051: files used by UUCP as well as optionally interpreting their contents
        !          1052: to the user in very descriptive terms (i.e., system so-and-so can do
        !          1053: such-and-such and is restricted from this-and-that).
        !          1054: See Appendix II.
        !          1055: Ideally a recipient of this package will be able to edit the
        !          1056: parameter file, and type
        !          1057: ``make install'' to generate a working system.
        !          1058: .NH 2
        !          1059: Maintenance
        !          1060: .PP
        !          1061: Although we have provided tools to get the system
        !          1062: up and running, it's at least as important to help keep
        !          1063: the system running smoothly.
        !          1064: Due to the anarchic and volatile nature of the network that UUCP supports,
        !          1065: not all requests that are generated are completed.  For one reason
        !          1066: or another data files will become orphaned, command and execution files
        !          1067: widowed, temporary files will strive for immortality, \fIcore\fR files
        !          1068: will be born (not by UUCP of course) and \fIdead.letters\fR will litter
        !          1069: directories.
        !          1070: Only a program can expend the time and effort required to manage
        !          1071: a busy system routinely.
        !          1072: .PP
        !          1073: One of the first programs we threw away was \fIuuclean\fR.
        !          1074: This left us without an automated mechanism to sweep all of UUCP's
        !          1075: litter under the rug.
        !          1076: Over a period of several weeks we noted our actions and our
        !          1077: thoughts as we manually handled the situations described above
        !          1078: in the most considerate manner.
        !          1079: From these observations a set of heuristics
        !          1080: was compiled that effectively deal with the deficiencies of
        !          1081: an imperfect system.
        !          1082: They are represented by a program (\fIuucleanup\fR) that
        !          1083: deals handily with the
        !          1084: typical cases.
        !          1085: Unanticipated problems are dealt with inelegantly
        !          1086: in the style of \fIuuclean\fR, but are recorded to facilitate the
        !          1087: incorporation of additional knowledge as it becomes necessary.
        !          1088: Appendix V shows examples of the various situations encountered
        !          1089: and how they are handled.
        !          1090: This ``expert'' program along with expanded \fIdaemon shells\fR that
        !          1091: monitor activity and generate reports provides enormous assistance
        !          1092: in maintaining UUCP.
        !          1093: .NH 2
        !          1094: Accounting
        !          1095: .PP
        !          1096: All the core programs
        !          1097: (\fIuucp\fR, \fIuucico\fR, \fIuuxqt\fR and \fIuux\fR) append accounting data
        !          1098: to log files, but they do not operate on the data.
        !          1099: Separate programs such as \fIuustat\fR are provided
        !          1100: that examine the files and operate on their contents.
        !          1101: Maintenance functions are also delegated to separate programs as
        !          1102: discussed.  
        !          1103: These separations
        !          1104: have significantly reduced the complexity of the core programs.
        !          1105: \fIUucp\fR spools requests to copy files.  \fIUux\fR spools remote
        !          1106: command executions.  \fIUucico\fR performs the actual transfer of files and
        !          1107: \fIuuxqt\fR executes remotely specified commands.
        !          1108: .NH 1
        !          1109: Things The Users Will Notice
        !          1110: .NH 2
        !          1111: Reporting Remote Execution Status
        !          1112: .PP
        !          1113: Specific knowledge of the commands invoked by \fIuuxqt\fR has been removed.
        !          1114: All commands are handled in a uniform manner.
        !          1115: .PP
        !          1116: In previous versions of \fIuuxqt\fR, the \fImail\fR command was handled specially.
        !          1117: Except for \fImail\fR, the return status of all commands was
        !          1118: unconditionally reported to the invoker.
        !          1119: For \fImail\fR however, no status was returned if the
        !          1120: command succeeded.
        !          1121: But, if the \fImail\fR command failed, \fIuuxqt\fR would
        !          1122: return the standard input as well as the status.
        !          1123: This was justified by the fact that \fIuuxqt\fR was principally used for
        !          1124: remote mailing.
        !          1125: When netnews became widely used, it too was a logical
        !          1126: candidate for exceptional handling within \fIuuxqt\fR.
        !          1127: Two approaches had been
        !          1128: taken.  The first was to treat the \fIrnews\fR command specially and ignore the
        !          1129: return status.
        !          1130: The second, more elegant solution appeared in the version
        !          1131: distributed with
        !          1132: .UX
        !          1133: 4.0.  That was to enhance \fIuux\fR
        !          1134: (and \fIuuxqt\fR) with an option
        !          1135: .CW -n ) (
        !          1136: to specify that command return status was not
        !          1137: to be sent back to the invoker.  This was a step in the right direction
        !          1138: but was not sufficient.
        !          1139: Another option was added locally to return status if and only if it was
        !          1140: not zero
        !          1141: .CW -z ). (
        !          1142: This was still not good enough.  More flexibility
        !          1143: was needed if we were to remove the builtin knowledge of what to do
        !          1144: with \fImail\fR.
        !          1145: Our solution is to provide three options to \fIuux\fR that modify
        !          1146: \fIuuxqt\fR's behavior.  They are:
        !          1147: .TS
        !          1148: cFCW l.
        !          1149: -n     do not request error notification
        !          1150: -z     request success notification
        !          1151: -b     return standard input on failure
        !          1152: .TE
        !          1153: Each option overrides the default behavior which is the opposite action.
        !          1154: In all cases of a failure, the standard error output is mailed to the originator.
        !          1155: Appendix VI is a sample message from UUCP resulting from a failed \fIrnews\fR
        !          1156: command.
        !          1157: Reporting error output is a significant enhancement.
        !          1158: Now the user is provided with all available information regarding remotely
        !          1159: executed commands with a general mechanism that handles all commands
        !          1160: equally well.
        !          1161: .NH 2
        !          1162: Forwarding
        !          1163: .PP
        !          1164: Users have always been confused by the lack of a forwarding mechanism
        !          1165: in UUCP.  Typically they assume that the syntax used by \fImail\fR
        !          1166: is correct for \fIuucp\fR.
        !          1167: For example,
        !          1168: .P1
        !          1169: mail harpo!allegra!princeton!honey
        !          1170: uucp file harpo!princeton!/usr/honey/uucp/file
        !          1171: .P2
        !          1172: Until very recently \fIuucp\fR could
        !          1173: not handle
        !          1174: such a request.  In response to this Mark Horton wrote a command (\fIuusend\fR)
        !          1175: which was distributed with 4.1bsd.  The \fIuusend\fR command accepted the
        !          1176: mail-like syntax and used the identical mechanism.  The way it worked was that
        !          1177: a \fIuux\fR command was issued to execute \fIuusend\fR on the next site in the
        !          1178: path.
        !          1179: There the \fIuusend\fR command issued another \fIuux\fR for the next site until
        !          1180: the
        !          1181: destination was reached.  The catch was that the \fIuusend\fR command must be
        !          1182: permitted to be remotely executed on each intermediate site.
        !          1183: In the version
        !          1184: of UUCP that we used as a base a forwarding mechanism was incorporated into
        !          1185: the code.  Unfortunately it appeared as a special case requiring additional
        !          1186: semantics for \fIuuxqt\fR on the remote system.  This code was immediately excised
        !          1187: (over 500 lines).
        !          1188: .PP
        !          1189: The \fIuusend\fR model was correct.
        !          1190: But it was argued that it was desirable for
        !          1191: \fIuucp\fR
        !          1192: to accept
        !          1193: the forwarding syntax rather than a separate command.  The other side of the
        !          1194: argument was that a user could generate the \fIuux\fR command and \fIuucp\fR
        !          1195: need know
        !          1196: nothing of it.  It was further argued that \fIuucp\fR itself is merely a special
        !          1197: case of the \fIuux\fR command (where the remotely executed command is \fIcp\fR)
        !          1198: and ought
        !          1199: to done away with (perhaps a shell procedure could take its place for
        !          1200: convenience's sake).  The makers of the first argument prevailed and forwarding
        !          1201: was put back into \fIuucp\fR.  However, rather than treat it as a special case
        !          1202: on the remote end, \fIuucp\fR generates the appropriate \fIuux\fR command.
        !          1203: This has the
        !          1204: advantage that it is simpler and it will work with any version.
        !          1205: The catch remains that the remote systems must allow the \fIuucp\fR command to
        !          1206: be executed by \fIuuxqt\fR.  It's interesting to note that the very first
        !          1207: version of
        !          1208: UUCP used this same mechanism to implement ``uucp tilt!file whuxlb!file''.
        !          1209: The
        !          1210: local system effectively sent a \fIuux\fR request to execute \fIuucp\fR on
        !          1211: \fItilt\fR to \fIwhuxlb\fR.
        !          1212: This was the only remote execution done by the
        !          1213: original (1976) version.
        !          1214: Thus at that time one could accomplish forwarding by a succession of \fIuucp\fR
        !          1215: commands.  I.e.,
        !          1216: .P1
        !          1217: uucp file ima!ist!file
        !          1218: .P2
        !          1219: could have been
        !          1220: accomplished by
        !          1221: .P1
        !          1222: uucp file ima!file;
        !          1223: sleep \fIn\fP
        !          1224: uucp ima!file ist!file
        !          1225: .P2
        !          1226: The only problem was knowing the correct value for \fIn\fR.
        !          1227: .NH 1
        !          1228: Priorities
        !          1229: .PP
        !          1230: Versions of UUCP since the second have had the capability to
        !          1231: grade file transfers by use of the
        !          1232: .CW -g
        !          1233: option.
        !          1234: However it's not clear
        !          1235: that there was an effect other than modifying the name of the command file.
        !          1236: In our version, the grade option does something useful.
        !          1237: When command files
        !          1238: are gathered up, they are sorted, so the grade serves to order the
        !          1239: processing of command files.
        !          1240: When used with \fIuux\fR, the grade option is
        !          1241: bound to the
        !          1242: execution file as well.
        !          1243: Thus upon receiving execution files, they are similarly
        !          1244: gathered and sorted and the grade again dictates their execution order.
        !          1245: The grade option could be used, for example, to provide mail with a higher
        !          1246: priority than netnews.
        !          1247: .NH 2
        !          1248: Sending Files That Uucp Cannot Read
        !          1249: .PP
        !          1250: For reasons of security and convenience UUCP must run under a user id
        !          1251: of its own.  The system would probably be more straightforward, more secure
        !          1252: and functionally superior if UUCP were to run as \fIroot\fR.
        !          1253: But that change seems drastic and would undoubtedly be unpopular.
        !          1254: So UUCP stands on its head
        !          1255: while bending over backwards to provide services and security
        !          1256: without a privileged user id.
        !          1257: There are two problems that users commonly complain about.
        !          1258: The first is that files received via UUCP are owned by the uucp
        !          1259: login and not their own.
        !          1260: This is more of an administrative problem than a technical one.
        !          1261: Although some versions of
        !          1262: .UX
        !          1263: allow users to arbitrarily change the ownership of their
        !          1264: files, it is clearly less desirable to allow users to do this remotely.
        !          1265: The problem is easy to get around on the receiving end by copying the files
        !          1266: and removing the originals.
        !          1267: The second problem is more serious.
        !          1268: Users sending files often find that
        !          1269: the request fails because \fIuucp\fR could not read their data due to stringent
        !          1270: protections.
        !          1271: This however can be dealt with since \fIuucp\fR is invoked by the
        !          1272: user who does have permission to access said files.
        !          1273: By default \fIuucp\fR does
        !          1274: not
        !          1275: copy the source files to its spool directory.
        !          1276: Rather, it transfers the data
        !          1277: directly from the specified file.
        !          1278: However if the file is not readable by
        !          1279: \fIuucp\fR,
        !          1280: then it makes a copy using the invoker's access privileges but owned by the uucp
        !          1281: login.
        !          1282: The file remains secure with respect to the user population because its mode
        !          1283: is changed to be readable only by the uucp login, after the data is copied in.
        !          1284: This obviates the undesirable requirement that the user make a public copy or
        !          1285: change the modes on the original file.
        !          1286: .NH 2
        !          1287: Documentation
        !          1288: .PP
        !          1289: Real programmers don't need auxiliary documentation, they read the
        !          1290: source code.  In deference to those programmers we have put
        !          1291: considerable effort into making the source code readable.
        !          1292: But the UUCP user population will include many more who don't want
        !          1293: to read the code (their loss).  For them we have revised the manual
        !          1294: pages to reflect the system more accurately.  Many new manual pages
        !          1295: are included covering the utilities mentioned.  Even manual pages
        !          1296: for the embedded programs \fIuucico\fR and \fIuuxqt\fR have been written.
        !          1297: Other documents have been published
        !          1298: by the authors|reference(uucp security)|reference(honey danber nijmegen).
        !          1299: A comprehensive administration guide will be included with
        !          1300: the ``Basic Networking Utilities, UNIX System V''.
        !          1301: .NH 1
        !          1302: Things The Administrator Will Appreciate
        !          1303: .NH 2
        !          1304: New Semantics to Support Gateways
        !          1305: .PP
        !          1306: Two options used with the \fIPermissions\fR file
        !          1307: allow users of UUCP to deal with some unresolved networking problems.
        !          1308: They are the \fIMYNAME\fR and \fIPUBDIR\fR options.
        !          1309: .PP
        !          1310: As described previously, the \fIPermissions\fR file allows the system to behave
        !          1311: differently depending upon the remote site it is communicating with.
        !          1312: The \f(CWMYNAME=\fInewname\fR option instructs UUCP to behave as if the local system
        !          1313: were
        !          1314: named \fInewname\fR.  The \f(CWPUBDIR=\fI/newdir\fR causes the local system to use
        !          1315: \fInewdir\fR
        !          1316: rather than the standard spool directory for the remote system.
        !          1317: Initially this was seen as a convenient mechanism for debugging.
        !          1318: UUCP transactions
        !          1319: could be made to take place within a single machine.
        !          1320: However some more interesting possibilities arise.
        !          1321: .PP
        !          1322: One can set up a gateway machine for a group of others.  By instructing remote
        !          1323: systems
        !          1324: to connect to the same physical machine using different logins, data destined
        !          1325: to the satellites will be transferred unwittingly to the gateway.  The data
        !          1326: accumulated in the special spool directories for the satellites can be transferred
        !          1327: to them and their UUCP systems can act upon it as if it had come directly from
        !          1328: the originating system.  Similarly data destined for a remote
        !          1329: system from one of the
        !          1330: satellites
        !          1331: can be redirected, using the \fIPUBDIR\fR option, to a special directory which is
        !          1332: then
        !          1333: transferred to the gateway for actual transmission to the remote system.
        !          1334: The beauty
        !          1335: of this scheme is that it is well confined and invisible to the users both
        !          1336: locally and remotely.
        !          1337: .PP
        !          1338: Another application might be to provide increased bandwidth among machines.
        !          1339: Let's say machines \fItempus\fR and \fIfugit\fR have a great deal of traffic
        !          1340: between them and
        !          1341: their communications link is not sufficient to dispose of all the data.
        !          1342: Then \fItempus\fR can think of \fIfugit\fR as two machines, \fIfugit1\fR and
        !          1343: \fIfugit2\fR.
        !          1344: Likewise
        !          1345: \fIfugit\fR will know of \fItempus1\fR and \fItempus2\fR.
        !          1346: Then it is a simple matter for traffic
        !          1347: between these two machines to utilize two separate routes.
        !          1348: UUCP will have
        !          1349: two simultaneous non-interfering connections between \fItempus\fR and
        !          1350: \fIfugit\fR, thereby
        !          1351: doubling the traffic capacity.  A similar use would be to have high priority
        !          1352: traffic sent to a machine using one name and other data sent using another.
        !          1353: Thus for example mail could be sent upon demand using a more
        !          1354: dear resource (like prime time Direct Distance Dialing), while netnews was
        !          1355: sent only over less expensive (but perhaps not as timely) facilities.
        !          1356: .PP
        !          1357: The possibilities for customization and cost reduction are vast.
        !          1358: These features will undoubtedly be used for applications that haven't
        !          1359: been considered, which is why they are so interesting.
        !          1360: .NH 2
        !          1361: Sequence Numbers
        !          1362: .PP
        !          1363: These numbers are used to provide unique file names for spooled
        !          1364: data.  Their purpose was often defeated on heavily loaded systems
        !          1365: and there has been a fair probability of conflict under certain pathological
        !          1366: conditions.  The implementation of sequence numbers in the second
        !          1367: version of UUCP was simple.  When a command or
        !          1368: data file was required, a sequence lock was created, the sequence number
        !          1369: file was read, the number incremented and written and the lock file
        !          1370: was removed.  The sequence number was four decimal digits.
        !          1371: The C. or D. file was formed from the appropriate one-character prefix, a `.', a
        !          1372: system name  up to seven characters (the remote's for command files,
        !          1373: either the remote or the local name for data files), and the sequence number.
        !          1374: The length of the sequence number was constrained to four characters
        !          1375: because the composite file name was limited to fourteen.
        !          1376: .PP
        !          1377: There are some specific problems identified with this technique.
        !          1378: The file system access required for locking, reading, writing, and
        !          1379: unlocking was expensive, especially when many data files were required.
        !          1380: .PP
        !          1381: For a given system there were @10 sup 4@ unique names
        !          1382: for command files and data files.
        !          1383: Ten thousand names were quickly used up on a very active system.
        !          1384: Typically, they were consumed at the
        !          1385: rate of three for each \fIuux\fR command and two for each \fIuucp\fR command.
        !          1386: Therefore if a system were to spool data for four thousand such commands before it
        !          1387: had transferred initial ones, the sequence number would wrap around and
        !          1388: there would be a high probability (1/3) of a name clash.
        !          1389: This
        !          1390: is not farfetched considering that a site distributing netnews to four others
        !          1391: (at 250 articles per day) will go through 1000 sequence numbers daily.
        !          1392: .PP
        !          1393: Because \fIuux\fR had named its data input files as D.remote\fInnnn\fR, a system
        !          1394: may receive files named identically from different remotes.
        !          1395: The likelihood
        !          1396: of this event was also proportional to the number of systems for which
        !          1397: jobs are remotely executed.  If a system receives netnews from
        !          1398: four others, but for some reason can't process the requests because of
        !          1399: the positive
        !          1400: feedback discussed earlier, the probability of a name clash is at least
        !          1401: one in ten after a day.  In fact it may be much greater because the sites
        !          1402: sending data are not likely to have mutually exclusive sequence numbers.
        !          1403: .PP
        !          1404: A solution to these problems was first introduced by Alan Watt of ITT.
        !          1405: He generated sequence numbers from the set of alphanumeric characters.
        !          1406: This extended the name space from @10 sup 4@ to @62 sup 4@.
        !          1407: (He also cached sequence numbers on each access to the sequence file.)
        !          1408: Although this deals with
        !          1409: locally generated names it provides no defense from receiving name
        !          1410: clashes.  There is also the aesthetically unpleasant aspect of creating
        !          1411: garbage names which may randomly turn out to be offensive.
        !          1412: .PP
        !          1413: Our version of UUCP deals handily with these problems.
        !          1414: The sequence number is seven hex digits.
        !          1415: Four of these digits are derived from a sequence number file.
        !          1416: The remaining three digits represent a cache of sub-job numbers
        !          1417: that modify the base number.
        !          1418: Thus a command will require only one access to the
        !          1419: file for up to @16 sup 3@ sequence numbers.
        !          1420: Since we use separate spool directories for each remote site, name
        !          1421: clashes will not occur when different systems send us the same file
        !          1422: names.
        !          1423: The initial base number is selected randomly, reducing the
        !          1424: possibility that we would generate names that clash 
        !          1425: on a remote site running an old version of UUCP.
        !          1426: The use of seven hex digits and the fact that a different number sequence
        !          1427: is maintained for each remote site allows us to avoid the use of alphabetic
        !          1428: sequences.
        !          1429: .NH 2
        !          1430: A New Locking Mechanism
        !          1431: .PP
        !          1432: Previous versions of UUCP relied on the modification time of a lock file.
        !          1433: It was assumed a file
        !          1434: older than some threshold was invalid.  This led to problems
        !          1435: when UUCP (or other programs sharing resources with UUCP) executed
        !          1436: for extended periods of time.  One awkward solution was to have programs
        !          1437: periodically touch the lock file.  Our solution relies on a property of
        !          1438: System V that enables a process to determine if it can kill another without
        !          1439: actually disturbing it.  The identifier of the process using a resource
        !          1440: is recorded in the lock file.  When another process examines the lock file
        !          1441: it issues a \fIkill\fR(0) to the identifier contained within.
        !          1442: If the \fIkill\fR succeeds
        !          1443: this indicates that the specified process is still running.  If it fails
        !          1444: \fIerrno\fR indicates if it was due to lack of permission (cu processes
        !          1445: will have different user ids).
        !          1446: If the process no longer exists,
        !          1447: the lock file is assumed to be invalid.  The code to add this function
        !          1448: to other versions of
        !          1449: .UX
        !          1450: is slight and straightforward and is included with the source distribution.
        !          1451: Alternatively a routine could be written that uses
        !          1452: \fIps\fR to glean
        !          1453: the same information, though this would be considerably less efficient.
        !          1454: For systems that don't implement this property of \fIkill\fR, UUCP may be
        !          1455: configured to use the old mechanism.
        !          1456: .NH 2
        !          1457: Giving Up
        !          1458: .PP
        !          1459: ``RETRY TIME NOT REACHED'' or ``CONNECT FAILED MAXRECALLS'' messages
        !          1460: indicate
        !          1461: that UUCP has given up trying to connect to a remote system.
        !          1462: If a connection fails, when do you try again?
        !          1463: Historically UUCP tried again every 55 minutes. After nine hours
        !          1464: and ten minutes it gave up for good.
        !          1465: This algorithm is clearly inadequate.  If a system was down for
        !          1466: more than ten hours, manual intervention was required.
        !          1467: On the other hand, perhaps 55 minutes was too long to wait between
        !          1468: attempts, but to lower that would mean it would give up after an even
        !          1469: shorter period.
        !          1470: We have replaced the \fIRETRYTIME/MAXRECALLS\fR concept with an exponential
        !          1471: backoff algorithm.
        !          1472: The early attempts are frequent and continue to
        !          1473: be spaced out in time until an attempt is made once every 23 hours.
        !          1474: UUCP will continue trying daily forever.
        !          1475: Optionally the \fISystems\fR
        !          1476: file may indicate that a given system should be treated differently
        !          1477: and attempts will be made continually at the specified interval.
        !          1478: One can of course easily compile in a custom algorithm.
        !          1479: .NH 2
        !          1480: Sharing Modules
        !          1481: .PP
        !          1482: As noted previously UUCP incorporates several functions that
        !          1483: are of value to other applications.  The locking routines can be used
        !          1484: by any facility, which is why lock files were placed in a more generic
        !          1485: location.
        !          1486: The connection function is being used by the \fIcu\fR and
        !          1487: \fIct\fR programs as
        !          1488: well as the various spoolers for line printers, typesetters, etc.
        !          1489: Any utility that needs to establish a bidirectional connection to a shared
        !          1490: resource can make use of these facilities.
        !          1491: The packet driver which was once part of the
        !          1492: .UX
        !          1493: kernel could be
        !          1494: more useful to other communications programs if it were returned there.
        !          1495: .NH 1
        !          1496: Roadmap
        !          1497: .NH 2
        !          1498: Utilities
        !          1499: .PP
        !          1500: The new version of UUCP comes with programs
        !          1501: to assist in setup, administration and debugging.  They are:
        !          1502: .IP "\fICvt\fR\ \ " 8
        !          1503: converts existing data, command and execution files from the old format.
        !          1504: .IP "\fIInstall\fR\ \ "
        !          1505: puts programs in the right place with the right modes.
        !          1506: .IP "\fIUutry\fR\ \ "
        !          1507: starts a \fIuucico\fR to a remote system.  It places debugging output
        !          1508: in a file and tails it.  It optionally causes the status file to be ignored.
        !          1509: .IP "\fISetUp\fR\ \ "
        !          1510: creates all the necessary UUCP system files and renames as necessary
        !          1511: (e.g., \fIL.sys\fR @->@ \fISystems\fR).
        !          1512: .IP "\fIremote.unknown\fR\ \ "
        !          1513: optionally invoked by \fIuucico\fR if an unknown system calls.
        !          1514: This procedure logs the caller and time.
        !          1515: .IP "\fIuudemon.admin\fR\ \ "
        !          1516: sends status information to the administrator.
        !          1517: .IP "\fIuudemon.clean\fR\ \ "
        !          1518: does routine maintenance of log files and invokes the
        !          1519: \fIuucleanup\fR program (previously described).
        !          1520: .IP "\fIuudemon.hour\fR\ \ "
        !          1521: invokes \fIuusched\fR and \fIuuxqt\fR.
        !          1522: .IP "\fIuudemon.poll\fR\ \ "
        !          1523: implements polling utilizing a file that describes which systems are to
        !          1524: be polled at what times.
        !          1525: .IP "\fIuukick\fR\ \ "
        !          1526: starts a \fIuucico\fR for a system, no debugging.
        !          1527: .IP "\fIuulog\fR\ \ "
        !          1528: examines or monitors log files
        !          1529: .IP "\fIuuto\fR\ \ "
        !          1530: sends files and/or directories to a remote user.
        !          1531: .IP "\fIuupick\fR\ \ "
        !          1532: retrieves data sent via \fIuuto\fR and interactively relocates it.
        !          1533: .IP "\fIuucheck\fR\ \ "
        !          1534: verifies that required files and directories are present.
        !          1535: .IP "\fIuucleanup\fR\ \ "
        !          1536: disposes of defunct files in an \fIintelligent\fR manner.
        !          1537: .IP "\fIuustat\fR\ \ "
        !          1538: displays the status of or cancels previously specified UUCP commands
        !          1539: or provides general status on connections to other systems.
        !          1540: It's worth noting that this version of \fIuustat\fR does its job by examining
        !          1541: the log files.  It requires no hooks in the core programs.
        !          1542: .IP "\fIuusched\fR\ \ "
        !          1543: deals with all the scheduling aspects of UUCP.
        !          1544: In a move to reduce the complexity of the core programs \fIuusched\fR was
        !          1545: invented.  
        !          1546: It determines which systems have work and if it's the right time to call (by
        !          1547: examining the \fISystems\fR file).  It optionally limits the number of
        !          1548: \fIuucico\fR
        !          1549: processes
        !          1550: that can be executing at once.
        !          1551: This program relieves \fIuucico\fR of the need to
        !          1552: search through all the system subdirectories for work.
        !          1553: \fIUucico\fR then is always
        !          1554: invoked with the name of the system to which it will connect.
        !          1555: .IP "\fIuugetty\fR\ \ "
        !          1556: may be used instead of the standard \fIgetty\fR to
        !          1557: allow lines to act both as inbound (normal login) and outbound ports for
        !          1558: \fIuucico\fR, \fIcu\fR, and \fIct\fR.
        !          1559: \fIUugetty\fR only works with System V versions of
        !          1560: .UX .
        !          1561: .KF
        !          1562: .PS 2.5i
        !          1563: box invis ht 352 wid 328 with .sw at 0,0
        !          1564: "\fR\s10\&Figure 2.  \f(CW/usr/spool/uucp\f1\s0" at 184,-10
        !          1565: "\f(CW\s10\&harpo\f1\s0" at 336,306
        !          1566: "\f(CW\s10\&chico\f1\s0" at 332,274
        !          1567: "\f(CW\s10\&zeppo\f1\s0" at 292,250
        !          1568: "\f(CW\s10\&.Corrupt\f1\s0" at 268,202
        !          1569: "\f(CW\s10\&.Admin\f1\s0" at 228,170
        !          1570: line  from 256,80 to 256,56 
        !          1571: line  from 256,80 to 240,64 
        !          1572: line  from 256,80 to 272,64 
        !          1573: line  from 208,64 to 208,40 
        !          1574: line  from 208,64 to 192,48 
        !          1575: line  from 208,64 to 224,48 
        !          1576: line  from 160,64 to 160,40 
        !          1577: line  from 160,64 to 144,48 
        !          1578: line  from 160,64 to 176,48 
        !          1579: line  from 120,80 to 104,64 
        !          1580: line  from 120,80 to 120,56 
        !          1581: line  from 120,80 to 136,64 
        !          1582: "\fI\s10\&uucico\f1\s0" at 256,86
        !          1583: "\fI\s10\&uuxqt\f1\s0" at 208,70
        !          1584: "\fI\s10\&uux\f1\s0" at 160,70
        !          1585: "\fI\s10\&uucp\f1\s0" at 120,86
        !          1586: line  from 184,352 to 144,184 
        !          1587: "\f(CW\s10\&.Log\f1\s0" at 184,138
        !          1588: line  from 184,352 to 184,152 
        !          1589: "\f(CW\s10\&.Status\f1\s0" at 144,170
        !          1590: "\f(CW\s10\&.Workspace\f1\s0" at 104,202
        !          1591: line  from 184,128 to 248,96 
        !          1592: line  from 184,128 to 208,80 
        !          1593: line  from 184,128 to 160,80 
        !          1594: line  from 184,128 to 120,96 
        !          1595: line  from 184,352 to 328,320 
        !          1596: line  from 184,352 to 328,288 
        !          1597: line  from 184,352 to 288,264 
        !          1598: line  from 184,352 to 264,216 
        !          1599: line  from 184,352 to 224,184 
        !          1600: "\f(CW\s10\&.Xqtdir\f1\s0" at 76,242
        !          1601: line  from 184,352 to 104,216 
        !          1602: line  from 184,352 to 80,256 
        !          1603: line  from 40,264 to 40,240 
        !          1604: line  from 40,264 to 24,240 
        !          1605: line  from 40,264 to 0,248 
        !          1606: "\f(CW\s10\&.Sequence\f1\s0" at 44,274
        !          1607: line  from 184,352 to 48,288 
        !          1608: "\f(CW\s10\&exodus\f1\s0" at 40,306
        !          1609: line  from 184,352 to 48,320 
        !          1610: .PE
        !          1611: .KE
        !          1612: .NH 2
        !          1613: Subdirectory Mania
        !          1614: .PP
        !          1615: In rearranging the data associated with UUCP, there is some concern
        !          1616: that we may have gone overboard.  See Figure 2.  On the other hand
        !          1617: our structure may not be complete in that perhaps lock files should
        !          1618: be stored hierarchically under \fIsystems\fR, \fIdevices\fR, and
        !          1619: \fIprocesses\fR directories.
        !          1620: (As it now stands \fIuuxqt\fR cannot make lock files incorporating fourteen
        !          1621: character system names.)
        !          1622: The directories are:
        !          1623: .IP "\f(CW.Status\fR\ \ " 8
        !          1624: a status file for each system.
        !          1625: .IP "\f(CW.Log\fR\ \ "
        !          1626: contains subdirectories for each core program which in turn contain
        !          1627: log files for each system.
        !          1628: .IP "\f(CW.Admin\fR\ \ "
        !          1629: This directory contains a miscellaneous collection of files including:
        !          1630: .RS
        !          1631: .PP
        !          1632: an audit file that is appended to when
        !          1633: a remote system invokes \fIuucico\fR with a debugging option,
        !          1634: .PP
        !          1635: a file in which assert errors are logged,
        !          1636: .PP
        !          1637: the file transfer statistics which
        !          1638: include the system, role, time of day, process id, device, direction of transfer,
        !          1639: number of bytes, and time in milliseconds for each transfer,
        !          1640: .PP
        !          1641: and log files created by the \fIuucleanup\fR program telling about
        !          1642: deletions and such.
        !          1643: .RE
        !          1644: .IP "\f(CW.Corrupt\fR\ \ "
        !          1645: where corrupt command and execution files are placed.
        !          1646: .IP "\f(CW.Old\fR -
        !          1647: for old log files being rotated out.
        !          1648: .IP "\f(CW.Sequence\fR\ \ "
        !          1649: files for each system containing the current sequence number.
        !          1650: .IP "\f(CW.Workspace\fR\ \ "
        !          1651: where command and data files are formed before being committed
        !          1652: to their final directory.
        !          1653: .IP "\f(CW.Xqtdir\fR\ \ "
        !          1654: where remotely generated executions take place.
        !          1655: .NH 1
        !          1656: Esoterica
        !          1657: .NH 2
        !          1658: Software Engineering or Hacking by Committee?
        !          1659: .PP
        !          1660: In late April of 1983 a diverse group of people from Bell Labs
        !          1661: met to discuss the state of UUCP and how to improve it.  These
        !          1662: people came from many different geographical and technical areas.
        !          1663: It was an informal gathering of interested parties who for the most
        !          1664: part were working on various projects not related to UUCP. However they
        !          1665: all had intimate dealings with UUCP and wanted to see a system that
        !          1666: was common among them so their efforts could
        !          1667: be combined towards a single improved version.  The notes from that meeting
        !          1668: are reproduced in Appendix VII.
        !          1669: .PP
        !          1670: The meeting provided the incentive and the mandate to do something
        !          1671: about UUCP.  Although several activities were in progress, none
        !          1672: seemed to address all the problems comprehensively.  The effort began
        !          1673: in individual stages.  The most current version of UUCP from the
        !          1674: .UX
        !          1675: Development Lab was delivered to Redman in late April.  The first step
        !          1676: was to add the appropriate code using \fIifdefs\fR so that it could be
        !          1677: compiled under 4.1bsd (Redman's base system).
        !          1678: This was done within a week.
        !          1679: Next, Redman modified the system to use separate spool directories.
        !          1680: The first version was complete towards the end of May.  In the beginning
        !          1681: of June
        !          1682: Honeyman became active and his \fIrational connection functions\fR were incorporated.
        !          1683: Midway through July Nowitz contributed the \fIpermissions\fR code.  At this point
        !          1684: the effort became totally collaborative among the authors.  By the end of July
        !          1685: UUCP was being distributed among those at the April meeting for comments and
        !          1686: enhancements.  Through this process many valuable contributions were received
        !          1687: from the community and the system was soaked in many environments including
        !          1688: all modern versions of
        !          1689: .UX
        !          1690: (4.0, System V, 4.1 bsd, 4.1c bsd, 4.2 bsd and Eighth
        !          1691: Edition) representing systems heavily
        !          1692: loaded with mail forwarding, netnews and software distributions.
        !          1693: .PP
        !          1694: In late September we began reviewing all modules and refining them to
        !          1695: meet standards of style and function.
        !          1696: This phase of our work
        !          1697: was quite useful: as the code was thoughtfully reworked,
        !          1698: design problems became apparent.  Following stylistic conventions
        !          1699: consistently improved the readability.  Its complexities were ironed out
        !          1700: resulting in more comprehensible code which tended to be more efficient.
        !          1701: .PP
        !          1702: From the start SCCS was used to document changes.  Figure 3 shows the
        !          1703: activity over time in lines of code changed.
        !          1704: The version we started with as a base comprised about 13,000 lines of code.
        !          1705: The current system is 14,000 lines.  These numbers represent the removal
        !          1706: of approximately 3,000 lines of code from the delivered system and the
        !          1707: subsequent addition of 4,000 lines.  Although it would have been
        !          1708: gratifying to show a net reduction in the size of the system, the additional
        !          1709: strengths and capabilities justify the growth.
        !          1710: The inclusion of 5,000 lines of documentation
        !          1711: and installation and conversion scripts is also compensation.
        !          1712: (While we're throwing numbers around, it's interesting to note that
        !          1713: the communication among the authors during this development was primarily
        !          1714: via electronic mail.  Approximately 2,000 messages were sent, totaling
        !          1715: on the order of 50,000 lines.  It was truly an Information Age effort.)
        !          1716: This was software engineering rather than hacking because a lot of
        !          1717: people spent a lot of time on it.
        !          1718: .KF
        !          1719: .ps -2
        !          1720: .G1 2.5i
        !          1721: frame invis ht 2 wid 3.5 left solid bot solid
        !          1722: label left "lines" "of code" left .2
        !          1723: label bot "Figure 3.  SCCS Activity"
        !          1724: coord x 3,10 y 0,4096
        !          1725: ticks left in at 0, 256, 512, 768, 1024 "1K", 1280, 1536, 1792, 2048 "2K", 2304, 2560, 2816, 3072 "3K", 3328, 3584, 3840, 4096 "4K"
        !          1726: ticks bot out at 4 "Apr", 5 "May", 6 "Jun", 7 "Jul", 8 "Aug", 9 "Sep"
        !          1727: draw solid
        !          1728: 4 170
        !          1729: 5 1010
        !          1730: 6 1435
        !          1731: 7 4000
        !          1732: 8 3275
        !          1733: 9 1530
        !          1734: new dotted
        !          1735: 4 85
        !          1736: 5 550
        !          1737: 6 2560
        !          1738: 7 3480
        !          1739: 8 2760
        !          1740: 9 1125
        !          1741: "Insertions" size -3 at 9.5, 2100
        !          1742: "Deletions" size -3 at 8, 1600
        !          1743: .G2
        !          1744: .KE
        !          1745: .PP
        !          1746: One of the problems we described earlier was the entropic forces on the
        !          1747: UUCP software.  We know of no solution to the problem that won't result
        !          1748: in stagnancy.  We have invested considerable effort
        !          1749: to produce a system that is better understood and more modular with
        !          1750: the prospect of easing the implementation of changes.  Our best effort then
        !          1751: to deal with change is to recognize that it is inevitable, make allowances
        !          1752: so it is less destructive, and to provide a fresh system for fodder.
        !          1753: .NH 2
        !          1754: Controversy
        !          1755: .PP
        !          1756: No program of this complexity and with such widespread use can be redesigned
        !          1757: without having to make many controversial decisions.
        !          1758: Sometimes there
        !          1759: is no ``right'' way to do a thing.
        !          1760: Sometimes the right way is unpopular
        !          1761: because conventions embrace the ``wrong'' way.
        !          1762: Like most implementors we have been
        !          1763: somewhat stubborn about providing functionality that is orthogonal to our
        !          1764: purpose of correctness.
        !          1765: .PP
        !          1766: A good example is the issue surrounding the length of site names.
        !          1767: We support system names up to a practical limit of fourteen characters
        !          1768: (although a greater number is possible).  The original version of UUCP
        !          1769: only allowed seven characters due to limitations that have been described.
        !          1770: Recently a version of UUCP has been introduced that only permits six
        !          1771: character site names.  Here are the problems.
        !          1772: .PP
        !          1773: It is common for a system to call itself by a name that is greater than
        !          1774: seven characters (e.g., \fIresearch\fR).
        !          1775: In previous versions of UUCP such
        !          1776: a system would have an effective seven character name (i.e., \fIresearc\fR).
        !          1777: There was no problem because the site name was truncated immediately before
        !          1778: any table lookups.  Now we have extended the limit.
        !          1779: We have a system called
        !          1780: \fIresearch\fR in our \fISystems\fR file.
        !          1781: When a system calls us and purports to
        !          1782: be \fIresearc\fR we have a problem.
        !          1783: Is \fIresearc\fR equivalent to \fIresearch\fR?
        !          1784: If we treat it as such, then we have effectively limited names to seven
        !          1785: characters.  Our purpose was to extend the name space.  Therefore we
        !          1786: treat \fIresearc\fR and \fIresearch\fR as two different systems.  In order that
        !          1787: this enhancement not be incompatible with other systems, they are required
        !          1788: to identify themselves with their full name.  To change any version
        !          1789: of UUCP to do this is quite trivial, (both in source and binary versions),
        !          1790: yet it does require a change.  The dilemma is whether to make use of the
        !          1791: flexibility provided or to restrict it on behalf of those that for some
        !          1792: reason or another cannot cope with the changed behavior.
        !          1793: .PP
        !          1794: Lauren Weinstein has proposed an enhancement that addresses the problem.
        !          1795: He has suggested that UUCP be given the knowledge of which systems are
        !          1796: compatible and which are not and change its behavior accordingly.
        !          1797: Given that this can be implemented, a new question arises.  Does the additional
        !          1798: complexity and inconsistent behavior serve our purposes or is it a vain attempt
        !          1799: to please all people all of the time?
        !          1800: This issue is still open.
        !          1801: .PP
        !          1802: A different issue was resolved more quickly because of the mass hysteria
        !          1803: which ensued.  \fIUux\fR keeps a record of the system and user for which
        !          1804: requests are generated and passes it to the \fIuuxqt\fR program on the remote
        !          1805: system via the execution file.
        !          1806: This is the \fIU line\fR.
        !          1807: Unfortunately a fresh
        !          1808: U line is generated by each invocation of \fIuux\fR.
        !          1809: Therefore when mail is
        !          1810: sent from \fIrob\fR on \fIdagaboh\fR to \fIdecvax!mcvax!bellcore!psl\fR, the U line on
        !          1811: \fIdecvax\fR is indicated as
        !          1812: \fIdagaboh!rob\fR.
        !          1813: When \fIdecvax\fR processes the request,
        !          1814: it creates a new U line
        !          1815: containing \fIdecvax!uucp\fR.
        !          1816: When the
        !          1817: request arrives on \fImcvax\fR and for one reason or another cannot be
        !          1818: executed, an indication is sent to \fIdecvax!uucp\fR rather than
        !          1819: \fIdecvax!dagaboh!rob\fR.
        !          1820: The solution was clear!
        !          1821: Build the U line from the previous one.  A new
        !          1822: flag was added to \fIuux\fR to facilitate this.  This solution quickly became
        !          1823: a problem.  Most versions of \fIuuxqt\fR read the U line into a buffer limited
        !          1824: by sixteen characters in length.  The result of processing our more informative
        !          1825: U line caused versions of \fIuuxqt\fR to dump core on most sites throughout
        !          1826: the network.  This caused their systems to cease processing remote
        !          1827: executions because they could never get past our execution file.  The
        !          1828: network was backed up for days.
        !          1829: When confronted with these implications
        !          1830: our response was one of cool headed reason.
        !          1831: We suggested that everyone
        !          1832: increase the buffer allocation.
        !          1833: After all, sixteen was too small anyway because,
        !          1834: as had been pointed out in previous bug reports, some systems had increased
        !          1835: the maximum number of characters for a login name from eight to sixteen.
        !          1836: Our reason did not prevail.
        !          1837: We knuckled under, left the U line alone, and
        !          1838: now add this information via a new record (the R line) which although
        !          1839: less elegant, is less hazardous.
        !          1840: .PP
        !          1841: Finally, there is a problem that is of no great philosophical importance.
        !          1842: \fIUucp\fR (and now \fIuux\fR) either copies its source files to the spool
        !          1843: directory
        !          1844: or it transfers them from their original locations.  The former method
        !          1845: ensures that the user encounters no surprises.  The latter is vastly more
        !          1846: efficient.  Either is an acceptable default provided it can be
        !          1847: overridden.  The problem is that all versions of UUCP that descended from
        !          1848: the V7 line (notably 4.xbsd) use the former mechanism.  All versions that
        !          1849: came from PWB (notably System V) use the latter.  Although the default
        !          1850: can be readily changed at compilation time, it would be useful for a standard
        !          1851: behavior to evolve.
        !          1852: We have chosen the PWB default.
        !          1853: Some people are already unhappy.
        !          1854: .NH 2
        !          1855: Global Problems Requiring Further Investigation
        !          1856: .PP
        !          1857: The issue of backward compatibility is a thorn in the
        !          1858: side of advanced developments.  Technology often provides us with wonderful
        !          1859: solutions that cannot be effectively deployed because they are incompatible
        !          1860: with other systems.  An extreme position is to ignore the problem, cite that
        !          1861: the new way is the right way and other systems must change or die off.  This
        !          1862: spurs evolution but spurns practicality.  It is a position often taken in
        !          1863: research (and rightly so).
        !          1864: The other extreme is to use technology to provide the same old
        !          1865: capabilities more cheaply.
        !          1866: This does not support the ability to use resources in
        !          1867: new ways for different purposes.
        !          1868: Unfortunately the compromise solution has two
        !          1869: drawbacks: it is expensive to provide multiple functionality supporting
        !          1870: both the past and the future, and by maintaining outmoded
        !          1871: technology, you are encouraging it.
        !          1872: .PP
        !          1873: Another issue concerning development and maintenance is perhaps
        !          1874: more amenable to compromise.
        !          1875: This is the consideration of the type of working environment imposed.
        !          1876: On the one hand there is the advantage of a tight control.
        !          1877: Some problems are avoided because designs are proposed, reviewed,
        !          1878: tested and scrutinized before they are unleashed.
        !          1879: This is in contrast to an environment where ideas
        !          1880: are quickly implemented and distributed without an overburdening bureaucracy.
        !          1881: The appropriate environment depends as much on the individuals involved as
        !          1882: the requirements.  Too often one approach or the other is taken as a matter
        !          1883: of policy.
        !          1884: .NH 2
        !          1885: Future Work
        !          1886: .PP
        !          1887: We had planned for this to be the perfection of software art.
        !          1888: It has been approaching that asymptotically.
        !          1889: However, in order that it be made
        !          1890: available for its intended use, there are several things left undone
        !          1891: (although development continues for future releases).
        !          1892: It should be run with controlled conditions in
        !          1893: various environments and systematically tuned.  Different algorithms should
        !          1894: be available for use in different circumstances (e.g., memory rich vs. low budget
        !          1895: computers).  A non-spooling system is desired for use with very fast networks
        !          1896: that provide immediate response.
        !          1897: Also, encrypting of data files may be a useful enhancement.
        !          1898: .NH 1
        !          1899: Conclusion
        !          1900: .PP
        !          1901: This work may serve as a good example of a small team development
        !          1902: of a modestly large program.  We have retained the data which
        !          1903: describes our efforts in the form of electronic mail and SCCS versions.
        !          1904: From these it can be seen how the work was partitioned, how decisions were
        !          1905: made, where the difficulties arose, where we got in each other's way and
        !          1906: where we stood on each other's shoulders.  All in all, what we set out to do,
        !          1907: how we approached it, what we did and why is fairly accurately chronicled.
        !          1908: .PP
        !          1909: Uucp has been rewritten for the third time.  The new system is healthier
        !          1910: and more versatile than its predecessors.  We have attempted to provide a system
        !          1911: that is useful for all sorts of networking applications.  We also hope that
        !          1912: this version may be used to bring UUCP maintainers back to a common system so
        !          1913: that their future developments may be shared more vigorously. 
        !          1914: .SH
        !          1915: Acknowledgements
        !          1916: .PP
        !          1917: We thank the following for their substantive work and comments:
        !          1918: adiron!bob, axiom!smk, cbosgd!mark, masscomp!trb, 
        !          1919: ihnp4!gjm, ittvax!swatt, mouton!karn, ncsu!mcm, rti!trt, 
        !          1920: sun!shannon, watmath!arwhite, icarus!alb,
        !          1921: watmath!dmmartindale, whuxlb!eric.
        !          1922: For moral support, thanks to
        !          1923: decvax!larry, exodus!dvw, gummo!mmp, parsec!kolstad, rabbit!ark,
        !          1924: research!dmr, research!doug, utzoo!henry, vax135!martin, watmath!bstempleton.
        !          1925: .PP
        !          1926: Thanks to  allegra!jpl who reviewed the code with us and contributed
        !          1927: some of his own.  Our appreciation goes to down!pep who can spot a bug on a post
        !          1928: at 100 yards.  To research!rtm for some fine ideas taken from his rewrite.
        !          1929: To teklabs!stevenm for compiling the buglist.  To vortex!lauren for always
        !          1930: being able to see the other side of an issue.  To ulysses!smb for doing most
        !          1931: of the work involving 4.1c/4.2bsd.  A special note of appreciation to bellcore!mel
        !          1932: for dreaming up such a system that would keep so many people busy for so long
        !          1933: improving it.  And an extra acknowledgement to sfwoo!dan for hacking UUCP
        !          1934: with such enthusiasm after these many years and for being able to tell the
        !          1935: rest of us what the variable names meant.
        !          1936: .SH
        !          1937: References
        !          1938: .PP
        !          1939: |reference_placement
        !          1940: .FC
        !          1941: .1C
        !          1942: .BP
        !          1943: .SH
        !          1944: Appendix I - Sample Permissions File
        !          1945: .P1 0
        !          1946: # This entry for public login
        !          1947: # Use default permissions
        !          1948: LOGNAME=nuucp
        !          1949: 
        !          1950: # This for some friendly outside sites when they call us
        !          1951: # They each have a separate login.
        !          1952: # When they call, we will send queued files
        !          1953: LOGNAME=harpo:gummo:allegra:mhtsa:mhuxt \e
        !          1954:   SENDFILES=yes \e
        !          1955:   WRITE=/usr/spool/uucppublic:/usr/RNEWS
        !          1956: 
        !          1957: # This entry for when we call these people.
        !          1958: # They also can execute a couple of additional commands.
        !          1959: # The commands are safe, so VALIDATE is not necessary on the LOGNAME entry
        !          1960: MACHINE=mh3bs:harpo:gummo:allegra:mhtsa:mhuxt:pwbqq \e
        !          1961:   WRITE=/usr/spool/uucppublic:/usr/RNEWS \e
        !          1962:   COMMANDS=rnews:rmail:xp:lp
        !          1963: 
        !          1964: # This entry for machines in our room (when they call us)
        !          1965: # The sites that login with these login-ids have extra command
        !          1966: # privileges, so VALIDATE name vs login-id
        !          1967: # (See next entry--the MACHINE values are related to these VALIDATE values)
        !          1968: LOGNAME=uucp:uucpl \e
        !          1969:   VALIDATE=raven:owl:hawk:dove \e
        !          1970:   REQUEST=yes SENDFILES=yes \e
        !          1971:   READ=/ WRITE=/
        !          1972: 
        !          1973: # This entry for machines in our room -- when we call them
        !          1974: # It also specifies the commands they can execute locally.
        !          1975: # (The uucp command in COMMANDS option permits forwarding.)
        !          1976: MACHINE=owl:raven:hawk:dove \e
        !          1977:   REQUEST=yes \e
        !          1978:   COMMANDS=rnews:rmail:xp:lp:uucp \e
        !          1979:   READ=/  WRITE=/
        !          1980: 
        !          1981: # This entry to call back on our faster link
        !          1982: LOGNAME=uucpm MACHINE=mhwpf \e
        !          1983:   COMMANDS=rnews:rmail:xp:lp \e
        !          1984:   CALLBACK=yes
        !          1985: .P2
        !          1986: .SH
        !          1987: Appendix II - Output From \f(CWuucheck -v\fP
        !          1988: .P1 0
        !          1989: *** uucheck:  Check Required Files and Directories
        !          1990: *** uucheck:  Directories Check Complete
        !          1991: 
        !          1992: *** uucheck:  Check /usr/lib/uucp/Permissions file
        !          1993: ** LOGNAME PHASE (when they call us) 
        !          1994: 
        !          1995: When a system logs in as: (nuucp) 
        !          1996:        We DO NOT allow them to request files.
        !          1997:        We WILL NOT send files queued for them on this call.
        !          1998:        They can send files to
        !          1999:            /usr/spool/uucppublic (DEFAULT)
        !          2000:        Myname for the conversation will be yquem.
        !          2001:        PUBDIR for the conversation will be /usr/spool/uucppublic.
        !          2002: 
        !          2003: .P3
        !          2004: When a system logs in as: (harpo) (gummo) (allegra) (mhtsa) (mhuxt) 
        !          2005:        We DO NOT allow them to request files.
        !          2006:        We WILL send files queued for them on this call.
        !          2007:        They can send files to
        !          2008:            /usr/spool/uucppublic
        !          2009:            /usr/RNEWS
        !          2010:        Myname for the conversation will be yquem.
        !          2011:        PUBDIR for the conversation will be /usr/spool/uucppublic.
        !          2012: .P3
        !          2013: When a system logs in as: (uucp) (uucpl) 
        !          2014:        We DO allow them to request files.
        !          2015:        We WILL send files queued for them on this call.
        !          2016:        They can send files to
        !          2017:            /
        !          2018:        They can request files from
        !          2019:            /
        !          2020:        Myname for the conversation will be yquem.
        !          2021:        PUBDIR for the conversation will be /usr/spool/uucppublic.
        !          2022: 
        !          2023: When a system logs in as: (uucpm) 
        !          2024:        We will call them back.
        !          2025: 
        !          2026: 
        !          2027: ** MACHINE PHASE (when we call or execute their uux requests) 
        !          2028: 
        !          2029: When we call system(s): (mh3bs) (harpo) (gummo) (allegra) (mhtsa) (mhuxt) (pwbqq) 
        !          2030:        We DO NOT allow them to request files.
        !          2031:        They can send files to
        !          2032:            /usr/spool/uucppublic
        !          2033:            /usr/RNEWS
        !          2034:        Myname for the conversation will be yquem.
        !          2035:        PUBDIR for the conversation will be /usr/spool/uucppublic.
        !          2036: 
        !          2037: Machine(s): (mh3bs) (harpo) (gummo) (allegra) (mhtsa) (mhuxt) (pwbqq) 
        !          2038: CAN execute the following commands:
        !          2039: command (rnews), fullname (rnews)
        !          2040: command (rmail), fullname (rmail)
        !          2041: command (xp), fullname (xp)
        !          2042: command (lp), fullname (lp)
        !          2043: 
        !          2044: When we call system(s): (owl) (raven) (hawk) (dove) 
        !          2045:        We DO allow them to request files.
        !          2046:        They can send files to
        !          2047:            /
        !          2048:        They can request files from
        !          2049:            /
        !          2050:        Myname for the conversation will be yquem.
        !          2051:        PUBDIR for the conversation will be /usr/spool/uucppublic.
        !          2052: 
        !          2053: Machine(s): (owl) (raven) (hawk) (dove) 
        !          2054: CAN execute the following commands:
        !          2055: command (rnews), fullname (rnews)
        !          2056: command (rmail), fullname (rmail)
        !          2057: command (xp), fullname (xp)
        !          2058: command (lp), fullname (lp)
        !          2059: command (uucp), fullname (uucp)
        !          2060: 
        !          2061: When we call system(s): (mhwpf) 
        !          2062:        We DO NOT allow them to request files.
        !          2063:        They can send files to
        !          2064:            /usr/spool/uucppublic (DEFAULT)
        !          2065:        Myname for the conversation will be yquem.
        !          2066:        PUBDIR for the conversation will be /usr/spool/uucppublic.
        !          2067: 
        !          2068: Machine(s): (mhwpf) 
        !          2069: CAN execute the following commands:
        !          2070: command (rnews), fullname (rnews)
        !          2071: command (rmail), fullname (rmail)
        !          2072: command (xp), fullname (xp)
        !          2073: command (lp), fullname (lp)
        !          2074: 
        !          2075: 
        !          2076: *** uucheck:  /usr/lib/uucp/Permissions Check Complete
        !          2077: .P2
        !          2078: .BP
        !          2079: .SH
        !          2080: Appendix III - Sample Devices File
        !          2081: .LP
        !          2082: .KS
        !          2083: .TS
        !          2084: l l l l l l.
        !          2085: CALLER LINE    USEFUL  CLASS   DIALER  CHAT SCRIPT
        !          2086: =
        !          2087: .T&
        !          2088: l s s s s s.
        !          2089: # the ACU's
        !          2090: #
        !          2091: # 212/801 dialers
        !          2092: .T&
        !          2093: lFCW lFCW lFCW lFCW lFCW lFCW.
        !          2094: ACU    cul0    cua0    1200    212     unused
        !          2095: ACU    cul1    cua1    1200    212     unused
        !          2096: .T&
        !          2097: l s s s s s.
        !          2098: # VenTel dialer
        !          2099: .T&
        !          2100: lFCW lFCW lFCW lFCW lFCW lFCW.
        !          2101: ACU    vn0     unused  1200    ventel  unused (for now)
        !          2102: ACU    vn0     unused  300     ventel  unused (for now)
        !          2103: .T&
        !          2104: l s s s s s.
        !          2105: # Vadic dialer
        !          2106: .T&
        !          2107: lFCW lFCW lFCW lFCW lFCW lFCW.
        !          2108: ACU    vd0     unused  1200    vadic   unused (for now)
        !          2109: .T&
        !          2110: l s s s s s.
        !          2111: # special entry for Vadic only systems
        !          2112: .T&
        !          2113: lFCW lFCW lFCW lFCW lFCW lFCW.
        !          2114: ACU    vd0     unused  V1200   vadic   unused (for now)
        !          2115: .T&
        !          2116: l s s s s s.
        !          2117: #
        !          2118: # the Micom also has some VenTels
        !          2119: .T&
        !          2120: lFCW lFCW lFCW lFCW lFCW lFCW.
        !          2121: ACU    Micom   secret  1200    micomventel     unused (for now)
        !          2122: ACU    Micom   secret  300     micomventel     unused (for now)
        !          2123: .T&
        !          2124: l s s s s s.
        !          2125: #
        !          2126: #
        !          2127: # the switches
        !          2128: #
        !          2129: # Micom pbx
        !          2130: # 4800 baud is funny ...
        !          2131: .T&
        !          2132: lFCW lFCW lFCW lFCW lFCW lFCW.
        !          2133: Micom  mc0     unused  4800    unused  \`\`\'\' \es\ec NAME? %s GO \ec
        !          2134: Micom  mc0     unused  Any     unused  \`\`\'\' \`\`\'\' NAME? %s GO \ec
        !          2135: Micom  mc1     unused  4800    unused  \`\`\'\' \es\ec NAME? %s GO \ec
        !          2136: Micom  mc1     unused  Any     unused  \`\`\'\' \`\`\'\' NAME? %s GO \ec
        !          2137: .T&
        !          2138: l s s s s s.
        !          2139: # Develcon pbx
        !          2140: .T&
        !          2141: lFCW lFCW lFCW lFCW lFCW lFCW.
        !          2142: Develcon       dv0     unused  Any     unused  \`\`\'\' \`\`\'\' Request: %s \e007 \ec
        !          2143: Develcon       dv1     unused  Any     unused  \`\`\'\' \`\`\'\' Request: %s \e007 \ec
        !          2144: .T&
        !          2145: l s s s s s.
        !          2146: # DATAKIT PS
        !          2147: .T&
        !          2148: lFCW lFCW lFCW lFCW lFCW lFCW.
        !          2149: Datakit        dk0     unused  Any     unused  \`\`\'\' \ed%s
        !          2150: Datakit        dk1     unused  Any     unused  \`\`\'\' \ed%s
        !          2151: .T&
        !          2152: l s s s s s.
        !          2153: # gandalf
        !          2154: .T&
        !          2155: lFCW lFCW lFCW lFCW lFCW lFCW.
        !          2156: Gandalf        gd0     unused  Any     unused  \`\`\'\' \`\`\'\' class %s start \ec
        !          2157: Gandalf        gd1     unused  Any     unused  \`\`\'\' \`\`\'\' class %s start \ec
        !          2158: .TE
        !          2159: .KE
        !          2160: .SH
        !          2161: Appendix IV - Sample Systems File
        !          2162: .LP
        !          2163: .KS
        !          2164: .TS
        !          2165: l l l l l l.
        !          2166: SITE   WHEN    CALLER  CLASS   CALLCODE        LOGIN
        !          2167: =
        !          2168: .T&
        !          2169: lFCW lFCW lFCW lFCW lFCW lFCW.
        !          2170: fonzie Any     ACU     D1200   MHd1234 ...
        !          2171: fonzie Any0631-0444    ACU     C1200   MH5678  ...
        !          2172: fonzie Any0631-0444;5  Micom   Any     fonz    ...
        !          2173: fonzie Wk1800-0600,Sa  Datakit,dg      unused  fonzie  ...
        !          2174: fonzie MoWeFr1300-1445 Ethernet,eg     unused  09      ...
        !          2175: fonzie Any     Direct  9600    tty42   ...
        !          2176: .TE
        !          2177: .KE
        !          2178: .BP
        !          2179: .SH
        !          2180: Appendix V - Heuristics Used by Uucleanup
        !          2181: .PP
        !          2182: At present, this is what is done:
        !          2183: .PP
        !          2184: For WARNING messages:
        !          2185: .IP
        !          2186: C. files of the age specified are read, looking for either user
        !          2187: files to be sent or received, or mail to be sent.  (Other
        !          2188: remote execution that does not involve sending user files
        !          2189: is not checked for now.)  In either of the cases, the user
        !          2190: is informed by mail that the request is not being processed
        !          2191: due to lack of communications with the remote system, and
        !          2192: the request will be deleted in the future if it the condition
        !          2193: remains for several more days.
        !          2194: .LP
        !          2195: For DELETIONS:
        !          2196: .IP "C. files -" 10
        !          2197: If they reference only D. files, the C. is merely deleted,
        !          2198: because the D. files are usually mail or news, and the later
        !          2199: D. processing will take care of them.
        !          2200: If they reference files from the file system,
        !          2201: a message is constructed that will contain lines like:
        !          2202: .P1 10n
        !          2203: We can't contact the remote.
        !          2204: 
        !          2205: local!file -> remote!otherfile
        !          2206: 
        !          2207: can't be executed.
        !          2208: .P2
        !          2209: .IP "X. files -"
        !          2210: These are merely deleted at present - D.s will be taken care of later.
        !          2211: Besides, some of the D.s are missing or else the X. wouldn't be
        !          2212: left around.
        !          2213: .IP "D. files -"
        !          2214: mail type data is sent to a local person if that is where it
        !          2215: was destined.  If not, it is returned to the sender -- assumed
        !          2216: to be from the first From line.  If a sender can't be determed,
        !          2217: the file is merely deleted.
        !          2218: .IP ""
        !          2219: netnews: if locally generated, just delete.  If remote, the X.
        !          2220: got lost, so execute rnews.
        !          2221: .IP "Other files -"
        !          2222: Just delete them.
        !          2223: .PP
        !          2224: Deletions and executions are logged.
        !          2225: .SH
        !          2226: Appendix VI - Example of a Uuxqt Error Report
        !          2227: .P1 0
        !          2228: remote execution       [uucp job allegraA60f1 (6/6-2:50:32)]
        !          2229:        rnews 
        !          2230: exited with status 1
        !          2231: 
        !          2232: 
        !          2233:        ===== stderr was =====
        !          2234: rnews: Cannot open /usr/spool/news/.sys (r) (From: harpo!decvax!pur-ee!iuvax!dcm).
        !          2235:        perror: No such file or directory
        !          2236: 
        !          2237: 
        !          2238:        ===== stdin was =====
        !          2239: From: harpo!decvax!pur-ee!iuvax!dcm
        !          2240: Newsgroups: net.unix-wizards
        !          2241: Title: uucp trap 9 ever fixed?
        !          2242: Article-I.D.: iuvax.119
        !          2243: Posted: Fri Jul  2 11:48:26 1982
        !          2244: Received: Sat Jul  3 00:54:31 1982
        !          2245: 
        !          2246: We (a VAX 4.1) are getting alot of trap 9s, probably from 
        !          2247: the bug mentioned in rv(4); has anyone ever fixed this?
        !          2248:                                pur-ee!iuvax!dcm
        !          2249: .P2
        !          2250: .BP
        !          2251: .SH
        !          2252: Appendix VII - Notes From Uucp Lovers Meeting
        !          2253: .FC
        !          2254: .2C
        !          2255: .PP
        !          2256: The first (and last) meeting of the uucp-lovers interest group
        !          2257: took place on 20 April 1983.
        !          2258: Invited were
        !          2259: allegra!honey, vax135!martin, eagle!karn, rabbit!ark, mhb5b!smb,
        !          2260: harpo!ber, cbosgd!mark, floyd!trb, research!rtm, and eagle!dan.
        !          2261: Others who showed up were representatives from USG,
        !          2262: mhtsa!lsc and mhtsa!brad,
        !          2263: whuxlb!pep and gummo!mmp.
        !          2264: The unexpurgated minutes follow.
        !          2265: .PP
        !          2266: .nf
        !          2267: From honey Wed Apr 20 00:46:26 1983
        !          2268: To: uucplovers
        !          2269: Subject: minutes
        !          2270: Cc: dmr doug
        !          2271: .PP
        !          2272: .ad l
        !          2273: pardon my editorial asides in what follows, the minutes of a meeting
        !          2274: called by levy to discuss uucp concerns.  attendants at today's
        !          2275: gathering of the clan were
        !          2276: .PP
        !          2277: .in +5n
        !          2278: eagle!dan, vax135!martin, ihnp4!gjm, gummo!ber, mhtsa!lsc,
        !          2279: mhb5b!smb, mhtsa!brad, eagle!karn, whuxlb!pep, and
        !          2280: allegra!honey
        !          2281: .PP
        !          2282: .in -5n
        !          2283: the first topic of discussion was the corporate electronic mail project
        !          2284: and its sidekick, network action central.  action appears to be jointly
        !          2285: administered through 452 (staff) and 774 (equipment and organizational
        !          2286: support).  murakami lent the impression that this was the beginning of
        !          2287: a permanent fixture w/in the labs and that any startup problems are
        !          2288: temporary.  the L.sys database is gradually falling together as new
        !          2289: data are collected and standards are promulgated.  discussion about the
        !          2290: means for handling the monthly L.sys produced a consensus that sites
        !          2291: should continue to maintain a local L.sys and that the local file should be
        !          2292: searched first, a la koenig, honeyman, and apparently everyone.
        !          2293: .PP
        !          2294: a lively discussion on uucp hacking consumed the major part of the
        !          2295: meeting.  there are as many versions of uucp as there are sites, with
        !          2296: the major contenders being usg 6.0, the new code by morris, and tom
        !          2297: truscott's hacks.  cohen grimly cautioned on the difficulty of getting
        !          2298: good stuff into 6.0, nonetheless, the company flag was raised, all
        !          2299: saluted, and we agreed to use the organizational heavy as a starting
        !          2300: point for producing a version that would satisfy all (and ourselves, in
        !          2301: particular).
        !          2302: .PP
        !          2303: the major enhancement proposed was a hashing scheme for the spool
        !          2304: directory.  while truscott uses separate directories for the C and D
        !          2305: files (as well as other files, i imagine), redman and others use the
        !          2306: names of the remote sites as the subdirectories.  lively discussion
        !          2307: ensued, during which a consensus was reached that the latter scheme was
        !          2308: more robust.  a proposal by levy that the hash function be based on a
        !          2309: short prefix of the machine name was met with interest.  while there
        !          2310: appears to be a problem with mkdir by setuid processes in usg, bellovin
        !          2311: patiently explained techniques to subvert this feature; after the third
        !          2312: or fourth go 'round, the meeting got back on track.  the feeling is
        !          2313: that cico or some daemon should do occasional rmdir's in the spooling
        !          2314: directory; ultimately there was not total agreement on all of the
        !          2315: mechanics of the hashing scheme, and i imagine the issue will be
        !          2316: discussed further in a manner fit for the information age.
        !          2317: .PP
        !          2318: a separate directory for the lock files was also proposed, a point on
        !          2319: which all were agreed, as this admits some gestures toward privacy made
        !          2320: impossible at present due to cu's use of lock files.  in addition,
        !          2321: nowitz and karn muttered about lock file aging.
        !          2322: .PP
        !          2323: while alan watt's code produces wild and amusing sequence numbers,
        !          2324: several people feel uncomfortable with his hacks.  a proposal for a
        !          2325: sequence file per system was propounded, but the necessity to shelter
        !          2326: several hundred seq files was judged problematic.  nowitz finally
        !          2327: suggested maintaining a single file with a separate sequence number for
        !          2328: each machine.  there were murmurs of assent over that, as well as the
        !          2329: suggestion that logging info be maintained per system, which everyone
        !          2330: wants to see reduced.  there was some agreement that morris's command
        !          2331: file per system is also a good idea, but out of its time.
        !          2332: .PP
        !          2333: there were several pleas for some sort of indexing scheme on L.sys.
        !          2334: karn has built weinberger's btrees on L.sys (but i predict problems
        !          2335: putting pjw's apparently top secret, company private hacks into system
        !          2336: VI), honeyman suggested dbm, while levy suggested a version of look.
        !          2337: it's too early to tell which way this one will go.
        !          2338: .PP
        !          2339: cohen reports that 6.0 incorporates all of the "known" bug fixes
        !          2340: (mcgeady's list, other netnoise reports), although honeyman, nowitz,
        !          2341: and redman immediately popped up with some "unknown" bugs.  (i remind
        !          2342: you all to #define NPLINES to 20 or so).  horton's recent note on
        !          2343: delays in the packet driver was discussed and duly deprecated.
        !          2344: .PP
        !          2345: a proposal to upgrade the DEBUG information was thrown out for
        !          2346: consideration whereupon it was thrown out for lack of interest.
        !          2347: .PP
        !          2348: finally, we agreed to take the most recent version of 6.0 uucp and hack
        !          2349: it into an unrecognizable state (i.e. remove the bugs, and make it work
        !          2350: well).  honeyman commandeered conn.c, redman got the spooling hacks,
        !          2351: levy was volunteered to write an L.sys editor and help murakami
        !          2352: standardize the action L.sys, and bellovin accepted the responsibility
        !          2353: for putting the spool directory mods into uuxqt.  cohen pointed out
        !          2354: that usg is unlikely to appreciate anything that falls under the ucb
        !          2355: umbrella, while nowitz argued against reliance on ifdefs.  the feeling
        !          2356: was that we can hide the idiosyncrasies in a single file and mask our
        !          2357: efforts as a gesture toward version 7 compatibility, a transparent
        !          2358: but innocent falsehood.  in any case, this issue is peripheral.
        !          2359: .PP
        !          2360: the final topic on the agenda was the corporate attempt at security
        !          2361: consciousness raising; a shouting match ensued, in the course of which
        !          2362: several and various reputations were sullied, certain paranoid
        !          2363: reactions were taken less than seriously, and no great meeting of the
        !          2364: minds was met.  honeyman argued in favor of mcilroy's position against
        !          2365: allowing remote machines to pull files, falling back on a position that
        !          2366: denied this capacity to all but a local cluster, falling further back
        !          2367: on a suggestion that permits files to be pulled from a directory other
        !          2368: than uucppublic (so that one remote site can't pull a file that another
        !          2369: remote site has sent).  redman pointed out that the only information
        !          2370: worth protecting in L.sys is the phone number (certainly the least
        !          2371: secure piece of data).  redman solicits opinions on the forthcoming GEI
        !          2372: regulations.
        !          2373: .PP
        !          2374: upon notable growlings of empty stomachs, a decision was made to
        !          2375: adjourn to a local chinese restaurant, in the time honored tradition of
        !          2376: uucp hackers everywhere.  this decision was subsequently rescinded in
        !          2377: favor of the oak room (constituting an unpropitious omen).
        !          2378: .in -5n
        !          2379: .ad b

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.