For now no, the gateway and sa hosts will stay put.
Understandable about keeping the old server up while changes propagate.
The old server is using courier, but I guess dovecot could be a better
route. I've used it a little in the past on a different server. What kind of
difficulty am I looking at to switch from courier to dovecot? Also, how
would you recommend that I keep the maildirs up to date? Im trying to figure
out the best way to do that without causing either lost or duplicate mail.
Am I going to want to create tarballs of mailboxes and run some type of
conversion on them before restoring them, or utilize sync, or is there a
better way?
Thanks for all the help you've been offering...I certainly appreciate it.
Connected by DROID on Verizon Wireless
-----Original message-----
From: Eric Shubert <e...@shubes.net>
To: qmailtoaster-list@qmailtoaster.com
Sent: Tue, Oct 4, 2011 16:09:28 GMT+00:00
Subject: [qmailtoaster] Re: Migrating from Qmail Rocks install on Solaris to
Qmail Toaster on CentOS
webmail is imap, so that simplifies a little.
The big/first thing is to freeze any account changes before beginning
the migration. That's pretty much a must, and shouldn't be a big deal.
On the inbound side of things, are you planning to put everything in the
QMT host and eliminate your present gateway and SA hosts? That will
dictate how you'll go about migrating (dns vs routing change).
On the MUA/retrieval side of things, you'll need to have both the old
and the new operational for a period of time. Even after you change DNS
to point to the new host, it takes a while for the change to propagate,
so you'll have requests coming to both servers. After a day or so, you
can turn off imap/pop services on the old host and do a final data
migration to pick up any straggling emails.
BTW, I hope you're using dovecot on your new QMT host. If you haven't
done this yet, take the time to do it now. It's much more efficient than
courier, and does a great job of cleaning things up automatically that
may not be quite right, like index files and such. I would use dovecot
for both imap and pop. Check the wiki regarding dovecot.
--
-Eric 'shubes'
On 10/04/2011 08:36 AM, ca...@smileglobal.com wrote:
Thanks Eric. They use a little bit of everything. Some customers are
strictly webmail, some use pop and some use imap.
Now that those are in the mix, what do you think?
/Connected by DROID on Verizon Wireless/
-----Original message-----
*From: *Eric Shubert <e...@shubes.net>*
To: *qmailtoaster-list@qmailtoaster.com*
Sent: *Tue, Oct 4, 2011 14:59:40 GMT+00:00*
Subject: *[qmailtoaster] Re: Migrating from Qmail Rocks install on
Solaris to Qmail Toaster on CentOS
As I see it, you could use 2 different processes (or bridges) for
migration. One process migrates the accounts, and is done only one
time.
The 2nd process migrates the mail, and is done several times
(initially,
and periodically until the old host is taken offline). Both processes
are done initially, then you have the 2nd process migrate any
straggling
mail that comes in.
I don't recall you mentioning whether your clients use imap or pop or
both. The logistics can be a little different depending on which
they use.
HTH.
--
-Eric 'shubes'
On 10/04/2011 01:18 AM, Casey wrote:
> Ok guys, here is my next challenge...really, the biggest problem
I'm
> foreseeing at the moment:
>
> So here I am joyfully (as I curse at the computer under my breath
every
> time I find a new problem...) migrating all 4000+ users of the 392
> different domains using the migrate-domain script (if you aren't
> familiar, it basically creates a tarball of every mailbox
belonging to
> the domain, and then generates a script that when run will
recreate the
> domain, user accounts, mailing lists and forwards --with a minor
amount
> of fuss after the fact on the new system) --- so that is all good
and
> well, but here is where the problem comes in...I have 165GB of
data to
> migrate, and in the end I plan on taking down "Server A" and having
> "Server B" completely take over, except every second after data
has been
> migrated over to "Server B", there is a pretty good chance that
new mail
> is coming in for one of the 392 different domains.
>
> The problem is that as long as that old server is still up, I need
to
> worry about keeping the mail content consistent between the old
server
> and the new. Obviously I'd like to have the time between domain
> migration and server deployment down to a minimum, but some of my
> customers are quite large (600 or so email accounts, each of
which will
> need to be reconfigured on their end at minimum just to make sure
they
> are using smtp-auth, and probably changing the incoming/outgoing
server
> settings on a few systems that are statically set to use the
server's IP
> versus hostname.
>
> Normally I'd probably opt to use rsync to keep the new server
in-tune
> with the old one, but I'm not sure that is exactly an option,
because
> the old system has vpopmail compiled with "many-domains" enabled,
in
> addition to "big user dirs", so once again I'm trying to
interface with
> a different folder structure -- for example, on the old system we
have
> domains that are broken up in the domain's directory by number
(i.e.;
> domains/0/abc.com, domains/1/bca.com, domains/cad.com, etc) as
well as
> users broken up by number in a similar fashion (i.e.;
> domains/abc.com/0/postmaster, domains/1/bca.com/demo,
> domains/cad.com/2/test, etc). Since I'm trying to standardize, I
don'
> want to have to compile those features in...but that makes it
difficult
> to use something such as rsync to run against a domain folder
with the
> flags set that will delete files from the destination that don't
exist
> on the host. So what do I do? I need a fairly automated way to
keep the
> mail synchronized between the servers before we take the old one
down.
> At the moment, there is enough manual intervention required in
migrating
> the domains, that it doesn't seem realistic to try to get all the
data
> migrated and current the day that we decide to do all of this.
>
> I'm really really really hoping that someone out there has some
ideas
> and can help me out with this one. I'd like the least amount of
service
> disruption possible, and can't run the risk of missing or losing
email
> for my customers. I want to get this to work, because my next
project is
> to setup a replicated qmailtoaster, which should be much easier
to work
> with and can use rsync and/or unison to get things in check.
>
> There has gotta be a few Toaster Master's out there that have the
> perfect solution...all I need is one good idea ;-)
>
> Thanks in advance,
>
>
> Casey
>
> Smile Global Technical Support
> Submit or check trouble tickets http://billing.smileglobal.com
> www.smileglobal.com <http://www.smileglobal.com>
>
-----------------------------------------------------------------------------
----
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and
installations.
If you need professional help with your setup, contact them today!
-----------------------------------------------------------------------------
----
Please visit qmailtoaster.com for the latest news, updates, and
packages.
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com
-----------------------------------------------------------------------------
----
Qmailtoaster is sponsored by Vickers Consulting Group
(www.vickersconsulting.com)
Vickers Consulting Group offers Qmailtoaster support and installations.
If you need professional help with your setup, contact them today!
-----------------------------------------------------------------------------
----
Please visit qmailtoaster.com for the latest news, updates, and
packages.
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail:
qmailtoaster-list-h...@qmailtoaster.com
