\documentstyle{article}
\title {\begin{center}
\hspace*{1mm}\special{psfile=owl.PS hoffset=-42}\hspace*{1mm}
\vspace{1cm}
\end{center}
Porting Athena to New Unix Workstations}
\author{Geer/Zolot}
\date{\today}
\begin{document}
\maketitle
\section{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.
\section{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.
\begin{itemize}
\item The Components
\item The Software Mods
\item Maintenance
\item Project Management
\end{itemize}
\begin{description}
\item [The Components]  describes the 
hardware and software required in order for
a workstation to be eligible for an Athena port.
\item [The Software Mods] describes the software modifications needed
to make the above components behave properly.
\item [Maintenance] discusses long-term support issues, and addresses
the feasibility of convincing vendors to adopt our mods into their
future releases.
\item [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.
\end{description}
\subsection{The Components}

\paragraph{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.

\paragraph{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.

\paragraph{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.

\paragraph{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).  

\paragraph{X Window System}
The X window system is a network-transparent,
vendor-independent way of controlling the display of the workstation.
We require X11R3, or later release.

\paragraph{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.

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

\paragraph{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
{\it nfs\_server.c}.

\paragraph{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.


\subsection{Software Mods}

\paragraph{Authentication}
To provide authentication in the open network environment, we have
introduced the Kerberos authentication service.  Modifications
were required to UNIX programs such as {\it mount, login,} and the
{\it r}$\ast$ family of remote-connection 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.

\paragraph{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.

\paragraph{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.

\paragraph{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).

\paragraph{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.)

\paragraph{net booting}
?

\paragraph{attach}
Athena's {\it attach} program is a layer on top of UNIX's {\it mount},
and incorporates name resolution and authentication into a 
{\it mount} request.
{\it attach} exists to provide a coherent,
``no-unnecessary-details''
interface to the file service as a whole.

\paragraph{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.

\paragraph{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.

\vspace{1 cm}
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:

\paragraph{OLC}
The On-Line Consulting ({\it 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.

\paragraph{Discuss}
{\it Discuss} is a multi-user, location transparent, server arbitrary
conferencing system modelled on the old Multics {\it 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.

\paragraph{Delete/Undelete}
Inadvertent user deletion of files is frequent, time-consuming
to someone, and ameliorable.
The {\it 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 {\it 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 {\it rm}
command can be preserved through the use of suitable aliases.

\paragraph{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, {\it 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.

\paragraph{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.

\paragraph{Shell changes}
The basic shell known as the C shell ({\it 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.

\paragraph{listmaint}
{\it lib.com\_err} is a simple library for regularizing the assignment of
error codes and their interpretation in text across
complex applications.
{\it 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 {\it 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.

\subsection{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?

\subsection{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?


\end{document}
