General Overview of OpenAFS
The CNF fileservers run OpenAFS (just AFS for short).
AFS (Andrew File System or A File System) is a distributed file system. The top
directory of the AFS hierarchy is the same all over the world, and is /afs.
Every institution in the world with AFS fileservers has its own unique "cell"
subdirectory under /afs. CNF's cell is named "cnf.cornell.edu" and is located at
/afs/cnf.cornell.edu
Within a cell, files are located on fileservers and are grouped within entities
named volumes. Volumes are partition of physical disks (of the data servers), in
which quotas are applied. Backups of data can also be performend on a per-volume
basis. And, data on readonly volumes can be replicated across multiple
fileservers.
Authentication
To have full access to AFS, you need to get a token. You will get tokens
automatically when logging into a CNF windows or linux machine with your Cornell
netid or guestid.
Your token has a limited lifetime, which is 8 hours at CNF. To check your
token's expiration date, do the following:
Windows
Click the lock icon in your system tray. Select the "Tokens" tab
if it is not already selected. If there is no lock icon in your
system tray, from the Start Menu, choose All Programs, OpenAFS, then
Authentication.
Linux
From the "Applications" menu, choose "afstokens". Your tokens are
displayed in the box labeled "My AFS Tokens".
Or from the commandline, type "tokens" to see your tokens.
General
You can both destroy your existing tokens and obtain new tokens using the above
Windows and Linux applications.
When obtaining new tokens, if using a Cornell netid, your username must be
formatted as:
netid@CIT.CORNELL.EDU (@CIT.CORNELL.EDU must be all caps).
If using a Cornell GuestID, your username must be formatted as:
guestid@GUEST.CORNELL.EDU (@GUEST.CORNELL.EDU) must be all caps.
Access Control Lists
An Access Control List (ACL) is the AFS mechanism which let you access
directories and files. This access mechanism works as follows:
*base permissions apply to directories (not files)
*new sub-directories inherit from parent directory permissions
*files have no individual protection. They inherit the protection from
the directory they sit in.
ACLs are composed of pairs [ protection group or user, access rights ]. For
example, grp_users (the group of all users) might have read permissions on a
particular directory.
Access Rights
There are seven access rights. Four deal with directories:
*a (administer) : right to administer of the ACLs of this directory
*l (lookup) : right to list the content of the directory
*d (delete) : right to delete files or sub-directories
*i (insert) : right to create new files or directories
The three others, while set on the directory, apply to the files within the
directory:
*r (read) : right to read a file
*w (write) : right to write in a file
*k (lock) : right to lock a file
Some aliases of the above ACLs:
*read = rl
*write = rlidwk
*all = rlidwka
*none = no right at all
Unix group and other mode bits on files are ignored.
Protection Groups
There are several pre-existing AFS protection groups:
*system:administrators
whose members are the AFS administrators of the current cell
*system:anyuser
every user, being or not authenticated within this cell or another cell
*grp_all
everyone who has an account on our fileserver
*grp_staff
all CNF staff
*grp_users
all CNF users
*grp_it
Your friendly CNF IT staff
*cnfhosts
Every computer on the CNF office and lab networks (but not on RedRover)