\documentstyle[fullpage,psbox]{article}
\title{Report of the Layered Athena Team}
\author{Bruce Lewis - Team Leader}
\date{June 1, 1995}
% adjust how figures are inserted
\renewcommand{\topfraction}{.9}
\renewcommand{\bottomfraction}{.9}
\setcounter{totalnumber}{4}
\renewcommand{\textfraction}{.1}

\begin{document}\sloppy
\maketitle
\tableofcontents
\newpage

\section{Introduction}

In the fall of 1992, DCNS Development initiated the Layered Athena
project, with two major motivations: To make it easier for private
workstation owners to use Athena, and to make it easier to port Athena
to new platforms.  Of these two, the hope of easier Athena ports was
probably the motivation for management to devote key resources to the
project.  Another goal of that fell out of the above goals is actually
identifying what Athena is.

This report details the extent to which Layered Athena has met these
goals, and serves as compilation of knowledge that has been gathered
from the efforts of the Layered Athena team, most recently Kevin
Cunningham, Bruce Lewis, John Morey, and Naomi Schmidt.  We owe much of
the knowledge herein to people who have been active on the team,
particularly Carla Fermann and Mark Rosenstein.

\subsection{Summary of Recommendations}

\begin{description}

\item[] {\bf Ports to New Platforms}

\input{rec1}

\item[] {\bf Layered Athena for Private Workstations}

\input{rec2}

\item[] {\bf Conceptual Models of Athena}

\input{rec3}

\end{description}

\newpage\section{Layered Athena Can Expedite Ports}

At the beginning of the Layered Athena project, it was hoped that a new
model for software installation could replace the current model, which
is development-intensive and time-consuming.  The Layered Athena team
has come to understand that the current model for installation is not
yet ready to be replaced, because Layered Athena does not meet the
requirements detailed in section 4.2.  However, Layered Athena is still
useful as an interim installation procedure before machines are
installed in public clusters.

A timeline for a non-layered port can look something like this:

\begin{verbatim}
                                           cluster deployment
DCNS dev:                                  |
srvd    aabbccbcccbccccbcccccbccccccbcccccc|bbbccc
inst1   ---------aaaabbbbcbccbcccbccccbcc--|
inst2   -------------------------aaaabbbbcc|dd
Non-DCNS dev:                              |
srvd    ---------------------cbbbccbcbccbcc|cbcccc
lockers ---------------------------aabbaabb|aabbaa
\end{verbatim}

In this timeline, the symbol (-) means nothing is done, (a) means
development work, (b) means finding and fixing bugs, (c) means use, and
(d) means documentation.  The port starts with developers doing the
simplest task, which is building system packs (srvd).  After the srvd
has undergone some developer testing, it needs to be installed on
several non-developer machines for further testing, and so that key
personnel can familiarize themselves with the new platform.

To install these machines, it isn't necessary to have a procedure that
fits all of the cluster group's requirements, so an intermediate
procedure is developed (inst1).  Depending on what roadblocks are
encountered, this procedure can take as long to develop as the final
install procedure.  It may need handholding, meaning a developer needs
to be involved in every installation.  This can take a significant
amount of developer time away from debugging the srvd and writing the
final install procedure.

As the time approaches to put machines in the clusters, the final
install procedure (inst2) must be written.  Because of the load on
developer time up to this point, inst2 is saved until the last minute,
and finished just in time.

Courseware, applications and tools in various lockers need to be
compiled on the new platform.  Unfortunately, groups such as ACS, CSS
and SIPB don't get the srvd software until relatively late in the game,
and must scramble to get everything working.  It's expected that a lot
of locker software just won't be ready until well after the new machines
are deployed in clusters.

Layered Athena makes possible a totally new timeline:

\begin{verbatim}
                                           cluster deployment
DCNS dev:                                  |
srvd    aabbccbccbbcccbbccccbbccccccccccccc|cccccc
layer   ----abc----c----c-----c------------|
inst2   ----------aaaabbbbccdd-------------|
Non-DCNS dev:                              |
layer   -------c---c----c-----c------------|
srvd    -------cbbbccbcbccbccccbccccccccccc|
lockers -------------aabbaabbaabbaabbaabbbc|bcbccbccc
\end{verbatim}

After the initial srvd has been built and lockers can be attached,
porting Layered Athena to a new platform takes less than a week.
(Later, when a vendor introduces a new OS version with binary
compatibility, the Layered Athena software developed for the previous
version should continue to work with little or no modification.)

New machines other than the ones developers are using should be
delivered with the native operating system pre-installed.  The Layered
Athena GUI can then be run without any developer assistance to install
srvd software, and to easily take updates as they become available.

As a result, the srvd gets more testing sooner, developers are freed up
to work on the final install procedure, and work on locker software can
begin long before machines hit the clusters.

The initial srvd need not be complete.  Login, the most difficult part
of the srvd, is not essential for private workstations.  The native
login can be used, along with a script called {\tt login\_athena} which
includes all the elements of an Athena tty login.  Users get their usual
prompt, shell, PATH, aliases, etc., and can port locker software in the
environment to which they have become accustomed.

\subsection{Recommendations}

\input{rec1}

\newpage\section{Don't Promote Layered Athena at MIT}

Over the years, Athena has established high expectations in the user
community regarding support.  In the Layered Athena world, it becomes
difficult to meet these expectations, especially when the platform is
not found in Athena clusters or in offices of user support groups.
Setting realistic expectations is of major importance whenever Layered
Athena is deployed.

Support groups need to be made aware of any deployment of Layered
Athena, and will need a plan to properly handle the inevitable
questions.

Some headline issues the Layered Athena team encountered are:

\begin{itemize}

\item How do we set realistic expectations?

\item How do we prepare and coordinate those who directly support
testers?

\item machines and tools for adequate support

\item feedback / data collection

\item timing / scheduling

\item proactive support (documentation, etc.)

\item vendor support in a layered world

\end{itemize}

It should be noted that the beta testers of Layered Athena did not
demand much support, but they are probably not a sufficiently random
sample of the MIT community for us to conclude that others will be like
them.  People who agree to a beta test tend to have lower expectations,
and to be more knowledgeable.  The six principal non-I/S beta testers
were all graduate students or staff.

\subsection{Recommendations}

\input{rec2}

\newpage\section{Athena's Components Demystified}

The Athena environment is a very complex entity.  Any attempt to
completely define it is likely to be full of gaps.  For example, one
might forget the network services that must be available, or the
knowledge that must exist in support groups for customers to get the
kind of service to which they have become accustomed.

However, the work done in Layered Athena makes it possible to answer the
question, ``What software makes a Unix workstation into an Athena
workstation?''  A similar question is, ``What development work needs to
be done for an Athena port?''

These questions become very important when we begin to look into new
models for the Athena computing environment.  A picture of the
components of this environment make it easy to point out how a new model
is and isn't different from our present model, thus making it easier to
estimate how much more or less effort will be involved in the ``new
model'' port.

An Athena port has three main software components:

\begin{enumerate}

\item Athena software on system packs, i.e. /srvd

\item Install - software to install an Athena workstation

\item Locker software

\end{enumerate}

Layered Athena deals primarily with the anatomy of the system packs, but
the other components are described here for completeness.  Forgetting
the about installation process is a grave error if one wishes to put a
new Athena platform in public clusters.  Forgetting locker software
shows that one is out of touch with the expectations of the Athena user
community.

\subsection{The System Packs}

Layered Athena was designed to allow private workstation owners to
choose which parts of the Athena systems packs they would like to
install.  To achieve this, it was necessary to come up with a division
of the system pack into subsets that were meaningful to users, and to
determine what subsets depended on what other subsets.  Figure 1
illustrates this division.

\begin{figure}[htbp]
\begin{center}
\PSbox{/mit/layerdev/doc/depend3.ps}{6.5in}{6.0in}
\end{center}
\caption{Subsets of the srvd with dependencies}
\end{figure}

\begin{description}

\item[Kerberos]

This subset installs or modifies the necessary configuration files for
support of Kerberos v4 clients.  It installs basic clients, {\tt
kinit, klist, kpasswd, rkinit, ksu}, and the utility programs {\tt
ksrvtgt} and {\tt ksrvutil}.  It does not require modifying system
startup files.  The Kerberos subset could easily be extended to include
Kerberized applications such as telnet and rlogin, providing an
easy-to-use solution for private workstation owners who want to protect
their passwords, but don't want any other Athena software.

\item[AFS]

This subset installs configuration files and the AFS cache directory,
and modifies system startup files so that AFS is started on reboot.  It
also installs the utilities {\tt aklog, unlog, fs, pts}, and {\tt vos}.
If a private workstation owner wants to get at files in AFS (which
includes virtually all Athena lockers), the Kerberos and AFS subsets are
enough.

\item[Basic Athena Services]

Many Athena services are so simple and unintrusive that they can be
packaged together in one subset, even though there's a wide variety of
functionality.  These services include hesiod, zephyr, moira, online
consulting, global message of the day, kpop email, authenticated
printing, and attach.

To ease use of these services when the login subset is not loaded, a
script called {\tt login\_athena} is included which will allows the user
to get tickets, Athena home directory, zephyr, and any other necessary
setup.

\item[X]

The Athena X subset includes the standard X11 clients as we compile
them.  For newer Unix platforms, this subset is unnecessary, as vendors
have largely caught up with Athena in terms of X releases.

\item[Login]

This subset runs the Athena login program on the workstation.  This
means that anyone with an active Athena account can login to the
workstation unless access is specifically restricted.  This subset
includes a lot of interaction with the base operating system, and is
typically the most difficult part of compiling system packs for a new
platform.

\item[Emacs]

This subset includes {\tt emacs} and its libraries and utilities.  Many
private workstation owners would like an easy way to install emacs
without having to compile it themselves, even if they don't want any
other Athena functionality.

\item[Man]

This subset includes the man pages for all Athena programs and on some
platforms, a modified {\tt man} program as well.  In the future, man
pages may be bundled with the other subsets rather than be separate.

\item[Tex]

This subset provides the \TeX\ and \LaTeX\ formatters and associated
utilities.  Like emacs, it is a third-party package some private
workstation owners may want, even if they don't want any other Athena
functionality.

\item[Andrew]

The subset provides {\tt ez} and other applications built on the Andrew
Tool Kit.

\item[Applications]

This subset contains Athena applications that don't fit into the ``Basic
Athena Services'' or other subsets.  They are small, easily-ported
programs, so that it's convenient to lump them together into one subset
despite the wide range of functionality provided.  Applications include:
{\tt olh, delete, mh, rcs, tcsh, eos, imake, notes}, kerberized remote
access, {\tt discuss, dash, perl}, and much more.

\item[Development]

This subset contains the libraries, include files, and other tools
necessary to write programs that use the Athena basic services.

\item[Public]

This subset was never implemented.  It would handle automatic updates to
new releases, etc.  It was hoped that one day Layered Athena would
reduce the effort needed to create an install kit for public
workstations, however, the current Layered Athena paradigm cannot
satisfy the requirements for that installation process, because it does
not reinstall the base operating system.

\end{description}

\subsection{The Installation Process}

As most readers of this document know, about 400 Athena workstations are
maintained by a staff of 5.  For this reason, the traditional Unix
installation process is far too cumbersome.  Not only do new
workstations need to be installed en masse during a short period during
the summer, but hacked or non-functional workstations need
reinstallation.  DCNS-cluster does roughly 140 reinstalls per semester.

A reinstall usually involves inserting the install media, typing a small
number of configuration variables (e.g. IP address), waiting for the
install media to pop out, and then letting the installation process
continue over the network.

To keep this job manageable, the following times must be kept small:

\begin{enumerate}

\item Time until done typing.  The native install procedure for most
versions of Unix involves a lot of typing, and there's no way to
parallelize this task without hiring more people.  For current
platforms, staff spend less than two minutes on this stage of a
reinstall.

\item Time until the install media pops out.  The sooner the install
media pops out, the sooner the installation of another workstation can
begin.  For current platforms, this takes anywhere from 5 to 20 minutes.
DEC 3100's, DEC 5000's and SGI's do not require install media; they do
the entire installation off the net.

\item Time until the installation process finishes.  If everything goes
well, it's acceptable for this stage to go on for hours.  However, when
something goes wrong, it is necessary for a staff member to sit in front
of the workstation and watch the install process happen to find out
what's breaking.  Current platforms take about 45 minutes to finish
installing themselves.

\end{enumerate}

Until these requirements change, any new public workstation platform
will need an install procedure.  This has always been one of the most
difficult parts of Athena ports.

For more details on Athena installation, see the file
\verb$/mit/opdoc/install/software.install.overview$ on Athena.

\subsection{Locker Software}

ACS and CSS keep track of what locker software is most important.  See
\verb$/mit/release77/WhatShouldRun$ on Athena for details.  Users also
expect software from a variety of lockers to be available, notably the
sipb and graphics lockers.  When porting to a new platform, it is
advantageous to make it available to the SIPB as soon as possible.

\subsection{Recommendations}

\input{rec3}

\end{document}
