AFS: Here, There and Everywhere.

Febuary 12, 1996

This is an outline of the ACM talk about AFS and Kerberos.

AFS:

AFS is the Andrew File System developed at CMU, and now maintained, developed and sold by Transarc (http://www.transarc.com/). It was named after Andrew Carnegie, co-founder of Carnegie Mellon University.

AFS is distributed. That is, the files and databases sit on multiple machines on the network.

Overview of AFS:

In AFS there are three classes of machines:

1. Clients, which run afsd and have some kernel patches.

   This is the part you've seen. Some of you have installed linux, or netbsd clients.

2. Fileservers, which run processes to answer volume and fileserver request.

3. Database servers, which run processes for:
   • kaserver : Kerberos database for authentication,
   • ptserver : Protection database for access,
   • vlserver : Volume database for locating volumes, and
   • buserver : Backup database for locating tape backups.

Note, that it is possible for a machine to be both a fileserver and a database server, and run the AFS client.

At RPI, we have 10 fileservers, three of which are also database servers. A (usually) up-to-date list of RPI's fileservers can be found at: http://www.rpi.edu/~sofkam/fileservers.html.

Note, the client machines only need to know about the database machines.

A collection of fileservers running with the same database servers is called a ``cell.'' At rpi, our cell is called ``rpi.edu.''

AFS, however, is truly global. By doing an ls of /afs you can see all the cells your workstation knows about.

The database servers for cells is located in a file called CellServDB , and is updated periodically from transarc.

Volumes, mount points and ACLs.

AFS stores volumes on a partition. Volumes have separate owners and quotas. They can be freely moved between fileservers. (Think of them as collections of files).

To access a volume, however, it must be mounted someplace in the /afs/rpi.edu tree. This is done with the

fs mkmount <dir> <volume>

The mount point is like a symbolic link. When you enter a directory that is a mount point, the client asks the vlserver for information about where that volume is located.

The client also asks the ptserver if you have access to the volume.

Access is controlled by Access Control Lists attached to each directory.

• r ead: Read contents of files.
• l ist: List files in directory.
• i nsert: Insert files into directory.
• d elete: Remove files from directory.
• w rite: Write to existing files.
• lock : Lock files.
• a dminister: Change ACLs.

ACLs are set with:

fs sa <directory> <principle> <permissions>

• read = rl ,
• write = rlidwk ,
• all = rlidwka ,
• none = no permissions.

The RPI memo 114 has information on ACLs and pts groups. (located in /dept/its/ic/tex/rpi114.dvi ).

There are also negative ACLs, that remove permissions previously granted with positive (normal) ACLs.

Two exceptions to ACLs:

1. system:administrators have implicit la access.

2. The volume owner (user, in the case of home volumes) has implicit la access.

UNIX user permissions mask the ACL permissions. The unix group and other permissions are ignored!

Protection (pts) entries.

ACLs contain entries from the protection database. These can be principles (users) or groups. Groups have negative ids.

The protection database is edited via the pts command.

pts creategroup <owner:group> [<owner>]
prt creategroup <group>
pts member <user or group>
pts exam <user or group>
pts setfields <user or group> <somar bits>

• S tatus: list status information.
• O wned: list groups owned by user or group.
• M embership: list user or group membership.
• A dd: add users to group.
• R emove: Remove users from group.

There are three values for each SOMAR field:

1. hyphen (- ): Only owners have access right.
2. lowercase: members of group have access right.
3. uppercase: everybody has access right.

The default for user is S---- , the default for groups is S-M-- .

Replications and how they work.

AFS also has the ability to replicate volumes. That is, a duplicate of a volume is stored on a different fileserver. These duplications are read-only, and they are not ``mirrors''

Replications provide:

1. Reliability. If the server with one replication goes down, the other replications are still accessible.

2. Speed. The access to heavily used volumes are spread out over several fileservers (and networks).

There are Three types of replications:

• Clones : readonly volumes located on the same file partition as the read-write volume. (backups are a special type of clone).

• Replicants : replications on a different fileserver in the same cell.

• Backup volumes : clones with copy-on-write flag.
  • Mounted as ./yesterday .
  • Backed-up by the AFS backup command.

  At RPI, the backup volumes are made at 6:00 am the morning of backups. It is this volume, and not the active volume that is locked and written to tape.

Note that Clones require only a separate AFS header, but contain links to the actual data. If the clone is accessed instead of the read-write volume the server does not need to maintain callbacks (check the cache terminology).

When first created, backup volumes also consist of a header, with pointers to the same data. But, the files are marked ``copy on write.'' Each time you modify a file, it is first copied to the backup volume.

Replications are updated by the vos release command, which copies changes from the read-write volume to the read-only volumes.

Kerberos:

Kerberos is an authentication mechanism that allows a client to authenticate via a third party (the Kerberos server) without the password every going over the network in the clear.

A good description of how it works can be found in Scientific American, November 1994 in an article by Jeffrey Schiller.

MIT versus AFS Kerberos. The differences are in:

• String-to-key function,
• Format of token/protocol,
• Default ticket lifetime.

Since version 3.3 AFS's kaserver has supported AFS kerberos on port 7004, and MIT Kerberos on port 750. But, the different hash's require a password change. The coming synthesis (i.e., RPI switching to MIT kerberos served from kaserver ).

Kerberos V. Not much to say really. Its a slightly different protocol/format then Kerberos IV, but at least the string-to-key is the same. Kerberos V comes with a Kerberos IV translator.

DCE/DFS:

Some advantages of DCE/DFS.

• DCE/DFS is the OSF standard, and has more vendor support for servers and clients (including Windows, Windows NT, OS/2).

• A DCE cell may be broken into multiple administrative domains.

• ACLs are on files.

• UNIX mode bits for user, group and other are used to mask DFS ACLs.

• Token (AFS ``callback'') handling is enhanced to provide the same update semantics one would expect from a local Unix file system.

• DFS supports byte-range file locking (AFS is cache chunk-size range).

• Backup filesets (AFS backup volumes) take up less space because only the modified blocks of a file are copied, rather than the entire file.

• The DFS fileserver processes run in kernel mode rather than in user mode. This allows asynchronous access to disks, and should improve performance.

• The DFS/AFS translator provides AFS clients with access to DFS files. The translator is made for long-term use, and is reported to be very good.

Some disadvantages of DCE/DFS:

• Not available for IRIX, SunOS 4.1.x, or Linux.

• The backup utility is based on the AFS 3.2 backup. (Switch to ADSM negates this negative at RPI.)

• There are no negative ACLs or host-based ACLs.

• Honoring UNIX file semantics can result in phantom filesets. That is, the open file stay behind even after the fileset is removed.

• The /.: and /: links tend to break scripts.

• Multiple vendor DCE utilities are inconsistent.

• Stealth ACLs can result from using UNIX chmod command.

• The DCE Security Server is YAKS (Yet Another Kerberos Server). A ray of light, however, is that the MIT Kerberos and DCE Security Server maintainer are the same person, and he is motivated to merge the two.