Porting Athena to New Unix Workstations

Geer/Zolot

October 18, 1989

1 Background

Project Athena brings about a method of distributed computing by providing specialized software and network services to (at present) two Unix workstation platforms: DEC (VAX and DECstations) and IBM (RT/PC). Here we examine the prospect of expanding our hardware platform.

2 The Four Levels of Analysis

The porting of Athena to new Unix workstations is an issue with (at least) four faces, each of which is the topic for a section of this document.

• The Components

• The Software Mods

• Maintenance

• Project Management

The Components describes the hardware and software required in order for a workstation to be eligible for an Athena port.

The Software Mods describes the software modifications needed to make the above components behave properly.

Maintenance discusses long-term support issues, and addresses the feasibility of convincing vendors to adopt our mods into their future releases.

Project Management is where we look at the present initiative being undertaken at MIT by IS, Athena (and others). We raise questions to determine who should set priorities and allocate resources for the Athena-porting effort.

2.1 The Components

Processor Athena’s original design was based upon a machine capable of running at least 1 MIP, though the market is largely delivering processors considerably more powerful than that (3-10 MIPS). In addition, demands for sophisticated user interfaces have raised a much higher constant (background) demand for those cycles.

Memory At least six megabytes of memory are needed to properly support a non-trivial user. One could get by with four megabytes, eight would be nice. This should be backed by at least 16Mb of swap, though 20-32Mb would be sufficient to remove swapping as a rate limiter in normal operation.

Local Disk At present we support “dataless” (not “diskless”) workstations; local disk storage is kept to a minimum, and exists to prevent consuming network bandwidth for swapping. The typical local disk contains about 15 mb of system software, plus swap and cache space which can be configured as needed. A 70mb local disk is quite sufficient.

Operating System The scope of this analysis is deliberately limited to workstations running a “recognizable” UNIX. Athena was developed under Berkeley Standard Distribution (BSD) 4.3, and has been ported to derivations of 4.3 (ULTRIX, IBM AOS).

X Window System The X window system is a network-transparent, vendorindependent way of controlling the display of the workstation. We require X11R3, or later release.

C Compiler A standard C compiler is needed. On the VAX side we have used PCC, and on the RT side we have used HC 3.1 and 2.1-S. We are optimistic that a change to gcc (from the Free Software Foundation) is desirable and feasible.

Network-driving Software Most of the network software requires the Berkeley SOCKET interface, or something similarly capable of driving TCP/IP.

Sun NFS Sun’s Network File System is one of the two methods in use for transporting files across the network. NFS 3.2 is required; 4.0 is desirable. Athena’s mods to this software require source code access to nfs server.c.

AFS The Andrew File System is the second method of transporting files across the network, and has many features which make it preferable to NFS. A choice between the freeware (CMU) and commercial (TransArc) forms must be made.

2.2 Software Mods

Authentication To provide authentication in the open network environment, we have introduced the Kerberos authentication service. Modifications were required to UNIX programs such as mount, login, and the r∗ family of remoteconnection utilities. Modifications were also required to NFS and AFS. As a general rule, modifications to accommodate Kerberos are required on both the server and client sides in portions of the code that get invoked whenever connections are established. These include kernel level modifications that cannot be simulated by placing a layer on top of binaries.

Name Service (Hesiod) Athena’s name service is layered on Berkeley BIND 4.3, so a workstation that can run BIND requires some trivial modification. A version for 4.8 BIND is in preparation.

Mail (POP) Athena’s mail delivery system is based on the Rand Mail Handler (MH) v6.6. Both the Post Office Protocol (POP) server and MH clients require minor modifications to accommodate authentication and name service.

Notification Service The Zephyr notification service consists of standard software which should run on any UNIX platform, though it presupposes the presence of Kerberos (authentication) and Hesiod (name service).

Network Address Assignment The Network Information Protocol (NIP) is an Athena creation. It provides a means of acquiring an IP address at boot time, and expects support from other network clients. (Here, this support comes from the gateways.)

net booting ?

attach Athena’s attach program is a layer on top of UNIX’s mount, and incorporates name resolution and authentication into a mount request. attach exists to provide a coherent, “no-unnecessary-details” interface to the file service as a whole.

Palladium Print Service The Palladium Print Service is an Athena implementation of an ECMA/ISO standard for print systems. A full featured, modern print system, it offers authenticated accounting and a robust management model.

Service Management (Moira) For a service to be manageable by Athena’s central service management tools, that service must be able to take its management instructions from a standard ASCII file. Our service management package will tailor an ASCII file to fit the specifications of the service and will deliver that file as needed.

The above constitute the core set of Athena essentials. Next we discuss several Athena-developed application programs and system utilities that greatly enrich the service environment:

OLC The On-Line Consulting (OLC) system is a rendevous mechanism, connecting an individual with a question to another individual with the answer. Intended for the naive user, OLC permits a bootstrap operation for nearly any type of use difficulty in the Athena environment. The server side of OLC also provides a stock answer browser and management and q.a. related logging of transactions. The availability of the Kerberos authentication system, the Hesiod nameservice, and the Zephyr notification system are prerequisites for the operation of OLC.

Discuss Discuss is a multi-user, location transparent, server arbitrary conferencing system modelled on the old Multics forum system. A button-and-mouse interface also exists, but is inherently inferior as it cannot catch the full flexibility of the command line interface. Configured by individual systems managers, a user need not know the location of the service. The supported user interface is lowest common denominator, purely a command line interface, but a button and mouse interface is in preparation.

Delete/Undelete Inadvertent user deletion of files is frequent, time-consuming to someone, and ameliorable. The delete/undelete suite of programs (including five others) provides a renaming and subsequent garbage collection paradigm for the file deletion functionality, as contrasted with the unlink-now paradigm of the the current rm command. Using these new programs, a period of recovery is provided, but in a manner consistem with toal fileserver disk acreage management. The syntax and normal-mode semantics of the standard rm command can be preserved through the use of suitable aliases.

OLH The OLH system is a complete access to help services for the distributed computing environment. It includes both character and display oriented user interfaces, and references both static (text) and interactive help services (such as OLC, vide supra). Its user interface is, of course, transparently easy to use. Providers of services can attach their help system to the global OLH dynamically, such as at the time of the initial service connection, without any requirement of central administrative overhead.

Pickup/Turnin The file exchange system is intended to mimic operations normally performed with paper in and out of class. There are files which represent assignments handed in, and annotated assignments handed back. There are files which represent handouts produced by the teacher which are taken by the students as reference material. Finally there are files submitted for exchange, as one might trade papers for peer review. The file exchange system consists of programs for students to run, and other programs for graders to run.

Shell changes The basic shell known as the C shell (csh) is the user interface of default or choice, depending on opinion, in the BSD environment. Athena has made moderately extensive changes to the command line operation of the C shell mimicing a Tenex shell known as the T shell. These changes are made to a product owned only by UCB, not AT&T, and can be distributed in difference form if required. All the Athena user community uses this modified shell, as do many persons outside that community.

listmaint lib.com err is a simple library for regularizing the assignment of error codes and their interpretation in text across complex applications. lib.ss is a simple library for building applications with command line interfaces intended to be consistent across the various applications. Both of these combine with libraries from the Moira service management system to form listmaint, a program that permits the average user to interact with the Moira database. Listmaint provides a low-level user interface a network connection module for this purpose.

2.3 Maintenance

Many of the above systems require source-level modifications to vendor-supplied software. To properly support a workstation, one would have to be prepared to repeat this modification each time the vendor produces a new software release. Furthermore, vendor support would be complicated in that one would need to isolate the source of a failure before assuming that it is the vendor’s responsibility, especially if one has mucked around in the vendor’s kernel sources.

How have we handled that up till now?

What to do about this in the future?

What would vendors have to do to support us without our having to have the source to and/or modify their code?

2.4 Project Management

We estimate that a full port would take two person-months, and that any one of the Athena components would take one person-week. By “person” here, we mean an experienced UNIX system programmer. Obviously, each subsystem brings with it its own areas of required expertise.

Who’s gonna staff this?

Who’s gonna decide which machines to port to?

Who’s gonna support the users of these machines?

Who’s gonna negotiate with vendors?