web-dev-qa-db-ja.com

モデレーターの承認後にMailmanがメッセージをドロップする原因は何ですか？

最近、モデレートを通過したメッセージがメーリングリストに配信されずに消えてしまうという問題が発生した中規模のMailmanシステムを実行しています。これは、すべてのメーリングリストに影響を及ぼしています。

別のWebサーバーで実行するとモデレートが失敗します

Mailman環境は、フロントエンドとバックエンドの2つのサーバーに分割されています。バックエンドサーバーはPostfixとMailmanqrunnersを処理し、フロントエンドサーバーはリストをモデレートするためのApacheとMailmanCGIスクリプトをホストします。 2つのサーバーは、すべての共有Mailmanデータを含むNFSマウントをサーバー間で共有します。

通常のメールフローはすべて正しく機能していますが、リストモデレーターがWebフロントエンドにログインしてメッセージを承認すると、トレースなしでメッセージが消えます。

  1. Postfix smtpdはSMTP経由で着信メッセージを受信し、その後
  2. Postfixsmtpdはメッセージを/usr/lib/mailman/mail/mailmanに配信します。
  3. Mailmanは、メッセージが承認のために保持されていることをvetteログファイル（バックエンドサーバー）に書き込みます。
  4. リストモデレーターは、CGI Webインターフェイスを使用して、メッセージを承認済みとしてマークします。
  5. Mailmanは、保留中のメッセージが承認されたことを示すエントリをvetteログファイル（フロントエンドサーバー上）に書き込みます。

この時点で、保留されたメッセージに関連する.pckファイルは消えますが、何も配信されず、それ以上のログエントリは作成されません。

モデレーションはメインMailmanサーバーのWebインターフェイスで成功します

通常、Mailman Webインターフェイスをバックエンドサーバーで実行することはありませんが（攻撃対象領域を減らすため）、テスト目的で実行しました。バックエンドサーバーでMailmanWebインターフェイスを使用すると、メッセージは正常に配信され、これらのログエントリが表示されます。

  1. smtpログファイルが受信者の数と完了までの時間で更新されました
  2. postログファイルがリスト名、メッセージID、および「成功」で更新されました。

背景

Mailman環境を新しいサーバーに移行した後、問題が発生しました。それはそれ自体では発生しませんでした。おそらく、まだ検出されていない構成エラーの結果である可能性があります。使用しているもの：

  • 両方のサーバー上のScientificLinux 6.3
  • 両方のサーバーでPython2.6.6
  • 両方のサーバーのOSパッケージからインストールされたMailman2.1.12
  • バックエンドサーバーでPermissiveモードのselinux
  • フロントエンド（Web）サーバーで強制モードのselinuxですが、type=AVCのログエントリは記録されていません。さらに、setenforce 0を使用しても問題は解決しません。

1つ見つかりました Mailmanユーザーリストの関連投稿 ですが、解決策は提供されませんでした。

postfixmailmanscientific-linux
1
Nic

Mailmanに複数のサーバーを使用する場合、すべてのサーバーが共有ストレージのキューディレクトリにアクセスできる必要があります。それでおしまい。

モデレートされたメッセージの行き先を理解する

  1. メッセージがモデレートのために保持されている場合、そのメッセージは$ DATA_DIRに移動され、メッセージIDが$ LIST_DATA_DIR/listname /pending.pckに追加されます。
  2. Mailman Webインターフェイスはpending.pckを調べて、モデレートのために保持されているメッセージを見つけます。モデレーターが保留中のメッセージを承認すると、メッセージは$ INQUEUE_DIRフォルダーに移動されます。

どのデータを共有する必要がありますか？

これは、MailmanWebフロントエンドを処理する別のサーバーがある場合に推奨するものです。

共有ストレージ上にある必要があります

  • queue_dir、inqueue_dir、outqueue_dir、cmdqueue_dir、bouncequeue_dir、newsqueue_dir、archqueue_dir、shuntqueue_dir、virginqueue_dir、badqueue_dir、retryqueue_dir、maildir_dirキューファイルは、フロントエンドWebサーバーを含むMailmanタスクを実行するすべてのサーバーからアクセスできる必要があります。

  • DATA_DIR、LIST_DATA_DIRメールキューに加えて、すべてのリスト構成ファイルと保持されているメッセージファイルも共有する必要があります。

  • PUBLIC_ARCHIVE_FILE_DIR、PRIVATE_ARCHIVE_FILE_DIRリストアーカイブを使用している場合は、アーカイブディレクトリも共有する必要があります。

共有ストレージ上にある必要があります

  • LOCK_DIR、PID_DIR、PIDFILE完全にはわかりませんが、qrunnerサーバーに問題が発生した場合に、ロックとpidfileを共有ストレージに配置する必要があるようです。プロセスが異常終了したことは明らかです。

  • SITE_PW_FILE、LISTCREATOR_PW_FILEパスワードファイルを共有ストレージに配置して、どのサーバーを使用していてもマスターリストのパスワードが確実に機能するようにすることをお勧めします。

  • CONFIG_DIRMTA=Postfixを使用している場合、MailmanはCONFIG_DIRにエイリアスファイルを自動的に作成します。 Mailmanを搭載した任意のマシンを使用してリストを作成または削除できるため、各マシンは共有エイリアスファイルを正しく更新できる必要があります。 （警告エンプター：各マシンでMailmanをわずかに異なる方法で構成したい場合がありますが、これは共有CONFIG_DIRでは難しい場合があります。）

共有ストレージにある可能性があります

  • LOG_DIR好みに応じて、これらのディレクトリをローカルに保持するか、共有ストレージに配置することができます。プロセスを新しいサーバーに移行した後も古いログを利用できるように、すべてのログをバックアップされている1つの中央の場所に置くのが好きです。

  • TEMPLATE_DIR Mailmanテンプレートをカスタマイズした場合（バウンスメッセージなど）、共有ストレージにもテンプレートを配置することをお勧めします。

  • SPAM_DIR SPAM_DIRが実際に何に使用されているかわかりませんが、すべての変数ファイルを共有ストレージに置くことをお勧めします。そのため、ここに含めます。

ローカルストレージのみ

  • WRAPPER_DIR、BIN_DIR、SCRIPTS_DIR、MESSAGES_DIRバイナリとスクリプトをローカルに保持して、オペレーティングシステムが提供するパッケージをアップグレードに利用できるようにすることをお勧めします。共有バイナリの同期を維持することを心配する必要はありません。 Mailmanは、共有ストレージに関係するすべてのサーバーでまったく同じバージョンを実行することに非常にこだわっているようです。

（2013-09-04に編集）次のガイダンスは、Mailman-UserslistservのMarkSapiroによって提供されました。

私のアドバイスは、標準のGNU Mailmanが、すべてのディレクトリarchives /、data /、lists /、locks /、logs /、qfilesであるvar_prefix内のすべてであるすべての可変データを共有することです。 /およびspam /、ただし、Scientific Linux（Red Hat派生）パッケージがあるため、FAQ at http://wiki.list.org/x/KYCB は、これらがインストールにどのようにマップされるかを示します。

FAQ at http://wiki.list.org/x/wgB0 には、これにいくらか対処するものがあります。いくつかの追加が必要になる場合があります。すべてのリンクを参照してください。

（2013-09-04に編集）実際には、構成ディレクトリはローカルではなく共有する必要があります。

1
Nic

Mark SapiroがMailman-usersに投稿しました2013年12月3日：

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

「Mailman2.1.12はPython 2.6+と互換性がありません。これは2.1.13で修正されました。」

この特定の問題は、このパッチによって修正されました。

（フォーマットが破損するため、ここにはパッチを含めていません。）

0
Barry S. Finkel