When I managed hosts at an energy company, we used to do the
same--we'd wait till, say, 6.3 was out, figure out what the last
snapshot of 6.2 was, test it out, and then upgrade from 6.1 "final" to
6.2 "final".

Figuring out what constituted 6.2 on its "final" day was an
interesting challenge. There was at the time (and likely today) no
documentation on it, since RHEL is a rolling distribution. I used
errata between the release dates to get the package names, and then
created a list of all the packages that formed each dot release. When
upgrading systems, I'd manually install just host hand-picked package
names at those specific versions.

Another option would've been figuring out the sensitive or high-impact
packages, blacklisting them through Yum, and providing them through a
curated repository. This way, you'd get security patches for the bulk
of your packages without the impact to your production systems
something like device mapper or kernel updates might have.
Shatil (@shatil)


On Wed, Mar 26, 2014 at 12:04 PM, Denice <[log in to unmask]> wrote:
> On Tue, 25 Mar 2014, Lamar Owen wrote:
>
>> On 03/25/2014 08:48 AM, Andras Horvath wrote:
>>
>>> On Mon, 24 Mar 2014 16:55:25 -0500
>>> Connie Sieh <[log in to unmask]> wrote:
>>>>
>>>> Point releases (7.1, etc.) might disappear. Expect them to not.
>>>
>>> Would this mean that the support of the minor branches would end and only
>>> the most recent minor version would get the long term support? If so, then I
>>> strongly believe that one of the most precious advantages of SL would
>>> disappear - compared to CentOS AFAIK.
>>
>> This is one of the key distinctions between SL and CentOS, and I would
>> imagine is more than a small amount of work on the SL team, especially as
>> the number of point releases increase.  I would find it interesting to see
>> who is using this capability and specific reasons why they need (rather than
>> want) this capability (specific drivers for specialized hardware, etc).  I'm
>> not interested in debating the reasons why, just collating them.
>
>
> As an LHC Tier-1 centre, albeit small, we very much like the feature
> of sitting on a point release until we are ready to move to the next
> point release.
>
> We do not apply updates automatically.  We apply updates in an ordered
> pattern.  Some updates are only applied after extensive testing
> on pre-production systems.  For example, we are very sensitive to
> storage-related issues.  Thus RPMs like device-mapper-multipath
> and any associated RPMs, mt-st, mtx, kernel, etc. are applied only
> after testing.
>
> Storage is not the only sensitive area.  We also need to care about
> other RPMs like java, tomcat, httpd, openssl, openldap and others
> depending on which services are running on which machines.
>
> At the juncture around a new SL point release, we see a much smaller
> set of new updates than we would if we were pushed into the next
> point release.  This is easy to deal with.
>
> We also manage a handful of Red Hat systems, and as a system admin I
> really hate to see the long list of RPMs that I need to sift through
> whenever the point release rolls over.  We have no control over it.
> It is made worse by needing to wait for maintenance windows when we
> can apply patches.
>
> By chosing the time when we move to the next point release, we keep
> control.  This is important to us in managing some 530 Linux servers.
>
> Note that we typically stay within 2 points of the latest point release.
> I'm not sure why some people stay on a point release - perhaps they
> will comment.
>
> cheers, etc.
>   Denice
> --
> deatrich @ triumf.ca, Science/ATLAS         PH: +1 604-222-7665
> <*> This moment's fortune cookie:
> Flying is the second greatest feeling you can have.  The greatest feeling?
> Landing...  Landing is the greatest feeling you can have.