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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
