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

[Axel Thimm]

On Wed, Aug 09, 2006 at 09:38:54AM -0400, Jack Neely wrote:
> > > 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.

Wrong x 3:

o not always, neither yum, not up2date initially had any
  "kernel-module(s)" support
o first implementation had a typo mismatch, kernel-modules vs
  kernel-module. In fact effectively its a very young approach, I
  think this was fixed less than a year ago
o you asked for "no yum plugins or other mess". Requiring all kernel
  modules to be initially marked as "always coinstallable" has been
  proven to be a bug and therefore a "mess".

> >   - 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.

There is a big capitalized "OR" in the list. Which means that if the
current /lib/module/<uname-r>/... file paths are kept you are lucky
that it's only file conflicts (and "just" an aborted yum update). But
if the non-overlapping kabi/whatever file path scheme is adopted you
don't have file conflicts, but worse: the modules will get installed
and depmod will play oracle on what module to chose.

So yes, it's one point with multiple failure paths all of which are
ugly.

> >   + 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.

6 years? So you've been using yum's secret unannounced and NSA
sponsored version back then, huh? ;)

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

And I know large universities that extensively make use of proprietary
operating systems, so what exactly does that say? Mass does not imply
infallibility.

> >   + 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.  [...] 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.

You asked about "Assuming no yum plugins or other mess", see above. I
never suggested using this scheme w/o any support for depsolvers, and
I did submit a working yum plugin for this scheme, didn't I?

Don't twist my words, please.

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

Well, you need to decide, is it 6, 3 or perhaps less? ...

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

Certainly not, then don't ask about academic exersizes on what the
behaviour is w/o any special depsolver handling.

To remain on the subject since there are other depsolvers out there
that know nothing yet about any kernel module scheme: The old scheme
will nuke your running kernel modules, there is no way out, and
currently for smart to not do so requires a special config entry *per
module*!!!

Getting back to the real facts: We're interested in

a) supporting rpm cli
b) supporting yum
c) supporting up2date

In the old case a) is forever tainted, b) needs a yet uncomplete
plugin (you never replied on the review on the requirements on
recursive package removal your plugin would have to do) and c) is
unclear to me.

In the new case a) is already done with, b) needs a plugin that is
already finished and c) is unclear, too ;)

[Regarding c) I hope that up2date uses yum more and more, so perhaps
at RHEL5 time yum plugins will fix this, too].

Nice to have are

a) support for apt
b) support for smart

As said in the old scheme, where you need *both* to mark all packages
as coinstallable *and* to undo case-wise this assumption, b) is a big
looser when it comes to marking packages as coinstallable. And support
for a) for kmdls is trivial and is even shipped with the source
tarball (only need to replace "kernel-module-*" matching with
"*-kmld-" matching) while for kmods you have the same issues as under
yum w/o any plugin.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20060809/ad950f31/attachment.sig>