On Tue, 2010-03-02 at 14:24 +0100, Tim Edwards wrote: > We'd like to keep the machines RHN-registered for support and > management, is there anyway to restrict them to just packages from > 5.4?
On 02/03/10 15:09, Colin Coe wrote: > http://press.redhat.com/2008/12/18/red-hat-increases-service-levels-and-reduces-costs-for-customers-with-extended-update-support/ On Tue, 2010-03-02 at 15:55 +0100, Tim Edwards wrote: > This doesn't really fit us or our use of RHEL. There's no way to do this > by just changing some yum settings? First off, with Red Hat Network (RHN) Satellite Server, one can create clone channels from both RHN (e.g., RHEL) and custom (e.g., internal RPMs) channels. This allows an organization to create a set of software specific to a set of systems, and those systems will only get those errata/packages that have been added to those clone channels. Individual RHN and custom errata updates from the feeder RHN and custom channels can be arbitrarily selected for cloning to the clone channels. E.g., in common customer workflow, there can be a "test" and "release" or "Gold" clone channel set, possibly an intermediate "staging" clone channel set as well. It allows customers to decide what errata and updates are important, and what are not. Secondly, Tim, what you're proposing can be a security or at least a support issue, one reason why Extended Update Service (EUS) was created, as I will detail. I offer this information so everyone can evaluate their own options for themselves. To start, I assume everyone here is familiar with Red Hat's Lifecycle: http://www.redhat.com/security/updates/errata/ And backporting of security fixes: http://www.redhat.com/security/updates/backporting/ Red Hat Errata almost always come in three (3) forms: - Security (RHSA) - Bugfix (RHBA) - Enhancement (RHEA) In the lifecycle, the latter two are largely limited to the first phase. Security is done throughout the full seven plus (7+) years of RHEL support. Security (RHSA) errata are backported fixes, regularly released after extensive integration, compatibility and regression testing, to avoid any issues with IHV/ISV and other products, while resolving CERT and other vunerabilities. Everyone should be regularly updating systems with RHSA errata to mitigate security issues. The value of the Red Hat subscription is ensuring that customer systems maintain full ABI/API compatibility, while addressing security issues as they are discovered. If there is an integration, compatibility, regression or other issue with a RHSA, then that is either a fault of Red Hat or your IHV/ISV (possibly contradictory to the Red Hat IHV/ISV agreement), and customers should notify the respected support of such situations. This is the value customers pay for, which Red Hat expends developer resources on (as well as working on and syncing with upstream developments, which are not productized, but the efforts go hand-in-hand -- e.g., Fedora). Bugfix (RHBA) and, even more so, enhancement (RHEA) errata are left to the full Updates. Sometimes bugfixes can change nominal operations, and that's why they are rolled up with security errata into the full Updates. Sometimes enhancement errata are independent, but sometimes they are a software rebase (e.g., Firefox 1.5 -> 3.0 a few updates back for both RHEL 4 and 5). Traditionally Red Hat Engineering and Global Support Services (GSS) services would refocus errata efforts on the new update after its released. This had two considerations. One, security errata being based on the latest Update means customers should be on the latest update (although properly declared and full RPM dependencies address most of this, but there can be dependency issues at times). Two, customers should are running the latest update, so Red Hat can re-produce an issue, without having to deal with the mixture of old and new packages, especially old kernels with newer userspace. I would not mention this if I have not seen it first hand myself. ;) The problem is that some Red Hat customers delay upgrading to the latest update, because bugfix and enhancements are added to security, whereas post-Update errata are typically only security. Red Hat experimented with "Z-streams", kernel and select userspace packages, with great success, especially with IHV/ISVs who were slow to release their software updates for the new, full RHEL Update. This lead to the introduction of the Extended Update Service (EUS) offering by late 2008. EUS allows customers to stay on an update for 12-18 months to plan and schedule an upgrade to a full, newer Update sometime after the Update is released. In the meantime, select "Z-stream" security errata is cut for the EUS channel. E.g., the latest security (RHSA) errata for RHEL EUS 5.3.z is RHSA-2010:0053, kernel 2.6.18-128 kernel tree (2.6.18-128.12.1.el5), even though current development is focused on RHEL 5.4's 2.6.18-164 kernel tree. See: http://rhn.redhat.com/errata/ (always freely browseable, no RHN account required) RHN Satellite Server and EUS are really designed for enterprises with 25-50 or more systems. EUS requires additional resources on Red Hat's end for the parallel integration, compatibility and regression testing, as well as GSS' duplication of test environments and other details. But it is offered to mitigate such issues when customers need to slip on their adoption of newer updates for various reasons (again, IHV/ISVs being a major reason). -- Bryan _Not_ speaking on behalf of Red Hat, but from _peer_ experience P.S. For smaller customers, there are other options. Red Hat Consulting and Red Hat Solutions Architects are always available to help discuss these options. They have a huge pool of expertise for customers, both large and small. http://www.redhat.com/consulting -- Bryan J Smith Senior Consultant Red Hat, Inc Professional Consulting http://www.redhat.com/consulting mailto:[email protected] +1 (407) 489-7013 (Mobile) mailto:[email protected] (Blackberry/Red Hat-External) -------------------------------------------------------- You already know Red Hat as the entity dedicated to 100% no-IP-strings-attached, community software development. But do you know where CIOs rate Red Hat versus other software and services firms for their own, direct needs, year after year? http://www.redhat.com/promo/vendor/ _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
