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

Greetings all, and first let me say congratulations to all those involved in 
the Debian project in general, and specifically I''d like to thank those
responsible for doing such a versatile and powerful packaging job with 
Exim4. Sarge is my first experience with Debian on one of my servers, and as 
they say - "it just keeps getting better". I cut my teeth on RH 7.0
and ran
it through 9, but after being left "high and dry" decided not to go
down the
Fedora road. Necessity dictates a major server overhaul, and Debian''s
won
both my respect and admiration due to it''s structure, capabilities, and
community. 

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" :)

Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.alioth.debian.org/pipermail/pkg-exim4-users/attachments/20050807/e407d74a/attachment.htm

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