\documentstyle[fullpage,psbox]{article}
\title{Layered Athena Design}
\author{Mark Rosenstein}
% adjust how figures are inserted
\renewcommand{\topfraction}{.9}
\renewcommand{\bottomfraction}{.9}
\setcounter{totalnumber}{4}
\renewcommand{\textfraction}{.1}

\begin{document}\sloppy
\maketitle

This document describes the overall design of Layered Athena---how we
expect to implement it in the current Athena environment.  The
document does not stand alone.  For a summary of the scope and
requirements for the project, read {\em Athena Layering Requirements}.
This document also assumes the reader is somewhat familiar with the
current (1993) Athena environment, particularly the services and
delivery mechanisms.

The design discussed in this document is intended only for Unix
platforms.  While the terminology and high-level concepts will also
apply to personal computers, this level of design is very much Unix
specific.  We will address PCs and Macs at a later date.

\section{Architecture}

Overall, Layered Athena will look a lot like {\tt mkserv} in terms of
how it works.  Layered Athena will be distributed as a filesystem very
similar to a regular Athena system pack, with an added directory of
configuration files and programs to implement Layered Athena.  There
will be a simple command line based client which does all of the work,
handling installations, removals, and updates.  Both a graphical user
interface and an friendly ASCII interface will be written as a
front-ends for the simple client, but will not duplicate the actual
guts of the code.

There are two different kinds of things to be done: set options and
manipulate subsets.  The options affect how and when subsets are
loaded, immediate configuration changes of the workstation, and the
eventual functioning of the subsets once they are running.  The
options are:
\begin{itemize}
\item Handling of updates---whether to auto-update when a newer
version is available, or just to send an email notification that an
update is needed
\item Who to notify about system maintenance, such as the availability
of new versions
\item When the last message requesting an update was sent to the
workstation owner mentioned above.  This is necessary so that they do
not get messages once an hour.
\item If the owner has acknowledged notification of an update request,
and does not want to receive further notices about this particular
version (they will start again anyway when the next release is
available).
\item Whether to allow monitoring of the workstation configuration via
SNMP
\item Where an additional copy of the configuration information is
stored.  A local file is always maintained, but a remote copy may also
be kept up-to-date.
\item If this workstation is centrally registered---should I/S be
informed in an automated manner about configuration changes of this
workstation?
\item Local customization scripts: the workstation may have
customizations to the standard Athena software
\end{itemize}
For each subset, several options are recorded:
\begin{itemize}
\item Subset status: ignored, use it remotely, copy it local
\item Version: what version is currently loaded
\end{itemize}
These settings are stored in a configuration file on the local disk.
This is a flat ascii file with a format similar to that described
below for subset configuration.  This file will be placed in a
``Layered Athena directory'', such as {\tt /var/athena} although it
will be different for different vendor operating systems.  Any other
state that must be remembered is also kept in files in this directory.

The graphical client has dialogs to set each of these options.  The
standard client implements them by registering and storing the
configuration if requested, copying any necessary files to the local
disk with {\tt synctree}, then running scripts to finish the
installation and/or customize the subsets.  Eventually {\tt mkserv}
options should be supported and run during an update as well, but this
will not be attempted for the first phase.  {\tt Mkserv} must fail
gracefully if attempted on a Layered Athena workstation.

Some subsets and configurations require boot-time support.  This is
handled by an {\tt rc.athena} script.  This script handles the initial
activation of the workstation.  A reactivate script also needs to be
run occasionally.  This will be done hourly through cron, and the
script will check to see if anyone is logged in before doing anything
disruptive.  Reactivation of a private workstation consists of
checking for any needed updates, changing the attached system pack if
the hesiod information changes, updating AFS cell configuration,
detaching lockers attached by users no longer logged in, and resetting
zephyr locations for logged out users.  If the workstation is running
the Athena login program, then password and group file cleanup must be
performed as well.

\subsection{Communication}

Layered Athena makes information available to the workstation owner, to
Athena operations personnel, and to anyone polling the workstation.

Much of the communication is email based.  This is a potential problem
because email may not work on the workstation, either because the
vendor or system manager did not configure it properly for the MIT
environment.  When this system sends mail, it will invoke {\tt
sendmail} with an alternate configuration file that is likely to get
the mail to the mailhub under most circumstances.

Messages are generated to the workstation owner when new software
versions are available.  The ``owner'' is identified when Layered
Athena is installed, and may be an individual or a mailing list.  If
the workstation is allowed to auto-update, it will do so, and just
send a single piece of email confirming the update.  Otherwise, it
will send a piece of email requesting the manual update.  This email
will not be from {\em root}, but will instead use a special return
address to collect info about bounced notices.  The message can
contain some release notes extracted from the release.  If the
workstation does not get updated, it will repeat this message once a
week until it is updated.  The owner may ``acknowledge'' the message
and quit receiving reminders until the next version is available, even
if the workstation does not get updated.

Unless the workstation owner specifically requests anonymity, Layered
Athena will also send a message to Athena operations when it is first
installed, and when it updates or the configuration is changed.  This
will be in the form of an email message containing the all of the
Layered Athena configuration information for the workstation.  The
message will be sent to an address which archives these into a database.
This database will allow us to help the workstation owner with
problems, and give us an idea of how people are using Layered Athena
in the field.

Finally, the workstation configuration is available via SNMP to anyone
who queries for it.  We will add several new variables to the Athena
MIB to report this.  Access to these variables may be turned off in
the configuration for those workstation owners who do not want to
allow others to find out what software is on their workstation.  When
the SNMP agent scans the Layered Athena configuration file, it will
check that it is OK to report as well as getting the configuration.

\section{Subsets}

There will only be a small number of subsets.  However, quite a bit of
information needs to be available about each subset:
\begin{itemize}
\item What other subsets it depends upon
\item The disk space required to install it
\item What files are in it
\item Whether it is installable on the local disk, usable from a
fileserver, usable without any installation or privileges, or any
combination of these
\item What special actions are necessary to install it
\begin{itemize}
\item So that it can be installed on the local disk
\item So that it can be used from a fileserver
\item So that it can be used once without any installation
\item If a reboot is necessary after installation or update
\end{itemize}
\item What special actions are necessary to remove it
\item What is the version of this subset
\end{itemize}

Most of this information goes in a simple configuration file.  This
configuration file is flat ASCII, with the following format:
\begin{verbatim}
% Lines beginning with percent are comments
% (blank lines are ignored)

% Entries that start with a keyword, followed by a colon.  The
% remainder of the line is the value for that keyword.  Multi-line
% values are handled by starting successive lines with whitespace.

% The long name of the subset, for display purposes
subset: Subset Name
% The approximate size in Kbytes if copied to the local disk
localsize: 1500
% The approximate size in Kbytes required on the local disk if the
% subset is used remotely
remotesize: 50
% Any subsets that must be present before this subset can be used.
% They are in a comma separated list.
dependencies: kerberos, basic
% Where it can be installed
locations: local, fileserver, transient
% A version number for the subset.
version: 4
\end{verbatim}

Subset version numbers are integers which increase each time the
subset changes.  Somewhere else we will keep a mapping of which subset
versions are in a particular syspack release.  What's missing from
this configuration file is the {\tt synctree} configuration and the
install and remove shell scripts.  These go in separate files.

\subsection{Packaging}

There are two paths we could follow for the packaging of the subsets.
We could keep them in a filesystem such as the current system packs,
or we could store them in an archive such as {\tt tar} or {\tt dump}
format.  Using an archive format is more efficient in disk space and
time to read all of the contents back for an installation.  On the
other hand, we need a filesystem hierarchy anyway to allow people
remote access without copying everything local.  If this filesystem
hierarchy could be an actual Athena system pack, then it requires no
or little additional disk space to make a release also available as
Layered Athena.

One way then to identify the files making up a subset is to use a
subscription list or other similar mechanism to describe portions of a
larger hierarchy.  We will use {\tt synctree} for this because of the
flexibly of its rules files.  If we find that we need something more
efficient and/or network friendly, {\tt synctree} can be enhanced to
use statfiles full of checksums similar to the way {\tt track} does
now.  We recommend {\tt synctree} over {\tt track} even without this
because it is more flexible and easier to port.

There are two different actions that {\tt synctree} implements here.
Subsets can be copied local, or made available locally while remaining
on the fileserver.  Rather than require two different {\tt synctree}
rules files, we will only use one but it gets run through the {\tt m4}
macro pre-processor before it is used.  We use {\tt m4} rather than
{\tt cpp} because {\tt cpp} behaves too differently on different
platforms, particularly with newer C compilers where it does
tokenizing.  The name of each subset being used will be defined, as
will an operation variable which is either ``link'' or ``copy''
specifying whether the subset is to be copied local or symlinked in.
The rules files for each subset in use will be concatenated together
and fed to synctree to actually do the copy.

So a subset will consist of a system pack and several files: the
configuration file, a {\tt synctree} rules file, an add script, and a
remove script.

\subsection{Contents}

Here we examine the actual subsets in more detail.  Note that several
of these subsets include additions to the {\tt /etc/services} file.
In the event that there is already an incorrect entry for a service,
we will overwrite the bad information.

Many of the subsets depend upon other subsets.  Figure 1 shows these
module interdependencies.

\begin{figure}[htbp]
\begin{center}
\PSbox{/mit/layerdev/doc/depend2.ps}{4.5in}{3.5in}
\end{center}
\caption{Subset dependencies}
\end{figure}

\subsubsection{Kerberos}

This subset includes the necessary support for Kerberos clients.  It
does not depend upon any other subsets.  It provides the following
end-user applications: {\tt kinit, klist, kpasswd, rkinit, ksu}, and
the utility programs {\tt ksrvtgt} and {\tt ksrvutil}.  These files
are copied or symlinked into {\tt /usr/athena/bin}.  The files {\tt
/etc/athena/krb.conf} and {\tt /etc/athena/krb.realms} will always be
copied local.  The file {\tt /etc/services} will be edited to contain
entries for {\em klogin, kshell, erlogin, kerberos, kerberos\_master},
and {\em passwd\_server} if they are not already present.

\subsubsection{AFS}

This subset adds AFS client filesystem support to the workstation.  It
requires the Kerberos subset.  The largest user visible addition will
be the {\tt /afs/...} hierarchy will be visible.  The applications
{\tt aklog, unlog, fs, pts}, and {\tt vos} will also be added.  Disk
space will be allocated for the cache, the system startup files will
be modified, and it may be necessary to install a new kernel as well.
The implementation of this subset will vary from platform to platform.

\subsubsection{Basic Athena Services}

This subset requires that Kerberos be installed as well.  It includes
support for hesiod, zephyr, moira, online consulting, global message
of the day, kpop email, printing, and attach.  This includes the
following end-user applications: {\tt zwgc, zwrite, zctl, moira,
blanche, chpobox, mailmaint, listmaint, olc, get\_message, from, inc,
lpr, lpq, lpquota, attach, detach, } and these utility programs {\tt
hesinfo, zhm, zinit, zlocate, zstat, fsid}, and {\tt movemail}.  These
files are copied or symlinked into {\tt /usr/athena/bin}.  The file
{\tt /etc/services} will be edited to contain entries for {\em
zephyr-srv, zephyr-clt, zephyr-hm, sms\_db, sms\_update, sms\_ureg,
globalmessage, kpop, lpallow, lpquery}, and {\em lplog} if they are
not already present.  It requires the following configuration files to
be on the local disk: {\tt /etc/resolv.conf, /etc/named.boot,
/etc/named.mit}, and {\tt /etc/athena/attach.conf}.

Installing this subset will interact with nameservice on the
workstation, since hesiod is implemented with the {\em named}.  The
rest of the subset will not be a problem.  The printing utilities will
fallback to using the local {\tt /etc/printcap} if the specified
printer is not in hesiod, so it will work with a local printer.

To ease use of these services when the login subset is not loaded, we
will include a {\tt login\_athena} script which will prompt the user
for their kerberos password and get them tickets, start zephyr, attach
their locker, and any other necessary setup.

Once Basic Athena Services are installed, users on this workstation
will have access to Athena lockers and third party software.  This
access does not mean that they have licensed or paid for the use of
this software.  When the policy issues are decided, it may become
necessary to display and get positive feedback about licensing when
this subset is installed.


\subsubsection{X}

The Athena X subset will include the standard X11 clients as we
compile them.  This subset does not depend upon any other subsets.  It
may duplicate some of what the vendor provides.  We will install our
clients in {\tt /usr/athena/bin} rather than {\tt /usr/bin/X11} to
attempt to avoid conflicts.  On some platforms, the X subset will
include a server as well.  On such platforms, the appropriate server
for the hardware will be installed in {\tt /etc} and symlinked from
its usual name to {\tt /etc/X}.

\subsubsection{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.  It requires the
Athena Basic Services and X subsets.  Besides the Athena login screen,
the end user will see the applications {\tt chsh, chfn, show\_console,
hide\_console, config\_console, session\_gate, logout}, and {\tt
/bin/athena/tcsh}.  This subset also includes {\tt rlogind} and {\tt
telnetd} for network logins.  Other necessary local files include {\tt
timeout, dm, xlogin, console}, and a number of files in {\tt
/etc/athena/login}.

Installing this subset will also cause {\tt /etc/ttys} or {\tt
/etc/inittab} to be edited to start up the login program.

\subsubsection{Emacs}

This subset includes {\tt emacs} and its libraries and utilities.  It
does not depend upon any other subsets.

\subsubsection{Man}

This subset includes the man pages for all Athena programs and on some
platforms, a modified {\tt man} program as well.  No configuration
files are required.

\subsubsection{Tex}

This subset provides the \TeX\ and \LaTeX\ formatters and associated
utilities.  This subset does not depend upon any other subsets.  It
includes the applications {\tt tex, latex, slitex, virtex, dvi2ps,
xdvi, dvitype}, and {\tt bibtex}.  It also includes a large number of
font and macro files.

\subsubsection{Andrew}

The subset provides {\tt ez} and the other applications built on the
Andrew Tool Kit.  On some platforms it will require the X subset, on
others the vendor's X implementation is sufficient to run Andrew.  It
includes the applications {\tt ahelp, bush, eq, ez, ez2ascii, ez2ps,
ezviewer, raster}, and {\tt table}, along with several directories of
fonts, libraries, and help files.

\subsubsection{Applications}

This subset contains most of the Athena applications, other than those
specifically mentioned above.  It requires the Athena Basic Services,
and the X subset is recommended.  Some applications will not run
without those subsets loaded.  Some of the more notable applications
include: {\tt olh, delete, mh, rcs, tcsh, eos, imake, notes},
kerberized remote access, {\tt discuss, dash, perl}, and much more.
Note that while {\tt olh} may be copied to the local disk, the
documentation database may not be copied local.  Not allowing this
dynamic database to be copied local assures that the information will
not grow stale.

\subsubsection{Development}

This subset contains the libraries, include files, and other tools
necessary to write programs that use the Athena basic services.  It
requires the Athena Basic Services subset since the developer cannot
test what has been written without those services.  Besides libraries
and include files, this subset contains {\tt compile\_et, mk\_cmds},
and {\tt imake}.

\subsubsection{Public}

This subset turns your workstation into an Athena public workstation.
It requires all other subsets as well.  We do not expect to have this
subset ready for the initial release of Layered Athena.

\section{Client Programs}

As described above, there will be three client programs for Layered
Athena.  All of the real work is done by a simple command line
interface which is not intended to be used by end-users.  A graphical
user interface will be written as a front end to make it more user
friendly.  There will also be an ASCII friendly interface for those
without the X Window System.

\subsection{Basic Client}

The basic client, called {\tt layer\_athena} takes all of its
arguments on the command line.  The command format is:
\begin{quote}
{\tt layer\_athena} {\it command [options]}
\end{quote}
where there are six different commands defined and a number of options
depending upon the command.

The {\em set\/} command will set options that apply to all of Layered
Athena.  Any of these settable options may also be used with the other
commands listed below.  Root privileges are necessary to set any
options other than in a {\em use\/} command.  The available options are:
\begin{quote}\tt\begin{tabbing}
layer\_athena set \=autoupdate|noautoupdate \\
	\>owner={\it email@address}\\
	\>location={\it roomnumber}\\
	\>monitor|nomonitor\\
	\>syspack={\it path}\\
	\>save={\it path}|nosave\\
	\>register|noregister\\
	\>custom={\it script}	
\end{tabbing}\end{quote}
If an option is not specified, it will retain its previous value.  The
{\em autoupdate\/} flag controls whether this workstation will
automatically take new software as Athena releases it.  Autoupdates
default to being enabled.  The {\em owner\/} specifies the email
address used for notifications about this workstation.  The {\em
location\/} is purely informational.  The {\em monitor\/} flag
specifies that it is OK for the configuration of this workstation to
be retrieved via SNMP.  This defaults to being enabled.  Use {\em
syspack\/} to indicate the mount point for the Athena system pack if
it is different from {\tt /srvd}.  The {\em save\/} option records
where an extra copy of the workstation configuration should be kept.
The {\em register\/} flag indicates that I/S should be notified about
configuration changes to this workstation.  This also defaults to
being enabled.  The {\em custom\/} option indicates a customization
script that should be run whenever Layered Athena changes anything on
the workstation.

The {\em install\/} command indicates the configuration of individual
subsets.  Root privileges are necessary to use this command.
\begin{quote}\tt
layer\_athena install {\it subset}=local|remote|ignore
\end{quote}
This command indicates, for each subset listed, whether they should be
copied to the local disk, setup so that the subset can be used
remotely, or not used at all.  Many subsets may be specified on the
same command line.  Any subset not mentioned will keep its previous
status.

The {\em update\/} and {\em autoupdate\/} commands have no options.
Root privileges are necessary to use these commands.  They cause the
workstation to update any loaded subsets to newer versions if they are
available.  An {\em update\/} will always do this for all loaded
subsets.  An {\em autoupdate\/} will check if autoupdates are allowed.
If they are, it will update.  If not, it will send an email message to
the owners of the workstation informing them that an update is
necessary.  It will record when it sent this message so that duplicate
messages are not sent, although after each week that the update is
overdue it will generate another message.

The {\em use\/} command allows a non-privileged user to use some subsets
without installing them on the workstation.  The options and syntax
are the same as the {\em install\/}  command.  When a user issues this
command, {\tt layer\_athena} will store its state for this in {\tt /usr/tmp}
instead of the regular path, and will verify that everything is in
place to get some functionality from the requested subsets.  Status
messages will be printed to {\em stderr\/}, and a series of {\tt csh}
commands will be printed to {\em stdout\/} which when sourced will setup
the user's environment.

The {\em status\/} command reports on the current configuration of the
workstation.  It has two options:
\begin{quote}\tt
layer\_athena status verbose|brief
\end{quote}
If {\em verbose\/} is specified, it will print out several lines of
information that are self-explanatory.  In {\em brief\/} mode, it will
display a compressed version of this information on one line.  This
command defaults to {\em verbose\/} mode.

When {\tt layer\_athena} runs, it will first update any configuration
options.  Then it will compare the requested configuration with what
is on the machine, and the version numbers of the available subsets.
From this it will determine if it needs to perform an update.  If so,
it will first run the macro processor to generate a {\tt synctree}
configuration, then run {\tt synctree} to put the files in place, and
finally run any necessary installation scripts.  If it is asked to
perform an auto-update, it will check if anyone is logged in first,
and create {\tt /etc/nologin} to make sure that no one logs in during
the update.  If any of the installed subsets indicate that a reboot is
necessary after update, {\tt layer\_athena} will then reboot the
workstation.

\subsection{GUI Client}

The GUI client uses the X Toolkit and Athena Widgets, and is called
{\tt xlayer}.  Its main screen is shown in Figure 2.  Note that the
buttons across the top activate menus or actions.  The owner and
location should be filled in by the user.  The buttons below that,
``Minimal Configuration'', ``Standard Configuration'', and ``Local
Configuration'' will configure the subsets according to what we
believe will be some popular setups.  The rest of the window contains
a list of the subsets.  Clicking on the ``status'' box following each
subset name will pop up a menu allowing the user to set what should be
done with that subset.  Clicking on the ``Description'' box following
each subset name will pop up a description of what is in that subset.

\begin{figure}[htbp]
\begin{center}\PSbox{/mit/layerdev/doc/gui.ps}{4.4in}{3.5in}\end{center}
\caption{GUI Client Mockup.  Clicking on a description button pops up
a box with the description of that subset.}
\end{figure}

If the user attempts to use a subset without first selecting the any
dependent subsets, a dialog will indicate the problem and offer to
select the missing subsets.  Something similar will happen if a
dependent subset is removed.

In typical usage, it is only necessary to fill in the owner and
location fields, click on the ``Standard Configuration'' button, then
``Do it'', which will ask for a confirmation.  Other less used
functions are found in the pull-down menus at the top.  This includes
having the workstation not announce itself to Athena Operations, and
saving and restoring the configuration from a file.  The wording used
to describe the various privacy options must be considered very
carefully so that most people will choose not to exercise these
options.

This client will know how to read the subset configuration files to
initialize the subset descriptions.  However, it will perform all of
its real work by running {\tt layer\_athena}, the regular client, as a
sub-process.

\subsection{Friendly ASCII Client}

Because one cannot count on X Windows being available, a friendly
terminal-based client also must be available.  This client is called
{\tt layer}.  To be maximally useful without any documentation or
training, this client will display ASCII menus of choices.  These
menus will be printed teletype-style, without the curses library, so
that they may be used in any environment.  As with the GUI client
described above, it will invoke {\tt layer\_athena} to actually do the
work.

It will display a short main menu corresponding to the obvious
functions at the top of the GUI client.  Submenus will handle the less
frequently used options and subsets themselves.

\section{Transient Use}

Transient use of Layered Athena is when a non-privileged user of a
workstation temporarily uses parts of Athena without permanently
modifying the workstation.  While not all parts (or even any) of
Athena may be usable from any given workstation, where possible we
would like to allow users to get at software.

While this could be a useful option, it is not practical to implement
it at this time.  Root privileges are necessary to initially mount the
system pack.  Most workstations would not have a {\tt /mit} directory
for {\tt attach} to use.  It has been said, ``attach {\em is}
Athena.''  Since {\tt attach} is so problematical, it is probably not
worth doing this at all, at least for the time being.

Some services require minor changes to be able to run without any
changes to the local filesystem.  These changes are still useful
without ``transient use,'' as they make the Athena software more
forgiving of configuration errors.  These changes are outlined in the
following section.

\section{Other Changes}

Several Athena services require changes to run without changes to the
root filesystem and without stepping on vendor services.

\subsection{Kerberos}

Kerberos expects to find several things on the local filesystem that
must be handled:
\begin{description}
\item[/etc/athena/krb.conf] Kerberos needs the contents of this file to
function properly.  The options are to hard-code fallbacks into the
programs, or have them look in another place for the configuration
file.  Since hard-coding configuration into program binaries is
generally a bad idea, we will have the library look in several places
for this file.  It will use a search path of:
\begin{enumerate}
\item \$ATHENACONF, where this environment variable names a directory
that may be on a remote filesystem.
\item /etc/athena
\item /etc
\end{enumerate}
Note that the environment variable is searched first so that it can be
used to test alternate configurations on an otherwise properly
configured workstation.  Also note that the environment variable will
be ignored if the real and effective UIDs do not match.  This avoids
introducing a security hole in setuid programs.
\item[/etc/athena/krb.realms] This file will be handled the same as {\tt
/etc/athena/krb.conf} described above.
\item[/etc/athena/srvtab] Machines without Kerberos permanently installed
have no business providing service and have no need for a srvtab file.
\item[/etc/services] If is likely that the {\tt /etc/services} file
will not contain all of the necessary port numbers.  The kerberos
library will be changed to first look in the local {\tt /etc/services}
file, then try a hesiod lookup of the port number, and finally fall
back on a compiled in value if all else fails.  As an aid in
discovering that the real {\tt /etc/services} file entries are missing
in permanent installations, the fallback code could syslog a warning
if (and only if) the {\tt /etc/athena/krb.conf} file does exist in the
expected place.
\item[/tmp/tkt*] While the ticket files will be created as needed at
runtime, there is the question of cleaning them up at logout.  The
Athena login takes care of this, but nothing is guaranteed to do this
on other systems.  The best way for this to be handled is for the
user's logout file to contain an invocation of {\tt kdestroy}.  The
{\em start\_athena} script could check for this, and offer to add it
for the user if it is not already there.
\end{description}
Another consideration for Kerberos is that the vendor also may provide
Kerberos.  If the vendor's Kerberos is compatible with Athena, then it
is just a matter of making sure that the configuration is correct.
Without root privileges, if the configuration is not correct, there is
nothing that the user can do.  If the vendor's Kerberos is
incompatible, we can have Athena's version first in all search paths,
and hope that the proper one is always found.

\subsection{Hesiod}

Providing hesiod support is somewhat problematical.  One cannot start
a named daemon without root privileges, as it uses a privileged
network port.  We are presented with three cases: the workstation does
not support the domain name system at all, the workstation has a name
server that works but does not support hesiod, or the workstation's
named can support hesiod.  Note that even in this third case, it will
still need to be properly configured.

Given the difficulty in both enabling and configuring hesiod, the best
choice might be to allow class IN queries for hesiod as well as class
HS.  This way only a functioning named is required, with no additional
configuration.  The switch could be handled as an on-the-fly
conversion in the hesiod servers, once the MIT servers are taught to
forward such requests to the hesiod servers.

\subsection{Zephyr}

The only problem with providing Zephyr in this fashion is making sure
that a host manager ({\tt zhm}) is running and that it knows which
Zephyr servers to use.  The host manager can run without privileges,
so it can be started by the {\em start\_athena} script (first checking
that one is not already running).  It will find which servers exist
using hesiod.

\subsection{Port numbers}

Many systems will have to have compiled to check hesiod for the port
number to use if the value is not in {\tt /etc/services}, with
fallback to a compiled-in value if that fails as well.  These systems
include:
\begin{itemize}
\item Moira
\item Global Message of the Day
\item Kerberized Pop ({\tt inc} and {\tt movemail})
\item Kerberized {\tt rlogin} and {\tt rsh}
\item NFS mapping ({\tt attach})
\item OLC
\item Athena network {\tt write}
\item Andrew ahelp
\end{itemize}

\subsection{X}

The X clients will not require any changes.  However, several
environment changes will be necessary.  {\bf XFILESEARCHPATH} will
need to be set to include where the Athena app defaults files can be
found.  The server font path will need to be extended to include our
fonts.

\subsection{TeX}

\TeX\ will require similar changes to X.  The {\bf TEXINPUTS}
environment variable will need to be set to point to the macros
directory.

\subsection{Emacs}

Emacs will require changes to find its lisp library files and sub
programs such as {\tt movemail} and {\tt loadst}.  Some changes to the
lisp startup code could copy certain environment variables to the
appropriate lisp variables when emacs starts.

\subsection{SNMP}

SNMP will be difficult to port to some operating systems.  The vendor
may provide an snmp agent with some vendor-specific features which
should be there.  The problem is that we probably cannot add the
Athena local MIB to this vendor agent, so are faced with the choice of
the vendor's extensions or our agent, which will have our extensions
but may not be able to find some of the basic host information much
less any vendor extensions.

\end{document}

\begin{comment}
This model assumes that the user cannot become {\tt root}.  So the
first problem is getting access to the software itself.  Since one
must be {\tt root} to make NFS mounts, the workstation must already
have AFS available or the necessary NFS filesystem mounted.  Any
attempt to make transient use of Layered Athena will check that the
system pack is somehow readable, and give up if it is not.

Once the system pack is available, most of the subsets are now usable.
A ``start\_athena'' shell script may need to be sourced in the user's
shell to get some environment variables set, obtain kerberos tickets,
start zephyr, and do other initialization.  This script can setup the
user's path since the binaries will probably be somewhere other than
the usual {\tt /usr/athena/bin}.  It will setup variables such as {\tt
\$bindir} which many Athena scripts rely upon.
\end{comment}