[BlueOnyx:08189] Re: Upgrade path 5106R to 5107R + migration advice

[Michael Stauber]

Hi all,

> As with the move from BlueQuartz (on CentOS 
> 4) to BX 5107R (on CentOS 5), there are far too many dependencies and 
> integrations to offer a reliable "upgrade" process.  That's not to say 
> that it can't be done.  If you've got plenty of time to kill and don't 
> mind experimenting with the box and its data, you may well be able to 
> get it done.  But I wouldn't recommend it.

Yeah, those are really good points and all valid.

I thought a bit about a "unsupported" method of migrating from CentOS5 to 
SL6.1. Like one that I could do, but one which wouldn't be for the faint at 
heart or those uncomfortable to work on the command line.

If one has physical access to the server and can boot it off a rescue CD, or 
if it's an OpenVZ VPS, where one can directly access the files on the VPS's 
file system area while the VPS is stopped, then there are *possibly* some ways 
to get it done. In theory. But even that could be wishful thinking as I 
haven't tried it yet.

The procedure would require you to be able to work on the file system of the 
stopped server. Either by manipulating the VPS's file area from the master 
node of an OpenVZ host, or by booting a physical server off a rescue CD. Then 
you'd need to manually remove of ALL files EXCEPT the DNS records, MySQL 
database, the CODB database, the config files for Sendmail, ProFTPd and a few 
other services. And you of course would leave the sites and users aboard. Once 
that's done (and you'd need to be really, really careful not to remove too 
much or too little) one could do a chrooted YUM install into the file area of 
the stopped VPS or the mounted filesystem of a physical box.

The chances to get it right first time around are minimal and the amount of 
time involved is probably five times longer and a hell of a lot more 
complicated than doing a CMU based migration.

There is also something that I call "suspension of disbelieve": Whenever 
something goes wrong with that "transformed" box, or whenever it acts slightly 
funny, you will wonder if you didn't make a mistake during the transformation. 
And trust me: You probably will have made a few mistakes during the course of 
it. With such a massive undertaking that's kind of unavoidable.

So yes: It can *perhaps* be done with some advanced Linux wizardry. But it's 
about as practical as trying to install 5107R onto original Cobalt hardware. 

The involved effort is prohibitively large, it'll be hard to generate a 
reproduceable procedure and there is way, way too much that can go wrong along 
the lines and that will trash all efforts to begin with.

So no: CMU is the only real way to do it. And CMU got a hell of a lot better 
since 2-3 years ago, so now it actually works and does a pretty good job.

There are also other things to consider, of which I just got reminded about 
over the weekend:

There are still a hell of a lot of people using BlueQuartz. Which uses 
CentOS4, which will get EOL'ed in seven months. Even now patch support for 
CentOS4 is a joke right out of a greek tragedy. And it will not get any better 
than that the closer this deadline comes.

Partially that BlueQuartz usage is explained due to the need to run some 
legacy Frontpage sites. Frontpage has been killed off four or five years ago 
and there is no 1:1 Linux based alternative around. When CentOS4 gets EOL'ed, 
you'll end up with a dead solution on an unsupported OS. Personally that would 
give me nightmares.

Then there is the PHP issue: PHP-5.3 is the currently maintained "stable" 
version of PHP. While some vendors still support older versions of PHP with 
backported fixes (like PHP-5.1.6 on CentOS5), anything older than PHP-5.3 has 
been EOL'ed upstream by php.net

Likewise PHP-5.3 introduces many changes, which prevents older non-PHP-5.3- 
ready code from running. Hell, there are even people running code on 
BlueQuartz that's not even PHP-5.0 ready at all.

So my suggestion would be: If you're still on a BlueQuartz box, then you have 
roughly half a year left. Use that time to convince your users to get their 
PHP scripts PHP-5.3 ready or to move away from Frontpage. Set them a deadline 
and don't let them talk you out of it. Cite security reasons and insist that 
the only alternative would be that they get a dedicated box of their own 
instead, for which you don't accept any responsibility in case it gets hacked. 
Anything else will bite you into your gluteus maximus in the not so distant 
future.

Once the deadline is reached, migrate straight to 5107R and skip 5106R.

Why skip 5106R? CentOS5 will be EOL'ed in March 2014. Which sounds like ages 
away. But given the sorry state of things over at the CentOS project I'm just 
one of many who wonder if they'll last that long before they realize that 
their years of mismanagement have driven the CentOS project against the wall 
and turned it into an unsalvageable wreck. While it will be possible to turn a 
CentOS5 box into a SL5 box without much hassles, moving to 5107R is the better 
alternative.

Is 5107R production ready? Yes, it is. I'd say it has less issues than 5106R 
and given the choice: Whenever I set up a new box, I'd chose 5107R over 5106R 
all the time.

-- 
With best regards

Michael Stauber
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.blueonyx.it/pipermail/blueonyx/attachments/20110823/6609af55/attachment.html>