upgrade to kudzu 1.1.116.2-3.6-1 in group-zenoss and group-zenoss-enterprise

[gstreiff]

Earlier versions of kudzu (1.1.116.2-3.3, for example) can segfault during boot time when paired with the 2.6.26.5 kernel. I've seen this specifically with our hardware appliance, but not in the vm appliance. This bug also had the side effect of knocking out my network interfaces.

The latest kudzu trove supposedly fixes this:

kudzu /conary.rpath.com@rpl:devel//1/1.1.116.2-3.6-1

The risk of exposure to this issue has been largely minimized by the fact that our zenoss group recipes now pre-req the 2.6.24.7 kernel.

However, if a customer explicitly upgraded their kernel such that
it is listed as a top-level trove, then it is possible that
on the next 'conary updateall' the buggy combination of 2.6.26.5
and back-level kudzu may get pulled in. You can tell if you're
exposed to the risk by running:

conary updateall --items

This does not actually update anything. It will just list your
top-level troves.

If you see a kernel trove listed (in addition to the expected zenoss
trove), then you are at risk on a subsequent 'conary updateall' of
pulling in 2.6.26.5 kernel.

Generally speaking, conary will save your previous kernel. So even if you get updated to the 2.6.26.5 kernel with buggy kudzu, you can
edit /boot/grub/grub.conf to boot from your previous (stable) kernel. In particular, 2.6.24.7 is a good kernel to be using with
our 2.2.4 Zenoss appliance.

rPath also recommends migrates as opposed to updateall because migrates will not try to upgrade any top-level kernel troves
unless you explicitly request it to do so. And thus you are less
exposed to the issue described in this ticket.

The Zenoss install guides have been updated
to include recommended approaches to upgrading via 'conary migrate'.