Simon- you are correct, I meant the rpmfusion repository, not the fedora. Given what you've just said, I'll stick with your rpms!
Thanks very much for your informative and detailed responses. eric p.s.- the machine in question is sort of a beta tester for the Notre Dame campus in terms of Fedora 12; the official use of Linux is still RHEL5, which I find too archaic for our department. The research computing IT department however is interested in my use of Fedora, so I'm reporting to them my anecdotes. I can happily say you have been very helpful. --- On Mon, 3/15/10, Simon Wilkinson <[email protected]> wrote: > From: Simon Wilkinson <[email protected]> > Subject: Re: [OpenAFS] multiplt kernel call traces > To: [email protected] > Cc: [email protected] > Date: Monday, March 15, 2010, 9:29 AM > > 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
