[opensuse] Re: Manual dist upgrade procedure(s) & tools/progs/aids?

Sam Clemens wrote:
In your original post, you, perhaps inadvertently, implied that
the machine couldn't be taken offline to do a fresh install.
---
Well --... it "can't" because it would cause me too much
grief. I *would* like to get to having a redundant, failover system,
but it hasn't been a priority.


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.
----
This is not a black & white issue. It's not "work this way
or not work at all".

Third party application vendors are not going tolerate their
apps breaking everytime the OS upgrades. Suse has included a "compat"
package for older glib-version programs for some time now. If you
follow the package dependencies, the old programs might require
lib-v2, while new glib might be at lib-v3 -- but "compat" will still
contain lib-v2 -- so if you install the new glib and compat at the
same time, nothing breaks.



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.
----
This is not windows....a *fork* duplicates the parent space.
If the libraries were in the parent, they will be duplicated into
the child's address space. If you run a new program, it will pick
up whatever *new* library is needed -- two different versions of
the library can be in memory at the same time -- processes using the
same version of a library can share read-only segments, but if another
group uses a different version, that different version is in a different
location in memory. The *old* library *stays* around on disk until
the last processes using that library exits.

Only after all processes using an old library have exited will
the inode for that file be released and the file space be reclaimed.

This is not windows -- where the libraries in memory are mapped
to device,sector. In unix it is relative to the libraries inode --
which doesn't go away when deleted if it is still being used in memory.


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.
----
The new libraries don't become active until you launch
new programs. The programs already in memory continue to use
any old libraries they have open -- only after you "reboot the program"
(stop & restart it) will it pickup the new libraries -- JUST like
the kernel. It's not random.


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.
----
Well -- it depends on what you mean and how you go about
it. Did you pay attention to the rpm requisites? If you do, the
old programs will complain if you take away their old library, but
if you upgrade glib with a new version and add a "compat" that deals
with previous versions (which SuSE does), then you don't have the
problem.



I once made the mistake of trying to upgrade glibc5 to glibc6.
The result was not pleasant.
----
If you ignored the pre-reqs, I could see why. OTOH, I have
also replaced libraries -- even going from one ARCHITECTURE
to another (i386 to x86_64)...even that was doable (though
a bit messy) which is why I'm wondering about scripts to aid in such
things.

And I've been a *nix person since the early 1980's.
---
Maybe earlier than me...not sure....um...late 80's
maybe? I admit, much of my experience has been working at unix
vendors, so maybe I have had an insider's view more than most. But
most of the people around me thought this stuff was pretty basic.

glibc is not considered to be "user level software".
---
From my perspective, it is -- programs run in kernel
space or user space. Glibc is used and linked to programs running in
user-space, not in kernel space.

Glibc is an application library that can run on linux or
on BSD or on other *nix'es. It's designed to be non-system specific.
That pretty much puts it in user space on any system I'm familiar
with.

It's intrinsic to nearly everything except the kernel itself,
and that ONLY because the kernel statically links whatever
it needs.
---
So dynamically loading modules don't exist in the kernel?
Or in Windows? or...whereever? The kernel doesn't statically linkk
everything -- it uses a specific list of functions that are known to
exist and stay in kernel space. It's not happenstance nor just a
change of a flag to static -- they are different versions than one
exist in the user-level glibc.


In every place I've ever worked "why not upgrade?" is not a
sufficient reason to upgrade a server.
---
I gave several reasons beyond that,

If it's doing what it
needs to do, then there's no reason to upgrade.
---
But I always want them to do more -- I'm a software
engineer, computer scientist. I'm not IT-support. So there is
some importance in not being too out of date. Suse9.3, for example
had a kernel that didn't provide very good SATA support. Neither
does it provide SAS support. As I already wrote -- I upgrade to
support newer software and hardware.


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.
---
Actually ... have been running 10.3 for ... several
months on multiple machines. My 9.3 server is the last system
to be upgraded because of stability concerns. It wasn't until
I used 10.3 for a few months and upgraded one of the platforms
from i586 suse->x86_64 (also live). My server is the *Last*
machine to be upgraded....not the first. Still don't want to take
it off line for an upgrade that can and usually does take several
days, minimum, up to several weeks (depending on what else is going
on). By not taking it down, I can leave it half way upgraded -- but
running and serviceable, and not stress out about not having my
main server offline (which would through my other systems off line
as well, it serving DNS, NFS, SMB-domain master, http-proxy(squid),
SOCKS, file-system backup, email server...among a few other
functions...

So rather than changing everything on the system at once,
which might result in the system not being able to due its normal
duties for some period -- I do the upgrade piecemeal and make sure
each important new piece works before I go on to break, er, upgrade
something else! :-)


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.
----
Asking which question? If anyone else does piecemeal
upgrades? OR if anyone else has or uses any tools that assist
them? Or if anyone else would find such programs useful?

So, in summary, your company needs to become acquianted
with the concept of "test platform" vs "production platform"
---
If only the budget would allow such find distinctions...
though, in truth it's better than it was. At one point the server
was also a prime compile and development machine as well as
being used for testing. I'm sure you are familiar with the
oft' repeated statement that most people don't make even close
to full use of their hardware -- that it just sits...well...
that's not usually me.


Untested installations, and especially upgrade procedures
are NEVER done on a production machine. That's *WHY*
you should have test machines.
---
I've been running 10.3 for some time on test machines.
I just haven't upgraded my most stable server exactly because
of the phrase "IF IT AIN'T BROKE...etc"... But there comes a
time when its time to move forward...*carefully* -- not by
reformatting the system partition with a new install (which is
what would be required to go from 9.3->10.3), but one "step"
at a time, so as not to break things. One "step" doesn't
necessarily mean 1 single rpm package. I seem to remember one
rpm command having around 30-35 required packages on the same
command line. At the time, I had to track those deps down manually.
(It's not like the rpm has a "what-provides" query feature that
works to find out what rpm's need to be added to an rpm line to
make an install work. RPM's "what provides" query only works
"retrospectively" on what's already installed :-(.


Are you finding software bugs in your 9.3 software?
---
Not so much lately, but I did report ones found when 9.3
was newer. I continue to do so for 10.x. But I am finding
software deficiencies in 9.3 -- not so much support for SATA or
SAS, firewire-800 also required a newer kernel.


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.
---
And how many releases back will SuSE support upgrading
from? Only 1. How long does MS claim they'll support older software?
About 2 years if you are lucky. Does HP even still market HPUX?
I thought it was near dying -- that they'd been switching too linux
for the most part. Most of the big-iron companies with 10 year
support contracts are having financial difficulties. It becomes
increasingly costly to support old or out-of-date hardware. Even
my server -- when I topped out it's memory, the chips for it were
already twice as high as newer chips because it was from the
previous generation...supporting older HW gets increasingly costly.
If it died, I'd like just replace it with one of the newer workstations
(used as test machine) that's about 12x faster.... But it's a source
of "pride" being able to keep old hardware running and *useful* ---
not having to waste money on new systems when not needed.


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.
----
I, and the machine are not part of the IT department --
I and the machine are in research.


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."
---
It really is more about what color desktop you are
sporting...whether or not it color coordinates with your outfits,
and is in style...etc....:)


choose to move ahead -- on my schedule when its convenient for
me.
That's the wrong schedule.
----
NO...it's the right schedule -- because I do things
when I am capable of doing them given time, resources, energy
money...etc.

You need to do it when it's convenient for the business.
That's why you're employed.
---
It's convenient when I have the time...:-) It
wouldn't be convenient, ever, if my upgrade knocked my other
systems off the net for a few hours (unless I'm very swamped dealing
with the problem, in which case, I won't notice it...:-)).


IF it's necessary to upgrade this machine now, then you
need to hop on a plane, and do this upgrade properly.
---
If only I got paid enough to do that...*sigh*...

At this point, I'm leaving the remaining 50% of this
unaddressed, because I have other things I need to do.
---
That's fine -- as this is mostly an "intellectual"
discussion for me at this point. The original question was
trying to discern if anyone else worked this way, had utils
they used, or knew of, or if they would find such utils helpful.
or if "anyone else" was "interested in this subject". Or if
there was a better place to ask and talk about this --

For whatever reason, the people on this list aren't very
open to experimental hacking -- it seems like more people are focused
on, or coming from IT issues rather than exploring what one can
do and how one might improve on things.

If people don't think about what works, what doesn't work,
and what's a pain, things won't change or improve. It is real
unfortunately, but most people (myself included at times) have lost
any sense of wonder or fun or sense of exploring and testing what
works and what doesn't. It's not about "right" and "wrong" or
"black" and "white", but finding "better" ways to do things
(where "better" is obviously a multi-value variable)...

-l

--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

Relevant Pages