\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}