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.
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
- 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.