Contact your AFS Site Contact. Only AFS Site Contacts can obtain Linux-AFS from the Transarc Distribution site:
/afs/transarc.com/public/afs-contrib/bin/linux.client
Sites outside the US must sign a form and use:
/afs/transarc.com/public/afs-contrib/bin.export/linux.client.export
Does your site currently have AFS at all? If not, then you cannot get Linux-AFS -- you must have a licence with Transarc for AFS itself. If you do have AFS, then your site should have an AFS Site Contact; contact your system administrators to find out who this might be.
Only sites that already have AFS may obtain Linux-AFS.
If you really don't have a site contact and you want to use an AFS client (for instance if you want to browse public files stored in AFS) use Arla.
The latest version for kernels 2.0.35-.36 is availible as an RPM, it's name being afs-3.3a-2.0.35.i386.rpm. Slackware users will need to use the rpm2tgz program to convert it over, since Derek will no longer be tossing out tarballs (.tar.gz/.tgz files) or get alien or something similar.
Older versions match related kernel versions according to this chart:
---------RPMS's only from now on-------------
2.0.34 is not supported because some inode code has changed, and it will not work properly. Alan Cox (head of stable kernel maintance) fixed that in 2.0.35. Developmental kernel versions (2.1.xxx) are not supported, including the modules-2.1.xxx utilities used on 2.0.x kernels.
Nine times out of ten you will have to recompile your 2.0.x kernel with the modules 2.0.x utlilites pack and turn kernel versioning on.
2.0.36 requires you to use insmod -f to load the modules and to have libafs.2.0.36.o symlinked to libafs.2.0.35.o .
2.2.x kernels have AFS 3.5 availible from Transarc directly. There are patches for different kernels availible through a contrib directory. If you are also looking for the backup programs, they are included in AFS 3.5. Transarc should have information on which build to get for which kernel.
From Matthew D. Langston:
Hello all,
Since December of 1997 (when RedHat Software released RedHat Linux 5.0) many people using RedHat Linux 5.0 and 5.1 have had trouble getting Derek's afs-3.3a-2.0.32.i386.rpm port of AFS for Linux to work properly due to problems with Linux's versioned kernel symbols. Much advice (both good and not so good) has been given on the linux-afs list about the procedure to get linux-afs to work properly with modutils 2.1.x (which comes with both RedHat Linux 5.0 and 5.1) and with Linux kernel 2.0.34 (which comes with RedHat 5.1).
The purpose of this post is to (hopefully) clear up some confusion about the procedures espoused on the linux-afs list which attempt to address the `versioned kernel symbols' problem. Although the advice given in this post is covered somewhat by section 2.3 of the linux-afs FAQ (http://www.umlug.umd.edu/linuxafs/), the `versioned kernel symbols' problem is asked (and answered) often enough on the linux-afs list that I thought a little more detail concerning this issue might be helpful. Perhaps some of what follows should be included in the linux-afs FAQ. [It already has -STrw]
There have been several posts to the linux-afs list which suggest that recompiling the Linux kernel with `CONFIG_MODVERSIONS' set to `n' (where n == no, or disabled) will fix the linux-afs `versioned kernel symbols' problem. Even though this does (unfortunately) work for Linux kernel 2.0.32, it is still *not* a good thing to do. What follows is an explanation of why you should consider always compiling your Linux kernels with `CONFIG_MODVERSIONS' set to `y' (where y == yes, or enabled).
1) The Linux kernel developers created versioned kernel symbols for a very good reason, one of which was to purposefully break kernel modules (e.g. `libafs.o' from afs-3.3a-2.0.32.i386.rpm) for kernels they weren't supposed to run on (e.g. Linux kernel 2.0.34).
2) Derek purposefully built afs-3.3a-2.0.32.i386.rpm to use versioned kernel symbols so that the kernel module `libafs.o' could be *safely* used across multiple versions of the Linux kernel. This will make `libafs.o' break when it should break (e.g. on Linux kernel 2.0.34), and run when it should run (e.g. on Linux kernel 2.0.32).
Enabling versioned kernel symbols when you compile your linux kernel is a *good thing*. This allows people who write kernel modules to use versioned kernel symbols if they want to (as Derek did), while allowing module writers to not use versioned kernel symbols if they don't want to. Although versioned kernel symbols are important for most kernel modules, they are particularly important for filesystem kernel modules.
Unfortunately, RedHat Software did a *really bad thing* when they released RedHat Linux 5.0 and 5.1 by replacing `modules-2.0.0' with `modutils-2.1.x'. `modules-2.0.0' is intended for use with the 2.0.x series of Linux kernels (which includes RedHat Linux 5.0 and 5.1), while `modutils-2.1.x' is intended for use with the 2.1.x (and 2.2.x) series of Linux kernels.
When RedHat Software replaced `modules-2.0.0' with `modutils-2.1.x', they broke binary compatibility for *all* kernel modules (e.g. libafs.o) that were supposed to work across multiple versions of Linux 2.0.x kernels. Shame on RedHat Software.
I would suggest that anyone who wants to use RedHat Linux 5.x with afs-3.3a-2.0.32.i386.rpm should do the following (in this order):
1) Replace `/sbin/genksyms' from `modutils-2.1.x' with `genksyms' from `modules-2.0.0'. There are two ways to do this. You can do this by completely removing `modutils-2.1.x' and replacing it with `modules-2.0.0'. For example:
$ rpm --nodeps -e modutils $ rpm -Uvh modules-2.0.0-1.i386.rpm
Alternatively (and in my opinion a slightly better idea), you can simply compile `genksyms' from the modules-2.0.0 distribution and place it in `/sbin' (thereby replacing the previous version of genksyms). For example:
$ cd modules-2.0.0/genksyms/ $ make $ mv /sbin/genksyms /sbin/genksyms.orig $ mv genksyms /sbin/genksyms/
I have also temporarily made an RPM of just genksyms (from the modules-2.0.0 distribution) available at ftp://ftp.slac.stanford.edu/users/langston/genksyms-2.0.0-1.i386.rpm
If you want to use this RPM (instead of compiling genksyms yourself), then do the following:
$ mv /sbin/genksyms /sbin/genksyms.orig $ mv /usr/man/man8/genksyms.8 /usr/man/man8/genksyms.8.orig $ rpm -Uvh --replacefiles ftp://ftp.slac.stanford.edu/users/langston/genksym s-2.0.0-1.i386.rpm
2) Use Linux kernel 2.0.32, and compile the kernel with `CONFIG_MODVERSIONS' set to `y'. Make sure to start from a canonicalized Linux kernel 2.0.32 source tree. For example:
$ cd linux $ make mrproper $ make menuconfig $ make dep $ make clean $ make zImage $ make modules $ make modules_install
It has been reported that afs-3.3a-2.0.32.i386.rpm will work with Linux kernel 2.0.33. I have not verified this, but now that you are using versioned kernel symbols with the `genksyms' from the modules-2.0.0 distribution (you are, aren't you?), it is easy enough for you to verify. Simply compile Linux kernel 2.0.33 with `CONFIG_MODVERSIONS' set to `y', and then try to use afs with it. If afs doesn't work, then its not supposed to work with Linux kernel 2.0.33.
I have verified that afs-3.3a-2.0.32.i386.rpm *should not be used* with Linux kernel 2.0.34. For example, here is what happens when I try to start afs under Linux kernel 2.0.34:
$ /etc/rc.d/init.d/afs start > afs.log 2>&1 libafs.o: unresolved symbol register_filesystem_R0c94bf58 libafs.o: unresolved symbol current_set_Ra3aab10f libafs.o: unresolved symbol __iget_R2986b63e libafs.o: unresolved symbol sleep_on_Rf6402ad8 libafs.o: unresolved symbol wake_up_R61177642 libafs.o: unresolved symbol interruptible_sleep_on_Ra9abd0e7 libafs.o: unresolved symbol iput_R2747137a libafs.o: unresolved symbol open_namei_Ra5d5975b libafs.o: unresolved symbol lnamei_R06eb3c3f libafs.o: unresolved symbol invalidate_inode_pages_Rcaf591e2 libafs.o: unresolved symbol namei_R5465020e libafs.o: unresolved symbol generic_file_mmap_R1785b460 libafs.o: unresolved symbol unregister_filesystem_Reabc6c6e
Do you see all of those unresolved references to symbols? Those are the names of Linux kernel functions, data structures, etc. that the libafs.o kernel module uses, and are known as `versioned kernel symbols'. These symbols are unresolved because they don't exists in Linux kernel 2.0.34.
For example, the first unresolved symbol is `register_filesystem_R0c94bf58'. This is a Linux 2.0.32 kernel function named `register_filesystem' whose function prototype is defined in `linux/include/linux/fs.h'.
The number that is appended onto the end (i.e. `_R0c94bf58'), is a unique kernel version number that is completely determined by the function prototype of `register_filesystem'. Since the function prototype of `register_filesystem' depends on `struct inode', and `struct inode' changed between Linux kernels 2.0.32 and 2.0.34, we would expect that the two versioned kernel symbols for `register_filesystem' would be different, and in fact they are:
It is my hope that this has helped the linux-afs community understand just how valuable and important versioned kernel symbols are. I also hope that this has helped anyone who needs to get linux-afs running under RedHat Linux 5.0 or 5.1.
--Matt
Matt has also thrown on the fire a patch to remove ax25 support from the kernel (in the sence that it just doesn't compile). It's a one line fix of /usr/src/linux/net/Makefile, but it has only been tested on a 2.0.35 kernel.
From Derek, on May 12:
I'm working on the AFS Server port. The problem is that it requires changes to the stock Linux kernel and ext2 FS support subsystem. I'm working with the Ext2 team to get this support into the mainline kernel. I cannot release servers until this is done, which I suspect wont happen until later in the 2.1 series. This means we will _hopefully_ have server support for Linux 2.2.
More on this from Jeffrey Hutzelman on Aug 9 1997:
There is an AFS server port for Linux in progress. It's not being released yet because it still has some instabilities, and requires patches to the e2fs code in the kernel. We hope the necessary e2fs changes will appear in Linux 2.2, but there are several factors that might delay it. As far as licensing goes, I must presume that terms will be similar to whatever is in your current AFS license agreement. Generally, sites either have an agreement for N fileservers, or for an unlimited number of fileservers. I suspect UMich has the latter, but I don't know - that would be a question to ask your AFS site contact. Also, bear in mind that AFS is not NFS. You can't just set up standalone servers, and you can't set up a server in an existing cell without knowing certain secrets (mostly, the key for afs@CELL), which administrators of any existing cells are unlikely to share. You could set up your own cell, but even that would require some cooperation from your AFS site contact, who would need to provide you with a license file.
Yes! Starting with kernel 2.0.32, a race condition that AFS seemed to have triggered was fixed and Derek put in a libafs.smp.o module into each release. Upgrade the kernel to 2.0.32 and instead of insmod libafs.o, use insmod libafs.smp.o instead.
NO! Development kernels are for that -- kernel development. They're changing too often, so Derek won't support them. When 2.2.x is released, Derek will put out a new version.
Linux-AFS is either a port of AFS 3.3 or 3.3a. The archive you choose will tell you on it's name which version it is.
Jeff writes:
I heard on Slashdot that Transarc has AFS 3.5 ready to come out, and it'll release it for all platforms at once, including Linux. Is this true? Derek? Anyone from Transarc?
The slashdot article is a bit misleading, and the PC Week article they link to even more so. Let me try to correct a few misconceptions that may arrive from those...
Have you read the README file? Transarc releases one with instructions on how to install the package. But if you're impatient:
Older releases:
cd / tar xzfv afs-XXX.tar.gz
where XXX is the remainder of the filename, usually the release number. If you are running RedHat's RPM, grab an rpm package and install as usual. Slackware users running 2.0.32 will need to grab rpm2tgz and convert the rpm's first. (Can anyone take over making Slackware packages?)
You'll then need to put /bin/athena and /usr/athena/bin into your path in order to use the AFS client binaries. Also, edit /usr/vice/etc/ThisCell to only contain the name of your AFS cell. If you are from the University of Maryland, you can put in either glue.umd.edu or wam.umd.edu.
You may want to tweek the cache size some. Look below.
For AFS 3.5 Transarc provides really good installation instructions . These probably come with the distribution, but they're also available at Transarc's page.
An Linux Alpha port should be availible at this time. If not, bug Derek, he actually did the port.
Linux Sparc ports are ready, but haven't been packaged yet as of last mail from Derek. Bug him again about it.
PowerPC (MkLinux/LinuxPPC) ports are on hold until the 2.2.x kernels.
There are vague plans at UMich on porting it.
The Arla developers should have some code for doing it with Arla, so check there.
/afs/citi.umich.edu/user/archive/pub/techreports/reports/citi-tr-95-11 .*
is probably a good place to start if you don't know about Disconnected AFS (which is similar to a feature in Coda).
This isn't exactly a Linux specific question, but is does get asked a lot.
Basically, when ssh runs it has no AFS permissions, so it can't read your home directory. You can get around this by fiddling with permissions, except then when you log in you won't be able to read your home directory, since you won't have authenticated with afs.
Therefore there are three things you need to do to really make this work:
How to install AFS or Arla is covered elsewhere in the FAQ.
The AFS patch for SSH is available here here.. You will need to download the ssh source, patch it with this patch, and then run configure with the --with-krb4 --with-afs flags.
OpenSSH comes with AFS support. Simply download it, run configure with the --with-kerberos4 --with-afs flags, make and make install.
You will also need to edit your ssh_config file to allow KerberosTgtPassing and AFSTokenPassing.
Once you have SSH installed with AFS support, ssh into the remote machine so that you can set the correct permisions on the .ssh directory. You need to make your authorized_keys file world readable, but don't want your private key to be visible. so you need to create a second directory called something like .sshident, and move everything in your .ssh directory, except your authorized_keys file, here, symlinking it to its original location.
Then from your home directory run these commands:
fs sa . system:anyuser l fs sa .ssh system:anyuser lr fs sa .sshident system:anyuser none
Log out from the remote computer. Make sure AFS is running properly on you local computer, and that you have permissions (run klog). Then try ssh'ing into the remote computer again. This time it should work.