researchv10dc/vol2/uucp/history.ms - annotate

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

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

unix.superglobalmegacorp.com

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