The following paper was originally published in the Proceedings of the Twelfth Systems Administration Conference (LISA ’98) Boston, Massachusetts, December 6-11, 1998 Anatomy of an Athena Workstation Thomas Bushnell, BSG Karl Ramm, MIT Information Systems For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: [email protected] 4. WWW URL: http://www.usenix.org Anatomy of an Athena Workstation Thomas Bushnell, BSG and Karl Ramm – MIT Information Systems ABSTRACT This paper presents work by many developers of the Athena Computing Environment, done over many years. We aim to show how the various components of the Athena system interact with reference to an individual workstation and its particular needs. We describe Hesiod, Kerberos, the locker system, electronic mail, and the software release process for workstation software, and show how they all interrelate to provide high-reliability computing in a very large network with fairly low staffing demands on programmers and systems administrators. Overview typing a few lines into a PROM monitor and perhaps inserting a floppy to install a workstation, and from The Athena system is an integrated campus net- then on it will not only install itself, but also automati- work of Unix workstations for academic computing at cally update itself for years as the Athena system MIT, comprising thousands of workstations and hun- develops and changes, all without needing any manual dreds of servers. We manage Athena with a fairly rea- intervention. sonably sized central staff. Workstations are located in public clusters managed by the central staff, in private The purpose of this paper is to describe some of clusters maintained by various academic departments, the key Athena services that hold this arrangement in faculty or staff offices, in public hallways and lob- together, from the standpoint of an Athena workstation bies, in dormitories, in libraries, and laboratories. and its maintenance. Many important Athena features, Most of these computers are available to any member such as the Zephyr messaging service or the extensive of the MIT community (it is in this sense that we use courseware developed at MIT, are not described here. the term ‘‘public’’ in this paper – MIT does not pro- vide any computing facilities for the general public). Hesiod An Athena workstation is a typical Unix work- Key to the operation of the Athena environment station which can provide a platform for users to run is the Hesiod directory service [Hesiod]. Hesiod pro- their applications: sending and receiving email, run- vides directories for many different things, such as ning courseware, text editing and formatting tasks, and filesystems, users, printers, and post office servers. so forth. Much that an Athena workstation does is Hesiod lookup is done through the Domain Name Sys- done locally as on any other Unix computer. Much is tem, by requesting TXT records. Originally we used provided by contacting servers over the network. the separate class HS, but now we store the records in Servers do not trust the integrity of the workstation or the IN class. In this way, large databases need not be its software which thus enables users to run their own replicated across many machines, which significantly Athena workstations, and us to publish to the entire reduces administrative overhead and risk. Athena community the root password for public work- For example, each user in the Athena environ- stations. ment has a password file entry stored in Hesiod, as In this environment, Athena handles most secu- shown in Example 1. (Note that the actual password is rity issues by the strategy of serial reuse: a given user not stored in Hesiod; user authentication is provided logs in, and has full and total control over the worksta- by the Kerberos system, as described below.) tion. Then she logs out, the workstation cleans itself Each of the tables managed by Hesiod has a up in preparation for another user, and then waits until name; the one above is the ‘passwd’ table. Each user another user logs in and has total control. We do not also has a post office box assigned on one of many attempt to fully address simultaneous-use problems, possible POP servers; the ‘pobox’ table in Hesiod is except in special cases. used to determine on which post office server a given Because Athena workstations are located in such user ’s mail should be found. For example, the ‘pobox’ a diverse array of places, and because there are so entry for one of us is: many of them, they are managed in a way to require POP PO8.MIT.EDU tb almost no intervention from the cluster maintenance Programs which need to read the database use library staff. A workstation requires a certain ineradicable functions which issue properly formatted DNS amount of hardware support. Beyond that, it requires requests to the normal DNS servers, which respond tb:*:7722:101:Thomas Bushnell BSG,,E40-342d,31368,6230654:/mit/tb:/bin/athena/tcsh Example 1: Sample Hesiod password file entry. 1998 LISA XII – December 6-11, 1998 – Boston, MA 175 Anatomy of an Athena Workstation Bushnell and Ramm with the requested entry. The libraries then dissect the space of identification names and a secure facility for DNS reply and return the desired entry. mutual authentication using those names. Athena One disadvantage of this mechanism is that servers and workstations then use the Kerberos system many user programs must be modified to issue Hesiod to make authorization decisions. library calls at the proper places. For example, any A Kerberos name is composed of two parts, a program that fetches mail from the mail spool must name and a realm. The name is composed of multiple have code added to request the identity of the post separate strings, but no interpretation is imposed by office server from Hesiod. In some cases this problem Kerberos itself on the contents and relation of those can be ameliorated: the Athena login process, for strings to each other. (In the older version 4 of Ker- example, fetches the password file entry for the user at beros there were exactly two strings in the name, one login and temporarily stores it in the password file on called the ‘‘principal’’ and one called the ‘‘instance.’’) the local workstation, so that other programs can sim- A realm identifies indirectly the servers and authoriza- ply call getpwnam and have it work. tion scope of the name. Each system using Kerberos Very similar functionality is provided by the NIS must maintain a table mapping realm names to the service designed by Sun Microsystems. However, associated Kerberos servers. Hesiod is different in several important respects. First, Kerberos servers function by creating entities and perhaps most importantly, it uses the very well- known as ‘‘tickets.’’ A ticket is an encrypted data tested DNS infrastructure, including caching, and does block specifying a Kerberos name, a time stamp, an not depend on the broadcast characteristics of net- expiration stamp, the Kerberos name of a service, and works as NIS does. NIS is generally used to handle a secret key. By presenting the ticket to the named ser- information which needs to be secure, but in the vice, the service can be assured that the presenter has Athena environment, Hesiod is never used for such the claimed identity. Such services might be POP information and other services are responsible for servers, file servers, telnet servers, and so forth. The security. ticket is encrypted using a key known only to the NIS databases can be completely downloaded; server, and the key contained in the ticket is also this ability is fundamental to the operation of NIS. known by the client. In order to use a ticket success- However, Hesiod never depends on this functionality, fully a client must also know the secret key, and so and BIND makes possible various kinds of discrimina- sniffing the ticket in transmission does not help an tion on what kinds of zone transfers should be permit- attack. A secret key together with its associated ticket ted. (Because of privacy considerations, we do not is known as a ‘‘credential.’’ permit arbitrary downloading of the Hesiod tables.) One important service is the Kerberos server Hesiod can be easily extended to support new itself. Tickets for the Kerberos server are called database types with little effort, but NIS maps are ‘‘ticket granting tickets.’’ Possession of tickets for a basically limited to the default set. file server allows you to use the fileserver, and posses- The current implementation of Hesiod limits sion of tickets for a post office server lets you retrieve responses to 1K bytes, but nothing in the actual proto- mail (in both cases, of course, subject to further autho- col has such a limitation. One serious disadvantage, rization on the server). Possession of a ticket granting however, is that Hesiod cannot be updated dynami- ticket, however, lets you obtain tickets for any other cally. NIS also has problems in this area. As a conse- service you desire. Users obtain ticket granting tickets quence, MIT generates the Hesiod databases once a when they log in, upon proving to the Kerberos server day, and updates them overnight. that they possess a correct password. From that point, the ticket granting ticket is used as necessary to obtain Hesiod will automatically be able to benefit from service tickets for the various servers the user needs. DNSsec and once a standard for dynamic DNS updates is approved (one is on the IETF standardiza- These credentials (tickets and associated client tion track now), Hesiod will be able to easily take keys) are conventionally stored in a file in /tmp.