[CentOS-devel] openafs status?

Jonathan Billings billings at negate.org
Thu Aug 20 18:59:28 UTC 2015


On Tue, Aug 18, 2015 at 06:28:53PM +0100, Ned Slider wrote:
> Lets look at an example. Every couple weeks RH release a kernel update
> but I can't update because my matching kmod-openafs isn't available yet.
> First I have to wait for CentOS to rebuild it and release the kernel
> update (lag). Then I have to wait for the SIG to rebuild their
> kmod-openafs against the newly built CentOS kernel (more lag). If I
> accidentally update my kernel and reboot - poof, I'm burned. Every time,
> guaranteed. If I don't update my kernel then compliance are on my case
> because I'm vulnerable to the latest CVE.
> 
> Personally, if I'm gonna get burned I'd rather be burned every 9 months
> that every single time upstream releases a new kernel update.

So, in these scenarios:

1.) Per-kernel kmod package:  You can't update your kernel to the
latest because kmod-openafs prevents it.  The only kernels installed
are ones that work with AFS.

2.) Per-point-release kmod package:  You get a new kernel, reboot, and
afs fails to mount because the AFS filesystem fails.  You have no
$HOME, no apps, and unless you're an openafs developer, you have no
idea why it didn't load.  You have to build a new kmod, or bug someone
to do it for you.  The only way this doesn't happen is if a CentOS
volunteer happens to be fast enough at testing to know to rebuild the
kmod package before you happen to see the new kernel on the mirrors.

What is the best user scenario?  

I'm pretty sure that the commercial support for AFS builds a kmod for
every kernel.  I was only trying to get a SPEC file that worked well
with koji, which is largely working, except for things I've already
mentioned. 

-- 
Jonathan Billings <billings at negate.org>


More information about the CentOS-devel mailing list