[3059] in Release_7.7_team
Draft of my December 12 Sun talk
daemon@ATHENA.MIT.EDU (Bill Cattey)
Thu Dec 6 19:14:44 2001
Message-ID: <8w40bkVz0001JXD1Ne@mit.edu>
Date: Fri, 7 Dec 2001 00:14:40 +0000 ()
From: Bill Cattey <wdc@MIT.EDU>
To: release-team@MIT.EDU
Enclosed is my 4/5 complete first draft of the talk I intend to give at
the December 12 meeting with Sun I previously announced to this list.
I'm very interested in hearing comments.
Have I thus far answered reasonably the questions asked?
What needs to change?
What should stay the same.
I'm writing as quickly as I can, but the event is less than a week away.
Your feedback is urgently needed.
My plan is to generate slides from the paper, and provide the paper as a
handout along with a page of useful URLs.
-wdc
----
The Once and Future Athena
With Regards to Sun Microsystems
by Bill Cattey
Presented 12 December 2001
----
The Questions:
Five questions were asked. In order of increasing priority:
1. Could an overview history of Athena at MIT, and the great things
that have come out of Athena over the years be given?
2. What are current projects Athena is working on that other higher-ed
customers would benefit from hearing about and that Athena wants to
evangelize?
3. What are novel ways has Athena employed Sun technologies that other
higher education customers may be interested in knowing about?
4. What are success stories of Athena managing large numbers of Suns
across MIT campus?
5. What products, tools, architectures and solutions of interest to
Sun higher education customers have been created by Athena?
----
1. History:
1981: MIT had no academic computing infrastructure.
Project Athena was an experiment to collaborate with IBM and DEC to
create an infrastructure of networked workstations, and investigate
its impact on education.
At that time, the computing models available were:
Timesharing on centrally administered hosts.
PC's
Workstations in workgroups like the Alto and the Lisp Machine, and
the Sun-1.
Athena conceived of an architecture that was to be:
Highly functional for the end user.
Hardware independent and vendor neutral.
Scalable to an entire enterprise.
Ubiquitous.
Coherent across multiple platforms.
The present marketplace shows that such an architecture is indeed
desirable. PC's grew in functionality, and communications capability.
Workgroups got progressively larger. Timesharing transformed into a
much broader approach to providing shared services. Over time, it has
become more difficult to identify a computer isolated from others.
Athena began with DEC and IBM to produce something that for a long
time looked like what Sun was already selling. But there were three
crucial differences:
Platform Independence.
Enterprise-wide scalability
Security
Although every computing vendor these days pays attention to security.
Athena began with the basic architecture of an open network, and a
customer base of clever individuals who could be expected to consider
cracking security a challenge. So MIT remains a source of security
expertise even today.
Athena has had single sign on, location independent computing
school-wide since 1989.
When Athena adopted UNIX as its infrastructure OS, common truth was
that a wizard was required to maintain the OS of every machine, or at
the very least, to clean up any mess that happened within the
workgroup. Athena learned how to leverage one wizard per platform
across an entire enterprise. That wizard creates a partnership such
that:
End users who make no customizations get a system that is,
turn it on and it works. Security updates arrive
non-disruptively.
Departmental administrators who need some customization can
have it and STILL retain central administration of the rest of
the system.
Client systems and server systems, vanilla systems and
customized systems are all installed from a common archetype
that allows low total cost of ownership, ease of fault
isolation, and maximum functionality.
Additionally, the "locker" abstraction enables a rendez-vous point
between end users and an enterprise full of individuals taking
responsibility for administration of software subsystems. Multiple
versions of software packages with explicitly differing sources and
administrators are all available to those who ask. Over time some
subsystems began as individual efforts, and migrated to the centrally
released universe.
Today users demand powerful desktop machines that are in constant
communication with other systems via the network. On these desktop
systems, users demand huge libraries of software which must be must be
functional, repairable, and immune to attack. Athena's approach,
having evolved over time, but with the basic architecture in mind from
day one remains a leader in understanding how to do this correctly and
at minimum cost.
----
2. Current Projects:
Actually, we've been in Maintenance Mode without much in the way of
ground-breaking projects since 1990. In a sense, our current project
is to help vendors like Sun, now that they appreciate the issues we've
lived with, to benefit from what we've learned. Stated another way:
to increase the visibility of our old tried and true developments.
The best motivating example I can give here is Athena Hesiod:
At the same time yp was being developed, MIT approached the same
problem in a different way. Instead of requiring an elaborate,
secure, server, we leveraged BIND to offer name-to-name translations
for 80% of what yp was doing at nearly zero development cost.
Hesiod has not had significant development effort put into it in 15
years. yp has. But the industry, by embracing LDAP essentially
re-implements the design tradeoffs made by the Hesiod service in 1986.
We've our experience is in many areas, and we'd like the MIT version
to get out into the world instead of waiting 15 years to see a
re-implementation eventually take hold.
There are two particular areas of development that have not gotten out
into the world:
Athena Zephyr instant messaging.
Athena install/update.
These are the developments I will talk about in detail later in
the talk.
----
3. Novel use of Sun technology:
Actually we don't make a lot of use of Sun technology, per se. Our
initial start-up in 1981 required us to re-invent a similar beast to
the Sun workgroup. But there were engineering principles that Sun
followed that we followed too:
Stick to simple, open, solutions that have value to customers.
Sun NFS is an example of this principle. Lots of vendors wrote
all-encompasing filesystems that were platform specific. But you
don't hear about them. They didn't achieve the kind of market
acceptance that NFS does. The Athena install system is a lot more
like pkgadd than SGI inst: It's a simple solution without a lot of
cleverness or glitziness.
Applying the Athena understanding to Sun technologies was easy because
we shared that engineering vision. The IBM AIX technology was not a
comfortable substrate to build Athena upon. Nor was SGI IRIX. Both
of those vendors insisted on creating narrow-focused, elaborate,
proprietary, add-ons to vanilla UNIX. We kept having to rip out their
"Value Added" to get systems that would obey our security and
scalability requirements.
The stuff we have done applies equally well to Sun Solaris, or Dell
Linux. Mind you, there are a few areas where cheap Linux is
out-performing Solaris. I've been trying to get a few projects of
under 6 man months in scope accepted by Sun to remedy these issues,
but I've thus far been unsuccessful. Examples: When we went from
track to pkgadd for Solaris installation, install time went from half
an hour to an hour and a half. Converting pkgadd from a shell script
to a C program would correct this. There is also the CNBoot program
that enables enterprise-wide install without requiring a RARP server
on every subnet.
----
4. Success Stories:
Here are three quick success stories:
Everyday use, Solaris 2.1, and Overnight Sensation.
Every day Use:
The biggest Athena success story is how there are over 10,000 users
accounts who walk up to over 1,000 computers fed by 100 servers. The
environment seen by those 10,000 users is independent of hardware or
software platform, and independent of physical location. If there are
patches that went out last night due to a CERT advisory, the 1000
computers quietly got them while nobody was looking. The 100 servers
are running the same packages, and get scheduled downtime to
synchronize with the updates.
A friend of mine works in a law office with 3 IT professionals, and a
couple dozen computers. She tells stories of how regularly nobody can
get any work done because of the network being down, or because of
software problems. Every day 10,000+ users, 1,000+ computers, and
100+ servers just work. We have the occasional disaster, but recovery
is swift, and the MBTF blows away what you get with other models.
Solaris 2.1:
Remember Solaris 2.1? The first version of Solaris certified as
working well enough to give to customers? Everyone here has heard
stories about how some problem with Solaris 2.1 made people very glad
to be very quick to be to Solaris 2.2 and better still Solaris 2.3.
My first major project in my present position was to complete the
1994 equipment renewal: Vax3100's were being replaced with Sun
Classic's running Solaris 2.1. I feared that customers would say I
replaced something working with something broken. But when I went out
into the field and queried, customers were delighted. They said, that
I replaced something slow with something fast, and that it worked for
them. My team was spread sufficiently thin that we did not have the
resources to migrate to Solaris 2.2. We ran on Solaris 2.1 for
approximately two years. But the things we tested, and tuned up to
make work were satisfactory to our customers. We kept hearing, "More
fast Suns!", and very little "Make it more reliable."
Overnight Sensation:
On the night of Tuesday July 24, 2001 we changed the information
Hesiod replied when asked, "Where do ordinary Athena Suns get their
system software?" Over night, several hundred Sun Ultras had
booted a miniroot, replaced the 32 bit Solaris 7 with the 64 bit
Solaris 8. And the next day students, faculty and staff, logged onto
systems and were greeted with a GNOME based desktop, taskbar, and
window manager.
It all just worked. People, when asked, were quite pleased with how
smooth the transition was, and how much easier the new interface was
to use.
These are my ideas of Athena success stories.
----
5. Developments:
A functional view of Athena:
Single Sign on with location independence
Enterprise-wide file service
Install/Update
principles
push computation to the end node.
create scalable services
minimize total cost of ownership
minimize hand work
make central administration attractive
have customer-centric updates
permit distributed software administration
workstation as FRU
SERVER as FRU
be platform independent
Hardware independent
OS independent
filesystem agnostic
understand issues of security
reality of the open network
disable superfluous services
encrypt where required
make secure portions small and auditable
infrastructure pieces
kerberos
hesiod
moira
update scripts
login library
attach library
tools
larvnet/athinfo
end-user functionality
zephyr
olc
discuss
