= Cyrus IMAP Aggregator =

== O que é ? ==

É uma forma de você escalar horizontalmente o Cyrus IMAP entre vários servidores.[[BR]]
Para provedores com um número muito grandes de caixas o servidor IMAP se torna um componente muito crítico, [[BR]] 
a falha de um servidor acaba afetando a milhares de usuários. A idéia do Aggregator é que você possa particionar[[BR]]
o problema distribuindo as caixas entre vários servidores.


== Como funciona ? ==

Existem basicamente 3 tipos de servidores envolvidos:

'''Frontends''' - São os servidores em que os clientes IMAP/POP3 e MTAs(Mail transfer Agent ) se conectam.[[BR]]
Para os clientes eles funciona como se fosse um servidor imap/pop3/lmtp normal. Quando uma operação é disparada[[BR]]
ele verifica no MUPDATE em que Backend está localizada a caixa do usuário e dispara a operação neste Backend.[[BR]]
Se você move a caixa do usuário para um Backend diferente para o usuário é transparente já que o Frontend[[BR]]
sabe a nova localização da caixa do usuário através do MUPDATE.[[BR]]
Os Frontends funcionam de forma redundante. 
   

'''Backends''' - São os servidores aonde fica localizado efetivamente a caixa do usuário, a diferença deste servidor para
um servidor IMAP Cyrus normal é que toda a operação efetuada nele é commitada no servidor MUPDATE. 


'''Mupdate''' - É o servidor que coordena as operações do ambiente, ele funciona como um tipo Banco de Dados.[[BR]]
Ele é responsável em informar aos Frontends a localização da caixa do usuário e em coordenar as operações efetuadas[[BR]]
pelos Backends. Se o mupdate master está fora não é possível criar novas pastas , nem alterar as propriedades das mailboxes.[[BR]]
A entrega também fica comprometida, mas abaixo na documentação é citado como contornar esta limitação.


== Como o Expresso atualmente se comporta com o ambiente configurado em Aggregation (Murder) ==

O Expresso funciona normalmente com o Cyrus Aggregator. A única adaptação necessária[[BR]]
é informar no '''/etc/imapd.conf''' os seguintes parâmetros:

{{{
.....
defaultserver:  backend1
defaultpartition: default
.....
}}}

Por enquanto no Expresso não é possível selecionar em que servidor IMAP[[BR]]
e em que partição você quer criar a caixa IMAP. Por isto estes dois parâmetros[[BR]]
devem ser informados. As caixas criadas pelo módulo Expresso Admin vão ser criadas[[BR]]
inicialmente neste servidor e partição, mas depois você pode movê-la entre qualquer[[BR]]
backend e partição do ambiente.

== Como mover uma caixa entre os Backends ==

Basta usar o comando '''RENAME''' do IMAP.
{{{
cyradm --user admin frontend1
frontend1> rename user/joe user/joe backend2!default
}}}

== Instalando e configurando um Frontend ==

== Instalando e configurando um Mupdate ==

== Instalando e configurando um Backend ==

== Como otimizar a entrega LMTP para usar o Mupdate local e não o Mupdate Master ==

Por padrão o lmtpproxyd utiliza para consultar aonde devem ser entregues a mensagem o '''mupdate_server:''' informado no arquivo[[BR]]
'''/etc/imapd.conf'''  ou seja se você tem um número muito grande de entregas você acaba sobrecarregando o MUPDATE MASTER com as solicitações.

Uma maneira simples de resolver este problema é fazer o lmtpproxyd do Frontend usar o próprio mupdate para consulta ao invés de usar o mupdate master.
A configuração é realizada da seguinte forma:[[BR]]

Copie o '''/etc/imapd.conf''' como um arquivo '''/etc/imapd-local.conf''''

{{{
  cp /etc/imapd.conf /etc/imapd-local.conf
}}}

Edite o arquivo '''/etc/imapd-local.conf'''

{{{
mupdate_server: 127.0.0.1
}}}

Depois edite o '''/etc/cyrus.conf''' e mude o serviço lmtpptoxyd para usar este arquivo ao invés do default.

{{{
SERVICES {
 ..............
  lmtp    cmd="lmtpproxyd -C /etc/imapd-local-lmtpd.conf" listen="lmtp" prefork=1
 ...............
}
}}}

Outra vantagem desta abordagem é que mesmo que o mupdate master falhe todo sistema continua entregando as mensagens normalmente.
Ou seja, os clientes continuam acessando as suas caixas IMAP, e a entrega continua normal mesmo com  o mupdate master fora.