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 [email protected]
or by phone at (217) 244-1144.

If you need assistance during hours when the NCO is not open,
please send electronic mail to [email protected], 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 [email protected] [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 [email protected] [>> 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 [email protected] [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 [email protected] [Expires May 28 10:14]
   User's (AFS ID 12345) tokens for [email protected] [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 [email protected].

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.

You are viewing proxied material from bitreich.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.