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@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org