+++ 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).
Changing the summary to match the agreed solution in the previous bug. That is to put kernelinfo.xml into it's own package that can be shipped separately from the test suite.
Created attachment 730815 [details] this patch moves kernelInfo.xml to its own package hwcert-client-info
committed to R39
Verified in hwcert-client-info-1.6.4-39.el6.noarch.
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-1139.html