[Pkg-exim4-users] Admin'd exim for a long time under RH, exim question about queue_only & configuring Debian's exim4 package in general

[Marc Haber]

On Sun, Aug 07, 2005 at 04:04:19PM -0700, Josh Matthews wrote:
> Now for the task at hand: our main mail server is located in our public 
> offices, however we've recently signed a colocation agreement with a 
> provider about 3 hours from our location. All of our other systems (Web 
> hosting & SQL, DSL provisioning equipment, etc) has been relocated (with the 
> exception of DNS), however now we find it's time to move the mail server. 
> Since it's a physical move, we can't avoid turning off the power for 2 or 
> three hours to server which is the lowest numbered MX record for all of our 
> domains, plus the domains we host. Obviously this is something that can be a > little distressing.
> 
> My plan has been to create a secondary server, which will temporarily take 
> over the primarys server's name in DNS. It's that new server which has been 
> configured with Sarge's exim4 distribution. I intend to set that server to 
> "queue_only" while the second server is being transported & installed in the 
> co-lo. Once it's been brought up on the new IP range, I intend to change DNS 
> once again for both our internal & hosted domains, so that our primary MX 
> record is the (now) colocated server, and change my backup server's DNS to 
> be the MX 20 of those domains. From what I can gather, once I initiate a 
> queue runner process on the backup server, it will treat all queued 
> "internal" mail just like all the other mail - i.e. using remote_smtp. My 
> question is two-fold:
> 
> 1) Does this like a reasonable solution, to those more experienced with 
> Exim? About the only other conclusion I could come up with was to allow the 
> backup server to deliver mail normally - local addresses to mbox spools & 
> remote_smtp for everything else. Than just append the contents of each old 
> mbox spool from the backup server to the user's spool on the new server.
> 
> 2) Considering that regardless of the configuration solution I use to 
> achieve this, I'll be keeping this server with a function Exim4, what's the 
> recommended method of creating the (extensive) macro file I'll need? My best 
> plan for that so far was to go through each of the conf.d/ files with a 
> yellow notepad and a pen, make a note of the dc_ variables and the values I 
> intend to change them to. Is this about what everyone does?
> 
> Thanks much for taking the time to read (and hopefully reply) to this, and 
> again special thanks to the maintainers of the exim4 package. No matter 
> what, I'm with this "for the long haul" :)

Why so complicated? The queue_only stunt is not necessary.

Set up the new server. Put all relevant domains in dc_relay_domains.

A few days before the change, put in the following MX records into all
domains in question:

old.hostname.of.main.server.example.com. IN old.ip.of.main.server
new.hostname.of.main.server.example.com. IN new.ip.of.main.server
spare.server.example.com IN ip.of.spare.server

@ MX 10 old.hostname.of.main.server.example.com.
@ MX 20 new.hostname.of.main.server.example.com.
@ MX 30 spare.server.example.com.

Then move the main server at your leisure. After main server has
successfully moved, remove MX 10 and MX 30. Wait a few more days, shut
down spare server.

This will work as follows: As long as your main server is still at the
old place, mail will go to old.hostname.of.main.server. In case of a
failure, foreign boxes will then try new.hostname.of.main.server.,
which is not yet reachable, so the third try is
spare.server.example.com, which will queue the mail and try for four
days to delver to the main server at both of its IP addresses.

The actual move is just another failure which will be handled as above.

When the main server is back, spare.server will eventually deliver
(automatically, no manual action needed) to
new.hostname.of.main.server.example.com, and even later, the world
will notice that new.hostname.of.main.server.example.com is actually
reachable.

After MX 10 and MX 30 have been removed, the move has completed.

otoh, you could just go ahead and move the server without any special
action. The world will queue your mail and eventually deliver. Just
make sure that you change the A record of your server before you
initiate the move, and you might want to reduce the TTL of that A
record a few days before. This is by far the easiest method of moving
which might be acceptable if the expected downtime for the move is
only a few hours.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835