In an attempt to keep corrections with the documents, I was wondering if we could put some pertinent notes in the same directory as the .mss file. Subject: New improved way of printing RS1 graphs (no screendumps!) I thought you all should know about this. Even a casual glance at the olc logs reveals that people are having a tough time printing RS1 graphs due to various lossage with screendumps and tektronix emulating xterms, and even if they get beyond that there is the problem that screen dumps cause the postscript printers to really crunch (including the LPS40's). Well, there is a better way, and I think we should do all we can do to publicize it. And as amazing as it may sound, it only uses supported software and is very easy! Here's what you do: From RS1: set plotter = 't4010' plot on file 'name.tek' From the shell: ps4014 name.tek | lpr -P The program ps4014 (which lives in /usr/athena and even has a man page!) converts tektronix commands into postscript commands. It does a much better job than a window dump because it has more structure to work with (instead of just a bunch of pixels). I've tried a few graphs of normal complexity and they take between one and two minutes to print on a postscript LN03, which is a lot less than a screendump would take. They also look very very very much better than window dumps do. What'ca think? -- Jon Subject: path name confusion in E. Workstation On p. 18 is the line: cp -r /foo/bar ~username Foo implies something the user created, atleast to the user world. Users see things like usr,mit,dev, and site. It may have been better to remind what the '/' directory is. A user was confused over this point. Subject: for the pile for Essential C Subject: Tricky xswitch problem I've been having difficulty in doing xswitch lately. Even after re-naming .Xdefaults file and zlogout, xswitch would hang the workstation on me. This happened on vsII's and vs2000's. Eventually I figured it out, though. I had an executable in my directory named 'echo' which would not run under tcsh unless I typed ./echo. However, I think xswitch must try to use it and it got my 'echo' instead of the real system 'echo'. After deleting my binary, everything was fine. This is something worth checking since the use of 'Essential C' could result in the creation of an executable named 'echo', as it did with me. Subject: rs1.ess notes Subject: RS/1 handouts Gary, Thanks for the Slides. The course went well. The following are the handouts I created to give 'updated' information about RS/1. Feel free to use them in any revisions you are making, or ask me questions about them. - - ------------------------------------------------------------------------ @Device(PostScript) @Style(FontFamily NewCenturySchoolBook, Size 13) @Modify(Example, Size 11, LeftMargin 1 cm, RightMargin 1cm) @MajorHeading(First Time Only) @begin(Enumerate, Spread 2) Create an RS/1 Home Directory. @begin(Example) % mkdir ~/rs1home @end(Example) Set the environment variable in @i{.login}, if it doesn't already exist. @begin(Example) % emacs .login & setenv RS1HOME ~/rs1home # RS/1 Home Directory @end(Example) Create an alias for using rs1 in your @i{.cshrc}. @begin(Example) @p[C-x C-f] .cshrc alias xrs1 'xterm -fn 9x15 =84x38-0+0 %-0+0 -n RS/1 -e rs1 &' @p[C-x C-c] @end(Example) Execute the @i{setenv} command. @begin(Example) % source ~/.login @end(Example) Enter RS/1. @begin(Example) % rs1 @end(Example) Tell RS/1 you have 80 column printers. @begin(Example) # set printer to 'lpt80' @end(Example) Tell RS/1 to printout plots with t4010 commands. @begin(Example) # set printer to 't4010' @end(Example) Tell RS/1 to use an Emacs in the upper corner of the screen. @begin(Example) # set editor_name to '/usr/athena/emacs -q -w =80x24-1+1' @end(Example) Leave RS/1. @begin(Example) # logout @end(Example) @end(Enumerate) @NewPage() @MajorHeading(Using RS/1) @begin(Enumerate, Spread 2) Change to Xversion 10, so you can use Tektronix mode. @begin(Example) % xswitch Confirm: Hit return to switch to X10 (all current X processes will die) or hit ^C to remain where you are: @end(Example) @Begin(Box) @p[Warning:] This will kill off all currently running X programs. You need to restart your window manager with: @begin(Example) % uwm & % @end(Example) @End(Box) Start up RS/1 in a separate window -- normal, VT100 mode. @Begin[Example] % xrs1 @i{or} % xterm -fn 9x15 =84x38-0+0 %-0+0 -n RS/1 -e rs1 & % @End[Example] Set terminal type to @ux[vt100]. @begin(Example) # terminal = 'vt100' @end(Example) When you want to do a graph, switch to Tektronix mode by pressing the @b[MIDDLE] mouse button on the Title bar. While holding the button down, move to the item ``Select Tek mode'', then release. This will @i{pop} the Tektronix window if it exists, or create it if it doesn't. Then, you must inform RS/1 of what you have done. @begin(Example) # terminal ='t4010' @end(Example) Do the same thing with ``Select VT mode'' when you wish to switch back. Exiting RS/1 will also kill off the window. @begin(Example) # logout @end(Example) @end(Enumerate) @Bar() If RS/1 exits abonormally, or refuses to start up, try using @b[rs1fix]. @begin(Example) % rs1fix @end(Example) @Newpage() @MajorHeading(Printing out Tables and Graphs from RS/1) The general procedure for getting hardcopy output from RS/1 is to create a file from within RS/1. These commands are analogous to the @b[DISPLAY] command, with the added arguement @b[on file]. The file is a valid UNIX filename, hence it is case sensitive and also must be enclosed in quotes. The procedure is to first create the file from RS/1, then print it out from UNIX. This is one reason why it is nice to have two windows. There are three different cases: @begin(Enumerate, Spread 2) To get a UNIX file of a table, use the @b{printout} command. It takes the usual arguements: noheader, nocolnumbers, norownumbers, etc. @begin(Example) # printout table foo noheader on file 'foo' % lpr -P@i{printer} foo @end(Example) You can print extra large tables by specifying 132 columns and then using @b[enscript] from UNIX. @begin(Example) # set printer to 'lpt132' # printout table longfoo on file 'lfoo' % enscript -r -P@i{printer} lfoo @end(Example) Be sure to change back to 'lpt80' for regular tables. To obtain a hardcopy of a graph, first print it out with Tektronix commands. Then use @b[ps4014] to conver it to PostScript output. Note that you can use this command even if not in Tektronix mode, so it will work under X version 11. @begin(Example) # plot graph foo bottomkey on file 'foo.tek' % ps4014 foo.tek | lpr -P@i{printer} @end(Example) @end(Enumerate) @NewPage() @MajorHeading(Curve fitting ) There are three principal types of fits: line, polynomial, and function. They are all of the form: @begin(Example) # fit @i{type} to curve @i{n} of graph @i{name} @end(Example) where @i{type} can be: @begin(Enumerate) line polynomial of degree @i{m} function ``@i{f(x; a, b, c...)}'' @end(Enumerate) Examples: @begin(Enumerate, Spread 2) @begin(Example) # fit line to curve 2 of results @end(Example) @begin(Example) # fit polynomial of degree 3 to graph foobar @end(Example) @begin(Example) # fit function ``a*(exp((b-x/c))+tanh(-c/x))'' to - Continuation# curve 4 of graph tesla @end(Example) @End(enumerate) Subject: usenix papers. [LONG] the following is the hesiod paper. it requires the athena refer file, and tbl. #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create: # hesiod # This archive created: Mon Jan 4 21:28:10 1988 export PATH; PATH=/bin:/usr/bin:$PATH echo shar: "extracting 'hesiod'" '(24875 characters)' if test -f 'hesiod' then echo shar: "will not over-write existing file 'hesiod'" else sed 's/^ X//' << \SHAR_EOF > 'hesiod' X.TL XThe \f(BIHesiod\fR\s-1*\s0\fB Name Server X.FS X\s-1*\s0 n. 8th century B.C. Greek poet. The names of the Gods and Xthe myths surrounding them are recorded in his poetry. X.FE X.AU XStephen P. Dyer X.AI XProject Athena XMassachusetts Institute of Technology XCambridge, MA 02139 Xdyer@ATHENA.MIT.EDU X.AB X\fIHesiod\fR, the Athena name server, provides naming for services and Xdata objects in a distributed network environment. More specifically, Xit replaces Xdatabases that heretofore have had to be duplicated on each workstation Xand timesharing machine (e.g., remote file system information, X\fI/etc/printcap\fR, \fI/etc/services\fR, \fI/etc/passwd\fR, \fI/etc/group\fR) Xand provides a flexible mechanism to supply new information Xas the need arises. X.AE X.2C X.NH XIntroduction and Purpose X.PP XThe computing enviroment at Project Athena has recently changed Xfrom a group of timesharing machines to a collection of file servers Xand many hundreds (and potentially many thousands) of publically-accessible Xworkstations. The origins of X.UX Xas a time-sharing system become acutely Xobvious when confronted with the need to Xmanage information for hundreds of machines that may be Xused by many different individuals. The method used by X.UX Xto maintain information for its users and programs has been ASCII Xdatabase files stored on each machine which are authoritative Xfor all users of that machine. XHowever, this breaks down when the number of machines and potential Xusers are multiplied Xby two or three orders of magnitude. The system management effort Xto keep each machine's information current grows directly as the number of Xmachines; this quickly becomes unworkable with more than a few Xdozen machines. We wanted a solution that could easily accomodate XAthena's expected growth for the next 5 years. X.PP XRather than having information duplicated on each machine, the Xconcept of retrieving information via a network service, a \fIname server\fR, Xhas proved workable and reliable. Xerox's \fIClearinghouse\fR, X.[ XXEROX X.] XSun's \fIYellow Pages\fR X.[ XSunYP X.] Xand the Internet Domain Name Server X.[ XMock1 X.] X.[ XMock2 X.] Xare examples of Xname services in current use. We chose to base our name service, X\fIHesiod\fR, on the Berkeley Internet Domain Name Server, BIND, X.[ XBIND X.] Xfor several reasons. First, the design had proved itself Xthrough its use in the Internet over the past several Xyears, and it had a number of features that made it an attractive Xbase for \fIHesiod\fR: its hierarchical name space, the ability Xto delegate authority to subsidiary name servers, and the ability Xto take advantage of local caching of data to improve performance. XSecond, the BIND source code was readily available and Xprovided a firm foundation for a more general name service; Xwe did not have to spend time building low-level support facilities Xwhich it already provided. XFinally, BIND source code is non-proprietary, which would facilitate our Xdistribution of \fIHesiod\fR to other interested sites. X.PP X\fIHesiod\fR provides a name service for use by workstations Xand timesharing systems. It does not address the problems of Xcentralized management and Xdistribution of such information, which is provided by another Xservice, the Athena Service Management System, or SMS. X.[ XSMSUsenix X.] XSMS maintains and distributes information managed by Athena Operations Xto each of the Athena \fIHesiod\fR name servers. X\fIHesiod\fR may be used without SMS; neither is Xdependent on the other. However, without an information Xmanagement system front end, the \fIHesiod\fR databases are simply XASCII files in BIND-compatible resource records format that Xmust then be managed with a text editor. Large sites may appreciate Xthe convenience SMS provides, while smaller sites Xmay opt for the simplicity of using \fIHesiod\fR without SMS. X.PP X\fIHesiod\fR provides a Xcontent-addressible memory where certain strings can be mapped to Xothers depending on the query. \fIHesiod\fR has no Xknowledge about the data it stores; queries and responses are Xsimple key/content interactions. XIt is designed to be used in situations where a small amount Xof data that changes infrequently needs to be retrieved quickly, with little Xoverhead. It is not intended to serve as a general-purpose database Xsystem supporting arbitrary queries, or as a repository for information Xthat changes frequently. The current implementation Xprovides no facility for an arbitrary Xapplication to update the \fIHesiod\fR database, which is Xrefreshed several times Xa day by the Athena SMS. Because of the limitation imposed by the Xunderlying implementation of \fIHesiod\fR, based as it is on the Internet Xdomain naming scheme, there is a maximum length of 512 bytes of Xdata that can be exchanged between the client and the name servers Xusing UDP datagrams. This imposes Xlimits on both the maximum size of an individual data record, as well as Xthe number of records that can be returned in a single packet in the Xcase of multiple matches. \fIHesiod\fR was designed to provide applications Xwith a rapid, low-overhead naming service in which a query would return Xno more than a few matches of limited size. Applications that Xrequire more complicated queries or ones that return voluminous Xdata should consider interfacing to SMS. X.NH X\f(BIHesiod\fB Queries X.PP XA \fIHesiod\fR query consists of two parts, a \fIHesiodName\fR, which is the Xname of an object in the network, and a \fIHesiodNameType\fR, an Xapplication-specific Xqualifier that identifies the application space in which that Xobject is named. X.PP XWe do not use standard Internet Domain Name notation to Xrefer to \fIHesiodNames\fR for several reasons: XFirst, we wish to have Xobjects with name containing the '.' character.\(dg X.FS X\(dg As just one example, MIT course names, such as \fI6.001\fR, contain periods. X.FE XIn Internet domain notation, a name that contains a '.' is considered fully Xresolved. Second, early BIND implementations Xhad no provision for deciding the proper domain suffix to use when Xresolving a relative name. X.PP XA name given to the \fIHesiod\fR name server for resolution looks like: X.nf XHESIODNAME => LHS XHESIODNAME => LHS@RHS XLHS => [Any ASCII character, except NUL and '@']* X { 0 or more characters from this alphabet } XRHS => [Any ASCII character, except NUL and '@']+ X { 1 or more characters from this alphabet } X.fi X.LP XIn other words, a \fIHesiodName\fR consists of [LHS][@RHS] Xwhere either [LHS] or [@RHS] need not be present. X.PP XThe LHS of a \fIHesiodName\fR is \fIuninterpreted\fR; although it may be Xmodified according to the rules described by the information in X\fI/etc/hesiod.conf\fR (see below), it is not itself a domain name. X.PP XWe define a set of routines known as the \fIHesiod\fR library that take two Xstrings, a \fIHesiodName\fR and a user-supplied key, a \fIHesiodNameType\fR, Xconvert it to a Xfully-qualified domain name, call the BIND library, and return the Xresults to the original caller. XThe \fIHesiodNameType\fR is Xa well-known string that is provided by an application that Xuses the \fIHesiod\fR library. It is used directly in the expansion of a \fIHesiod\fR Xname to a BIND name (see below) without further indirection or translation. XA new \fIHesiodNameType\fR comes into existence simply by being used Xby an application; no libraries or configuration files need to be modified. XNaturally, there has to be appropriate data stored by the name server Xwhich is associated with that \fIHesiodNameType\fR. X.PP XTo provide an example, one of the routines in the \fIHesiod\fR library takes a X\fIHesiodName\fR and returns a fully-qualified name to be handed to BIND: X.nf X.in +2 X\fCchar * Xhes_to_bind(HesiodName, HesiodNameType) Xchar *HesiodName, *HesiodNameType;\fR X.fi X.in -2 X.PP XThe \fIHesiodNameType\fR Xidentifies the query to make to BIND and the proper expansion Xrules to use with the LHS and RHS of the name. This would be chosen by Xthe application, and could be application-specific. X.PP XThus, the following are valid \fIHesiodNames\fR: X.nf X.in +2 X14.21 Xdefault-printer Xdefault-printer@SIPB X@heracles X@heracles.MIT.EDU Xkerberos@Berkeley.MIT.EDU X.in -2 X.fi X.LP XThe configuration file \fI/etc/hesiod.conf\fR contains two tables specifying the treatment of XLHS and RHS components of a \fIHesiodName\fR. In the translation of a X\fIHesiodName\fR to a valid BIND name, the LHS is expanded by concatenating Xtogether the \fIHesiodName\fR, the separator '.', the HesiodNameType, Xand the LHS entry found in the configuration files. XIf the RHS is null, the RHS entry in the configuration file is used. XIf the RHS is a fully qualified domain name already, it is used directly. XOtherwise, if a RHS is present, Xit is used as a \fIHesiodName\fR for further Xresolution against the \fIHesiodNameType\fR, "rhs-extension". XIf this query succeeds, the first reply is used as the RHS, Xotherwise an error is Xreturned. XThe fully-expanded LHS and RHS are then Xconcatenated together, separated by a '.', and this value is passed to BIND Xfor resolution. X.PP XThe following is a typical copy of \fI/etc/hesiod.conf\fR: X.nf X.in +2 X.sp X#file /etc/hesiod.conf X#comment lines begin with a '#' in column 1 X#LHS table Xlhs = .ns X#RHS table Xrhs = .Athena.MIT.EDU X.sp X.fi X.in -2 X.PP XWith this definition, Xa call to \fBhes_to_bind\fR("e40", "printer") Xwould Xproduce a LHS of "e40.printer.ns" and a RHS of ".athena.MIT.EDU", and the Xresulting BIND name, "e40.printer.ns.Athena.MIT.EDU". X.PP XIn C pseudo-code, we would have the following productions: X.nf X \fBhes_to_bind\fR("14.21, "filesys") => X "14.21.filesys.ns.Athena.MIT.EDU" X \fBhes_to_bind\fR("e40, "printer") => X "e40.printer.ns.Athena.MIT.EDU" X \fBhes_to_bind\fR("SIPB, "rhs-extension") => X "SIPB.rhs-extension.ns.Athena.MIT.EDU" X \fBhes_to_bind\fR("default@SIPB", "printer") => X "default.printer.ns.SIPB.MIT.EDU" X (this assumes that the previous production X resolved to "SIPB.MIT.EDU") X \fBhes_to_bind\fR("kerberos@Berkeley.EDU", "sloc") X => "kerberos.sloc.ns.Berkeley.EDU" X.fi X.LP XThese productions are then passed to the BIND name server for resolution. X.NH XData Types X.PP X\fIHesiod\fR data are stored as Internet domain resource records. A new class, XHS, signifying a \fIHesiod\fR query or datum has been reserved, and Xa new query type, TXT, that allows the storage of arbitrary ASCII strings. XPaul Mockapetris, the Internet Domain System designer, has recently Xspecified the HS class and the TXT type in RFCs 1034 and 1035. X.NH XBIND Requirements X.PP XA version of BIND that supports the HS Xquery class and TXT query type is required to Xsupport the \fIHesiod\fR name service. The latest release of BIND as Xof 12/31/1987, version 4.7.3, has been modified at Athena Xto support this, and we will be forwarding these changes to Berkeley Xfor future releases of BIND. X.NH XAthena Client Applications of \f(BIHesiod X.PP XMany applications and subroutines have been modified to take advantage of Xthe \fIHesiod\fR service. See Appendix A for an enumeration of Xsome of the \fIHesiodNameTypes\fR in common use within Project Athena. X.PP XThe \fIattach\fR program queries \fIHesiod\fR for the filesystem Xwith the given name, retrieves the data, and mounts the appropriate RVD Xor NFS X.[ XSUNNFS X.] Xfilesystems, while also authenticating the user Xto the file server using \fIKerberos\fR. X.[ XKTech X.] X.PP X\fILogin\fR uses the user's login name as a X\fIHesiodName\fR to retrieve the user's \fI/etc/passwd\fR and Xgroup membership information. XThe actual password field is not used; rather the \fIKerberos\fR Xservice authenticates the user. \fILogin\fR queries \fIHesiod\fR Xto determine which \fIKerberos\fR server to invoke. XBy convention, the username is also the name of the user's default Xfilesystem. XThe \fIlogin\fR program runs the \fIattach\fR program (\fIq.v.\fR) Xwith the user's login name as an argument to mount the user's Xhome directory. X.PP XAthena users receive their mail on POP X.[ XPOP X.] X(post-office protocol) servers. XWe have modified the MH Xprograms \fIinc\fR and \fImsgchk\fR to Xquery \fIHesiod\fR for the location of the user's POP server. X.PP XThe \fIlpr\fR program is compiled with a special version of the X\fI/etc/printcap\fR access library that queries \fIHesiod\fR if Xthe printer name cannot be found in the local \fI/etc/printcap\fR. X.PP XThere are optional implementations of \fBgetpwnam()\fR, \fBgetgrnam()\fR, and Xtheir inverse counterparts that query \fIHesiod\fR for name-to-UID, Xname-to-GID translation, and vice-versa. The same library includes Xan implementation of \fBgetservent()\fR that queries \fIHesiod\fR Xin preference to lookup in the file \fI/etc/services\fR. X.NH X\f(BIHesiod\fB Resource Records and Data Files X.PP XAppendix B lists samples of the resource records that we store Xon behalf of \fIHesiod\fR client applications. The format of the XASCII strings returned by \fIHesiod\fR is application-specific. XIn the case of queries that have an inverse operation, such as Xqueries with the \fIHesiodNameTypes\fR, \fBpasswd\fR, and \fBuid\fR, Xthe \fBuid\fR resource records are \fICNAMEs\fR for the corresponding X\fBpasswd\fR records. X.PP XThe BIND boot file on each workstation, \fI/etc/named.boot\fR, Xrefers to an auxiliary Xcache file, \fI/etc/named.hes\fR, that specifies the authoritative Xname servers for \fIHesiod\fR queries. X.NH XProgramming with the \f(BIHesiod\fB Library X.PP XThere are only two subroutines, \fBhes_resolve()\fR and \fBhes_error()\fR, Xthat are usually invoked by the Xapplications programmer when using \fIHesiod\fR. The subroutine X\fBhes_resolve()\fR Xis the primary interface into the \fIHesiod\fR Xname server. It takes two string arguments, the Xname to be resolved, the \fIHesiodName\fR, and a type Xindicating the type of service associated with this name, Xthe \fIHesiodNameType\fR. X\fBhes_resolve()\fR Xreturns a pointer to an array of strings, Xmuch like \fBargv[]\fR, Xcontaining all the data that matched the query, one match per Xarray slot. The array is NULL terminated. XA second call to X\fBhes_resolve()\fR Xwill overwrite any previously-returned data, so applications that Xrequire data to be maintained across multiple calls to X\fBhes_resolve()\fR Xshould copy the returned values into data areas they maintain. X.PP XNote that a call to X\fBhes_resolve()\fR Xmay return more than one match. The semantics of Xusing or choosing between multiple matches Xis dependent on the particular application. In general, however, Xmultiple matches are considered "equivalent", and any of them Xcould be used equally well. This is exploited, for example, by the X\fIattach\fR command that attaches a remote file system to the Xworkstation. In the case of system libraries, multiple copies of which Xare considered equivalent, the Xattach command iterates through all matches, stopping after the first Xsuccessful attach. Because \fIHesiod\fR is based on the Internet XDomain Naming scheme, no interpretation can or should be given to the order Xin which matches are returned. X.PP XIf X\fBhes_resolve()\fR Xreturns NULL, then no data could be found, either Xbecause the name server had no matching records or an error occurred. XThe function \fBhes_error()\fR takes no arguments and Xreturns a small integer indicating the Xtype of error, if any, encountered in the last call to X\fBhes_resolve()\fR. X.PP XIt is important to emphasize that \fIHesiod\fR knows nothing about the data Xit stores; any meaning given to the \fIHesiodName\fR, the \fIHesiodNameType\fR Xand the Xdata returned by \fIHesiod\fR is completely imposed by the application. XThe format of the data stored by \fIHesiod\fR is application-specific, Xand would be defined by the application programmer. X.KS X.nf X.sp X\fC#include X Xchar *HesiodName, *HesiodNameType; Xchar **hp; X Xhp = hes_resolve(HesiodName, HesiodNameType); Xif (hp == NULL) { X err = hes_error(); X switch(err) { X . X . X . X } X} else { X /* do your thing with hp */ X while(*hp != NULL) process(*hp++); X}\fR X.fi X.KE X.PP XThe error values returned by \fBhes_error()\fR are one of the following: X.in +2 X.nf X.sp X\fC#define HES_ER_UNINIT -1 X#define HES_ER_OK 0 X#define HES_ER_NOTFOUND 1 X#define HES_ER_CONFIG 2 X#define HES_ER_NET 3\fR X.in -2 X.sp X.fi X.LP XThe most common values returned by \fBhes_error()\fR are HES_ER_OK, Xmeaning no error, and HES_ER_NOTFOUND, meaning that the desired Xname was not found in the \fIHesiod\fR data base. XHES_ER_CONFIG indicates a problem Xwith the optional per-machine \fIHesiod\fR configuration file, \fI/etc/hesiod.conf\fR. XHES_ER_UNINIT will never be returned by \fBhes_error()\fR, unless it Xis called before the first time \fBhes_resolve()\fR is called. XHES_ER_NET indicates that the request never received a response from Xthe \fIHesiod\fR name server. This can be due to a variety of network Xproblems: for example, the host making the request might be disconnected Xfrom the network, an intervening gateway might be down, or Xno \fIHesiod\fR name servers responded. No further information about Xthe state of the network is available because the Xdomain system on which \fIHesiod\fR is based uses datagrams with retries Xas the communications interface. X.PP XHES_ER_NOTFOUND is a negative acknowledgement indicating that the desired Xname/\fIHesiodNameType\fR pair was not found in the \fIHesiod\fR Xdatabase. An application receiving this error message can Xconsider this an authoritative response. Of course, this may be Xdue to an omission in the database, or simply reflect a delay Xbetween the time \fIHesiod\fR data was asked to be placed into the Xdatabase, and the actual \fIHesiod\fR updates, which occur several times Xeach day. X.PP XIn the case of a \fIHesiod\fR error of HES_ER_NET, it may be prudent Xfor an application to assume that this situation is temporary, and Xthat a later call to \fBhes_resolve()\fR will either return the desired data Xor a definitive reply of HES_ER_NOTFOUND. XHES_ER_CONFIG indicates a problem with the \fIHesiod\fR configuration Xfile, a situation that requires intervention by a wizard and Xwill not resolve itself spontaneously. Because no query to the X\fIHesiod\fR name server is actually made, no conclusion can Xbe drawn about the validity of the name to be resolved. The standard Athena Xdistribution of the \fIHesiod\fR library does not require a configuration Xfile; its built-in defaults suffice, so this situation should not be Xencountered frequently. X.PP XA general design strategy for applications using \fIHesiod\fR is to have Xa contingency plan in place in case \fIHesiod\fR does not respond, Xis configured incorrectly or does not know the name. This may be Xbuilt-in to the application, such as new versions of \fIlpr\fR that Xrevert to using the old printcap libraries if X\fIHesiod\fR printer information is not available. Another popular scheme, exploited Xby the \fIMH\fR application \fIinc\fR and the EMACS tool, \fImovemail\fR, is to Xallow the value of an environment variable, in this case, \fBMAILHOST\fR, to Xoverride the call to \fIHesiod\fR to retrieve a person's mailhost, using his username Xas the key. Thus, a user can temporarily "hard-wire" appropriate Xvalues to allow applications to proceed. Not every application can Xbe programmed in such a fashion, but it is prudent to try to design Xapplications with this in mind. X.NH XDatabase Size and Performance X.PP XA measure of how successful \fIHesiod\fR has been in its Xdeployment over the past six months is how infrequently Xproblems have appeared. For the most part, applications make X\fIHesiod\fR queries and receive answers with millisecond delays. XToday, the \fIHesiod\fR database for Project Athena Xcontains almost three megabytes of data: roughly 9500 \fI/etc/passwd\fR Xentries, 10000 \fI/etc/group\fR entries, 6500 file system entries and X8600 post office records. There are three primary \fIHesiod\fR Xnameservers distributed across the campus network. X.PP XBIND has proven itself remarkably robust in Xaccomodating such a large, monolithic database. One problem has been Xnoticed: the time to load the Xprimary nameservers (which are updated from the Athena SMS every six hours) has Xincreased markedly as the size of our data has grown. XAt this point, it takes approximately 20 minutes Xto reload a primary nameserver running on a VAX 750 Xand each primary nameserver's working set is Xapproximately 10 megabytes. XBy staggering the times to reload each of the primary \fIHesiod\fR servers, Xthis has not proved to be Xa large operational problem. However, it does point out an area that should Xbe examined for improved performance. XBecause the \fIHesiodNameType\fR component in Xthe domain name passed to BIND identifies a potentially Xseparate start of authority, the X\fIHesiod\fR database could be split across two or more primary nameservers, Xeach authoritative for a subset of the full database. This Xwould reduce the time to load each nameserver and the size of its working set. X.NH XAcknowledgements X.PP XJerry Saltzer, Technical Director of Project Athena, Xprovided a great deal of assistance and guidance Xin the design of the \fIHesiod\fR name server. Thanks, too, go to Dan Geer Xand Jeff Schiller for their assistance during the design and deployment Xstages. Clifford Neuman, presently at the University Xof Washington, and Felix Hsu of Digital Equipment Corporation Xparticipated in the early design of the system. X.NH XReferences X.[ X$LIST$ X.] X.br X.1C X.SH XAppendix A: \f(BIHesiodNameTypes\fB in Use at Athena X.PP XHere is a list of some of the presently-defined HesiodNameTypes, the type of Xinformation provided as a \fIHesiodName\fR, and the applications programs that Xuse such queries. X X.TS Xbox; Xc c c c X---- Xl l l l. X\fIHesiodName\fR \fIHesiodNameType\fR Used By Info Returned X Xworkstation name "cluster" \fIgetcluster\fR workstation cluster information Xfilesystem name "filsys" \fIattach/detach\fR RVD and NFS file system info Xusername "pobox" MH \fIinc/movemail\fR location and type of mailbox Xusername "passwd" \fItoehold/login\fR Athena-wide /etc/passwd entry X \fBgetpwent()\fR, \fIet. al.\fR Xuid (ASCII) "uid" \fBgetpwent()\fR, \fIet. al.\fR Athena-wide UID to username mapping Xgroup name "group" \fBgetgrent()\fR, \fIet. al.\fR Athena-wide /etc/group entry X (no membership list) Xgroup name "grplist" \fBgetgrent()\fR, \fIet. al.\fR Athena-wide group membership mapping Xgid (ASCII) "gid" \fBgetgrent()\fR, \fIet. al.\fR Athena-wide GID to group name mapping Xprinter name "pcap" \fBpgetent()\fR Athena-wide /etc/printcap entry Xservice name "service" \fBgetservent()\fR Athena-wide /etc/services entry Xservice name "sloc" \fIOn-Line Consulting (OLC)\fR Host name to contact for this service X \fIKerberos\fR (for those services that do not reside on every host) X.TE X.bp X.SH XAppendix B -- Sample Resource Records from Current \f(BIHesiod\fR Database Files X.LP X.nf X\fC# filsys.db X# format of data is X# filesystem-type name-on-server server-hostname mount-mode mount-point Xdyer.filsys HS TXT "NFS /mit/dyer eurydice w /mit/dyer" Xdyfeigen.filsys HS TXT "NFS /mit/lockers/dyfeigen zeus w /mit/dyfeigen" Xdyim.filsys HS TXT "NFS /mit/lockers/dyim zeus w /mit/dyim" Xbldg1-rtsys.filsys HS TXT "RVD rtsys oath r /srvd" Xbldg1-rtsys.filsys HS TXT "RVD rtsys persephone r /srvd" X X# gid.db X# format of data is X# canonical name with this group id X481.gid HS CNAME 10.01.group X483.gid HS CNAME 10.01a.group X484.gid HS CNAME 10.01b.group X639.gid HS CNAME 10.01sa.group X640.gid HS CNAME 10.01sb.group X638.gid HS CNAME 10.01t.group X X# group.db X# format of data is X# /etc/group entry X10.01.group HS TXT 10.01:*:481: X10.01a.group HS TXT 10.01a:*:483: X10.01b.group HS TXT 10.01b:*:484: X10.01sa.group HS TXT 10.01sa:*:639: X10.01sb.group HS TXT 10.01sb:*:640: X10.01t.group HS TXT 10.01t:*:638: X X# grplist.db X# format of data is X# groupname1:gid1:groupname2:gid2:... X10.01.grplist HS TXT "10.01:481:10.01t:638" X10.01ta.grplist HS TXT "10.01t:638" X X# passwd.db X# format of data is X# /etc/passwd entry Xdyer.passwd HS TXT "dyer:*:17287:101:Steve Dyer,,,,:/mit/dyer:/bin/csh" X X# pobox.db X# format of data is X# post-office-type server-host-name mailbox-name Xdyer.pobox HS TXT "POP E40-PO.MIT.EDU dyer" X X# printcap.db X# format of data is X# /etc/printcap entry Xnil.pcap HS TXT "nil|LPS-40:rp=nil:rm=castor.mit.edu:sd=/usr/spool/printer/nil:" X.bp X# service.db X# format of data is X# service-name protocol port-number Xdiscard.service HS TXT "discard tcp 9" Xdiscard.service HS TXT "discard udp 9" Xnntp.service HS TXT "nntp tcp 119" X X# sloc.db X# format of data is X# host name where this service is offered Xzephyr.sloc HS TXT ARILINN.MIT.EDU Xzephyr.sloc HS TXT NESKAYA.MIT.EDU Xzephyr.sloc HS TXT ORPHEUS.MIT.EDU Xzephyr.sloc HS TXT PRIAM.MIT.EDU X X# uid.db X# format of data is X# canonical name with this user id X17287.uid HS CNAME dyer.passwd SHAR_EOF if test 24875 -ne "`wc -c < 'hesiod'`" then echo shar: "error transmitting 'hesiod'" '(should have been 24875 characters)' fi fi exit 0 # End of shell archive ------- Message 2 the following is the xtoolkit paper. it requires the athena refer file. the two figures are in postscript. - --dan #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create: # xtk # xtk.fig1.PS # xtk.fig3.PS # This archive created: Mon Jan 4 21:36:51 1988 export PATH; PATH=/bin:/usr/bin:$PATH echo shar: "extracting 'xtk'" '(40797 characters)' if test -f 'xtk' then echo shar: "will not over-write existing file 'xtk'" else sed 's/^ X//' << \SHAR_EOF > 'xtk' X.de BC X.mc \(bv X.. X.de EC X.mc X.. X.hw wid-get Radio-Button-Box com-pos-ite Scrolled-Ascii-Text X.\".TL X.\"\-For Review Only\- X.\".br X.\"Draft 1.10.1 X.\".br X.\" X.\".br X.TL XThe X Toolkit: More Bricks for Building User-Interfaces X.br X\-or\- X.br XWidgets For Hire X.sp 3 X.AU XRalph R. Swick X.AI XDigital Equipment Corporation XProject Athena XMassachusetts Institute of Technology XCambridge, MA 02139 Xswick@ATHENA.MIT.EDU X.AU XMark S. Ackerman X.AI XProject Athena XMassachusetts Institute of Technology XCambridge, MA 02139 Xackerman@ATHENA.MIT.EDU X X.AB XPrimitives for application-level user interface construction Xfacilities currently under development at M.I.T. Project Athena are Xdescribed. The design philosophy of the X Toolkit and associated Xwidgets and Xsome of Xthe practical implications are discussed. X.AE X X.2C X.SH XIntroduction X X.PP XThe X Window System\f1\(dg\fP X.[ XXProtocol X.] X.[ XXACM X.] X.\"[1,2] X.FS X\(dg \fBThe X Window System\fP and \fBX Windows\fP are trademarks of the XMassachusetts Institute of Technology. Use of the latter Xis strongly discouraged. The developers prefer simply "\fBX\fP" when Xa shorter form is required. X.FE Xwas developed at the Massachusetts Institute of Technology to Xsatisfy the needs of a broad spectrum of users for a high-performance, Xhigh functionality, network-based window system that can be Ximplemented on Xa wide variety of high-resolution raster graphics display devices. XThe widespread interest and unprecedented vendor support for the X Window XSystem has assuaged one of the principal concerns of application Xdevelopers: the cost of supporting multiple hardware platforms with Xdifferent base technologies, including window systems. X X.PP XThe X Window System has been carefully designed to address Xtwo (sometimes conflicting) desires of application developers: to use Xhardware-level techniques for maximum performance and to maintain Xportability with a common programming Xinterface across multiple vendor Xplatforms. X has succeeded in gaining broad vendor support largely Xbecause its specification is intentionally restricted to the set of Xprimitives needed to manipulate multiple independent window contexts Xon raster graphics displays without declaring (or restricting) the Xchoice of particular user-interface semantics. XIt is explicitly intended that developers be able to choose a visual Xinterface appropriate to their needs, their Xcorporate philosophy, their research requirements, religious Xpreferences, or whatever. X X.PP XThis restriction to low-level control and input primitives in the Xdefinition of the X communications protocol and in the corresponding Xapplication interface layer, Xlib X.[ XXlib11 X.] X, is X.\"[3] Xeither a strength or a weakness in the X Standard, Xdepending on the reviewer's point of Xview. Vendors Xwhose installed base of products contains Xwell-defined visual interface and human-computer interface researchers Xfind this flexibility in the standard to be of major importance. XHowever, many application developers consider user interaction and Xother higher-level graphics libraries to be a base system technology Xthat should be provided by the hardware vendors and, of course, be Xstandard across vendors. X X.PP XTo address the desires of such developers for common higher-level Xdevelopment tools, there are several projects under way at various Xlocations covering different application needs and problem Xdomains. XOne Xsuch project is the X Toolkit project, a collaborative effort of XMIT/Project Athena, DEC/Western Software Laboratory, Hewlett-Packard XCompany/Corvallis Workstation XOperation and others. The X Toolkit project is producing an Xapplications interface layer above the Xlib layer specifically Xtailored to visual user interface construction. X X.SH XToolkit Overview X X.PP XThe X Toolkit (hereafter called simply "Xtk") recognizes that no Xsingle comprehensive set of user interface tools is likely to be Xacceptable for standardization in the near future. In order to Xmaximize the utility and acceptability of the user interface library, XXtk has been divided into two separable pieces. These two layers Xwill be described below. X X.PP XThe fundamental entity in Xtk for user interface construction is the X\fIwidget\fP.\(dg X.FS X\(dgWe chose this term since all other common terms were overloaded with Xinappropriate connotations. We offer the observation to the Xskeptical, however, that the principal realization of a \fIwidget\fP is its Xassociated XX \fIwindow\fP Xand the common initial letter is not un-useful. X.FE X X.PP XThe core of Xtk, the "Intrinsics" (a term appropriated from a previous XH-P user interface library for X), is a set of utility routines Xintended for use in developing widgets. The Intrinsics are Xa set of user interface primitives that are themselves free Xof visual and interaction style. XThe Intrinsics do not constrain the widget writer to make the widget Xlook or operate in any particular way. XThese primitives Xmay be used together or Xseparately to produce higher layers which do incorporate specific Xpolicy and style. XSuch higher layers will Xfurther reduce applications development Xcost. X X.PP XMost applications will Xcall only a few of the Intrinsic routines directly. XThese routines offer Xa uniform programming interface to the Xbasic procedures (\fImethods\fP) of all widgets, regardless of Xthe widget Xtype. X X.PP XThe Xtk Intrinsics have been presented in an earlier paper X.[ XXtk X.] X.\"[4] Xand, Xalthough the detailed design has evolved, X.[ XIntrinsics X.] X.\"[5] Xthe philosophy and architecture of Xthe X Toolkit Xremain the same. The Xprincipal additions are a class hierarchy for widget Xtypes; Xthe separation of widget identifiers from the corresponding X window Xidentifiers; and the ability, using the class hierarchy, for new Xwidgets to inherit methods from an existing widget. XThese changes Xsimplify significantly the task of widget development Xand make widgets more modular. X X.PP XWidgets Xdefine Xinput semantics and visual appearance. XSome widgets are pliable; their input semantics (mouse buttons, Xpointer motion, keyboard input) are bound at run-time, while other Xwidgets may have fixed (hard-coded) semantics. Likewise, visual Xappearance (highlighting, repositioning or other animation) may be Xfixed or may be adjusted at run-time. X X.PP XThe Intrinsics provide a uniform way for widget Xdevelopers Xto handle the Xcommon chores of widget construction: initialization, input event Xdispatching (including enabling and disabling user input dispatch to Xsub-hierarchies Xof widgets), run-time configurability, uniform handling of common Xevents (such as exposure and re-size), cleanup, and others. The XIntrinsics also include the Xuniform Xapplication programming interfaces Xfor creating, Xcontrolling, Xand destroying widgets. The XIntrinsics currently consist of over 90 public procedures, of which Xhalf are intended solely for widget Xconstruction. X X.PP XThe goal of the Intrinsics is to make possible the quick development Xof widgets. Sets of widgets should adhere to a consistent application Xinterface, user interaction policy, and visual appearance. It is Xviewed as desirable (or, by some, a necessary evil) that the Xconstruction of multiple such sets ("widget families") covering Xdifferent philosophies be possible with the Xtk Intrinsics. X X.PP XThe second Xpiece of the Xtk is a set of basic widgets. XMost Xapplication developers require a minimum set of widgets as a Xcomponent of any Xproduct-quality Xuser interface library. The X Toolkit Xproject also recognizes the need for concrete examples in a real Xwidget family. To serve both these needs, Xthe first author is leading the effort at Project Athena Xto produce a basic widget set that will be included Xwith the version 1 release of the X Toolkit. XTo distinguish this set from others which we know of, or Xexpect to be developed, we shall here call these the "Athena Widgets". X X.PP XIn addition to the goal of being a basic widget set, the Athena XWidgets have another goal arising from code which had been written Xprior to X Version 11. Many of the components of Xtk had been Xprototyped in a toolkit for X Version 10 that was released by DEC XUltrix Engineering in the spring of 1987. The Athena Widgets borrow Xheavily from those prototypes in order to ease some of the porting Xburden for certain Xapplications built on these prototypes. X X.PP XThe Xwidgets described here are being developed Xin conjunction with Xa set of visual courseware Xprojects at Project Athena. These projects vary considerably in their Xuser dialogs and yet require a standard visual appearance. This has Xled to an emphasis in the Athena Widgets on handling text, graphics, and Xvideo in a variety of ways, and has extended the widget hierarchy Xto fulfill these needs. X X.PP XThe Athena Widgets are intended to fulfill X80% of Xapplication Xrequirements. We Xhave tried to select Xthe critical widgets that will allow the easy solution of individual Xrequirements. (See the section on XCreating New Widgets Xfor more on this.) X X.SH XIntrinsics X X.PP XOne of the Xprinciples Xespoused in the design of the Xtk is the Xconstruction of widgets from primitives. XWe will describe Xtwo independent Xfacilities available Xin the Intrinsics Xfor such construction: subclassing and Xcomposition. From an application point of view, every widget is a Xsingle object. The actual semantics and appearance of the widget may, Xhowever, be very complex. XFor example, Xa "control Xpanel" widget Xis likely to consist of simpler Xwidgets with a "geometry Xmanager" controlling the spatial relationship between the component Xwidgets and possibly a "focus manager" controlling the dispatching of Xuser input to those components. Depending upon the needs of the Xapplication, such a compound (or "composite") widget may be Ximplemented independently and added to the widget library as a new Xwidget class, Xmay Xbe constructed by the application at run-time Xwith in-line calls to the XXtk XIntrinsics, or may be constructed by Xthe composite widget itself from a resource record retrieved through Xthe Intrinsic resource management facilities. X X.PP XComposition of widgets is most appropriate when there are distinct Xvisual regions to a widget, each having separate input/display Xsemantics, and especially when the same semantics may appear in a Xregion of another widget class. In this case, the semantics common to Xboth regions may be extracted into a more primitive widget class. X X.PP XThis is the principle of modularity of widgets: the application will Xstill view a composite widget (a control panel, for example) as a Xsingle widget. The internals of this composite widget are built when Xthe widget is instantiated. The composite widget may determine and Xinstantiate all of its components, as for a custom application panel. XThe components may also Xbe instantiated and assigned by the client of Xthe composite widget. Some of the Athena Widgets exhibit this Xrecursive construction Xbehavior; e.g. Dialog, while others are X`boxes', or frames into which the client inserts independently Xinstantiated widgets, e.g. Form and XVPaned. X X.PP XThe second construction facility, subclassing, allows a widget class Xto semi-automatically inherit some or all of the characteristics of an Xexisting widget class, and to share portions of the code that Ximplement the Xparent (super-) class Xmethods. The new widget may call upon the Xsuperclass methods to manipulate any part of the widget state defined Xby the superclass and needs only to implement the code to manage the Xstate that is unique to the new class. X X.PP XThe subclassing facility is most appropriate for new widgets which Xneed only to add additional semantics to an existing widget, or to Xconstrain in some manner the full generality of an existing widget. XExamples of both subclassing and composition Xin the Athena Widgets Xare described below. X X.PP XSeveral widget classes have been defined solely for the purpose of Xbeing subclassed. The \fBComposite\fP class provides methods to maintain Xa list Xof child widgets, to manage the insertion and removal of Xchildren, to manage requests from the children for Xnew geometries, Xand to manage the assignment of input events to specific Xchildren (input focus). The \fBConstraint\fP class has all the methods of XComposite and in addition provides methods to automatically create and Xinitialize an arbitrary data record attached to each child. The Xcontents of this data record are defined by each subclass of XConstraint and are intended to contain layout information used by the Xsubclass geometry manager. Neither Composite nor Constraint are Xintended to be instantiated; only their subclasses are. Nothing in the Ximplementation, however, will prevent an application from Xinstantiating any class, should it prove useful. X X.PP XAll widgets are expected to be self-contained with respect to Xexposure, resize and input event handling. That is, the clients of Xthe widget (i.e. the application program or a composite widget of which this Xwidget is a component) are guaranteed that all exposure and input Xevents sent by the X server for the window defining the widget will be Xprocessed completely by the widget. A client that creates an instance Xof the ScrolledAsciiText widget, for example, is not involved in any Xof the details of text re-painting, scrolling, selection, cut and Xpaste, and so on. The client is also free to assign any shape to the Xwidget and assume that the widget will adjust to the imposed size. X X.PP XThe principal mechanism the Athena Widgets use to communicate back to Xthe client is the callback procedure. While a client has the option Xto query the widget state, it is usually more convenient for a command Xbutton, for example, to directly call a client-supplied procedure when X`pressed' by the user. Some widgets accept more than one callback Xprocedure for alternate interactions that they implement. X X.SH XRuntime Configurability X X.PP XOne of the major design principles followed by the Athena Widgets is Xto make as much of the user interface as possible customizable by the Xend-user of the application. Fierce debates X(i.e. \fIwars\fP) Xbreak out Xevery time someone proposes a single Xset of key or button bindings for all users, or that a fixed Xchoice of colors or text fonts will be appropriate for all Xindividuals. Even such characteristics as whether scrollbars go on Xthe left or right (or top/bottom) of a window may be appropriate for Xindividual customization. X X.PP XThe Xtk implements run-time configurability through the Xlib Resource XManager. The Resource Manager is a general-purpose repository for Xstorage and retrieval of arbitrary data within a single process Xaddress space. During initialization, the Xtk pre-loads the resource Xdatabase from Xthe X server and from Xone or more files. When a new instance of a widget is Xcreated Xby the application, Xthe widget resource list is examined and the widget instance Xis initialized with data from the resource database. Each widget Xdeclares an instance name and a class name for purposes of matching Xagainst resource names in the database. The Resource Manager defines Xrules for Xpartial Xname matches so that a single resource entry may Xinitialize many widget instances. X X.PP XThe implementor of a new widget Xhas the choice of which widget characteristics Xto declare as resources and which to hard-wire Xinto the widget. In general, any instance data for which the widget Xis willing to allow modification requests Xfrom Xthe client should be declared in the resource list. X X.PP XWidget characteristics such as text font and color are obvious Xresource choices. The Athena Widgets also declare the keyboard and Xmouse button bindings as resources. In this way, the user of any Xapplication linked against the widgets has the option to accept our Xdefault bindings or enter his/her own bindings. XThe Resource Manager naming mechanism Xallows the user to attach the new bindings to all instances of a Xwidget class (e.g. Scrollbar) in any application, or to a specific Xwidget Xin a specific application only, or any combination Xin-between. A client may, if it so chooses, Xoverride Xany entry in Xthe resource database either by storing its own entry (preferred), or Xby passing an explicit value when instantiating the widget (discouraged). X X.PP XThe keyboard and button bindings are configurable in yet a second way. XEach widget that accepts user input declares a list of action routines Xthat may be invoked by Xinput events. XThe Athena Widgets use the Translation Management facilities in the XIntrinsics to bind keys and buttons to widget action routines. These Xbindings can specify parameters to the action routines to further Xconfigure their behavior. The Scrollbar widget, for example, declares Xthree action routines, one of which is parameterized so that the range Xof values it returns may be established by the bindings. X X.PP XUsing these action routines and the default scrollbar bindings, the XScrolledAsciiText widget, for example, allows the user to scroll Xa block of Xtext forward or backward by a variable amount and to drag the thumb X(elevator) Xto a new position, displaying any portion of the text. A user may supply Xan alternate set of XScrollbar Xbindings that will cause the scrollbar to Xreport full-length forward or backward scrolls, independent of the Xpointer position, possibly disabling the variable scrolling as Xdesired. X X.PP XTwo of the Athena widget classes exist for the purpose of handling Xinterprocess Xinteractions with other X client processes. The \fBShell\fP Xwidget Xdefines no user action routines, but Xmaintains all the appropriate window properties established by Xconvention for X window managers, including icon representation. Many Xof these parameters are controlled by command line options and parsed Xby the Xtk initialization routine. Most applications use a Shell Xwidget as their Xoutermost X(top level) widget. X X.PP XAdditional semantics appropriate for temporary, or "pop-up", panels are Xadded to a subclass of Shell, the \fBPopup\fP widget. From the client's Xpoint-of-view, both Shell and Popup are simple widgets; they manage Xexactly one child widget and have a trivial geometry manager. XUIMS developers may find it desirable Xto extend Shell at some time in the future, Xeven allowing site tailoring for specific choices of window manager. XOne such addition might be a Shell that, when made smaller by the Xwindow manager (as instructed by the user, of course); added Xscrollbars (or other interaction semantics); and provided a movable Xviewport on the application window which, from the application's Xpoint-of-view, Xretains Xits original size. X X.SH XCurrent Widgets X X.PP XThe Athena Widgets are divided into two major classes. The Xfirst are simple widgets: various sorts of buttons, labels, Xedit buffers and the ubiquitous scrollbar. XThese form the elemental building blocks of a user Xinterface. The second are composite widgets: Xscrolled text, Xdialog boxes, and various methods of putting together simple widgets in more Xcomplex arrangements. X X.PP XAll simple widgets have initialization, realization, display, Xand interaction methods. These methods may be fairly simple, as with Xthe button widgets, or quite complex, as with the text Xwidget. X X.PP XAll widgets use the Core widget as the root of their class hierarchy. XThe Core widget (whose class name, as a special case, is just X\fBWidget\fP) Xhas the minimal set of instance fields common to all widgets: width, Xheight, border width, and so on. While it is not usually intended Xthat an application ever create an instance of (Core) Widget, it is Xsupported: an application that wants a simple window within a widget Xpanel \fImay\fP instantiate XWidget Xand use the resulting window. X X.PP XThe \fBLabel\fP widget Xis just that; a widget that displays either a text Xstring or X(in the near future) Xa pixmap without any interaction semantics and therefore Xwithout any callback procedures. It can only center, right justify, Xor left justify its text in the client's choice of fonts within its Xassigned size. (The default size is a bounding box for the text or Xgraphics.) A Label may be insensitive, or grayed-out, and the border, Xas for all widgets, Xneed not be visible. Like all widgets, the Label widget processes Xexposure Xevents on its window so the parent can be assured that all Xvisible portions of the Label are properly refreshed on the screen. XOne will typically use the label to Xposition and paint items intended Xfor display only. X X.PP XThe \fBCommand\fP button widget Xis a subclass of Label with interaction semantics Xand therefore a callback procedure. A Command Xbutton Xis a Label with X\fIenter\fP, \fIleave\fP, \fIset\fP, \fIunset\fP, and \fInotify\fP Xactions. XWhen insensitive, the XCommand Xbutton Xdoes not respond to user input events. On \fIenter\fP Xto a sensitive Command, Xthe border will, by default, Xbecome visibly Xthicker. On \fIset\fP, the button is Xdisplayed in reverse video; on \fIunset\fP, the button is returned to Xnormal. On \fInotify\fP, a single client-supplied callback procedure is Xactivated. These actions are mapped, by default but not by necessity, Xto the pointer enter, button down, and button up events. One Xwill typically use the Command Xbutton Xto create "clickable" icons or labels that start a program action. XThe Command Xbutton Xis an essential building block for point-and-click interfaces. X X.PP XFigure 1 shows several Labels and Command buttons. XThe user has moved the pointer into one of the Command buttons, and Xthe button has been highlighted. These Labels and Command Xbuttons are enclosed in two layers of Boxes, which will be Xdiscussed below. X X.KF X.sp 2i X.ce XFigure 1 X X.KE X X.PP XThe Command Xwidget Xcan be extended into its subclass X\fBTwoState\fP button. On \fIset\fP, the TwoState widget Xdisplays a second label or graphic. In all other respects, it is similar to XCommand. TwoState is useful for simultaneously displaying and Xchanging a binary application state. X X.PP XThe \fBToggle\fP widget Xis also a subclass of XCommand Xand also has Xsimple interaction semantics and a callback procedure. A Toggle is a Xbinary state button. Once \fIset\fP, e.g. by button down, it Xremains in that state Xuntil the user Xselects Xthe Toggle Xagain. Toggle Xis useful for selecting on-off Xoptions. The application may use the callback to be notified on each Xstate change, or may query the Toggle for its current state as appropriate. X X.PP XThe \fBGrip\fP widget is a minimal Command button. Grip (a.k.a. Knob) Xhas a single callback but no default interaction semantics. The Xinteractions (event bindings) are provided by the client when Grip is Xinstantiated. Grip simply uses the X window background as its Xdisplay. This widget was built for clients who need to identify Xspecific locations where, for example, the pointer may be used to drag Xan object. X X.PP XThe \fBScrollbar\fP widget implements a vertical or horizontal Xscrollbar. There are three callbacks: one to move the scrollbar thumb X(elevator), Xa second to execute a client callback passing a distance Xin pixels as data, and a third to execute an application callback Xpassing as data the position of the pointer as a percentage of the Xscrollbar length. XThe Xinclusion of the \fImoveThumb\fP action routine in the Xactions table allows the client some control over whether or not the Xscrollbar widget automatically Xrepositions the Xthumb Xon input. X X.PP XThe \fBAsciiFile\fP and \fBAsciiString\fP text widgets allow the entry, Xmodification, Xand Xdisplay of text. The widgets can be Xinstantiated in read-only or read-write modes. They implement a Xsubset Xof the ever popular Emacs, including mouse-driven cutting and Xpasting. XKey bindings are, of course, Xcompletely settable through the Translation Manager.\(dg X.FS X\(dgIt has been suggested that some users would prefer an AsciiFile Xwidget that allowed them to specify their favorite text editor. While Xthe full semantics of the Text widget may be difficult to support with Xan arbitrary external process, it may be an interesting exercise to Ximplement a sub-process interface widget that, in carefully defined Xcircumstances, could be substituted by the user for the AsciiFile widget. X.FE X X.PP XThe AsciiString widget Xoperates on a single Xin-core text string; XAsciiFile on a Xdisk file. They are both subclasses of \fBText\fP, which implements most of Xthe user Xinteractions. XThe implementation of the Text widget follows Xa source/sink model, allowing for the development of additional text Xsources X(other than string and file) Xand for additional display sinks. X X.PP XThese few simple widgets are an attempt to create a number of Xgeneral widgets that can then be tailored for individual uses. A more Xcomplex button widget (for example, one that might display two lines Xof text) would require a different display method but keep the Xinteraction method for XCommand. X X.PP XHowever, few interfaces of any real complexity or use could be Xcreated using just these simple widgets. The simple widgets must be Xcombined using Composite widgets. Composite widgets require geometry, Xchild insertion and deletion, and input focus methods. The geometry Xmanager for the composite may or may not be constraint based, and must Xhandle resizing events by re-positioning the child widgets. XGenerally, the child insertion, child deletion, and input focus Xmethods will be inherited from the superclass, Composite. X X.PP XThe \fBBox\fP widget arranges its Xchildren in the minimum bounding box. The children Xare automatically rearranged when one is deleted or added. XOne can create button areas or horizontal menus using Box. X X.PP XThe \fBRadioButtonBox\fP widget is a subclass of Box exclusively Xfor Toggle Buttons. XIt allows only one Toggle button Xto be set at a time. XIf a second Toggle becomes set, the RadioButtonBox will Xcheck Xits list of children and unset any others. XThis is useful for mutually exclusive Xapplication options. X X.PP XThe \fBForm\fP widget can contain any number of simple or composite widgets. XForm Xis a general-purpose constraint-based layout widget that can Xbe instructed to maintain fixed separations between children, or to Xmaintain fixed distances between children and the edges of the form, Xand so on. When Form is resized, it uses the constraint information Xto resize and reposition the children to maintain the assigned Xseparations. Forms are useful for creating arbitarily complex Xinteraction windows Xthat exhibit `nice' resizing behavior. X X.PP XThe X\fBDialog\fP widget is a subclass of Form. It arranges a specific Xcombination of Label, AsciiString field, and Command Xbuttons. XThe XLabel is displayed on the first line, followed by the text field, and Xthe buttons are on the last line. Dialog is principally a convenience Xwidget implemented to handle a common programming problem. X X.PP XThe \fBScrolledAsciiText\fP widget contains a Xscrollbar and an AsciiString or AsciiFile widget. Using the default Xscrollbar bindings, the ScrolledAsciiText widget allows the user to Xscroll the contained text forward or backward by a variable amount. XBy dragging the thumb to a new position, s/he can display any portion Xof the text. X X.PP XThe X\fBPaned\fP widget manages any number of simple or composite widgets in a tiled Xmanner. The current Paned widget, \fBVPaned\fP, stacks its children Xvertically with the top and bottom edges of successive widgets Xtouching. VPaned uses XGrip Xto allow the user to Xre-position the boundaries between the tiled widgets. X X.PP XFigure 2 illustrates the current Athena Widget hierarchy. This Xdiagram should only be of interest to widget developers; application Xdevelopers should be concerned only with the external characteristics Xof a widget. The fact that a Toggle button actually uses the Label Xcode to display its text string should be of no consequence to the Xapplication. The widget class X.nh X\fBSimple\fP X.hy 14 Xcontains only Xthe procedure to change a widget's borders to indicate sensitivity Xor insensitivity. X X.de F2 X.NP X.1C X.sp .5i X.fo ##Figure 3: Athena Widget Hierarchy## X X.PS Xboxht = .5i; boxwid=1i; XAA: box "Core" Xmove down 1.0 Xmove left 1.0; AB: box "Clock"; Xmove left 1.0; AC: box "Simple" Xmove down Xmove down Xmove down Xmove down XW: circle Xmove down Xmove down Xmove left 1.0; BA: box "Label";move to BA.n Xmove down 1.0; BAA: box "Command"; move to BAA.c Xmove down 1.0; BAAA: box "Two-State" Xmove to BAAA.e right .5; BAAB: box "Toggle" Xmove to BA.e Xmove right .75; BB: box "Grip" Xmove right .75; BC: box "Text" Xmove down 1.0; move left .5; BCA: box "AsciiString" Xmove right 1.5; BCB: box "AsciiFile" Xmove to BC.e Xmove right .75; BD: box "ScrollBar" Xmove to AB.e Xmove right 1.0; AD: box "Load" Xmove right 1.0; AE: box "Composite" Xmove down 6.5; move left 3.0; Z: circle; move down 1.0 Xmove left .75; CA: box "Shell" Xmove to CA.n; move down 1.0; CAA: box "Popup" Xmove to CAA.c; move right 1.25; DAA: box "Radio" Xmove to CA.e Xmove right .75; DA: box "Box" X Xmove right .75; CB: box "Constraint" Xmove to CB.s; move down .5 X XDB: box "Form" Xmove to DB.e; move right .5; DC: box "Paned" Xmove to DB.s; move down .75 XDBA: box "Dialog"; move to DBA.e Xmove right .5; DCA: box "VPaned" X X X Xarrow from AA.b to AC.n Xarrow from AA.b to AB.n Xarrow from AA.b to AD.n Xarrow from AA.b to AE.n X Xarrow from AC.b to W.n X Xarrow from W.b to BA.n Xarrow from W.b to BB.n Xarrow from W.b to BC.n Xarrow from W.b to BD.n X Xarrow from BA.b to BAA.n Xarrow from BAA.b to BAAA.n Xarrow from BAA.b to BAAB.n X Xarrow from BC.b to BCA.n Xarrow from BC.b to BCB.n X Xarrow from AE.b to Z.n Xarrow from Z.b to CA.n Xarrow from Z.b to CB.n Xarrow from Z.b to DA.n X Xarrow from CA.b to CAA.n X Xarrow from CB.b to DB.n Xarrow from CB.b to DC.n Xarrow from DC.b to DCA.n Xarrow from DB.b to DBA.n Xarrow from DA.b to DAA.n X X.PE X X X.ce XFigure 2 X.wh 0 NP X.2C X.rs X.bp X.. X.wh 0 F2 X X.SH XSpecial-purpose Widgets X X.PP XThe \fBClock\fP widget displays an analog or digital time-of-day clock. The X\fBLoad\fP widget displays a continuous system load graph. Both of these Xwere exercises in converting existing simple applications into Xwidgets. Load allows the client to supply its own procedure to fetch Xdata, or to use the built-in default \fIGetSystemLoadAverage\fP procedure. X X.SH XExample X X.PP XFigure 3 shows a variety of composite and simple widgets instantiated Xin a single Xtrivial Xapplication. The outermost widget is a VPaned (inside a XShell) which, in turn, contains several other composite and Xsimple widgets. The small Xsolid Xboxes are Grips which allow the user Xto move the attached pane boundary up or down, forcing the associated Xwidgets to be resized. X X.PP XThe uppermost pane of the VPaned is a Command button marked X"quit". Appropriately, when the user clicks on this button, the Xapplication exits. The pane below this is a Label. X X.PP XThe third pane is a Dialog containing a Label "I am a dialog Xform"; an AsciiString text field Xwith an initial value; and a Command button Xmarked "ok". XThe next pane is a Box containing a Label marked "label" and a XCommand button marked "command". The Clock and Load widgets form the Xnext two panes. X X.PP XThe seventh pane is another Box with an AsciiString widget and a XScrollbar. The last pane in figure 3 is an AsciiFile widget displaying X\fI/etc/motd\fP. X X.PP XThe application that instantiated this entire hierarchy is less than X200 lines of C source, including four callback procedures. X X.KF X.sp 5.2i X.ce XFigure 3 X X X.KE X X.SH XCreating New Widgets X X.PP XSmall changes to existing widgets can be made through the general Xfacilities of the resource and translation managers. XWith Xthese Xmanagers, one can make changes to color, font, key bindings, and the Xsuch. XMany changes that would require a new interface object in other Xtoolkits can be done through resource changes to the existing widgets Xin the X Toolkit. X X.PP XThe simplest case of creating a new widget is to create a Xsubclass of an existing Xwidget. XFor example, if one wanted a Xcommand Xbutton with two lines of text, Xs/he Xmight create a subclass Xof XCommand. XSince all superclass structures are inherited, one Xwould merely need to add an additional string field to the instance Xstructure and nothing to the class structure. Since there is no Xchange in user interaction semantics, only the display method would Xneed to be changed. In addition, code to allow the modification of Xthe second text string would be required. All other code could be Xinherited. This new widget could then be incorporated in any Xcomposite widget that allowed buttons. X X.PP XSubclassing composite widgets is a little more work since new Xgeometry managers may be desired. In general, the additional methods Xof a XComposite Xwidget tend to be complex and the new subclass will Xwant to inherit as much as possible. X X.PP XOne potential `client' of a widget that the implementor of the widget Xshould keep in mind is the writer of the next widget. With a little Xthought, the designer of a new widget can decide which of the new Xmethods added Xby Xthe subclass should be declared as class variables, Xwhich as widget instance variables and which as in-line code. X X.PP XClass variables are the best way to export methods to Xpotential future subclasses. By installing a procedure pointer into a Xclass variable, the new subclass has the option to easily inherit the Xold method or to define its own implementation. X X.PP XThe developer of a family of widgets may find circumstances in which a small Xmodification to a parent class would make a new subclass much easier Xto implement. From the application point-of-view, widget instance and Xwidget class data structures are opaque types. XThe effect of an addition to one of these structures can be isolated Xto subclasses of the changed widget without breaking existing application Xcode. X X.PP XA subclass is free to manipulate any of the widget instance variables Xdefined by its Xsuper\%classes. XThe subclass must be careful if it Xsimultaneously manipulates superclass instance data and inherits Xsuperclass methods that use the same data. At present, the only way Xto determine such side-effects is by examination of the superclass Ximplementation(s). We hope to establish conventions in the future for Xdocumenting all the public and semi-public interfaces of a widget. X X.SH XWidgets Of The Future X.LP XOn our wish list are: X X\fBread-only dial\fP: posts a position between 0 and 1 to a circular Xdial. Useful for indicating position or state. X X\fBtitle bar\fP: the mandatory title, horizontal lines, and close button. XA convenience widget, like Dialog. X X\fBmenus\fP: pull-down, pull-aside, Xand deck-of-cards Xmenus. X X\fBindex pane\fP: allows the user to select from a scrollable list of Xtext Xstrings. Useful for selecting topics or filenames. X X\fBvideo label\fP: handles the display of video Xfrom an external source Xinside a widget. X X\fBvideo command button\fP: extends the command button to handle Xvideo windows. X X\fBtext sinks\fP: a variety of additional Text sinks is desirable. XOne such possibility is a sink that interprets bytes from the Text Xsource as ANSI XTerminal control sequences. XAnother desirable sink would interpret font Xchange control sequences in the source and display multi-font text. X X\fBviewport (frame)\fP: a movable (scrollable) window frame on a Xlarger widget. X X\fBdata plotting\fP: a variety of data plotting Xwidgets. Useful for engineering curriculum applications. X X.PP XMany of these widgets are required by the visual courseware projects Xat Project Athena and will be implemented over the next several Xmonths. X X.SH XIssues X X.LP XThere are several open issues in the effective design and Ximplementation of new widget classes: X X.IP \0\0\(bu 4 XThe class mechanism has only a simple inheritance structure. XTherefore, a widget class gets both its display and interaction Xsemantics from its single parent class. This leads to an awkwardness Xand duplicate code in composing widgets where multiple inheritance is Xreally desired. XOne way around this is to export little procedures that may be Xused by other widgets to minimize duplicate code, but Xthis is clearly undesirable. X X.IP XOne Xexample Xwhere simple inheritance influenced our widget Ximplementation is the Text widget. Our preferred hierarchy would be a Xsimple Text class, implementing only the editing and selection actions X(without scrolling options) and to implement ScrolledText as a Form Xconsisting of a XScrollbar, Xoptionally some Command buttons, and the XText primitive. X X.IP XThis would give the user interface designer the maximum flexibility: Xby customizing the ScrolledTextForm, taking advantage of the Xconstraint-based geometry manager of Form, scrolling could be Xcontrolled by a variety of interaction devices. X X.IP XIt is desirable, however, for ScrolledText to have the semantics of a XText widget from the programmer's viewpoint, and so ScrolledText Xcannot be implemented as a trivial Form instance Xwithout knowing the internals of Text. X X.IP \0\0\(bu 4 XThe Athena widgets have been implemented Xwithout the aid of a graphic artist. We hope that the Ximplementations and interfaces are amenable to `dropping in' new Xdisplay methods should the opportunity arise. As presented now, the Xvisual appearance can be reasonably characterized as stark. X X.IP \0\0\(bu 4 XAn infinite variety of convenience widgets that are fixed composites Xof other widgets (like Dialog and Titlebar) are possible. Before Ximplementors go Xtoo wild defining such things and adding them to the standard Xlibrary, we need to implement an example of a widget that determines Xits content entirely through the Resource Manager. Then, when there Xis a resource editor, new composite forms can be built using Xnon-programmatic methods and the widget library can be trimmed back to Xjust the primitives. X X.IP XWhether composite widgets are separately written as new classes or Xbuilt from a resource record by a `ConfiguredForm' widget, there is Xthe issue of how much access a programmer should have to the Xindividual component widgets. Good programming practice tells us that Xeven composite widgets should always be opaque. Realism tells us that Xprogrammers will always want to look behind the curtain. X X.IP \0\0\(bu 4 XAs will Xno Xdoubt have become clear to the reader by this point, the XXtk does not (yet) aspire to be a full UIMS, for reasons discussed at Xthe opening. It is our desire to see the Xtk as the lower Xlevel of a UIMS. X X.SH XSummary X X.PP XThe M.I.T. X Toolkit, comprised of both general-purpose Intrinsics Xfor widget construction and implementations of widgets for direct Xapplication use, provides highly extensible mechanisms for application Xuser interface construction. X X.PP XThe X Toolkit layer sits above Xlib but below a full UIMS layer. By Xproviding a consistent application programming interface to widgets, Xthe Xtk allows independent development of an application and its Xassociated user interface. X X.PP XEach of the widgets in the Athena widget set leaves as much as Xpossible configurable by the end-user of an application, while still Xproviding reasonable and useful defaults. XWe expect Xthat, Xthrough use, this basic widget set will be extended and improved. X X.PP XAll of the work described here, including complete source code, will Xbe released by M.I.T. with the next release of the X Window System. XThe Massachusetts Institute of Technology, Digital Equipment XCorporation, and others maintain copyright protection over all Xmaterials Xreleased by Project Athena Xwith explicit permission granted for unlimited use, Xmodification and re-distribution for any purpose and without fee. X X.SH XAcknowledgments X X.PP XMany individuals have contributed to the design and implementation Xof the Intrinsics and of the Athena Widgets. To name them all Xis impossible. XSpecial mention must, however, go to XCharles Haynes, Phil Karlton, Tom Benson, Mike Gancarz, Harry Hersh, XMike Chow, Loretta Guarino-Reid, XRich Hyde, XKathy Langone, Mary Larson, Joel XMcCormack, Leo Treggiari, Jake VanNoy, Terry Weissman, Smokey Wallace, XSusan Angebranndt, XRam Rao, Chuck Price, Al Mento, Peter Smith, Jeanne Rich (all from DEC); Frank XHall, Tom Houser, Ed Lee, Rick McKay, Fred Taft, Ted Wilson, Phil XGust (all from H-P); Jack Palevich (formerly H-P); XJohn Osterhaut (U.C. Berkeley); XSteve Pitschke X(Stellar), Richard Carling (Masscomp); Ron Newman, XDan Geer, Bill Cattey, Russ Sasnett, Steve Wertheim, Stewart Hou, XChris Peterson (M.I.T. Athena); Xand Matt Hodges (DEC and M.I.T. Athena). XEach of the above has made Xsignificant contribution to the X Toolkit Xdistribution. X X.SH XReferences X.LP X.\"[1] R. W. Scheifler and J. Gettys, \fIThe X Window System\fPACM X.\"Transactions on Graphics, Vol. 5 No. 2 (April, 1987) X.\" X.\"[2] \fIX Window System Protocol\fP, M.I.T. X11R1 distribution, X.\"(September, 1987) X.\" X.\"[3] J. Gettys, R. Newman, R. W. Scheifler, \fIXlib - C Language X.\"Interface\fP, M.I.T. X11R1 distribution X.\" X.\"[4] R. Rao, S. Wallace, \fIThe X Toolkit\fP, Usenix Summer 1987 X.\"conference proceedings X.\" X.\"[5] \fIX Toolkit Intrinsics\fP, Beta test version, M.I.T. X11R1 X.\"distribution and Nov, 1987 update SHAR_EOF if test 40797 -ne "`wc -c < 'xtk'`" then echo shar: "error transmitting 'xtk'" '(should have been 40797 characters)' fi fi echo shar: "extracting 'xtk.fig1.PS'" '(4677 characters)' if test -f 'xtk.fig1.PS' then echo shar: "will not over-write existing file 'xtk.fig1.PS'" else sed 's/^ X//' << \SHAR_EOF > 'xtk.fig1.PS' X%!PS-Adobe-1.0 X%%Creator: E40-358-14:ackerman (Mark S. Ackerman,'Ack',e40-342M,0133,8685235) X%%Title: box.raw (xboxes) X%%CreationDate: Fri Jan 1 17:09:16 1988 X%%EndComments X%%Pages: 1 X%%EndProlog X%%Page: 1 1 X X/bitdump % stk: width, height, iscale X% dump a bit image with lower left corner at current origin, X% scaling by iscale (iscale=1 means 1/300 inch per pixel) X{ X % read arguments X /iscale exch def X /height exch def X /width exch def X X % scale appropriately X width iscale mul height iscale mul scale X X % allocate space for one scanline of input X /picstr % picstr holds one scan line X width 7 add 8 idiv % width of image in bytes = ceiling(width/8) X string X def X X % read and dump the image X width height 1 [width 0 0 height neg 0 height] X { currentfile picstr readhexstring pop } X image X} def Xgsave X/Times-Roman findfont 15 scalefont setfont X249 270 translate X112 (Figure 1) stringwidth pop sub 2 div -20 moveto X(Figure 1) show Xgrestore X72 600 div dup scale X2300 2600 translate X78 174 6 bitdump X00000000000000000000 X7ffffffffffffffffff8 X7ffffffffffffffffff8 X7ffffffffffffffffff8 X7ffffffffffffffffff8 X7800000000000007fff8 X7bfffffffffffff7fff8 X7bfffffffffffff7fff8 X7bfffffffffffff7fff8 X7bfffffffffffff7fff8 X7bc00000000000f7fff8 X7bdffffffffffef7fff8 X7bdffffffffffef7fff8 X7bdffffffffffef7fff8 X7bdffffffffffef7fff8 X7bdf3fefff3efef7fff8 X7bdfbfefffbcfef7fff8 X7bdfbfefffbafef7fff8 X7bdfbc61c7befef7fff8 X7bdfbfaebbbefef7fff8 X7bdfbc2e83befef7fff8 X7bdfbbaebfbefef7fff8 X7bdfbbaebbbefef7fff8 X7bdf1c21c7183ef7fff8 X7bdffffffffffef7fff8 X7bdffffffffffef7fff8 X7bdffffffffffef7fff8 X7bdffffffffffef7fff8 X7bc00000000000f7fff8 X7bfffffffffffff7fff8 X7bfffffffffffff7fff8 X7bfffffffffffff7fff8 X7bfffffffffffff7fff8 X7bc00000000ffff7fff8 X7bdfffffffeffff7fff8 X7bdfffffffeffff7fff8 X7bdfffffffeffff7fff8 X7bdfffffffeffff7fff8 X7bdfffffffeffff7fff8 X7bdffffbdfeffff7fff8 X7bdfffffdfeffff7fff8 X7bdf0bb387effff7fff8 X7bdeebbbdfeffff7fff8 X7bdeebbbdfeffff7fff8 X7bdeebbbdfeffff7fff8 X7bdf0b3bdbeffff7fff8 X7bdfecb1e7effff7fff8 X7bdfefffffeffff7fff8 X7bdfefffffeffff7fff8 X7bdfffffffeffff7fff8 X7bdfffffffeffff7fff8 X7bc00000000ffff7fff8 X7bfffffffffffff7fff8 X7bfffffffffffff7fff8 X7bfffffffffffff7fff8 X7bfffffffffffff7fff8 X7800000000000007fff8 X7ffffffffffffffffff8 X7ffffffffffffffffff8 X7ffffffffffffffffff8 X7ffffffffffffffffff8 X78000000000000000078 X7bffffffffffffffff78 X7bffffffffffffffff78 X7bffffffffffffffff78 X7bffffffffffffffff78 X7bc00000000000ffff78 X7bdffffffffffeffff78 X7bdffffffffffeffff78 X7bdffffffffffeffff78 X7bdffffffffffeffff78 X7bdf3fefff3c7effff78 X7bdfbfefffbbbeffff78 X7bdfbfefffbbbeffff78 X7bdfbc61c7bfbeffff78 X7bdfbfaebbbf7effff78 X7bdfbc2e83befeffff78 X7bdfbbaebfbdfeffff78 X7bdfbbaebbbbfeffff78 X7bdf1c21c7183effff78 X7bdffffffffffeffff78 X7bdffffffffffeffff78 X7bdffffffffffeffff78 X7bdffffffffffeffff78 X7bc00000000000ffff78 X7bffffffffffffffff78 X7bffffffffffffffff78 X7bffffffffffffffff78 X7bffffffffffffffff78 X7bc00000000000000f78 X7bc00000000000000f78 X7bcfffffffffffffcf78 X7bcfffffffffffffcf78 X7bcfffffffffffffcf78 X7bcffffffffffec7cf78 X7bcffffffffffebbcf78 X7bcffffffffffebbcf78 X7bcf1c65971a70fbcf78 X7bceebaaabe9aef7cf78 X7bcefbaaab0baeefcf78 X7bcefbaaaaebaedfcf78 X7bceebaaaaebaebfcf78 X7bcf1c6ebb0bb083cf78 X7bcfffffffffffffcf78 X7bcfffffffffffffcf78 X7bcfffffffffffffcf78 X7bc00000000000000f78 X7bc00000000000000f78 X7bffffffffffffffff78 X7bffffffffffffffff78 X7bffffffffffffffff78 X7bffffffffffffffff78 X78000000000000000078 X7ffffffffffffffffff8 X7ffffffffffffffffff8 X7ffffffffffffffffff8 X7ffffffffffffffffff8 X78000000000000000078 X7bffffffffffffffff78 X7bffffffffffffffff78 X7bffffffffffffffff78 X7bffffffffffffffff78 X7bc00000000000ffff78 X7bdffffffffffeffff78 X7bdffffffffffeffff78 X7bdffffffffffeffff78 X7bdffffffffffeffff78 X7bdf3fefff383effff78 X7bdfbfefffbfbeffff78 X7bdfbfefffbf7effff78 X7bdfbc61c7befeffff78 X7bdfbfaebbbc7effff78 X7bdfbc2e83bfbeffff78 X7bdfbbaebfbfbeffff78 X7bdfbbaebbbbbeffff78 X7bdf1c21c71c7effff78 X7bdffffffffffeffff78 X7bdffffffffffeffff78 X7bdffffffffffeffff78 X7bdffffffffffeffff78 X7bc00000000000ffff78 X7bffffffffffffffff78 X7bffffffffffffffff78 X7bffffffffffffffff78 X7bffffffffffffffff78 X7bc00000000000000f78 X7bdfffffffffffffef78 X7bdfffffffffffffef78 X7bdfffffffffffffef78 X7bdfffffffffffffef78 X7bdffffffffffe83ef78 X7bdffffffffffefbef78 X7bdffffffffffef7ef78 X7bdf1c65971a70efef78 X7bdeebaaabe9aec7ef78 X7bdefbaaab0baefbef78 X7bdefbaaaaebaefbef78 X7bdeebaaaaebaebbef78 X7bdf1c6ebb0bb0c7ef78 X7bdfffffffffffffef78 X7bdfffffffffffffef78 X7bdfffffffffffffef78 X7bdfffffffffffffef78 X7bc00000000000000f78 X7bffffffffffffffff78 X7bffffffffffffffff78 X7bffffffffffffffff78 X7bffffffffffffffff78 X78000000000000000078 X7ffffffffffffffffff8 X7ffffffffffffffffff8 X7ffffffffffffffffff8 X7ffffffffffffffffff8 X00000000000000000000 X Xshowpage X%%Trailer SHAR_EOF if test 4677 -ne "`wc -c < 'xtk.fig1.PS'`" then echo shar: "error transmitting 'xtk.fig1.PS'" '(should have been 4677 characters)' fi fi echo shar: "extracting 'xtk.fig3.PS'" '(30520 characters)' if test -f 'xtk.fig3.PS' then echo shar: "will not over-write existing file 'xtk.fig3.PS'" else sed 's/^ X//' << \SHAR_EOF > 'xtk.fig3.PS' X%!PS-Adobe-1.0 X%%Creator: E40-358-14:ackerman (Mark S. Ackerman,'Ack',e40-342M,0133,8685235) X%%Title: temp (xwidgets) X%%CreationDate: Thu Dec 31 16:33:22 1987 X%%EndComments X%%Pages: 1 X%%EndProlog X%%Page: 1 1 X X/bitdump % stk: width, height, iscale X% dump a bit image with lower left corner at current origin, X% scaling by iscale (iscale=1 means 1/300 inch per pixel) X{ X % read arguments X /iscale exch def X /height exch def X /width exch def X X % scale appropriately X width iscale mul height iscale mul scale X X % allocate space for one scanline of input X /picstr % picstr holds one scan line X width 7 add 8 idiv % width of image in bytes = ceiling(width/8) X string X def X X % read and dump the image X width height 1 [width 0 0 height neg 0 height] X { currentfile picstr readhexstring pop } X image X} def Xgsave X/Times-Roman findfont 13 scalefont setfont X209 129 translate X193 (Figure 3) stringwidth pop sub 2 div -20 moveto X(Figure 3) show Xgrestore X72 450 div dup scale X1500 1200 translate %was 871 538; 0 0 lower left X202 556 4 bitdump X0000000000000000000000000000000000000000000000000000 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7ffffffffffffffffffffffffef7ffffffffffffffffffffff80 X7ffffffffffffffffffffffffff7ffffffffffffffffffffff80 X7fffffffffffffffffffffc2ece1ffffffffffffffffffffff80 X7fffffffffffffffffffffbaeef7ffffffffffffffffffffff80 X7fffffffffffffffffffffbaeef7ffffffffffffffffffffff80 X7fffffffffffffffffffffbaeef7ffffffffffffffffffffff80 X7fffffffffffffffffffffc2cef6ffffffffffffffffff803f80 X7ffffffffffffffffffffffb2c79ffffffffffffffffff803f80 X7ffffffffffffffffffffffbffffffffffffffffffffff803f80 X7ffffffffffffffffffffffbffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X0000000000000000000000000000000000000000000000000000 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7ffffffffe7fffffffffffffffcfffffffffff7fffffdfffff80 X7fffffefff7ffffeffffffffffb7ffffffffef7f7fffdfffff80 X7fffffefff7ffffeffffffffffbfffffffffef7fffffdfffff80 X7ffff8c3ff78e38c3fe34e3fe3bff8dd8d37434e74e3dfffff80 X7fffff6fff777d76ffdd35dfdd0ff75d74d76f37735ddfffff80 X7ffff86fff70619effdd741fddbff05d05f76f77775ddfffff80 X7ffff76fff77ddeeffdd75ffddbff7eb7df66f77775ddfffff80 X7ffff76dff775d76dfdd75dfddbff76b75f96d777761ff803f80 X7ffff873fe38e18f3fe3763fe3bff8f78dff7376377ddf803f80 X7ffffffffffffffffffffffffffffffffff77fffffddff803f80 X7ffffffffffffffffffffffffffffffffff8ffffffe3ff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X0000000000000000000000000000000000000000000000000000 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7ffffffffff1ffffffffffbfff3fffff9fffffffffffffffff80 X7ffffffffffbffffffffffbbffbfffff6fffffffffffffffff80 X7ffffffffffbffffffffffbfffbfffff7fffffffffffffffff80 X7ffffffffffbff197fc7fc33c7bc71ff7c6997ffffffffffff80 X7ffffffffffbffeabffbfbbbfbbbaefe1ba6abffffffffffff80 X7ffffffffffbff0abfc3fbbbc3bbaeff7bafabffffffffffff80 X7ffffffffffbfeeabfbbfbbbbbbbaeff7bafabffffffffffff80 X7ffffffffffbfeeabfbbfbbbbbbbb0ff7bafabffffffffffff80 X7ffffffffff1ff0bbfc3fc31c31c7eff7c6fbbffffffffffff80 X7fffffffffffffffffffffffffffeeffffffffffffffffffff80 X7ffffffffffffffffffffffffffff1ffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7800000000000000000000000000000000000000000000001f80 X7bffffffffffffffffffffffffffffffffffffffffffffffdf80 X7bffffffffffffffffffffffffffffffffffffffffffffffdf80 X7bffffffffffffffffffffffffffffffffffffffffffffffdf80 X7bffffffffffffffffffffffffffffffffffffffffffffffdf80 X7bffffffffffffffffff9fffff7fffffffffffffffffffffdf80 X7bfffbffffffffffffffdfffff7fffffffffffffffffffffdf80 X7bfffbffffffffffffffdfffff7fffffffffffffffffffffdf80 X7b8d30e34ff4e377f763ddd8ff4e34e3ffffffffffffffffdf80 X7b74dbdd37f35d77f77dddd77f35d35dffffffffffffffffdf80 X7b05dbc17ff74157f761ddd07f7417c1ffffffffffffffffdf80 X7b7ddbdf7ff75f57faddddd7ff75f7dfffffffffffffffffdf80 X7b75db5d7ff75d57fadddd977f75d7ddffffffffffffffffdf80 X7b8ddce37ff763affde18e58ff7637e3ffffffffffffffffdf80 X7a7fffffffffffffffffffffffffffffffffffffffffffffdf80 X783fffffffffffffffffffffffffffffffffffffffffffffdf80 X799fffffffffffffffffffffffffffffffffffffffffffffdf80 X7bffffffffffffffffffffffffffffffffffffffffffffffdf80 X7bffffffffffffffffffffffffffffffffffffffffffffffdf80 X7bffffffffffffffffffffffffffffffffffffffffffffffdf80 X7800000000000000000000000000000000000000000000001f80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7800001fffffffffffffffffffffffffffffffffffffffffff80 X7bffffdfffffffffffffffffffffffffffffffffffffffffff80 X7bffffdfffffffffffffffffffffffffffffffffffffffffff80 X7bffffdfffffffffffffffffffffffffffffffffffffffffff80 X7bffffdfffffffffffffffffffffffffffffffffffffffffff80 X7bff7fdfffffffffffffffffffffffffffffffffffffffffff80 X7bff7fdfffffffffffffffffffffffffffffffffffffffffff80 X7bff7fdfffffffffffffffffffffffffffffffffffffffffff80 X7be36fdfffffffffffffffffffffffffffffffffffffffffff80 X7bdd5fdfffffffffffffffffffffffffffffffffffffffffff80 X7bdd3fdfffffffffffffffffffffffffffffffffffffffffff80 X7bdd5fdfffffffffffffffffffffffffffffffffffffffffff80 X7bdd6fdfffffffffffffffffffffffffffffffffffffffffff80 X7be377dfffffffffffffffffffffffffffffffffffffffffff80 X7bffffdfffffffffffffffffffffffffffffffffffffffffff80 X7bffffdfffffffffffffffffffffffffffffffffffffffffff80 X7bffffdfffffffffffffffffffffffffffffffffffffffffff80 X7bffffdfffffffffffffffffffffffffffffffffffffff803f80 X7800001fffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X0000000000000000000000000000000000000000000000000000 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X78000000000780000000000007ffffffffffffffffffffffff80 X7bfffffffff7bffffffffffff7ffffffffffffffffffffffff80 X7bfffffffff7bffffffffffff7ffffffffffffffffffffffff80 X7bfffffffff7bffffffffffff7ffffffffffffffffffffffff80 X7bfffffffff7bffffffffffff7ffffffffffffffffffffffff80 X7be7fdffe7f7bffffffffffdf7ffffffffffffffffffffffff80 X7bf7fdfff7f7bffffffffffdf7ffffffffffffffffffffffff80 X7bf7fdfff7f7bffffffffffdf7ffffffffffffffffffffffff80 X7bf78c38f7f7be38cb2e34e1f7ffffffffffffffffffffffff80 X7bf7f5d777f7bdd75557d35df7ffffffffffffffffffffffff80 X7bf785d077f7bdf75556175df7ffffffffffffffffffffffff80 X7bf775d7f7f7bdf75555d75df7ffffffffffffffffffffffff80 X7bf775d777f7bdd75555d75df7ffffffffffffffffffffffff80 X7be38438e3f7be38dd761761f7ffffffffffffffffffffffff80 X7bfffffffff7bffffffffffff7ffffffffffffffffffffffff80 X7bfffffffff7bffffffffffff7ffffffffffffffffffffffff80 X7bfffffffff7bffffffffffff7ffffffffffffffffffffffff80 X7bfffffffff7bffffffffffff7ffffffffffffffffffff803f80 X78000000000780000000000007ffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X0000000000000000000000000000000000000000000000000000 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7ffffffffffffffffffffffffbffffffffffffffffffffffff80 X7ffffffffffffffffffffffdfbf7ffffffffffffffffffffff80 X7ffffffffffffffffffffdfdfbf7f7ffffffffffffffffffff80 X7ffffffffffffffffffffefdfbf7f7ffffffffffffffffffff80 X7ffffffffffffffffffefefffbffefefffffffffffffffffff80 X7ffffffffffffffffffefffffbffffefffffffffffffffffff80 X7ffffffffffffffffffefffffbffffefffffffffffffffffff80 X7ffffffffffffffffefffffffbffffffefffffffffffffffff80 X7fffffffffffffffff7ffffffbffffffefffffffffffffffff80 X7fffffffffffffffff7fffffffffffffdfffffffffffffffff80 X7fffffffffffffff7fffffffffffffffffbfffffffffffffff80 X7fffffffffffffffbfffffffffffffffff7fffffffffffffff80 X7fffffffffffffffbfffffffffffffffff7fffffffffffffff80 X7fffffffffffffffdffffffffffffffffeffffffffffffffff80 X7fffffffffffffffdffffffffffffffffeffffffffffffffff80 X7fffffffffffffdfeffffffffffffffffdff7fffffffffffff80 X7fffffffffffffefeffffffffffffffffdfeffffffffffffff80 X7ffffffffffffffff7fffffffffffffffbffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7ffffffffffff7fffffffffffffffffffffffdffffffffffff80 X7ffffffffffffbfffffffffffffffffffffffbffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7ffffffffffeffffffffffffffffffffffffffefffffffffff80 X7fffffffffff7fffffffffffffffffffffffffdfffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffdfffffffffffffffffffffffffffff7fffffffff80 X7fffffffffeffffffffffffffffffffffffffffeffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7ffffffffffffffffffffffffffffffffffffffffbffffffff80 X7ffffffffbffffffffffffffffffffffffffffffe7ffffffff80 X7ffffffffcffffffffffffffffffffffffffffff9fffffffff80 X7fffffffff3ffffffffffffffffffffffffffffe7fffffffff80 X7fffffffffcffffffffffffffffffffffffffffdffffffffff80 X7ffffffffff7ffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffdffffffffffffffffffffffffffffffffe7fffffff80 X7fffffffe7fffffffffffffffffffffffffffffffdffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7ffffffe3fffffffffffffffffffffffffffffffff8fffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7ffffffbfffffffffffffffffffffffffffffffffff3ffffff80 X7ffffffcffffffffffffffffffffffffffffffffffefffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7ffffff1fffffffffffffffffbfffffffffffffffff1ffffff80 X7ffffffffffffffffffffffff1ffffffffffffffffffffffff80 X7fffffffffffffffffffffff001fffffffffffffffffffffff80 X7fffffffffffffffffffffff001fffffffffffffffffffffff80 X7fffffffffffffffffffffff001fffffffffffffffffffffff80 X7fffffffffffffffffffffff001fffffffffffffffffffffff80 X7ffffffffffffffffffffffe001fffffffffffffffffffffff80 X7fffffe00ffffffffffffffc001ffffffffffffffe00ffffff80 X7ffffffffffffffffffffffe000fffffffffffffffffffffff80 X7fffffffffffffffffffffff0007ffffffffffffffffffffff80 X7fffffffffffffffffffffff8003ffffffffffffffffffffff80 X7fffffffffffffffffffffff8003ffffffffffffffffffffff80 X7fffffffffffffffffffffff8001ffffffffffffffffffffff80 X7fffffffffffffffffffffff8000ffffffffffffffffffffff80 X7ffffff1ffffffffffffffff80007ffffffffffffff1ffffff80 X7fffffffffffffffffffffff80007fffffffffffffffffffff80 X7fffffffffffffffffffffff80003fffffffffffffffffffff80 X7fffffffffffffffffffffff80201fffffffffffffffffffff80 X7fffffffffffffffffffffff80300fffffffffffffffffffff80 X7fffffffffffffffffffffffc07c0fffffffffffffffffffff80 X7fffffffffffffffffffffffc07e07ffffffffffffffffffff80 X7ffffffcffffffffffffffffc07f03ffffffffffffefffffff80 X7ffffffbffffffffffffffffc07fc1fffffffffffff3ffffff80 X7fffffffffffffffffffffffc07fe1ffffffffffffffffffff80 X7fffffffffffffffffffffffc07ff0ffffffffffffffffffff80 X7fffffffffffffffffffffffc07ffc7fffffffffffffffffff80 X7fffffffffffffffffffffffc07ffe3fffffffffffffffffff80 X7fffffffffffffffffffffffc07fff3fffffffffffffffffff80 X7fffffffffffffffffffffffc07fffdfffffffffffffffffff80 X7ffffffe3fffffffffffffffc07fffffffffffffff8fffffff80 X7fffffffffffffffffffffffe07fffffffffffffffffffffff80 X7fffffffffffffffffffffffe0ffffffffffffffffffffffff80 X7fffffffffffffffffffffffe0ffffffffffffffffffffffff80 X7fffffffffffffffffffffffe0ffffffffffffffffffffffff80 X7fffffffffffffffffffffffe0ffffffffffffffffffffffff80 X7fffffffffffffffffffffffe0ffffffffffffffffffffffff80 X7fffffffe7ffffffffffffffe0fffffffffffffffdffffffff80 X7fffffffdfffffffffffffffe0fffffffffffffffe7fffffff80 X7fffffffffffffffffffffffe0ffffffffffffffffffffffff80 X7fffffffffffffffffffffffe0fffffffffffffdffffffffff80 X7ffffffffff7ffffffffffffe0fffffffffffffe7fffffffff80 X7fffffffffcfffffffffffffe0ffffffffffffff9fffffffff80 X7fffffffff3ffffffffffffff1ffffffffffffffe7ffffffff80 X7ffffffffcfffffffffffffff1fffffffffffffffbffffffff80 X7ffffffffbfffffffffffffff1ffffffffffffffffffffffff80 X7ffffffffffffffffffffffff1ffffffffffffffffffffffff80 X7ffffffffffffffffffffffff1ffffffffffffffffffffffff80 X7ffffffffffffffffffffffff1ffffffffffffffffffffffff80 X7ffffffffffffffffffffffff1ffffffffffffffffffffffff80 X7fffffffffeffffffffffffff1fffffffffffffeffffffffff80 X7fffffffffdffffffffffffff1ffffffffffffff7fffffffff80 X7ffffffffffffffffffffffff1ffffffffffffffffffffffff80 X7ffffffffffffffffffffffff1ffffffffffffffffffffffff80 X7ffffffffffffffffffffffffbffffffffffffffffffffffff80 X7ffffffffffffffffffffffffbffffffffffffffffffffffff80 X7fffffffffff7ffffffffffffbffffffffffffdfffffffffff80 X7ffffffffffefffffffffffffbffffffffffffefffffffffff80 X7ffffffffffffffffffffffffbffffffffffffffffffffffff80 X7ffffffffffffffffffffffffbffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7ffffffffffffbfffffffffffffffffffffffbffffffffffff80 X7ffffffffffff7fffffffffffffffffffffffdffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7ffffffffffffffffbfffffffffffffffdffffffffffffffff80 X7fffffffffffffeff7fffffffffffffffefeffffffffffffff80 X7fffffffffffffdff7fffffffffffffffeff7fffffffffffff80 X7fffffffffffffffefffffffffffffffff7fffffffffffffff80 X7fffffffffffffffefffffffffffffffff7fffffffffffffff80 X7fffffffffffffffdfffffffffffffffffbfffffffffffffff80 X7fffffffffffffffdfffffffffffffffffbfffffffffffffff80 X7fffffffffffffffbfffffffffffffffffdfffffffffffffff80 X7fffffffffffffffff7fffffffffffffdfffffffffffffffff80 X7fffffffffffffffff7ffffffbffffffefffffffffffffffff80 X7ffffffffffffffffefffffffbffffffefffffffffffffffff80 X7ffffffffffffffffffefffffbffffefffffffffffffffffff80 X7ffffffffffffffffffefffffbffffefffffffffffffffffff80 X7ffffffffffffffffffefefffbffefefffffffffffffffffff80 X7ffffffffffffffffffffefdfbf7f7ffffffffffffffffffff80 X7ffffffffffffffffffffdfdfbf7f7ffffffffffffffffffff80 X7ffffffffffffffffffffffdfbf7ffffffffffffffffffffff80 X7ffffffffffffffffffffffffbffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X0000000000000000000000000000000000000000000000000000 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7bffffffffffffffffffffffffffffffffffffffffffffffff80 X75ffffffefffffffffffffffffffffffffffffffffffffffff80 X6effffffffffffffffffffffffffffffffffffffffffffffff80 X6e969c71cf1fffffffffffffffffffffffffffffffffffffff80 X6eaa6baeefefffffffffffffffffffffffffffffffffffffff80 X60aae833ef0fffffffffffffffffffffffffffffffffffffff80 X6eaaebfdeeefffffffffffffffffffffffffffffffffffffff80 X6eaaebaeeeefffffffffffffffffffffffffffffffffffffff80 X6ebaec71c70fffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7ffffffffffffffffffffffffffffffffffffdffffffffffff80 X7ffffffffffffffffffffffffffffffffffffdffffffffffff80 X0000000000000000000000000000000000000000000000000000 X7ffffffffffffffffffffffffffffffffffffdffffffffffff80 X7ffffffffffffffffffffffffffffffffffffdffffffffffff80 X7ffffffffffffffffffffffffffffffffffff87fffffffffff80 X7ffffffffffffffffffffffffffffffffffff87fffffffffff80 X7ffffffffffffffffffffffffffffffffffff87fffffffffff80 X7fffffffffffffffffffffffffffffffffffd87fffffffffff80 X7fffffffffffffffffffffffffffffffffffd83fffffffffff80 X7fffffffffffffffffffffffffffffffffffd83fffffffffff80 X7fffffffffffffffffffffffffffffffffffd83fffffffffff80 X7fffffffffffffffffffffffffffffffffffc827ffffffffff80 X7fffffffffffffffffffffffffffffffffffc807ffffffffff80 X7fffffffffffffffffffffffffffffffffffc807ffffffffff80 X7fffffffffffffffffffffffffffffffffffc807ffffffffff80 X7fffffffffffffffffffffffffffffffffffc003ffffffffff80 X7fffffffffffffffffffffffffffffffffffc003ffffffffff80 X7fffffffffffffffffffffffffffffffffffc002ffffffffff80 X7fffffffffffffffffffffffffffffffffffc000ffffffffff80 X7fffffffffffffffffffffffffffffffffffc000ffffffffff80 X7fffffffffffffffffffffffffffffffffffc0007fffffffff80 X7bffffffffffffffffffffffffffffffffffc0007fffffffff80 X7bffffffffffffffffffffffffffffffffffc0007fffffffff80 X7bffffffffffffffffffffffffffffffffffc0007fffffffff80 X79ffffffffffffffffffffffffffffffffffc0003fffffffff80 X79ffffffffffffffffffffffffffffffffff40003fffffffff80 X79ffffffffffffffffffffffffffffffffff40001fffffffff80 X78ffffffffffffffffffffffffffffffffff40001fffffffff80 X70ffffffffffffffffffffffffffffffffff00001effffffff80 X70ffffffffffffffffffffffffffffffffff00000effffffff80 X607fffbfffffffffffffffffffffffffffff00000effffffff80 X607fffbfffffffffffffffffffffffffffff00000e7fffffff80 X603fff97ffffffffffffffffffffffffffff0000067fffffff80 X403fff97ffffffffffffffffffffffffffff0000067fffffff80 X401fff83ffffffffffffffffffffffffffff0000027fffffff80 X401fff83fffffffffffffffffffffff7ffef0000027fffffff80 X000ff781fffffffffffffffffffffff7ffad0000007fffffff80 X000ff781fffffffffffffffffffffff3ffa50000007fffffff80 X0007f380ffffffffffffffffffffffe3ff840000007fffffff80 X0007e180ffffffffffffffffffffffe1bf800000007fffffff80 X0003e1807fffffffffffffffffffffe1bf800000007fffffff80 X0003e0803fffffffffffffffffffffe09f800000007fffffff80 X0001e0803fffffffffffffffffffffe00f800000007fffffff80 X0000e0001fffffffffffffffffffffe00e800000007fffffff80 X0000e0000fffffffffffffffffffffe006000000007fffffff80 X000060000fffffffffffffffffffffe002000000007fffffff80 X0000200007ffffffffffffffffffffe000000000007fffffff80 X0000000003ffffffffffffffffffffc000000000007fffffff80 X0000000001ffffffffffffffffffffc000000000007fffffff80 X0000000000ffffffffffffffffffffc000000000007fffffff80 X00000000007fffffffffffffffffffc000000000007fffffff80 X00000000003fffffffffffffffffff8000000000007fffffff80 X00000000000fffffffffffffffffff8000000000007fffffff80 X000000000007ffffffffffffffffff8000000000007fffffff80 X000000000001ffffffffffffffffff8000000000007fffffff80 X0000000000003fffffffffffffffff8000000000007fff803f80 X0000000000000fffffffffffffffff8000000000007fff803f80 X00000000000000ffffffffffffffff8000000000007fff803f80 X0000000000000007ffffffffffffff8000000000007fff803f80 X000000000000000007ffffffffffff8000000000007fff803f80 X0000000000000000000000000000000000000000007fff803f80 X0000000000000000000000000000000000000000000000000000 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7800780000000000000000000000001fffffffffffffffffff80 X7aab7bffffffffffffffffffffffffdfffffffffffffffffff80 X7b557bffffffffffffffffffffffffdfffffffffffffffffff80 X7aab7bffffffffffffffffffffffffdfffffffffffffffffff80 X7b557bffffffffffffffffffffffffdfffffffffffffffffff80 X7aab7bfffffffffffdffffffffffffdfffffffffffffffffff80 X7b557bbfffeffffdfdfffbffffffffdfffffffffffffffffff80 X7aab7bbfffeffffffdfffbffffffffdfffffffffffffffffff80 X7bff7b0e3743fdd9e18e30ffffffffdfffffffffffffffffff80 X7bff7bbddaeffddddd75dbffffffffdfffffffffffffffffff80 X7bff7bbc1deffd5ddd741bffffffffdfffffffffffffffffff80 X7bff7bbdfdeffd5ddd75fbffffffffdfffffffffffffffffff80 X7bff7bb5daedfd5ddd85db7fffffffdfffffffffffffffffff80 X7bff7bce3773feb8e1f63cffffffffdfffffffffffffffffff80 X7bff7a7fffffffffff77ffffffffffdfffffffffffffffffff80 X7bff783fffffffffff8fffffffffffdfffffffffffffffffff80 X7bff799fffffffffffffffffffffffdfffffffffffffffffff80 X7bff7bffffffffffffffffffffffffdfffffffffffffffffff80 X7bff7bffffffffffffffffffffffffdfffffffffffffffffff80 X7bff7bffffffffffffffffffffffffdfffffffffffffffffff80 X7bff780000000000000000000000001fffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffffffff80 X7bff7fffffffffffffffffffffffffffffffffffffffff803f80 X78007fffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X0000000000000000000000000000000000000000000000000000 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffff803f80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7bfefffffffbbffeffffffffffffff6ec71dffbbffffffffff80 X75defffffffbbffefff7ff7efffffeeebaeeffbbffffefffff80 X6edefffffffbbffefff7ff7ffffffeeebeeeffbbffffffffff80 X6e869c69c7fbb1a6dc61c61cf1a7fdeebfef7fbb1a71cf1a7f80 X6ede6ba6fbfaae9abbb7fb7eee9bfdf5c7df7fd6e9aeeee9bf80 X60dee82ec3faaebe7cf7c37eeebbfdf5fbbf7fd60bf3eeebbf80 X6edeebeebbfaaebebf77bb7eeebbfef5fb7effd6fbfdeeebbf80 X6edaebaebbf92ebedbb6bb6eeebbfefbbafeffeeebeeeeebbf80 X6ee6ec6ec3fbb1beec79c39c71bbff7bc60dffef1bf1c71bbf80 X4fffffffffffffffffffffffffffffffffffffffffffffffff80 X07ffffffffffffffffffffffffffffffffffffffffffffffff80 X33ffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X7fffffffffffffffffffffffffffffffffffffffffffffffff80 X0000000000000000000000000000000000000000000000000000 X Xshowpage X%%Trailer SHAR_EOF if test 30520 -ne "`wc -c < 'xtk.fig3.PS'`" then echo shar: "error transmitting 'xtk.fig3.PS'" '(should have been 30520 characters)' fi fi exit 0 # End of shell archive ------- Message 3 the following is the sms paper. it requires the athena refer file, and pic. - --dan #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create: # sms # This archive created: Mon Jan 4 21:39:21 1988 export PATH; PATH=/bin:/usr/bin:$PATH echo shar: "extracting 'sms'" '(43388 characters)' if test -f 'sms' then echo shar: "will not over-write existing file 'sms'" else sed 's/^ X//' << \SHAR_EOF > 'sms' X.TL X.br XThe Athena Service Management System X.sp 3 X.AU XMark A. Rosenstein XDaniel E. Geer, Jr. XPeter J. Levine X.AI XProject Athena XMassachusetts Institute of Technology XCambridge, Massachusetts 02139 X{mar,geer,pjlevine}@ATHENA.MIT.EDU X.AB XMaintaining, managing, and supporting an unbounded Xnumber of distributed network services on multiple server instances Xrequires new solutions. XThe Athena Service Management System provides centralized control of data Xadministration, a protocol for interface to the database, tools for Xaccessing and modifying the database, and an automated mechanism for Xdata distribution. X.AE X.2C X.NH 1 XIntroduction X.PP XThe purpose of the Athena Service Management System (SMS) is to Xprovide a single point of contact for authoritative information about Xresources and services in a distributed computing environment. XSMS is a centralized data administrator providing Xnetwork-based update and maintenance of system servers.\(dg X.FS X\(dg Care must be taken to distinguish among different senses of the Xword ``server'': Xthe SMS server, which manages a database; Xthe servers which provide system services and whose Xmaintenance are SMS's reason for existence; and the update servers Xwhich allow SMS to affect these system services. X.FE X.IP \0\0\(bu 4 XConceptually, SMS provides mechanisms for managing servers and Xresources. This aspect comprises the fundamental design of SMS. X.IP \0\0\(bu 4 XEconomically, SMS provides a replacement for labor-intensive Xhand-management of server configuration files. X.IP \0\0\(bu 4 XTechnically, SMS consists of a database, a server and its protocol Xinterface, a data distribution manager, and tools for accessing and Xmodifying SMS data. X.LP XSMS provides coherent data access and data update. XAccess to data is provided through a Xstandard application interface. XPrograms designed to reconfigure network Xservers, edit mailing lists, manage group membership, etc., all use this Xapplication interface. XApplications used as administrative Xtools are invoked by users; Xapplications that update servers are X(automatically) invoked at regular intervals. XManagement reports and operational feedback are also provided. X.NH 2 XRequirements X.PP XThe requirements for the initial Athena SMS include: X.IP \0\0\(bu 4 XManagement of 15,000 accounts, including individual users, course, Xand project accounts, and special accounts used by system services. X.IP \0\0\(bu 4 XManagement of 1,000 workstations, timesharing machines, and network Xservers, including specification of default resource assignments. X.IP \0\0\(bu 4 XAllocation of controlled network services, Xsuch as creating and setting quotas for new users' Xhome directories on network fileservers, Xconsistent with load-balancing constraints. X.IP \0\0\(bu 4 XMaintenance of other control information, Xincluding user groups, mailing lists, access control lists, etc. X.IP \0\0\(bu 4 XMaintenance of resource directories, such as the Xlocation of printers, specialized file systems (including Xprivately supported file systems), and other network services. X.LP XThis must be accomplished with the utmost robustness. X.PP XThe system must be easily expandable, Xboth to support additional instances of a particular service Xand to offer additional services in the future. XAt this time, SMS is used to update three services (with RVD to be Xadded shortly): X.IP \0\0\(bu 4 X.I Hesiod: XThe Athena Name Service, X.I Hesiod, Xprovides service-to-server Xand label translation. XIt can be thought of as a high-performance, read-only Xfront-end to the SMS database. XSee the companion paper in this volume. X.[ XDyer Hesiod 1988 X.] X.IP \0\0\(bu 4 XNFS: XAt Athena, most shared-access read-write file systems Xare provided by a locally modified form of the Network File System. X.[ XSandberg NFSUsenix 1985 X.] XSMS manages the NFS server hosts, Xproviding quota-based resource allocation, Xand load balancing. XAlso refer to the companion paper in this volume. X.[ XSteiner KUsenix 1988 X.] X.IP \0\0\(bu 4 XMail Service: XAthena's mail service is through a central Xrouting hub to multiple post office servers X(mail repositories) based on the XPost Office Protocol X.[ XRose POP 1985 X.] X(POP) of the Rand Mail Handler X.[ XRand MH 1985 X.] X(MH) package. XSMS allocates individual post office boxes to post office servers, and Xbuilds the X.I /usr/lib/aliases Xcontrol file used on the central mail hub. X.IP \0\0\(bu 4 XRVD: XAt Athena, most shared-access read-only file systems Xare provided by Xa Remote Virtual Disk system. XSMS manages the RVD server hosts, Xproviding access control lists and Xserver configuration files. X.PP XEach of these server hosts are controlled by some number of Xserver-specific data files; Xover 50 separate files are required Xto support the services described above. XSMS currently supports three X.I Hesiod Xservers, 17 RVD file servers, X32 NFS file servers, Xone mail hub and three post offices. XEach RVD server requires one Xfile, and each server's file is different. XA X.I Hesiod Xserver requires 9 separate files containing 64000 resolvable queries, Xbut each X.I Hesiod Xserver receives the same 9 files. XEach NFS server requires two files, one file identical across most NFS Xservers, one file different. XThe mail hub requires one file, X.I /usr/lib/aliases. X.NH 2 XDesign Points X.PP XThere are five factors to be taken into account when making design Xdecisions. XIn order of importance, to this project Xthey are: X.RS 3 X.IP 1. 3 XReliability X.IP 2. XConsistency X.IP 3. XFlexibility X.IP 4. XTime Efficiency X.IP 5. XSpace Efficiency X.RE X.PP XSMS must be reliable. XIn particular, it must be designed to allow Xstraightforward recreation of SMS on replacement hardware from backups, Xshould the need arise. XThe backup regime for SMS consists of frequent database backups Xin ASCII format, to redundant sites. XAll components of the SMS system are designed such that a duplicate Xconfiguration can be kept running as a test platform without Xinterfering with normal, ``real,'' operations. XService updates are verified by testing the server before calling an Xupdate successful. XFailed operations ring alarms that are heard, Xdisabling parts of the system if required, but without Xinteractions with logically unconnected parts of the service Xmanagement system. XServices which are duplicated for availability are updated Xsuch that the service is always available; i.e., it is Xnot permitted for server updates to drift into unwarranted Xsynchrony, bringing down all instances at the same time. XThe entire life-cycle is considered part of the package, so Xtight change and source-code control X(reviewing each change to source, Xrunning only what can be built from source) Xis part of the design. X.PP XIn addition to having authoritative control of the data, XSMS must see that the data is kept consistent. XTo guarantee internal consistency, XSMS clients do not touch the database directly; Xthey do not even see the database system used by SMS. XEach application uses the application library to access the database. XThis library is a collection of functions allowing access to the database by Xcommunicating with the SMS server using the SMS protocol. XMany of the database consistency constraints are handled by the library. XA number of consistency verification applications also exist. XTo make this consistency reliable, Xthe protocol is designed to be tamper-proof, Xwithstanding both denial-of-service attacks and malicious attempts to Xcorrupt the data. XSecurity is provided with the help of authentication by the X.I Kerberos Xprivate-key authentication system. XSee the companion paper in this volume. X.[ XSteiner KUsenix 1988 X.] X.PP XBeyond these goals, SMS must be flexible in both its database Xunderpinnings and the services it supports. XAs discussed later in the design section, the Xparticular Database Management System used is insulated from SMS Xthrough a Global DataBase X(GDB) library, X.[ XMendelsohn GDB 1987 X.] Xmaking SMS plug-compatible with other database Xfoundations. XIt is independent of the individual services\(emwhile each Xservice updated by SMS has its own particular data format and Xstructure, the SMS database stores data in one coherent format. XA separate program, Xthe Data Control Manager (DCM), Xconverts SMS database (internal) structure to Xserver-appropriate structure (such as a configuration file). XWhen a new service is supported, the database can be changed and only Xminimal updates are necessary in the SMS server, and Xa new module is Xadded to the DCM specifying the additional specific Xoutput data format to be manufactured. X.PP XAlso, Xin the interests of flexibility, Xno administrative Xpolicy decisions are coded into the design. XThese are determined only by the data in the database. X.PP XSimplicity of the design is more important than Xthe speed of operation; Xother systems, such as the X.I Hesiod Xname service, Xprovide a high bandwidth read-only interface to the database. XTo this end, the server only supports simple queries. XProcessing efficiency for complex queries is maximized by local Xapplications running on the workstation, not on the central server. XAny set of changes that must be atomic to maintain database Xconsistency are performed on the server; sets of non-atomic changes Xand complex lookup operations are supported Xin the server only through combining simpler queries. X.NH XSystem Design X.PP XThere are three sides to the SMS system: X.IP \0\0\(bu 4 XThe input side, Xwhich contains all of the user-interface programs, Xallowing the user to enter, examine, or modify data in the database. X.IP \0\0\(bu 4 XThe database side, Xwhich consists of the actual database, Xthe SMS server which manipulates the database, Xand utility programs to backup, restore, Xand verify the internal consistency of the database. X.IP \0\0\(bu 4 XThe output side, Xwhich extracts information from the database, formats Xit into server-specific configuration files, and updates the various Xservers by propagating these files. X X.PS Xlinewid=.25i; circlerad=.5i Xcircle "Input" "\s8User Interface\s0" Xline <->; circle "Database" "\s8SMS Server\s0" Xarrow; circle "Output" "\s8DCM & Update\s0" X.PE X X.PP XVarious amounts of glue are required to connect these three sides. XAt the lowest level, Xthere is the network protocol that Xclient programs use to gain access to the database. XThis, Xhowever, Xdepends on the actual model of how database queries are done, Xwhich is influenced Xby the organization of the database (but not its exact format, Xwhich is hidden through the protocol). X.NH 2 XThe SMS Protocol X.PP XThe SMS protocol is the fundamental Xinterface to SMS for client applications. XIt allows all clients of SMS to speak a common, Xnetwork-transparent language. X.PP XThe SMS protocol is a remote procedure call protocol based on the GDB Xlibrary, Xwhich in turn uses a TCP stream. XEach client program makes a connection to a Xwell known port to contact the SMS server, Xsending requests and receiving replies Xover that stream. XEach request consists of a major request number, Xand several counted strings of bytes. XEach reply consists of a single status code followed by zero or more Xcounted strings of bytes. XRequests and replies also contain a protocol version number, Xto allow clean handling of version skew. X.PP XThe following major requests are defined for SMS. XIt should be noted that each query Xdefines its own signature of arguments and results. XFor some of these actions the server checks authorization based on the Xauthenticated identity of the user making the request. X.IP \fBnoop\fP 10 XDo nothing. XThis is useful for testing and profiling of the server. X.IP \fBauthenticate\fP 10 XThere is one argument, a X.I Kerberos X.[ XMiller KTech 1987 X.] Xauthenticator. XAll requests received after this request are performed on behalf Xof the principal identified by the authenticator. X.IP \fBquery\fP 10 XThe first argument is the name of a pre-defined query (a ``query Xhandle''), and the rest are arguments to that query. XQueries may retrieve information or modify what is in the database. XIf the server query is allowed, any retrieved data Xare passed back as several return values. All but the last returned Xvalue will have a status code Xindicating more data, with the final one Xreturning the real status code of the query. X.IP \fBaccess\fP 10 XThere are a variable number of arguments. XThe first is the Xname of a pre-defined query usable for the ``query'' request, Xand the rest are query arguments. XThe server returns a reply with a zero Xstatus code if the query would have been allowed, Xor a reply with a Xnon-zero status code explaining why the query was rejected. X.PP XNormal use of the protocol consists of establishing a connection, Xproviding authentication, then performing a series of queries. XAs long as the Xapplication only wants to retrieve data or perform simple updates, Xonly an authenticate followed by queries are necessary. XThe access operation is useful for verifying Xthat an operation with side effects will succeed before attempting it. X.NH 2 XQueries X.PP XAll access to the database by clients is provided by the Xapplication library via the SMS protocol. XThis interface provides a limited set of predefined, named queries, Xallowing tightly controlled access to database information. XQueries fall into four Xclasses: retrieve, update, delete, and append. XAn attempt has been Xmade to define a set of queries that provide sufficient flexibility to Xmeet all of the needs of the Data Control Manager as well as the Xindividual application programs, since the DCM uses the same interface Xas the clients to read the database. XSince the database can be modified and extended, the application Xlibrary has been designed to allow the easy addition of queries. X.PP XThe generalized layer of functions makes SMS independent of the Xunderlying database. XIf a different database management system is required, Xthe only change needed Xwill be a new SMS server. XIt is made by linking the pre-defined queries to a set of data Xmanipulation procedures provided by a version of GDB suited to Xthe alternate DBMS. X.PP XAt this time there are over 100 supported queries. See the complete Xtechnical description of SMS for a listing. X.[ XSMSTech X.] XSome sample queries include: X.IP \fBget_nfs_quotas\fP X.br XArguments: machine, device X.br XReturns: list of login/quota tuples X.br XErrors: no match, bad machine X.br X.I XRetrieves disk quota assignments for all users on the specified disk Xpartition. X.IP \fBget_user_by_login\fP X.br XArguments: login name X.br XReturns: login, uid, shell, home, last, first, middle, status, ID Xnumber, year, expiration date, modification time X.br XErrors: no match, not unique X.br X.I XRetrieves information about a particular user, searching by Xlogin name. Similar queries exist to search by last name, first name, Xuser ID, and Registrar's ID number. X.R X.IP \fBadd_machine\fP X.br XArguments: name, type, model, status, serial number, system type X.br XReturns: nothing X.br XErrors: already exists, bad type X.br X.I XAppends a new machine to the list of machines known by SMS. X.R X.IP \fBupdate_server_info\fP X.br XArguments: service, update interval, target file, script, dfgen X.br XReturns: nothing X.br XErrors: no match, not unique X.br X.I XUpdates a service entry, allowing anything but the service Xname to be changed. X.R X.IP \fBdelete_filesys\fP X.br XArguments: label X.br XReturns: nothing X.br XErrors: no match, not unique X.br X.I XDeletes the specified file system information from the database. XDoes not automatically reclaim the storage at this time. X.R X.LP XEach query has two possible return status values Xin addition to any errors given above: X.B success Xand X.B permission_denied. X.NH 2 XThe Database Management System X.PP XThe database is the core of SMS. XIt provides the storage mechanism Xfor the complete system. XSMS expects its database to consist of Xseveral tables of records with strings, integers, and dates. XTables Xare keyed on one or more fields in each record allowing efficient Xretrieval by key or wild cards. X.PP XThe database currently in use at Athena is Ingres X.[ XRTIngres 1986 X.] Xfrom Relational Technology, Inc. XIngres provides a complete query system, Xa C library of routines, Xand a command interface language. XIts advantages are that it is available and that it mostly works. XBy design, XSMS does not depend on any special feature of Ingres Xso as to retain the option to Xutilize other relational database systems. X.PP XThe database is an independent entity from the SMS system. XThe Ingres query bindings and database-specific routines are layered Xat the lower levels of the SMS server. XAll applications are independent of database-specific routines. XAn application passes Xquery handles to the SMS server which then resolves the request into Xan appropriate database query. X.PP XThe database contains several types of objects. Each object in the Xdatabase has an access control list (ACL) associated with it Xindicating who is allowed to modify that object. XEach object also has records who last modified it and when that Xmodification was performed. XThe ACL's are just references to lists in the database. XThe database contains the following: X.IP \0\0\(bu 4 XUser information: full name, login name, user ID, registrar's ID, Xlogin shell, home directory, class year, status, modification time, Xnickname, home address, home phone, office address, office phone, Xschool affiliation, an ACL X.IP \0\0\(bu 4 XMachine information: name, type, model, status, serial number, system Xtype, an ACL X.IP \0\0\(bu 4 XCluster (mapping of machines to default printer and RVD server) Xinformation: name, description, location, default servers, Xmachine assignments, an ACL X.IP \0\0\(bu 4 XGeneral service information: service name to network port mapping X.IP \0\0\(bu 4 XFile system configuration: name, type, server host, name on server Xhost, mount point on client host, access mode, an ACL X.IP \0\0\(bu 4 XNFS information: host name, physical disk partition, quota by user Xon each partition, an ACL X.IP \0\0\(bu 4 XRVD information: host name, physical disk partition, virtual Xdisks assigned to each partition, pack ID, access passwords, size, an XACL X.IP \0\0\(bu 4 XPrinter information: name to X.I /etc/printcap Xentry mapping X.IP \0\0\(bu 4 XPost office location: for each user post office server and box on that Xserver X.IP \0\0\(bu 4 XLists: name, description, modification date, members (which can be Xusers, other lists, or literal strings), attributes (mailing list, XUNIX group and gid), an ACL X.IP \0\0\(bu 4 XAliases: includes allowed keywords for certain fields in the database, Xalternate names for file systems, alternate names for services X.IP \0\0\(bu 4 XDCM information: services to be updated, hosts supporting each Xservice, target files on each host, last update time, Xenable/override/success flags for updates X.IP \0\0\(bu 4 XInternal control information: next user ID, group ID, machine ID, and Xcluster ID to assign (these are just hints); an ACL for each query; usage Xstatistics X.NH 2 XSMS-to-Server Update Protocol X.PP XSMS provides a reliable mechanism for updating the servers it manages. XThe goals of the server update protocol are: X.IP \0\0\(bu 4 XRational, automatic update for normal cases and expected kinds of failures. X.IP \0\0\(bu 4 XAbility to survive clean (target) server crashes. X.IP \0\0\(bu 4 XAbility to survive clean SMS crashes. X.IP \0\0\(bu 4 XEasily understood state so that straightforward recovery by hand is Xpossible. X.PP XAll actions are initiated by the SMS system. XUpdates of managed servers are performed such that a partially completed Xupdate is harmless. XUpdates not completed are simply rescheduled for retry until Xthey succeed, or until an update can not be initiated. XIn the latter case, a human operator will be notified. X.PP XThe update protocol is based on the GDB library just as is the SMS protocol Xitself. In the update protocol, there are four commands: X.IP \fBauthenticate\fP 11 XA X.I Kerberos Xauthenticator is sent. The update server on Xthe target Xserver uses this authenticator to verify that the entity Xcontacting it is authorized Xto initiate updates. X.IP \fBtransfer\fP XThis command is used for sending information, usually entire Xfiles. The protocol is capable of efficiently sending a half-megabyte Xbinary file. X.IP \fBinstructions\fP XThis sends over a command script, which when executed on the target Xserver will install the new configuration files just sent. X.IP \fBexecute\fP XThis instructs the update server to execute the instructions Xjust sent. X.PP XIn typical usage, all four commands are used in the order presented above. XMultiple transfers may be necessary for some server types. Note that Xwhen data files are transfered, they do not directly overwrite the Xexisting data files. Instead, they are put in a temporary position. XWhen the update is executed, the old files are renamed to another Xtemporary name, and the new files are given the correct names. This Xminimizes the interval during which a server system crash would leave an Xinconsistent set of configuration files. If all portions of the Xpreparation are completed without error, the execution is then Xallowed. This usually consists of moving files around, then sending a Xsignal to or restarting a server process. The update server then Xperforms a plausibility check on the result by verifying the operation Xof the system server, and sends SMS an indicative return code. X.NH 1 XSystem Components X.PP XSix software components make up the SMS system. X.IP \0\0\(bu 4 XThe database, currently built on the commercial database system XRTI Ingres. X.IP \0\0\(bu 4 XThe SMS server, a program always running on the machine containing the Xdatabase. It accesses the database for the client programs. X.IP \0\0\(bu 4 XThe application library, a collection of routines implementing the SMS Xprotocol. It is used by client programs to communicate with the XSMS server. X.IP \0\0\(bu 4 XThe client programs, a collection of programs that make up Xthe user interface to the system. X.IP \0\0\(bu 4 XThe data control manager, a program run periodically by X.I cron Xand driven by data in the database. XIt constructs up-to-date server configuration Xfiles and installs these files on the servers. X.IP \0\0\(bu 4 XThe update servers, which run on each machine containing a server that XSMS updates. XThese are contacted by the data control manager to Xinstall the new configuration files and notify the real servers being Xmanaged by SMS. X X.PS Xlinewid = .25i; lineht = .2i Xcirclerad = .3i X XCH: Xcircle "chpobox" "app. lib." radius .35 Xmove to CH; move right; XMM: Xcircle "usermaint" "app. lib." radius .35 Xline dotted from CH.w to CH.e+(-.05,0) Xline dotted from MM.w to MM.e+(-.05,0) Xdown Xmove to CH+(.45,.7); box dashed width 1.8 height 1.2 Xmove to CH+(.45,.7); box invis width 1.8 "User Workstation" X Xmove to CH+(-.05,-1) XSVR: Xcircle "SMS" "server" Xmove to SVR.e; arrow right XDB: Xbox "database" Xmove to SVR; move down XDCM: Xcircle "DCM" Xmove to DCM.n; arrow to SVR.s Xmove to DB; move down XBU: Xcircle "backup" Xmove to BU.n; arrow to DB.s Xmove to SVR+(.5,.4); box dashed width 1.8 height 1.8 Xmove to SVR+(.5,-1); box invis width 1.8 "SMS Machine" X Xarrow from CH to SVR chop .35 chop .3 Xarrow from MM to SVR chop .35 chop .3 Xmove to SVR+(.2,.8); box invis width 1.7 "SMS Protocol" X Xmove to DCM+(0,-1) XUL: Xcircle "update" "server" radius .35i Xmove to UL.e; arrow right XNFS: Xbox "NFS" "server" Xmove to UL+(-.4,-.1); box dashed width 1.8 height 1 Xmove to UL+(-.4,-.5); box invis width 1.8 "System Server" X Xarrow from DCM to UL chop .3 chop .35 Xbox invis at UL+(.2,.55) "Update Protocol" X X.PE X X.PP XBecause SMS has a variety of interfaces, a distinction must be Xmaintained between applications called clients that directly read and Xwrite to SMS (i.e., administrative programs) and services which use Xinformation distributed from SMS (i.e. a name server). In both cases Xthe interface to the SMS database is through the SMS server, using the SMS Xprotocol. The significant difference is that server update is handled Xautomatically through the Data Control Manager; administrative programs Xare executed by users. X.NH 2 XClients X.PP XSMS includes a set of specialized management tools to grant system Xadministrators overall control of system resources. XFor each system service there Xis an administrative interface. To accommodate novice and occasional Xusers, a menu interface is the default. For regular users, a Xcommand-line switch is provided that will use a line-oriented Xinterface. This provides speed and directness for users Xfamiliar with the system, while being reasonably helpful to novices Xand occasional users. A specialized menu building tool has been Xdeveloped in order that new application programs can be developed Xquickly. This user interface does not depend on the X Window System. X.[ XScheifler XACM 1987 X.] XIt must be possible for Xsystem operators to use dumb terminals to correct resource problems, Xi.e. it cannot be a requirement that a high level of functionality Xbe present before the service management system can operate. X.PP XFields in the database have associated with them lists of legal Xvalues. A null list indicates that any value is possible. This is Xuseful for fields such as \fIuser_name, address\fP, and so forth. The Xapplication programs, before attempting to modify anything in the Xdatabase, request this information, and compare it with the proposed Xnew value. If an invalid value is discovered, it is reported to the Xuser, who is given the opportunity to change the value, or ``insist'' Xthat it is a new, legal value. (The ability to update data in the Xdatabase does not necessarily indicate the ability to add new legal Xvalues to the database.) X.PP XApplications should be aware of the ramifications of their actions, Xand notify the user if appropriate. For example, an administrator Xdeleting a user is informed of storage space that is being reclaimed, Xmailing lists that are being modified, and so forth. XObjects that need to be Xmodified at once (such as the ownership of a mailing list) Xpresent themselves to be dealt with. X.PP XThe following list of client programs are currently in use at Project XAthena. These are rewrites of standard XUNIX Xprograms, and are available to Xregular users: X.IP \0\0\(bu 4 X.I chfn X- change finger information X.IP \0\0\(bu 4 X.I chsh X- change default shell X.LP XThese are new programs available to regular users: X.IP \0\0\(bu 4 X.I register X- allow new students to claim an Athena account X.IP \0\0\(bu 4 X.I mailmaint X- allow users to add/delete themselves to mailing lists X.LP XThese are used by system administrators: X.IP \0\0\(bu 4 X.I Xattachmaint X.R X- map file system names to physical server configurations X.IP \0\0\(bu 4 X.I Xchpobox X.R X- change forwarding post office for a user X.IP \0\0\(bu 4 X.I Xclustermaint X.R X- associate a machine with a set of default servers X.IP \0\0\(bu 4 X.I Xdcmmaint X.R X- update DCM table entries, including service/machine mapping X.IP \0\0\(bu 4 X.I Xlistmaint X.R X- create and maintain groups, mailing lists, and access Xcontrol lists X.IP \0\0\(bu 4 X.I Xnfsmaint X.R X- configure NFS file servers X.IP \0\0\(bu 4 X.I Xportmaint X.R X- maintain the list of well known contact ports X.IP \0\0\(bu 4 X.I Xregtape X.R X- enter new students from the Registrar's tape X.IP \0\0\(bu 4 X.I Xrvdmaint X.R X- configure RVD servers X.IP \0\0\(bu 4 X.I Xusermaint X.R X- maintain user information including file service and Xpost office location X.LP XFinally, this program is used only in debugging SMS: X.IP \0\0\(bu 4 X.I Xsmstest X.R X- perform any query manually X.NH 3 XNew User Registration X.PP XA specialized client is the new user registration program. A new Xstudent must be able to claim an Athena account without any intervention Xfrom Athena user accounts staff. XWithout this the user accounts staff would be faced with manually Xcreating hundreds of accounts at the beginning of each academic term. X.PP XAthena obtains a copy of the official list of registered students from Xthe MIT Registrar shortly before the start of each term. The X.I regtape Xclient adds each student on the Registrar's tape who has not already Xbeen registered for an Athena account to the ``users'' relation of the Xdatabase, and assigned a unique user ID; the student is not assigned a Xlogin name or any other resources at this time. A one-way encrypted Xform of the student's ID number is stored along with the name. No Xother database resources are allocated at that time. This ID number Xand the exact spelling of the student's full name as recorded by the XRegistrar are all that are needed for a student to claim an account. XThus the ID number is something of a password until a real account has Xbeen set up. X.PP XWhen the student decides to register with Athena, he or she walks up Xto any workstation and logs in using the username of ``register''. XThis produces a form-like interface prompting for the user's first Xname, middle initial, last name, and student ID number. The X.I register Xprogram does not talk to the SMS server directly, but goes through a Xregistration server first. The registration server deals with access Xcontrol to the SMS server and the X.I Kerberos Xadministration server. XRegister encrypts the ID number, and sends a X.I verify_user Xrequest to the registration server. The server responds with X.B Xalready_registered, not_found, X.R Xor X.B OK. XAfter this the Xregister server will do work on behalf of the user; the user still Xcannot contact SMS directly until he or she obtains a login name and Xuser ID. X.PP XIf the user has been validated, X.I register Xthen prompts the student for a Xchoice in login names. It then goes through a two-step process to Xverify the login name: first, it simulates a login request for this Xuser name with X.I Kerberos; Xif this fails (indicating that the username Xis free and may be registered), it then sends a X.B grab_login Xrequest. On receiving a X.B grab_login Xrequest, the registration server then proceeds to register the login Xname with X.I Kerberos; Xif the login name is already in use, it returns a failure code to X.I register. XOtherwise, it allocates a home directory for the user Xon the least-loaded fileserver, Xsets an initial disk quota for the user, Xbuilds a post office entry for the user Xon the least-loaded post office server, Xand returns a success code Xto X.I register. XSMS keeps track of loading on servers in the database, incrementing Xand decrementing its estimate of the load as it allocates and Xdeallocates resources on each server. X.PP X.I Register Xthen prompts the user for an initial password. XIt sends a X.B set_password Xrequest to the registration server, which decrypts it and forwards it to X.I Kerberos. XAt this point, pending propagation of Xinformation to the X.I Hesiod Xname service, the central mail hub, and the user's home fileserver, Xthe user's account has been established. XThese updates may take up to 12 hours to complete. X.NH 2 XThe SMS Server X.PP XAs previously stated, Xall remote communication with the SMS database is done through the SMS Xserver, using the SMS protocol. The SMS server runs as a single XUNIX Xprocess on the SMS database machine. It listens for connections on a Xwell known service port and processes remote procedure call requests Xon each connection it accepts. X.PP XGDB, through the use of BSD XUNIX Xnon-blocking I/O, allows the Xprogrammer to set up a single-process server that handles multiple Xsimultaneous TCP connections. The SMS server will be able to make Xprogress reading new RPC requests and sending old replies Xsimultaneously, which is important if a reasonably large amount of Xdata is to be sent back. The RPC system from Sun Microsystems was Xalso considered for use in the XRPC layer, but was rejected because it cannot handle large return Xvalues, such as might be returned by a complex query. X.PP XA major concern for efficiency in some DBMS's is the time it Xtakes to begin accessing the database, sometimes requiring starting up Xa backend process. Since this is a heavyweight operation, the XSMS server will do this only once when it starts. X.PP XThe server performs access control checks on all queries. An access control Xlist (ACL) is associated with each query handle, and with many objects within Xthe database. For instance, to add someone to a list, it is Xsufficient to either be on the ACL associated with the X.B add_member_to_list Xquery, or to be on the ACL of the list in Xquestion. XIn addition, lists, users, machines, and Xfile systems have lists of additional users who are allowed to modify Xthem. XThe concept of an all powerful database administrator is Xnot necessary with SMS, although could be implemented by having the Xsame ACL for all queries that affect the database. X.PP XBecause one of the requests that the server supports is a request to Xcheck access to a particular query, it is expected that many access Xchecks will have to be performed twice: once to allow the client to Xfind out that it should prompt the user for information, and again Xwhen the query is actually executed. It is expected that some form of Xaccess caching will eventually be worked into the server for Xperformance reasons. X.NH 3 XInput Data Checking X.PP XWithout proper checks on input values, a user could easily enter data Xof the wrong type or of a nonsensical value for that Xtype into SMS. For example, consider the case of updating a user's mail Xaddress. If, instead of typing ``athena-po-1'' (a valid post office server), Xa user accounts administrator Xtyped in ``athena-po1'' (a nonexistent machine), all the user's mail Xwould be returned to sender as undeliverable. X.PP XInput checking is done by both the SMS server and by applications Xusing SMS. Each query supported by the server may have a validation Xroutine supplied which checks that the arguments to the query are Xlegitimate. Queries that do not have side effects on the database do Xnot need a validation routine. X.PP XSome checks are better done in applications programs; for example, the XSMS server is not in a good position to tell if a user's new choice Xfor a login shell exists. However, other checks, such as verifying Xthat a user's home directory is a valid file system name, are conducted Xby the server. An error condition will be returned if the value Xspecified is incorrect. The list of predefined queries defines those Xfields which require explicit data checking. X.NH 2 XBackup X.PP XIt is not critical that the SMS database be available 24 Xhours a day; what is important is that the database remain internally Xconsistent and that the data never be lost. With that in Xmind, the database backup system for SMS has been set up to maximize Xrecoverability if the database is damaged. Backup is done Xin a simple ASCII format to avoid dependence on the actual DBMS in use. X.PP XTwo programs X.I (smsbackup Xand X.I smsrestore) Xare generated Xautomatically (using an X.I awk Xscript) from the database description Xfile. X.I smsbackup Xcopies each relation of the current SMS database Xinto an ASCII file. X.I Smsbackup Xis invoked nightly by a command Xfile that maintains the last three backups on-line. These backups Xare put on a separate physical disk drive from the drive containing Xthe actual database and copied over the network to other locations. X.I Smsrestore Xdoes the inverse of X.I smsbackup, Xtaking a set of ASCII files and recreating the Xdatabase. These backups by themselves provide recovery with the loss of no Xmore than roughly a day's transactions. To obtain complete recovery, Xit is necessary to examine the log files of the servers. XAn automated procedure to do this has not been written since it is Xcomplicated and has not been needed yet. X.NH 2 XThe Data Control Manager X.PP XThe Data Control Manager is a program responsible for Xdistributing information to servers. The DCM is invoked by X.I cron Xat regular, frequent intervals. XThe data that drives the DCM is read from the database, rather Xthan being coded into the DCM or kept in separate configuration files. XEach time the DCM is run, it scans the database to Xdetermine which servers need updating. Only those that need Xupdating because their configuration has changed and their update Xinterval has been reached will be updated. X.PP XThe determination that it is time to check a service is based on Xinformation about that service in the database. Each service has an Xupdate interval, specifying how often providers of that service should Xbe updated, and an enable flag. For each server/host tuple, the Xdatabase stores the time of the last update attempt, whether or not it Xwas successful, and an override flag. If the previous update attempt Xwas not successful, the override flag will indicate when to try again. XThe administrative user's interface provides a mechanism to set the Xoverride flag manually, so as to update a server sooner than it Xotherwise would be updated. X.PP XLocking is also provided since an update may still be in progress the Xnext time the DCM is invoked. Without this locking the new DCM Xprocess would attempt to update the same service that the older process Xis still working on. X.PP XIf it is necessary to update a server, a separate program (also named in Xthe database) is invoked to extract the information from the database Xand format into the server-specific files. The DCM then contacts the Xupdate server on the machine with the target server, Xsends the necessary data files and the shell script that is invoked Xon the server machine to install the new files. XThe success flag is set or cleared based on whether the update attempt Xsucceeded. If the attempt failed, the override flag is set, Xrequesting that another attempt be made to update this server sooner Xthan indicated by the default update interval. X.PP XFor performance reasons, some parts of the DCM currently touch the Xdatabase directly rather than going through the SMS server. Nothing Xis being done that could not be done through the server. However, Xbypassing the server makes extracting large amounts of information Xmuch faster and avoids slowing down the server for these operations. X.NH 1 XSystem Performance X.PP XThe system is more reliable than the one previously in Xuse at Athena. The old version had an update mechanism more suited to Xthe scale Xof tens of timesharing hosts rather than thousands of workstations. XSystem crashes have been rare. XThe speed of the system Xis fair, being fast enough to use interactively, although some queries Xdo take a while to complete. The database currently Xoccupies about 13 megabytes on the server. X.PP XMost of the system as described here has been in use for over six Xmonths. A few of the points mentioned here are just now being Ximplemented and put into service. XNote that this is the only management Xtool for 5000 active users, 650 workstations, and 65 servers. X.NH 2 XAvailability X.PP XThe SMS server has nearly always been accessible. Some queries, such Xas listing all publicly accessible mailing lists, will tie up the Xserver for a short period of time. Regular users are prohibited from Xthe longer queries such as listing all users, which will lock up the Xserver for several minutes. The server is occasionally down for Xsafety when an SMS administrator wishes to modify the database directly Xthrough Ingres. X.NH 2 XSecurity X.PP X.I Kerberos Xauthentication on all network access and physical security Xof the machine have been sufficient to prevent breakins. XHowever, the system has not had enough exposure to believe Xit is really resistant to concerted attacks. X.PP XOne problem with the current implementation Xhas to do with security and access control lists. It is difficult to Xadminister the numerous ACL's in the system, and it is not always obvious Xwhen different queries are used to predict the effects of changing an XACL. Currently this problem is avoided by having two classes of Xqueries: those that anyone can do, and those that only the database Xadministrators can perform. There need to be more intermediate Xlevels. For instance, it would be useful to allow some system operators Xto change the information describing public workstations, but not the Xtimesharing machines and service hosts. X.NH 2 XConsistency X.PP XThe current database suffers from decay. The database grows indexes Xand reference counts that are wrong, post office boxes that do not Xbelong to any user, and groups with no members. These are assumed to Xbe caused by coding errors in the client library and clients. Any Xproblem is potentially compounded by the very X.I Xraison d'\*^etre X.R Xof SMS. XWith hundreds of workstations in the field there is no guarantee that SMS Xclient programs installed on them are all at current revision level. XThere are also a few problems suspected in the Xdatabase system itself (Ingres), but these are difficult to pinpoint. XHowever, the various data extraction programs used by the DCM are Xrobust; they skip over any inconsistent records so these cause few Xproblems. X.PP XA database consistency checker, in the spirit of X.I fsck, Xis run Xregularly, but only for informational purposes. Because of the Xdangers involved in modifying the database outside the SMS server, it Xis not modified by this checker at this time. X.PP XA shortcoming of the current system is that it is occasionally Xnecessary to use Ingres directly to make some modification to the Xdatabase. For example, it was recently necessary to modify every Xinstance of a particular login shell in the user account information. XA special client could have been written to do this, but it would only Xbe used once, so the operation was done interactively with the Ingres Xquery interpreter. A large number of similar operations to be Xexecuted would normally imply a need for a generalized batch Xprocessor. This is is too complicated for our needs, hence such Xoperations are either done by hand through the regular clients, or Xedited into a script that can be run through the raw Ingres Xinterpreter. Availability of this interpreter makes such operations Xrelatively easy; yet there is the temptation to fix too many things Xthat way, bypassing the checks built in to the client library and SMS Xserver. X.PP XCare must be taken to avoid hardcoding into the SMS design current Xpolicy decisions about accounts and resources here at Athena. Yet by Xmaintaining this flexibility, it sometimes is too easy to break the Xrules. This is more often an error than an intentional breaking of Xthe rules. XFor instance, there have been users who did not have a post office box Xbecause of administrative mistakes; they were unable to receive mail. X.NH 1 XConclusion X.PP XSystems for managing the otherwise unmanageable need Xto be designed well, burned in realistically, and Xprovided with seamless upgrades. XWith the Athena SMS, we have an example Xof a system that is working for the scale of 1,000 Xworkstations, but needs significant Xrefinement to go to the 10,000 workstation level. XThe initial vision has proven correct; the remaining Xquestion is whether the design as we now have it will Xbe capable of the next leap in scale. We believe it Xwill and will be back to report to you with our results. X.SH XAcknowledgments X.PP XThe authors would like to acknowledge the following people Xfrom M.I.T. Project Athena for their help in making SMS a Xreality: XMichael R. Gretzinger, a former Systems Programmer, and William E. XSommerfeld, Jean Marie Diaz, Ken Raeburn, Jos\*'e J. Cap\*'o, and Mark XA. Roman, students working for XAthena System Development, who helped with the design and Ximplementation of the system; and XJerome Saltzer, Technical Director of Project Athena, and Jeffery XSchiller, Manager of Operations at Project Athena, for invaluable Xcritiques of the design of the system and this paper. X.SH XReferences X.[ X$LIST$ X.] SHAR_EOF if test 43388 -ne "`wc -c < 'sms'`" then echo shar: "error transmitting 'sms'" '(should have been 43388 characters)' fi fi exit 0 # End of shell archive ------- Message 4 the following is the athena changes to bsd paper. it requires the athena refer file. - --dan #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create: # changes # This archive created: Mon Jan 4 21:41:24 1988 export PATH; PATH=/bin:/usr/bin:$PATH echo shar: "extracting 'changes'" '(39605 characters)' if test -f 'changes' then echo shar: "will not over-write existing file 'changes'" else sed 's/^ X//' << \SHAR_EOF > 'changes' X.hw workstation X.TL XBerkeley X.UX Xon 1000 Workstations: X XAthena Changes to 4.3BSD X.AU XG. Winfield Treese X.AI XProject Athena XMassachusetts Institute of Technology XCambridge, MA 02139 Xtreese@ATHENA.MIT.EDU X.AB X4.3BSD X.UX Xas shipped is designed for use on individually-managed, networked Xtimesharing systems. A large network of individual workstations and server Xmachines, all managed centrally, has many important differences from such Xa model. XThis paper discusses some of the changes necessary for 4.3 in this new world, Xincluding the file system layout, configuration files, and software. The Xintegration with Athena's authentication system, name service, and service Xmanagement system is also discussed. X.AE X.2C X.NH XOverview X.PP X``By 1988, create a new educational computing environment environment at M.I.T. Xbuilt around high-performance graphics workstations, high-speed networking, Xand servers of various types.'' This one-sentence statement is a high-level Xdescription of the technical goals of Project Athena. While the primary Xgoals are to enhance education, attaining them has required a significant Xeffort to engineer a software system for use in such an environment. X.PP XThe Athena hardware environment currently consists of approximately 650 Xworkstations and 65 dedicated server machines. There are two kinds of Xworkstations: DEC MicroVAX systems and IBM RT PC's. The servers are VAX X11/750's or dedicated workstations of either type. The operating system in Xuse now is 4.3BSD X.UX Xon the VAX machines, and IBM's 4.3/RT X.UX Xfor the RT PC systems. All systems include support for Sun Microsystem's XNetwork File System (NFS). X.[ XNFSUsenix X.] XThe workstations and servers are connected to local-area XEthernet subnetworks, which are linked by a high-speed fiber optic X``spine.'' At present, there are twelve such subnetworks at M.I.T. X.PP XThe problems of a distributed system are the scale of the Xoperation and the role of the network as a fundamental component. X.UX Xsystems have Xtraditionally been managed on a ``one system, one wizard'' basis, but this is Xnot acceptable at an eventual scale of 1000 workstations, 100 server Xmachines, and 10,000 users. XTwo questions often asked are: ``Does it scale?'' and ``Is it well-behaved on Xthe network?'' All too often, the answer to one or the other is ``No,'' and Xpart of the system must be reworked to satisfy those constraints. X.PP XThis paper describes the goals and constraints faced by Athena, as well as Xmany of the solutions devised in building such a system. In particular, the Xnext two sections examine the goals and evolution of the computing system Xside of the Project. Next is a discussion of the base operating systems in Xuse, such as 4.3BSD. This is followed by a description of the constraints of Xscale and the network, as well as some of the solutions bounded by those Xconstraints. Finally, system configuration issues and future directions for Xenlarging the workstation base are discused. X.NH XGoals X.PP XThe following are four important goals for engineering a Project Athena Xworkstations. X.PP X\fBThe system Xmust provide a coherent environment across heterogeneous hardware.\fP XWhen Project Athena was created, ``coherence'' was identified as an important Xcharacteristic of a successful workstation environment. Briefly, X``coherence'' means that the environment seen by users on different Xworkstations should be as similar as possible. To a first approximation, Xthis is achieved by using Berkeley X.UX Xsystems on all workstations. X.PP X\fBIt must provide rich computing environment for the Athena user community.\fP XTo make a workstation optimal for educational use at M.I.T., a rich software Xenvironment must be available. If, for example, the software is not useful Xfor building tools for teaching a thermodynamics class, that class will not Xuse Athena workstations. Many third-party software packages, including an Xeditor, text formatter, and spreadsheet, have been added to the standard X.UX Xsystem for this reason. X.PP X\fBIt must scale to 1000 machines such that the Athena Operations staff can Xmanage them.\fP XThe entire network of workstations must also be manageable. The Athena XOperations staff is not large, but it is currently responsible for over 700 Xmachines. Hence, a solution to a problem that requires any resources in Xproportion to the number of machines (e.g., having to visit each Xworkstation) is prohibitively expensive. Wherever possible, operations tasks Xshould be automated; otherwise, they should at least be performed centrally. X.PP X\fBIt must behave well on the network.\fP XAthena workstations must also be ``good neighbors'' on the network; Xthey should not generate problems for other systems on the network, such as Xby gratuitously consuming network bandwidth. X.NH XEvolution of Project Athena X.PP XAt the time of Project Athena's inception in 1983, workstations as defined Xhere were still Xin the design phase. In the beginning, then, Athena used off-the-shelf Xhardware and software. Approximately 50 DEC VAX 11/750 systems were Xdeployed as traditional timesharing systems running Berkeley X.UX X(4.2BSD, later 4.3), and over 100 IBM PC/AT's Xrunning PC-DOS were deployed as networked single-user Xmachines. Using both systems yielded much information about managing and Xengineering networked X.UX Xsystems and single-user machines. X.PP XWorkstations became available to Athena staff in late 1985. At Xthat time, Athena attempted to apply the lessons learned from running Xtimesharing systems to distributed workstation systems, as well as Xto develop solutions to the new problems posed by workstations. Much of the Xdesign work was done ``on the fly'' in order to make usable workstations Xavailable to staff, and eventually to users, as quickly as possible. X.PP XThe first student workstation clusters, running a prototype system, Xwere opened for use in the fall of X1986. Since then, the number of workstations available has steadily Xincreased. During the 1986-87 academic year, both timesharing and Xworkstation systems were in use. Over the summer of 1987, the Project Xshifted almost entirely to the workstation environment, with only a few Xtimesharing systems in use for classes with specific requirements X(e.g., those using a non-networked database system). The majority of Xthe timesharing systems were converted to NFS file servers, primarily for Xstudent ``lockers,'' or file storage areas. X.NH XHardware X.PP XThe typical Athena workstation is roughly a ``3M'' machine; that is, it has Xa 1 million-instructions-per-second processor, a megapixel (1000 x 1000) Xdisplay, and three or four megabytes of memory. It also has a mouse, a Xlocal disk (typically 30 - 70 megabytes), and an Ethernet network interface. XActual hardware in use includes DEC VAXstation II and VAXstation 2000 Xsystems, and IBM RT PC desktop models. Various other configurations of XMicroVAX and RT PC systems are used for development and as dedicated Xservers. X.PP XThe heterogeneous hardware base has imposed certain constraints on XAthena software. For example, the VAX and the RT PC architectures use Xdifferent byte orders to represent integers. Hence, if data is to be Xexchanged between the two architectures, the software must be prepared to Xhandle this difference. This is true both of network protocols and of files Xused for data storage, since such files may be transferred between machines. XSome software, such as NFS, already obey this constraint; all new software Xmust also obey it. X.PP XThe hardware differences also make the goal of coherence difficult to reach. XFor example, the compilers available on the two machines are somewhat Xdifferent. While the differences are minor, they can be most annoying. XSince the same source code is used on both machines whenever possible, the Xstandard source pool has been partitioned into sections of Xmachine-independent and machine-dependent sources to simplify the system Xbuild process. The compilers, for Xexample, are machine-dependent; a text editor such as \fI/bin/ed\fP is not. X.PP XOf course, hardware from other vendors meets the specifications for the Xbasic Athena workstation. In the future, the ``Athena Environment'' will be Xproduced as a layer on top of vendor-supplied systems that meet certain Xfundamental requirements. X.NH XBase Software Systems X.PP XThe basic software used on all Athena workstations at this time is 4.3BSD X.UX Xwith machine-dependent software supplied by the hardware vendors. All Xsystems include NFS client support and use the X Window System. X.[ XXACM X.] XThe standard Berkeley distribution is augmented by several third-party software Xpackages and local Athena modifications and additions. X.PP X\fBRT PC System.\fP XThe RT PC kernel is taken from 4.3/RT. NFS support Xhas recently been integrated into that kernel at Athena. The necessary Xmachine-dependent utilities (e.g., the C compiler) were also drawn from Xthe 4.3/RT system. X.PP X\fBVAX System.\fP XThe basic VAX system is 4.3+NFS from the University of Wisconsin. Some Xdevice drivers from Digital's Ultrix-32 have been added to handle some of Xthe hardware in use at Athena. X.NH XConstraints of Coherence. X.PP XProviding a coherent environment across different types of workstations Ximposes several constraints on constructing the system, including the Xfollowing. X.PP X\fBThe same basic system must be available on all platforms and must evolve in Xsynchrony.\fP XTo promote both uniformity and maintainability, all software is Xperiodically built from the source code. This ensures that all changes to Xheader files, libraries, etc., are actually reflected in the running Xsystem. Maintaining and building sources for two different Xarchitectures turns out to be no small task. XUnfortunately, \fImake\fP and \fIrdist\fP Xalone are not sufficient to maintain source code on multiple architectures, Xespecially when some changes (e.g., kernel modifications) must be made Xto code that is similar but not identical. New tools to automate this Xprocedure are under development. X.PP X\fBData must be interchangeable between the systems.\fP XSince different machines may use different internal data formats, Xapplications must be prepared to cope with such variations. This is Xparticularly true of network services, since services may be available from Xservers with Xdifferent architectures. Fortunately, this constraint is not difficult to Xobserve, \fIprovided it is anticipated\fP. X.NH XConstraints of Scale X.PP XScale is one of the driving considerations in building the XAthena system. Unfortunately, not all constraints of scale are obvious at Xfirst glance (or even the second or third). Some of the specific Xconstraints of a large scale system include the following. X.PP X\fBResources cannot be expended in proportion to the number of workstations.\fP XThis may seem obvious, but it is a constant problem. Athena Operations, for Xexample, does not have resources that grow in proportion to the number of Xworkstations installed. The only way to support those workstations is to Xmake operational tasks more efficient. X.PP X\fBDifferences in software, including configuration files, must be Xminimized.\fP XOne way to minimize operational tasks is to minimize the differences between Xworkstations. There are more than twenty different configuration files in a Xstandard 4.3 system. Workstation systems are much easier to manage when most Xof these are identical from workstation to workstation. On Athena public Xworkstations, all configuration files are identical except for X\fI/etc/rc.conf\fP, which contains the hostname and network address. XOperators can be Xtrained to understand two or three configurations, but expecting them to Xunderstand the subtleties of 1000 is too much. If configuration files are Xidentical, an operator can simply look at the configuration file that seems Xto be incorrect, realize that it is not standard, and copy the correct Xversion from a standard source. X.PP XThere are, of course, some small exceptions to this rule. In particular, a Xworkstation must be able to find the nameservers in the first place. At Xthis time, a list of nameservers is maintained on the workstation's local Xdisk. In the future, this should not be necessary (see ``Future Plans''). X.PP X\fBNetwork services must be redundant to tolerate network and server Xfailures.\fP XIf a central name or authentication service is not available, the world will Xgrind to a halt. Providing redundant servers minimizes the probability Xof a given service being unavailable, as well as distributing the load over Xseveral different servers when all is well. In contrast, it is not always Xpossible, nor is it necessary, to provide redundant servers for modifying Xcentral database information that is later distributed to appropriate Xservers (e.g., the central nameserver database). As a corollary to Xthis, critical network services should also rebound quickly after system Xcrashes or power failures. X.PP X\fBA centrally-managed name service should provide information for finding Xnetwork services.\fP XSuppose the FOO service is provided by machine HERA.MIT.EDU. If this Xservice moves to ZEUS.MIT.EDU, it should not be necessary to update Xconfiguration files on 1000 workstations. Indeed, experience has shown that Xthere would be workstations with the wrong information months after the Xchange takes place. A name service provides a much easier way to manage Xthis problem. X.PP X\fBSoftware installation must be quick and painless.\fP XInstalling new software on a workstation Xshould not take much time, nor should it require Xmany props. Since workstation systems at Athena are installed to a standard Xform, the installer need perform very little customization; the rest of the Xprocedure is automatic. In fact, for most workstations, only the hostname Xis different. X.PP X\fBSoftware update must be quick and painless. Automatic update is even Xbetter, if it works correctly.\fP XIn an ideal world, software update would be completely automatic. In an Xautomatic update, a workstation compares its software to a central library Xand makes any necessary changes. Some software must be updated with great Xcare, however. For example, a new kernel requires that the workstation be Xrebooted, and often requires that various kernel-dependent utilities, such Xas \fIps\fP, be updated at the same time. The tools for doing this are not Xyet entirely reliable. X.PP X\fBConfiguring servers must be quick, painless, and reproducible.\fP XService machines (e.g., printer servers) are implemented as a set of Xdifferences from a basic workstation system. Converting a standard Xworkstation to a server is then a straightforward Xprocess. This allows a vanilla Xmachine to be ``swapped in'' quickly for a server should hardware problems Xarise. It also simplifies updating servers with the latest software Xrelease. X.PP X\fBSecurity must not depend on superuser access.\fP XIn a large environment such as Athena's, the root password to workstations Xcannot be different on each machine. Indeed, with the workstation Xphysically available to a user, it is not necessary to know the root Xpassword; booting the machine in single-user mode is sufficient to gain root Xaccess. A user may therefore easily modify the software local to the Xworkstation, and network services must not blindly trust root users from Xworkstations. X.PP X\fBNetwork services must be managed centrally.\fP XTrying to manage a large number of network services can become quite Xdifficult. When only 10 or 100 workstations are involved, it may be possible Xto manage services on one or two machines, a job that can be done by hand. XOn a larger scale, the number of servers must also be considered. To this Xend, Athena has designed the Service Management System (SMS), X.[ XSMSUsenix X.] Xwhich consists Xof a central database of service information, tools for manipulating that Xinformation, and tools for extracting appropriate information for the Xservices themselves. A particular advantage of maintaining this database is Xthat it reduces to one the number of different places a given piece of Xinformation must be stored: it is kept once in the database and is provided Xto servers as they need it. X.NH XConstraints of the Network X.PP XWorking in a networked environment also imposes several constraints on the Xoverall system. One of the most important for users is that several services Xavailable on timesharing systems should Xbe available on workstations as well. In Xsome cases, these services behave somewhat differently than in the Xtimesharing world, but functionality is preserved. Some of the services Xinclude the following. X.PP X\fBSystem Libraries.\fP XTimesharing systems have many programs available for a Xuser to execute; most of these are traditionally found in \fI/usr\fP. XWorkstations do not typically have the hundreds of megabytes necessary to Xkeep the complete system library available on a local disk, and it would be Ximpossible to keep the software up to date if they did. To solve this Xproblem, Athena has provided a ``Remote Virtual Disk'' (RVD) service. RVD was Xoriginally developed at M.I.T.'s Laboratory for Computer Science and Xsignificantly enhanced at Project Athena. An RVD ``pack'' appears to a Xworkstation just as a local physical disk device does. An RVD server only Xsupplies requested disk blocks; all filesystem information is manipulated by Xthe client workstation. As a result of this, an RVD pack may be used by Xmany clients in a read-only mode, or by a single client in an exclusive Xread-write mode. Another effect of the block-level service is that a single XVAX 11/750 server can support 75 client workstations with quite acceptable Xperformance. X.PP X\fBName Resolution.\fP XOn a timesharing system, names are often translated to machine-usable data Xby configuration files. For example, \fI/etc/hosts\fP maps machine names to Xnumeric Internet addresses. Another file might contain the name of the XRVD server that provides the system libraries. In a large, dynamic Xenvironment, this reliance on static files causes innumerable problems. To Xmanage changing information, it is necessary to have a service that provides Xname translation. Athena undertook some minor extensions to the BIND X.[ XBind X.] Xnameserver package from 4.3BSD to provide generalized name service; the Xresulting software is known as \fIHesiod\fP. X.[ XHUsenix X.] X\fIHesiod\fP provides information on users, locations of Xuser lockers, locations for various network services, etc. Changes in the X\fIHesiod\fP database, which is generated by the Service Management System, are Xavailable to all workstations within a few hours (the delay is caused by Xtime to propagate to the Hesiod servers and by internal nameserver caches of Xthe BIND implementation). X.PP X\fBAuthentication Service.\fP X.UX Xsystems have traditionally stored encrypted passwords in X\fI/etc/passwd\fP on each machine. It is quite difficult to maintain Xpassword and group files on 50 timesharing machines and completely Ximpractical to provide complete password and group files for each machine in Xa large network, so an alternative authentication system is required. XAthena has implemented a system known as \fIKerberos\fP X.[ XKUsenix X.] Xto handle authentication for network services, including workstation login. X.PP X\fBFile Service.\fP XA user's files should be available for use on any workstation. At Athena, Xeach user has a ``locker'' for personal storage. User lockers are distributed Xacross many file servers, but the appearance to the user is that the home Xdirectory is as expected, and it is the current directory at login, Xjust as on a timesharing system. One difference Xis that other users' home directories are not immediately available but must Xexplicitly attached to the workstation's directory hierarchy. The net Xeffect, however, is positive: in the earlier days of Athena timesharing, a Xuser could not gain access another's files if they were on a different machine. XSecurity and privacy considerations are observed, however, and the usual X.UX Xprotections are enforced. X.PP X\fBPrinting.\fP XTypical timesharing systems have printers available locally. XThe environment assumed for 4.3BSD makes some attempt to provide networked Xprinting facilities, but the \fIlpr\fP system is still difficult to manage. XTwo of its major problems are local queuing and local configuration. XNormally, \fIlpr\fP drops a print request in a queue on the local machine, Xand a line printer daemon either prints it or queues it to a remote machine, Xas specified in \fI/etc/printcap\fP. \fIlpr\fP gives the user no indication Xwhether or not the machine physically connected to the printer Xis actually up and Xaccepting requests. In the Athena workstation world, this can cause a file Xto be left in a local queue on a workstation, with no guarantee that it will Xever be printed. To circumvent this problem, \fIlpr\fP has been modified to Xqueue directly to the remote printer server. If it is not available, the user Xreceives an immediate error and may try to find another printer to use. X.PP XThe second problem is \fI/etc/printcap\fP itself. As a static configuration Xfile, the copy on every workstation must be updated Xwhen a new printer is added or an old one moved. X\fIlpr\fP has been modified to query \fIHesiod\fP for information about Xprinters Xin order to find a printer server. Printer servers themselves behave more Xtraditionally; they use a local \fI/etc/printcap\fP for detailed information Xabout their own printers. X.PP X\fBElectronic Mail.\fP XTimesharing systems provide a convenient maildrop for users. The Xaddress is typically \fIuser@machine\fP, and local users can be addressed Xsimply as \fIuser\fP. Where, then, should mail be kept for a user who might Xlogin on workstation ABC one day and workstation XYZ the next, especially Xwhen none of the workstations has sufficient local disk space to store mail? XAthena has adopted the concept of a ``post office,'' which holds mail for a Xuser until he picks it up. The Post Office Protocol X.[ XPop X.] Xsoftware supplied with the MH mail system X.[ XMhuser X.] Xhas been Xmodified for use with \fIKerberos\fP, and the retrieval software finds the mailbox Xusing \fIHesiod\fP. The changes are transparent, so Xthe user simply uses the same Xcommands as he did on the timesharing system, without having to worry about Xthe details. At this Xtime, Athena has three post offices in use, serving approximately 8000 Xusers. X.PP XSending mail to Athena users is also straightforward. The address is simply X\fIuser\fP within Athena, or \fIuser@ATHENA.MIT.EDU\fP from outside. All Xmail is routed by a central mail hub, which uses a master list of users at Xvarious post offices. The list is provided by SMS. This machine also Xhandles distribution to mailing lists within Athena. When a user sends mail Xfrom a workstation, it is queued to the mail hub for forwarding to a post Xoffice, mailing list, or outside machine, as appropriate. Note that X\fIall\fP mail goes to the mail hub; workstations do not try to contact Xforeign machines themselves, nor do they run a \fIsendmail\fP daemon to Xreceive incoming mail. At this time, sending mail does suffer from one of Xthe same problems as \fIlpr\fP: mail is queued locally on Xthe workstation if the mail hub is not responding. In such a case, there Xis no guarantee that it will ever be delivered; the next user may willfully Xor mistakenly delete any mail in the spool directory. X.PP X\fBNotification.\fP XOn a timesharing machine, it is easy to notify a user asynchronously of some Xevent: one need simply find the entry in \fI/etc/utmp\fP, if one exists, and Xsend a message to the appropriate terminal. Where, however, does one find a Xuser Xsomewhere in the forest of 1000 workstations? And where does one deliver a Xmessage in a thicket of windows? To solve this problem, Athena has developed Xa notification system known as \fIZephyr\fP, X.[ XZUsenix X.] Xwhich can be used both to locate users and Xto send messages to them. One simple example is the command \fIzwrite Xtreese\fP, which will deliver a message to user \fItreese\fP on his Xworkstation if he is logged Xin somewhere on the Athena network (within constraints of permission and Xprivacy, of course). X.PP X\fBRemote Access.\fP XAn Athena workstation is designed to be a single-user machine, if for no Xother reason than that it is easy to gain root access on one. By default, XAthena workstations do not permit remote logins, remote shells, or remote Xfile access, since that may harm the current user of the workstation X(i.e., the one logged in on the console). A user can defeat this Xprotection and allow access to a workstation during a session if desired. XThe major disadvantage of this restriction is that operations Xpersonnel cannot remotely login to repair problems; experience has shown Xthat this is an acceptable limitation. X.PP X\fBOn-Line Consulting.\fP XOn a X.UX Xtimesharing system, one can usually find the system manager or other Xknowledgeable user when one runs into problems. Finding assistance is much Xmore difficult when there are 5000 active users of the system, with the XAthena staff system wizards somewhere on the other side of the campus. To Xsolve this Xproblem, Athena implemented an ``On-Line Consulting System'' (OLC) that Xcan be used to ask questions of consultants and other knowledgeable users Xlogged in Xelsewhere one the network. Questions are saved until a consultant becomes Xavailable, and answers are often returned by electronic mail if the question Xremains unresolved when the user logs out. X.PP X\fBNetwork Etiquette.\fP XAthena workstations must be good neighbors on the network. Services that Xrequire the use of Ethernet broadcast packets are almost always unacceptable Xby that measure. They raise two problems: first, the broadcasts are limited Xto the local net (as a matter of policy) and can therefore reach only a small Xfraction of the workstations. Second, they tend to generate a great deal of Xnetwork traffic when many machines are involved, consuming valuable network Xbandwidth and local processing cycles. One example is the X\fIrwho/ruptime\fP software from 4.3BSD; handling the packets from nearly a Xhundred workstations on the same local net seriously affected workstation Xperformance in the early days of workstation use at Athena. Athena machines Xno longer run that software. X.NH XConfiguration Changes X.PP XIn satisfying these constraints, Athena has made several changes to the Xstandard X.UX Xconfiguration for use on workstations. These fall into Xfour categories: changes to the directory hierarchy, introduction of X``activated'' and ``deactivated'' states for a workstation, modification of the Xlogin procedure, and changes to configuration files. Strictly speaking, Xmany of these changes are not necessary for the public workstations most Xcommon at Athena, but are included for use on non-public machines, such as Xthose in the offices of M.I.T. faculty members. X.PP X\fBDirectory structure.\fP XMost of the changes in the directory structure are in \fI/usr\fP. Because Xsome standard subdirectories are used for executable programs and some for Xspooling and administration, \fI/usr\fP on an Athena workstation actually Xcontains a set of symbolic links. Directories such as \fIadm, spool\fP, and X\fIcrash\fP are stored on the local disk on \fI/site\fP; other directories Xare actually subdirectories of \fI/urvd\fP, a read-only RVD system Xlibrary mounted at activation. X.PP XOver time, the root filesystem has also outgrown its original size. To avoid Xreconfiguring all machines with a larger filesystem, many programs in X\fI/etc\fP or \fI/bin\fP are actually symbolic links to a second RVD system Xlibrary, mounted on \fI/srvd\fP. These programs are those which are not Xessential for a workstation during its boot procedure or for repairing a Xworkstation in single-user mode. For example, the C compiler and the Xassembler fall into this category. The \fI/srvd\fP system library also has Xthe latest versions of programs that should reside on the root; it is used Xas a reference both for installing and for updating workstations. X.PP X\fBActivating a Workstation.\fP XAs with all systems, it is occasionally necessary to update the software Xavailable on a workstation. One limitation of read-only file service such as Xthe RVD system is that this cannot be done while a workstation has attached Xthe system libraries. Of course, it is possible to make the new libraries Xavailable and wait until all of the workstations have booted again to start Xusing Xthem. This solution takes too long to work probabilistically and so implies a Xvisit to each workstation to boot it. This, too, is unacceptable. X.PP XTherefore, when not in use, an Athena workstation is in a ``deactivated'' Xstate. No Xsystem libraries are attached and the window system is not running. In Xplace of a \fIgetty\fP on the console, a program known as \fItoehold\fP Xwaits for a keypress from a user who wishes to login. \fIToehold\fP then Xexecutes a shell script that attaches the system libraries. If this Xsucceeds, \fItoehold\fP starts the X Window System, and a login window Xappears for the user. X.PP XAfter a user logs out, \fItoehold\fP ``deactivates'' the workstation. This Xincludes detaching any attached filesystems, including the system libraries Xand filesystems that the user may have attached during his session, ensuring Xthat remote access is impossible, cleaning the temporary storage areas X(e.g., \fI/tmp\fP), and killing the window system. X.PP X\fIToehold\fP also has an alternate entry: typing control-P (^P) on the Xconsole allows one to login directly on the console without activating the Xworkstation. This is particularly useful for repairing a workstation that Xis not working properly. X.PP X\fBLogging In.\fP XThe login process is considerably more complicated now. X\fI/bin/login\fP now includes the following functions: X.PP X1. It authenticates the user with \fIKerberos\fP. To limit access on Xcertain workstations, if the file X\fI/etc/nocreate\fP exists, an account is not automatically created; the Xuser must already be listed in \fI/etc/passwd\fP. X.PP X2. It adds entries for the user to \fI/etc/passwd\fP and \fI/etc/group\fP, Xusing information from \fIHesiod\fP. This makes the information available Xto programs that require it for the duration of the session. X.PP X3. It attaches the user's home directory on \fI/mit/\fP. If Xthe directory is unavailable for some reason (e.g., the appropriate NFS Xserver is down), a temporary home directory is created for the user in X\fI/tmp\fP. In this case, the user is notified of the situation and may Xchoose to abort the login. If the file \fI/etc/noattach\fP exists, the home Xdirectory is not automatically attached, and a local home directory is Xassumed to exist. X.PP X\fI/bin/login\fP then continues with the normal execution of the shell. XNote that it does no longer simply \fIexec()\fP the shell; it forks before Xexecuting the shell so it can perform some cleanup operations when the user Xlogs out. The cleanup includes deletion of \fIKerberos\fP information and detaching Xthe user's home directory. X.PP XAs part of the login process, a \fIZephyr\fP windowgram client is Xstarted and the \fIZephyr\fP server informed of the login. X.PP X\fBConfiguration Files.\fP XMany X.UX Xconfiguration files have been heavily modified for workstation Xuse; some of the most important are described here. X.PP X\fIBoot-Time Configuration.\fP XAs usual, the script \fI/etc/rc\fP is executed when a workstation boots. XThe \fIrc\fP script on Athena workstations, however, has been extensively Xreworked to provide a great deal of flexibility. There are actually four Xfiles involved: \fIrc, rc.conf, rc.net\fP, and \fIrc.local\fP. X.PP X\fI/etc/rc\fP does most of the work, and it calls each of the other three as Xrequired. It first performs disk checks and resets the password file Xappropriately. It then calls \fIrc.conf\fP to obtain configuration Xinformation for the workstation and \fIrc.net\fP to initialize the network Xsubsystem. Next, it spawns various daemons and further cleans up from the Xlast session, including flushing all connections to file servers (both RVD Xand NFS). Finally, it calls \fIrc.local\fP for any workstation-specific Xtasks. X.PP X\fIrc.conf\fP sets a number of configuration variables for the workstation, Xincluding its hostname and network address. These are used to determine Xwhich daemons should be run, what configuration should be done, etc. XThis defines the supported set Xof differences between workstations and servers, and confines their Xspecification to a single file. X.PP X\fIrc.net\fP performs network initialization, including configuring network Xinterfaces, setting default routes, and starting the local nameserver. XThese functions are isolated in a single file to simplify starting the Xnetwork in single-user mode; trying to repair a workstation often requires Xuse of some service on the network. A program named \fImachtype\fP is used Xto determine the type of the machine so a single version of the file Xcan be used on all Athena machines. X.PP X\fIrc.local\fP is reserved for local configuration on non-public machines; Xstandard server configurations are handled by \fI/etc/rc\fP itself. X.PP X\fINameserver Configuration.\fP XBecause of the \fIHesiod\fP extensions to \fI/etc/named\fP, an additional standard Xconfiguration file has been added: \fI/etc/named.hes\fP. It contains the Xnames and addresses of the \fIHesiod\fP servers. (Note: the addresses of \fIHesiod\fP Xservers are included because some software attempts to resolve names with a Xclass ANY query. If the addresses are not present, this will result in a Xresponse that does not include the address, and the desired host cannot be Xcontacted.) For local priming of the nameserver cache, the file X\fI/etc/named.local\fP is available. On public workstations it is empty. X.PP X\fISendmail Configuration.\fP XThe files \fIaliases, aliases.dir, aliases.pag, Xsendmail.cf\fP, and \fIsendmail.fc\fP in \fI/usr/lib\fP are actually Xsymbolic links into \fI/site/usr/lib\fP to allow local configuration Xchanges. On Xpublic workstations, the aliases files are empty, and the \fIsendmail.cf\fP Xfile is a standard Athena version. \fISendmail.cf\fP is configured only to Xsend mail, Xnot to receive it. In addition, it rewrites ``from'' addresses to be from X\fIuser@ATHENA.MIT.EDU\fP and rewrites unqualified usernames to be to X\fIuser@ATHENA.MIT.EDU\fP. \fISendmail\fP does not run as a daemon on XAthena workstations; it is started on demand to send mail and Xperiodically by \fIcron\fP to attempt to send any queued mail. X.PP X\fI/etc/passwd and /etc/group.\fP XThese files are updated at login time from information supplied by \fIHesiod\fP. XWhen a workstation deactivates, \fI/etc/passwd.local\fP and X\fI/etc/group.local\fP are copied over these files, undoing any Xchanges. Public workstations also initialize these files from \fI/srvd\fP Xat boot time to prohibit other changes. X.NH XFuture Plans X.PP XImplementation of the workstation environment at Project Athena is not yet Xfinished. Some known areas of work include the following topics. X.PP X\fBNetwork Error Logging.\fP XAs the number of workstations and servers grows, it becomes more and more Xdifficult to monitor what is happening. By logging error messages and Xstatus information across the network to a central machine, it may be Xpossible to detect abnormal situations before major failures occur. The Xsheer scale of the system also tends to generate several occurrences of Xlow-probability errors; monitoring them from a central location can help in Xunderstanding and solving the problem. Automatic filtering tools will be Xneeded to cope with the volume of messages. X.PP X\fBAutomatic Software Update and Integrity Check.\fP XAs noted above, updating workstation software is a major undertaking, since Xit currently requires a visit to each workstation. It is necessary to Xdevelop a reliable means to automatically update software on a workstation. XReliability is the key issue; a software update should not leave a Xtrail of broken workstations. Part of this effort is a software integrity Xcheck system that verifies that the configuration and software are correct. X.PP X\fBShift to Vendor Software Base.\fP XAs DEC and IBM produce new hardware, it will become more and more necessary Xfor Athena Xto work with the vendors' software as well. This is driven partly by device Xsupport, and partly by the fact that their diverging systems make it harder Xto build software Xfrom nearly identical source code across different platforms. New Xapplications also require some of the new functionality of the vendor versions. XTo this end, the Athena developments (e.g., \fIKerberos\fP) must either be Xabsorbed by the vendors or engineered as a layer above the vendor Xsystems. As a side effect, this engineering will enable non-Athena sites to Ximport Athena software easily. X.PP X\fBDynamic Configuration.\fP XOne last consequence of scale is that the configuration of a workstation Xshould be as dynamic as possible. The names and addresses of nameservers, Xfor example, should not be wired into a configuration file on the Xworkstation; they should be available from a server on the local network Xwhen a machine boots. This is one exception to the use of broadcast packets Xabove; a workstation may be permitted to broadcast an initial request for Xinformation. X.PP XIn a similar vein, the Internet address of a workstation could be assigned Xdynamically. Already one of the most common and most annoying problems that XAthena faces is the misconfigured network address. Experiments Xwith assigning the address at boot time are already underway. One immediate Xapplication of this is for student-owned workstations: if a student moves Xa workstation to Xa different dormitory with a different subnetwork, the workstation requires Xa different address. The average student, however, cannot be expected to Xunderstand how to change the address or how to get a new address assigned Xby M.I.T. Telecommunications. Maintaining correct workstation name-to-address Xmappings in a dynamic environment would become much more difficult; the Xmanagement issues need to be resolved as well. X.PP X\fBScale to 10,000 workstations/1000 servers.\fP XAthena's work at M.I.T. has generated a demand for the workstation Xenvironment to be used elsewhere on campus. This, coupled with one of Athena's Xoriginal goals to eventually provide a workstation system for students to Xown, means that the next few years will see a dramatic increase in the Xnumber of workstations in use (and the number of servers required to support Xthem). Scaling up another order of magnitude will require further work as Xwe reach the limits of the work done so far. As one example, a \fIHesiod\fP Xnameserver currently has an in-core image of over ten megabytes, stretching Xthe limits of our current system configuration. This problem, of course, Xhas a straightforward solution, but it indicates that solutions suitable for Xthe current scale may be insufficient for the next stage. X.NH XConclusion X.PP XThe Athena environment represents a first step in re-engineering X.UX Xfor a Xdistributed workstation system. As large networks become more common, the Xissues of scale and management will become more and more important. One Xwizard must suffice for perhaps a thousand workstations. X.NH XAcknowledgements X.PP XThe author would like to thank Dan Geer, Kathy Lieben, Jerry Saltzer, Mark XLevine, Xand Jennifer Steiner for valuable comments on earlier drafts of this paper. XThanks also to the staff and users of Project Athena, who have supported Xand endured the construction of this system. X.NH XReferences X.[ X$LIST$ X.] SHAR_EOF if test 39605 -ne "`wc -c < 'changes'`" then echo shar: "error transmitting 'changes'" '(should have been 39605 characters)' fi fi exit 0 # End of shell archive ------- Message 5 List of trademarks, copyrights, etc., used in the 6 Athena papers. I trust all are recognizable. - --dan UNIX 4.3 BSD ndbm Network File System NFS X Window System X Windows Hesiod Kerberos Zephyr SMS RVD Ingres Post Office Protocol MH POP IBM PC/AT RT/PC ACIS PC/DOS DEC MicroVAX II VAXstation II VAXstation 2000 VAX Ultrix Ultrix 2.0 ------- Message 6 the following is the athena refer file. - --dan #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create: # usenix.refer # usenix.refer.ig # This archive created: Mon Jan 4 21:50:21 1988 export PATH; PATH=/bin:/usr/bin:$PATH echo shar: "extracting 'usenix.refer'" '(4957 characters)' if test -f 'usenix.refer' then echo shar: "will not over-write existing file 'usenix.refer'" else sed 's/^ X//' << \SHAR_EOF > 'usenix.refer' X%K ACMNeedham X%A R. M. Needham X%A M. D. Schroeder X%T Using Encryption for Authentication in Large Networks of Computers X%J Communications of the ACM X%V 21 X%N 12 X%P 993-999 X%D December, 1978 X X%K KTech X%K Miller X%A S. P. Miller X%A B. C. Neuman X%A J. I. Schiller X%A J. H. Saltzer X%T Section E.2.1: Kerberos Authentication and Authorization System X%I M.I.T. Project Athena X%C Cambridge, Massachusetts X%S Project Athena Technical Plan X%E J. H. Saltzer X%D December 21, 1987 X X%K KProgrammer X%A W. J. Bryant X%T Kerberos Programmer's Tutorial X%I M.I.T. Project Athena X%D In preparation X X%K KAdministrator X%A W. J. Bryant X%I M.I.T. Project Athena X%T Kerberos Administrator's Manual X%D In preparation X X%K DESNBS X%A National Bureau of Standards X%D 1977 X%T Data Encryption Standard X%R Federal Information Processing Standards Publication 46 X%I Government Printing Office X%C Washington, D.C. X X%K DECBurrows X%A M. Burrows X%A M. Abadi X%A R. Needham X%T Authentication: A Practical Study in Belief and Action X%I D.E.C. Systems Research Center X%D In preparation X X%K XTKIntrinsics X%T X Toolkit Intrinsics X%I M.I.T. Software Distribution Center X%D September, 1987 X X%K XProtocol X%T X Window System Protocol X%I M.I.T. Software Distribution Center X%D September, 1987 X X%K Xlib11 X%A J. Gettys X%A R. Newman X%A R. W. Scheifler X%T Xlib - C Language Interface X X%K Xtk X%A R. Rao X%A S. Wallace X%T The X Toolkit X%C D.E.C. Western Software Laboratory X%B Usenix Conference Proceedings X%D Summer, 1987 X X%K KUsenix X%T Kerberos: An Authentication Service for Open Network Systems X%A J. G. Steiner X%A B. C. Neuman X%A J. I. Schiller X%B Usenix Conference Proceedings X%D Winter, 1988 X X%K HUsenix X%T Hesiod X%A S. P. Dyer X%B Usenix Conference Proceedings X%D Winter, 1988 X X%K ZUsenix X%T The Zephyr Notification System X%A C. A. DellaFera X%A M. W. Eichin X%A R. S. French X%A D. C. Jedlinsky X%A J. T. Kohl X%A W. E. Sommerfeld X%B Usenix Conference Proceedings X%D Winter, 1988 X X%K SMSUsenix X%A M. A. Rosenstein X%A D. E. Geer X%A P. J. Levine X%B Usenix Conference Proceedings X%D Winter, 1988 X X%K AthChanges X%T Berkeley Unix on 1000 Workstations: Athena Changes to 4.3BSD X%A G. W. Treese X%B Usenix Conference Proceedings X%D Winter, 1988 X X%K POP X%A M. T. Rose X%T Post Office Protocol (revised) X%I University of Delaware X%O (MH internal) X%D 1985 X X%K MHUser X%T The Rand Message Handling System: User's Manual X%I U.C.I. Dept. of Information & Computer Science X%C Irvine, California X%A Rand Corp. X%D November, 1985 X X%K RVD X%T Remote Virtual Disk Protocol X%A M. Greenwald X%I M.I.T. Laboratory for Computer Science X%D 1985 X X%K NFSUsenix X%A R. Sandberg X%A D. Goldberg X%A S. Kleiman X%A D. Walsh X%A B. Lyon X%T Design and Implementation of the Sun Network Filesystem X%B Usenix Conference Proceedings X%D Summer, 1985 X X%K SUNNFS X%T NFS Protocol Specification and Services Manual X%A Sun Microsystems X%O Revision A X%D 1987 X X%K RTIngres X%T Ingres Reference Manual X%O Release 5.0, Unix X%A Relational Technology, Inc. X%D 1986 X X%K GDB X%T A Guide to Using GDB X%A N. Mendelsohn X%I M.I.T. Project Athena X%D 1987 X%O Version 0.1 X X%K XACM X%K Scheifler X%A R. W. Scheifler X%A J. Gettys X%T The X Window System X%J ACM Transactions On Graphics X%V 5 X%N 2 X%P 79-109 X%D April, 1987 X X%K ZTech X%K DellaFera X%A C. A. DellaFera X%A M. W. Eichin X%A R. S. French X%A D. C. Jedlinsky X%A J. T. Kohl X%A W. E. Sommerfeld X%T Section E.4.1: Zephyr Notification Service X%C Cambridge, Massachusetts X%S Project Athena Technical Plan X%E J. H. Saltzer X%I M.I.T. Project Athena X%D December 21, 1987 X X%K SMSTech X%A P. J. Levine X%A M. R. Gretzinger X%A J. M. Diaz X%A W. E. Sommerfeld X%A K. Raeburn X%T Section E.1: Service Management System X%S Project Athena Technical Plan X%E J. H. Saltzer X%I M.I.T. Project Athena X%C Cambridge, Massachusetts X%D 1987 X X%K HTech X%A S. P. Dyer X%A F. S. Hsu X%T Section E.2.3: Hesiod Name Service X%S Project Athena Technical Plan X%E J. H. Saltzer X%I M.I.T. Project Athena X%C Cambridge, Massachusetts X%D 1987 X X%K SunYP X%A Sun Microsystems X%T Yellow Pages Protocol Specification X%S Networking on the Sun Workstation X%D 1986 X X%K Xerox X%T Clearinghouse Protocol X%D April, 1984 X%A Xerox Corporation X%C Stamford, Connecticut X X%K Mock1 X%T RFC 1034 - Domain Names - Concepts and Facilities X%A P. Mockapetris X%I USC/Information Sciences Institute X%D November, 1987 X X%K Mock2 X%T RFC 1035 - Domain Implementation and Specification X%A P. Mockapetris X%I USC/Information Sciences Institute X%D November, 1987 X X%K BINDImplement X%T Experiences Implementing BIND X%T A Distributed Name Server for the DARPA Internet X%A J. M. Bloom X%A K. J. Dunlap X%P 172-181 X%B Usenix Conference Proceedings X%D Summer, 1986 X X%K SecMech X%T Security Mechanisms in High-Level Network Protocols X%A V. L. Voydock X%A S. T. Kent X%J Computing Surveys X%V 15 X%N 2 X%D June 1983 X%I ACM X X%K ACMAthena X%T Computing in Higher Education: The Athena Experience X%A E. Balkovich X%A S. R. Lerman X%A R. P. Parmelee X%J Communications of the ACM X%V 28 X%N 11 X%D November, 1985 X%P 1214-1224 X%I ACM SHAR_EOF if test 4957 -ne "`wc -c < 'usenix.refer'`" then echo shar: "error transmitting 'usenix.refer'" '(should have been 4957 characters)' fi fi echo shar: "extracting 'usenix.refer.ig'" '(3432 characters)' if test -f 'usenix.refer.ig' then echo shar: "will not over-write existing file 'usenix.refer.ig'" else sed 's/^ X//' << \SHAR_EOF > 'usenix.refer.ig' Xusenix.refer:0,191 acmnee needha schroe using encryp authen large networ comput commun acm decemb 1978 Xusenix.refer:191,278 ktech miller miller neuman schill saltze sectio kerber authen author system projec athena cambri massac projec athena techni plan saltze decemb 1987 Xusenix.refer:469,109 kprogr bryant kerber progra tutori projec athena prepar Xusenix.refer:578,113 kadmin bryant projec athena kerber admini manual prepar Xusenix.refer:691,188 desnbs nation bureau standa 1977 data encryp standa federa inform proces standa public govern printi office washin Xusenix.refer:879,166 decbur burrow abadi needha authen practi study belief action system resear center prepar Xusenix.refer:1045,100 xtkint toolki intrin softwa distri center septem 1987 Xusenix.refer:1145,100 xproto window system protoc softwa distri center septem 1987 Xusenix.refer:1245,87 xlib11 gettys newman scheif xlib langua interf Xusenix.refer:1332,136 xtk rao wallac toolki wester softwa labora usenix confer procee summer 1987 Xusenix.refer:1468,176 kuseni kerber authen servic open networ system steine neuman schill usenix confer procee winter 1988 Xusenix.refer:1644,85 huseni hesiod dyer usenix confer procee winter 1988 Xusenix.refer:1729,199 zuseni zephyr notifi system dellaf eichin french jedlin kohl sommer usenix confer procee winter 1988 Xusenix.refer:1928,113 smsuse rosens geer levine usenix confer procee winter 1988 Xusenix.refer:2041,144 athcha berkel unix workst athena change treese usenix confer procee winter 1988 Xusenix.refer:2185,107 pop rose post office protoc revise univer delawa intern 1985 Xusenix.refer:2292,166 mhuser rand messag handli system user manual dept inform comput scienc irvine califo rand corp novemb 1985 Xusenix.refer:2458,106 rvd remote virtua disk protoc greenw labora comput scienc 1985 Xusenix.refer:2564,189 nfsuse sandbe goldbe kleima walsh lyon design implem sun networ filesy usenix confer procee summer 1985 Xusenix.refer:2753,103 sunnfs nfs protoc specif servic manual sun micros revisi 1987 Xusenix.refer:2856,100 rtingr ingres refere manual releas unix relati techno inc 1986 Xusenix.refer:2956,97 gdb guide using gdb mendel projec athena 1987 versio Xusenix.refer:3053,144 xacm scheif scheif gettys window system acm transa graphi april 1987 Xusenix.refer:3197,297 ztech dellaf dellaf eichin french jedlin kohl sommer sectio zephyr notifi servic cambri massac projec athena techni plan saltze projec athena decemb 1987 Xusenix.refer:3494,249 smstec levine gretzi diaz sommer raebur sectio servic manage system projec athena techni plan saltze projec athena cambri massac 1987 Xusenix.refer:3743,186 htech dyer hsu sectio hesiod name servic projec athena techni plan saltze projec athena cambri massac 1987 Xusenix.refer:3929,114 sunyp sun micros yellow pages protoc specif networ sun workst 1986 Xusenix.refer:4043,97 xerox cleari protoc april 1984 xerox corpor stamfo connec Xusenix.refer:4140,137 mock1 rfc domain names concep facili mockap usc inform scienc instit novemb 1987 Xusenix.refer:4277,138 mock2 rfc domain implem specif mockap usc inform scienc instit novemb 1987 Xusenix.refer:4415,194 bindim experi implem bind distri name server darpa intern bloom dunlap usenix confer procee summer 1986 Xusenix.refer:4609,150 secmec securi mechan high level networ protoc voydoc kent comput survey june 1983 acm Xusenix.refer:4759,198 acmath comput higher educat athena experi balkov lerman parmel commun acm novemb 1985 acm SHAR_EOF if test 3432 -ne "`wc -c < 'usenix.refer.ig'`" then echo shar: "error transmitting 'usenix.refer.ig'" '(should have been 3432 characters)' fi fi exit 0 # End of shell archive ------- Message 7 the following is the zephyr paper. it requires the athena refer file, and tbl. - --dan #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create: # zephyr # zephyr.tbl # This archive created: Mon Jan 4 21:44:43 1988 export PATH; PATH=/bin:/usr/bin:$PATH echo shar: "extracting 'zephyr'" '(29239 characters)' if test -f 'zephyr' then echo shar: "will not over-write existing file 'zephyr'" else sed 's/^ X//' << \SHAR_EOF > 'zephyr' X.TL X.br XThe \f(BIZephyr\fP Notification Service X.sp 3 X.AU XC. Anthony DellaFera X.AI XDigital Equipment Corporation XProject Athena XMassachusetts Institute of Technology XCambridge, MA 02139 Xtony@ATHENA.MIT.EDU X.AU XMark W. Eichin XRobert S. French XDavid C. Jedlinsky XJohn T. Kohl XWilliam E. Sommerfeld X.AI XProject Athena XMassachusetts Institute of Technology XCambridge, MA 02139 X{eichin,rfrench,opus,jtkohl,wesommer}@ATHENA.MIT.EDU X.AB X\fIZephyr\fP is a notice transport and delivery system Xunder development at Project Athena. X.[ XACMAthena X.] X\fIZephyr\fP is Xfor use by network-based services and applications with a Xneed for immediate, reliable and rapid Xcommunication with their clients. \fIZephyr\fP meets the Xhigh-throughput, high fan-out communications requirements of large-scale Xworkstation environments. XIt is designed as a suite of ``layered services'' Xbased on a reliable, authenticated notice protocol. XMultiple, redundant \fIZephyr\fP servers provide basic routing, Xqueueing, and dispatching services to clients that communicate via the X\fIZephyr\fP Client Library. More advanced communication services are Xbuilt upon this base. X.AE X.2C X.SH XIntroduction X.PP XThis paper is a brief introduction to the concept of a Xnotification service in general and to the design of the \fIZephyr\fP XNotification Service in particular. A notification service Xprovides network-based services and their clients with immediate, Xreliable, and rapid Xcommunication for small quantities of time-sensitive Xinformation. The sections which follow address Xthe following issues: X.IP \0\0\(bu 4 XMotivation for developing a notification service. X.IP \0\0\(bu 4 XRole of a notification service in networked Xworkstation environments. X.IP \0\0\(bu 4 XDesign constraints. X.IP \0\0\(bu 4 XServices provided for users by a notification service. X.IP \0\0\(bu 4 XUnsolved problems and topics for future development. X.PP XWhile this paper is about X\fIZephyr\fP, Project Athena's Notification Service, it is our belief Xthat the concepts presented here can be generalized to fit a broad Xrange of notification services and systems. XA good understanding of a notification service can Xbe acquired by comparing the \fIZephyr\fP Notification Service and a Xmore traditional method of workstation message delivery, electronic Xmail (specifically, \fIsendmail\fP). Table 1 makes this comparison. X.1C X.so usenix.tbl X.bp X.2C X.SH XA Solution To Communication Needs X.PP XWhen services designed for use in a time-sharing environment Xare used for a very large system of networked workstations, certain Xcommunication services begin to fail.\(dg X.FS X\(dgActually, services in general begin Xto fail, but the scope of this discussion is primarily the realm of Xcommunication services. XWhile some of the services, such as \fIOn-Line Consulting\fP, may Xbe unfamiliar to the reader, they are part of the Athena Xenvironment. See the companion paper Xon Athena Changes to Berkeley XUnix, Xthis volume, Xfor an overview of that environment. X.[ XAthChanges X.] X.FE XThey predominantly fail from to their Xinability to cope with large increases in network scale (i.e., an Xincrease in both the number of workstations and Xthe number of interconnected local area networks). XAfter examining how certain of these services communicate with their Xclients, we have identified two primary failure modes. These are Xthe inability of a service to cope with increasing Xserver-to-client fanout and the inability of clients to deal by the Xreplacement of a local service with a remote, distributed service. XThe \fIZephyr\fP project was begun to provide a Xsolution to these two failure modes Xin the context of time-sensitive communications. \fIZephyr\fP Xhas grown into a more powerful tool than was originally anticipated; Xwhat began as the development of a ``desirable'' service soon turned Xinto the development of a ``required'' service. X.PP XThe following services are candidate clients of a Xnotification service. All need either the base Xlevel \fIZephyr\fP service, Xwhich will deliver a message to an identifiable Xbut unlocalized recipient, Xor the notice subscription layered service, Xwhich will deliver Xa message to the set of potential recipients interested in, Xi.e. subscribing to, Xmessages of that class. XThese service levels are discussed more fully in the next Xsection. X.IP "\fIFile Service\fP" X.br XA file server Xcan send notices to the users and hosts that it knows would be Xaffected by a change in file server status, e.g. a shutdown. XIf those users also register Xa subscription with the notice subscription layered service, Xother providers of information, such as operations staff, Xwould also be able to reach the user. X.IP "\fIPost Office Service\fP" X.br XRemote post offices can notify users about the arrival of new mail. X.IP "\fIElectronic Meeting Service\fP" X.br XElectronic meeting services (conferencing systems) Xcan notify interested users of new transactions, Xusing the notice subscription layered service. X.IP "\fIPrint Service\fP" X.br XPrint servers (and queuing services in general) can send Xjob status information Xback to the job's submitter. X.IP "\fIMOTD Service\fP" X.br XMessage-of-the-day information X(system wide, service-specific, or local) Xcan be sent to users, Xsuch as when they begin using a particular service Xin the case of a service-specific MOTD. X.IP "\fIOn-Line Consulting\fP" X.br XThe notification service can be used as the Xunderpinning of a dynamic on-line consulting service. The notice Xsubscription layered service can be used to provide topic based Xinformation routing, user location, and consultant-to-client Xrendezvous. X.IP "\fIHost Status Service\fP" X.br XBroadcast-based host status systems (e.g., \fIruptime\fP) do Xnot scale to a large workstation environment; disk usage grows Xlinearly with network size and total packet computation time grows Xgeometrically. The notification service can provide immediate host Xstatus and error log notification on selected hosts or servers. X.IP "\fIUser Location Service\fP" X.br XBroadcast-based user location systems (e.g., \fIrwho\fP) Xalso do not scale to a large workstation environment for the same Xreasons noted above under \fIHost Status Service\fP. The notification Xservice can provide asynchronous and immediate user location and state Xchange (login/logout) notification on selected users or groups of Xusers. This can facilitate communication among users. For example, Xwithin the limits of user permission and access control (described Xin the section \fIA User's Overview\fP), Xstudents can watch for their friends or Xdevelopment team members for their co-workers. X.IP "\fITalk or Phone Service\fP" X.br XIn a network of workstations, one must Xknow the exact address of Xothers in order to \fItalk\fP to them. XA notification-based \fItalk\fP facility Xcan be constructed that locates the party being called, transmits a Xtalk request notice to that party and, if permission is granted, Xautomatically establishes a \fItalk\fP connection. X.IP "\fIEmergency Notification\fP" X.br XIn the Athena environment, Xthere is a requirement to provide a simple, Xasynchronous, and secure means of sending urgent notices to all users Xon a workstation or in a particular group of workstations. XBroadcast methods are not useful on a large scale and are Xby definition imprecise. XIn addition, the workstation user must trust Xthe broadcasting host and the person issuing the message. XUsing \fIZephyr\fP, Xemergency notices can be sent directly to all users on any Xspecified host, with authenticity\(dg X.FS X\(dgSince \fIZephyr\fP relies on authentication, Xit is also suggested that you read the \fIKerberos\fP Xpaper in this volume. X.[ XKUsenix X.] XThis provides a general introduction the Project Athena \fIKerberos\fP XAuthentication System. X.FE Xguaranteed. X.IP "\fIMessage Service\fP" X.br XCurrent \fIwrite\fP services suffer the same problems Xnoted above under \fITalk or Phone Services\fP. XA notification-based \fIwrite\fP utility Xis trivial, since almost Xall the work is subsumed by the notification service. Write notices Xcan go to individual users or to previously Xcreated subscription groups. X.IP "\fIOther Service Events\fP" X.br XThe Xnotification service can be used to reliably notify users of a wide Xrange of asynchronous service events that occur in distributed Xworkstation environments. This notification can be accomplished by Xusing the base notification service, the emergency notification Xservice, or one of the notification service layered services. X.SH XFitting The Tool To The Job X.PP X\fIZephyr\fP is designed Xaround a system of dynamically-updated, locally-authoritative servers Xthat provide centralized routing, queuing, and dispatching. XClients Xcommunicate with these servers via the \fIZephyr\fP Client Library Xinterface. The \fIZephyr\fP Client Library implements the X\fIZephyr\fP Protocol, a reliable, authenticated notice Xtransmission protocol. In our design we view the notification service Xas a suite of ``layered services'' built upon a base notice transport Xlayer. Additional layers provide more advanced communications Xservices. XThis design is analogous to that of the X Window System. X.[ XXACM X.] X.PP X\fIZephyr\fP notices consist of two Xparts: a routing header and client data. It is the job of the X\fIZephyr\fP Servers to route notices between \fIZephyr\fP clients Xbased upon attributes specified Xin the notice's routing header. Servers do not Xexamine a notice's client data; it is entirely possible that Xthat data is encrypted or otherwise uninterpretable. By examining the Xattributes in a notice's routing header, a X\fIZephyr\fP Server computes the list of recipients of Xa notice. The most basic routing attribute that may be Xspecified is a single recipient, named by a ZID.\(dg X.FS X\(dgRecipients must be uniquely identifiable. X\fIZephyr\fP relies on \fIKerberos\fP Xto both provide and guarantee these identifiers. XSo as to avoid confusion with the sense of a XUID, we shall refer to the X\fIZephyr\fP identifier as a ZID. X.FE XMore complex Xrouting attributes are specified for the layered services. XThe notice classification Xinformation for the notice subscription layered service discussed Xabove or specialized keywords for use with a rule-based Xrouting service are examples of such complex attributes. X.PP XDetermining notice recipients based Xupon routing header attributes is Xknown as "subscription multicasting". XSubscription multicasting is a Xpassive routing technique; attributes not recognized by a service Xlayer are simply ignored. This allows layered services to implement Xdifferent notice routing methods that peacefully co-exist while using Xthe same base notification service. XIn this way subscription multicasting differs Xfrom other message routing techniques such Xas network broadcast or \fIsendmail\fP. XBecause the set of recipients for any notice can Xalways be determined, Xit is more efficient and less Xvulnerable to increases in network scale than Xbroadcast techniques. XBecause additional resources, routing methods, and recipients Xmay be dynamically added by almost any user, Xit requires less maintenance and incurs less Xoverhead than traditional list based message transmission techniques X(such as \fIsendmail\fP). X.PP X\fIZephyr\fP clients determine what level of service they Xreceive from the notification service by choosing the service layer Xwith which they communicate. For example, certain system services Xhave complete knowledge of their clients, and only need the Xnotification service to route information to those clients. XThis is the most basic service layer. For example, Xa file server knows Xthe particular users it is serving, Xand needs only the ability to reliably Xnotify those users about service state changes. On the other hand, Xclient services that cannot identify their clients (or may simply not Xknow who is interested in such state information) may wish to notify X``interested parties'' about service state changes. A workstation Xerror logger would fall into this category. This type of service Xwould make use of the notice subscription service layer. Such a Xservice layer provides the ability to store communication state Xinformation for client services external to those services. This adds Xto the notification service the unique ability to provide to its Xclients status and availability information about other Xservices even when those services are disabled and Xcannot communicate with their own clients. X.SH XDesign Requirements And Constraints X.PP XThe goal of the \fIZephyr\fP development is Xto produce a 4.3BSD XUnix Ximplementation of Xa notification service useful to Athena. XThis implementation should Xconsider the effects of: X.PP X\fIScale\fP - XSuch a service must efficiently provide its Xcapabilities with the highest possible fan-out (i.e., client to server Xratio), without adversely affecting network load or server host Xperformance. XAdditional redundant servers must Xbe easy to install, and Xmust provide load sharing immediately. X.PP X\fIEvolution\fP - XSince \fIZephyr\fP is an evolving service, Xit is must gracefully handle Xprotocol compatibility from one version of the service to the next. X.PP X\fIManagement\fP - XIt must be possible to perform Xall aspects of Xservice maintenance and operation remotely. X.PP X\fINetwork Protocols\fP - XSince the notification service depends upon an underlying Xnetwork transport mechanism, it accepts those design constraints Ximposed by that mechanism. The \fIZephyr\fP Protocol, as currently Ximplemented, is based on the XUnreliable Datagram Protocol (UDP). As such, it is constrained to operate Xwithin the capabilities of UDP. However, there is nothing in the Xdesign of the protocol that would prevent its using other network Xtransport mechanisms (such as a remote procedure call Xsystem). XConstraints imposed by UDP are listed below, along with a brief description Xof how they affect \fIZephyr\fP application Xprogrammers and end users. X.IP X.br X\fIDuplicate Notices\fP X.br XUDP does not provide any suppression of Xduplicate packets, \fIZephyr\fP Xclients may receive duplicate X\fIZephyr\fP notices. \fIZephyr\fP applications must be capable of Xdealing with this possibility. X.IP X.br X\fIMissequenced Notices\fP X.br XUDP does not provide packet sequencing. XWhile \fIZephyr\fP notices do contain timestamps, it is up to the Xapplication to check the timestamp and handle notices Xreceived out of sequence. X.IP X.br X\fIFlow Control\fP X.br XUDP does not provide any flow-control capability. X\fIZephyr\fP applications must be capable of dealing with notices at whatever Xrate they arrive or be willing to lose notices. X.IP X.br X\fIUnreliable Delivery\fP X.br XUDP does not provide a reliable delivery Xmechanism. \fIZephyr\fP does provide several levels of Xacknowledgment processing, but Xit is up to the application to decide how Xmuch overhead it is willing to incur in order to guarantee notice Xdelivery. X.IP X.br X\fIPacket Size\fP X.br XUDP packets have a relatively small, maximum size. XConsidering the amount of routing data and other information that X\fIZephyr\fP must store in each packet, Xthis becomes a Xconstraint on how much user data may be included with each packet. X.PP XHow visible these constraints are to the end user is up to the X\fIZephyr\fP application programmer. For example, our \fIzwrite\fP Xapplication (which allows users to exchange \fIwrite\fP-like Xmessages) only guarantees that the message was sent, not that it will Xactually arrive or how many copies will arrive. X.PP XIn order to provide ZID-based communications, the notification Xservice must dynamically maintain a database that maps ZID's to their current Xphysical locations in the network. The only requirement on the ZID Xused in addressing is that it must be a network wide ZID and be X``registered'' as a client of the notification service (i.e., have its Xphysical address(es) stored in the notification service database). XIn particular, X\fIZephyr\fP manages a location database that maps \fIKerberos\fP X``principal names'' (authenticated user names) into a tuple of physical Xlocation information (geographic location, hostname, IP port number, and tty, Xamong other things). This database is primarily used by \fIZephyr\fP Xfor notice routing, but is also made available to \fIZephyr\fP clients Xvia the User Location Layered Service discussed below. X.PP XThe reliability of the information stored in the user location Xdatabase imposes constraints upon applications that rely on X\fIZephyr\fP. X.IP \0\0\(bu 4 XUser location information present in the database can be Xassumed to indicate that a user has logged Xin, because user logins that are reported to X\fIZephyr\fP must be \fIKerberos\fP authenticated. X.IP \0\0\(bu 4 XUser location information present in the database cannot be Xassumed to indicate that a user is still logged Xin, because there is no way to guarantee an Xorderly user logout. (For example, a workstation may crash). X.IP \0\0\(bu 4 XThe absence of user location information in the database Xcannot be assumed to indicate that a user has not logged in, Xbecause a user can choose to not make his or her login Xinformation publicly available. X.PP X\fIZephyr\fP attempts Xto prevent user location data Xfrom persisting when it is no longer valid. If a workstation Xcrashes, the user login sessions on that workstation are necessarily Xterminated without sending logout notices to a \fIZephyr\fP Xserver. This Ximplies that logins in the database may not always Xbe valid. XTo cope with this, a specialized \fIZephyr\fP client Xruns during the workstation reboot sequence. This client simply Xtells a \fIZephyr\fP server to flush any Xprevious state information associated with the (rebooted) workstation. X.SH XA User's Overview X.PP XFor this discussion, a ``user'' of \fIZephyr\fP is either a user of a X\fIZephyr\fP client or an applications programmer who is using the X\fIZephyr\fP Client Library. X.PP XThe \fIZephyr\fP system can be viewed as divided into two Xparts, clients and servers. XThere must be at least one \fIZephyr\fP Server (\fIzephyrd\fP) per X\fIKerberos\fP realm (realm of authority of a particular authentication Xservice), one \fIZephyr\fP HostManager Client (\fIzhm\fP) per Xactive workstation and one \fIZephyr\fP WindowGram Client (\fIzwgc\fP) Xper user login session. XTo ensure reliable service, Xthere should be several \fIZephyr\fP Servers per \fIKerberos\fP realm. X.PP XWhen a workstation is reboots, a \fIzhm\fP is automatically Xstarted. The \fIzhm\fP serves two purposes. First, it acts as a Xreliable transmission tower for notices sent from local \fIZephyr\fP Xclients. Second, the \fIzhm\fP acts as an emergency notice routing Xchannel on the individual workstation. When \fIzhm\fP starts up it Xfirst seeks out a \fIZephyr\fP Server and registers itself with that Xserver. From then on, that \fIzhm\fP and all clients that communicate Xthrough it are ``owned'' by that server. Only that server will be Xconsidered to have ``authoritative'' information about \fIZephyr\fP Xclients on the workstation managed by that \fIzhm\fP. X.PP XAll \fIZephyr\fP clients on a workstation use the \fIZephyr\fP XClient Library to send and receive \fIZephyr\fP notices. The X\fIZephyr\fP Client Library routes all notice traffic leaving a Xworkstation through that workstation's \fIzhm\fP. XIn this way, clients themselves are not required to Xhave to locate and manage Xcommunications with a \fIZephyr\fP Server. If the \fIzhm\fP loses Xcontact with its \fIZephyr\fP Server (i.e., the \fIZephyr\fP server Xwhich owns it does not respond within a fixed but configurable safety Xmargin) it is the \fIzhm's\fP job to seek out and contact a new X\fIZephyr\fP Server. X.PP XWhen a user logs into a workstation, Xa \fIzwgc\fP for that user is automatically started, Xprovided that the user can provide an authenticator and that Xthe user has not deliberately disabled \fIZephyr\fP. If the Xuser is not interested in using \fIZephyr\fP, Xit is still important that s/he have a X\fIzwgc\fP running. The most important reason is that \fIzwgc\fP is the Xcontact point for \fIZephyr\fP emergency notices. These notices Xare transmitted by certain privileged users X(e.g. operations staff), X\fIdirectly\fP to the Xworkstation's \fIzhm\fP. The \fIzhm\fP then forwards these notices to all X\fIzwgc's\fP currently running on the workstation. X.PP XWhen the \fIzwgc\fP starts up, it registers the user with X\fIZephyr\fP and, depending upon the setting of certain \fIZephyr\fP Xcontrol variables, may make other \fIZephyr\fP requests. XThese variables may be modified using Xthe \fIZephyr\fP Control Utility (\fIzctl\fP). The most important of Xthese variables is the \fIZephyr\fP exposure level variable. This Xvariable controls how much information about an individual user X\fIZephyr\fP will store and make available to requesting clients. XThere are currently six possible settings for this variable: X.IP X\fBnone\fP - XThis completely disables \fIZephyr\fP. The user is not Xregistered with \fIZephyr\fP. No user location information is Xretained by \fIZephyr\fP. No login or logout announcements will be Xsent. No system default notice subscriptions will be entered for the Xuser. X.IP X\fBopstaff\fP - XThe user is registered with \fIZephyr\fP. Only system Xoperation notices and emergency notices will be received. No user Xlocation information is retained by \fIZephyr\fP. No login or logout Xannouncements will be sent. System default notice subscriptions will Xbe entered for the user. X.IP X\fBrealm-visible\fP - XThis is the default exposure setting. XThe user is registered with \fIZephyr\fP. All notices Xwill be received. User location information is retained by X\fIZephyr\fP and made available only to users within the X\fIKerberos\fP realm. XNo login or logout announcements will be sent. XSystem default notice subscriptions will be entered for the user. X.IP X\fBrealm-announced\fP - XThe same as \fBrealm-visible\fP, plus Xlogin/out announcements will be sent to Xusers within the \fIKerberos\fP realm who have explicitly requested Xthem). X.IP X\fBnet-visible\fP - XThe same as \fBrealm-visible\fP, plus Xuser location information Xis made available to any user who requests it. X.IP X\fBnet-announced\fP - XThe same as \fBrealm-announced\fP, plus Xlogin/out announcements will be sent to any user who has requested Xthem. X.PP X\fIzwgc\fP is a vital client. XFor this reason X\fIzwgc\fP has two primary interfaces. The first, and most powerful, Xis an X Window System interface referred to as a ``WindowGram Xbrowser.'' This browser allows the user to scroll through and perform Xcertain operations (such as ``save'', ``delete'', ``cut'' and X``paste'') on all the notices that \fIzwgc\fP has received. If a user Xlogs into an X display, \fIxwgc\fP selects this interface. XIf the user does not have access to an X Display, X\fIxwgc\fP selects a simple terminal based interface. X.PP XIn addition to the basic services described above, X\fIZephyr\fP provides additional layered services that are built on Xthe base notification service.\(dg X.FS X\(dgThe architectural design details of Xthe \fIZephyr\fP Service Layers are discussed in the \fIZephyr\fP Xdesign document. X.[ XZTech X.] X.FE XThe two most important of these are Xthe \fIZephyr\fP Notice Subscription Layered Service and the X\fIZephyr\fP User Location Layered Service. X.PP XThe \fIZephyr\fP Notice Subscription Layered Service provides Xa dynamic information dispersal service based upon a ``subscription Xlist'' paradigm. The most important use for this layered service is Xby services that cannot directly identify their clients or may simply Xnot know who is interested in the information they are providing. XSuch services may wish to simply send notices to ``all interested Xparties.'' X.PP XThe simplest function that the \fIZephyr\fP Notice XSubscription Layered Service provides is a method for users and groups Xof users to exchange notices. This is accomplished with the X\fIzwrite\fP utility. In addition to person-to-person messages X\fIzwrite\fP allows users to send notices to notice subscription Xlists. X.PP XRestricted access to user location information is made Xavailable to \fIZephyr\fP clients by the \fIZephyr\fP Client Library. XThis information is dispersed by the User Location Layered XService. The database which this layered service uses is maintained Xinternally by \fIZephyr\fP to track the existence of ZID's in Xthe network. A user can be located through \fIZephyr\fP by using the X\fIzlocate\fP and/or \fIznol\fP utilities. These utilities make calls to Xthe \fIZephyr\fP User Location Layered Service for the user. The X\fIzlocate\fP utility allows users to manually locate one or more users. XThe \fIznol\fP utility makes use of the \fIZephyr\fP Notice Subscription XLayered Service to subscribe to user login/out notices from Xa list of ZID's provided by the user. X.PP XWhen a workstation crashes, all clients running on that Xworkstation are lost. When this happensr, client state information that X\fIZephyr\fP has associated with that workstation must be Xflushed and any corresponding \fIZephyr\fP system resources must be freed. XThis is done in two ways. The first occurs slowly while the Xworkstation remains down, the second when it reboots. If the Xworkstation remain down long enough all invalid state Xinformation will be incrementally detected and flushed. This Xincremental flushing occurs whenever a \fIZephyr\fP Server attempts to Xsend (or route) a notice to a client and discovers that the Xworkstation on which that client is supposed to be running is not Xresponding. When the workstation does eventually reboot, \fIzhm\fP is Xcalled with a special ``reboot flush'' flag. This causes \fIzhm\fP to Xrun just long enough to transmit a special workstation state flush Xnotice to the first available \fIZephyr\fP Server. These two X``garbage collection'' techniques work together to keep the X\fIZephyr\fP system's database current. X.PP XThe last phase of user interaction with \fIZephyr\fP occurs at Xlogout time. When the user logs out, \fIzwgc\fP notifies \fIZephyr\fP Xto flush all state associated with that user's login and then exits. X.PP XThe \fIZephyr\fP system currently consists of the following suite of programs: X.TS Xcenter expand; Xl l. X\fIzctl(1)\fP \fIZephyr\fP subscription control program X\fIzinit(1)\fP \fIZephyr\fP login initialization program X\fIzleave(1)\fP Remind you when you have to leave X\fIzlocate(1)\fP Find a user X\fIznol(1)\fP Notify on login/out of specified users X\fIzwgc(1)\fP \fIZephyr\fP WindowGram Client X\fIzwrite(1)\fP Write to another user X\fIzhm(8)\fP \fIZephyr\fP HostManager Client X\fIzephyrd(8)\fP \fIZephyr\fP Server daemon X\fIzstat(8)\fP Display \fIZephyr\fP statistics X.TE X.SH XFuture Directions And Unsolved Problems X.PP XOnce the basic notification service is in place it becomes a Xsimple matter to provide many other layered services based upon it. XThe \fItalk\fP service mentioned above is a good example of a service Xthat utilizes multiple \fIZephyr\fP service layers. XWe envision \fIZephyr\fP as a transport service that can Xincorporate new notice routing methods as they are developed. X\fIZephyr\fP is designed to allow communication development efforts to Xoccur side-by-side with running production systems that utilize X\fIZephyr\fP. For example, researchers Xat M.I.T.'s Sloan School of Management have expressed Xinterest in using X\fIZephyr\fP as the transport service layer for a rule based Xcommunication system. X.PP XThe following is a list of some of the areas Xof future development. They are either unsolved problems Xor areas that need further investigation. X.IP \0\0\(bu 4 XExtend the \fIZephyr\fP Protocol for use across long-haul networks. X.IP \0\0\(bu 4 XModify the \fIZephyr\fP Server to allow ZID registration from other X\fIKerberos\fP authentication realms. X.IP \0\0\(bu 4 XModify the \fIZephyr\fP Server to forward \fIZephyr\fP notices to Xrecipients in other \fIKerberos\fP realms. X.IP \0\0\(bu 4 XDevelop a more formal interface definition for use between the X\fIZephyr\fP notice transport layer and \fIZephyr\fP Layered Services. X.IP \0\0\(bu 4 XDevelop a more advanced user interface for the \fIZephyr\fP WindowGram XClient. X.IP \0\0\(bu 4 XDecouple \fIZephyr\fP from the \fIKerberos\fP system. XIn the current implementation, Xthey are linked together too closely. X.IP \0\0\(bu 4 XIntegrate with more clients. X.SH XConclusions X.PP X\fIZephyr\fP has proven useful in providing a mechanism for Xtransporting time-sensitive information in a large-scale Xworkstation environment. XIt not only permits existing services from the timesharing Xworld to evolve toward the workstation world, but also permits Xnew services to grow alongside. XIt makes reasonable compromises between reliability and Xcomplexity and is already of use to both users Xand operations staff. XIndeed a major problem has been its popularity while Xstill under development. X.SH XAcknowledgements X.PP XThe authors would like to acknowledge the following people Xfrom M.I.T. Project Athena for their help in making \fIZephyr\fP a Xreality. Michael R. Gretzinger, former Systems Programmer, and David G. XGrubbs, former Manager of Systems Integration, for their Xsuggestions on the Xinitial concept of a Notification Service, and Daniel E. Geer, the Manager of XSystems Development, for his undying support of Xour efforts. XWe also thank Katharyn L. Lieben and G. Winfield Treese Xfor the improvements they made to this paper. X.SH XReferences X.[ X$LIST$ X.] SHAR_EOF if test 29239 -ne "`wc -c < 'zephyr'`" then echo shar: "error transmitting 'zephyr'" '(should have been 29239 characters)' fi fi echo shar: "extracting 'zephyr.tbl'" '(3745 characters)' if test -f 'zephyr.tbl' then echo shar: "will not over-write existing file 'zephyr.tbl'" else sed 's/^ X//' << \SHAR_EOF > 'zephyr.tbl' X.ds CF "Table 1 X.TS H Xallbox center expand; Xc s s Xc c c Xlw5 lew30 lew30. XA Comparison Between \fIZephyr\fP And Mail X_ XMetric \fIZephyr\fP Electronic Mail X_ X.TH XAddressing T{ X.fi XImplicit/Dynamic: All addressing is Xdetermined dynamically; Xan explicit ``address'' is not required. One-to-one Xaddressing is supported by explicitly specifying of recipient XZID. The notice subscription layered service Xallows for self-selection by the recipient. XT} T{ X.fi XExplicit/Static: Sender must know and Xexplicitly provide the name and address (except for ``local'' mail) of Xeach recipient. Static mailing Xlist support is provided. Only recipients explicitly named receive Xmessages. XT} XDelivery Method T{ X.fi XNotices are delivered via dynamically routed reliable Xdatagrams. No connections need be established or maintained. Multiple Xlevels of notice acknowledgment are supported. XT} T{ X.fi XMail is delivered Xusing a point-to-point TCP/IP connection. Acknowledgments are not Xsupported, per se. Return receipts may be requested but are Xnot guaranteed to work. XT} XDelivery Action T{ X.fi XAsynchronous/Active: Notices arrive without user Xintervention. Notices to a particular user are delivered Xautomatically and immediately to all of his or her current login Xsessions. XT} T{ X.fi XSynchronous/Passive: Mail must be sent and read manually Xby the user. Mail, in general, is delivered to one particular Xplace (a ``post office'' or ``mail drop'') for each user; s/he Xmust then actively retrieve it. XT} XMessage Length T{ X.fi XShort, fixed, notice length with a maximum of Xapproximately 10 lines of 80 characters each. XT} T{ X.fi XLong, typically unfixed, Xmessage length. Mail messages may be and often are extremely large, on Xthe order of many pages. When message length is fixed it is usually Xdone so by unpredictable rules that vary from site to site. XT} XMessage Persistence T{ X.fi XNotices are considered time-sensitive; no queuing Xis provided. If the client recipient is not logged in, then the Xnotice is flushed. XT} T{ X.fi XLong time-to-live. Messages typically remain in a mail drop Xuntil read. XT} XMessage Fan-out T{ X.fi XHigh fan-out: Sending to large lists is efficient. XEach client generates one copy of a notice regardless of the number Xof recipients. Each server receives one copy of a notice being Xrouted regardless of the number of recipients. XT} T{ X.fi XLow fan-out. Sending to large lists can consume a great deal of the Xcomputing resource. If a message is sent to \fIn\fP users, X\fIn\fP copies Xare generated by the sender, each of which is retained indefinitely by Xits recipient. XT} XTraffic Performance T{ X.fi XHigh volume/High throughput: Notices Xmay be transmitted in large numbers due to the low overhead of Xdynamically-routed reliable datagrams. XT} T{ X.fi XMedium volume/Low Xthroughput: Large mail messages can send a reasonable volume Xof data, but slowly (as connections need to be established and routes Xdetermined). XT} XSystem Configurability T{ X.fi XDynamically reconfigurable: Dynamic resource Xallocation and configuration within the base notification services Xallows for automatic and simple user-level reconfiguration of layered Xservices. XT} T{ X.fi XStatically reconfigurable: Reconfiguration of XUnix Xmail systems is wizard-level Xwork and has significant global impact. No Xutilities are provided for dynamic system modification or Xreconfiguration. All changes must be made centrally and atomically. XT} XSystem Maintenance T{ X.fi XLow maintenance: Layered services dynamically Xrecover unused resources through time-outs and reference counting. XT} T{ X.fi XHigh maintenance: Mail requires a post office staff Xto maintain post office boxes (mail drops), mailing lists, the routing Xsystem, and to manually reroute ``dead letters.'' XT} X.TE X.ds CF SHAR_EOF if test 3745 -ne "`wc -c < 'zephyr.tbl'`" then echo shar: "error transmitting 'zephyr.tbl'" '(should have been 3745 characters)' fi fi exit 0 # End of shell archive Subject: Inserting RS/1 graphs into Scribe Eureka! I did it, although it took me an additional 3 hours. There is one moderately complext UNIX command, and one mildly complex Scribe command involved. Here is the stock answer I wrote, a modified version of which is now added to my version of Essential RS/1 in ~enprabha/Doc. Enjoy. - ------------------------------------------------------------------------ It is now possible, albeit slightly tricky, to include pictures made from Tektronix mode in Scribe documents. You should have a file with a name like 'hardcopy.tek' which contains the Tektronix commands, created by either the COPY menu option or the 'plot' command in RS/1. To change it into a PostScript file, use the following command: % ps4014 -R -s6.5,8 copy.tek | grep -v "showpage" > copy.PS This will create a picture of the appropriate size, while '-R' orients it in the same direction as the rest of the Scribed text. grep -v removes the command showpage from the PostScript file, so you can include it in Scribe, means you cannot print the graph out separately. Be warned that this can take a few minutes. You include this graph in Scribe by using the ``@Picture'' command. This is best done in the context of an ``@FullPageFigure'', as described in "More Scribe: Reports". You should use something that looks like this: @Begin(FullPageFigure) @Picture(Width 6.5 inch, Height 8.5 inch, PostScript `copy.PS') @Caption(This is an RS/1 Graph) @End(FullPageFigure) The extra 0.5 inches of height is to allow for the page headings. You can vary the size if you like, but be sure to synchronize changes to both ``ps4014'' and ``@Picture''. For more information about ps4014 options, type: % man ps4014 - ------------------------------------------------------------------------ Subject: ????????? punt on lab pcs for now. Use ACIS 4.2/RT, with Athena enhancements. It's not really 4.2a BSD anymore. By all means put in a discussion of Athenadoc. M. Ciccarone Subject: updating essential athena i am revising essential athena and just ran into a paragraph which seems like it might be out of date: @b(Please note:) Many people previously registered with Athena will have to reregister. If you were previously registered but haven't changed your password since January 1, 1987 then your name isn't known by the new user authentication service--Kerberos. Therefore, if you haven't changed your password since that date, please reregister. What is the situation for people for who haven't re-registered by now? Subject: the e51 cluster i'm working on revising essential athena and i wanted to find out what's up with the e51 cluster. is it going to be reopened soon? if so, i can mention it in the document; if not, i'm going to leave it out. do you know or do you know who would? Subject: new addition for the maintaining athenadoc document the easiest way to keep only one copy of any document is to have the athenadoc caretaker remove the revision history when s/he moves the contents from the back to front of a document. Subject: Problem with MORE EMACS Please correct the online version and put the correction in the .mss for the paper copy. Perhaps now is the time to put a box on the cover page with the following message. @begin(box) The online version of this document differs from the paper copy. This version omits operation of the ctrl-shift-left mouse operation that would cause an error. @end(box) - --or some hooha like that. Keep the same version letter, but change the date on the cover page. Subject: [rfrench@ATHENA.MIT.EDU: Re: VS 6.0a: emacs ctrl-shift-left doesn't perform as advertised] While researching your bug report of last week, in which you stated that when you follow the instructions described in the _More Emacs_ document you get an error message instead of the buffer selection menu, I learned that support for menus inside emacs will be removed in future releases of the Athena system. C-S-LEFT will do nothing in future releases. PS--kll: the reference in @i[More Emacs] needs to be nuked. Subject: amex.card source @device(PostScript) @make(text) @definefont(Userfont, 1=, 2=, 3=, 4=) @Style(Font "NewCenturySchoolbook", size 6) @Style(spacing 1,indent 0) @Style(leftmargin .5 inch, rightmargin .1 inch) @Style(TopMargin .25 inches) @Style(BottomMargin .25 inches) @modify(Plus size +1,script +.1 lines) @modify(minus size +1 , script -.1 lines) @modify(MajorHeading,FlushLeft, size 10, Facecode B, above .3 inch, below .2inch) @Modify(Heading, Flushleft, size 8, Facecode B) @Modify(SubHeading, Flushleft, size 12, Facecode B) @Tabclear @Tabset(2.25 inches) @Modify(display, rightmargin +0) @Modify(example,rightmargin +0) @Modify(heading, font userfont, facecode 2) @modify(subheading, font userfont, facecode 4,above .2inch,below .2inch) @define(columns=text, columns 3, columnmargin .5 inch, boxed) @begin(columns) @begin(Heading,Flushleft,above .1inch, below .05inch) Athena Cluster Chart--9/1/87 @end(heading) Global cypher lock combination 37619 @blankspace(.01 lines) W20 cypher lock (2 & 5 together) then 6323 @begin(Format) @Tabset(+7, +9, +8) @b[Bldg.@\Room@\Phone@\Description] @blankspace(.1 lines) @=1@\@=1-142@\@=3-2019@\Public (DEC VS2000) @=2@\@=2-225@\@=3-0106@\Public (IBM RT) @=4@\@=4-167@\@=3-0105@\Public (IBM RT) @=4@\@=4-035@\@=3-5660@\Public (DEC VSII) @=6@\@=6-218M@\@=3-0104@\Public (IBM AT) @=11@\@=11-113@\@=3-2061@\Video @\@=11-115@\@=3-4435@\User Services @\@=11-116@\@\Public (DEC VS2000) @\@=11-124@\@\Development Cluster @\@=11-124a@\@\IS/Athena Training @=16@\@=16-034@\@=3-0152@\Public (IBM RT) @=37@\@=37-312@\@=3-0180@\Electronic Classroom @\@=37-332@\@=3-0182@\Development Cluster @\@=37-318@\@=3-0179@\Public Cluster @=38@\@=38-344@\@=3-4650@\Public (DEC VS2000) @=66@\@=66-080@\@=3-4474@\Public (DEC VS2000) @=E51@\@=E51-007@\@=3-0173@\Public (IBM AT) @=W20@\@=W20-500@\@=3-0103@\Public (IBM RT & @\@\@\DEC VS2000) @end(format) @blankspace(5 lines) @begin(Heading,Flushleft,above .1inch, below .05inch) Athena Cluster Chart--9/1/87 @end(heading) Cypher lock combination 37619 @blankspace(.01 lines) W20 cypher lock (2 & 5 together) then 6323 @begin(Format) @Tabset(+7, +9, +8) @b[Bldg.@\Room@\Phone@\Description] @blankspace(.1 lines) @=1@\@=1-142@\@=3-2019@\Public (DEC VS2000) @=2@\@=2-225@\@=3-0106@\Public (IBM RT) @=4@\@=4-167@\@=3-0105@\Public (IBM RT) @=4@\@=4-035@\@=3-5660@\Public (DEC VSII) @=6@\@=6-218M@\@=3-0104@\Public (IBM AT) @=11@\@=11-113@\@=3-2061@\Video @\@=11-115@\@=3-4435@\User Services @\@=11-116@\@\Public (DEC VS2000) @\@=11-124@\@\Development Cluster @\@=11-124a@\@\IS/Athena Training @=16@\@=16-034@\@=3-0152@\Public (IBM RT) @=37@\@=37-312@\@=3-0180@\Electronic Classroom @\@=37-332@\@=3-0182@\Development Cluster @\@=37-318@\@=3-0179@\Public Cluster @=38@\@=38-344@\@=3-4650@\Public (DEC VS2000) @=66@\@=66-080@\@=3-4474@\Public (DEC VS2000) @=E51@\@=E51-007@\@=3-0173@\Public (IBM AT) @=W20@\@=W20-500@\@=3-0103@\Public (IBM RT & @\@\@\DEC VS2000) @end(format) @blankspace(5 lines) @begin(Heading,Flushleft,above .1inch, below .05inch) Athena Cluster Chart--9/1/87 @end(heading) Cypher lock combination 37619 @blankspace(.01 lines) W20 cypher lock (2 & 5 together) then 6323 @begin(Format) @Tabset(+7, +9, +8) @b[Bldg.@\Room@\Phone@\Description] @blankspace(.1 lines) @=1@\@=1-142@\@=3-2019@\Public (DEC VS2000) @=2@\@=2-225@\@=3-0106@\Public (IBM RT) @=4@\@=4-167@\@=3-0105@\Public (IBM RT) @=4@\@=4-035@\@=3-5660@\Public (DEC VSII) @=6@\@=6-218M@\@=3-0104@\Public (IBM AT) @=11@\@=11-113@\@=3-2061@\Video @\@=11-115@\@=3-4435@\User Services @\@=11-116@\@\Public (DEC VS2000) @\@=11-124@\@\Development Cluster @\@=11-124a@\@\IS/Athena Training @=16@\@=16-034@\@=3-0152@\Public (IBM RT) @=37@\@=37-312@\@=3-0180@\Electronic Classroom @\@=37-332@\@=3-0182@\Development Cluster @\@=37-318@\@=3-0179@\Public Cluster @=38@\@=38-344@\@=3-4650@\Public (DEC VS2000) @=66@\@=66-080@\@=3-4474@\Public (DEC VS2000) @=E51@\@=E51-007@\@=3-0173@\Public (IBM AT) @=W20@\@=W20-500@\@=3-0103@\Public (IBM RT & @\@\@\DEC VS2000) @end(format) @newcolumn() @begin(Heading,Flushleft,above .1inch, below .05inch) Athena Cluster Chart--9/1/87 @end(heading) Cypher lock combination 37619 @blankspace(.01 lines) W20 cypher lock (2 & 5 together) then 6323 @begin(Format) @Tabset(+7, +9, +8) @b[Bldg.@\Room@\Phone@\Description] @blankspace(.1 lines) @=1@\@=1-142@\@=3-2019@\Public (DEC VS2000) @=2@\@=2-225@\@=3-0106@\Public (IBM RT) @=4@\@=4-167@\@=3-0105@\Public (IBM RT) @=4@\@=4-035@\@=3-5660@\Public (DEC VSII) @=6@\@=6-218M@\@=3-0104@\Public (IBM AT) @=11@\@=11-113@\@=3-2061@\Video @\@=11-115@\@=3-4435@\User Services @\@=11-116@\@\Public (DEC VS2000) @\@=11-124@\@\Development Cluster @\@=11-124a@\@\IS/Athena Training @=16@\@=16-034@\@=3-0152@\Public (IBM RT) @=37@\@=37-312@\@=3-0180@\Electronic Classroom @\@=37-332@\@=3-0182@\Development Cluster @\@=37-318@\@=3-0179@\Public Cluster @=38@\@=38-344@\@=3-4650@\Public (DEC VS2000) @=66@\@=66-080@\@=3-4474@\Public (DEC VS2000) @=E51@\@=E51-007@\@=3-0173@\Public (IBM AT) @=W20@\@=W20-500@\@=3-0103@\Public (IBM RT & @\@\@\DEC VS2000) @end(format) @blankspace (5 lines) @begin(Heading,Flushleft,above .1inch, below .05inch) Athena Cluster Chart--9/1/87 @end(heading) Cypher lock combination 37619 @blankspace(.01 lines) W20 cypher lock (2 & 5 together) then 6323 @begin(Format) @Tabset(+7, +9, +8) @b[Bldg.@\Room@\Phone@\Description] @blankspace(.1 lines) @=1@\@=1-142@\@=3-2019@\Public (DEC VS2000) @=2@\@=2-225@\@=3-0106@\Public (IBM RT) @=4@\@=4-167@\@=3-0105@\Public (IBM RT) @=4@\@=4-035@\@=3-5660@\Public (DEC VSII) @=6@\@=6-218M@\@=3-0104@\Public (IBM AT) @=11@\@=11-113@\@=3-2061@\Video @\@=11-115@\@=3-4435@\User Services @\@=11-116@\@\Public (DEC VS2000) @\@=11-124@\@\Development Cluster @\@=11-124a@\@\IS/Athena Training @=16@\@=16-034@\@=3-0152@\Public (IBM RT) @=37@\@=37-312@\@=3-0180@\Electronic Classroom @\@=37-332@\@=3-0182@\Development Cluster @\@=37-318@\@=3-0179@\Public Cluster @=38@\@=38-344@\@=3-4650@\Public (DEC VS2000) @=66@\@=66-080@\@=3-4474@\Public (DEC VS2000) @=E51@\@=E51-007@\@=3-0173@\Public (IBM AT) @=W20@\@=W20-500@\@=3-0103@\Public (IBM RT & @\@\@\DEC VS2000) @end(format) @blankspace(5 lines) @begin(Heading,Flushleft,above .1inch, below .05inch) Athena Cluster Chart--9/1/87 @end(heading) Cypher lock combination 37619 @blankspace(.01 lines) W20 cypher lock (2 & 5 together) then 6323 @begin(Format) @Tabset(+7, +9, +8) @b[Bldg.@\Room@\Phone@\Description] @blankspace(.1 lines) @=1@\@=1-142@\@=3-2019@\Public (DEC VS2000) @=2@\@=2-225@\@=3-0106@\Public (IBM RT) @=4@\@=4-167@\@=3-0105@\Public (IBM RT) @=4@\@=4-035@\@=3-5660@\Public (DEC VSII) @=6@\@=6-218M@\@=3-0104@\Public (IBM AT) @=11@\@=11-113@\@=3-2061@\Video @\@=11-115@\@=3-4435@\User Services @\@=11-116@\@\Public (DEC VS2000) @\@=11-124@\@\Development Cluster @\@=11-124a@\@\IS/Athena Training @=16@\@=16-034@\@=3-0152@\Public (IBM RT) @=37@\@=37-312@\@=3-0180@\Electronic Classroom @\@=37-332@\@=3-0182@\Development Cluster @\@=37-318@\@=3-0179@\Public Cluster @=38@\@=38-344@\@=3-4650@\Public (DEC VS2000) @=66@\@=66-080@\@=3-4474@\Public (DEC VS2000) @=E51@\@=E51-007@\@=3-0173@\Public (IBM AT) @=W20@\@=W20-500@\@=3-0103@\Public (IBM RT & @\@\@\DEC VS2000) @end(format) @newcolumn() @begin(Heading,Flushleft,above .1inch, below .05inch) Athena Cluster Chart--9/1/87 @end(heading) Cypher lock combination 37619 @blankspace(.01 lines) W20 cypher lock (2 & 5 together) then 6323 @begin(Format) @Tabset(+7, +9, +8) @b[Bldg.@\Room@\Phone@\Description] @blankspace(.1 lines) @=1@\@=1-142@\@=3-2019@\Public (DEC VS2000) @=2@\@=2-225@\@=3-0106@\Public (IBM RT) @=4@\@=4-167@\@=3-0105@\Public (IBM RT) @=4@\@=4-035@\@=3-5660@\Public (DEC VSII) @=6@\@=6-218M@\@=3-0104@\Public (IBM AT) @=11@\@=11-113@\@=3-2061@\Video @\@=11-115@\@=3-4435@\User Services @\@=11-116@\@\Public (DEC VS2000) @\@=11-124@\@\Development Cluster @\@=11-124a@\@\IS/Athena Training @=16@\@=16-034@\@=3-0152@\Public (IBM RT) @=37@\@=37-312@\@=3-0180@\Electronic Classroom @\@=37-332@\@=3-0182@\Development Cluster @\@=37-318@\@=3-0179@\Public Cluster @=38@\@=38-344@\@=3-4650@\Public (DEC VS2000) @=66@\@=66-080@\@=3-4474@\Public (DEC VS2000) @=E51@\@=E51-007@\@=3-0173@\Public (IBM AT) @=W20@\@=W20-500@\@=3-0103@\Public (IBM RT & @\@\@\DEC VS2000) @end(format) @blankspace(5 lines) @begin(Heading,Flushleft,above .1inch, below .05inch) Athena Cluster Chart--9/1/87 @end(heading) Cypher lock combination 37619 @blankspace(.01 lines) W20 cypher lock (2 & 5 together) then 6323 @begin(Format) @Tabset(+7, +9, +8) @b[Bldg.@\Room@\Phone@\Description] @blankspace(.1 lines) @=1@\@=1-142@\@=3-2019@\Public (DEC VS2000) @=2@\@=2-225@\@=3-0106@\Public (IBM RT) @=4@\@=4-167@\@=3-0105@\Public (IBM RT) @=4@\@=4-035@\@=3-5660@\Public (DEC VSII) @=6@\@=6-218M@\@=3-0104@\Public (IBM AT) @=11@\@=11-113@\@=3-2061@\Video @\@=11-115@\@=3-4435@\User Services @\@=11-116@\@\Public (DEC VS2000) @\@=11-124@\@\Development Cluster @\@=11-124a@\@\IS/Athena Training @=16@\@=16-034@\@=3-0152@\Public (IBM RT) @=37@\@=37-312@\@=3-0180@\Electronic Classroom @\@=37-332@\@=3-0182@\Development Cluster @\@=37-318@\@=3-0179@\Public Cluster @=38@\@=38-344@\@=3-4650@\Public (DEC VS2000) @=66@\@=66-080@\@=3-4474@\Public (DEC VS2000) @=E51@\@=E51-007@\@=3-0173@\Public (IBM AT) @=W20@\@=W20-500@\@=3-0103@\Public (IBM RT & @\@\@\DEC VS2000) @end(format) @blankspace(5 lines) @begin(Heading,Flushleft,above .1inch, below .05inch) Athena Cluster Chart--9/1/87 @end(heading) Cypher lock combination 37619 @blankspace(.01 lines) W20 cypher lock (2 & 5 together) then 6323 @begin(Format) @Tabset(+7, +9, +8) @b[Bldg.@\Room@\Phone@\Description] @blankspace(.1 lines) @=1@\@=1-142@\@=3-2019@\Public (DEC VS2000) @=2@\@=2-225@\@=3-0106@\Public (IBM RT) @=4@\@=4-167@\@=3-0105@\Public (IBM RT) @=4@\@=4-035@\@=3-5660@\Public (DEC VSII) @=6@\@=6-218M@\@=3-0104@\Public (IBM AT) @=11@\@=11-113@\@=3-2061@\Video @\@=11-115@\@=3-4435@\User Services @\@=11-116@\@\Public (DEC VS2000) @\@=11-124@\@\Development Cluster @\@=11-124a@\@\IS/Athena Training @=16@\@=16-034@\@=3-0152@\Public (IBM RT) @=37@\@=37-312@\@=3-0180@\Electronic Classroom @\@=37-332@\@=3-0182@\Development Cluster @\@=37-318@\@=3-0179@\Public Cluster @=38@\@=38-344@\@=3-4650@\Public (DEC VS2000) @=66@\@=66-080@\@=3-4474@\Public (DEC VS2000) @=E51@\@=E51-007@\@=3-0173@\Public (IBM AT) @=W20@\@=W20-500@\@=3-0103@\Public (IBM RT & @\@\@\DEC VS2000) @end(format) @end(columns) Subject: something i found in linda's jason stuff i don't know if this would be of any value, but it's a pretty comprehensive outline of how to put together a document. i though you might be interested in seeing it. Essential RS/1: Sketch of Requirements 1. Audience: The undergraduate who knows how to login to Unix, has little other knowledge of Unix or computers, and who wants to use RS/1 to help him/her prepare a lab report. 2. Draft by early March. 3. Short. 10 or fewer pages (5 leaves). 4. Use a concrete example, follow it through all steps. 5. Show: -mkdir? -how to enter RS/1 (graphics terminal) -simplified command format rules -get help -leave RS/1 -enter a table of data using prompting editor -graph it on the screen (X x Y, others?) -run some statistics on it -specify subsets of graph? -hardcopy of table -hardcopy of plot -modify tables -list them -delete them -see contents of them -more information, more to do -other topics as necessary 6. Work with a real TA/students to see their problems. -Charles Soletti? -John Lepingwell, Bill Unkel? -Bill Saphir (student) 7. Work with BB&N to see what could be turned into a permanent vendor document. 8. Conduct one review cycle that encompasses projects, consulting staff, and regular athena staff. 9. Format text with Scribe. Print masters on Imagen. 10. Deliver source and formatted master. Subject: postps source Reply-To: poto@ATHENA.MIT.EDU Work: Intermetrics, 733 Concord Ave. Cambridge MA (617) 661-1840x4533 [About /mit/poto/postps :] The rt.dir and vs.dir directories are where the compilation happens for the rt and vax respectively, thus keeping the .o and executables separate. This is simply a hack so that doing a 'make vs' or 'make rt' on the ~/postps directory will build the right thing. This is a hack and is by no means a good way to set it up, just the way I did it. Jose' //\ Subject: guide for writing man pages during yet another trek through linda's jason files, i ran into a document from 9/84 about how to write man pages. i think it might be valuable update it so dan can give it to watchmakers. (i don't know who should do the updating; i'm certainly willing.) here's a copy of it (it's /mit/docsourc/archive/Dclass/manpage.mss): @device(imprint10) @make(report) @definefont(Userfont, 1=, 2=) @modify(CopyrightNotice, Fixed -1 inch, Flushright) @Modify(Titlebox, Fixed 2.5 inches) @Style(Font computermodernroman10) @Style(spacing 1,indent 0) @Style(LeftMargin .5inch) @begin(Titlepage) @Begin(Titlebox) @begin(Text,Flushright,Font Userfont, FaceCode 1) Manual Page Composition @end(text) @blankspace(.25inch) @End(Titlebox) @begin(researchcredit) @Tabset(4.2inches) @begin(format,Font Userfont, FaceCode 2) @\Will Doherty @\MIT Project Athena @\Revision A @\September 7, 1984 @end(format) @end(researchcredit) @CopyrightNotice(Massachusetts Institute of Technology) @end(titlepage) @Set(page=1) @Begin(MajorHeading,FlushRight) Manual Page Composition @end(MajorHeading) @Tabset(4.2inches) @begin(format,Font Userfont, FaceCode 2) @\Will Doherty @\MIT Project Athena @\Revision A @\September 7, 1984 @end(format) @Section(Introduction) Project Athena manual pages exist to give users an idea of what programs we maintain on our machines and how to use them. Because programmers at Bell Laboratories and the University of Berkeley developed most of the Unix@foot(UNIX is a trademark of Bell Laboratories) operating system we use, most of our manual pages come from those two sites. However, some manual pages come from other development projects. The unformatted system versions of manual pages appear in the @b[/usr/man] subdirectories named @b[man1] through @b[mann], to indicate the part of the manual the program described by this manual page occupies. The formatted system versions of manual pages appear in the @b[usr/man] subdirectories named @b[cat1] through @b[catn], to indicate the part of the manual the program described by this manual page occupies. A program called @b[catman], which accesses @b[nroff], produces the formatted system versions (in @b[/usr/man/cat*]) of the unformatted manual pages (in @b[usr/man/man*]). If, after reading this guide, you still have questions about manual pages, contact Linda Merims, E40-431, x3-1368, lbm@@jason, or Will Doherty, MIT E40-426, X3-1300, wdoherty@@jason. @Section(nroff and troff) We format manual pages using programs called @b[nroff] and @b[troff]. We now use @b[nroff] to format on-line and hard-copy manual pages. We will use @b[troff] for phototypesetting hard-copy manual pages on the Imagen printer. @b[nroff] and @b[troff] take files chock full of wierd formatting commands and produce a pretty finished product. We use a macro package called @b[an] to add special commands to the regular set of @b[nroff/troff] commands. To call @b[nroff] on an unformatted manual page file, you could type: @Center(@b[nroff -man] unformat-file @b[>] format-file) The @b[-m] calls the macro and the @b[>] format-file directs the formatted output into a file. @Section(Manual Page Guidelines) To prepare a manual page for @b[nroff/troff] processing, you should follow these guidelines (some of them are specific to Project Athena): @begin(itemize) All manual pages should include all of the following, and only the following, section identifiers whenever possible: @b[Name, Synopsis, Description, Files, See Also, Diagnostics, Bugs], @b[Authors,] and @b(Restrictions). A brief description of these section identifiers appears in a chart below. Manual pages in Part 2 of the Project Athena documentation set often should contain two other section identifiers: @b[Return Value] and @b[Errors]. Write clearly and concisely. Pretend that you are an inexperienced user reading your manual page and attempting to use the program as you read. Have others review your work by trying to understand the program given the manual page. If you can't decide how to format a particular manual page, look at manual pages for similar commands for some helpful hints. @end(itemize) @Section(Section Identifiers) @begin(format,Leftmargin +1inch) @Tabset(1.50 inch,+14) @b[Section Identifier@\@=Description] @&_ @b[Name]@\Program name, dash, and a concise description @\that appears in the @b[/etc/whatis] file for use @\by the @b[apropos] command. @b[Synopsis]@\Program name, options, and arguments-- @\the syntax of the program, similar to a usage @\comment @b[Description]@\A more lengthy description of the program, @\its options and arguments. This section @\still concise though. Add subsections to @\organize descriptive information clearly. @b[Files]@\All files related to this program that users @\may find of interest. @b[See Also]@\All other programs related to this program @\that users may find of interest. @b[Diagnostics]@\Information of user for debugging @\errors in the program or for dealing with @\error conditions that result from the use @\of the program. @b[Bugs]@\A list of "bugs"--errors in the program @\not yet fixed, or never to be fixed. @\Uncommon usages or results of program. @b[Authors]@\The author(s) of the program and @\a brief history of its development. @b[Restrictions]@\Rules about copying the software. @\Usually for proprietary software. @end(format) @newpage @Section(Generic Pre-Format Manual Page) Here is a sample manual page (hypothetically stored as @b[/usr/man/man1/program]) before formatting with @b[nroff]: @begin(flushleft) @begin(format,Leftmargin +1inch) .TH PROGRAM 1 "August 1984" {Page head and foot} .FM mit {Project Athena-specific} .SH NAME {Section heading} program \- sample manual page .SH SYNOPSIS .B program {.B = bold} [ -abc ] filename... {options, arguments} .SH DESCRIPTION .I program {.I = italic} is an artificial command used to show how to write manual pages. .I program doesn't really do anything. .PP {New paragraph} @i[program] has three options: Options: .TP 6 {This is a hanged indent starting at column 6.} .B \-a {Use the \ before strange chars like -, \, etc.} This option does nothing. .TP 6 {Hanged indents are a good way to .B \-b organize options on a man page. The null option. Look at the post-format version below .TP 6 to see what hanged indents look like.} .B \-c Useless. .SH FILES Here you put a list of files related to .I program. .SH "SEE ALSO" {Multi-word section heads require quote delimitiers} Manual and other commands that are relevant. .br {line break} nonprogram(1), noncommand(5) .SH DIAGNOSTICS This section should describe the diagnostics you could use to check the operation of .I program. This is especially useful for descriptions of compiler error messages. .SH BUGS Infinite therefore not listed. .SH AUTHORS Joe Schmoe, Random Programmer, and Lusing Hacker .br Ported from University of Berkeley. @End(format) @end(flushleft) @newpage @Section(Generic Post-Format Manual Page) Here is a sample manual page (hypothetically stored as @b[/usr/man/cat1/program]) after formatting with @b[nroff]: @begin(flushleft) @Begin(format,Leftmargin +1inch) PROGRAM(1) UNIX Programmer's Manual PROGRAM(1) NAME program - sample manual page SYNOPSIS program [ -abc ] filename... DESCRIPTION @i[program] is an artificial command used to show how to write manual pages. @i[program] doesn't really do anything. @i[program] has three options: -a This option does nothing. -b The null option. -c Useless. FILES Here you put a list of files related to @i[program]. SEE ALSO Manual and other commands that are relevant. nonprogram(1), noncommand(5) DIAGNOSTICS This section should describe the diagnostics you could use to check the operation of @i[program]. This is especially useful for descriptions of compiler error messages. BUGS Infinite therefore not listed. AUTHORS Joe Schmoe, Random Programmer, and Lusing Hacker Ported from University of Berkeley. MIT Project Athena 1 August 1984 @End(format) @end(flushleft)