[Dovecot] migrate 15K users to new domain name
I need to migrate 15K users to a new domain name, and plan to use "dsync mirror" in the transition phase. Could someone confirm that this should work:
Before giving users access to new-domain do a first sync to get all the stale data over:
for user in $old-domain; do
dsync mirror $user@old-domain $user@new-domain
doneConfigure sieve vacation filter to forward all messages from $user@old-domain to $user@new-domain, and notify sender of changed address.
Give users access to both new-domain and old-domain, and do a final sync.
for user in $old-domain; do
dsync mirror $user@old-domain $user@new-domain
dsync mirror $user@old-domain $user@new-domain # twice in case the first was slow
drop all messages for $user@old-domain
Leave notice message for $user@old-domain saying he should use new-domain
doneWait a few weeks/months, and then drop all users@old-domain.
Does this look sensible?
-jf
On Thu, Apr 19, 2012 at 11:22, Jan-Frode Myklebust janfrode@tanso.netwrote:
I need to migrate 15K users to a new domain name, and plan to use "dsync mirror" in the transition phase. Could someone confirm that this should work:
Before giving users access to new-domain do a first sync to get all the stale data over:
for user in $old-domain; do dsync mirror $user@old-domain $user@new-domain doneConfigure sieve vacation filter to forward all messages from $user@old-domain to $user@new-domain, and notify sender of changed address.
Give users access to both new-domain and old-domain, and do a final sync.
for user in $old-domain; do dsync mirror $user@old-domain $user@new-domain dsync mirror $user@old-domain $user@new-domain # twice incase the first was slow drop all messages for $user@old-domain Leave notice message for $user@old-domain saying he should use new-domain done
Wait a few weeks/months, and then drop all users@old-domain.
Does this look sensible?
-jf
What do you mean by a "new domain" in this context? Is the server changing? Is the storage changing? In my thinking, a domain change is as simple as using a rewrite rule in your MTA. I am sure I didn't understand your requirement and as such my response is equally vague.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223
I can't hear you -- I'm using the scrambler. Please consider the environment before printing this email.
On Thu, Apr 19, 2012 at 02:01:44PM +0300, Odhiambo Washington wrote:
What do you mean by a "new domain" in this context?
The user's email addresses are changing from username@old.domain to username@new-domain.
Is the server changing?
No.
Is the storage changing?
The user's home directory is based on the user's email address, so this is changing.
In my thinking, a domain change is as simple as using a rewrite rule in your MTA.
Also the user's login-names needs to change from old to new domain, and all their data needs to move from old to new domain.
-jf
On Thu, Apr 19, 2012 at 16:28, Jan-Frode Myklebust janfrode@tanso.netwrote:
On Thu, Apr 19, 2012 at 02:01:44PM +0300, Odhiambo Washington wrote:
What do you mean by a "new domain" in this context?
The user's email addresses are changing from username@old.domain to username@new-domain.
That can be handled by address rewrites within the MTA.
Is the server changing?
No.
Is the storage changing?
The user's home directory is based on the user's email address, so this is changing.
In my setup, I have virtual users. So the home directory is in the /var/spool/virtual/$domain/$user/mdbox
How is yours setup? If the domain name changed, from domain1 to domain2, I believe it would be easy to change as follows:
cd /var/spool/virtual/ mv $domain1 $domain2
Well, it the size of $domain1 is in TBs, I'd probably do it another way as doing mv is a bit dangerous with very large datasets:
cd /var/spool/virtual
mkdir domain2
cd domain1
for d in ls -1; do mv $d domain2/$d; done [ or something closer]
In my thinking, a domain change is as simple as using a rewrite rule in your MTA.
Also the user's login-names needs to change from old to new domain, and all their data needs to move from old to new domain.
And the login names are stored in a flatfile or db?? Either way, you can do a rename. Dump the database and just use vi to rename old-domain to new-domain, then drop the db and import the dump.
mysqldump dbname dbname.sql
vi dbname.sql :g/old-domain/s//new-domain/g mysqladmin drop dbname mysqladmin create dbname mysql dbname < dbname.sql
You can also edit the flatfile to s/old-domain/new-domain/g cat flatfile | xargs sed -i.BAK 's/old-domain/new-domain/g'
Maybe I still don't understand you:-)
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223
I can't hear you -- I'm using the scrambler. Please consider the environment before printing this email.
On Thu, Apr 19, 2012 at 05:03:01PM +0300, Odhiambo Washington wrote:
In my setup, I have virtual users. So the home directory is in the /var/spool/virtual/$domain/$user/mdbox
How is yours setup?
mail_home = /srv/mailstore/%256LRHu/%Ld/%LnIf the domain name changed, from domain1 to domain2, I believe it would be easy to change as follows:
cd /var/spool/virtual/ mv $domain1 $domain2
If I could figure out what the %256LRHu hash is, mv would probably be a very good solution..
And the login names are stored in a flatfile or db??
LDAP
Either way, you can do a rename.
No, we need to keep the old username/password working, so that all users will get notified of the changed -- even if they take off on a 6 month vacation the day before the change.
Maybe I still don't understand you:-)
You seem to be understanding perfectly well. I've been looking myself blind on dsync mirror, when a simple "mv" probably will work just as well :-)
-jf
On 19.4.2012, at 17.19, Jan-Frode Myklebust wrote:
mail_home = /srv/mailstore/%256LRHu/%Ld/%Ln
If I could figure out what the %256LRHu hash is, mv would probably be a very good solution..
With v2.1.4 you could do something like:
doveadm -c dummy.conf user -m user@domain
where dummy.conf contains the minimum configuration needed:
mail_home = /srv/mailstore/%256LRHu/%Ld/%Ln ssl = no
It still does a userdb lookup though, so either the user@domain needs to exist in userdb or you need to create a separate dummy Dovecot installation using userdb static that the dummy.conf uses.
On Thu, Apr 19, 2012 at 05:59:39PM +0300, Timo Sirainen wrote:
With v2.1.4 you could do something like:
doveadm -c dummy.conf user -m user@domain
where dummy.conf contains the minimum configuration needed:
mail_home = /srv/mailstore/%256LRHu/%Ld/%Ln ssl = no
Thanks! Works perfect.
-jf
participants (3)
-
Jan-Frode Myklebust
-
Odhiambo Washington
-
Timo Sirainen