Move of mailboxes
mailing_lists.cyrus_info at melson.fastmail.net
Thu May 5 06:08:22 EDT 2011
> Is there a recommended procedure to do the move? Any pointers (even to
> pitfalls) are welcome.
I'm actually in the middle of migrating two backends of a Murder
(2.2.13p1) to new machines (and Cyrus version, 2.3.16, though it doesn't
sound like you're switching Cyrus versions in your case). Full
disclosure, no idea if this is the recommended procedure and 2.2.13's
probably too old to be that useful, but it's been working for me.
The way I've been doing it is writing a small script that:
1) Checks $cyrus_var/proc to see if the user is logged in.
2) If they are not, connects to one of the proxy frontends, changes
permissions on the mailbox to (temporarily) stop the user from
manipulating it if they were to log in mid transfer.
3) Issue a rename (which I think ultimately just makes an XFER call to
the appropriate backend?) of the format: "user.melson user.melson
mailboxes3.example.com!partition1" (for example).
4) Set the permissions back to normal after success. (I may be changing
this permission switching to temporarily deny the user authentication,
that method just didn't fit my environment when I started this).
The script's just some perl using Cyrus::IMAP::Admin, and it should be
fairly easily to replicate in anything with an IMAP library.
(It's basically the same process I use to shuffle people between
backends in the murder environment normally, which was handy from a
laziness standpoint; the process is used for moving from 2.3.16->2.3.16
backends as well)
It's been pretty successful so far, no user has noticed anything amiss
(that said, most of my users are relatively light users), and delivered
email just gets queued up during the transfer as near as I can tell.
I've found it to be an ideal way to go about migration/upgrades - I can
introduce users into the new environment slowly to catch configuration
"glitches", make sure I didn't misjudge the resources I would require,
etc, etc. Very handy. It's been good about catching problems, even (I
have a customization that extends the valid characters in mailboxes I
forgot to apply on the new machines; the XFER noticed right away and
left the user's mailbox unmoved and unmolested)
Oh, one thing I forgot - I'm fairly sure you *do* have to set
allowusermoves: 1 in your configuration if you're using this method.
The gotchas I've run into are probably more quirks of the environment
I'm working with or relics of a relatively old Cyrus at this point, but
I'll share them in case they are useful.
*) I've had some weirdness if the transfer gets interrupted in the
middle (I forget the exact symptom, but the mailbox on the home spool
was flagged as REMOTE (or something like that), but it hadn't actually
made it over to the new machine - a simple ctl_mboxlist -m on the
backend fixed it up since the frontend had the right information).
*) This is probably more my environment than anything else, but I've had
to throttle the moves and not run too many simultaneous moves in
parallel or I basically overwhelm the server I'm migrating from - it
seems to actually be the delete of the mailbox from its old home that
hits the hardest. I've not looked into it much, because, old crusty
server (2.4 kernel, ext3 file system; like I said, probably my
melson at fastmail.net
More information about the Info-cyrus