Re: Perdition and mass migration

Simon Horman <[email protected]>
Newsgroups gmane.mail.perdition.user
Message-ID <[email protected]>
On Mon, Mar 29, 2010 at 01:02:43PM -0300, Raul Dias wrote:
> Hi,
> 
> I am planning a large pop3 -> pop3 + imap migration across data centers 
> and countries.
> 
> I just found out about perdition and I need to understand if it will 
> help solve a few problems.
> 
> 1 - Usernames with ' . ' (dots) in it.
> 
>          There are several usernames with dots in it.  The destination 
> server is a Cyrus Imapd with the default
>          hierarchy setup (no dots).
>          For what I read in the pertitiondb man page, I could use 
> something like:
> 
>                  (.*)\.(.*):$1_$2@newserver:port
> 
>          Where the account in the new server will obviously have an 
> underscore to replace the dot.
> 
>          Is this right?

Yes, that should work as you describe. You will also to enable the
username_from_database configuration directive.

> 2 - --outgoing_server* *SERVER_A,SERVER_B*
> *
>          It was not clear yet, how will --outgoing_server works.*
> 
> *        On each connection it will connect to one of ther servers 
> only.  Is that it?
>          If so, whats the advantage?
> *
> *        Or will it connect to both servers and retrieve messages from 
> both? (what I need)
>          I understand that on a imap server this is not so easy, but on 
> pop3 doent seems to be a big challenge.
> 
>          If this is not how it works?  Is there something that could be 
> done achieve this behaviour?

As it stands perdition only connects to one real-server.
If more than one real-server is supplied using the outgoing_server
option then those real servers are tried in order. Though
there is a (very simple) round-robin algorithm that selects which
one to try first.

Could you describe in a little more detail what you need to achieve
with two mailboxes? It may be possible to enhance perdition in order
to meet your needs.

> 3 - virtual domain support: user@domain
> 
>          This is not clear to me.
> 
>          For what I understood, this will be split into user as the 
> login and domain will be the host to connect.
>          Is that right?
>          If so, how can I prevent it?

There are several different ways that perdition can work in this regard.
It can split on the @ or it can treat user@domain as an atomic unit.

Firstly, if you have client_server_specification enabled,
then the user can specify the server using user@server.
This option is off by default.

Secondly there key used to lookup the user in the popmap.
This may or may be controlled using the query_key option.
The default is \U which means the full username, that is
user@domain and not just user.

Lastly there is the strip_domain option which allows
the domain name to be removed when querying the popmap;
performing local authentication (local authentication is disabled by default),
performing remote authentication; or some combination of these.
By default strip_domain is disabled.

There is some overlap between the query_key and strip_domain as they
were added to the perdition at different times.

>          Also How do I map it?
>          e.g.: user@domain to server:port
> 
>                  user@domain:user@domain@server:port
> 
>          is that it?

I would need to check the code for this case, but yes, that should work
as perdition should search from the end for the last @ and use it
to split the user from the server/port information. And if the
user contains a @, that should be fine.

An alternative is to choose a different delimiter, which can be more
than one character long. This required recompiling perdition.

Some popmap mechanisms, for example LDAP, don't require such complex
string composition as the user, server and port can be stored as
discreet elements.

______________________________________________
Perdition-users mailing list
[email protected]
http://lists.vergenet.net/listinfo/perdition-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.