Zimbra offers Open Source email server software and shared calendar for Linux and the Mac
Go Back   Zimbra :: Forums > Zimbra Collaboration Suite > Installation

Welcome to the Zimbra :: Forums!
Welcome, if you would like to post a comment please register. We also encourage you to explore all things Zimbra with our team and members of the community.

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 03-31-2006, 09:25 AM
Former Zimbran
 
Posts: 294
Default Migrating from "mdir" to Zimbra

I have a Surgemail Server that stores mails as mdir format.

I also have a Zimbra Server. I gathered from the Forums that Zimbra stores the Metadata in database and the Message seperately in a MIME file.

I wish to migrate from Surgemail to Zimbra. But I authenticate my users using Enternal LDAP. The OpenLDAP server that contains users' passwords, encrypts them. I have many users - such that I cannot ask passwords from all. I do not want to change their passwords.

One solution for migration that I understand is as follows:

1. Save Users' Passwords from LDAP.
2. Set a New Password for all Users, one which is known by us.
3. Migrate Users' Accounts using this new password and an IMAP Migration tool, such as IMAPSync.
4. Reset the Users' Passwords to their Original ones.

One disbenefit, that I foresee in this process is that, from the time when I change the user's password until the time when this password is reset, the User cannot login because he will use the password that LDAP had earlier but is not using it now because his account is being migrated. I also understand that I can only change the password for the user who is being currently migrated and after restoring his original password, I would proceed with the next user.

However, I have a many users who have tens of thousands of messages and being extremely heavy users of email, are continuously accessing it. In this case there will be a service downtime for these users which I cannot afford.

Also, I would want to Sync the messages, that I receive/delete/send in Zimbra with Surgemail, about twice a day. Again, while I Sync these messages via IMAP, these users will see downtime.

So, I am looking for a solution which will enable me to: Migrate from Surgemail to Zimbra, and, Synchronize Accounts on Surgemail with Zimbra (after migration) as a routine without knowing the Users' Passwords.

For this, I am willing to spend some time and write a script if it is not very difficult to understand what to do. I know a little Perl and if I can be given a few tips, I might be able to manage 2 scripts one for each purpose.

Thank-you,

- Chintan.
Reply With Quote
  #2 (permalink)  
Old 03-31-2006, 09:29 AM
Zimbra Employee
 
Posts: 4,792
Default

imapsync shouldn't cause downtime. You should be able to do it while user's are logged in.

For auth you can just have Zimbra auth against your existing LDAP and this will keep you from needing to sync passwords. You'd still need something to sync create/delete's in LDAP but that's an easier problem to solve.

Is this a temp solution and eventually you'll turn off the old system, or do you actually plan to run both systems in parallel for a long period of time? If so why?
__________________
Bugzilla - Wiki - Downloads - Offline Client
Reply With Quote
  #3 (permalink)  
Old 03-31-2006, 09:58 AM
Former Zimbran
 
Posts: 294
Default

Yes, Kevin, you are right in that IMAPSync will not cause any downtime. In fact, none of the systems will have a downtime. However, there will be a downtime in service to the user because we would be changing the password in order to do the IMAP migration - since, IMAPSync will not transfer messages unless we provide it with the User's Password on both IMAP Servers.

This password will not be known to the User - and so he will not be able to access his mailbox while the messages are being transferred. Because, even if I use Zimbra's Internal Authentication, I would still need to Authenticate myself on Surgemail.

We are currently in the process of testing Zimbra and if all is well - maybe in a few months - we would migrate completely to it. In addition, so far the most universal thing is IMAP and so to keep integrity of emails in a format that can be used by "any" email aplication it is essential to maintain Surgemail - atleast for the time being - until our organization decides to part from it.
Reply With Quote
  #4 (permalink)  
Old 03-31-2006, 10:11 AM
Elite Member & Volunteer
 
Posts: 255
Default

My suggestion would be to setup a slipt domain: http://wiki.zimbra.com/index.php?title=Split_Domain then migrate the users a few at a time instead of syncing twice a day. You may have to do some after hours work when the user or users have left for the day, but that is the life of an admin. If for some crazy reason you decide not to implement Zimbra you can always migrate the user back. IMHO I believe you are making it out to be much more difficult than it really needs.
Reply With Quote
  #5 (permalink)  
Old 03-31-2006, 10:39 AM
Former Zimbran
 
Posts: 294
Default

Thank-you for your reply rsharpe. I think what you say, might be a good idea if I had users in one Timezone.

We have users in almost all countries - and all the users are active and have very heavy usage. The smallest mailbox I know is about 2500 Emails!

I am not a Senior Linux Admin and have limited experience working in a Production Environment like this - which is why, probably, I am trying to take extra care.

If no previously implemented solution exist then I was hoping to learn how the messages are stored in Zimbra. This way I can probably conduct a few experiments...

Thank-you,

Sincerely,

Chintan Zaveri.
Reply With Quote
  #6 (permalink)  
Old 03-31-2006, 10:55 AM
Elite Member & Volunteer
 
Posts: 255
Default

It'll still work if you have users across multiple timezones.

For example i'm in EST (GMT -5) timezone, and say I have a users in PST (GMT -8) timezone I could migrate all those PST users at 8am EST, that would make it 5am PST. Most people would be sleeping at this time and wouldn't notice the change. I would have to say you are at an advantage because you wouldn't have to do all your work after hours at midnight, because for some employees it will be midnight for them but 1pm for you, and thats when you do the work, no disruptions for them, I wouldn't imagine they're sending emails at midnight. Would you agree?
Reply With Quote
  #7 (permalink)  
Old 04-01-2006, 09:18 AM
Former Zimbran
 
Posts: 294
Default

Yes I agree
Reply With Quote
  #8 (permalink)  
Old 04-04-2006, 06:16 AM
Junior Member
 
Posts: 7
Default Migration Techniques

I don't think imapsync supports it yet, but Cyrus SASL supports the concept of proxy authentication. That's where you authenticate as an admin user, then you pretend to be a normal user. This way you don't have to mess with resetting each user's password.

I used a simular method in a custom Python script when we migrated our users from Sendmail to iPlanet a few years ago.

Another useful tool is Perdition.

http://www.vergenet.net/linux/perdition/

It's an IMAP/POP proxy server. We used perdition to do a gradual migration, and it redirected the users to their correct mail box.

Hope this helps.

Rick
Reply With Quote
  #9 (permalink)  
Old 04-04-2006, 09:15 AM
Zimbra Employee
 
Posts: 4,792
Default

Quote:
Originally Posted by rholbert
Another useful tool is Perdition.
For the record Zimbra ships this by default.
__________________
Bugzilla - Wiki - Downloads - Offline Client
Reply With Quote
  #10 (permalink)  
Old 04-04-2006, 12:04 PM
Former Zimbran
 
Posts: 294
Thumbs up Thank-you

Thank-you very much rholbert and thank-you very much Kevin. This will help me very much.

Will post a story once the migration is over (maybe by this weekend).

Sincerely,

Chintan Zaveri.
Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads

Why Join?

Registering let's you ask questions, makes it easier to search, displays any files attached to posts, and notifies you about replies.

blog.zimbra.com




 

SEO by vBSEO ©2011, Crawlability, Inc.