The AFS client software is installed on all UNIX servers at IES.
AFS is a distributed file system based on client/server technology. It was originally developed at Carnegie Mellon University and was commercially distributed by Transarc Corporation, later it became open source.
The basic concept underlying AFS is that of a wide-area file system managed by client and server programs. The file system appears to the user as a giant virtual hard disk or megadirectory made up of subdirectories from across the entire continent. A user's designated portion of the AFS file system is a subdirectory called a volume. Volumes are mounted by a client AFS program through a Kerberos authentication/password procedure.
The files and programs in a volume can be stored on a departmental AFS file server down the corridor, on the IES AFS server machine, or on a remote AFS file server on the Internet. From the user's point of view at the desktop, it is almost irrelevant where the volume to be mounted is physically located, as it and other AFS volumes are tracked by the AFS servers which make them appear as subdirectories of one virtual megadirectory or disk. This means that it is unnecessary for an AFS user to employ the FTP program to transfer files between directories in the global AFS filespace; rather, once the proper directory permissions have been set up by a volume's owner, an AFS user, for instance a user on IES, can simply use basic UNIX file system commands such as cp to copy files from a permitted volume to their personal AFS volume.
The Cache Manager component of AFS client programs is a major source of strength in a busy network environment. When the client software requests information from the AFS server, a copy of the requested file is stored in cache memory (disk) on the computer running the client software. Modifications are made on the copy, not on the original which remains unchanged on the server until the copy of the file on the client computer has been closed or saved. The upshot of this is a healthy reduction of requests to the AFS file server and less impact on overall campus network traffic.
AFS supports easy sharing and collaboration options for users who are left cold by twiddling with standard UNIX permission bits and inscrutable chmod commands. AFS users can easily share their directories with other individual AFS users, or with a designated group of AFS users. In practical terms, this means that IES users and other AFS users at the University can use shared AFS file space to do things like:
The rest of this article deals with the basics of AFS.
The AFS file system uses a hierarchical tree structure. The lowest level of the structure, i.e., the worldwide root AFS directory, is called /afs. Subdirectories of the worldwide AFS root directory are called AFS cells; for example, the IES AFS cell is called ies.auc.dk which can be located down the pathname:
alfred@lada> /afs/ies.auc.dk
In similar fashion, to go to an individual University user's AFS volume, enter a command in the form:
alfred@lada> cd /afs/ies.auc.dk/user/userID
A short form of the command above that works within the local ies.auc.dk.ca cell is:
alfred@lada> cd ~username
The ies.auc.dk cell is referred to as the local cell and all other AFS cells are called foreign cells. To mount a foreign cell so as to access its volumes, enter the following change directory (cd) command at the UNIX prompt:
alfred@lada> cd /afs
If you issue a list command (ls) after executing the cd command above, a subset of the available foreign AFS cells is listed, for example the AFS cell at Rensselaer Polytechnic Institute (RPI) in the United States. To mount the AFS cell at RPI, enter the following cd command:
alfred@lada> cd rpi.edu
If you issue an ls command on the RPI directory, a number of subdirectories are listed and you can continue to explore the RPI directories using the cd command. After such exploration, you could, for example, issue the following command to go to the RPI directory where PC software utilities are stored:
alfred@lada> cd campus/pc.software/ibm/utilities
Issue the ls command to see the available PC utilities. Choose a utility program to copy to your AFS volume at the University of Alberta. For example, you can copy the program PKZIP at RPI to your AFS filespace by issuing a command in the form:
alfred@lada> cp pkz204g.exe ~/pkz.exe
Note that the last part of the command above is the filename you give to the file you are copying to your AFS filespace.
In the example session above, you were able to copy a foreign file to your local AFS filespace in the ies.auc.dk cell because the owner of the foreign directories has permitted such access to all AFS users. This permission was set up with an AFS Access Control List (ACL), an easy-to-use tool that makes it possible to share directories, files, and programs among AFS users.
The biggest obvious difference between ACLs and traditional UNIX file permissions is that an ACL is used to apply permissions to an entire directory in an AFS volume; it cannot be used to apply permissions to individual files within a directory a la the UNIX chmod command. Related to this, the ACL of a parent AFS directory is also automatically inherited by any new child subdirectories created in or moved into the parent directory. The only way to change the ACL of the child subdirectory is to separately apply a different ACL to it.
ACLs are created, modified, and examined with the AFS fileserver command (fs) followed by various subcommands and ACL arguments. For example, to examine the default ACL applied to your home directory, enter the following at the UNIX prompt:
alfred@lada> fs listacl
The information returned by this command indicates that the system administrator and yourself have write access rights to your home directory, while all others have read access. This is the default for all the AFS directories in the ies.auc.dk cell.
To examine the ACLs of the files within a directory, cd to the directory and enter the following at the UNIX system prompt:
alfred@lada> fs listacl *
Before exploring in more detail the commands for creating and modifying ACLs, it's important to understand that there are seven types of ACL permissions, called access control rights, which can be applied to an AFS directory. These rights, shown below, can be given to other AFS users by the owner of the AFS directory in question. In AFS terms, the user who has the rights is called the possessor.
| r (read) | This right allows the possessor to both list and read the files in the directory |
| l (lookup) | This right allows the possessor to list the files in the directory using the ls and associated UNIX commands |
| i (insert) | This right allows the possessor to add/copy/move new files and subdirectories to the directory |
| d (delete) | This right allows the possessor to remove files and subdirectories |
| w (write) | This right allows the possessor to modify the files in the directory and to change the UNIX protection bits of individual files using chmod |
| k (lock) | This right allows the possessor to run programs in the directory that require file-locking |
| a (admin) | This right allows the possessor to change the ACL of the directory As a convenient option, the separate access control rights shown above can also be grouped together to form four different packages of access control rights. These four packages are: |
| write | This rights package gives the possessor read, lookup, insert, delete, write, and lock rights (i.e., rlidwk) |
| read | This rights package gives the possessor read and lookup rights (i.e., rl) to an AFS directory |
| all | This package of rights gives the possessor read, lookup, insert, delete, write, lock, and administer rights (i.e., rlidwka) |
| none | This option removes from the possessor all previously granted access control rights to an AFS directory |
Now that we've covered the different types of access control rights, let's try a few real-life scenarios of sharing AFS directories among different users. Remember that while these example sharing scenarios are using the AFS client program, they are really taking place within the local AFS ies.auc.dk cell which is independent of IES and part of the global AFS megadirectory. A different AFS client program besides the one running on GPU could be used to share AFS directories in the very same way.
Let's assume that you are the IES user albert who wants to share the contents of a directory in your AFS volume with a colleague who has the username bravo. The first thing to do is to create, in your home directory, the new directory you want to share:
alfred@lada> mkdir shared.stuff
Put the files/programs you want to share in the new shared.stuff directory. Now, cd to your home directory and then examine the ACL of shared.stuff:
alfred@lada> fs listacl shared.stuff
The command above returns the following ACL information:
Access list for /afs/ies.auc.dk/user/albert/shared.stuff is Normal rights: system:administrators rlidwka system:anyuser rl albert rlidwka
The returned information is the default ACL for directories in the ies.auc.dk cell; it signifies that only the system administrator and yourself currently have full access to the shared.stuff directory. A new ACL must be applied to the directory so that bravo can share its contents. To do this, cd to the directory that contains the shared.stuff directory (i.e., the directory above shared.stuff) and issue one of the following commands at the prompt. Both of these commands give all the ACL access control rights to bravo except the administer right, i.e., the right to change the directory's ACL:
alfred@lada> fs setacl shared.stuff bravo rlidwk
... or ...
alfred@lada> fs setacl shared.stuff bravo write
If you don't want to give bravo the ability to add, change, or delete files in shared.stuff, but only the ability to list and read/copy the files, modify the ACL for the directory with one of the following commands:
alfred@lada> fs setacl shared.stuff bravo rl
... or ...
alfred@lada> fs setacl shared.stuff bravo read
Check to see that the ACL rights for the shared.stuff directory have been changed to what you want by issuing the fs listacl command once more.
Now that you have applied a new ACL to the shared.stuff directory, bravo is free to share the contents of the directory according to the access control rights stipulated in the fs setacl command. For example, the write package of rights gives bravo the power to remove a file called old.txt from your shared.stuff directory with the following command:
bravo@lada> rm ~alfred/shared.stuff/old.txt
Bravo could also copy a file called new.txt from his/her home directory to your shared.stuff directory with the command:
bravo@lada> cp new.txt ~alfred/shared.stuff/new.txt
In like manner, Bravo could open and edit a file called agenda.txt in shared.stuff using a file editor such as emacs:
bravo@lada> emacs ~alfred/shared.stuff/agenda.txt
The kinds of sharing that are possible between individual AFS users are also applicable to defined groups of AFS users.
The five default system-wide AFS protection groups are:
| system:administrators | This group is comprised of University system administrators who have all access control rights to all directories in the ies.auc.dk cell |
| system:authuser | This group is made of all Kerberos-authenticated users in the local ies.auc.dk cell |
| system:anyuser | This group is comprised of all users, including non-AFS users,whether they are authenticated or not |
| webserver | This group is the only the webserver |
| group:XXgrXXX | These groups is group account e.g. group:03gr891 |
Typically, you would use a default system-wide protection group like system:anyuser to share a directory with the whole world, such as your new_public_dir directory on GPU where you can store and share your World Wide Web home page and other HyperText Markup Language (HTML) documents. To do this, first apply the following fs setacl command to your home directory:
alfred@lada> fs setacl ~ system:anyuser l
This command gives all users lookup (l) access to your home directory (they can list the directory's contents, but not read or copy). This is required so afs can navigate through your home directory to your new_public_dir directory.
Now, apply one of the following commands to your new_public_dir directory:
alfred@lada> fs setacl new_public_dir system:anyuser lr
... or ...
alfred@lada> fs setacl new_public_dir system:anyuser read
Both of the previous commands give all users read and lookup access to your new_public_dir directory, the required setup for sharing documents.
To see which users are in a group you have run the following
alfred@lada> pts membership alfred:nygruppe
alfred@lada> pts membership karthy:junta
or which groups a user is member of
alfred@lada> pts membership alfred
alfred@lada> pts membership fkj
The command for examination for the access control for a directory is named fs la and must be used like:
alfred@lada> fs la /afs/ies.auc.dk/user/fkj Access list for /afs/ies.auc.dk/user/fkj is Normal rights: system:administrators rlidwka system:anyuser rl fkj rlidwk
which shows that the adminstrator have read, write and adminstrative rights, the user fkj have read and write rights and all other users have read access to the directory.
For some directories you do not have access if you are not an owner or member of a group that have access to a directory
alfred@lada> fs la /afs/ies.auc.dk/project/risc fs: You don't have the required access rights on '/afs/ies.auc.dk/project/risc'
You should try youself to examine the directories which are standard in your own home directory by default. The directories concerned are: `Incoming', `Local', `Private', `Public' and `public_html'.
alfred@lada> cd /afs/ies.auc.dk/user/alfred alfred@lada> fs la Private ... alfred@lada> fs la Public
See the difference between the `Private' and `Public' directories and the others that exists in your home directory including `.' (your root directory).
Access control lists are named differently if you are used to Unix file permissions. Instead of `rwx' which relate to read, write and execute you have with AFS `rlidkwa' which relate to read, lookup, insert, delete, write, lock, and administer. Instead of specifying all the access control letters there exits a shorthand notation which covers the letters of most used combinations
| Makro | AFS acl |
|---|---|
| none | - |
| read | rl |
| write | rlidkw |
| all | rlidkwa |
So to set the access control lists for a directory you have to use the command fs sa in the following way
alfred@lada> mkdir testdir alfred@lada> fs sa testdir alfred all alfred@lada> fs sa testdir system:anyuser none
The effect of the commands is that no-one except yourself can read and write files in the directory testdir. If you wish that everybody have read access then do the following
alfred@lada> fs sa testdir system:anyuser read
If you have a user group called alfred:friends you have to give them write access but adminstrator access then
alfred@lada> fs sa testdir alfred:friends write
You can always check if the directory have the correct access control lists by fs la testdir. Try with you own directories!
To be able to access the AFS files and directories of your own you need an AFS token. It is a kind of ticket that you use to prove to AFS that you in particular have the authorization to access protected files. On Unix you can see if you have a token with.
alfred@lada> tokens Tokens held by the Cache Manager: >User's (AFS ID 43885) tokens for afs@ies.auc.dk [Expires Nov 23 10:35] --End of list--
If you do not have an AFS token no information will be shown
alfred@lada> tokens Tokens held by the Cache Manager: --End of list--
It is possible to get an AFS token on Unix by a login command for AFS called klog. You need to supply your password.
alfred@lada> klog Password:
If you did not have a token you can get one by typing klog. To remove your tokens you can use the unlog command to do the work. If you have a jobs running more then 24 hours you must renew the tokens, it can be done automatically by reauth (see e.g. Long running matlab jobs