Meet the Gang   1   2   3   4   5   6   7   8   9

Just wondering

From andrew

Answered By Jim Dennis, Faber Fedor

This is a multi-part message in MIME format.

[Faber] First off, this is a major no-no around these here parts. Please send your emails as text only, NOT as HTML. Most of us will refuse to read HTML (because we don't use Outlook, Netscape, etc.). We even have one guy here who carries around a riffle for people who send MIME formatted emails!

I'll answer your Q this time, but any more that come in as anything other than text only will be ignored (at least by me).

[JimD]

Note that his message was in text and HTML. This is more of a venial sin; though MIME handling of some text mode MUAs isn't all that good and both sections seemed to be in MIME parts (one text/plain and one text/html).

Hello,

[Faber] Hi.

I am wondering if you could help.

[Faber] We try our best.

My question is if i was to buy a Redhat 7.2 CD & choose the Upgrade will i expect my major services to break or will this upgrade be able to make it as painless as possible.

[Faber] Yes, it will be as painless as possible and yes it will break things. It all depends on what you are running. If you save your configuration files (the Upgrade promises to do that, and I beleive it but I don't trust it), you should have minimal problems. Red Hat will save your config files as config_file.rpmsave, so you'll still have to go in and "fix" stuff.

Outside of that, the only problem I've had upgrading a system is when the 2.4 kernel didn't have a driver/module for the RIAD controller and we had to drop back to the 2.2 kernel and it broke DNS because the BIND on the CDs is looking for a specific 2.4 kernel feature. Outside of that, they've all gone well.

[JimD]

Personally I prefer the "scorched disk" upgrade method. That's where we do a fresh installation to a new disk and copy our data and configuration over.

Obviously this works best if you have (at least temporary use of) a whole system on which to perform your staging.

Debian is the only system that I regularly upgrade from one major release to the next without "scorching the earth" beneath it. In other cases I've just seen too many artifacts and quirks in other operating systems when upgrading core libraries and system components.

An advantage to the "scorched disk" approach is that you have an obvious back of the entire system throughout the process. You can easily switch back to the old system. So it represents a lower risk than the typical "boot from the new distribution CD, cross you fingers and pray" process (herein-after referred to as the "boot and pray" technique).

If you don't have a whole system to spare then get a spare hard disk. Most systems have a spare interface/channel to which a third or fourth IDE device can be attached (and PCs with SCSI subsystems almost always have spare IDs and spare IDE interfaces). Care should be taken when connecting a new IDE hard drive to an IDE chain with any other IDE device already on it. (I once wiped out a system by accidentally configuring two drives as masters --- the pinouts on those used to be harder to figure out; bad documentation. Luckily the customer's backups were good and recent).

After you get the new drive in place and make it bootable, be sure to mount the old filesystems in read-only mode during the transition.

When your done with all of the data and configuration transfer you can put the drive on a shelf for a few weeks, months, or whatever. When the filesystems on the old drive are so far out of date that you wouldn't use them in the worst case --- then the drive is ripe for putting into a new system.

Of course its possible to do this using tapes, CDR, DVD-RAM or whatever removable media you normally use for your regular backups. However, the mismatch between the sizes of most production filesystem and removable filesystem media make this convenient. Tapes are big enough but they must be accessed using archiving utilities which is also inconvenient.

So it is best to use an extra drive where you can.

The hardest thing about any upgrade is knowing when you're done. How confident can we be that everything is working? This is one of the challenges to professional systems administration that remains largely unsolved.

Ideally we should be able to run an automated test suite which would test each service and application on our system(s) (locally and from remote systems, including some from "out on the Internet" for public servers). Recently I've been reading about "Extreme Programming" which advocates the continuous creation and maintenance of automated test suites which are integrated into the sources and makefiles of a software system. I've come to the conclusion that sysadmins need to adopt similar practices. We need something like an /etc/systest/Makefile what launches these checks for a given host.

However, that's work for another time -- an article of its own. For now you'll just have to muddle through and test your newly (upgraded) system using whatever procedures you normally use to

This page edited and maintained by the Editors of Linux Gazette Copyright © 2001
Published in issue 73 of Linux Gazette December 2001

HTML script maintained by Heather Stern of Starshine Technical Services, https://www.starshine.org/

Meet the Gang   1   2   3   4   5   6   7   8   9