Re: [cobalt-users] [RaQ 4] 'rough' process to renumber IP's with no downtime

["E.B. Dreger" <eddy+public+spam@xxxxxxxxxxxxxxxxx>]

BT> Date: Fri, 28 Mar 2003 21:31:04 -0800
BT> From: Bruce Timberlake

Thanks for writing this... it's been on my "to do" list, but you
just saved me (and many others) a good deal of time. :-)

I'd like to make a few additions...


BT> This process also assumes your ISP/colo/etc is continuing to route
BT> traffic for the "old" IP addresses, and has already started routing
BT> the new IP addresses to your RaQ as well. If this isn't the case,
BT> stop now and wait until the routing is set up.

One can begin renumbering even before the new IPs are routed.
Just make certain the IPs are indeed being allocated to you...
however, many (most?) ISPs will simply make the routing change.

Also, I recommend leaving eth0 set to the old address until one
is ready to ditch the old IP addresses.


BT> Verify the RaQ is listening for the new IPs by pinging the new IPs
BT> from another box.  If there's no answer, figure out what's wrong
BT> before continuing.  Figuring out what might be wrong is left as an
BT> exercise for the reader. :)

Some people block ping.  In this case:

* Attempt to establish a TCP connection to the new IP addresses.

* Clear the ARP cache.  Trying pinging from a machine w/ IP
  address in the new subnet.  If you see an ARP entry, the new IP
  is working.


BT> If you are providing the DNS info yourself, edit the 'records' file
BT> and do global search-and-replace to change all the IPs to the new
BT> ones.  Then "distribute" those changes to the zone files by clicking
BT> "Save Changes" in the Control Panel (or manually run the CGI).

Make backups of hand-editted config files before using the GUI.
It likes overwriting things.


BT> NOTE: All domains I host are externally registered, so step 3 is my
BT> "best guess" at what you should do if you are the authoritative
BT> nameserver for the domain(s). I have not tested this at all, so USE
BT> WITH CAUTION!

I prefer running DNS on machines that do nothing but DNS.  Even
if people don't take that approach, it's still necessary to keep
in touch with the slave servers... be sure the slaves know the
new IP of the masters, and the masters allow zone transfers from
the slaves.

Note that RAQs up through and including the RAQ4 are by default
all too eager to allow zone transfers to anyone. :-(  The RAQ550,
however, requires one to explicitly allow zone transfers.  :-)  I
don't know about the XTR.


BT> This may not be the best or "correct" way to handle renumbering (I
BT> have a nagging feeling that it may somehow break FTP or other
BT> services - I don't use them so I can't comment at the moment), but it
BT> worked for me when I only had a day or two's notice to "get it
BT> done"... and I didn't have any mail or web downtime for any domain
BT> I'm hosting, so I'm pretty sure it works...

Many/most services bind a socket to 0.0.0.0 instead of a specific
IP.  This accepts inbound packets to any IP address bound to the
system, and sends packets using the "default" specified by eth0.

Bottom line:  Most things should work.

Another helpful hint:  Grep almost all files (skip /proc, /dev,
/tmp, and such) for the old IP block(s).  It's a great way to
find things about which you forgot.


Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 (785) 865-5885 Lawrence and [inter]national
Phone: +1 (316) 794-8922 Wichita

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@xxxxxxxxx>
To: blacklist@xxxxxxxxx
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist@xxxxxxxxx>, or you are likely to
be blocked.