Expressolivre: Anexos e mensagens exportadas com 0KB

Ao exportar múltiplas mensagens simultaneamente pelo Expresso, o arquivo .ZIP gerado é inválido, com tamanho de 0KB, seguem as possíveis soluções para este problema:

1- Instalação do pacote ZIP, o aplicativo é executado para geração do arquivo compactado.

2- Caso a partição que contenha o diretório /tmp estava sem espaço, o arquivo não poderá ser gerado, portanto é necessário limpar o conteúdo temporário.

Caso o problema apresentado seja de espaço em disco conforme relatado na segunda soluções, os seguintes warnings poderão ser observados nos logs do PHP:

PHP Warning:  filesize(): stat failed for /tmp/email_hbncqub15lc2g6j1jfuc1nl306.zip in /var/www/expresso/expressoMail1_2/inc/get_archive.php on line 27

PHP Warning:  readfile(/tmp/email_hbncqub15lc2g6j1jfuc1nl306.zip): failed to open stream: No such file or directory in /var/www/expresso/expressoMail1_2/inc/get_archive.php on line 279

Destacando que a falta de espaço de diretório temporário também gera problema com a anexação de arquivos nas mensagens, uma vez que esse procedimento também utiliza esse espaço.

 

Anúncios

Sobre o Cyrus IMAP

Compartilho com vocês um pequeno trecho do conteúdo de treinamento baśico de Cyrus Imap, que irei oferecer gratuitamente:

O Cyrus IMAP (http://www.cyrusimap.org) é um servidor POP/IMAP de alta performance e altamente escalável, desenvolvido pela Carnegie Mellon University (CMU), ele possibilita acessos simultâneos (leitura/escrita) a uma mesma caixa postal e quotas e regras de acesso (ACL) a qualquer caixa da hierarquia.

Nos repositórios estáveis das distribuições (Red Hat, Suse, Debian,etc…) até o momento a versão disponibilizada do Cyrus Imap é bastante antiga (2.2.13), que não é mais atualizada, recebendo somente atualizaçõs de segurança. Portanto, recomenda-se a utilização da versão atual, 2.4 , que possibilita o uso de replicação nativa e diversas melhorias para o ambiente Aggregator, além diversas melhorias no código para estabilidade, performance e segurança.

O Cyrus Imap opera somente com seu formato de armazenamento, não sendo possível utilizar os formatos Maildir, Mailbox ou qualquer outra configuração. Por padrão, o Cyrus Imap armazena as mensagens e meta-arquivos na mesma estrutura de diretório, o armazenamento de mensagens é constituído por diversos arquivos pequenos que não são acessados tão frequentemente, uma mensagem é acionada somente quando o usuário abre a mesma, os meta-arquivos são separados em arquivos por caixa postal (pasta): header, index, cache, expunge e squat, sendo os três primeiros para indexação e recuperação dos cabeçalhos das mensagens, o expunge para controle de remoção atrasada se essa opção estiver habilitada e o arquivo squat contém uma indexação específica para pesquisa de mensagens, com ganho de 20 a 30% em relação a indexação padrão para operações que envolvam pesquisa, sendo o maior dos meta-arquivos, se a mensagem não estiver referenciada neste arquivo será recuperada através da indexação normal, porém com desempenho inferior.

Sabendo que os meta-arquivos são acessados com mais frequência e ocupam um espaço relativamente pequeno, cerca de 10% para toda a estrutura de caixas postais do usuário (esse resultado foi obtido a partir de estudos com implementações reais até 1000 usuários), é uma boa estratégia configurar o Cyrus Imap para separar esses arquivos em meta-partições que utilizam discos mais rápidos para obter um melhor desempenho das operações de I/O no servidor IMAP.

A partir da versão 2.3 essa configuração é possível utilizando os parâmetros metadata no arquivo de parametrização do Cyrus Imap. Como conceito, cada partição pode ter somente uma meta-partição e a definição de quais arquivos serão separados é global, ou seja, é definido quais meta-arquivos ficarão separados em meta-partição e essa configuração é compartilhada para todas as partições.

Scripts para o Cyrus Imap: Aplicar permissão e remover caixas postais

Precisei executar um procedimento para remover cerca de 400 caixas postais no Cyrus Imap, como certamente executar essa tarefa manualmente não seria nada adequado criei um script em Perl para remover essas caixas postais em lote, porém algumas em algumas caixas postais o usuário administrador não possuía as devidas permissões, compartilho com vocês os dois scripts, para aplicar as permissões corretas e remover as caixas postais desejadas:

(Os scripts também estão disponbilizados em https://github.com/fsschmidt/cyrusimap)

Aplicar permissão:

#!/usr/bin/perl -w
#Autor: Fabio S. Schmidt <fabio_schmidt@hotmail.com>
#Revisao em: 14/03/2013
#Script para aplicar permissao em caixas postais do Cyrus Imap
use Cyrus::IMAP::Admin;
#
# PARAMETROS DE CONFIGURACAO
#
my $cyrus_server = $ARGV[2];
my $cyrus_user = “admin”;
my $matricula = $ARGV[1];
my $mechanism = “login”;
if (!$ARGV[1]) {
    die “Usage: $0 SENHA MAILBOX SERVIDOR\n”;
} else {
    $cyrus_pass = “$ARGV[0]”;
}
print “Aplicando permissao ALL para o usuario $cyrus_user na caixa : $matricula. \n”;
aplicapermissao($matricula);
sub aplicapermissao {
    my ($user, $subfolder) = @_;
    my $cyrus = Cyrus::IMAP::Admin->new($cyrus_server);
    $cyrus->authenticate($mechanism,’imap’,”,$cyrus_user,’0′,’10000′,$cyrus_pass);
    $cyrus->setaclmailbox(“user.$matricula”, ‘expresso-admin’, ‘all’);
    if ($cyrus->error) {
        print STDERR “Error: “, $matricula,” “, $cyrus->error, “\n”;
    } else {
        print “Permissao concedida para o usuario $matricula.\n”;
    }
}
Remover caixa postal:
#!/usr/bin/perl -w
#Autor: Fabio S. Schmidt <fabio_schmidt@hotmail.com>
#Script para remover caixas postais do Cyrus Imap
use Cyrus::IMAP::Admin;
#
# PARAMETROS DE CONFIGURACAO
#
my $cyrus_server = $ARGV[2];
my $cyrus_user = “admin”;
my $matricula = $ARGV[1];
my $mechanism = “login”;
if (!$ARGV[1]) {
    die “Usage: $0 SENHA MAILBOX SERVIDOR\n”;
} else {
    $cyrus_pass = “$ARGV[0]”;
}
print “Removendo usuario : $matricula. \n”;
removeusuario($matricula);
sub removeusuario {
    my ($user, $subfolder) = @_;
    my $cyrus = Cyrus::IMAP::Admin->new($cyrus_server);
    $cyrus->authenticate($mechanism,’imap’,”,$cyrus_user,’0′,’10000′,$cyrus_pass);
    $cyrus->deletemailbox(“user.$matricula”);
    if ($cyrus->error) {
        print STDERR “Error: “, $matricula,” “, $cyrus->error, “\n”;
    } else {
        print “Usuario $matricula foi removido com sucesso.\n”;
    }
}
Para executar os comandos em lote, basta criar um laço FOR conforme o exemplo abaixo:
#!/bin/bash
# EXCLUIR CAIXAS POSTAIS DO CYRUS IMAP
echo “Excluindo caixas postais do CYRUS IMAP…”
for i in `cat remover_caixas.txt`
do perl remover_caixas.pl SENHA $i SERVIDOR
done

Expressolivre: Atualizando para a versão 2.5 – Uncaught exception ‘Exception’ with message ‘DateTimeZone

Ao atualizar o Expresso para a versão 2.5, saindo da versão 2.4, era apresentada uma tela em branco ao logar, identifiquei nos log o seguinte erro:

PHP Fatal error:  Uncaught exception ‘Exception’ with message ‘DateTimeZone::__construct(): Unknown or bad timezone ()’ in /var/www/expresso/expressoMail1_2/inc/class.functions.inc.php:25\nStack trace:\n#0 /var/www/expresso/expressoMail1_2/inc/class.functions.inc.php(25): DateTimeZone->__construct(”)\n#1 /var/www/expresso/expressoMail1_2/inc/class.imap_functions.inc.php(212): Functions->CalculateDateOffset()\n#2 /var/www/expresso/expressoMail1_2/controller.php(66): imap_functions->get_range_msgs2(Array)\n#3 {main}\n  thrown in /var/www/expresso/expressoMail1_2/inc/class.functions.inc.php on line 25, referer: http://192.168.0.136/expressoMail1_2/index.php

A solução para este problema é entrar como administrador e definir novamente o timezone em preferências obrigatórias.

 

 

Expressolivre: Atualizando para a versão 2.5 – pear_error: message=”Connection refused”

Ao atualizar o Expresso, saindo da versão 2.4 para a versão 2.5, identifiquei o seguinte erro ao logar no ambiente:

[Sat Jan 12 14:46:45 2013] [error] [client 192.168.0.153] [pear_error: message=”Connection refused” code=111 mode=return level=notice prefix=”” info=””], referer: http://192.168.0.136/expressoMail1_2/index.php

O problema era o arquivo de configuração do sieve (Sieve.srv) em prototype/config, que não havia sido preservado durante a atualização, portanto, basta configurar novamente que o problema será solucionado.

Cyrus Aggregator: Serviço Sieve não conecta no Backend

Olá, essa dica pode ser útil para quem utiliza o Cyrus Aggregator e atualizou a versão, no caso onde tivemos o problema atualizamos da versão 2.4.12 para 2.4.14.

Verificamos que após a atualização, o serviço Sieve do Frontend não conseguia conectar ao servidor Backend, toda a configuração estava correta e o serviço estava rodando em ambos os servidores, mas o seguinte erro era apresentado nos logs do Frontend:

Jul 29 15:15:44 meufrontend cyrus/master[30298]: about to exec /usr/lib/cyrus/bin/timsieved
Jul 29 15:15:44 meufrontend cyrus/sieve[30298]: executed
Jul 29 15:15:54 meufrontend cyrus/sieve[30298]: accepted connection
Jul 29 15:15:54 meufrontend cyrus/sieve[30298]: connect(meubackend) failed: Connection refused
Jul 29 15:15:54 meufrontend cyrus/sieve[30298]: couldn’t authenticate to backend server
Jul 29 15:15:54 meufrontend cyrus/sieve[30298]: Lost connection to client — exiting
Jul 29 15:15:54 meufrontend cyrus/master[30260]: process 30298 exited, status 0

Como se sabe a porta do serviço Sieve foi definida para 4190/tcp recentemente (anteriormente utilizava a porta 2000/tcp), porém,  estávamos utilizando a porta antiga e ao atualizar para a versão 2.4.14 mesmo se o Sieve no Frontend estiver escutando nessa porta ele irá efetuar a conexão porta 4190 do Backend.

Portanto, é imprescindível atualizar a configuração do ambiente definindo o Sieve para escutar na sua porta oficial.

Separando os meta-arquivos do Cyrus Imap

Por padrão, o Cyrus Imap armazena as mensagens e meta-arquivos na mesma estrutura de diretório, o armazenamento de mensagens é constituído por diversos arquivos pequenos que não são acessados tão frequentemente, uma mensagem é acionada somente quando o usuário abre a mesma, os meta-arquivos são separados em arquivos por caixa postal (pasta): header, index, cache, expunge e squat, sendo os três primeiros para indexação e recuperação dos cabeçalhos das mensagens, o expunge para controle de remoção atrasada se essa opção estiver habilitada, o arquivo squat contém uma indexação específica para pesquisa de mensagens, com ganho de 20 a 30% em relação a indexação padrão para operações que envolvam pesquisa, sendo o maior dos meta-arquivos, se a mensagem não estiver referenciada neste arquivo será recuperada através da indexação normal, porém com desempenho inferior.

Sabendo que os meta-arquivos são acessados com mais frequência e ocupam um espaço relativamente pequeno, cerca de 10% para toda a estrutura de caixas postais do usuário (esse resultado foi obtido a partir e estudos com implementações reais até 1000 usuários), é uma boa estratégia configurar o Cyrus Imap para separar esses arquivos em meta-partições que utilizam discos mais rápidos para obter um melhor desempenho das operações de I/O no servidor IMAP.

A partir da versão 2.3 essa configuração é possível utilizando os parâmetros metadata do Cyrus Imap, como conceito, cada partição pode ter somente uma meta-partição e a definição de quais arquivos serão separados é global, ou seja, é definido quais meta-arquivos ficarão separados em meta-partição e essa configuração é compartilhada para todas as partições.

Vejamos o exemplo abaixo com as configurações no arquivo /etc/imapd.conf :

metapartition_files: header index cache expunge squat

metapartition-default: /var/spool/cyrus

metapartition-splitmeta: /var/spool/splitmeta/metadata

partition-default: /var/spool/cyrus/

partition-splitmeta: /var/spool/splitmeta/partition

Vemos que com o parâmetro metapartion_files estamos definindo que todos os 5 meta-arquivos devem ser armazenados na meta-partição, neste cenário já temos uma partição em funcionamento, a partição default que é a padrão do Cyrus Imap e precisamos separar os meta-arquivos das caixas postais já existentes.

Como a configuração de separação de meta-arquivos é global, precisamos informar que os meta-arquivos da partição default estão localizados no mesmo diretório da estrutura de mensagens, como pode ser visto nos parametros partition-default e metapartition-default, já para a nova partição, nomeada splitmeta os meta-arquivos serão armazenados em outro diretório, definido com a diretiva metapartition-splitmeta, onde “slipmeta” deve ser substituído com o nome de cada partição do servidor IMAP.

Após efetuar as modificações execute o comando abaixo para criar a estrutura necessária para a nova partição e meta-partição:

su -s /bin/bash – cyrus -c ‘/usr/lib/cyrus/bin/mkimap /etc/imapd.conf

Será necessário efetuar o reload do serviço do Cyrus Imap para utilizar as novas configurações:

/etc/init.d/cyrus-imapd restart

Para movimentar os usuários para a nova partição é necessário utilizar o comando rename na shell do Cyrus (cyradm) conforme abaixo, durante a movimentação para a nova partição os meta-arquivos serão separados na meta-partição:

cyradm> renamemailbox user/fabio user/fabio splitmeta

Com este comando estamos movimentando o usuário fabio com toda sua estrutura de caixas postais para a nova partição splimeta.