+++ This bug was initially created as a clone of Bug #915815 +++ Use case: Users behind a firewall or other restricted access lab could use an updated kernelinfo.xml and we would prefer not to spin a new package for the sole purpose of a new kernel has been released. Expected results: A kernelinfo.xml could be hosted on an internal server similar to the fv images allowing the info test to verify the GA kernel version info. Additional info: We could add a signature check to verify remove files including this xml (which is a reasonable idea anyway). The purpose isn't security as in saftey but more to verifying it's the content we expect/know since we do not have rpm verify to use. This could apply to fv images too or anything else we call home to retrieve. (Should this be a separate bug/feature?) We can also allow for a manually edited version with a warning or error the catalog/review team can catch but also provide a warning to the local user so they can address it before they do a bunch of testing against a bad file. --- Additional comment from Christian Horn on 2013-02-26 10:31:23 EST --- Looks ok to me, although I think the "hosting on the intranet" part is overcomplicating things. Just having a defined location on the local filesystem where an updated kernelinfo.xml might exist would be easier to use. --- Additional comment from Rob Landry on 2013-02-27 17:13:28 EST --- (In reply to comment #1) > Looks ok to me, although I think the "hosting on the intranet" part is > overcomplicating things. Just having a defined location on the local > filesystem where an updated kernelinfo.xml might exist would be easier to > use. This already exists in a way but it will cause the rpm -V of v7 to fail. I think if we just fully mimic the fv structure; which supports, RH hosted, $server hosts, and local hosted images; we'll cover all of the bases. Greg, should I open another bug for local filesystem provided kernelinfo.xml? Should the signing infrastructure be in it's own bug? --- Additional comment from Christian Horn on 2013-02-28 10:59:31 EST --- Singning and verifying the signature with a gpg pubkey which is part of the v7 suite sounds like a sane method indeed. Alternatively we could put the updated kernelinfo.xml into a separate rpm (but I favor the signature piece).
It seems that a separate package might be the simplest solution.
That works too, yum can then serve as the local $server hosting option. We will need a very low touch and low latency process to get this out quickly and without a hwcert-client spin. Gary, I think it should not be necessary to issue announcements for every info package that goes out?
Created attachment 730844 [details] this patch moves kernelInfo.xml to its own package hwcert-client-info
committed to R18
Verified in hwcert-client-info-1.5.9-18.el5.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1125.html