Looking Ahead - Upgrade

[Rick Stevens]

Sam Varshavchik wrote:
> Rick Stevens writes:
> 
>> Gene Poole wrote:
>>> In the near future I would like to upgrade my server machine from 
>>> Fedora 8
>>> x86_64 to Fedora 9 x86_64. This machine has several key components 
>>> running,
>>> including Oracle 10G, Samba, and Apache - Tomcat.
>>>
>>> Has anyone any idea what I can expect so I can plan ahead?
>>
>> Always back stuff up.  Expect it all to go to hell and force a
>> reinstall.  That's the only truly safe way.
> 
> Well, one of my machines originally had Red Hat 3.3 installed, and it's 
> been upgraded with every release since then, until the current Fedora 8 
> (not to mention all of its hardware replaced in the interim). It's as 
> stable as a freshly-installed box.
> 
> Upgrades are never a problem, if you follow some simple, straightforward 
> rules.

Uh, oh.  I smell trouble...

> 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.  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), installing the binaries and
poking various symlinks and such to make existing apps happy.  So, Rule
1 can't ALWAYS be adhered to, no matter how "stock" you want your system
to be.

> * After each upgrade, open /root/upgrade.log, and filter out all the 
> whining from rpm about the configuration files. For each configuration 
> file, open the carried-over one that was left in place, take all the 
> changes you have in the old file, manually merge it into the .rpmnew 
> file, then replace the old configuration file with the .rpmnew file.
> 
> * 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).

All I'm saying is be prepared for the worst.  Yes, it may (and probably
will) be OK, but it may not as smooth as you'd like.

Your mileage may vary.  Batteries not included.  <insert desired
disclaimer here>
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer                       rps2 at nerd.com -
- Hosting Consulting, Inc.                                           -
-                                                                    -
-              "Swap memory error: You lose your mind"               -
----------------------------------------------------------------------