History of AFS on Linux at Fermilab

(aka: Why do the rpm's keep changing?)

When I first joined the computing department, my first task was to get AFS working with Linux. At the time we were just moving to Fermi Linux 5.2.1, which was running a 2.0 kernel. Also at that time, the only option we had was AFS 3.5 supplied by Transarc.

It was determined that we couldn't run AFS on a 2.0 kernel, it had to be at least a 2.2 kernel. Because of this there were scripts written to make the upgrade of a kernel easier. Rpm's were also written to make the installation of AFS easier. These were my first rpm's I'd ever written, and they weren't very good. They got the job done, but didn't uninstall or upgrade very easily. They were also named poorly.

Along came Fermi Linux 6.1.1, and with it the 2.2 kernel. Now people didn't have to upgrade their kernels. I was also getting better at writing rpm's. I had also realized that my rpm's were going out into the world, and that naming them just 'afs' wasn't a good idea. So the rpm's were changed to 'afs-fermi'. These new batch of rpm's were written much better. You could upgrade and uninstall them without too much worry.

Then along came a mess. This mess had a name called 'insmod'. Insmod is the program that sticks kernel modules into and out of the kernel. Transarc insisted that it was broken and we had to put in a new insmod. We did this, and the new insmod did work great. I tested the afs-fermi rpm in a multitude of ways to make sure that it would both install correctly, and uninstall correctly, insmod. But, then along came a security patch for insmod, which went out with autorpm. It not only fixed the security hole, but it fixed the bug that Transarc had complained about. This sounds good, but there was one little problem. I hadn't planned on that. So now, if someone uninstalled these versions of AFS, all sorts of things broke, especially networking.

So here comes Fermi Linux 7.1.1, with the 2.4 kernel. At this point we now had an option. We could use AFS from Transarc or we could use OpenAFS. Transarc wasn't being very timely when coming out with new AFS modules for the new kernels, so we really had no choice but to choose OpenAFS. OpenAFS had come along far enough that it was pretty stable and worked as well as Transarc's. At this point we had a lot of nifty features built into the rpm's and startup scripts, so even though there was prebuilt rpm's, we decided to package our own rpm's. Thus the 'openafs-fermi' rpm's were built.

OpenAFS continued to progress and get better, and kernels continued to get more complicated, so we kept looking at their latest offering. We also had a problem that it was a lot of work for me to keep packaging new versions of 'openafs-fermi' with each new kernel. And then along came the OpenAFS rpm for version 1.2.3. In this rpm they had enough of our custom changes that we could just make some minor changes to their source rpm, and it would work for us. And thus, the rpm's changed once again. But this time it split into three. There was now 'openafs', 'openafs-client', and 'openafs-kernel'. But now a person only needs to recompile our source rpm, and openafs will work with whatever 2.4 kernel they have.

HISTORY