Earl R Shannon
Earl_Shannon at ncsu.edu
Mon May 19 10:02:34 EDT 2003
There's a lot of things you haven't said that we would need to know.
And the first thing I would say doesn't involve anything technical.
Manage your users expectations. How you make the move and the fallout
from any problems that may result can be greatly mitigated if the users
understand what is happening. I know its seems so obvious, but some
things do bear repeating.
50 Accounts, but how much data?
Will the users have to use a new server name to connect to their email?
Is the authentication database going to have to move?
What we have done in the past is this (Not necessarily in the order
Create the accounts and subfolders on the new server as they exist just
before moving the data. We script this using IMAP::Admin in perl. This
helps avoid any database conflicts since we are only using the IMAP
protocol. You could dump the data from the db3 to flat file and import
it on the new servers and I expect you would save considerable time over
our method, particularly if one were moving large numbers of accounts
such as we did.
Move the data, reconstruct the accounts.
We have a CNAME for each user that has an account with us that points to
their IMAP server, ie joeuser.mail.ncsu.edu would point to the imap
server that joeuser's account is on, so we have to update the CNAME in
our DNS database. We shorten the TTL for the zone the CNAME records are
in. Our users use the CNAME to configure their clients so they don't
usually need to do anything when we move them. The biggest problem we've
run into with this is the time out of the DNS records. Helpful cacheing
nameservers may keep bad data. Really nothing we can do about that
though. We also use HESIOD and have to update that as well.
Our authentication method doesn't require us to do anything when we move
people. We are using saslauthd with the kerberos5 mechanism. If you have
an authentication database residing locally on the machine then it
will have to move as well.
During the move the users permissions are set so that all they may do is
read their mail. We also have a defer list that sendmail reads before
attempting to deliver email which the accounts being moved are added to.
This prevents new mail delivery into the old account while its being
moved to the new account. Once the accounts are moved they are removed
from the defer list.
Anyway, that's pretty much how we did it. We moved four servers with
almost 10,000 accounts per machine. It's considerable work for us and is
one reason why we are very interested in getting the Cyrus Murder
implemented. The abstracting out the mailbox location, along with our
new IMAP servers using a SAN, will change moving accounts to a
hopefully much simpler process.
Systems Programmer, Unix Systems, Information Technology Division
North Carolina State University
David Reid wrote:
> I need to move about 50 accounts from one machine to another. Basically it's
> time to change servers so the new server is being built and made ready, and
> while cyrus is installed I need some way to move the accounts and the
> messages over. Current server uses berkeley DB 3.2 and new server is using
> berekeley db 4 if that makes any difference. Of course I'm aiming for as
> little downtime as possible.
> Anyone got suggestions?
More information about the Info-cyrus