I have task in hand , there are few servers running RHEL4.4 I am required to upgrade them to RHEL4.8 I have a standby server having repos(rpms) of rhel4.8.What would be most reliable method to upgrade rhel4.4 server to rhel4.8 and most viable technique to rollback if required.

Thanks in advance .

Regards.
Pragul

Your Fallback methode is depending on your configuration. Are these VirtualMachines or BareMetals? Is the bootdisk on SAN or local?

Some general advice:
If these are production servers and/or if unsure: don't do this alone.
Take the time to make a plan and to test.
Save configuration data (cfg2html etc)
Start with testservers, then development, acceptance and finally production.
Make a snaphot or a clone from the bootdisk if possible, do this while server is down.
If the servers bootdisk is a local disk, use Clonezilla to make a recovery backup. TEST IT (on a different server).
Before starting the upgrade, reboot te server and test if everything still works.
Check if the server needs firmware upgrades if BM) and also the hba.
Good luck!

1 members found this post helpful.

The best and safest way would be to put in brand-new hard drive(s), load 4.8 to them, and migrate your data/applications over. If you need to 'roll back', you just put the old hard drives back in, that are configured with 4.4. You could even do that on your standby server, and migrate one server at a time, testing each to make sure everything is working. That way, your original OS/configurations are unchanged...at the end of everything, you'll be left with a few spare hard drives, which are cheap anyway.

The more obvious question is WHY would you bother 'upgrading' to an OLD, UNSUPPORTED OS??? The latest RHEL is 6.4...and if you're not PAYING for RHEL, you shouldn't be using it.

1 members found this post helpful.

the very last rhel4 was RHEL 4.9
it was supposed to go end of life last year , but it got a reprieve from the executioner
( from 7 year support to 10 year support)
RHEL4.9 is on "EXTRA" extended life support
you have to buy the "extra" support

seeing as you ? are ? paying for the extra support , have you contacted red hat ?

1 members found this post helpful.

Thank you Xrgm ,TBone and John VV for your prompt replies.

Xrgm:- These machines are IBM blade ,local boot(no SAN connection at all),I am asked to upgrade OS to facilitate hardware up gradation.

It would be really helpful , if you could suggest me method which I have to adapt to perform this OS upgrade.
Should

1)I set up a NFS export of RPMs from the standby server and mount them locally on these servers(RHEL4.4).

2)#rpm --test -Uvh *.rpm(to check dependency)

3)Download required dependency move to exported directory.( repeat 2 and 3 steps till it clears all dependency)

4)Install and repackages patches. #rpm --repackage -Uvh *.rpm

Roll back strategy:-

# rpm -Uvh --rollback '2 hours ago'.

Can anyone suggest more reliable technique than the above strategy for update and patch rollback.

I have heard of up2date utility as well ,can I anyone help me with client end configuration to repos on standy( I don't have much experience working on rhel4 systems)

TBone:I don't have scope to addd a new disk to these systems.These are very few critical servers running web services and client wanted to keep it untouched till now,but with pressing need of improved hardware to withstand increasing load they have decided to do hardware upgrade ,and this OS up-gradation come up with recommendation from hardware vendor.

JohnVV:- we don't extended support subscription from redhat.

We did suggest things, but the most important thing we said was DO NOT 'upgrade' to an old, unsupported OS, and call Red Hat support for help. That apparently needs to be said again. RHEL 4.8 is old and unsupported, period. You SHOULD NOT BE USING IT, especially if you're not PAYING FOR IT.
If you're the administrator, you should know that you should NEVER use RPM to upgrade entire systems (nor CAN YOU), but you should use yum instead, which will resolve your dependencies. And, since you CANNOT download the required dependencies (since, again, RHEL 4.8 is NOT SUPPORTED), you're back where you started.
Again, unless you're PAYING for RHEL, up2date is not going to work for you...and this illustrates how old your systems are, since up2date is not even used any more. If you don't have experience being an administrator on RHEL systems, you really shouldn't be performing this entire upgrade, but need to get someone who knows how to work with production systems.
Sorry, that's just not true. If the company has purchased brand-new servers, then spending an additional $69 on disks to make sure the upgrade goes smoothly is trivial. Especially if you're purchasing brand-new IBM blade servers. Also, I have never worked ANYWHERE where there wasn't a few spare hard drives laying around.

If these are 'critical' servers, then why are they using old, unsupported OS, and not PAYING for it?? That doesn't say there is much 'critical' about them, since they're not being taken seriously. If you want to do the best job, you need to load the latest version of the OS, apply any patches/upgrades, and migrate the software over. Test it after that, and roll it into production. Repeat with each server. Doing an in-place upgrade of a 'critical' system is dangerous, and more so when you're 'upgrading' to something obsolete.
If you're not PAYING for Red Hat support, then you should not be using it, especially in a production environment. Load CentOS instead.

Totally agree with the above. You must absorb it, then go back to your mgr and explain the hole his systems are in.
He needs to spend some money by 1 or more of

1) getting support from RH - highly recommended

2) get test machine to try out upgrades - critical for prod systems

3) jump to current RHEL eg 6.4 WITH support

4) engage an experienced RHEL guy and maybe consider moving on to Centos if not willing to pay for RHEL, as you'll get not updates/support otherwise.
Think of the security considerations as an example; your current systems are wide open

TBOne:- Thank you for the prompt and expert advice from you , I agree and understand the fact that RHEL4 is no more supported by Red Hat ,the situation I have in hand requires me to upgrade rhel4.4 systems to rhel4.8 (unfortunately no other option) we can't migrate them to higher OS version any other distro,as client suspect that it will throw off apps running on it.

For additional HD I had checked with guy at DC , he of option that to add a HD on prod server would require a change approval and its very tedious and time consuming process indeed and I have to execute the upgrade in very short duration, might be in next 2 days.

It as known fact that Yum is nothing but RPM with wrapper ,and yum utilizes, RPM in its background,hence if we have all required dependencies in repos ,RPM should work like a charm ,(thats what I belief is ,can be wrong as well).

I am planning to get dependencies downloaded from some trusted ftp sites on Internet I am still a newbie to system administration world hence I would request expert advice from Linux guru like you.

then PLAN FOR the near 100% certainty of a FUBAR'ed system

one that might NEVER boot
clone those drives first !!!!!!

and DO NOT expect manually installing rpm's ,from some random site, using rpm to work well .

There are a few things wrong:

• Any apps written for one version of Linux will (more than likely), run just fine on another. It would depend on HOW the app was written, what it was written IN, if the libraries it calls are static or dynamic, etc.
• If you are the consultant, you should be advising your client to TEST the applications and KNOW if it works or not. Just going the lazy way through without testing and knowledge is doing your client a disservice. Find out...that's what they're paying you for.
• Again, if you're a consultant, why are you advising your client to use an old/outdated and INSECURE operating system? You should be advising them to do what is BEST for their company, not what's easiest for you to migrate them to.

YOU need to build a test server, move their application(s) to it, and TEST THEM. Do it with the latest version of CentOS, and it won't cost you anything except a bit of time. Identify any application problems, and SOLVE THEM.
...and we're back to "you haven't tested things, so rushing isn't a good idea". And, since this is your client, THEY control the schedule...and can push it back as needed. Who cares if its a tedious process for them?? They set the rules, and can do what they like...tell them it's required, and it'll happen.
Oh? It's a 'known fact'?? From who/where did you get that information?? Yum may USE rpm to install packages, but the tracking/dependency resolution behind the scenes is NOT anything like just the base rpm command, which is why any decent administrator would not use it.
And we have given it...but you are ignoring ALL OF IT, and keep arguing that what you're planning is a good thing. It isn't. There are no 'trusted' FTP sites for old OS RPM's, and even if you DO manage to find them, they are old, insecure and out of date.

Do a proper job. Update, test, and resolve issues NOW, rather than having to kludge together something and hope it works. Even *IF* the VERY BAD PLAN you've put together works (and it probably won't), all you've done is move from one old, unsupported platform to another, and you've STILL got bugs, security holes, and software that still needs to be updated. FIX the problems...don't just patch them..

1 members found this post helpful.