CentOS - Nov 2016 - CentOS 6.3 packages updates options without upgrading.

>
>
>
> Show us this "no way to update system properly" to get a clear
big picture
> that is allowing us to provide you with potentially better solutions.
>
Thanks really Leon very much w/ a very resourceful info. esp release notes
helps across minor versions.  So, this is for a friend of mine, and I have
been told that they will not currently consider updating their userland
from 6.3 to 6.8 but only selected few packages.  The picture seems to be
that their company runs a lot of apps on 6.3 userland and might have some
specific dependencies, etc., but more importantly, this environment has
been running in customers' environment for quite some time esp 1000s of
customers, so updating system properly is not easily feasible for this
scenario.  However, they can hand pick packages seem fit for update that
can be pushed out using their internal code fixes and updates for end
users. SO, this seems to be the problem of trying to hand pick certain
packages to be updated, if feasible w/o much adverse effects.

On 11/08/2016 06:27 AM, Dipal Bhatt wrote:
>>
>>
>>
>> Show us this "no way to update system properly" to get a
clear big picture
>> that is allowing us to provide you with potentially better solutions.
>>
> Thanks really Leon very much w/ a very resourceful info. esp release notes
> helps across minor versions.  So, this is for a friend of mine, and I have
> been told that they will not currently consider updating their userland
> from 6.3 to 6.8 but only selected few packages.  The picture seems to be
> that their company runs a lot of apps on 6.3 userland and might have some
> specific dependencies, etc., but more importantly, this environment has
> been running in customers' environment for quite some time esp 1000s of
> customers, so updating system properly is not easily feasible for this
> scenario.  However, they can hand pick packages seem fit for update that
> can be pushed out using their internal code fixes and updates for end
> users. SO, this seems to be the problem of trying to hand pick certain
> packages to be updated, if feasible w/o much adverse effects.
> _______________________________________________
I think RHEL sells support packages for specific releases. Maybe they 
could pay for a RHEL license for 6.3 and then rebuild the updates for 
the CentOS 6.3 machines not covered in the RHEL support license.

If they have thousands of customers, paying for RHEL license for some of 
them probably is not an un-reasonable thing to do.

On Tue, 2016-11-08 at 08:27 -0600, Dipal Bhatt wrote:
> .....  So, this is for a friend of mine, and I have
> been told that they will not currently consider updating their userland
> from 6.3 to 6.8 but only selected few packages.  The picture seems to be
> that their company runs a lot of apps on 6.3 userland and might have some
> specific dependencies, etc., but more importantly, this environment has
> been running in customers' environment for quite some time esp 1000s of
> customers, so updating system properly is not easily feasible for this
> scenario.
If everyone is running STANDARD CENTOS there should be *no* problems
updating to the latest C 6.8 version.

(1) Save one complete installation.

(2) Install it on a spare machine.

(3) Change /etc/sysconfig/network-scripts/ifcfg-eth0 if necessary.

(4) Do a: yum update

(5) Test the applications

(6) Wait a few weeks and if still no problems, then upgrade the others.



-- 
Regards,

Paul.
England, EU.      England's place is in the European Union.

On 11/8/2016 6:27 AM, Dipal Bhatt wrote:
> Thanks really Leon very much w/ a very resourceful info. esp release notes
> helps across minor versions.  So, this is for a friend of mine, and I have
> been told that they will not currently consider updating their userland
> from 6.3 to 6.8 but only selected few packages.  The picture seems to be
> that their company runs a lot of apps on 6.3 userland and might have some
> specific dependencies, etc., but more importantly, this environment has
> been running in customers' environment for quite some time esp 1000s of
> customers, so updating system properly is not easily feasible for this
> scenario.  However, they can hand pick packages seem fit for update that
> can be pushed out using their internal code fixes and updates for end
> users. SO, this seems to be the problem of trying to hand pick certain
> packages to be updated, if feasible w/o much adverse effects.
thats a whole lot of words that boil down to  nothing,    they won't 
update because they don't want to, and are too lazy ?



-- 
john r pierce, recycling bits in santa cruz

Unfortunately, that's the constraint it seems hence, there's inquiry of
other options.  But, looks like, any el6 package should work as long as we
meet the dependencies?
Kindly thanks for many help.

On Tue, Nov 8, 2016 at 10:55 AM, John R Pierce <pierce at hogranch.com>
wrote:
> On 11/8/2016 6:27 AM, Dipal Bhatt wrote:
>
>> Thanks really Leon very much w/ a very resourceful info. esp release
notes
>> helps across minor versions.  So, this is for a friend of mine, and I
have
>> been told that they will not currently consider updating their userland
>> from 6.3 to 6.8 but only selected few packages.  The picture seems to
be
>> that their company runs a lot of apps on 6.3 userland and might have
some
>> specific dependencies, etc., but more importantly, this environment has
>> been running in customers' environment for quite some time esp
1000s of
>> customers, so updating system properly is not easily feasible for this
>> scenario.  However, they can hand pick packages seem fit for update
that
>> can be pushed out using their internal code fixes and updates for end
>> users. SO, this seems to be the problem of trying to hand pick certain
>> packages to be updated, if feasible w/o much adverse effects.
>>
>
> thats a whole lot of words that boil down to  nothing,    they won't
> update because they don't want to, and are too lazy ?
>
>
>
> --
> john r pierce, recycling bits in santa cruz
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
>

On 2016-11-08 08:27, Dipal Bhatt wrote:
> Thanks really Leon very much w/ a very resourceful info. esp release notes
> helps across minor versions.  So, this is for a friend of mine, and I have
> been told that they will not currently consider updating their userland
> from 6.3 to 6.8 but only selected few packages.  The picture seems to be
> that their company runs a lot of apps on 6.3 userland and might have some
> specific dependencies, etc., but more importantly, this environment has
> been running in customers' environment for quite some time esp 1000s of
> customers, so updating system properly is not easily feasible for this
> scenario.  However, they can hand pick packages seem fit for update that
> can be pushed out using their internal code fixes and updates for end
> users. SO, this seems to be the problem of trying to hand pick certain
> packages to be updated, if feasible w/o much adverse effects.
Hi Dipal,

I compliment you on your unflagging politeness in the
continual attempt to steer you to another, safer course.

I've been faced with a similar situation, a vendor (Sungard)
who would only qualify Red Hat 4 and Sun Server 6, and wouldn't
budge. The setting was a US$100 million annual budget enterprise
with a CTO with very low risk tolerance. Our staff pushed the
"don't upgrade" strategy about as far as anyone could ever
hope to take it. We hand patched our way through "heartbleed",
for example.

In my case, wanting better outcomes, I accelerated the move to
automated deployment (Cobbler + Puppet), and was then able to
provide solid test environments that allowed developers to
quickly re-deploy applications on newer versions of the OS.
Initially the push-back was voiced as the whole idea being too
costly. The new approach actually reduced costs, freed up
developer time, and led to stable systems running in (mostly)
supported configurations. When the vendor demanded a bug be
demo'd on a Red Hat 4 system, we were able to spin one up. But
they almost never asked. Apparently most of their customers had
decided safety and convenience outranks stupidity on the part of
the vendor, and as a practical matter their help desk
strategically failed to notice the "unsupported" OS.

I believe the approach you've been requested to assist with
has an implicit wager that you're almost certain to lose:

   > they can hand pick packages seem fit for update
   > that can be pushed out using their internal code 
   > fixes and updates

Consider, this is what Red Hat pays staff to do. Update some
packages, test if anything breaks, act on reports from the 
field. When one makes a complete upgrade to 6 (current), one
rides on the coattails of all the work of the Red Hat team to
test and stabilize changes. 

On the other hand, if one omits the update to 6 (current), they
have the identical problem but are foresaking the vendor's sunk
costs in testing and debugging. The implicit wager is that the
few hand-picked packages will reduce exposure to changes,
and so reduce labor, and increase your chances for a stable
system. However, consider that glibc went through these changes

 CentOS 6.3 glibc-2.12-1.80             
 CentOS 6.4 glibc-2.12-1.107         
 CentOS 6.5 glibc-2.12-1.132             
 CentOS 6.6 glibc-2.12-1.149             
 CentOS 6.7 glibc-2.12-1.166             
 CentOS 6.8 glibc-2.12-1.192

and that just about everything links against glibc, and you
can see that upgrading piecemeal is a good recipe for running
into subtle problems. And that's _one_ package.

If you have a small set of specific breaking changes, better
to get the devs off their butts and fix things or find work
arounds than to take on the greater risks of piecing together
odds and ends... which never stops.

Apparently you're in for an unending, unprofitable slog through
the worst, most unsatisfying kind of sysadminery. Been there,
done that, moved on!

Best regards,
-- 
Charles Polisher