NCSA AFS User Guide Introduction ============ This user's guide is an introduction to the Andrew File System (AFS) concepts and commands as implemented at NCSA. On the NCSA high-performance computing systems, AFS is an additional resource. AFS file permissions are different from the standard UNIX file permissions. The UNIX file system permissions have very little meaning in AFS, so you must understand how to create and apply the Access Control Lists (ACLs) for your directories. The information you need to make the transition to the AFS environment easier is contained in this guide. Please review it carefully. Information Sources Hardcopy Some Transarc Corporation documentation is available for reference in the National Consulting Office (see ``Getting Help'' on page 1). Online Three online resources are available for your reference: man pages, a frequently asked questions (FAQ) list on the World Wide Web (WWW), and this user guide. The AFS FAQ is at the following URL: http://www.cis.ohio-state.edu/hypertext/faq/usenet/afs-faq/faq.html This user guide, as well as a link to the Ohio State-maintained FAQ, is available on the NCSA WWW server at the following URL: http://www.ncsa.uiuc.edu/Pubs/NCSASysDir.html Getting Help The NCSA National Consulting Office (NCO) is open from 8:30 a.m. to 5 p.m. Monday through Friday (except University holidays). Please contact the consultants first with your questions. Contact NCO staff by sending electronic mail to consult@ncsa.uiuc.edu or by phone at (217) 244-1144. If you need assistance during hours when the NCO is not open, please send electronic mail to help@ncsa.uiuc.edu, the NCSA 24-hour help desk. The Andrew File System (AFS) ============================ AFS is a distributed file system with a common name space. Data are stored in volumes on AFS file server machines and accessed through a cache manager on AFS client machines. If you work at different sites that have AFS cells (for example, NCSA and the Pittsburgh Supercomputing Center), you and other members of your group can access your data without doing file transfers. Access to data stored on AFS is controlled through authentication methods explained below. AFS, while similar to existing UNIX file systems, involves some new concepts and definitions that you need to understand. Cell Cells are directories within the AFS file space below the root. AFS, like other UNIX file systems, uses a hierarchical file structure -- a tree. The root is named /afs; all subdirectories of the root are called cells. A cell name is generally the same as the Domain Name Service (DNS) domain name. At NCSA, the cell name is ncsa.uiuc.edu. A cell organizes and maintains its own file space and can connect to file space of other cells running AFS. This gives you access to a very large file space that allows file sharing with users in each cell running AFS, whether the cell is local or remote. The cell controlling the workstation you are using is your local cell. All other cells in the AFS file space accessible are called foreign cells. NCSA mounts a subset of the AFS foreign cells, which are listed in the /usr/vice/etc/CellServDB file. If a foreign cell is mounted, you may access data in that foreign cell by authenticating with that cell using the klog command (see ``Logging in to a Foreign Cell'' on page 5). Change to that cell using the cd command (cd /afs/cellname). If you do not have an account in the foreign cell then you cannot klog for that cell. Please contact NCSA by electronic mail if you need a new foreign cell mounted at NCSA (see ``Getting Help'' on page 1). You must contact the foreign cell administrator for permission to access the foreign cell, not NCSA. Volume An AFS volume is the basic unit of AFS storage and represents a subsection of a disk drive partition. Most AFS cells are configured to assign a user's home directories to one volume. Volumes look very similar to a UNIX directory and contain files, directories, and path names to other volumes. All volumes have quotas (see ``File Server Information and Volume Quotas'' on page 14) and Access Control Lists associated with them (see ``AFS File Protection: Protection Groups and Access Control Lists'' on page 6). Server Machines Server machines provide access to the AFS volumes and the data bases that control access to these volumes. You do not need to know which server machine is responsible for a given volume. AFS automatically finds the volume that contains the directory or file you want to access. Client Machines Clients are workstations or other machines (e.g., Sun, RS/6000, CM-5) running the AFS client software that connect to the server machines. This linkage provides access to the AFS volumes you need to use the system. NCSA Client Systems At NCSA the following systems were running AFS client software at press time: * Thinking Machines Corporation CM-5 * CONVEX C3880 * CONVEX Exemplar* * Silicon Graphics Inc. Power Challenge* * Silicon Graphics workstations** in NCSA Numerical Laboratory and Renaissance Educational Laboratory * Sun workstations** * Hewlett Packard workstations** *will be running AFS when in production mode **workstations maintained by NCSA's Computing and Communications Group AFS Availability Verification If you use telnet to access a system, you see the following information when you first log on, which tells you that it is running AFS. login: yourname Password: yourpassword AFS (R) 3.3 Login Last login: Fri Oct 2 08:12:14 from machinename SunOS Release 4.1.2 (AMAZON) #1: Tue Nov 2 09:56:14 CST 1993 % Another way to find out if the system can run AFS is to try to change your directory to the /usr/afsws directory. If you can change to this directory, AFS is installed on the system (although it may not be in use). Authentication AFS uses Kerberos as its authentication mechanism and Access Control Lists (ACL) as its authorization mechanism instead of UNIX file system Discretionary Access Control (owner, group, and other). The Kerberos and ACL combination provides superior security for your files. ACLs are explained in the section entitled ``Access Control Lists'' on page 6. Briefly, an ACL is a list you establish that determines who can access your files and what can be done with the files. Each directory has an associated ACL in the file system. You own your home directory and all subdirectories, and you establish and maintain the ACL for your home directory. The UNIX file systems permissions have very little meaning in AFS, so you must understand how to create and apply the ACLs for your directories. (See ``Your Default Home ACL'' on page 12 for information on your default home directory setting.) Passwords and the resulting authentication process are similar to logging in on a UNIX system. If you provide the correct password, you get access to all AFS files associated with your account. Tokens are used to control access to files. They indicate that you have authenticated successfully as a user within a named cell. Tokens are held in the client's cache manager, explained next. Cache Manager A cache manager is a process that assists your machine in accessing information stored in the AFS file space. Part of the client machine software, the cache manager requests files from server machines and stores a copy of the file on your machine. You work on the copy, not the original that is still on the server. This process reduces the number of network requests to the servers. Changes you make to the copy are not transmitted to the original until the file is closed or saved during the working session. Once the file is closed (or saved) the cache manager sends the revised file to the file server machine and replaces the original with the changed copy. A major function of the cache manager is to store user tokens. As an added security measure, tokens ``go stale'' and must be renewed periodically using the klog command. (See ``NCSA Token Period'' on page 4.) Each time you log off the system and then log back on, a new token is issued. (See ``AFS Authentication Commands'' on page 4.) Cache Manager and X Window Systems A token, stored by the cache manager, is associated with one session on one host computer. If you are using the X Window System on a workstation, you only need to authenticate once on that host system. You can then open as many windows with that AFS token as you want. If, however, you then telnet to another host system, you must authenticate again to open windows on that system. AFS Authentication Commands =========================== NOTE: See ``Modifying Your Dot Files or Scripts'' on page 16 for information on adding the appropriate path to your $PATH environment variable in your .login or .cshrc file. Tokens and Authentication Each time you log on to an AFS machine, the authentication process takes place. If the password you enter is correct, a token is issued that identifies you to AFS. The token is used as the AFS file server and the client machine work together to provide you access to your data. If you maintain an open session for the life of your token, you need to issue the klog command to reauthenticate yourself to AFS when your token goes stale. When you have a stale token, you receive a system prompt telling you that you are not an authorized user. You cannot edit files, write to AFS, and perform other basic functions. Enter the klog command to reauthenticate into AFS. Next enter your password in response to AFS's request. If the password is correct, a new token is issued that identifies you to AFS. You can have tokens authenticating you into more than one cell but you can only have one token per cell. For more information on the klog command, enter klog -help. NCSA Token Period The life of tokens is established by the NCSA AFS system administrators. The system administrators have set the NCSA token period to 25 hours. Authentication Commands klog and unlog Use the commands below to obtain, destroy, and check on tokens. To start the authentication process, enter: % klog Password: yourpassword% You can destroy an existing token rather than waiting for it to go stale by entering the unlog command. For example, you would destroy your token if you want to end your session with a foreign cell. tokens To find out what tokens have been issued to you, enter the following. % tokens % The output from a tokens command request is shown below. AFS tells you when your current token expires. % tokensTokens held by the Cache Manager:User's (AFS ID 12345) tokens for afs@ncsa.uiuc.edu [Expires May 27 15:49] --End of list--% The system returns an ``empty'' list when you have no active tokens. % tokensTokens held by the Cache Manager: --End of list--% The system tells you if your token has expired as shown below. % tokensTokens held by the Cache Manager:User's (AFS ID 12345) tokens for afs@ncsa.uiuc.edu [>> Expired <<] --End of list--% Remember that you are not able to edit and save files and perform other basic functions when you are not authenticated into AFS (have no active tokens). Getting a New Token Each time you log in to an AFS machine, you automatically generate a new token, which extends the period during which your token is valid. For example, if your token is scheduled to expire at 11 a.m. and you log in to the system at 7 a.m., a new token is issued for the full period of 25 hours. If your token expires during a working session, use the klog command to get a new token. To verify that a token was issued, enter the tokens command as shown below. % klogPassword: yourpassword% tokensTokens held by the Cache Manager:User's (AFS ID 12345) tokens for afs@ncsa.uiuc.edu [Expires May 28 10:14] --End of list--% Logging in to a Foreign Cell Access a mounted foreign cell by issuing the klog command in conjunction with your username and the name of the cell you want to access. For example, to access the Pittsburgh Supercomputing Center, enter: % klog username -cell psc.edu% tokensTokens held by the Cache Manager:User's (AFS ID 12345) tokens for afs@ncsa.uiuc.edu [Expires May 28 10:14] User's (AFS ID 12345) tokens for afs@psc.edu [Expires May 29 11:37] --End of list--% Verify that you have logged into the PSC cell by issuing the tokens command. If you do not have permission to access the foreign cell, the reply show below is returned. % klog mandyp -cell psc.eduPassword:Unable to authenticate to AFS because user doesn't exist.% Contact the Consulting Office (see ``Getting Help'' on page 1) if you need assistance. Summary of Authentication Commands % tokens lists all of your tokens % klog username -cell cellname accesses the named mounted foreign cell % klogstarts the authentication process % unlog [cellname]unauthenticates you on a cell by cell basis AFS File Protection: Protection Groups and Access Control Lists =============================================================== The differences between UNIX and AFS file protection will undoubtedly be the most difficult part of your transition to AFS. After reading the information below, please contact the NCSA Consulting Office if you have any questions (see ``Getting Help'' on page 1). Remember that the UNIX protection bits for group and other have very little meaning in AFS. UNIX bits for owner still apply. You can set the UNIX mode bits for group and other within the AFS environment, but AFS ignores these settings in favor of the protection groups and ACL settings. Access Control Lists Access Control Lists (ACL) control who may access files and directories. You control the ACLs for your directories and files. A file uses the ACL of the directory in which it resides. If you move a file to a new directory, it then assumes the access control rights of that new directory. To protect a file as in the original directory, you must move it to a like-restricted directory. In sum, files do not have individual permissions; rather they have the permissions of the directory in which they reside. A subdirectory created assumes the ACL of the parent directory. However, you can modify the ACL for the subdirectory independently following creation. If the parent directory, however, has a more restrictive ACL than the child, other users might be denied some of the access rights you granted them in the child. Always issue lookup access (see ``Your Default Home ACL'' on page 12) in the parent directory for someone who has permissions in the subdirectory. The ACL for a directory is maintained using the fs command described in ``Establishing an Access Control List'' on page 8. Each access control entry has two parts: a user or group name and the access control rights. Access Control Rights There are seven access control rights that can be assigned to a protection group or to a directory. The first four listed apply to the directory; the final three apply to the files in the directory. a administer -- allows the possessor to change the ACL for the directory l lookup -- allows the possessor to issue ls to list the names of the files and subdirectories in the directory; to issue ls -ld to get a long listing of the directory element; to examine the ACL for the directory; and to access the directory subdirectories i insert -- allows the possessor to add new files and subdirectories to the directory (either new or copies) d delete -- allows the possessor to remove files and subdirectories or move them (where the user has insert rights) r read -- allows the possessor to look at the contents of the directory and read the data in files in the current directory w write -- allows the possessor to modify the contents of files in the directory and to change the UNIX mode bits with the chmod command k lock -- allows the possessor to run programs that need to file-lock files in the directory The vendor provides four shorthand notations that are easier to use than the combinations they represent. write includes rlidwk (read, lookup, insert, delete, write, lock) read includes rl (read and lookup) all includes rlidwka (read, lookup, insert, delete, write, lock, and administer) none removes the entry Protection Groups A protection group is similar to a UNIX group but, in AFS, you establish and maintain the protection group yourself. Three system-wide protection groups, provided by the AFS vendor, are available by default. NCSA system administrators have established the ACL for your home directory for these system-wide protection groups. Remember that new directories you create below your home directory take on the home ACL. You can change the access permissions assigned to home and subdirectories if you choose. See ``Your Default Home ACL'' on page 12 to understand why the ACL for home is set as it is. System-wide Groups The three system-wide protection groups provided by the AFS vendor are: system:administrators the AFS system administrator system:authuser any user authenticated into NCSA's cell system:anyuser all users, authenticated or not You cannot add additional system-wide protection groups. However, you can modify the access rights assigned to each of these groups as explained in ``ACLs for System-wide Protection Groups'' on page 8. (Access rights are described in ``Access Control Rights'' on page 7.) Groups You Create In addition to possibly modifying the ACLs for the system-wide groups, you can create groups yourself and assign permissions to the members. Refer to ``Creating a Group and Setting the Group's ACL'' on page 10 for information on establishing a group and providing permission. Refer to the section entitled ``Summary of ACL Commands'' on page 11 for additional information. Step-by-Step Process Determining the ACL for a directory or a user is similar in concept to determining the permissions in the UNIX protection bits. The basic steps you follow are summarized below. Subsequent sections tell you how to determine the access list settings and how to modify the settings. Remember that the ACL of a new directory assumes the permissions of the parent directory until modified. If the default permissions are appropriate for the new directory, you do not need to make any changes. * decide what access you want to give to others (e.g., read, write) * determine the proper setting abbreviations for this access (see ``Access Control Rights'' on page 7) * check the default ACL for the directory (and therefore for the files in the directory) * modify as necessary to make the ACL for the directory match your requirements * check the ACL to see that your modifications were completed successfully You should keep lookup rights for system:anyuser for your home and scratch directories. Refer to the section entitled ``Your Default Home ACL'' on page 12 for a better understanding. Establishing an Access Control List =================================== The fs (file server) command is used to check and set the ACL for directories. The fs listacl command tells you what permissions exist for the current directory. ACLs for System-wide Protection Groups After you have decided what access you want to give to others and what the abbreviations are you should use, the next step is to determine the current ACL for a directory. Remember that a directory's ACL is inherited from the parent directory and remains that way until you modify it. For example, to see the ACL for a directory named MyDirectory owned by a user named Lahti, she enters: % fs listacl MyDirectoryAccess list for MyDirectory isNormal rights: system:administrators rlidwka <--system administrators have all permissions system:anyuser l <--any other user has only lookup permission lahti rlidwka <--owner Lahti has all permissions% If you want system:anyuser to have additional permissions on the directory, change that using the fs setacl command sequence. For example, Lahti wants other users to do more than just look at the files contained in MyDirectory -- she wants them to be able to insert files (i). She adds this permission for system:anyuser as follows: % fs setacl MyDirectory system:anyuser li% fs listacl MyDirectoryAccess list for MyDirectory isNormal rights: system:administrators rlidwka system:anyuser li <--any other user now can lookup and insert lahti rlidwka % The command formats are: % fs listacl directory list a directory's ACL% fs setacl directory username accessrights set one directory's ACL ACLs for Individual Users Suppose you have a directory whose contents you want to share with one other user. To give this person complete access to a certain directory and all the files within that directory, you must modify the ACL for the directory. For example, user Lahti wants user Goodwin to have access to the directory called CollabDir. First she checks the existing ACL. Next she adds lookup, insert, delete, read, and write access as follows: % fs listacl CollabDirAccess list for CollabDir isNormal rights: system:administrators rlidwka system:anyuser l lahti rlidwka% fs setacl CollabDir goodwin lidrw <--adding permissions for Goodwin% fs listacl CollabDirAccess list for CollabDir isNormal rights: system:administrators rlidwka system:anyuser l lahti rlidwka goodwin rlidw <--Goodwin now has permissions % To remove an individual user's permissions for a directory, use the same command you use to give access: % fs setacl CollabDir goodwin none % fs listacl CollabDir Access list for CollabDir isNormal rights: system:administrators rlidwka system:anyuser l lahti rlidwka% Creating a Group and Setting the Group's ACL If you work with a group and you want to give the members access to a directory, you can create a user-owned group to provide access. You can add or delete individuals to the group as needed using the AFS protection server (pts) commands. To start this process, make a directory and check the ACL (or check the ACL for an existing directory). In this example, the user is named Anders and the directory is Election94Dir. % mkdir Election94Dir% fs listacl Election94DirAccess list for Election94Dir isNormal rights: system:administrators rlidwka system:anyuser rl anders rlidwka % Anders now wants to create a group called Team94 and provide access to the Election94Dir. Anders has decided that the members of the team should have all permissions. Anders creates the Team94 group (with members Morgan, Rochelle, and Perez) using the pts creategroup command and adds the appropriate permissions using the pts adduser command: % pts creategroup anders:Team94 <--create a group called Team94group anders:Team94 has id -211% pts adduser -user wmorgan lrochelle perez -group anders:Team94 % pts membership anders:Team94 <--verify the membersMembers of anders:Team94 (id -211) are: wmorgan lrochelle perez % pts examine anders:Team94 Name: anders:Team94, id: -211, owner: anders, creator: anders, membership: 3, flags: S-M--, group quota: 0. % Anders next gives access to the three members of Team94 using the fs setacl command: % fs setacl Election94Dir anders:team94 all <--give Team94 all permissions% fs listacl Election94DirAccess list for Election94Dir isNormal rights: anders:team94 rlidwka <--verify permissions for Team94 system:administrators rlidwka system:anyuser rl anders rlidwka% NOTE: Always verify group membership and permissions after creating or modifying a group. Summary of ACL Commands The following table summarizes the commands to use to make modifications to the ACL for a directory (and therefore to the files within the directory). Remember that you can give system-wide access with the protection groups or you can give access to specific individuals. You can also create your own groups and give access that way. Command lineAction % mkdir directory creates a new directory, which assumes the ACL of the parent directory % fs listacl directory lists a directory's ACL % fs setacl directory username accessrightsprovides permissions for a single user for a directory % pts creategroup owner:groupnamecreates a user-owned group % pts adduser username owner:groupname adds a user to a group % pts membership groupnamechecks the members of groupname % fs setacl directory owner:groupname accessrights establishes the access rights for a group to a directory % pts adduser -user user1 user2 ... -group owner:groupnameadds multiple users to a group % pts removeuser username owner:groupnameremoves a user from a group % pts delete owner:groupnamedeletes a group % pts rename owner:oldgroupname owner:newgroupnamechanges a group name % fs setacl -dir directory1 directory2 ... -acl username accessrightssets the ACL for multiple directories, where username is a group name or an individual user's name; ACLs set must be the same for all directories % fs checkvchecks to make sure that the data in the local cache are current (stands for checkvolumes) % pts help lists protection server commands Your Default Home ACL ===================== By default the ACL on your home volume and scratch volume created for new AFS accounts is set so that the system group system:anyuser has lookup access only to the volume. Because of the lookup access, any user may ls your home directory and see the file names. Other users, however, may not read or insert files into your home directory. Your home directory needs to remain system:anyuser lookup (lookup is usually abbreviated as l). Some system commands and applications need to list (ls) your home directory or file status (stat) to work. Listing your home directory requires system:anyuser lookup permission while file status requires system:anyuser read and lookup permission. You may set the ACL to system:anyuser none on directories but you should always allow system:anyuser lookup on your home directory (see ``Unauthenticated Applications'' on page 13). Refer to the ``Establishing an Access Control List'' on page 8 for information about modifying the access on your directories and files. Root Root has no special privileges in your home directory because it is not authenticated in AFS. Utilities like cron and sendmail that normally use root access to read or write files in your UNIX file space are not able to do so under AFS. While more secure, this setup may present a problem if you need personal cron entries or frequently use .forward files to reroute mail. Additionally, files like .login, .cshrc, .twmrc, and .Xdefaults must be read by unauthenticated system programs and must be located in your home directory. See ``Organizing Your Home Directory'' on page 13. Binary Executables Another major difference between UNIX permissions and AFS ACLs is the definition of the UNIX ``execute'' privilege. For a binary to be executable in AFS, the ACL for the directory in which the executable resides must have both lookup and read permission. Therefore any subdirectory in your home directory from which binaries are executed (e.g., ~/bin) should have both read and lookup access rights for the party executing the binary. ACL Reminders * Remember that newly created directories take on the ACL of the parent directory. When you create new directories in your home directory you may need to use the fs command to set the ACL appropriately. * If you want to provide other users access to your home directory you can do so yourself using the fs command (see ``File Server Information and Volume Quotas'' on page 14). You can also create a subdirectory with a specific ACL that you create yourself (see ``Creating a Group and Setting the Group's ACL'' on page 10). If you understand and use the fs and pts commands properly you have considerable flexibility in controlling access rights to your files. Use the ACL to your advantage. An Example A dummy AFS account named afsman illustrates these recommendations. Change to the /afs/ncsa/user/afsman directory and read the README file for a better understanding of the impact of the ACL on your home directory. Organizing Your Home Directory ============================== The best way to organize your home directory is to create a subdirectory, called public for example, that is system:anyuser rl (that is, read and lookup access) and then move your dot files to the public subdirectory. Link these dot files in your home directory to the files located in the public subdirectory using the ln command. For example, entering ls -la on such a home directory shows: drwx------ 5 user 2048 Apr 22 16:51 .drwxrwxrwx 2 root 2048 Mar 3 15:11 ..lrwxr-xr-x 1 user 25 Apr 22 08:53 .cshrc-> public/.cshrclrwxr-xr-x 1 user 25 Apr 22 08:53 .forward -> public/.forwardlrwxr-xr-x 1 user 30 Apr 22 08:50 .vacation.msg -> public/.vacation.msgdrwxr-xr-x 2 user 2048 Apr 22 16:32 public Remember that by default the ACL on your home volume is set so that the system group system:anyuser has lookup access. Root is not authenticated in AFS and has no special privileges in your home volume. The dummy AFS account in /afs/ncsa/user/afsman illustrates this. Review the README file for a better understanding of the impact of the ACL on your home directory. Unauthenticated Applications ============================ Some applications, such as TeX and ghostview, read and get the status (stat) of some or all of the directories in the path to a file. When used with a file in AFS, these applications may hang or report errors when denied access to a directory, even one that has no apparent connection to the intended file. For instance, LaTeX attempts to list all of the directories in the directory above the input file. If one of those directories is not available, LaTeX reports an error, even though it has nothing to do with the input file. To temporarily work around this problem, it is usually possible for NCSA staff to move the input file to a non-AFS directory. If you encounter such problems, contact the help desk at (217) 244-0710 or send electronic mail to help@ncsa.uiuc.edu. Password ======== To change your AFS password, enter: % kpasswd Old password: oldpassword New password: newpassword Verifying, please reenter new_password: newpassword% AFS passwords are internal to AFS. Your password should not be longer than 8 characters. Also, it should not contain the following special characters: ' ^ & ? ( ) | $ You should follow the normal precautions when setting your password, including changing it periodically and not revealing it to others. File Server Information and Volume Quotas ========================================= fs Command The fs command operates on AFS data and helps you manage your ACL and check quotas. You can use it to find out which file server contains a file or directory that you need. Use the commands below to learn more about various file servers: % fs whereis directorylists the file server with the file or directory % fs checkservers -allchecks the status of all file servers % fs checkservers cellnamechecks the status of the cell named % fs listquotagets information about volume quotas (or fs lq) % fs helplists file server commands available Home and Scratch Space Your initial AFS home directory and scratch space varies according to the category of NCSA user you are: Type Home Dir Quota Scratch Vol QuotaAcademic user 3 Megabytes 3 MegabytesEducation user 1 Megabyte no scratchIndustrial user contact your NCSA consultantVendors contact NCSA Consulting OfficeVisitors contact NCSA Consulting OfficeStaff contact your supervisor Home directories (/afs/ncsa/user/username) are backed up to tape nightly. Scratch volumes (/afs/ncsa/scratch/username) are not backed up. Scratch space in your AFS home directory is not destroyed periodically. You may ``permanently'' store data in your home directory, but you should also archive these files to UniTree, the NCSA mass storage system. See the NCSA UniTree User's Guide available on the NCSA World Wide Web server from the following URL: http://www.ncsa.uiuc.edu/Pubs/NCSASysDir.html Projects Directory NCSA has project space available to provide additional storage for large users or collaborative projects. (Depending on your needs, you may be asked to purchase additional disks.) Access to the /afs/ncsa/projects directory must be assigned to you or your group by NCSA system administrators. Once you are assigned additional space, you are responsible for administering the ACL for that space. Contact the Consulting Office (see ``Getting Help'' on page 1) to request additional space. Working Within Your Quota Always check the amount of space you have available under your quota before you move (mv) or uncompress files. Under the present implementation of AFS, if your quota is nearly full and you attempt to move or uncompress a file, the move or uncompression will not succeed and the original files are deleted. If you want to uncompress a file and preserve the original file, the following command line is recommended: % zcat file.Z > file You can use the scratch space (see ``Scratch Directory'' on page 15) to move or uncompress files. Do not leave files in this directory because it is purged daily at 4 a.m. NCSA's AFS Configuration ======================== Before starting to use AFS, you need to understand how the file system and your home and scratch directories are configured in NCSA's implementation of AFS. This section provides general information on the file system layout and the paths of AFS files specific to NCSA's implementation. Scratch Directory A scratch directory for untarring large files and other short-term work is available in /afs/ncsa/scratch/temp. Any file in this directory is public -- that is, any user in the NCSA cell can read, write, insert, delete, and lookup files in this directory. Because of the functionality of this space, it is: * not backed-up * purged daily at 4 a.m. Therefore, in the unlikely event of a disk crash, this space cannot be restored from tape. If you require a private area in this directory, contact the NCSA Consulting Office (see ``Getting Help'' on page 1). Please provide sufficient lead time for the staff to assist you. Backups Backups are done nightly at midnight for your home directory only. The backed-up, read-only files are mounted in a volume called ~/OldFiles. If you are a Macintosh user, you can think of the /OldFiles volume as a trashcan. Unlike a Mac trashcan, however, the /OldFiles volume contains an image of all the files in your home directory. The /OldFiles volume does not occupy much space on physical disk because it is primarily composed of pointers to the original file copies. You can restore accidentally deleted files if you do this before the next backup is generated. Remember that a file created and deleted in the same day (before any backup is performed) is not available to be restored. If you do not retrieve an accidentally deleted file before the /OldFiles is replaced with a later version, you can request that the file be restored from the backup tapes maintained by the system administrators. (See ``Getting Help'' on page 1.) NOTE: The /OldFiles directory is not included when determining your use of file space toward your quota. NOTE: The directory /OldFiles/OldFiles in your home directory should be disregarded. Conceptually this is a recursion -- that is, a backup of a backup. The /OldFiles/OldFiles appears as an entry in your home directory but you cannot change to that directory or list the contents (an error message is returned). Contact the NCSA Consulting Office (see ``Getting Help'' on page 1) if you have questions about this directory. Modifying Your Dot Files or Scripts When your AFS account is established, you get skeleton .login and .cshrc files that include path entries needed for AFS and some suggestions for handling architecture-specific log on issues. If you are not using the skeleton .login or .cshrc, preferring your existing dot files, you should make the modification listed below. For your convenience you should include the path /usr/afsws/bin in your $PATH environment variable in your .login or .cshrc file. AFS user commands are in this directory and including the path in your .login or .cshrc file simplifies your entry of AFS commands. Because a few AFS commands are the same as UNIX commands, the additional path information is needed to avoid error messages and uncompleted commands.(Without this path in your .login or .cshrc, you need to enter the full path when you issue an AFS command.) Making the Change To modify your $PATH, open your .cshrc file using an editor (e.g., vi). Look for a line similar to the line below: set path=($path /usr/local/bin /usr/local/gnu/bin) Add /usr/afsws/bin to the front part of your path so the line now looks similar to the line below: set path=($path /usr/local/bin /usr/afsws/bin /usr/local/gnu/bin) Put the /usr/afsws/bin at the beginning of the $PATH listing because you want to access the AFS commands, not the UNIX commands using the same abbreviations. Save the change and quit from your editor. Enter source .cshrc to have this change take effect. NOTE: Remember your $PATH line will probably be different than the sample line shown here. Contact the Consulting Office (``Getting Help'' on page 1) if you need assistance. Directory Configurations The table below shows you the path (known as a mount point in AFS) for the files associated with the AFS implementation at NCSA. /afs/ncsa is actually a soft link to /afs/ncsa.uiuc.edu. /afs/all_mounted_cells This is the mount point for local and foreign cells. The mount points are the foundation for any metacenter file system. (MetaCenter refers to the coordinated programs of the NSF-founded high-performance computing centers -- NCSA, Cornell Theory Center, Pittsburgh Supercomputing Center, San Diego Supercomputer Center, and the National Center for Atmospheric Research.) /afs/ncsa/all_local_volumes This is the mount point for all the NCSA AFS volumes. /afs/ncsa/common/all_architecture_names This directory includes machine-independent system software (e.g., fonts), system administrative files, and documentation (e.g., man pages). /afs/ncsa/all_architecture_names Machine dependent system software such as system binaries (executables) is included in this directory. /afs/ncsa/src/all_architecture_names The licensed source files for the appropriate architecture is contained in this directory. For example, on a Sun system, the Sun operating system and AFS source code are located here. /afs/ncsa/packages/package_names Application packages and public domain binaries (executables), libraries, and include files are in this directory. A subdirectory is established for each package and within that subdirectory a directory is made per architecture supported. The bin, lib, and include files for the architecture are there. NCSA system administrators have linked the directory /usr/ncsa/bin to /afs/ncsa/packages/package_names. The /afs/ncsa.uiuc.edu/packages/X11R5/SunOS_4.1.2/bin directory, for example, contains the X11R5 binaries for Sun SPARC systems. Links are used as necessary so that directories such as /usr/bin/X11 point to the correct location within AFS on a given system. /afs/ncsa/projects/various_project_names This directory is for project work that is collaborative in nature. Different groups within NCSA and users outside of the NCSA cell may access this directory provided they can be authenticated. This configuration can be considered a start on a metacenter file system. Some volumes are local and some are foreign, but researchers do not need to know the location of the volume being accessed. Coordination with other metacenter sites is necessary for this aspect to be fully implemented. /afs/ncsa/user/account_names This directory is where home volumes are mounted. Because of the large number of user accounts, subdirectories (e.g., .u1) have been created. These subdirectories are linked to /afs/ncsa/user/account_name. For example, the directory /afs/ncsa/user/mandyp is linked to /afs/ncsa/.u1/mandyp. /afs/ncsa/scratch/account_names This is your link to a scratch area in your home directory. For example, the directory /afs/ncsa/scratch/mandyp is a link to /afs/ncsa/.u1/mandyp/scratch. .