If anyone is interested, we have a perl script that does the following:

The script will:
#1) obtain list of mailboxes under the old UI via direct IMAP calls
#2) create the new mailboxes via direct IMAP calls
#3) do the recursive copy of mail files from old UID to new UID
#4) reconstruct new UID mailbox
#5) get the seen file for the old UID and prep for the new UID
#6) get the contents of all cyrus.header files for old & new UIDs into arrays
#7) hula-hoop thru seen file stuff; do tricky search and replace
#9) handle search and replace for old UID to new UID in <newUID>.sub file
#10) move any sieve scripts to the new UID


I can't say it is a perfect implementation because it does not try to address items 2 or 3 below, but these are not used extensively in our environment.

If you would like a copy, email me directly and I will be happy to send it,

John Wade


Rob Siemborski wrote:


On Mon, 30 Jun 2003, twk wrote:



Then Why Cant I similarly rename
'user/username ----> user/newusername '


Because you can't. It's an architectural limitation of Cyrus.



This isn't true. Its certainly possible, its just quite laborous to do correctly.



Here is what we do :

- Create a new account (new)
- cp -r /imap/user/o/old/* /imap/user/n/new
- reconstruct -r user.new
- delete old account

I wouldn't consider that particularly laborious.



Except you haven't renamed the user, you've just renamed the mailbox.


To rename the user you need to also do the following:

1. move the subscriptions, seen state & sieve scripts (ok, this isn't
hard)
2. change the ACLs on all the mailboxes so that the old username is
replaced by the new username (this is quite intensive to do on a large
mail store)
3. update the group memberships (since cyrus doesn't control its own
group memberships, this involves the use of an outside process somehow).

There is an 'allowusermoves' option in 2.2 that does some of this, but (2)
and (3) just can't be done in any efficient way using the current scheme
(We have thought about using numberic uids for users, but that would be a
significant architechural shift).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper








Reply via email to