[3] in Layered Athena
Layered Athena Requirements
daemon@ATHENA.MIT.EDU (Mark Rosenstein)
Fri Oct 23 12:04:43 1992
Date: Fri, 23 Oct 92 12:03:59 -0400
From: Mark Rosenstein <mar@MIT.EDU>
To: layered-athena@MIT.EDU
DCNS Development is embarking on a project to finally do a layered
Athena. Below is our proposed "requirements" for the project, i.e.
the criterion that a successful implementation will meet. We would
like to get your feedback on these requirements.
Please send any comments to "layered-athena@mit.edu". Anyone may add
themselves to this public maillist, or read the discuss meeting of the
same name.
-Mark
----------------------------------------------------------------
Athena Layering Requirements
Mark Rosenstein
October 19, 1992
There has been much talk of layering Athena on vendor operating
systems, but up until now we have not really addressed this. We must
take the opportunity now to do this as an independant project rather
than be forced into it by small decisions made while porting the
environment to new platforms.
Layering Athena on a private workstation means giving the
workstation owner the option of choosing what parts of Athena to
install. There are a spectrum of possible layerings, from a pure
vendor OS to the current Athena model to copying the entire system
pack and some lockers to the local disk. The workstation owner needs
local control over where on this spectrum his workstation falls and
how and when it recieves updates. One extreme model that may prove
popular is where the workstation owner is not involved at all, but a
user without any privileges temporarily does what is necessary to use
Athena services.
Due to the past difficulty in gathering requirements and
communicating with customers for similar projects, we are taking a
different approach with these requirements. This docu- ment was
produced internally without further data gathering. We are now seeking
comments on it from the potential customers of the layered Athena:
both our own operations groups and users in the wider MIT community.
1.Divisibility: the Athena release should be divided up into
smaller pieces, herein referred to as subsets.
(a) Subsets are logical units which may be a single program or
may include many directories of fonts, libraries, utility
programs, and other support files.
(b) Use of some subsets may require the inclusion of others.
These dependancies must be made explicit.
(c) For convenience, some popular groupings of common subsets
should be created.
2.Placement: the workstation owner should have the option of:
(a) Not having a given subset available at all.
(b) Being able to use a subset that resides on the fileserver.
This may require placing symbolic links or configuration
files on the local disk, while leaving as much as possible
behind on the file server.
(c) Copying all parts of the subset to the local machine.
Note that some subsets, such as those affecting basic networking on
the workstation, may only make sense copied to the local disk.
3.Updates: the workstation owner should have the option of:
(a) His workstation is updated automatically whenever a newer
version of a subset is available.
(b) He is notified that new software is available, but must take
manual action.
(c) He is not ever bothered with updates.
4.Conflicts with Vendor operating system
(a) Whenever possible, we should avoid conflicting with similar
systems provided by the vendor.
(b) If we provide an enhanced version of a program the vendor also
provides, we must not remove the vendor version from the
system, merely rename it or put ours earlier in the users'
search path.
(c) If our enhanced version lacks some feature that third-party
software may rely on, then we cannot move the vendor version
at all.
5.Remembering the configuration: provision should be made for storing
the workstation configuration somewhere stable. This way in the
event of a disk crash, the workstation owner can restore the machine
to its previous state.
6.Tracking: DCNS needs to know what people are using so that we can
provide better service and know when it is safe to decommission old
versions.
(a) The above requirement for stable storage of the configuration
might allow for whatever tracking we need.
(b) Real time monitoring such as SNMP should be able to tell us
what subsets are loaded.
(c) Are there privacy concerns here?
7.Scale: if someone manages a number of similar machines, it should
be possible to configure one, then duplicate that configuration on
the others. If a central database is used to store configurations,
it must easily handle tens of thousands of workstations.
8.Security
(a) For some workstations, only the owner should be allowed to
change the configuration, not anyone who can become root.
(b) Since someone with root privileges can do whatever they want
to a workstation, security only applies to the stable storage
of configurations.
(c) An unprivileged user should be allowed to temporarily use some
Athena software.
9.Licensed Software: Important parts of the Athena software suite are
licensed third party software. It is important that making layered
Athena available not easily allow people to copy licensed software
off campus or otherwise violate licensing terms.
10.Customization: The workstation owner may want a particular subset
with a simple local customization. There must be provision for
running a local customization script at install and update time to
handle changes.
11.User Interface: a user interface must be supplied so that the
average workstation owner can customize their workstation without
calling for help from I/S. This interface must not make any
assumptions about what is already on the workstation (i.e. X
Windows) so that it can run on the raw vendor's software.
As is probably clear from reading the requirements, the solution is
both technical and procedural. In addition to programming the pieces
necessary to pull this together, we will have to document it and
identify how we deal with special cases, how we support customers
using this, and many other things.
