AFS Guide | F.A.Q.| Basic AFS | Advanced AFS | Kerberos | Features | Other Info
AFS is a file-sharing system comparable to NFS, Apple File Protocol, NetBIOS, or Netware Core Protocol. It allows "client" work stations to access files from a remote file "server". AFS is still under development. From the standpoint of someone familiar with standard UNIX file systems or NFS, the main differences are the new file permissions and authentication system.
AFS provides several advantages over other file-sharing
protocols that make it ideal for computing at Stanford:
Some of the major goals of the system are minimizing the burdens of system administration and providing a common basic level of service to all UNIX users at Stanford.
For a longer but simpler explanation of kerberos, take a look at our main Kerberos page.
Basically, Kerberos is an authentication service between machines on an open network. AFS is one of many services that uses kerberos for its authentication system. Kerberos provides user authentication for certain restricted services, such as printing, computer, and modem access. It also provides for encrypted connections, so information being sent can't be seen by some third party who is eavesdropping on your session.
Mac users can get the benefit of Kerberos by installing MacLeland , users of Windows 95 can do the same by installing PC-Leland , and UNIX administrators can use the clients available for UNIX (as you'll notice, at Stanford kerberos and AFS work hand in glove).
For more general information, see the files /afs/ir/users/c/consult/pub/afs/mit-kerberos.ps and the kerberos faq in /afs/ir/users/c/consult/pub/faq/kerberos. (The M.I.T document was obtained by anonymous ftp from athena-dist.mit.edu.)
You should update your UNIX session configuration files. The command
/usr/pubsw/bin/updatercwill allow you to do this quickly. (You only need to run it once).
You need to make sure the directory that your .plan and .project files are in is world-readable. One method to do this is to create a world-readable subdirectory to contain them. Type the following commands at the UNIX system prompt:
cdThe cd command makes you go to your root directory. The mkdir creates a public subdirectory. The first fs command gives the world list access to your home directory (so anyone can see the names of files and directories in your home, but not their contents). The second fs command gives the world read permission to the subdirectory public/. The mv command moves your .plan and .project files to the now world-readable subdirectory. The ln command creates a symbolic link from your .plan and .project files in public/ to your home directory, which is where the standard UNIX finger daemon expects them to be.
This solution will also work for the .klogin and .rhosts files.
Leland no longer users .forward files. Run lelandforward to set up forwarding.
You can use any one of these commands:
fs listquota
fs lq
sweetquota
lelandquota
The files contained within your afs home directory use both AFS and UNIX file permissions. The only UNIX (chmod) permissions which are still applicable under AFS, however, are the permissions for the owner. UNIX permissions on directories are not used.
Your temporary files (those found in /tmp and /usr/tmp) are in local UNIX file space. Only the UNIX file privileges apply here. That is why the umask variable in your .cshrc is still important. The default .cshrc file has umask set to 077, which gives no file permissions to other users.
For more info on UNIX permissions and AFS, read the Advanced AFS Page.
Each night between midnight and 3 AM, a backup image of your account is made. If you delete a file under the standard UNIX file system or in NFS, it is gone. If you delete or modify a file in an AFS volume, you may be able to retrieve the file *if* it existed when the backup image was made.
Newer accounts are created with their backup volume mounted as the directory named ".backup". If you do not have this mounted, it is easy to do. Running
fs mkmount ~/.backup user.$USER.backupwill mount your backup volume in the directory named .backup in your home directory. (Note, you can use a name other than ".backup".)
To unmount the volume type
fs rmmount ~/.backupYou don't need to unmount it: files in .backup do not count against your disk quota usage.
The backup volume (user.$USER.backup) is a read-only copy of your account. It takes up minimal space and does not count against your quota. You cannot remove or alter files in the backup volume, and file changes made after the last backup but before the next backup are not available.
Unlike the local UNIX file system and NFS, AFS has a limited mechanism to undelete files. To restore a file, you must copy the file from the "backup volume" to your account.
Be aware that the file you are recovering needs to be at least a day old (i.e., existed before the last backup was made), and you must take steps to recover it on the same day that you deleted it (i.e., before the next backup image is made).
If you do not have a .backup directory, mount it:
fs mkmount ~/.backup user.$USER.backupSuppose you delete the file ~/Mail/incoming. The following commands may recover it (assuming you have sufficient quota):
cdYour recovered file would be located in your Mail subdirectory and named incoming.bak
NOTE: if you are trying to recover files from an AFS directory other than your home directory, you will need to mount a different volume. To find a directory's volume name, type
cd directory (e.g., cd /afs/ir/data/mydata)A command to mount this particular backup volume is
fs mkmount OldData data.mydata.backupYou can then copy what files you need. The unmount command is
fs rmmount OldDataThere are several possibilities. A user needs "list" permission on all the ancestors to a directory to access a directory. For example:
You wish to give a friend access to directory ~/private/project. Using the fs listacl command (or "fs la" for short), you find the following:
cardinal:> fs la ~
Access list for /afs/ir/users/m/y/myself is
Normal rights:
system:administrators rlidwka
system:anyuser l
myself rlidwka
cardinal:> fs la ~/private/
Access list for /afs/ir/users/m/y/myself/private is
Normal rights:
system:administrators rlidwka
myself rlidwka
cardinal:> fs la ~/private/project/
Access list for /afs/ir/users/m/y/myself/private/project is
Normal rights:
system:administrators rlidwka
myself rlidwka
myfriend rlidwk
Your friend does not have access to the directory ~/private, so the permissions on ~/private/project are not accessible.
You can use the fs setacl (or "fs sa" for short) command to remedy this:
cardinal:> fs sa ~/private/ myfriend l
This gives myfriend "list" access to ~/private: the names of files and directories there will be visible to your friend, but not their contents (except in this case for project/, which you already gave myfriend "write" access to).
Another possibility is that the person has permission to get to the directory, but the change has not been updated on the local machine. AFS clients cache permissions locally and update them every two hours. If the friend runs klog, the recent change to the ACL will be reflected.
You cannot under AFS 3.3 at Stanford. Later versions may have cross-cell authentication.
An ACL can only hold 20 entries. Those entries, however, may be groups. You can, for instance, create a group with 30 members. By adding that group to an ACL, you can thus add 30 users with only one entry in the ACL for a given directory. Read the section on groups in the Advanced Section for an explanation of groups and the pts command.
When you log in, you receive a "token", or authentication to your files. To determine if you have a token, type "tokens" at the system prompt. You will see the token, if any, that you have and when it expires. Tokens have a 25 hour lifetime on our system. To obtain a new token, run the program klog. It will prompt you for a password and grant you a new token.
Before logging out of the Leland host you are using, run the command
keeptoken NumberOfHoursWhere NumberOfHOurs is an integer indicating the number of hours you expect your program to run. You can guess generously if you aren't sure.
If you are trying to use rlogin to connect to a Leland host, you will need to have a .klogin file set up in your Leland account.
Assuming you have setup your public directory (see question 4), the following will allow you to use klogin and the other kerberos programs:
cd
echo "$USER@IR.STANFORD.EDU" >! public/.klogin
ln -s public/.klogin
You can then run "klogin hostname" to rlogin to another host. "ktelnet hostname" will give you the kerberized equivalent of telnet. In neither case will you need to provide your password to connect to the new machine.
The .klogin file makes the
.rhosts file unnecessary. If you need to
use rlogin for machines which do not run the kerberized rlogin
daemon, you need to run klog after you rlogin. A convenient way
to do this is to add the following to your interactive portion of
your .cshrc file:
(tokens | egrep Expires >! /dev/null) || klog &&
rehash
For this to work, your .cshrc and .rhosts files need to be world-readable.
MacX utilizes remote commands, so it shares problems similar to that of a .rhosts file. It is still possible to use MacX with Kerberos, though, as follows:
tcsh6.05 has AFS support to enable this feature. It also supports the tcsh variable "afsuser" if your local username is different than your afs username.
Use symbolic links (i.e., "ln -s"), not hard links. AFS currently only has ACLs for directories, so it would be ambiguous to allow hard links to files in different directories.
No. When DFS comes out in a few years, permissions will be by file, not directory.
Try posting your question to su.computers.afs or mailing consult@leland. If no one there knows the answer, then mail afs-help@leland.
To AFS Main Page
