Atualizar caixas de correio cítricas e divididas

Question

Estou tentando atualizar um servidor Cyrus IMAP de 2.2.12 para 2.4.12 / 13.

Certo, eu sei que estou procurando um bom guia para fazer isso, já que minha versão atual é uma versão antiga. Eu acho que não será apenas atualizar a versão ou instalar o novo e importar a configuração, estou errado? Eu suponho que precisarei migrar as informações do banco de dados, mas não sei como fazê-lo.

Nosso principal e exclusivo servidor Cyrus está gerenciando mais de 10.000 usuários e suas caixas de correio correspondentes. Com a nova migração, queremos dividir esse servidor principal em servidores menores para dividir as caixas de correio por cliente. Como posso exportar apenas algumas caixas de correio do Cyrus 2.2.12? Eu quero exportar as caixas de correio seletivamente.

Eu encontrei ferramentas "Mailsync", mas não parece ser seletivo com caixa de correio. Existe alguma maneira de migrar para a nova versão do Cyrus corretamente?

    

Answer 1

(Cerca de oito anos atrás, migrei mais de 50.000 contas de usuário de um antigo servidor de e-mail (executando o uw-imapd) para um novo 'farm' de servidores que consiste em três servidores e executando o Cyrus. para criar um script de migração que faria o login no servidor antigo e copiasse os emails do novo servidor via IMAP uma conta de usuário por vez.Um servidor OpenLDAP + Perdition estava na frente dessa coisa decidindo para onde um usuário deveria ser encaminhado (para antigo servidor ou para o novo servidor) .A operação foi feita on-line sem qualquer tempo de inatividade.Isso está indo off-topic, então eu vou continuar com a minha resposta.)

Uma palavra de aviso: o trabalho que você vai fazer pode ser um pouco tedioso e digitar uma resposta curta o suficiente para você também não é fácil. :-) Aqui estão alguns pontos para você considerar.

Você tem algum trabalho a fazer. Atualizar o Cyrus em si não é impossível, mas a divisão dos usuários de um servidor para vários servidores ao mesmo tempo requer planejamento. Apenas copiar tudo, do servidor antigo para o novo, não funciona, pois o formato BerkeleyDB / skiplist foi alterado no meio e os arquivos de dados antigos não são utilizáveis fora da caixa.

Quando se trata da lista de usuários / caixas de correio, é melhor usar a opção ctl_mboxlist -d para despejar as informações de usuário / caixa de correio no servidor antigo em um arquivo de texto e ctl_mboxlist -u para carregar o conteúdo no novo servidor. Este é o caso se você apenas atualizaria o Cyrus e ao mesmo tempo mudaria para um servidor mais poderoso, porém único. As caixas de correio podem ser copiadas com rsync , seguidas pelo comando reconstruct -rfx user/* no Cyrus.

Se você quiser fazer a divisão ao mesmo tempo, convém testar se o comando xfermailbox em cyradm atualmente permite mover as caixas de correio de um servidor para outro. Em caso afirmativo, você pode simplesmente criar um script que chame xfermailbox 10 000 vezes e mova suas contas de usuário para onde desejar.

Outra dica: Você provavelmente precisará do comando reconstruct -rfx user/someaccount se descobrir que após a migração algum usuário não consegue encontrar as pastas / e-mails.

Tudo bem e dandy até isso, mas você já considerou o seguinte:

• Se você vai dividir os usuários entre vários servidores, você tem algo como Perdition ou Cyrus Murder cuidando de redirecionar logins POP / IMAP para corrigir o servidor de e-mail?
• Se estiver dividindo, você tem o OpenLDAP ou algum outro gerenciamento centralizado de autenticação / usuário?
• Se estiver dividindo, você configurou seu Postfix ou qualquer servidor SMTP para descobrir onde a conta de usuário realmente está?
• Você tem problemas de desempenho atualmente? 10 000 contas de usuários não são muito e, a menos que você tenha realmente alguns motivos sérios para dividir as contas de usuários em vários servidores, reconsidere cuidadosamente isso. Um armazenamento centralizado de algum tipo + dois servidores semipoderosos configurados no modo de failover ativo / passivo pode ser mais inteligente e mais simples em termos de administração do sistema. É claro que ter vários servidores menores com discos locais pode ajudar a distribuir a carga de E / S, mas a Cyrus diz 'Obrigado' se você der RAM suficiente e a E / S não deve ser um problema real.
• Se o motivo de sua decisão de dividir a carga em vários servidores for devido a problemas de desempenho, verifique se o seu Cyrus está usando o BerkeleyDB ou o Skiplist para mailboxes.db etc. O BerkeleyDB sem um DB_CONFIG bem ajustado pode facilmente matar o desempenho e / ou levar a deadlocks. Skiplist é mais livre de preocupações. Além disso, a implementação POP3 no Cyrus é muito entropia e se o seu servidor não tiver um gerador de números aleatórios baseado em hardware, os logins podem ser MUITO lentos sem rngd daemon ou Cyrus configurado para usar /dev/urandom em vez de /dev/random para aleatoriedade.

Espero que isso ajude você um pouco.

    

Answer 2

Você me deu boa pista para seguir.

De qualquer forma, vou responder às ideias que devo considerar:

• Temos perdição, mas estamos considerando manter a perdição ou mudar para o nginx.
• Temos o LDAP
• No momento, não tenho certeza disso e devo verificar e investigar
• Hoje em dia não temos problemas de desempenho, mas estamos crescendo e mais clientes estão chegando ao nosso sistema. Nós pensamos que talvez dividir por clientes ou grupos de clientes deve ser uma boa opção. Pode ser um trabalho tedioso do ponto de vista do SysAdmin, mas pode ser bom para o bussines e o SLA. Qualquer outra opção será bem recebida:)
• Como comentei antes, não temos problemas de desempenho, em qualquer caso, estamos usando o BerkeleyDB

Enfim, saiba que estou fazendo um esquema do que devemos fazer para o sucesso na migração, então não posso tentar os comandos que você me fornece.

Eu voltarei quando eu verificá-los.

Muito obrigado!