> 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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
--
Jack Neely <jjneely(a)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