(See also the very brief Useful AFS Information, also accessible via the helpafs command in unix. Also the description of Installing the Windows AFS client and Using the Windows AFS client.)
The CABI unix computers use the Andrew File System (AFS). This file system resides on CABI's IBM and Linux file servers. The file system can be accessed from all the other CABI computers ("clients"). MRI data acquired on any of our MR systems can be saved to the AFS filespace and accessed from a Sun or Linux workstation or a Windows PC for subsequent image processing and display. Data can be shared between users collaborating on projects, without the inconvenience of having to manually copy data from computer to computer.
AFS provides enhancements over conventional unix file systems, including greater flexibility in file sharing and increased protection of data. For example, you can specify which users or groups of users can access your data, and there are more file permissions than in conventional unix. (Normally in unix you can give permissions to only one of a number of groups which have been set up by the system administrator, plus separate permissions to a group which includes everyone else.)
With the new file system come some new commands, which are described in great detail in the IBM AFS User Guide. (Those who are not a member of CABI can get to the IBM AFS User Guide on IBM's website.) A brief introduction and several examples are given here in order to help CABI computer users become familiar with AFS.
When you log into a unix or linux computer with AFS, you receive a token, which is a unique identifier. AFS uses this to authenticate you when you try to do things like copy files, write files, etc. Your token is valid for 25 hours after you log in; then it expires. If you need to be on a computer for more than 25 hours, or if you run a program for more than 25 hours, you need to renew your token with the klog command before it expires.
When you log into the Windows AFS client you also receive a token which lasts for 25 hours. You can renew it by clicking on the "Obtain New Tokens..." button in the AFS client window. If you log into AFS via Network Neighborhood on Windows (through a CABI unix computer) there is no way to renew the token.
AFS is a global and distributed file system. When you log into an AFS client, you have access to the same files, no matter which computer you are using. Disk space on all AFS fileservers are combined to create the AFS filespace. Some programs (for example, those in /usr/local) reside on every fileserver. All fileservers share the file serving workload: If one server is being used more heavily than the others, it will shift some of the burden onto the other servers.
On each client (with the exception of PCs running Windows 95/98), there is a disk cache which speeds up file access. When you read a file from the AFS file system, it is first copied from a fileserver to the local disk cache on the client that you are using, and you work on the local copy of that file. When you change the file and save changes, the changes are saved locally on the client. As a result data processing should be faster than it was previously when changes to files had to be saved on the old server. In addition, if the server or the network goes down temporarily you can still work on the file locally. When you close the file, the copy on the server will be updated.
Note: With some programs, the 'save' command actually saves, closes, and reopens the file, in which case the copy on the server will be updated every time you save the file. As with any other shared file system, if you are working on a file for a long time, it would be wise to close it and reopen it again every so often (maybe every half hour) in order to make sure that the server copy is updated. That way, if the network goes down for some reason, you will be sure to have a recent copy on the server.
Sites running AFS are in domains called cells. Our cell is cabi.rfmh.org. Following AFS convention, the unix path to our cell is /afs/cabi.rfmh.org. (We have created a link to it called /afs/cabi. In windows, it is afs-cabi.) If we didn’t have the firewall, we would be able to see other cells, for example /afs/widgets-r-us.com, in one global filesystem. We could share data with other sites, depending on how the permissions are set on the directories (see below).
In unix a file (or directory) is owned by a user and by a group, and it has permissions which determine what kind of access (read, write, or execute) the user, the group, and everyone else has for that file. In addition, files in your account can be owned by someone else. Groups are created and modified by the system administrator.
In AFS, you own all the files and subdirectories in your account, and you can determine who gets access to your files. You can create your own groups of people, and then give them permissions to your files. For example, you can have a group of people who can change a file, and another group of people who can just read the file.
File permissions in AFS are assigned to directories, not to individual files. Each file in a directory has the permissions of that directory. AFS keeps track of the directory permissions in a special database. The permissions for each directory are stored in an Access Control List. The types of permissions are:
l: users can list files in directory (for example with ls
command). This permission acts as a gateway: those without
"l" permission on a directory cannot see the files in
that directory or any of its subdirectories.
r: users can read files in directory
i: users can put files in a directory
d: users can delete files in a directory
w: users can modify files in a directory
k: users can lock files in a directory
a: users can administer directory (for example, they can change
the ACL)
read: synonym for rl -- this is the normal unix r permission
write: synonym for rlidwk -- this is the normal unix w permission
Note: The "l" permission is a very limited permission. You can list files with ls, but you cannot get statistics on the files (such as file type or modification date) with "ls -l" or "ls -F" if you have only "l" permission. We have found that the file manager in Linux (probably also Sun) is very slow showing files in directories for which you only have "l" permission. We recommend that you give "read" permission to anyone that you collaborate with; or you can give "read" permission to anyone with a valid token (ie, anyone who is logged in to our AFS filesystem). See the examples below.
You can list the permissions of a directory with the fs listacl command, and you can set permissions with the fs setacl command. To give someone read permission on the current directory, use fs setacl . <username> read.
In AFS you can create groups of users and set their permissions for directories that you own. You create them with the pts creategroup command. Add users to the group with the pts adduser command, and view group memberships with the pts membership command. Groups are named as <owner>:<groupname>, where <owner> is the owner of the group. The system has two groups called
system:administrator = the AFS administrator (usually the
computer systems administrator)
system:authuser = anyone who has a valid token (anyone logged
into AFS)
system:anyuser = anyone who can get to the AFS space but who does
not have a valid token
Each user’s home directory is a separate volume, with a fixed amount of space (1 GB). Some users have subdirectories called dv01, dv02, etc., which are separate volumes and have extra disk space. (Users or protocols which have bought hard disks for golem get extra space.) In order to see how much of your quota is being used in a volume, use the fs quota or fs listquota command.
All home directories have a subdirectory called Backup. Backup is a read-only copy of your home directory from the day before. You cannot change files in Backup. Every night (at 1 AM) the Backup subdirectory is updated. If you accidently delete an important file in your home directory, you can retrieve yesterday’s copy from Backup. (Your Backup subdirectory does not count against your quota.)
AFS has several new commands in addition to unix commands. Some of these are given below. For more information, please see the AFS documentation in the private area of our web site (member password required). There are two “command suites” that are useful for AFS users, fs commands and pts commands.
tokens prints your token
kpasswd change your password
klog renew your token (requires your password)
fs help lists the commands
fs help <command> or fs
<command> -h gets help on a specific command, for
example: fs help listquota
fs quota shows how much of your quota is used in
a volume
fs listquota same but gives more information
fs la (short for fs listacl)
lists the access control list for a directory
fs sa (short for fs setacl)
sets the access control list for a directory
pts help lists the pts commands
pts help <command> or pts
<command> -h gets help on a specific command
pts creategroup creates a group
pts adduser adds a user to a group
pts removeuser removes a user from a group
pts membership <username or groupname>
shows the groups to which the user belongs, or the users which
belong to a group
chmodafs changes the access control list for a
directory and all of its subdirectories (fs sa
works only on the specified directory).
Usage: chmodafs
<start directory> <user/group> <acl>
[<user2/group2> <acl2> ...] (see example
below, Task 5)
Note that chmodafs does not follow symbolic links. Note also that chmodafs does not change the permissions on any directory named Backup, since your ~/Backup directory is read-only.
Note: In the following examples the user lewis is in his home directory, /afs/cabi/usr/lewis.
[dharma: lewis]$ tokens
Tokens held by the Cache Manager:
User's (AFS ID 112) tokens for afs@cabi.rfmh.org [Expires Jun 30
15:20]
--End of list--
[dharma: lewis]$ fs listquota .
Volume Name Quota Used %Used Partition
user.lewis 1000000 555845 56% 76%
[dharma: lewis]$ fs la .
Access list for . is
Normal rights:
system:administrators rlidwka
system:authuser l
lewis rlidwka
- The . refers to the current directory, and la
is short for listacl.
- According to the AFS online documentation, the full command is fs
listacl -path . - note that you do not need the
"-path", since AFS understands that a directory is
being specified by the position of the "." on the
command line. You could also simply use fs la,
since the current directory is the default.
- User lewis and the system administrator have all permissions on this directory;
they can read and write files, and they can change the
permissions. Everyone else who can get to the AFS filespace and
who has a valid token (anyone who has successfully logged onto a
CABI computer) has list permission.
[dharma: lewis]$ fs sa . system:authuser read
[dharma: lewis]$ fs la .
Access list for . is
Normal rights:
system:administrators rlidwka
system:authuser rl
lewis rlidwka
- Now anyone in the system:authuser group (anyone who can log
into our AFS space) has "read" permission in the
current directory, although they still have just "l"
permission on all of the subdirectories.
- sa is short for setacl.
The full command for setting permissions is fs
setacl -dir <directory>+ -acl <access list entries>+
- note that you can specify multiple directories, in
which case you need the "-dir" and the
"-acl".
[dharma: lewis]$ fs la Share
Access list for Share is
Normal rights:
system:administrators rlidwka
system:authuser l
lewis rlidwka
[dharma: lewis]$ fs la Share/Project1
Access list for Share/Project1 is
Normal rights:
system:administrators rlidwka
system:authuser l
lewis rlidwka
[dharma: lewis]$ chmodafs Share system:authuser read
system:anyuser l
Setting ACLs on directory Share and its subdirectories. ACLs
specified: system:authuser read system:anyuser l
Share
Share/Project1
Share/Project2
[dharma: lewis]$ fs la Share
Access list for Share is
Normal rights:
system:administrators rlidwka
system:authuser rl
system:anyuser l
lewis rlidwka
[dharma: lewis]$ fs la Share/Project1
Access list for Share/Project1 is
Normal rights:
system:administrators rlidwka
system:authuser rl
system:anyuser l
lewis rlidwka
- Now anyone in the system:authuser group (anyone who can log
into our AFS space) has "read" permission in the
directory called "Share" and its subdirectories; any
other user who can reach these directories can now list the files
in those directories.
- chmodafs is very similar to fs
saexcept that it takes only
one directory as its first argument (fs sa
can take multiple directories) and it changes the ACLs for all of
its subdirectories
[dharma: lewis]$ mkdir PerfData
[dharma: lewis]$ fs la PerfData
Access list for PerfData is
Normal rights:
system:administrators rlidwka
system:authuser rl
lewis rlidwka
- By default the permissions of the new subdirectory have the
same permissions as the parent directory
[dharma: lewis]$ pts creategroup lewis:perfpeople
group lewis:perfpeople has id -211
[dharma: lewis]$ pts adduser -user branch hrabe lewis pell -group lewis:perfpeople
[dharma: lewis]$ pts membership lewis:perfpeople
Members of lewis:perfpeople (id: -211) are:
branch
hrabe
lewis
pell
[dharma: lewis]$ fs setacl PerfData system:authuser l lewis:perfpeople write guilfoyl i
[dharma: lewis]$ fs listacl PerfData
Access list for PerfData is
Normal rights:
lewis:perfpeople rlidwk
system:administrators rlidwka
system:authuser l
lewis rlidwka
guilfoyl i
- Anyone who can get to the AFS filespace and has a valid
token (anyone who has successfully logged onto a CABI computer)
has list permission in the directory PerfData; anyone in the
lewis:perfpeople group now has write (and read) permission in the
directory; and user guilfoyl has insert permission and can put
files in the directory.
If you collaborate with others, we recommend that you
|
This page was last updated on 5/23/2005. |