[OpenAFS] Directory layout for new cells

[Russ Allbery]

Kelsang Wangden <wngdn@src.uchicago.edu> writes:
> Sam Hartman <hartmans@MIT.EDU> wrote:

>> How common is the arch designation at top-level?  MIT uses system for
>> that at the top-level and arch within package-specific "lockers."

>> If arch is very common, then I'll probably create arch as the
>> directory with system as a symlink.

> IIRC, my co-worker Jon and I decided on "arch" in a brainstorming
> session, so for all I know it's unique to our site.

We use systems instead.

Our cell layout looks vaguely like:

/afs/<cell>/
    class               Course directories
    data                Large data volumes (statistical data sets, etc.)
    dept                University department directories
    dev                 Local source trees and CVS repositories
    dist                Distribution trees (ftp and web)
    group               Student organizations and research groups
    pubsw               Software packages (symlinked into system/@sys)
    service             CellServDB and whatnot
    site                University computing organizations
    systems/@sys        Trees for each sysname
    users/u/s/username  User volumes

Our AFS installation instructions have people create a few symlinks, most
notably /usr/pubsw -> /afs/<cell>/systems/@sys/pubsw.  That directory is a
pure symlink tree, with all of the symlinks pointing into ../package,
which is another mount for /afs/<cell>/pubsw.  In that directory, things
are broken down by class of software (Data, Kerberos, Editors, etc.) and
then by package name with version in the same sort of system that lots of
people use with various different automated tools (I rolled my own).

If we had it to do all over again, /afs/<cell>/pubsw would probably be
called package instead.  /usr/pubsw is a good thing to call the software
tree, though, since "pubsw" has the same number of letters as "local",
allowing us to do binary edits of some vendor software to convince it to
look in the right place even if we can't recompile it (and yeah, we've had
to do this quite a few times).

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>