[SLL] Procedural advice wanted.

[Ski Kacoroski]

On Mon, 2009-03-16 at 18:09 -0800, Paul Franz wrote:
> I have a server I want to upgrade with a clean install. I don't want to take the
> server down until it the replacement is working. In order to do the upgrade I need
> access to the running server for files to transfer and existing configurations to
> reference.
> 
> If I install the OS on a new machine in the network, it will have the name and IP
> associated with that name. Maybe I should do that and change the name before testing.
> It seems to me this will be frought with problems. Maybe the configurations for
> installed software such as bind, mail, dovecot, etc will take on the characteristics
> of the new machine, for example. Or maybe the test didn't work and I have to change
> the name back to something else.
> 
> There are quite a number of files under /etc/ that have the server's name in it so
> renaming would be a chore.
> 
> Any advice?
> 

Paul,

There are a few approaches I have used in this situation;

1. If I do not have extra hardware, then I copy the configuration files
to a laptop or other machines (e.g. /etc and whatever else).  I then
take down the server, wipe the disk, reinstall and can refer back to the
configuration files as needed.  If possible I also do a full backup to
tape just in case I missed a configuration file that was in a strange
place.  This does require downtime.

2. If have a second machine, I build up the new machine with a different
IP and a temporary name in dns, but the same name as the hostname and in
the local hosts file.  I try to set up most of my services on secondary
IP's so I can move them between machines easily (e.g. 10.1.2.10 is the
primary IP which I use to manage the server, but 10.1.3.10 is the IP
that the service runs on).  This makes it very easy, after I have
configured the service on the new machine to turn it on 'live' -- just a
simple edit of the network config file and a networking restart.

If you cannot do the above idea, then I bring up the server on a
different IP, test the service on it, and when it all looks good do a
cutover where you edit the config file on the new server to have the new
IP and then do a restart on the new server and a shutdown on the old
server.  If things go wrong, just back it out (about 5 minutes of
downtime depending on the reboot cycle), and then figure out what
failed, fix it and try again.

3. Convert to a VM.  I am a big, big fan of virtualization.  In fact if
you are starting a new server from scratch you should consider putting
ESXi on the hardware and building the server on top of it.  For starters
you will most likely be able to run 2 - 3+ servers on the same hardware.
You also may be able to separate out your services between machines to
make it easier to perform maintenance.  In the longer term, this will
make future migrations easier as you just move a file between host
machines.  And it doesn't cost you anything extra.

Good luck,

Ski

-- 
"When we try to pick out anything by itself, we find it
 connected to the entire universe"            John Muir

Chris "Ski" Kacoroski, kacoroski at gmail.com, 206-501-9803
or ski98033 on most IM services