On 15 Mar 2010, at 14:08, [email protected] wrote: > As a follow up to your response- will this problem "go away" for kernel > version 2.6.33? If so, perhaps I can upgrade to that version.
It will, yes. > As an alternative- can I fix this by downgrading the kernel to some lesser > version (say 2.6.30)? Yes. The problematic code is only in 2.6.31 and 2.6.32. Of course, vendors may have backported that code into earlier versions (or not taken the fixes, in later versions), but that's one of the joys of the way the Linux kernel gets distributed. > I found I needed pam-afs-session; is the library provided in the rpm going to > be included in the default openafs packages? pam-afs-session will always be a standalone package. There is an argument that we should possibly include it in our repository, but we have yet to do so. OpenAFS 1.5.x does have libkopenafs, which is similar to the library that pam-afs-session uses, so that will be available with that release. > Lastly- since I run Fedora, which now provides openafs by their own > repositories, which repository would you recommend- theirs or yours? As far as I'm aware, Fedora doesn't package OpenAFS. Fedora doesn't accept packages which introduce new kernel modules as a matter of policy, so we could never get the OpenAFS client into Fedora itself. I guess it would be possible to get the OpenAFS server into Fedora, but significant changes would have to happen to the way it's package for it to be acceptable to them. RPMFusion, on the other hand, does now appear to provide OpenAFS packages. These are significantly different from the ones that OpenAFS ship, so you need to decide fairly early one what you want to support for your site. I've never used the RPMfusion packages, nor had much communication with their packager, so I can't really comment on them. I'd love it if someone else was maintaining the OpenAFS RPMs, because it would be one less thing I need to do with each release. However, both my site and many others rely on the RPMs working the same way from release to release. We can't just switch to a set of 3rd party RPMs at the drop of a hat, and I think it's a real shame that the people doing third party RPM packaging never seem to come and talk to use before doing so. Given that we don't actually have contacts for 3rd party packagers, it's also unlikely that we'll be able to tell them about impending security fixes, or patches that are necessary for new security releases - so the OpenAFS RPMs are likely to get these before anyone else. This leaves the problem of support. If you are using the OpenAFS RPMs, then I'm quite likely to know how they were built, to have a set of kernel debug images floating around, and to be prepared to find the time to debug your problem. If you're using third party RPMs, then I'm as likely as not to ask you to report your problem to them, and to rule out anything to do with the way they've configured their builds, and their build system, before I'll take a look at it. So, for all of those reasons, I'd recommend using the OpenAFS rpms. Not that the rpmfusion ones are necessarily bad, in any way, it's just that it's much easier for the community to help you if you're using RPMs that we know the origin of. Cheers, Simon. _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
