AFS at CSAIL

AFS at CSAIL

AFS is a distributed file system that uses Kerberos for authentication. AFS is cross-platform compatible, has built-in redundancy, fault-tolerance, high availability, and backup/restore management. Plus, it supports a much more granular access control model than standard UNIX modes, including user-defined access groups and even unauthenticated/anonymous access if desired.

The CSAIL AFS cell, csail.mit.edu, is available on any system with AFS software installed and an internet connection. For the convenience of lab members, TIG runs a public login machine login.csail.mit.edu with AFS configured. Access is via SSH (either via Kerberos tickets or by entering your CSAIL Kerberos password when prompted).

Using AFS at CSAIL

• AFS Basic Use
• AFS Access Control
• AFS Protection Groups
• Cross Realm Authentication

Installing AFS

• OpenAFS Installation for Windows
• OpenAFS Installation for Mac OS
• OpenAFS on non-CSAIL Ubuntu Linux

Filesystem Layout

Beneath /afs/csail.mit.edu contain the top level CSAIL AFS directores. The ones you are most concered with are:

• u: User home directories are stored under this hierarchy. All CSAIL users with a Kerberos principal and INQUIR database entry have an AFS home directory. Your u: home directory is also where your http://people.csail.mit.edu/you/ is hosted.

• group: Contains data shared between members of a research group. If other members of your group use data stored in your personal home directory, it’s probably a good idea to move it into the group directory instead. We’ve found this helps with personnel transitions (for example if you go and graduate or something.) It is also where your groups’ groups.csail.mit.edu/GROUPNAME is hosted.

• proj: Contains shared data for projects that cross reearch-group boundaries and where your projects’ projects.csail.mit.edu/PROJECTNAME is hosted. proj also contains the /courses for academic specific courses.

Also beneath /afs/csail.mit.edu is:

• @sys: There is not actual @sys subdirectory; @sys is translated into the local host’s architecture and operating system (e.g., i386_linux26). Directories named after the output of this command are used to hold operating system and architecture specific binary files.
• common: Shared files useful on multiple architectures. Currently this only includes configuration example files. In the future it could contain multi-platform scripts and licensed software that runs on multiple platforms