O que poderia fazer com que o Mailman descartasse mensagens após a aprovação do moderador?

Question

Eu rodei um sistema Mailman de tamanho médio que recentemente desenvolveu um problema onde todas as mensagens que passam pela moderação desaparecem em vez de serem entregues à lista de discussão. Isso está afetando cada uma de nossas listas de discussão.

A moderação falha quando realizada em um servidor da Web separado

O ambiente do Mailman é dividido em dois servidores, front-end e back-end. O servidor de backend manipula os qrunners do Postfix e do Mailman, enquanto o servidor front-end hospeda o Apache e os scripts CGI do Mailman para moderar as listas. Os dois servidores compartilham uma montagem NFS entre eles que inclui todos os dados do Mailman compartilhado.

Todo o fluxo de e-mail padrão está funcionando corretamente, mas quando um moderador de lista efetua login na interface da web e aprova uma mensagem, ela desaparece sem deixar rastros.

1. O postfix smtpd recebe a mensagem recebida por SMTP e, em seguida,
2. O postfix smtpd entrega a mensagem para /usr/lib/mailman/mail/mailman .
3. O Mailman marca as gravações no vette logfile (servidor de backend) em que a mensagem é mantida para aprovação.
4. O moderador de lista usa a interface da Web CGI para marcar a mensagem como aprovada.
5. O Mailman escreve uma entrada para vette logfile (no servidor front-end) dizendo que a mensagem em espera foi aprovada.

Neste ponto, o arquivo .pck relacionado à mensagem retida desaparece, mas nada é entregue e nenhuma outra entrada de log é criada.

A moderação é bem-sucedida com a interface da Web no servidor principal do Mailman

Embora normalmente não executemos a interface da web do Mailman no servidor de back-end (para reduzir a superfície de ataque), eu a executei para fins de teste. Quando usamos a interface da web do Mailman no servidor backend, a mensagem é entregue normalmente e vemos essas entradas de log.

1. smtp logfile atualizado com número de destinatários e tempo para conclusão
2. post logfile atualizado com nome da lista, ID da mensagem e "sucesso".

Plano de fundo

O problema foi iniciado após a migração do ambiente do Mailman para novos servidores. Não surgiu por conta própria, é provavelmente o resultado de algum erro de configuração que ainda não detectamos. Estamos usando:

• Scientific Linux 6.3 em ambos os servidores
• Python 2.6.6 nos dois servidores
• Mailman 2.1.12 instalado a partir de pacotes do sistema operacional em ambos os servidores
• selinux no modo permissivo no servidor de back-end
• selinux no modo Imposição no servidor frontend (web), mas nenhuma entrada de log com type=AVC está sendo gravada. Além disso, usar setenforce 0 não resolve o problema.

Encontrei uma postagem relacionada na lista de usuários do Mailman , mas não solução foi fornecida.

    

Answer 1

Ao usar mais de um servidor para o Mailman, todos os servidores precisam ter acesso aos diretórios de filas no armazenamento compartilhado. É isso.

Entendendo para onde as mensagens moderadas são

1. Se uma mensagem for retida para moderação, ela será movida para $ DATA_DIR e o ID da mensagem será anexado a $ LIST_DATA_DIR / listname / pending.pck.
2. A interface da web do Mailman procura no pending.pck para localizar mensagens mantidas para moderação. Quando um moderador aprova a mensagem retida, ela é movida para a pasta $ INQUEUE_DIR.

Quais dados precisam ser compartilhados?

Isso é o que eu recomendo se você tiver um servidor separado que manipule a interface web do Mailman.

DEVE estar em armazenamento compartilhado

• queue_dir , inqueue_dir , outqueue_dir , cmdqueue_dir , bouncequeue_dir , newsqueue_dir , archqueue_dir , shuntqueue_dir , virginqueue_dir , badqueue_dir , retryqueue_dir , maildir_dir Seus arquivos de filas precisam estar acessíveis por qualquer servidor que execute tarefas do Mailman, incluindo o servidor da Web frontend.

• DATA_DIR , LIST_DATA_DIR Além das filas de e-mail, você também precisa compartilhar todos os arquivos de configuração de lista e arquivos de mensagens retidos.

• PUBLIC_ARCHIVE_FILE_DIR , PRIVATE_ARCHIVE_FILE_DIR Se você estiver usando arquivos de lista, também precisará compartilhar os diretórios de arquivo.

DEVE estar no armazenamento compartilhado

• LOCK_DIR , PID_DIR , PIDFILE Não tenho certeza, mas parece que os bloqueios e pidfiles devem estar localizados no armazenamento compartilhado para que, caso algo ruim aconteça com o servidor qrunner, será evidente que os processos terminaram anormalmente.

• SITE_PW_FILE , LISTCREATOR_PW_FILE Você provavelmente deseja que seus arquivos de senha estejam no armazenamento compartilhado para que você possa ter certeza de que a senha da sua lista mestra funciona, independentemente do servidor em que estiver.

• CONFIG_DIR Se você estiver usando MTA=Postfix , o Mailman criará automaticamente o arquivo de aliases em CONFIG_DIR. Como qualquer máquina com o Mailman pode ser usada para criar ou excluir listas, cada máquina também deve poder atualizar um arquivo aliases compartilhado corretamente. (Caveat Emptor: Às vezes você quer configurar o Mailman de maneira um pouco diferente em cada máquina, o que pode ser difícil com um CONFIG_DIR compartilhado).

PODE estar no armazenamento compartilhado

• LOG_DIR Dependendo de suas preferências, você pode manter esses diretórios locais ou colocá-los no armazenamento compartilhado. Eu gosto de ter todos os meus logs em um local central que está sendo submetido a backup, para que eu ainda tenha logs antigos disponíveis após a migração dos processos para um novo servidor.

• TEMPLATE_DIR Se você personalizou seus modelos do Mailman (por exemplo, mensagens devolvidas), provavelmente desejará tê-los em armazenamento compartilhado também.

• SPAM_DIR Eu não sei para que SPAM_DIR é realmente usado, mas é recomendado que todos os arquivos variáveis estejam em armazenamento compartilhado, então estou incluindo isso aqui.

Somente armazenamento local

• WRAPPER_DIR , BIN_DIR , SCRIPTS_DIR , MESSAGES_DIR É uma boa idéia manter binários e scripts locais, para que você possa aproveitar os pacotes fornecidos pelo sistema operacional para atualizações sem se preocupar em manter os binários compartilhados em sincronizar. O Mailman parece ser muito específico sobre ter exatamente a mesma versão em execução em qualquer servidor envolvido com o armazenamento compartilhado.

(Editado em 2013-09-04) A seguinte orientação foi fornecida por Mark Sapiro na lista de usuários do Mailman-Users.

My advice would be for standard GNU Mailman to share all the mutable data which is everything in var_prefix which is all of the directories archives/, data/, lists/, locks/, logs/, qfiles/ and spam/, however you have a Scientific Linux (Red Hat derivative) package, so see the FAQ at http://wiki.list.org/x/KYCB for how these map to your install.

There is a FAQ at http://wiki.list.org/x/wgB0 that addresses this somewhat. It might need some additions. Do see all the links.

(Editado em 2013-09-04) Atualmente, o diretório de configuração deve ser compartilhado, não local.

    

Answer 2

Mark Sapiro postou no Mailman-users 03-Dec-2013:

http://www.mail-archive.com/[email protected]/msg63365.html

"Mailman 2.1.12 is not compatible with Python 2.6+. This was fixed in 2.1.13."

Este problema específico foi corrigido por este patch:

(Eu não estou incluindo o patch aqui, pois a formatação seria corrompida.)