[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.net>wrote:
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.net>wrote:
That can be handled by address rewrites within the MTA.
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]
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:
mail_home = /srv/mailstore/%256LRHu/%Ld/%LnIf 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:
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.
participants (3)
-
Jan-Frode Myklebust
-
Odhiambo Washington
-
Timo Sirainen