[OpenAFS] multiplt kernel call traces

[Simon Wilkinson]

On 15 Mar 2010, at 14:08, ematlis@yahoo.com 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.