![[Return to Library]](../books.gif)
![[Contents]](../toc.gif)
![[Previous Topic]](../prev.gif)
![[Bottom of Topic]](../bot.gif)
![[Next Topic]](../next.gif)
![[Index]](../index.gif)
This chapter introduces concepts for the AFS file system and defines terms. It assumes that you are already familiar with standard UNIX commands, file protection, file system hierarchy, and pathname conventions.
AFS makes it easy for people to work together on the same files, no matter where the files are located. AFS users do not have to know which file server machine is storing a file, and administrators can move files from machine to machine without interrupting user access. Users always identify a file by the same pathname and AFS finds the correct file automatically, just as happens in the local file system on a single machine.
However, while AFS makes file sharing easy, it does not compromise the security of the shared files. It provides a sophisticated protection scheme.
AFS uses a client/server computing model. In client/server computing, there are two types of machines: server machines and client machines. Server machines store data and perform services for client machines. Client machines perform computations for users and access data and services on server machines. Some machines act as both clients and servers. In most cases, you will work on a client machine, accessing files stored on a file server machine.
AFS is a distributed file system which joins the file systems of multiple file server machines, making files stored on a remote file server machine as easily accessible as files stored on the local disk. A distributed file system has two main advantages over a conventional centralized file system:
AFS hides the distributed nature of the underlying file system from users. Working with AFS files looks and feels like working with files stored on the local machine, except that you can access many more files. And because AFS relies on the power of users' client machines for computation, increasing the number of AFS users does not slow AFS performance appreciably, making it a very efficient computing environment.
AFS acts as an extension of your machine's local UNIX file system. Your system administrator creates a directory on the local disk to act as a gateway to AFS. By convention, this directory is called /afs, and it functions as the root of the AFS filespace.
Just like the UNIX file system, AFS uses a hierarchical file structure - a tree. Under the /afs root directory are subdirectories created by your system administrator, including your home directory.
Other directories that are at the same level of the local file system as /afs, such as /usr, /etc, or /bin, can either be located on your local disk or be links to AFS directories. Files relevant only to the local machine are stored in the local machine filespace, freeing the local machine's disk space for other uses. All other files can be stored in AFS, allowing shared access to and use of those files.
| Note: | You can use AFS commands only on files in the AFS filespace or the local directories that are links to the AFS filespace. |
The cell is the administrative domain in AFS. Each cell is autonomously administered: the cell's administrators determine how client machines are configured and how much file server machine storage space is available to each user.
The organization corresponding to a cell can be a company, a university department, or any defined group of users. From a hardware perspective, a cell is a grouping of client machines and server machines that belong to the same home or local cell. An AFS site is a grouping of one or more related cells. For example, the cells at the ABC Corporation form a single site.
By convention, the subdirectories of /afs are the cellular file trees which contain subdirectories and files relevant to a single cell. For example, directories and files relevant to the ABC Corporation cell are stored in the subdirectory /afs/abc.com.
While it organizes and maintains its own filespace, each cell and each site can also connect with the filespace of the other cells and sites running AFS on the same network. The result is a huge filespace that allows file sharing within and across cells.
The cell containing the client machine you are using is called your local cell. All other cells in the AFS filespace are termed foreign cells.
The disks in a computer are divided into sections called partitions. AFS further divides partitions into subsections called volumes. A volume houses a subtree of related files and directories. The volume provides a convenient container for storing related files and directories. Your system administrators can move volumes from one file server machine to another without your noticing, because AFS automatically tracks a volume's location.
You access the contents of a volume by accessing its mount point in the AFS filespace. A mount point is a special file system element that looks and acts for you like a regular UNIX directory, but tells AFS the volume's name. When you change to a different directory (by using the cd command, for example) you sometimes cross a mount point and start accessing the contents of a different volume than before. You normally do not notice the crossing, however, because AFS automatically interprets mount points and retrieves the contents of the new directory from the appropriate volume. You do not need to track which volume, partition, or file server machine is housing a directory's contents. If you are interested, though, you can learn a volume's location; for instructions, see Locating Files and Directories.
If your system administrator has followed the conventional practice, your home directory corresponds to one volume, which keeps its contents together on one partition of a file server machine. User volumes are typically named user.username. For example, the volume for a user named smith in the cell abc.com is called user.smith and is mounted at the directory /afs/abc.com/usr/smith.
Because individual user home directories are nearly always contained in the same volume, when you change from one home directory to another you often cross volume, partition, and file server boundaries. This is also true for other related groupings of directories.
Because AFS volumes are stored on different file servers, when one file server crashes only the volumes on that server are inaccessible. Volumes stored on other servers are still accessible. However, if the mount point to a volume is stored in a volume on a crashed server, the former volume is also inaccessible. For that reason, volumes containing frequently used directories (for example, /afs and /afs/cellname) are often copied and distributed to many file servers.
Each volume has a size limit, or quota, assigned by the system administrator. A volume's quota, measured in 1 kilobyte blocks, represents the maximum amount of disk space the volume can consume. If you attempt to exceed a volume's quota, you receive an error message. For instructions on checking volume quota, see Displaying Volume Quota.
Volumes have completely independent quotas. For example, say that the current working directory is /afs/abc.com/usr/smith, which is the mount point for the user.smith volume with 1000 free blocks. You try to copy a 500 block file from the current working directory to the /afs/abc.com/usr/pat directory, the mount point for the volume user.pat. However, you get an error message saying there is not enough space. You check the volume quota for user.pat, and find that the volume only has 50 free blocks.
As an AFS user, you work on an AFS client machine. The Cache Manager on that machine is your agent in accessing information stored in the AFS filespace. When you access a file, the Cache Manager on your client machine requests the file from the appropriate file server machine and stores (caches) a copy of the requested file on your client machine's local disk. Application programs on your client machine use the local, cached copy of the file. This improves performance because it is much faster to use a local file than to send requests for file data across the network to the file server machine.
Because application programs use the cached copy of a file, any changes you make are not necessarily stored permanently to the central version stored on the file server machine until the file closes. At that point, the Cache Manager writes all of the changes in the file back to the appropriate file server machine, where they replace the central copy of the data. Some application programs close a file in this way each time you issue their save command (and then immediately reopen the file so that you can continue working). With other programs, issuing the save command writes the changes only to the local cached copy. If you use the latter type of text editor, you need to close the file periodically to make sure your changes are stored permanently.
If a file server machine becomes inaccessible, you can continue working with the local, cached copy of a file fetched from that machine, but you cannot save your changes permanently until the server machine is again accessible.
When the central version of a file changes on the file server, the file server advises all other Cache Managers with copies of that file that their version is no longer valid. AFS has a special mechanism for performing these notifications efficiently. When the file server sends the Cache Manager a copy of a modifiable file, it also sends a callback. A callback functions as a promise from the file server to contact the Cache Manager if the centrally stored copy of the file is changed while it is being used. If that happens, the file server breaks the callback. If you run a program that requests data from the changed file, the Cache Manager notices the broken callback and gets an updated copy of the file from the file server. Callbacks ensure that you are working with the most recent copy of a file.
| Note: | The callback mechanism does not guarantee that you immediately see the changes someone else makes to a file you are using. Your Cache Manager does not notice the broken callback until your application program asks it for more data from the file. |
As with a standard UNIX file system, if multiple users modify the same file, the changes saved last are the changes you see, regardless of who made the changes. When collaborating with someone on the same files, it is important to coordinate your work so you do not overwrite each other's changes. AFS allows you to prevent other users from accidentally overwriting your files by limiting access to your directories using access control lists (ACLs), which are discussed further in Protecting Your Directories and Files.
Because AFS is easily accessed by many users, several methods are used to ensure system security, including the following:
AFS uses two related methods to ensure that only authorized users access AFS: passwords and mutual authentication. Both methods require that a user prove his or her identity.
When you first identify yourself to AFS, you must authenticate to prove that you are who you say you are. To do this, you provide the password associated with your username.
When you correctly type your AFS password, your Cache Manager receives a token, indicating that you are a valid AFS user. A token is a package of information that is scrambled by an AFS authentication program using your AFS password as a key. Your Cache Manager can unscramble the token because it knows your password and AFS's method of scrambling. If your Cache Manager can unscramble the token and use its information, you are authenticated as an authorized AFS user.
The token is proof to the other AFS file servers that you are authenticated and can access the AFS filespace. This serves as the basis for the second means through which AFS creates security, called mutual authentication. Under mutual authentication, both parties communicating across the network prove their identities to one another. AFS requires mutual authentication whenever a server and client (most often, a Cache Manager) communicate with each other.
The mutual authentication protocol that AFS uses is designed to make it very difficult for people to authenticate fraudulently; here is how it works. Before it can communicate with file servers, your Cache Manager must have a valid token; it gets this token when you authenticate with AFS. When your Cache Manager contacts a file server, it also sends your token, which is encoded to be recognized only by an AFS file server. If the server recognizes your token, it can communicate with your Cache Manager. In turn, the Cache Manager accepts the file server as genuine if the file server can unscramble and use the information in the token. Mutual authentication is complete when both your Cache Manager and the file server have proven their identities to one another.
AFS uses access control lists (ACLs) to determine who can access the information in the AFS filespace. Each AFS directory has an ACL to specify what actions different users can perform on that directory and its files. An ACL can contain up to about 20 entries for users, groups, or both; each entry lists the user or group and the access permissions of each user or group.
The owner of a directory and system administrators can always define the composition of an ACL. Users automatically own their home directories and subdirectories. Other non-owner users can define a directory's ACL only if specifically granted that permission on the ACL. For more information on ACLs, see Protecting Your Directories and Files .
A group can be composed of one or more users and client machines. If a user is a member of a group, the user has all of the permissions granted to that group (as if the user were listed directly on the ACL). If a user is logged into a client machine that is a member of a group, the user has all of the permissions granted to that group. For instructions on defining and using groups, see Using Groups.
All users who can access your cell's filespace, authenticated or not, are automatically assigned to a group called system:anyuser. For a discussion of placing the system:anyuser group on ACLs, see Allowing Access by Users from Foreign Cells.
| Note: | You can use the UNIX mode bits to further control access on specific files within an AFS directory; however, the effect of these mode bits is different under AFS than standard UNIX. See File and Directory Protection. |
AFS is designed to be similar to the UNIX file system. For instance, many of the basic UNIX file manipulation commands (cp for copy, rm for remove, and so on) are the same in AFS as they are as in UNIX. All of your application programs work as they did before. However, there are differences between a standard UNIX file system and AFS, as described in the following sections.
AFS allows users to share remote files as easily as local files. To access a file on a remote machine in AFS, you simply specify the file's pathname. In standard UNIX, you must log into the remote machine, transfer the file from the remote machine to the local machine, or create a mount point on the local machine that points to the appropriate directory on the remote machine.
AFS users can see and share all the files under the /afs root directory, given the appropriate privileges. An AFS user who has the necessary privileges can access a file in any AFS cell, simply by specifying the file's pathname. File sharing in AFS is not restricted by geographical distances or operating system differences.
To become an authenticated AFS user, you need to provide a password to AFS.
See Logging in and Authenticating with AFS
AFS authentication passwords are stored in special AFS database, rather than in the local password file (/etc/passwd or equivalent). If your machine uses an AFS-modified login utility, you can change your password with a single command. If your machine does not use an AFS-modified login utility, you must issue separate commands to change your AFS and local passwords. See Changing Your Password.
AFS does not rely on the mode bit protections of a standard UNIX system (though its protection system does interact with these mode bits). Instead, AFS uses an ACL on each directory to control access. The differences between the two methods are summarized below:
The kinds of failures you experience when a standard UNIX file system goes down are different than when one or more individual AFS file servers are unavailable. When a standard UNIX file system is inaccessible, the system simply locks up and you can lose changes to any files with which you were working.
When an AFS file server machine becomes inaccessible, you cannot access the files on that machine, but if a copy of a file available on another file server machine you do not necessarily even notice the server outage. This is because AFS gives your cell's system administrators the ability to store copies of popular programs on multiple file servers. The Cache Manager chooses between the copies automatically; when one copy becomes unavailable, the Cache Manager simply chooses another.
If there are no other copies of a file that is stored on an inaccessible server machine, you can sometimes use that file if an up-to-date copy is held by your client machine's Cache Manager. However, you cannot save changes to files stored on an inaccessible file server until that server is running again.
Most of the UNIX remote commands (ftp, rcp, rsh, rlogin) remain available in AFS, depending on how your administrators have configured them. The remote commands run programs on a remote machine without explicitly telnetting to it. If the remote machine has a Cache Manager, your token is used there also and you are authenticated while the remote command executes. If the remote machine does not run a Cache Manager, you receive the following message:
Warning: unable to authenticate.
You are logged into the remote machine, but you are not authenticated to AFS. You can access the local files on the remote machine and the AFS directories that grant access to the system:anyuser group, but you cannot access protected AFS directories.
This section summarizes differences in the functionality of some commonly issued UNIX commands.
Many sites currently use the Networking File System (NFS). NFS client machines can access the AFS filespace through the NFS/AFS Translator. See Appendix A. NFS/AFS Translator.
![[Top of Topic]](../top.gif)