[SOLVED] Migrate from postfix/Maildir/OpenBSD to Zimbra 5.0.21/CentOS5 - no passwords

[blueflametuna]

Greetings, (apologizing in advance for the long post)...

I have read that imapsync can be used here, but I am a bit fuzzy on the procedure. I have a new Zimbra server in production, just finished an upgrade, so I'm already margainally familiar with it. It has several domains on it. I also have an older production server running postfix with another domain and about 800 users. My goal is to migrate all those users and the domain onto the zimbra server.

I have seen two types of scripts:
One uses zmmailbox addMessage (not what I think I want), and imapsync.

I have been trying to figure out how to use imapsync to accomplish this, but found that without having passwords, there are a few issues.

We are prepared to tell the users that once we switch to the new server, we will provide them with the new temporary password, and that they should change it when they log in the first time. But I am still not sure how to access their account on the old server using the scripts. Something about an admin auth? Please help me with this concept...

Before I digress further, (please stop me), here's what I am thinking:

On Zimbra server:

* Create migration domain - call it migrate.com
* Create users from list - user1@migrate.com ...
* Run imapsync for each user from production.com to migrate.com
* Create production.com domain on Zimbra
* Rename all users from user1@migrate.com to user1@production.com
* Delete migrate.com

* Change DNS to point email traffic to Zimbra server
* Decommission old production server.

Some questions:

Some of the user accounts have more than just the
/var/mail/user/Maildir/new cur and tmp folders.
There are subdirectories like:
.Sent/new
.Draft/new
.Trash

and some with spaces:
.Sent Messages
I have seen one example of a script that handles those.

- - -

On our Zimbra, the default disk quota size is 50MB.
Many of the users have much more than that.
Do I need to increase the size of their quota prior to the migration?
Unlimited for all?

- - -

Once there, will all of the messages appear as unread?

- - -

Assuming I can get past the password issue, can I get there from here?
Or am I just a clueless old-school newbie?

Thanks for not flaming. ;-)

[blueflametuna]

I now have imapsync installed on the source server. (That was fun.)

I was able to connect using the --justconnect option,
but without individual users' passwords, I do not see a way to migrate the data. Am I missing something obvious here?

Am I going to need to modify every user password to something I know on both source and destination servers to do this?

Any suggestions?

Thanks!

[Matuscak]

Originally Posted by blueflametuna

I was able to connect using the --justconnect option,
but without individual users' passwords, I do not see a way to migrate the data. Am I missing something obvious here?
Thanks!

You didn't mention what imap server you've got on the source box, but at least for Dovecot, what you want to do is configure "Master User" support. Take a look at this article on the Dovecot wiki: Authentication/MasterUsers - Dovecot Wiki. Once that is set up you use --authuser1 on the imapsync line to pass the Master User password. You can create an admin account in Zimbra to do the same thing there.

[blueflametuna]

Yes, dovecot. 1.0.rc7

I've added the following to the dovecot.conf file:

auth_master_user_separator=*

...
passdb passwd-file {
args = /etc/passwd.masterusers
master = yes
pass = yes
}
...

Got an error trying to telnet in. I am assuming that the config changes have not been read in. What's the magic incantation to restart dovecot?

Also, you mentioned that I can do the same on the Zimbra side.
I already have an admin account, or at least I am a user with admin privileges. Is there anything else that needs to be done in Zimbra?
I can still create new users and give them all the same password, if needed.

Thanks for your help. There have been a lot of views, and no replies.

[blueflametuna]

OOps. Crash and burn. Tried a kill -HUP <pid> to reload dovecot.
Then wasn't able to connect. Restored the original configuration.
Not sure what I broke, but it was bad.

(Yes, I know, dovecot v1.2.10 is available.)

[Matuscak]

Originally Posted by blueflametuna

...
passdb passwd-file {
args = /etc/passwd.masterusers
master = yes
pass = yes
}
...

Got an error trying to telnet in.

FWIW, my configuration does not have the "pass = yes" option in it. I've never tried the telnet test before, but after getting an error, I noticed that
the command is literally "1 login loginuser*masteruser masterpass", including the leading "1".

Also, did you create the /etc/passwd.masterusers file with:
# htpasswd -b -c -s /etc/passwd.masterusers MasterUser MasterPassword

I am assuming that the config changes have not been read in. What's the magic incantation to restart dovecot?

It's been a while since I've used *BSD, but IIRC, look in /etc/rc.d.
Something like: /etc/rc.d/dovecot restart

Also, you mentioned that I can do the same on the Zimbra side.
I already have an admin account, or at least I am a user with admin privileges. Is there anything else that needs to be done in Zimbra?
I can still create new users and give them all the same password, if needed.

I don't think there was anything that needed to be changed on the Zimbra settings. Here's a (slightly munged) code fragment that that moves a mailbox from our old server to Zimbra:

#!/bin/bash
#

#++
# Use this for transferring directly from mailhub's IMAP server to Zimbra.
# Change user1 and user2 to the desired accounts.
#--
imapsync --user1 matuscak --user2 jgmtest@foo.com \
--buffersize 8192000 --nosyncacls --subscribe --syncinternaldates \
--host1 mailhub.foo.com --authuser1 admin --password1 'AdminPassword' --authmech1 PLAIN \
--host2 mail.foo.com --authuser2 convert@foo.com \
--password2 'ZimbraPassword' --authmech2 PLAIN -ssl2

exit

[blueflametuna]

When I made these config changes:

auth_master_user_separator=*

...
passdb passwd-file {
args = /etc/passwd.masterusers
master = yes
pass = yes
}
...

and restarted dovecot, I was no longer able to connect.
There was something wrong with the syntax.

I found in the wiki that the masteruser was added as a feature as early as v1.0_b4, so it should be in rc7. But I did not find the line commented out for auth_master_user_separator in it. Does space matter?

Is this any different?

auth_master_user_separator = *

Thanks for the tip on the login command. (Missed the "1").
If I can get past the .conf syntax issue and restart dovecot successfully, I will give it another try.

[Matuscak]

Originally Posted by blueflametuna

I found in the wiki that the masteruser was added as a feature as early as v1.0_b4, so it should be in rc7.

On a CentOS system we used for conversion, the RPM claims to be dovecot-1.0.7-7.el5

But I did not find the line commented out for auth_master_user_separator in it. Does space matter?

Is this any different?

auth_master_user_separator = *

I don't think spaces are significant, but I think the location of the passdb passwd command is important. It should be in the auth default section of the file.

FWIW, If I grep out all the comments in my dovecot.conf file, here's all that's left:

protocol imap {
}

protocol pop3 {
}

protocol lda {
postmaster_address = postmaster@example.com
}

auth_master_user_separator = *

auth default {
mechanisms = plain

passdb passwd-file {
args = /tools/mail/dovecot.masteruser
master = yes
}

passdb pam {
}

userdb passwd {
}

user = root

}

dict {
}

plugin {
}

[blueflametuna]

Similarly, here is the new config file - which does not load:

protocol imap {
}

protocol pop3 {
pop3_uidl_format = %v-%u
pop3_client_workarounds = outlook-no-nuls oe-ns-eoh
}

auth_master_user_separator = *

auth default {
mechanisms = plain

passdb passwd {
}

passdb passwd-file {
args = /etc/passwd.masterusers
master = yes
pass = yes
}

userdb passwd {
}

user = root
}

---

I wasn't sure about where to insert the new parameters.
My best guess is the two passdb entries may be in conflict.
There is a user database file built from the system password file.
It looked like I would still need both to allow current users to still login,
and add the master user concept. I could be wrong.

[blueflametuna]

Found it in the logs:

Feb 11 08:44:47 myhost dovecot: SIGHUP received - reloading configuration
Feb 11 08:44:48 myhost dovecot: auth(default): Last passdb can't have pass=yes
Feb 11 08:44:48 myhost dovecot: Auth process died too early - shutting down
Feb 11 08:44:48 myhost dovecot: child 360 (auth) returned error 89


It would appear that order is significant.