[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