Modifying Cyrus IMAP to ease a migration to Gmail?
Dan White
dwhite at olp.net
Wed Oct 3 11:46:21 EDT 2012
On 10/03/12 10:51 -0400, Brian Chase wrote:
>This may be a question more geared toward the developers of Cyrus, but I
>figured I'd start with this list.
>
>Some background information & context:
>
>I work at an organization with a Cyrus Murder cluster that contains several
>hundred thousand mail accounts. We're beginning the process of migrating
>these accounts to Google's Gmail. (No fault of Cyrus' as a product, but
>we've decided as an organization that we don't want to be supporting all
>those users and maintaining over 10TB of imap data stores. That said,
>Cyrus works quite well at that scale.)
>
>Anyway, so the consulting company we're working with to help us with the
>migration is using Google's GAMME tool. It's a mail migration tool that
>works with Exchange and IMAP servers to pull the data out of the old mail
>servers and into Google's servers. It's a pretty limited program, and
>unfortunately, for it's IMAP support is more limited than we'd like. The
>GAMME tool takes simple lists of users, in a formatted text file, and uses
>that information to login as each user on the IMAP server and then copy all
>their mail onto the Google server. The problem with that is it needs the
>plain-text passwords for all the existing users to be able to log into the
>IMAP server.
Page 25 of the Administrator's Guide points to a solution using an
administrative password, rather than specifying the user's password, such
as:
adminuser#adminpassword, cyrususer1
This may work if you specify a proxyservers user on your frontend
(adminuser).
>Now, like any sane organization, we don't keep track of our users'
>passwords in plain-text, so we can't generate these user lists that GAMME
>wants. And we also are unwilling to say, reset over a half a million user
>account passwords with ones we would then know.
How are you planning to transfer the passwords to gmail?
Consider enabling 'auto_transition: true' within /etc/imapd.conf, on each
of your frontends, which would store the cleartext password of each user
the next time the login, into /etc/sasldb2.
>What I'm thinking of doing:
>
>To get around this problem what I would like to do is to setup a custom
>Cyrus front-end server. The front end server would be isolated on our
>network and only be able to talk to the other relevant Cyrus servers and to
>the systems we have running the GAMME tool. For the custom front-end
>server I think it should be possible to modify the source code that handles
>the authorization to bypass the normal process. I want the customized
>server to allow connections to the individual accounts on the back end data
>store servers using either a specific hard coded password or to just allow
>authentication with any password. Is something that would work given the
>Cyrus Murder architecture, and if so, which source code files for Cyrus
>contain the relevant authorization routine(s) that would need to be changed?
On such a frontend, or on an existing frontend listening on a protected IP,
you could bypass authentication with 'pwcheck_method: alwaystrue' (if your
libsasl2 was compiled with --enable-alwaystrue).
In /etc/cyrus.conf:
gammeimap cmd="imapd" listen="10.0.0.5:imap" prefork=0 maxchild=100
and in /etc/imapd.conf:
gammeimap_sasl_pwcheck_method: alwaystrue
--
Dan White
More information about the Info-cyrus
mailing list