This document presents a basic outline of installing OpenAFS, and is presented to provided general support. You should contact your site administrators for site specific data, and please be aware that this information is only what I've managed to cobble together--your mileage may vary.
Binaries and source code for OpenAFS are provided from OpenAFS.org. It is said in many places that it's not hard to build, but I've had little luck, so I recommend you stick to the binaries.
That being said, since they include some additional features that aid afs administration, I tend to prefer David Botsch's builds, available at http://cf.ccmr.cornell.edu/publicdownloads/afs. Thus far, I've had good success installing the latest version he's provided, and then using the binary from OpenAFS.org to update the installation. At the time of this writing, he's got 1.2.10 up. (I don't recommend his mount_afs app for the unitiated tho, it will crash your machine if AFS is already mounted!).
Assuming you're using the binary package, it's a straight forward installation--you just run the installer as you would for any other package. The installer will do the following:
Depending on which version you're installing and whether this is a brand new installation or an upgrade, you might be prompted for your home cell name and cell server's IP numbers. If so, the information below may help. The two things AFS needs to know are what is your home cell, and where are that cell's database servers.
First, you'll need to add your home cell name to the ThisCell file. Using a text editor (in this example, I'm using vi) and as root, open the file:
sudo vi /var/db/openafs/etc/ThisCell
Put a single line in this file with your cell name, eg. isis.unc.edu for isis users, or cs.unc.edu for foblockquotlks using the UNC Comp Sci cell.
Next, you'll need to make sure that the cells you want to use are listed in the CellServDB file. Again as root, make a backup of the current CellServDB file, and then open it with a text editor:
sudo /var/db/openafs/etc/CellServDB /var/db/openafs/etc/CellServDB.orig sudo vi /var/db/openafs/etc/CellServDB
Then add your cell data to the file (if you don't know this, you may have to contact your site administrators).
>isis.unc.edu # University of North Carolina Project Isis 152.2.1.5 #db0.isis.unc.edu 152.2.1.6 #db1.isis.unc.edu 152.2.1.7 #db2.isis.unc.edu
Then save the changes. Your basic configuration is complete, and you can reboot and try them out. If everything worked, once you've booted the machine (on the network, afs doesn't start if there's no network!), you should have a /afs subdirectory in the command line and "server" named AFS in Finder. You'll need to run klog from a terminal window and provide your afs id and password to access your files, however.∂
Finder doesn't know shinola about afs--to Finder, it's just like a local hard disk. So if you're mobile, or on a wireless connection, or using dialup, or just on an iffy network connection, Finder can freak out trying to access directories and files in afs space. New installations (1.2.10 and later) don't have as much trouble as earlier versions, since by default they include some features not present in earlier versions, but if you're having problems, here's something to try. When it starts up, afs will look for an afsd.options file, and if it finds one, it will read that file for flags to use with the afsd program. So as root, you can create that file, and put in an appropriate line, thusly:
sudo vi /var/db/openafs/etc/config/afsd.options
Add the following line:
-fakestat-all -afsdb -stat 2000 -dcache 800 -daemons 3 -volumes 70 -rootvol root.afs
The first flag is the most important. Since Finder doesn't know about afs permissions, only unix permissions, Finder will try to read directories it doesn't have afs permission to access. And it takes a very long time to give up. fakestat-all tells afs to fake directory information for all of the mountpoints, so Finder won't hang when you access /afs. This means you can use a full CellServDB file with no ill effects. The -afsdb flag tells afs to try to use dns services to local afs servers, rather than just relying on teh CellServDB file. This is a good thing.
There is another flag you may want to use in this line, -dynroot, which tells afs to build /afs mountpoints dynamically when the system tries to use them. This means that your system won't try to contact a cell's servers until you access that cell, which is better on an iffy network connection or if you're a laptop user. When you use this flag, you will see only those afs server listed in the CellServDB file, but you can try to access any cell by cd'ing or opening that cell--if the cell is listed correctly in their DNS tables, you should be able to open it. You can't use this option if you're using afs space as your OS X home directory, tho, since your home directory won't be mounted when you login (thanks Brian!). Here's a discussion of the dynroot flag from some of the OpenAFS folks.
Please note that Finder will still hang if you don't have a network connection and you try to access afs--it is a network file system, so you need to be on a network connection to use it!
At this point you should be able to perform most all operations from the CLI. But if you try to copy files to and from AFS space from Finder, you may encounter errors. This is probably due to a mismatch in the UID for your accounts. Ideally, you'll want not only your usernames on both your OS X machine and your AFS account to match, but also the UIDs for each.
By default, Mac OS X will start assigning UIDs at 501, so it's most likely that that's what your UID is. If, in a terminal window, you cd to your AFS home space, and do an "ls -l" you'll likely see something like this:
[localhost] hays% cd /afs/cs.unc.edu/home/hays [localhost:cs.unc.edu/home/hays] hays% ls -l total 211 drwxr-xr-x 3 5420 1003 2048 Jul 24 2000 DesktopFolderDB -rw-r--r-- 1 5420 1003 32768 Sep 7 2000 Fall200Scheduler.doc drwxrwxr-x 3 daemon 1003 10240 Feb 12 10:48 autoremedy drwxr-xr-x 2 5420 daemon 2048 Jul 25 2000 bin drwxr-xr-x 2 5420 1003 2048 Sep 21 2000 bin-hp700_hpux
In the listing above, the number 5420 represents the UID in use by hays in AFS space. If you try to copy files via Finder, Finder sees that the local UID and the UID in AFS space do not match, and generates an error. In order to fix this, you need to change your local UID to match the UID in the AFS cell. Warning! This procedure is a bit dangerous--what we're going to do is change the ownership of the files on your system on the file. You should have a good backup before you start this!
pts examine your_username
Make a note of your UID in the afs system.
%su
%find / -xdev -user <old Mac uid> -print -exec chown <AFS uid> {} \;
Give this some time to run, it can take a while. (And thanks to Brian Biswas for coming up with this method.)
You won't want to have to navigate the entire cell's tree regularly, so you'll want to make access easier. There are a couple of things you can do.
ln -s /afs/your.cell.here/path/to/your/afs/space/ /Users/yourlogin/your_choice
That way you can access the afs space from your home directory easily. You can create similar links to any common afs areas, such as department project space.
See the Kerberos Integration doc for information on getting afs tokens automatically.