OpenAFS RPMs for Fedora Core 3:

 Name                    Last modified      Size  Description
 Parent Directory                             -    
 older/                  2006-05-14 23:22    -   
 openafs.spec            2005-12-08 09:42   18K  spec file

Thu, Dec 8, 2005: Updated with in-progress specfile for FC5. Sorry about the lack of updates for a while there.

Sun, Aug 28, 2005: Okay, sorry no update in a while. Waiting for the next supposed-to-be-non-weird kernel update for FC3.

Fri, Jul 15, 2005: Oh, that's exciting — the 2.6.12 kernel for FC3 now does the -devel subpackage thing just like FC4 and RHEL4. Oh what fun…

Thu, Jun 30, 2005: there's discussion on the Fedora Packageing mailing list about the best general way to package external kernel modules; I'm following that and will use the results to make a FC4 package, which I'll then submit to Fedora Extras….

This is a work in progress -- not only is it a brand-new package of a complicated program, it's a bleeding edge snapshot of that program itself. I very much welcome feedback and improvements.

This is basically a developers-only release. I've included binary RPMs for your convenience, but that doesn't mean they're perfect. Please report crashes on the openafs-devel list, and packaging problems to me. (Note that unlike earlier versions, this package includes working SMP support. Additional feedback on that would be particularly appreciated. To save space and build time, the packages here only include the kernel modules for the latest errata kernel at the time they were built -- currently 2.6.11-1.27_FC3.)

These packages are now built on Fedora Core 3, due to popular (three people) demand. "Backporting" to Fedora Core 2 should be a simple matter of changing the kernel headers and rebuilding.

I need help improving this package. Please see the to-do list below. Or, help with things not on the list. I'm not picky.

Save time and bandwidth and don't download the debuginfo package unless you know what it is and you need it.

These RPMs have been signed with the BU Linux GPG key.

Readme:

This is a new RPM for OpenAFS. It's somewhat based on the old openafs.org
packages, somewhat based on my older BU Linux RPMs, but mostly all-new.

I've created it with the goal of having a very nice package specifically for
BU Linux 4.0 / Fedora Core 2. This differs somewhat from the openafs.org
packages, which aim to be as portable as possible. In general, I've tried to
follow Red Hat / Fedora conventions, and haven't considered how this may
work on SuSE, Mandrake, and so on. This isn't to disparage those distros at
all -- they're just not the target.

I've endeavored to remove as much "magic" as possible from the spec file,
and from the init script, which I've largely rewritten. In general, I'm all
for computers doing magic, but a straightforward process is easier to keep
clean and easier to debug.

OpenAFS has been configured to use Linux standard paths instead of the old
Transarc ones. This is really nothing special, as it's the default. The
cache is likewise put at /var/cache/afs.

Also, the init script and sysconfig file no longer start the server --
they're just for the client options. Instead of having AFS_CLIENT/AFS_SERVER
on/off settings, these should be separately controlled through their own
scripts and chkconfig. I've left the actual 'make the server go' part for
later, as I don't actually run the server here.

I have far fewer subpackages than the openafs.org packages. Here's what
happened to the missing ones:

  -compat: I don't think this is widely necessary anymore. Compatibility
           symlinks can be put into place on a site-local basis, or legacy
           scripts fixed.

  -kernel: merged into openafs-client

  -kernel-source: removed, as there's some weirdness with the 'make
           libafs_tree' process. Anyway, rebuilding this RPM with
           support for new kernel modules is the "right" thing to do.

  -openafs-kpasswd: this subpackage's description said it contained a
           compatibility symlink, but actually it contained two binaries.
           I've moved them into the main package.

  -openafs-krb5: built from a separate source tarball, which I haven't
           looked at yet. Probably should be a separate package anyway.

I have not included the documentation. I think that should be a separate
"openafs-manual" package, eventually.


The build process for external kernel modules has changed significantly for
the 2.6 kernel. The relevant part is that one needs a properly configured
build tree that exactly matches each kernel for which one wants to build a
module. Canonically, this build tree is at "/lib/modules/`uname -r`/build".
However, requiring each kernel for which we want a module to actually be
installed on the build system is inconvenient at best. Therefore, this RPM
actually includes the proper headers as source files. There's a script
(extractkernheaders.sh), which takes a kernel RPM (give the name on the
command line) and spits out a tar.bz2 containing just the build tree named
and formatted appropriately for use as source files.

This is a bit odd, I know, but it has some significant advantages. First, it
makes building modules for both i586 and i686 possible. But most
importantly, it insures repeatable package builds -- every time one builds
the modules, one gets exactly the kernel modules one wants, no less and no
more. The old way was very inconvenient when releasing an updated package --
one had to make sure the build machine had installed a copy of all possible
old kernels which someone might be using. Putting everything in one place
eliminates this problem.

Adding a new kernel to build against is easy: take the original Fedora Core
binary RPM, and run `extractkernheaders.sh kernel-*.rpm`. Then, add the
resulting tar.bz as a source file, and add its version-arch string to the
kernelversions macro. Add a local tag to the release number, rebuild, and
there you go.

This is very much a work in progress, and I look forward to hearing
feedback, suggestions for improvements, declarations that I'm doing it all
wrong, etc. Please check the TODO.RPM file for things which I particularly
think need help.

                                      -- Matthew Miller
                                         June 18 2004; updated Nov. 17 2004

Todo:

- make init script for server

- test client init script thoroughly -- it's sure to have some bugs

- make openafs-manual package

- *** go though all packaged files and determine that they are in the right
  subpackage (and that they should in fact be packaged) -- an AFS guru should
  be involved here. Currently, I think there's too much stuff in the base
  package -- maybe an openafs-utils should be added. ***

- find out what's up with libafsrpc.so, and remove "provides" kludge

- make nice complete and accurate buildrequires list

- the loop to build kernel modules is a little kludgy, with the ARCH/VER
  thing. simplify, simplify.

- openafs-krb5?

- pam module stuff -- test, and package up nicely -- maybe integrate with
  system-config-authorization, possibly replacing pam_krb5afs?

- resove conflict with pagsh in krbafs-utils package
                                                                                

- make kernel module / daemon not so cavalier about printing informational
  messages to the console -- need some sort of patch to shut up all the
  chatty informational messages spit out to the console on load/unload. It's
  fine for those to be logged, but only actual errors should make that much
  noise.
        
- figure out some way to do kernel dependencies properly, ideally _without_
  needing to make a separate subpackage for each module/version.

- make 'forcestop' option which would kill all processess using /afs before
  attempting to unmount (or alternately, make regular stop do that and
  add 'softstop, which wouldn't). Not doing this yet, because right now,
  AFS doesn't unmount _anyway_ even if processes aren't using it.