On 09/30/2014 11:10 AM, Kevin Stange wrote:
On 09/30/2014 10:03 AM, Nux! wrote:
What needs to happen for that?
We had a short discussion about it here:
http://lists.centos.org/pipermail/centos-devel/2014-September/011893.html
The issue is that something during the issuance of new updates has to build a persistent list of CExAs and then regenerate the updateinfo.xml while building the repo update.
Right now CentOS pushes the update notices directly to the mailing list and doesn't store that data anywhere to generate the XML file. The only way I know to build historical updateinfo.xml would be to scrape the mailing list for all previous data. Needed are release ID, package (name, version, release, arch), SHA sum, release type (bug, enhancement, new package, security), severity (if security), reference URL, summary, additional description (if any).
SL publishes updateinfo.xml so if someone has insight into how they manage it, perhaps we could make use of the process to shoehorn into CentOS. See:
http://ftp.scientificlinux.org/linux/fermi/scientific/6x/x86_64/updates/secu...
I think that is only one issue.
The other issue (as I understand it), is that we would need an all encompassing metadata across all versions to make this work as well.
Meaning that (lets take CentOS-6 as an example) ... we would need a tree of all RPMs (6.0, 6.1, 6.2, 6.3, 6.4, 6.5 .. plus all the updates directories) on all the mirrors to make that work.
I suppose we could do it if all the metadata was in one place (at a level up) and the directories could be separate.
But either way, it would add significantly to the size required to mirror CentOS and require a redesign of how we do trees completely (we currently only push the latest tree for each live major version).
(For example, we would likely have to separate ISOs out of main trees as there is no way we could mirror all the ISO's as well as all the binary RPMs for 11 CentOS 5 versions, 5 CentOS 6 versions, etc. to every mirror, that is several TB of info if we include ISOs)
=====================================================================
So, all of this would be required and the end result would be that you would then be able to install security updates only.
The only problem with that is ... in a staged build system, security updates only is not supported. It is not really supported in RHEL either. Why do I say that? Look at any RHEL RHSA update .. I'll take one of the shellshock updates:
https://rhn.redhat.com/errata/RHSA-2014-1306.html
If you look at the Solution section you will see this quote:
"Before applying this update, make sure all previously released errata relevant to your system have been applied."
It does not say all "previously release Security Errata" has been applied ... it does not say all "BugFix and Security Errata" has been applied .. it says "all previously released Errata" has been applied.
Why is that?
Well, because things are built on top of the last update (the build root used is 'staged'). The build root grows as you add packages to the distribution. Package A is built, it goes into the build root and then Package B gets built the next day against that Package A. If you run that Package B against an older version of Package A than the one it was built against, then it may not work the same way as it was intended to work.
So, the only 'supported' and 'tested' configuration is all the latest packages installed.
That is why Red Hat specifically has EUS/AUS repositories where they SPECIFICALLY built the same bash (in our example) against the extended 6.4 EUS tree. They have a different shell shock patched build of bash there:
https://rhn.redhat.com/errata/RHSA-2014-1311.html
The bash for RHEL-6.4 AUS is (after being built against the 6.4 AUS tree) different that the one for RHEL-6.5 .. why is that? Because it is the same source code, but it is built against a different subset of packages. (The AUS is basically all of 6.4 as it was when 6.5 was released, and all the new 6.5 security updates, built in order and in a staged manner against that 6.4 tree ... so it is '6.4 plus 6.5 security updates'.) Do you think Red Hat would maintain a separate AUS/EUS 6.4 tree and build all the new security updates from 6.5 again against that 6.4 EUS/AUS tree if the users could just not update to 6.5 and just use yum-security to use the 6.5 updates? Of course not, they would just use the 6.5 security packages for 6.4. They don't use the 6.5 security updates directly against 6.4, because it might not work. Instead, they maintain a separate 6.4 tree.
If you take the 6.5 bash update and install it in 6.4, will it work? Likely. Will it absolutely fix the security issue? Maybe not .. it is certainly not 'supported' by Red Hat that way.
======================================================================
So, only installing Security updates and not all updates is not a very good idea (certainly on on different minor versions), because you are not operating in a tested manner and the update could very well not even mitigate the security issue UNLESS you install all updates (security and otherwise) that happen before it anyway.
Therefore why would we want to take great pains to totally redesign our mirror infrastructure (the size increase rendering some number of our current donated mirrors as too small to now be used). Take great pains to maintain a separate database of Security info to generate the xml file. Then that will make the end release that it is now very easy for users to think they are safe (because they do all security updates after all) ... but they are not safe because they are running 6.5 security updates against 6.4? Or help them run only critical security updates and the combination introduces new issues unique to that combination?
They only way to have another secure combination is to build and test the security updates in that combination. If you want 6.3 with only the 6.4 and 6.5 Moderate Security updates (or above) added to that, you would need to build the 6.4 and 6.5 security updates (in order) against that 6.3 tree ... staging it as you go so that the next update gets built against the update before it. You would also then need to TEST that this combination actually fixes the security issues. Then you could be reasonably sure that the solution was safe.
But if you just installed the CentOS 6.4 and 6.5 moderate updates (or higher) on CentOS 6.3 (the same packages you rebuilt in the preceding paragraph) .. even if they installed, it would be significantly different than the solution where you built them yourself.