Hi there. I know you mentioned athena.mit.edu as one of the cells you
looked at, but I figured I'd give a bit of an explanation in an effort
to clarify the madness in our method. =)
The top of the cell is purely for gross high-level logical divisions;
there's no software installed at that level. Under
/afs/athena.mit.edu we have:
activity/X/name - student activity group volumes, X is the
first letter of name.
astaff - Athena staff work volumes
contrib - volumes given out to other groups to
"contribute" software by installing it in AFS.
course/NN/NN.MMM - academic course volumes, NN is the department
number and MMM is the course number. (At MIT,
all courses are referred to this way.)
dept - space leased from us to independent departments
org/X/name - every group on campus is guaranteed a basic
amount of web-publishing space. This is where
those volumes go unless the group has space
somewhere else. X is the first letter of name.
project - volumes for projects under development
reference - mostly read-only volumes - OS sources, RFCs,
documentation...
service - operational "services" provided by us, and
cell-wide configuration. The site CellServDB
is in there, as well as mountpoints for
volumes restored from tape.
software - volumes for third-party software packages
system - "system packs". Athena includes a master OS
image as well as a volume of standard software
that gets layered onto the machine at install
time. Also includes Athena environment-wide
configuration.
user/X/Y/username - user homedirectories, X and Y are the first
and second letters of the name.
Partially orthogonal to this is the concept of "lockers". A locker is
a named set of dirs and files, referenced by a hesiod database.
(There's nothing special about hesiod; one could use NIS or LDAP just
as easily; it's just that we were doing hesiod first.) In this day
and age, a locker is usually an AFS volume or collection of volumes,
but it can also be an NFS server/path combination. (It could even
theoretically be a directory inside an AFS volume, but we try to avoid
that for organizational reasons.) When a locker is in AFS, the locker
name dereferences to an arbitrary path in AFS. So the "consult"
locker maps to "/afs/athena.mit.edu/contrib/consult". Lockers can
even be in other cells.
Installed software that's not part of the default Athena binary image
(stored in /afs/athena.mit.edu/system/...) goes into lockers. Where
the locker is in AFS is determined by who owns the space and who
maintains the software. The internal structure of the locker is up to
the maintainers, though there are some standards.
The main principle of organization of software lockers is that any
architecture-specific data should be buried under an "arch/@sys"
directory. So binaries go in .../arch/@sys/bin, architecture-specific
libraries go in .../arch/@sys/lib, and so on. Shared files can go
straight into the locker, like .../man.
Users access software in lockers using a couple commands, "add" and
"attach". "attach", when given a locker name, looks up the locker in
hesiod, and "mounts" it on /mit/lockername. (In the case of AFS, this
"mount" is just a symlink to the AFS path. In the case of an NFS
locker, "attach" actually mounts the appropriate NFS directory there.)
"add" is a shell alias in the default user dotfiles which does:
eval `/bin/athena/attach -Padd $add_flags !:*`
(or something similar in the bourne shell). "attach -Padd" will first
attach a locker as described above, and then output the appropriate
csh (or sh if you use -b) to extend the user's PATH and MANPATH to
include the locker's man directory and arch/@sys/bin directory. In
addition, if arch/@sys/bin doesn't exist, it starts looking for @sys
values which are backwards compatible to feed to the user. So if a
user on a sun4x_56 box tried to add a locker, "attach -Padd" would
first look for .../arch/sun4x_56/bin, then arch/sun4x_55/bin, then
arch/sun4m_54/bin, sun4m_53, and even sun4m_412.
[aside: While we happen to use AFS @sys values for those dir names, we
bend over backwards not to depend on the string '@sys' actually being
magical. All the mapping is done by "add", so a user's path gets a
literal like "/mit/consult/arch/sun4x_56/bin", not
"/mit/consult/arch/@sys/bin". Thus, we could pick up an AFS locker
and drop it into NFS-land, and it would still Just Work transparently
to the user.]
>From a user perspective, all they have to do to look at an arbitrary
locker is:
attach lockername
cd /mit/lockername
And to use software in an arbitrary locker:
add lockername
program
"attach" and the locker scheme abstracts away the AFS path (and, in
fact, the whole filesystem -- it was conceived before we were even
using AFS), making it simple for users to find things. Thus, user
homedirectories and other similar volumes are also lockers, though
they are rarely used to install software. And since users only ever
need to think about the locker name, we're free to organize the top
level of the cell by our own organizational whims.
Source for "attach" is in
/afs/dev.mit.edu/source/src-current/athena/bin/attach. More thorough
documentation of the locker directory conventions is in
/afs/dev.mit.edu/source/src-current/packs/dotfiles/lockers.7.
Mike Whitson
MIT/IS Athena Server Operations
