AFS
From CCGB
AFS is a network filesystem, it will allow you to mount your BX home directory (and other files) from anywhere, as if you were in Wartik on a desktop. To learn about AFS, please consult the OpenAFS User Guide. Since it's very long, I'll suggest that you at least read the Introduction and then refer to the rest of the guide whenever you have questions.
Contents |
New Concepts
Locations
Files available via AFS are mounted in the /afs directory. Inside /afs there can be multiple "cells", a cell name is generally derived from an organization's domain name. The BX cell is 'bx.psu.edu'. Thus, everything available in AFS at BX is mounted at /afs/bx.psu.edu. For example, note that /home is now just a symbolic link to /afs/bx.psu.edu/home:
% ls -ld /home lrwxrwxrwx 1 root root 20 2007-04-25 17:50 /home -> /afs/bx.psu.edu/home
Permissions
AFS mostly ignores traditional UNIX permissions. It has its own (much more powerful) permissions system. In AFS, files do not have their own permissions. Whether or not a file can be read from or written to is determined by the permissions on the file's directory. This means that doing a traditional UNIX operation like:
% ls -l foo.txt -rw-r--r-- 1 nate nate 0 2007-05-31 13:20 foo.txt % chmod 600 foo.txt % ls -l foo.txt -rw------- 1 nate nate 0 2007-05-31 13:20 foo.txt
Will have no real effect. The file's mode bits are changed, but they will be ignored as far as actual access is concerned. If the directory containing foo.txt has permissions allowing all users to read it, then users will still be able to read foo.txt. You can change AFS permissions with the fs command. See fs help or man fs for more information than is provided here.
There is one caveat to file permissions: the owner bits have some effect on a file. This is explained in the OpenAFS Admin Manual.
Here are the permissions set on my home directory:
% fs listacl /afs/bx.psu.edu/home/nate Access list for /afs/bx.psu.edu/home/nate is Normal rights: system:administrators rlidwka system:authuser rl www-data rl postfix rl dovecot rl tsm rl nate rlidwka
The users and groups shown above are explained in more detail below:
system: groups
AFS has 3 special groups, system:administrators, system:authuser and system:anyuser. system:administrators contains anyone with an admin token (you can get the list of admins with the command pts membership system:administrators). system:authuser is anyone with tokens at all (aka any authenticated BX user). system:anyuser is any unauthenticated user. Note that giving system:anyuser read access to a directory will have no effect since system:anyuser cannot access the higher-level /afs/bx.psu.edu/home directory.
www-data
www-data needs read access to /afs/bx.psu.edu/home/nate and my public_html/ directory in order to serve webpages. The default permissions on ~/public_html are:
% fs listacl /afs/bx.psu.edu/home/nate/public_html Access list for /afs/bx.psu.edu/home/nate/public_html is Normal rights: system:administrators rlidwka system:authuser rl www-data rl nate rlidwka
If I want to prevent a directory in ~/public_html/ from being accessible on the web, I can remove www-data's access to that directory. Note that simply giving www-data no permission will not work since www-data is also a member of system:authuser. There are two ways to properly remove access for a specific user from a directory.
This removes www-data's access AND all other BX users' access:
% fs setacl /afs/bx.psu.edu/home/nate/public_html/private www-data none system:authuser none % fs listacl /afs/bx.psu.edu/home/nate/public_html/private Access list for /afs/bx.psu.edu/home/nate/public_html/private is Normal rights: system:administrators rlidwka nate rlidwka
This removes www-data's access but not other BX users' access. When specifying negative permissions, you list those permissions which you do NOT want the specified user or group to have:
% fs setacl /afs/bx.psu.edu/home/nate/public_html/private www-data none % fs setacl /afs/bx.psu.edu/home/nate/public_html/private www-data all -negative % fs listacl /afs/bx.psu.edu/home/nate/public_html/private Access list for /afs/bx.psu.edu/home/nate/public_html/private is Normal rights: system:administrators rlidwka system:authuser rl nate rlidwka Negative rights: www-data rlidwka
Note that giving www-data access but removing system:authuser's access allows you to place something on the web that regular BX users can't see on the local filesystem. This was not possible with NFS.
dovecot and postfix
Dovecot is the POP/IMAP server and Postfix is the SMTP server. Dovecot is how you read your mail and Postfix is how your mail is delivered to you. These programs need the ability to write to your ~/Maildir directory:
% fs listacl /afs/bx.psu.edu/home/nate/Maildir Access list for /afs/bx.psu.edu/home/nate/Maildir is Normal rights: system:administrators rlidwka postfix rlidwk dovecot rlidwk nate rlidwka
You should not remove postfix's privileges on your Maildir, or mail sent to you will be rejected. You should not remove dovecot's privileges, or you will not be able to read your mail.
tsm
tsm is the backup server. You should only remove tsm's privileges from a directory if you do not want it to be backed up. Note that the same caveats about system:authuser apply as they do with the www-data user. Simply removing tsm's read access to a directory will not prevent tsm from being able to read it unless you also apply negative privileges, or remove system:authuser's access to the directory.
Tokens
You acquire AFS tokens by first acquiring Kerberos tickets:
% kinit Please enter the password for nate@BX.PSU.EDU: % aklog % tokens Tokens held by the Cache Manager: User's (AFS ID 2048) tokens for afs@bx.psu.edu [Expires Jun 1 13:09] --End of list--
AFS allows you to acquire tokens without a password since it uses your Kerberos TGT to verify your identity. Without AFS tokens, you are only allowed to access directories accessible to system:anyuser (which at BX is none).
On BX workstations, you will automatically acquire AFS tokens when you log in. On Mac OS X workstations, you'll also get new AFS tokens when you type your password in to the screen saver. On Ubuntu/Debian workstations, you will not get an AFS token when typing your password in the screen saver unless you open a terminal and type aklog. I plan to eventually have a workaround for this.
Groups
AFS gives you the ability to create your own groups, unlike previous filesystems where only administrators could create groups. Let's say that I have a directory to which I want to give Bob, Rico and Cathy read-only access. In addition, I want to give Minmei, Belinda and Aakrosh read/write access. I create the directory:
% cd /afs/bx.psu.edu/home/nate % mkdir collab
Now I create my groups with the pts command:
% pts creategroup nate:collab-read group nate:collab-read has id -209 % pts creategroup nate:collab-write group nate:collab-write has id -210 % pts listowned nate Groups owned by nate (id: 2048) are: nate:collab-write nate:collab-read
Add users to my new groups:
% pts adduser -user rsharris -user rico -user cathy -group nate:collab-read % pts adduser -user mhou -user giardine -user ratan -group nate:collab-write % pts membership nate:collab-read Members of nate:collab-read (id: -209) are: rsharris rico cathy % pts membership nate:collab-write Members of nate:collab-write (id: -210) are: ratan giardine mhou
Finally, I set appropriate permissions on my collab/ directory:
% fs setacl collab nate:collab-write write nate:collab-read read system:authuser none % fs listacl collab Access list for collab is Normal rights: nate:collab-write rlidwk nate:collab-read rl system:administrators rlidwka ... nate rlidwka
Laptops
This also applies to your own personal systems at home. You can access AFS from any system with an AFS client, anywhere.
Laptops can access AFS directly by installing/configuring Kerberos and then installing/configuring the OpenAFS client. I'll have the procedure up here shortly.
Best Practices
There are a few behaviors you may need to change to work with AFS effectively.
Login time
If you remain logged in for more than 24 hours without renewing your tickets and tokens (either via typing your password in the screen saver's password dialog or via kinit -R; aklog), your home directory will become inaccessible. This is generally bad for applications (especially Mac Mail). Therefore, it's best to get in the habit of saving and quitting most applications before leaving for the day, in case you don't return to your workstation within the next 24 hours. Issuing a kinit -R; aklog right before leaving will give you 24 hours from when you leave to return (instead of 24 hours from the last time you logged in via the screen saver or login window, which might have been early in the morning).
If you don't plan to be back at your workstation within 24 hours, log out or use k5max, described below.
Long running programs
Long running programs will encounter problems after 24 hours when tokens expire and your home directory becomes unreadable. There is a solution to this problem. Tickets can be renewed without a password for 7 days. If you simply start something that will keep your ticket renewed (and then fetches new AFS tokens) before it expires, you can run programs as long as a week without intervention. There's an easy script to do this which you can find in your path (if you want to look at it, it's housed at /afs/bx.psu.edu/misc/apps/bin/k5max.
Acquire renewable tickets via kinit (this is the default anyway, most likely you already have them) and then run this script. It'll wake up every hour to renew your ticket, and will keep doing so until it's killed or the ticket's renewable life is reached.
Note that k5max will die if you disconnect from the terminal (even if you background it with k5max &). The easy solution to this is to start long-running processes inside screen, which allows you to disconnect from the terminal (and the entire machine). Start the screen from a pagsh so you get a new, unique PAG (PAGs are discussed in the AFS User's Guide). A script that does this for you is in your path - to use it, simply execute pagscr:
% pagscr
... a screen session starts ...
% klist # just making sure the tickets expire in 24 hours, and have a 7 day renewable lifetime
Ticket cache: FILE:/tmp/krb5cc_2048_V30704
Default principal: nate@BX.PSU.EDU
Valid starting Expires Service principal
06/05/07 15:50:24 06/06/07 15:50:22 krbtgt/BX.PSU.EDU@BX.PSU.EDU
renew until 06/12/07 15:50:22
Kerberos 4 ticket cache: /tmp/tkt2048
klist: You have no tickets cached
% tokens
Tokens held by the Cache Manager:
User's (AFS ID 2048) tokens for afs@bx.psu.edu [Expires Jun 6 15:50]
--End of list--
% k5max &
% ./foo.py & # this is my long-running program
"Detach" from the session with <CTRL>-a followed by d. You can now kill the terminal, log out, etc. "Attach" to the session by logging back in to the system and executing screen -r. For more information, refer the Screen User's Manual.
Why??
Feel free to skip this if you aren't interested in WHY we're moving to AFS.
Performance
AFS clients run a Cache Manager process which keeps files you're accessing a lot locally on the client. It writes changes back to the AFS server, but unlike NFS, it does not need to maintain constant communication with the server for every single file operation. This improves performance over NFS.
Accessibility
With AFS, you can access your files from anywhere as if they were local. You'll need Kerberos and the OpenAFS client (both are easily obtainable on all common OS'), and then it's as simple as:
laptop% kinit; aklog Please enter the password for nate@BX.PSU.EDU: laptop% cd /afs/bx.psu.edu/home/nate ...
Security
AFS uses Kerberos to verify your identity. NFS has no method to verify your identity, so there was no way to safely serve files over NFS to untrusted clients. AFS also offers some basic data encryption between client and server.
Mac OS X Bug
Mac OS X has a long-standing unresolved bug that can cause the system to freeze when the NFS server housing your home directory becomes slow or unresponsive. AFS does not suffer from this problem.
