> > 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-packaging -- Jack Neely <jjneely@xxxxxxxx> Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
