Looking Ahead - Upgrade

[Rick Stevens]

Sam Varshavchik wrote:
> Rick Stevens writes:
> 
>> Sam Varshavchik wrote:
>>> Rick Stevens writes:
>>>
>>> The only problems you'll ever have will not be as a direct result of 
>>> the upgrade, per se, but rather the new stuff occasionally not 
>>> plainly working. I recall one upgrade, I think it was Red Hat 5, that 
>>> loaded a kernel that had a bug that caused a complete freeze, and 
>>> that was triggered only on certain hardware, and I won the lottery. 
>>> That caused a little bit of excitement. Of course, a fresh install 
>>> won't make much of a difference here.
>>>
>>> The rules are pretty simple:
>>>
>>> * Do not install stuff manually, cowboy-style. Always use rpm to 
>>> install software packages, instead of crossing your fingers before 
>>> running 'make install'.
>>
>> Not always possible.
> 
> Oh? Since when did both emacs and rpmbuild stop working, preventing the 
> creation of an appropriate spec file, and producing the rpm packages?
> 
>>                        I recently had to put OpenSSL 0.9.8g on a CentOS
>> 5.1 machine to pass a certain certification.  The latest OpenSSL for
>> CentOS 5.1 is 0.9.8b (farking ancient).  I did it by building it from
>> a F9-Preview source RPM, building it (with some tweaks as F9 has some
>> ciphers that CentOS 5.1 doesn't have),
> 
> So you were able to install the software via rpm. So your point is…

It was NOT a binary RPM.  It was a heavily tweaked source RPM and would
probably blow up an upgrade.  I won't say that definitively, but it's
bloody likely.

> 
>>                                        installing the binaries and
>> poking various symlinks and such to make existing apps happy.
> 
> Was there some bugs in emacs that prevented you from putting those 
> symlinks into the spec file?

I don't know.  I don't do emacs and I had to get it done at like 2:00 
a.m. to meet a deadline.  I buggered the spec with vi and did some
rebuilds.  It was dark, they were big....

>>                                                                So, Rule
>> 1 can't ALWAYS be adhered to, no matter how "stock" you want your system
>> to be.
> 
> Well, in 13+ years I've managed to adhere to the rule without much of a 
> problem. And that included patching out the kernel bug I referenced in 
> my previous message.
> 
>>> * Know your software. If you're running MySQL or Postgres, dump your 
>>> database before the upgrade. Major dot-releases of Postgres will 
>>> often refuse to boot up with the previous release's database. You'll 
>>> need to nuke your entire DB, start Postgres and have it initialize a 
>>> fresh DB, then load your dump. Other major software packages may have 
>>> their own idiosyncrasies.
>>
>> The fact you've had good luck in upgrades is (to be honest) a bit
>> anecdotal.  There have been many, MANY people with completely stock
>> systems that have crashed and burned BIG time.  Even Red Hat doesn't
>> recommend an upgrade more than 2 revs up (e.g. F7-->F9).
> 
> Well, I gues I've been lucky then, upgrading from one release to 
> another, for 13+ years, with multiple machines containing wide varities 
> of hardware.

Yes, you have.  And this wasn't meant to start a flame war.  All I'm
saying is that yes, it sometimes works (perhaps more often than not),
but sometimes it ends up as a smoking hole in the ground.  Be careful.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer                       rps2 at nerd.com -
- Hosting Consulting, Inc.                                           -
-                                                                    -
-    "Hello. My PID is Inigo Montoya.  You `kill -9'-ed my parent    -
-                     process.  Prepare to vi."                      -
----------------------------------------------------------------------