Moving accounts

Earl R Shannon Earl_Shannon at
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 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.

Earl Shannon
Systems Programmer, Unix Systems, Information Technology Division
North Carolina State University
ph: (919)-515-5480

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?
> david

More information about the Info-cyrus mailing list