[Fedora-packaging] Re: kmdl proposal and kmod flaws

Jack Neely jjneely at ncsu.edu
Wed Aug 9 13:38:54 UTC 2006


> > Okay...walk me through this then:
> > 
> > Assuming no yum plugins or other mess.
> > 
> > A new kernel is available that corrects some random remote DoS.  How do
> > I get all 1300 machines to pull down the new AFS modules?
> 
> It's in the wiki, but here it comes again:
> 
> o current kernel module scheme w/o any special depsolver handling:
>   - broken on rpm level, inherits on all depsolvers
>   - Modules of the current kernel get nuked whether you reboot into
>     the new kernel or not

Wrong.  Both up2date and yum have always marked packages that provide
'kernel-modules' as install only for several years now.  Modules don't
get "nuked" unless you rpm -U.

>   - Module upgrades within the same kernel get blocked due to file
>     conflicts 
>   - OR module upgrades within the same kernel get coinstalled and
>     module-init-tools can flip a coin to find out what to choose

Upgrades within the same kernel don't work.  This is one point, not
multiple.

>   + but the new kernel gets its kernel modules (and only the new
>     kernel ...)

This point has been used in practice by several large universities.
I've been doing this for about 6 years.  While not perfect its been
proven to be acceptable and allow machines to remain fulled patched.

NC State University.  Duke.  I believe Matt at Boston U. has used this
approch in the past as well.

> 
> o proposed kernel module scheme
>   + old and current kernels remain untouched by new kernels and kernel
>     modules for new kernels

Contrast:  The current tools allow this as well.  I use up2date.  It
does not nuke my old kernel modules.

>   + Proper upgrades of kernel modules within a kernel
>   - new kernels don't get associated kmdls coinstalled
> 

This is a big problem.  Your scheme discurages people from keeping their
systems updated.  You'd rather have all of my 1300 machines run a swiss
cheese kernel from 2003 for RHEL 3.  

> Now compare and judge for yourself :=)
> 

I did.  Its hard enough to get people to keep their kernels upgraded.
Your scheme makes it next to impossible without manual touching of all
machines.  This is not acceptable.

> Next thing to consider is whether and how to fix the remaining issues:
> 
> o current kernel module scheme special handling:
>   - no special handling possible with rpm cli will remain forever
>     broken

And it sucks.  I agree here.  However, ask who did not make compromises
when we developed the current scheme.  

>   - needs to both mark kernel module packages as coinstallable (which
>     they are not) and to perform non-rpm comformant depsolving

The co-installable mark has been in production and tested for 3 years
now I beleive.

I use the caveat of not issuing an upgrade within a kernel version.
Modules act identically to kernel packages themselves.

>   - Is required for all depsolvers and is a MUST otherwise depsolvers
>     reduce your system to ashes
> 

I've been doing this with up2date for quite a while and manage to
maintain mine.  Seth?  Matt?

> o proposed kernel module scheme special handling:
>   + nothing needed for rpm cli
>   + Obviously less than half the code needed than for the current
>     scheme, rather trivial coding, easy maintenance

How much code do we need to support pulling in modules for new kernels?

>   + Is NICE TO HAVE, absence does not break running system

No.  Yum/Up2date modifications would be required.  Not optional.  We
must not discurage people from applying security errata.

> 
> Compare again. :=)

Jack

> -- 
> Axel.Thimm at ATrpms.net



> --
> Fedora-packaging mailing list
> Fedora-packaging at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-packaging


-- 
Jack Neely <jjneely at ncsu.edu>
Campus Linux Services Project Lead
Information Technology Division, NC State University
GPG Fingerprint: 1917 5AC1 E828 9337 7AA4  EA6B 213B 765F 3B6A 5B89




More information about the packaging mailing list