Mailinglist Archive: opensuse (2532 mails)
| < Previous | Next > |
Re: [opensuse] Re: Manual dist upgrade procedure(s) & tools/progs/aids?
- From: Sam Clemens <clemens.sam1@xxxxxxxxx>
- Date: Tue, 06 May 2008 16:51:49 -0400
- Message-id: <4820C4E5.4060401@xxxxxxxxx>
Linda Walsh wrote:
In your original post, you, perhaps inadvertently, implied that
the machine couldn't be taken offline to do a fresh install.
Wholesale replacement of basic system libraries will end
in utter chaos, as the install system nees the new libraries,
and the older software needs the old libraries.
If your in-place software forks off ANY child processes,
and their required libraries are missing, the whole server
is going to be worthless for the rest of your installation
procedure anyways.
Updating a kernel compiled against the same libraries is
significantly different than upgrading all of the libraries.
1. The new kernel is only copied into place...it doesn't
become active until AFTER the reboot.
2. Replaced libraries (old ones removed) causes significant
chaos -- the reason is that the system is "live"...and the
old executables are expecting the old libraries, not the
replacement libraries.
I once made the mistake of trying to upgrade glibc5 to glibc6.
The result was not pleasant.
And I've been a *nix person since the early 1980's.
This is an entirely different problem.
glibc is not considered to be "user level software".
It's intrinsic to nearly everything except the kernel itself,
and that ONLY because the kernel statically links whatever
it needs.
In every place I've ever worked "why not upgrade?" is not a
sufficient reason to upgrade a server. If it's doing what it
needs to do, then there's no reason to upgrade. On the other
hand, if there is some new functionality which can be obtained
by upgrading, then do it.
But, also, at every place I've ever been at, when an upgrade
of that sort comes around, it's not done on a production machine
while it's in use. The upgrade is FIRST done on a test machine,
and tested for days to weeks. Once the test configuration is
approved, THEN it's put onto the production machine.
If you were using industry standard testing procedures,
you would have worked out this upgrade process already
on the non-production machine, and therefore, wouldn't
be asking this question on this list.
So, in summary, your company needs to become acquianted
with the concept of "test platform" vs "production platform"
Untested installations, and especially upgrade procedures
are NEVER done on a production machine. That's *WHY*
you should have test machines.
Are you finding software bugs in your 9.3 software?
Same holds true.
One Fortune 50 company I worked at had an HP-UX server which
was so old HP sent us a letter telling us that this particular
machine would no longer be covered under the site maintenance
contract, because the hardware was more than 10 years old.
Upgrading IT solely for the purpose of upgrading is one of
the surest ways to cause chaos in the workplace -- AND make
the I.T. people look really, REALLY bad.
Generally, you keep all your platforms on a "known good" version
of the O.S. unless a new release of an app fixes a bug, or offers
a new NEEDED capability, **AND** that new software release
is not offered on the currently installed version of the O.S.
Plenty of Fortune 500 companies are maintaining their market
competitiveness without striving to maintain "bleeding edge"
modernity in their IT shop.
Business and business reasons ALONE determine when to upgrade.
Stop viewing the OS installation as a fashion statement.
Your girlfriends at the bar aren't going to be whispering to each
other, "Can you BELIEVE it...she's using LAST SPRING's software."
That's the wrong schedule.
You need to do it when it's convenient for the business.
That's why you're employed.
> You seem to feel that one should be a slave to the Distro's
IF it's necessary to upgrade this machine now, then you
need to hop on a plane, and do this upgrade properly.
At this point, I'm leaving the remaining 50% of this
unaddressed, because I have other things I need to do.
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx
John Andersen wrote:
Huge overwrought rant snipped...---
Now lets suppose it was a power supply, or a memory module.
What then?
If this machine is so sensitive
You seem to be really scared of some bogeyman that doesn't
exist. Who are you writing to or about? I never said anything
about a sensitive machine. If my desktop was to go out randomly for
a day or weeks due to attempts to make a "complete" upgrade work,
it wouldn't be acceptable either.
If this machine can't be taken off line
Another bogeyman -- no one said the machine couldn't be
taken offline for a kernel reboot or hardware upgrade.
In your original post, you, perhaps inadvertently, implied that
the machine couldn't be taken offline to do a fresh install.
I asked a hard technical question, maybe that triggered
your way-off-base rant: If the kernel of an Operating system can
be replaced while running, then what possible program above the kernel can't be hot-upgraded (i.e. without taking the machine down).
Wholesale replacement of basic system libraries will end
in utter chaos, as the install system nees the new libraries,
and the older software needs the old libraries.
If there is any rant, maybe this is it. When Windows 95, 98
and ME came out -- it was a running source of amusement about how primitive Windows was because it required rebooting on not, just
OS updates, but even user-level software. Among unix users,
it was considered a primitive throw-back -- because unix users
never got a "Permission Denied" message when deleting or renaming a
file they had access to. It's long been a bug-a-boo on Windows; not
being able to delete "in-use" files -- making updates famously
difficult!
It's A BUG!!! Not a feature!
If your in-place software forks off ANY child processes,
and their required libraries are missing, the whole server
is going to be worthless for the rest of your installation
procedure anyways.
If you weren't installing a kernel, changing hardware or reformatting the system disk, you didn't need to reboot.
Updating a kernel compiled against the same libraries is
significantly different than upgrading all of the libraries.
1. The new kernel is only copied into place...it doesn't
become active until AFTER the reboot.
2. Replaced libraries (old ones removed) causes significant
chaos -- the reason is that the system is "live"...and the
old executables are expecting the old libraries, not the
replacement libraries.
I once made the mistake of trying to upgrade glibc5 to glibc6.
The result was not pleasant.
And I've been a *nix person since the early 1980's.
Then along unix's and linux's on the PC. On PC's people were
"used" to the need to reboot when installing software. So for some
reason, most of the PC-*nix distributions unconsciously(?) leaned toward
Microsoft as a model for how to do things on the PC. Unfortunately,
instead of bringing unix ways to the PC ("we don't need no stinkin'
reboots for no userspace-update badges"), MS seduced them unto the
dumb side of software updating. :-( ( :-))
This is an entirely different problem.
why don't you have a hot spare?---
How does a hot spare allow upgrading a few (or one) package at a time on a live machine to see how it runs with your live configuration?
Or how does it help upgrading, testing and verifying one package
or one package group at a time? How can one consider it more
user-friendly to force users into a full update rather than allowing
incremental upgrades of only the packages they need? Why
replace everything if most of everything is working? Why not just
add or replace the one new package you are interested in?
But maybe most important: How does install a hot-spare while logged in *remotely* (as mentioned in the base-note) over ssh?
You want to go from 9.3 to 10.3, seamlessly, on a machine that----
(by all accounts) hasn't been down for more then a heartbeat
since 9.3!?!
Seemlessly? Hasn't been down since 9.3? Oh no! More scary bogeymen!! Dude, chill out, pop a reality pill. Those are your personal
demons and projections. I think the longest thisi machine has been up,
non-interrupted, has been around 8 months. At the very least, there are
kernel's that come out and need to be upgraded to. But even in the
kernel world, responsible software (kernel) engineers are addressing
that problem. They aren't ranting about users not wanting to
have to be down for software updates -- they are going one better --
kernel replacement with out reboots!
I'll say it again -- the only software that was famously known for
requiring reboots for user-level software was Windows 95 and 98.
That's not a standard to strive for.
glibc is not considered to be "user level software".
It's intrinsic to nearly everything except the kernel itself,
and that ONLY because the kernel statically links whatever
it needs.
Why? What ever for? [go from 9.3 to 10.3]---
Why not? If I can do it one package at a time and not
experience any downtime, It might go better with the usually,
shiny new kernels that come out regularly w/better hardware
support, more efficient algorithms, etc. Or are you trying
to make the case that there are no improvements in 10.3 vs. 9.3
worth upgrading for?
In every place I've ever worked "why not upgrade?" is not a
sufficient reason to upgrade a server. If it's doing what it
needs to do, then there's no reason to upgrade. On the other
hand, if there is some new functionality which can be obtained
by upgrading, then do it.
But, also, at every place I've ever been at, when an upgrade
of that sort comes around, it's not done on a production machine
while it's in use. The upgrade is FIRST done on a test machine,
and tested for days to weeks. Once the test configuration is
approved, THEN it's put onto the production machine.
If you were using industry standard testing procedures,
you would have worked out this upgrade process already
on the non-production machine, and therefore, wouldn't
be asking this question on this list.
So, in summary, your company needs to become acquianted
with the concept of "test platform" vs "production platform"
Untested installations, and especially upgrade procedures
are NEVER done on a production machine. That's *WHY*
you should have test machines.
If I find a bug in a software program, wouldn't it be more
productive to report that bug against 10.3? Do you think
reporting a bug against 9.3 would even be accepted, let alone
useful?
Are you finding software bugs in your 9.3 software?
If its not broke, don't fix it.---
Not a bad sentiment, but this is the computer industry.
Same holds true.
One Fortune 50 company I worked at had an HP-UX server which
was so old HP sent us a letter telling us that this particular
machine would no longer be covered under the site maintenance
contract, because the hardware was more than 10 years old.
Upgrading IT solely for the purpose of upgrading is one of
the surest ways to cause chaos in the workplace -- AND make
the I.T. people look really, REALLY bad.
Generally, you keep all your platforms on a "known good" version
of the O.S. unless a new release of an app fixes a bug, or offers
a new NEEDED capability, **AND** that new software release
is not offered on the currently installed version of the O.S.
You either move ahead, or get left behind. Take your pick. I
Plenty of Fortune 500 companies are maintaining their market
competitiveness without striving to maintain "bleeding edge"
modernity in their IT shop.
Business and business reasons ALONE determine when to upgrade.
Stop viewing the OS installation as a fashion statement.
Your girlfriends at the bar aren't going to be whispering to each
other, "Can you BELIEVE it...she's using LAST SPRING's software."
choose to move ahead -- on my schedule when its convenient for
me.
That's the wrong schedule.
You need to do it when it's convenient for the business.
That's why you're employed.
> You seem to feel that one should be a slave to the Distro's
schedule and jump on every update in the prescribed manner. How
quaint. In the real world, business schedules or practices don't
and shouldn't be forced to revolve around a distro maker's release
schedule.
IF it's necessary to upgrade this machine now, then you
need to hop on a plane, and do this upgrade properly.
At this point, I'm leaving the remaining 50% of this
unaddressed, because I have other things I need to do.
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx
| < Previous | Next > |