(ヽ´ω`) < 助けてほしいマン

わからないことを助けてほしいマンが書くブログ

(ヽ'ω`) < DigitailOceanのネットワーク周りのお話

(ヽ'ω`) < いろいろと

DigitalOceanのネットワーク周りの情報やTIPSをまとめてみた。

(ヽ'ω`) < グローバルIPを変更したいんだけど

IPを変えたい時はDropletを削除・再作成するといいよ、というポストを見つけた。モデレータが回答しているので、コントロールパネルでの機能としては用意されていないっぽい。

How do I change the IP address of the server? | DigitalOcean

(ヽ'ω`) < 帯域制御とかしてるの?

普通の使い方ならしていないとのこと。逆に言うと、明らかにヤバイだろコレっていう状況だとされるのかな?

Do you limit bandwidth? | DigitalOcean

benMOD November 15, 2012 We do not throttle bandwidth or traffic after a certain amount. From time to time you may speed different bandwidth speeds depending on internet conditions, load on your droplet, or the system as a whole.

(ヽ'ω`) < 帯域の上限は? 帯域保証はあるの?

Dropletが1Gigabit NICなので1Gbpsが上限。とはいえそこまでいけるわけ無いよねと。

Do you limit bandwidth? | DigitalOcean

creating.www October 15, 2013 Do you guarantee any speed, and what is upper limit for one Droplet? kamaln7MOD October 18, 2013 @creating.www: All droplets are on 1Gbps ports.

帯域保証については言及なしなので、機能として用意されてないっぽい。

(ヽ'ω`) < 1Tの転送量を超えたらどうなるの?

Outboundトラヒックに対しては、$0.02/GBの転送量が加算される。

Bandwidth transfer | DigitalOcean

Is Digital Ocean a metered server? What if I exceed the Network Bandwidth limits? | DigitalOcean

(ヽ'ω`) < 転送量使い切ったらアクション起こすとかの機能は無いの?

下記のポストを見る限り、用意されていないっぽい。(モデレータが記事の案内をしている。機能として用意されているならそれを掲載するはず)

Bandwidth limit | DigitalOcean

このポストに簡単なスクリプトが投稿されている。

Can I make my server automatically suspend if it hits the bandwidth limit? | DigitalOcean

[Bash] Florian Strankowski - Pastebin.com

vnstatコマンドで当月の通信量を確認して、999Gを超えていたらshutdownコマンドを発行するという、単純明快なスクリプト。コレをcronで1日1回実行と書かれているが、バーストトラヒックが予測不可能な場合は、もっと細かく時間を区切ったほうがいいだろう。

実際に使うときにはshutdownコマンドの代わりにサービスを停止したり、トラヒックを抑える処理を行うほうが良いと思う。ロードバランサ配下であれば、グループメンバーから外させるとか。

ネットワークに限った話しでなく、支払い全体ということであれば、メールの通知サービスが用意されている。

Never Get Surprised By Your Monthly Invoice Again! | DigitalOcean

任意の金額を超えたらメールで警告を送ってくれる。ただし、警告を送るだけでその後のアクションはユーザ自身に任される。

(ヽ'ω`) < ネットワークの物理的な構成は?

このトピックにDigitalOceanの中の偉い人(zagiってユーザ名)が登場して説明しているところによると、

Very bad performance downloading from Digital Ocean VPS (HTTP) - Page 2 - LowEndTalk

2013年の話だが、ニューヨークリージョンの物理サーバは1Gbpsでコアネットワークに接続されていて、そこからインターネットへは冗長化された10Gbps回線で接続されているとのこと。上位ISPはCogentLevel3

公式のHPにも1Gbps、10Gbps接続の記述があるので、そこは変わってなさそう。

Frequently Asked Questions | DigitalOcean

All DigitalOcean physical nodes are connected via gigabit ethernet to switches, which are uplinked to our aggregators and core routers. All core routers are uplinked via 10-gigE uplinks to providers.

(ヽ'ω`) < 速度が安定しない

先ほど書いたトピックにも報告があるが、同一リージョンでも速度差が発生することがあるっぽい。理由については色々推測されているが、とりあえずDropletを削除・作成して新しいIPを取得することで、改善したケースもあるとのこと。(元のIPが上位ISPで帯域制御の対象になっていたのでは? と推測されている)

その他の対処方法についても、先のトピックに詳しい。…が最安$0.007/hourのサービスに多くを求めるのも酷というもの(ヽ'ω`)

高額プランもあるじゃないか、と言われるとそれはそうなんですが、ある程度の額を出すのであればDigitalOceanである必要性が…と言うより帯域保証のあるVPSサービスってあるのかな?

(ヽ'ω`) < 使っていて他に気づいたことがあったら

また第2段ってことで書いていきます。

もしも気が向いたら下のリンクのコレをアレしてください、Vultrとの比較や負荷実験とかして記事にします(ヽ'ω`)

SSD Cloud Server, VPS Server, Simple Cloud Hosting | DigitalOcean

(ヽ'ω`) < DigitalOceanのVirtIOオプションはOnにするのが良いのか?

(ヽ'ω`) < そもそもVirtIOってなんなのよ?

下記のページによると、KVMやQEMUで採用されている、I/O周りのドライバの準仮想化ソフトらしい。

libvirt: Wiki: Virtio

VirtIOを使用しない環境(完全仮想化)では、ハイパーバイザーによってI/O周りのドライバが完全にエミュレーションされる。ハイパーバイザーが実際のハードウェアの挙動を再現する形になるので、それなりに処理コストが大きくなる。

VirtIOを使用すると、VM上ではNICやディスクコントローラが仮想化されたものであると認識された上で、専用のドライバを経由してハイパーバイザーで処理される。そのドライバはハイパーバイザーの動作に最適化されたものなので、完全仮想化環境に比べて、パフォーマンスが向上する。

ここでの完全・準仮想化について、あくまでI/O周りのドライバに限定した話で、OS自体の仮想化方式については関係ない。というより、完全仮想化されたOSで、I/Oドライバのみ準仮想化させパフォーマンスを向上させる、というお話。

(ヽ'ω`) < 基本的にはOnでOK

DigitalOceanの中の人も、基本的にはパフォーマンスが上がるからOnでいいよー、とのこと。

What is VirtIO? Do I need this option? | DigitalOcean

RedhatもKVMでVirtIOを有効化することでパフォーマンスが上がると解説している。(Windowsについてだが)

第10章 KVM 準仮想化 (virtio) ドライバー

KVM virtio ドライバーを使用すると、以下の Microsoft Windows バージョンがベアメタルベースのシステムと同様の動作をすることが予想されます。

ただ、実際のDiskベンチマークではスコアが落ちているケースもある。

VirtIO Testing Disk DigitalOcean Cloud Benchmarks - OpenBenchmarking.org

コンパイルオプションで-j $NUM_CPU_JOBSを渡しているので、コンパイル時のスレッド数はコア数+1になると考えると、マルチスレッド系の処理が少し弱くなるっぽい。

この現象がDigitalOcean特有のものなのか、KVM全般的なものなのかは不明だが、ディスクアクセスが多いアプリケーションを使用する場合は、念の為にテストを行ったほうが良いかと思われる。今KVM環境が手元にないので検証はいずれ(ヽ'ω`)

(ヽ'ω`) < VirtIOを有効化することによるデメリットは?

マルチスレッドプロセスのディスク処理が遅くなる可能性については上で述べた。

他には完全仮想化ではなくなるので、アプリケーションによっては動作の一部に影響が出るかもしれない。とはいえ、ドライバレベルでゴリゴリ書いてあるようなアプリケーションなんてそうそう無いだろうし、そんなものをVPSで動かすシチュエーションもあまり想像できないので、一般的な環境では"無い"。

…と言ってしまうと問題ありかもしれないのだが、DigitalOceanの中の人は言っちゃってるんですよね。

csalinas July 18, 2013 I have a question, if i am using VirtIO, ¿this has an impact on my billing? Thanks. kamaln7MOD July 18, 2013 csalinas, enabling VirtIO does not incur any extra charges. We recommend enabling it :]

elgs1980 August 14, 2013 So is there any penalty or side effect using VirtIO? I mean is there any reason to not select the VirtIO on droplet creation? Thanks. kamaln7MOD August 15, 2013 VirtIO doesn't have any side effects. You should enable it unless you have a valid reason not to. :]

contacto November 7, 2013 I would like to know that too, when should i NOT enable VirtIO? kamaln7MOD November 10, 2013 VirtIO doesn't have any side effects usually. You should enable it unless you have a valid reason not to (which is usually rare). :]

Lynx April 20, 2014 Can you provide any specific examples where VirtIO should be disabled? kamaln7MOD April 21, 2014 You might need to disable VirtIO if you're using a program that's not compatible with it. Usually you're fine with VirtIO enabled.

(ヽ'ω`) < VirtIO機能提供以前のDropletでVirtIOを有効にしたい

サポートチケットを発行せよとのこと

sabbir456 August 18, 2013 How to enable VirtIO in old droplets ?

kamaln7MOD August 21, 2013 @Sabbir: Please open up a support ticket so we can enable VirtIO on your old droplets.

(ヽ'ω`) < VirtIOが正しく有効化されているか確認したい

dfコマンドの出力で/dev/vdaがあればOKっぽい。

marana October 26, 2013 Is there any way to know if i have VirtIO activated in my droplet? Thanks!

kamaln7MOD October 29, 2013 @marana: Run the following command to check if VirtIO is enabled.
[[ df | grep '/dev/vda' | wc -l -ne 0 ]] && echo 'enabled'

さくらのVPSでも/dev/vdaあったから、KVM使ってるところはほとんど有効化推奨って感じなんですかね。

(ヽ'ω`) < FSCTでWindowsファイル共有サービスのパフォーマンスを測定する2 - ネットワーク-

(ヽ´ω`) < ネットワークについて

前回の記事でFSCTでは3つの役割のPCが必要という事を解説した。

(ヽ'ω`) < FSCTでWindowsファイル共有サービスのパフォーマンスを測定する - 概要- - (ヽ´ω`) < *****

複数台のPCが存在し、テスト対象はWindowsファイル共有サービスなので、当然3つの役割を担当するPCはネットワークに接続されている必要がある。

ここでテストの敷居が多少高くなり、サーバとクライアントのPCにはデータ通信(実際の負荷)用のネットワークと、テストをコントロールするためのネットワーク、2つのNICが必要となる。

物理・仮想を問わず、通常のファイルサーバやミドル~ハイエンドのNASであれば、NICが2つ以上最初からついていたり、増設は簡単だと思うが、ローエンドのNASの場合はどうするか。恐らくだが、そもそもFSCTではそういった製品のテストを想定していないと思われる。

(ヽ'ω`) < テスト用ネットワークの構築

添付の説明文書では、テスト用ネットワークとして4つの形態を例に上げている。

各形態の概要図については、添付の説明文章内の"FSCT Architecture"の"Networking"を参照していただきたい。

Basic

基本的なスタイル。

サーバと各クライアントはNICを2つ持ち、1つを負荷生成用に使用し、もう一方をテストのコントロールに割り当てる。当然、テストではない環境ではクライアントのNICは1つだけとなる。

おそらく、通常のオフィスなどで最も一般的な形態と思われる。

Segmented

2台以上のクライアントを別々のLANセグメントに配置することで、負荷を分散する。サーバはLANセグメントの数だけNICが必要となる。

1つ重要なことが書いてあって、1Gbpsの回線あたり、4,000ユーザをまかなうことができるとある。

これはhpのPDF文章でも、"FSCTの経験則"として記載されている。

http://h50146.www5.hp.com/products/storage/whitepaper/pdfs/4AA3-8726jpn.pdf

4000以上のユーザがいる場合は、LANセグメントとNICを分割することで、効果的に

使用状況にも大きく左右されると思うが、参考として覚えておくと良い。

Shared

サーバと各クライアントは3つ以上のNICをを持ち、2つ以上のNICを負荷生成用に使用する。

実運用時、各クライアントは別LANセグメントのIPを2つ持つ事になるのだが、サービスレイヤでロードバランシングされるのかな?

という事で軽く検索してみると、Windows Server 2012とSMB3.0の組み合わせで、SMBマルチチャネルという機能が追加されたらしい。

The basics of SMB Multichannel, a feature of Windows Server 2012 and SMB 3.0 - Jose Barreto's Blog - Site Home - TechNet Blogs

Segmentedの場合、クライアント通信を行うのはそのLANセグメントに属する1つのNICだけだが、Sharedの形態でSMBマルチチャネルが有効な場合は複数のNICが使われるっぽい。

Windows Server 2012 R2 のネットワークの注意事項 - SMB Multichannel (1) - 仮想化でプリセールスしてるSEの一日

NIC Team は Ethernet (L2) ヘッダーの情報で送信パスを決定しますが*1、Multichannel は L7 ベースでコントロールするため、この時点では送信元や宛先に関するヘッダー情報は持っていません。このため、宛先などは一切考えず、到達できるすべてのパスを用いてラウンドロビン的に送ろうとします。

上記ページの図を見ても、複数のLANセグメント(別のサブネット)の通信をまとめてファイル転送が行われている。

逆に同一セグメントの場合はどうなるの? といった疑問だが、Windowsファイル共有に限った話ではなく、Windowsネットワーク全般の話で、同一セグメントでの複数IP付与は想定してないらしい。

How multiple adapters on the same network are expected to behave

複数NICを使用しての通信ということになるとNICチーミングと同じでは? と思われるかもしれないが、NICチーミングはあくまでもL2/3でのロードバランシングなので、単一の相手との通信ではNICのワイヤスピード以上が出ることはない。

また、あるパスでエラーが発生しても、その他のパスを使用して転送が行われるため、サービスの可用性も向上する。

Network fault tolerance. When clients simultaneously use multiple network connections, the clients can continue without interruption despite the loss of a network connection.

SMBマルチチャネルの設定はデフォルトでOnになっていて、複数パスが存在する場合、自動的に構成が行われるので、特に管理者は難しい設定を行う必要はない。

必要がないだけで、経路の制御などを行いたい場合は、ちゃんとそのための方法が用意されている。

Windows Server 2012 R2 のネットワークの注意事項 - SMB Multichannel (3) - 仮想化でプリセールスしてるSEの一日

NIC Teaming

名前の通り、サーバ側のNICをチーミング構成にすることで負荷分散を行う。実際に負荷が分散されるかは、チーミングモードの設定と、運用環境に依る。

チーミングモードについては、以下のページに詳しい。

運用:Windows Server 2012 R2のNICチーミング機能(LBFO)をマスターする (2/3) - @IT

Windows Server 2012 R2であれば、動的モードにしておけば問題ないだろう。

(ヽ'ω`) < どのネットワーク形態がいいの?

FSCTの経験則から、1GbpsのNICが搭載されていれば、4000ユーザまではBasicでも問題が無いとのこと。

Sharedの形態でSMBマルチチャネルが有効であれば、パフォーマンスと可用性が向上するので理想的。

ただ、実際には複数のLANセグメントを接続できない場合が多いだろうから(サービスではなく、ネットワーク設計の問題)、NIC Teamingが現実的だろうか。

(ヽ'ω`) < 画像引用しろよ、文章だけだとわかりにくいだろ

そもそもこの記事自体も説明文章の内容そのまんまなので、ここに画像までやったら引用の範囲を超えますので(ヽ'ω`)

(ヽ'ω`) < あれ? 実際にテスト実行するんじゃないのか?

SMBマルチチャネルの話が少し長くなったので、

(ヽ'ω`) < 次で

(ヽ'ω`) < FSCTでWindowsファイル共有サービスのパフォーマンスを測定する - 概要-

(ヽ´ω`) < Windowsファイル共有のパフォーマンスを測定する

Windowsのファイル共有機能を提供する製品はいっぱいあるのだが、どの製品のどのランクのモノを選んでいいのかがわからない。パフォーマンスチューニングをしたのだが、どの程度の効果があるのかを測定したい。

そんな時には負荷テストを実施すると思うが、そんな時の助けになるのがこのツール。

(ヽ´ω`) < File Server Capacity Tool(FSCT)

Microsoftから提供されているWindowsのファイル共有機能に特化した計測ツール。

Download File Server Capacity Tool v1.2- (64 bit) from Official Microsoft Download Center

有名なのかそうじゃないのかよくわからなくて、Googleで検索しても日本語ページはほとんど引っかからず、hpのファイルサーバパフォーマンスに関するPDF文章で1件。

http://h50146.www5.hp.com/products/storage/whitepaper/pdfs/4AA3-8726jpn.pdf

英語のページを含めてもそんなに情報ソースが多く無い。使い方のソースになりそうなのが、Technetのページと本体に添付されている説明文章のみ。

How to use the File Server Capacity Tool (FSCT) on Server 2012 R2 - Ask Premier Field Engineering (PFE) Platforms - Site Home - TechNet Blogs

あとはStorage Developer Conference 2008でMicrosoftの社員が作成したと思われる、プレゼン資料ぐらいか。

http://www.snia.org/sites/default/files2/sdc_archives/2008_presentations/monday/JoseBarreto_CIFS_SMB_FSCT.pdf

資料が少ないから調べるの大変そうだなー、と思っていたら本体添付の説明文章がかなり細かく書いてあるので、意外に楽だった。

(ヽ´ω`) < FSCTの特徴

ディスクパフォーマンスを測定するだけなら他にもいくつもツールが有るが、FSCTは以下の特徴を持っている。 (本体添付の説明文章、"Introducing FSCT"より)

実際のWindowsとWin32アプリケーションの挙動をシミュレートする

他のDiskストレスツールと比べて最も特徴的な点。

一般的なDiskストレスツールはひたすらファイルの作成や削除、コピーなどを繰り返し続ける。(複数の物理クライアントからの操作や、ファイルサイズの大小変更等の機能もあるが)

当然のことながら、このタイプのテストで発生する負荷は、実際にユーザが操作する際の挙動とはかけ離れている。

それに対してFSCTでは、Windowsでのファイル操作(コマンドライン・エクスプローラーからのファイル操作、Wordでのファイルオープン・セーブ・クローズ等)をシミュレートすることで、実際にユーザがWindowsを操作している時の挙動と同じような負荷をかける事ができる。

Workloadsと呼ばれるテストシナリオ機能

前項で実際のユーザの操作をシミュレートすると説明したが、実際にどのような操作が行われるかはWorkloadsと呼ばれるシナリオに沿って定義される。

どのようなサイズのファイルを使って、どういう操作を行うのか。その操作の時間あたりの頻度は。それらを記述したXMLとテキストファイルの集合がWorkloadsの本体となる。

FSCTでは"HomeFolders"という名前のWorkloadsが提供されている。これはユーザのホームディレクトリがファイルサーバに存在する場合を想定したシナリオとなっている。

FSCTで提供されているWorkloadsは"HomeFolders"だけだが、例えば

  • 大きいファイルしか読み書きしない
  • ファイルの読み込みだけで書き込みをしない
  • ファイルのコピーしか行わない

というそれぞれのケースに合わせてWorkloadsを作成することで、自分の環境にマッチした系祖国を行うことができる。

1つの物理クライアントで複数のセッションを生成可能

ストレステストなので、リクエストを発行するクライアントPCはそれなりの台数が必要だが、10000台のクライアントを想定した環境で、実際に10000台のテスト用PCを用意することは

(ヽ´ω`) < 無理

FSCTでは1台のクライアントPC内に複数のユーザを作成し、それぞれのユーザからのリクエストをシミュレートすることができる。ファイルサーバの同時接続数の限界を測定するのに役に立つ。

詳細なレポート機能

FSCTでのテスト結果はテキストファイルで出力される。このファイルの中には

  • スループット
  • レイテンシ
  • ネットワーク帯域
  • OSのパフォーマンスカウンター(サーバ/クライアント両方)

等が含まれる。

更にEvent Tracing for Windows(ETW)のトレースデータとやらも出力可能とのこと。

ストレステストの場合、サーバ側の限界かと思っていたら、リクエストを送信するクライアントの限界だったというオチがあるので両方のデータが取得できるのは非常に便利。

テスト結果の出力例を引用すると

*** Results
Users  Overload  Throughput  Errors  Errors [%]  Duration [ms]
8000         0%         733       0          0%         181194
9000         0%         824       0          0%         181334
10000        0%         917       0          0%         180945
11000       19%         848      20          0%         203830
12000      200%         383      32          0%         216528

こんな感じで、上記の出力から察するにこのサーバの限界ユーザ数は10000~11000ぐらいと推測することができる。(Workloadsが適切に構成されていると仮定すると)

一度に複数パターンのユーザ数テストを行う事ができる

テストを行う際に、

  • 最小ユーザ数
  • 最大ユーザ数
  • ユーザ増数

を指定することができる。

先ほどのテスト結果の例を再掲すると

*** Results
Users  Overload  Throughput  Errors  Errors [%]  Duration [ms]
8000         0%         733       0          0%         181194
9000         0%         824       0          0%         181334
10000        0%         917       0          0%         180945
11000       19%         848      20          0%         203830
12000      200%         383      32          0%         216528

とあるが、これは

  • 最小ユーザ数 = 8000
  • 最大ユーザ数 = 12000
  • ユーザ増数 = 1000

でテストが行われたことがわかる。

ここで10000~11000あたりが限界とわかったので、次は

  • 最小ユーザ数 = 10000
  • 最大ユーザ数 = 11000
  • ユーザ増数 = 100

として、条件を徐々に細かくしていくことで限界点を詳細に探ることができる。

(ヽ´ω`) < Warning!!

添付の説明文章にも特徴のすぐ後に書いてあるのだが、FSCTで行われるテストではボリュームのフォーマットが行われる。しかも事前確認なし。データが消える可能性がある。

If you use FSCT in a production environment, you risk unintentional data loss.

可能性というかフォーマットされたら確実に消えると思うのだが、兎に角、FSCTによるテストは導入時か移行時のみとし、現用の環境では行わないこと。

また、FSCTではADドメイン(あるいはWorkgroup)のパスワードを、クリアテキストでネットワーク上に流すため、可能な限り専用のネットワーク内で行うことをオススメする。

(ヽ´ω`) < 3つの登場人物

FSCTでは最低限3つの役割を演じるPCが必要となる。

Controller(コントローラ)

テスト全体を制御し、得られたデータを蓄積していくためのPC。

FSCTが動作するWindows OSが動作していなければならない。

Server(サーバ)

テスト対象となるWindowsファイル共有サービスが動作しているサーバー。

動作させるWorkloadsの内容によるが、FSCTに標準で用意されている"HomeDirectory"を使用するためには、ユーザ一人辺り100MBytesの要領が必要となる。

Windowsファイル共有サービスが動いていれば(CIFS/SMB)、非Windowsサーバ(殆どの場合はLinux+Sambaだと思うが)でもOK。その場合は、ディレクトリの作成やパーミッションの設定等の細かい設定を、手動で行っておく必要がある。

Client(s)(クライアント)

実際にサーバにリクエストを送るクライアントPC。

先に説明したとおり、1台のクライアントで複数のユーザリクエストをシミュレートが可能なのだが、サーバより先にクライアント側が悲鳴を上げないように、適切な台数を用意する必要がある。

それじゃあどうやってその適切な台数を導出するのか、という話だが、テストを行った際にクライアント側のパフォーマンスカウンターも取得できるというのは説明したとおり。この値を見て、クライアント側の負荷を計測する。もしもキツイようなら、クライアントの台数を増やす。

一つの目安として、添付の説明文章ではサーバのCPUコアの4倍の数だけ、クライアントのCPUコアを用意するべきと書かれている。

例えばサーバが4コア1CPUならば、クライアントは4コア1CPU4台、2コア1CPU8台、1コア1CPU16台と言った感じ。

ここからは推測になるのだが、Disk自体の性能ではなく、CPUのコア数で決定するということは、FSCTで行われるテストでは単純なDiskのI/Oの計測ではなく、サービスレイヤ(Windowsファイル共有サービス)でのスループット・アベイラビリティを計測することに主眼をおいているのではないかと。

クライアントではFSCTプログラムを走らせる必要があるため、コントローラ同様、Windows OSである必要がある。

DC(ドメインコントローラ)

AD環境でテストを行う場合は、当然ADのDCが必要となる。

FSCTでは非AD環境のWorkgroupでもテストを行えるため、必須ではない。

ただし、サーバが非Windows OSの場合はユーザの一括作成・削除のためにAD環境とDCが必要となる。(必須では無さそうだが、Workgroupで非Windows OSサーバでのテストは以下のように記載されているだけで、それ以上の情報がない)

There is not an easy way to run an FSCT test in a workgroup with a non-Windows server.

登場人物をまとめると

上記の3つの役割をまとめると以下の通り

名前 役割 OSの制限 備考
Controller テストの全体的な制御とデータの取得を行う Windowsのみ
Server テスト対象となるWindowsファイル共有サービス(CIFS/SMB)が稼働しているサーバ 非Windows系OK
Client(s) Controllerから指令を受けて、Serverへのリクエストを送信する Windows系のみ サーバとクライアントのCPUコア数が1:4になるように台数を用意する

(ヽ'ω`) < ここまで概要

FSCTの特徴と3つの登場人物ができたところで一旦区切り。

次はこの3つの登場人物を接続するためのネットワークについて説明し、実際にテストを行なっていく。

(ヽ'ω`) < Mailmanのconfig_listコマンドの使用方法と一括設定について

(ヽ´ω`) < config_listコマンドの役割

bin/config_listコマンドでは、コンソールからリストの各種設定を変更できる。

システム管理者がコマンドの実行を行う事を想定されているようで、パスワード等による認証は不要。

単一のリストだけの設定変更であれば、WebUIからのほうが手軽だが、運用形態の変化によるmm_cfg.pyの変更などが発生した場合、複数のリストに対して一括して処理を行うことができる。(繰り返しになるが、mm_cfg.pyを変更しても、既に作成されたリストの設定には影響がない)

(ヽ´ω`) < いくつかの注意点

面倒なことに、config_listコマンドでは、予め変更したい設定内容を記述したファイルを別個に用意してやらないといけない。

このファイルはPythonのスクリプトそのもので、config.pck内の変更したい変数への代入文を記載する。

例としてアーカイブの設定を変更するための設定ファイルは以下の通り

$ vi /tmp/archive_config.py

archive = True
archive_private = 1
archive_volume_frequency = 2

ここで注意したいのが、このファイルに記載されている変数名がmm_cfg.pyでの名前と違う(WebUIやconfig.pckファイルのダンプでの変数名と同じ)であること。

これまでの記事で何度も繰り返しているが、mm_cfg.pyはあくまでもテンプレートであり、実際のリスト毎の設定はリスト作成時にconfig.pckファイルとして出力される。今ここで変更しようとしているのはconfig.pckなので、config.pckの変数名を記述する。

(ヽ´ω`) < config.pck内変数名の取得

実際に入力となる設定変更用のファイルを書く前に、設定を行う変数名を調べておく必要がある。

config.pck内で使用されている変数名は以下の2通りの方法で確認ができる。

WebUIからの確認

WebUIの各設定項目に太字で記載されている、"◯◯◯の詳細"というリンク文字列の"◯◯◯"が対応する変数名となる。

f:id:tsugi-hagi:20141216164422p:plain

処理対象のリストが1つだけであれば、変数名を確認したこの画面から、そのまま変更してしまったほうが早い。

dumpdbコマンドからの確認

コンソールからbin/dumpdb <config.pckファイルの場所>を実行することで、config.pckの中身をテキストで確認することができる。

[root@d09f4ab28203 mailman]# bin/dumpdb lists/mailman/config.pck
[----- pickle ファイル開始 -----]
<----- 1 番目のオブジェクト ----->
{   'accept_these_nonmembers': [],
    'acceptable_aliases': '\n',
    'admin_immed_notify': True,
    'admin_member_chunksize': 30,
    'admin_notify_mchanges': False,
    'admin_responses': {   },
    'administrivia': True,
    'advertised': True,
    'anonymous_list': False,
    'archive': True,
    'archive_private': 0,
    'archive_volume_frequency': 1,
(以下省略)

ここでは各行の:より左側の部分、accept_these_nonmembersacceptable_aliasesが変数名となる。

(ヽ´ω`) < mm_cfg.py内の変数とconfig.pck内の変数の対応付けはどうやるの?

どこかに文章としてあるのかもしれないが、今のところ見当たらないです(ヽ´ω`)

ほとんどの場合はprefixとしてDEFAULT_が付いているかどうかなので、なんとなくはわかるかと。

(ヽ´ω`) < 設定ファイルの形式

変数名がわかったら、それに対する代入文を記述したPythonファイルを作成する。

基本的には下記の通り変数名 = 値を1行ずつ書いて行く。

archive = No
max_num_recipients = 10

値として使用可能なものは以下の通り

  • 数字
  • 文字列(シングルクォーテーションで囲む)
  • 真偽値(True, False)
  • 上記の値を含む配列
  • 上記の値を含む辞書

数字、文字列、真偽値は特に問題なく記述ができるはず。

配列・辞書

配列は複数の値を取りうる変数で、値は"[]"で囲まれる。

典型的な例としては、リストの管理者で、これは変数名ownerで設定される。

# bin/dumpdb lists/mailman/config.pck | grep "'owner'"
    'owner': ['ml-admin@hoge.com', 'john@foo.net', 'take@bar.jp'],

WebUI上で表示は以下の通りとなる。

f:id:tsugi-hagi:20141216164355p:plain

WebUIでの設定時は、指示通りテキストボックスに改行区切りで値を入れていく。

config_listコマンドで設定する場合、入力ファイルを以下のように作成する。

owner = ['ml-admin@hoge.com', 'john@foo.net', `take@bar.jp']

その他の形式にも言えることだが、入力ファイルには`bin/dumpdb'コマンドの出力そのまま

'owner': ['ml-admin@hoge.com', 'john@foo.net', 'take@bar.jp']

のように記述してはいけない。必ず変数名 = 値の形式で書くこと。

時間関係の関数

Defaults.pyの最上部に以下の定義がされている

def seconds(s): return s
def minutes(m): return m * 60
def hours(h): return h * 60 * 60
def days(d): return d * 60 * 60 * 24

これを見ると分かる通り、時間指定のベースは秒単位であり、minutes(), hours(), days()の関数が使用できる。

# 会員権停止の警告メールを3日おきに送信する
bounce_you_are_disabled_warnings_interval = days(3)

真偽値のエイリアス(Yes, On, No, Offの関係)

これまたDefaults.pyの最上部に以下の定義がある。

# Some convenient constants
try:
    True, False
except NameError:
    True = 1
    False = 0

Yes = yes = On = on = True
No = no = Off = off = False

真偽値のYes, yes, On, on, TrueNo, no, Off, off, Falseはそれぞれ同じ意味になるように定義されている。

更に

]# python
Python 2.6.6 (r266:84292, Jan 22 2014, 09:42:36)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> True == 1
True
>>> True == 0
False
>>> False == 0
True
>>> False == 1
False

より、Yes, yes, On, on Trueは1とNo, no, Off, off Falseは0と同値となる。つまり、Yesの代わりに1を使用したり、Offの代わりにnoを使うこともできる。

tryでTrueとFalseの名前を確認しているのは、Pythonの実装系によって定義されていない可能性を考慮しているものと思われる。

(ヽ´ω`) < 実際にやってみる

以上の内容を元に、実際にファイルの作成からコマンドの実行までを行う。 設定内容は以下の通り

  1. 通常のメーリングリストから、Aliasesのようなリストに役割を変更する
  2. Subjectのprefixを無しにする
  3. 配送メールの返信先を、元メールの送信者宛にする
  4. 非メンバーからの投稿を有効にする
  5. 管理者のアドレスを変更する(admin1@hoge.com, admin2@foo.net)
$ vi /tmp/aliases_settings.py

# 2) Subjectのprefixを無しにする
subject_prefix = ""

# 3) 配送メールの返信先を、元メールの送信者宛にする
reply_goes_to_list = 0

# 4) 非メンバーからの投稿を有効にする
generic_nonmember_action = 0

# 5) 管理者のアドレスを変更する(admin1@hoge.com, admin2@foo.net)
owner = ['admin1@hoge.com', 'admin2@foo.net']

3と4の値については、Defautls.pyに値の意味が記載されている。

# Mailman can be configured to "munge" Reply-To: headers for any passing
# messages. One the one hand, there are a lot of good reasons not to munge
# Reply-To: but on the other, people really seem to want this feature. See
# the help for reply_goes_to_list in the web UI for links discussing the
# issue.
# 0 - Reply-To: not munged
# 1 - Reply-To: set back to the list
# 2 - Reply-To: set to an explicit value (reply_to_address)
DEFAULT_REPLY_GOES_TO_LIST = 0

# What shold happen to non-member posts which are do not match explicit
# non-member actions?
# 0 = Accept
# 1 = Hold
# 2 = Reject
# 3 = Discard
DEFAULT_GENERIC_NONMEMBER_ACTION = 1

設定内容を記述したファイルができたので、これをリストに適用する。

# /opt/mailman/bin/config_list --inputfile=/tmp/aliases_settings.py <リスト名>

初めて設定した時は、WebUIやdumpdbコマンドで変更が正しく適用されているかを確認したほうが良い。

(ヽ´ω`) < 全てのリストに対して処理を行う

さて、ようやく本題。

単一のリストの設定を変更するだけであれば、わざわざ変数名を探してファイルを作って…という面倒な手順をふまずに、WebUIで変更を行ったほうが良い。

長々と前振りをしてまで、config_listの使い方を説明したのは、このコマンドを使用し全てのリスト(あるいは特定の複数)に対して、処理を行うケースを想定してのこと。

config_listコマンドに渡すリスト名のパラメータに、ワイルドカードが使えれば楽なのだが、残念ながらそうはなっていない。

ということで、以下の様な単純なスクリプトを作ってぶん回す。

#!/bin/bash

# Mailmanのインストールパス
MAILMAN_PATH=/opt/mailman

# 変更する設定内容
INPUT_FILE=/tmp/aliases_settings.py

# 処理対象のリスト
TARGET_LISTS=`ls $MAILMAN_PATH/lists`
# 特定のリストをファイル記述して処理
## TARGET_LISTS=`cat /tmp/target_lists.txt`

for list in $TARGET_LISTS;
do
    echo $list
    $MAILMAN_PATH/bin/config_list -v --inputfile=$INPUT_FILE $list
done

TARGET_LISTSの中の値で、任意のリストを指定できるので、

# "external-"から始まるリスト全てを処理対象とする
TARGET_LISTS = `ls $MAILMAN_PATH/lists/external-*`

単純なスクリプトなので、これをベースに目的に合わせて作りなおすと吉。

(ヽ´ω`) < withlistってコマンドが全リスト対象のオプションもあって便利そうなんだけど、コレじゃダメなの?

bin/withlistコマンドはPythonを使える人向けに、Mailman操作のプログラムインターフェースを提供するものなので、既に他の人が作成したスクリプトで設定を行うのには便利だけど、そうじゃないケースでは使いにくいかと。

(ヽ´ω`) < 運用計画はしっかりと

というわけで、config_listコマンドの使用方法はそこまで難しくはない。

が、変更を行うときに、単一のファイルで設定を完結できないのは少し面倒くさい。

可能な限りこの作業を繰り返さないために、Mailmanの構築時にしっかりと運用計画とmm_cfg.pyの内容を作成するのが良いです。

(ヽ'ω`) < Mailmanの設定ファイル、Defaults.pyとmm_cfg.py, config.pckの関係について

(ヽ´ω`) < 3つもあるからわかりにくい

Mailmanの細かい設定パラメータについて解説する前に、

既にインストールの段階で説明したとおり、Mailmanの設定はMailman/mm_cfg.pyMailman/Defaults.pyのデフォルト設定を上書きする形で行われる。

それでは、Mailmanに関する全ての設定がこの2つのファイルだけで行われているかというと然にあらず。実はMailmanの設定には「全体設定」と「リスト毎の設定」がある。

各リストのデフォルト設定はDefaults.pymm_cfg.pyで設定した値、つまりシステム管理者が設定した値となるが、多くの設定に関しては、リストの管理者が変更可能である。

この変更はリストの管理者がWebUIから行うことができるが、

  • リスト管理者のメールアドレス
  • リストから配送されるメールのSubjectに付与するPrefix
  • メンバー登録時のWelcomeメッセージの内容

のようなリスト固有のものもあれば、

  • メンバー以外からメールを受信した際の挙動(配送、破棄、保留)
  • アーカイブ化処理の有無
  • エラーメールの処理方法

などと、Mailmanのコアな部分の挙動についても制御が可能となっている。

「リスト毎の設定」はlists/<リスト名>/config.pckというファイルに保存される。この拡張子pckのファイルはPickleファイルと言い、Pythonに標準で添付されているオブジェクトシリアライズのためのフォーマットとなる。バイナリファイルなので、中身を見たい場合にはbin/dumpdbコマンドを使用する。

Defaults.py, mm_cfg.py, config.pckそれぞれの関係をまとめると以下のようになる。

ファイル名 役割 変更方法 変更者 ファイル形式
Defaults.py Mailmanデフォルトの設定を記載
各パラメータの役割についてのコメント有
基本的に変更しない システム管理者 Pythonスクリプト
mm_cfg.py Mailmanのシステム全体に渡る設定を記載 ファイルを直接編集 システム管理者 Pythonスクリプト
config.pck 各リスト毎の個別・固有の設定を記載 WebUI(リスト管理者、システム管理者)、bin/config_listコマンド(システム管理者) 主にリスト管理者 Pickle形式(バイナリファイル)

(ヽ´ω`) < 設定内容の移譲について

上記の図を見てわかるとおり、config.pckはリスト作成時に作成されるため、リスト作成後にmm_cfg.pyの内容を変更しても、その内容は既存のリストには反映されない。既存のリストへ設定を反映させるには、個別にbin/config_listコマンドで設定を流しこんでやる必要がある。(この方法については後述する)

ApacheやPostfixなどの一般的なサーバアプリケーションでは、設定ファイルを書き換えてサーバをリロードすれば設定が反映されるが、Mailmanではここが特殊でハマりやすい。

(おーい、未承認メールの保留期間を2週間にしておいてくれー)
(ヽ´ω`) < はいはい、mm_cfg.pyでDEFAULT_MAX_DAYS_TO_HOLDを14に設定っと…
3週間後
(オラァ! 2週間って言っただろうが! 全然消えてねぇぞ!![※デフォルトでは未承認メールは自動削除されない])
(;ヽ´ω`) < えぇ…
(;ヽ´ω`) < スンマセン、今WebUIで変更しました!
(チッ)
(ヽ´ω`) < と言うか自分でWebUIから変更してくれればよかったんじゃ…

というのが実体験に基づくかどうかは置いておいて、この特徴をしっかりと覚えておくためには、Defaults.pymm_cfg.pyを"設定ファイル"と考えずに "テンプレート" として考えると良い。

Defaults.pymm_cfg.pyはテンプレートで、設定ファイルはconfig.pckのみと覚えておけば、設定を変更するには、当然設定ファイルであるconfig.pckを操作しないといけない、となる。

(ヽ´ω`) < 「固有設定」と「個別設定」について

config.pckファイルの中身、リスト毎の設定には「固有設定」と「個別設定」がある。それぞれの区別は以下の通り。

言葉 定義 設定は必須か?
固有設定 リストの名前や管理者のメールアドレスなどの、そのリスト自身の独立性を表す設定。
リスト作成時にinputとして渡す。
必須
個別設定 Defaults.py, mm_cfg.pyから引き継がれ、必要に応じて上書きされた、メーリングリストシステムとしての挙動を制御する設定。 必要に応じて。設定しない場合はシステム管理者が設定した値が使用される。

実際のファイルの中身に明確な区別があるわけではなく、概念として2つの設定があるということを留意してもらいたい。

繰り返しになるが、個別設定は「mm_cfg.pyのものが使用される」のではなく、「mm_cfg.pyから生成される」ということを覚えておくこと。

(ヽ´ω`) < config.pckファイルの変更方法

config.pckファイルの中身を変更するには2つの方法がある。

1つめはWebUIからの変更。これはリスト管理者がログインして行うことができるし、システム管理者がマスターパスワード(bin/mmsitepassで作成したパスワード)でWebUIにログインすることでも変更が可能。

(ちなみに、アクセス対象のWebUIのURLはどちらの場合でも同じ。つまり、WebUIにログインする際には、リスト個別のパスワードとマスターパスワードの2つが利用可能となる。)

もう1つが先程から何度か出ているbin/config_listコマンドである。

これはサーバのスクリプトファイルなので、当然、サーバのコンソールを触れる人間、通常はシステム管理者のみが使用できるコマンドとなる。

bin/withlistというコマンドもあるのだが、これはかなりPythonプログラマに寄ったコマンドなので、Pythonに馴染みのない管理者にはとっつきにくい。

(ヽ´ω`) < config_listコマンドの使用方法

長くなるので次のエントリで

(ヽ'ω`) < わかりにくい 図を使え 人に伝える気があるのか

(ヽ'ω`) < そ、そのうち追加します

(ヽ'ω`) < Mailmanを"まずは動くまで"設定

(ヽ´ω`) < インストールの続き

前回までで、Mailmanを使うためのファイルの配置と、Postfix, Apacheの連携ソフトウェアの設定を行った。

かなり長い手順となったが、今回はMailman自身の設定を行っていく。

  • Mailmanの初期設定
    1. mm_cfg.pyの設定
    2. aliasesファイルの仮作成
    3. 管理ML(mailman)作成
    4. マスターパスワード設定
  • 動作を確認
    1. 投稿確認
    2. Gmailからの投稿確認

(ヽ´ω`) < Mailmanの初期設定

以下の手順を行い、Mailmanが正常に起動するまでもっていく。ここでは、個別のカスタマイズについては触れない。設定項目があまりにも多いため、別のエントリで逆引き形式で解説を行う。

mm_cfg.pyの設定

Mailmanでは、あらゆるシステムのデフォルト設定値がMailman/Defaults.pyというファイルに記載されている。

このファイル自身は、拡張子を見て分かる通りpythonスクリプトそのものとなっているが、ApacheやPostfixの設定ファイルと同じように

変数名 = 値

の形式で設定を入れているだけなので、読んでいく分にはあまり問題がないと思う。

各変数名(設定項目)がどういう働きをするのかも、このファイルに記載されているので、このファイルを参照すればどのような設定が行えるかがわかるようになっている。

で、システムの設定をデフォルトから変更したい時、

例えば、デフォルトではMailmanから配送されたメールの返信先は、送信者のアドレスとなっているが、これをメーリングリストのアドレスに変更したい、という場合

Defaults.pyDEFAULT_REPLY_GOES_TO_LISTの値を0から1に変更する、のではなく

同じディレクトリ(Mailman/)のmm_cfg.pyというファイルに、設定を記述する。

# Mailman/Defaults.pyの以下の記述はそのままで
DEFAULT_REPLY_GOES_TO_LIST = 0

# Mailman/mm_cfg.pyに以下の記述を追加する
DEFAULT_REPLY_GOES_TO_LIST = 1

これはシステムの正常性を保つのに非常に便利な話で、Defaults.pyに記載されているデフォルト値は変更されないので、不都合が発生して、その原因が不明な場合はmm_cfg.pyの内容を削除してしまえば、元の状態に戻すことができる。

本来であれば、ここでメーリングリストの基本的な設定を記述してくことになるのだが、まずは最低限の記載のみを行う。

# 1) 連携するMTAの名前を指定
MTA = 'Postfix'

# 2) WebUIからアクセスする際のFQDN
DEFAULT_URL_HOST = 'mailman-ui.tsugihagi.net'

# 3) メーリングリストアドレスの@以降の部分
DEFAULT_EMAIL_HOST = 'ml.tsugihagi.net'

# 4) 上記のDEFAULT_*_HOSTを変更した場合、
#    下記の通りadd_virtualhostメソッドを呼び出す
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)

各項目についての説明

  1. 連携するMTAの名前を指定
    ここではPostfixを使用するので、値にはPostfixを指定。他にはMailman/MTA/ディレクトリ以下のクラスの名前が使用可能とのことだが…ManualPostfixしか無い。完全にPostfixとの連携が前提なんですかね。
  2. WebUIからアクセスする際のFQDN
    Mailmanが提供するWebUIのURL内の、ホスト名部分を指定する。ここでは
    http://mailman-ui.tsugihagi.net/mailman/
    というURLで提供することを想定。URL内の斜体の部分が対象の値となる。
  3. メーリングリストアドレスの@以降の部分
    各メーリングリストのアドレスが
    hogehoge@ml.tsugihagi.net
    となるとして、斜体の部分。もしも foobar@tsugihagi.net
    とした場合はDEFAULT_EMAIL_HOST = 'tsugihagi.net'となる。
  4. add_virtualhostの呼び出し
    DEFAULT_URL_HOSTとDEFAULT_EMAIL_HOSTの値を変更した時には、必ずこのメソッドを呼び出す必要がある。ここはMailmanをバーチャルホストで運用した場合の話もからんでくるのだが、とりあえずおまじない的に覚えておく。

mm_cfg.pyについて補足しておくと、このファイルの内容がそのまま、各メーリングリストの設定として扱われるわけではない。

このファイルの内容を読み取って、各メーリングリストの設定内容がconfig/<メーリングリスト名/config.pckというファイルに書き出される。

この辺りの細かい話は、メーリングリストのカスタマイズに関連して、別エントリで解説を行う。

aliasesファイルの仮作成

下記のコマンドでaliasesファイルを作成する。このファイルはメーリングリストの作成・削除を行う度に更新されるので、ここでは問題なく作成できるかをだけを確認する。

# /opt/mailman/bin/genaliases

上記コマンド実行後に、data/以下にaliases, aliases.dbと2つのファイルが作成されている事を確認しておく。

[root@d09f4ab28203 data]# ls -l
total 36
-rw-rw---- 1 root mailman   351 Dec 15 06:07 aliases
-rw-r----- 1 root mailman 12288 Dec 15 06:07 aliases.db
-rw-r--r-- 1 root mailman    10 Dec 15 05:51 last_mailman_version
-rw-r--r-- 1 root mailman 14100 Dec 15 05:51 sitelist.cfg

[root@d09f4ab28203 data]# cat aliases
# This file is generated by Mailman, and is kept in sync with the
# binary hash file aliases.db.  YOU SHOULD NOT MANUALLY EDIT THIS FILE
# unless you know what you're doing, and can keep the two files properly
# in sync.  If you screw it up, you're on your own.

# The ultimate loop stopper address
mailman-loop: /opt/mailman/data/owner-bounces.mbox

管理ML(mailman)作成

Mailmanではシステムの管理のために、1つのメーリングリスト('site-wide mailing list')が必要となる。

パスワードリマインダー等は、このメーリングリストのアドレスから届くことになる。他にも色々なところで使われる…っぽいのだが、あんまり見たことがない。

このメーリングリストはデフォルトではmailmanという名前となる。(もしもこの名前が気に喰わない場合は、mm_cfg.pyMAILMAN_SITE_LISTという名前の変数を設定することで変更が可能)

メーリングリストの作成は、bin/newlistコマンドを使用する。このコマンドの引数は以下の通り。

newlist <メーリングリスト名> <管理者のメールアドレス> <管理パスワード>

ここではmailmanという名前のメーリングリストを作成するので、

# /opt/mailman/bin/newlist mailman ml-admin@tsugihagi.net sOme_PA$$W0RD

上記コマンドで、mailman@ml.tsugihagi.netというメーリングリストが作成された。

コマンド実行時に、エンターを押すと管理者にメールを送信した旨のメッセージが表示されるが、実際にはMailmanのサービスはまだ実行されていないので、送信は行われない。

実際にmailmanというメーリングリストが作成されたことを、システム上で確認してみる。

まずは、lists/ディレクトリにmailmanというディレクトリが存在しているか。

[root@d09f4ab28203 mailman]# pwd
/opt/mailman
[root@d09f4ab28203 mailman]# cd lists
[root@d09f4ab28203 lists]# ls -l
total 4
drwxrwsr-x 2 root mailman 4096 Dec 15 06:11 mailman

次に先ほどgenaliasesで作成されたdata/aliasesファイルにエントリが追加されているか。

[root@d09f4ab28203 lists]# cat /opt/mailman/data/aliases
# This file is generated by Mailman, and is kept in sync with the
# binary hash file aliases.db.  YOU SHOULD NOT MANUALLY EDIT THIS FILE
# unless you know what you're doing, and can keep the two files properly
# in sync.  If you screw it up, you're on your own.

# The ultimate loop stopper address
mailman-loop: /opt/mailman/data/owner-bounces.mbox

# STANZA START: mailman
# CREATED: Mon Dec 15 06:10:11 2014
mailman:             "|/opt/mailman/mail/mailman post mailman"
mailman-admin:       "|/opt/mailman/mail/mailman admin mailman"
mailman-bounces:     "|/opt/mailman/mail/mailman bounces mailman"
mailman-confirm:     "|/opt/mailman/mail/mailman confirm mailman"
mailman-join:        "|/opt/mailman/mail/mailman join mailman"
mailman-leave:       "|/opt/mailman/mail/mailman leave mailman"
mailman-owner:       "|/opt/mailman/mail/mailman owner mailman"
mailman-request:     "|/opt/mailman/mail/mailman request mailman"
mailman-subscribe:   "|/opt/mailman/mail/mailman subscribe mailman"
mailman-unsubscribe: "|/opt/mailman/mail/mailman unsubscribe mailman"
# STANZA END: mailman

この2点で正常にメーリングリストが作成されたどうかを判別できる。(実際に問題なく配送されるかは別だが)

マスターパスワード設定

マスターパスワードという名前は勝手につけた名前で、公式ドキュメントでは'site password'と表記されている。

このパスワードはMailmanに関する全ての操作を行うためのパスワードで、Linuxシステムでのrootパスワードと、ほぼ同じとなる。

以下のコマンドで作成する。

# mmsitepass <パスワード>
# /opt/mailman/bin/mmsitepass My-$lt3-p@$sW0rD

当然、取り扱いには最大限の注意を

(ヽ´ω`) < 動作を確認

これでようやく設定は完了。実際にMailmanの動作を確認する。

と、その前にMailmanのサービスが起動していないので起動してやる。 CentOS6で使用できるSysVinit用のサービス起動スクリプトが、script/mailmanにあるので、それを/etc/init.d/にコピーして起動する。

# cp /opt/mailman/script/mailman /etc/init.d/
# chkconfig --add mailman
# service mailman start

投稿確認

早速投稿確認を行う。

現在の状態で、システムにはmailman@ml.tsugihagi.netというメーリングリストが1つだけ存在するので、そこにユーザを追加して、投稿が配送されるかを確認する。

今回はサーバ側の解説がメインなので、この辺りの操作は、実際の運用で作成された手順書等を参考にしてもらいたい。「Mailman 運用」でググると山ほど手順書が引っかかる。

mailman 運用 - Google 検索

Gmailからの投稿確認

Gmailでは同一のMessage-IDを持つメールを重複メールとして扱う、という仕様がある。

Message-IDはメールの送信時に決定されるが、GmailからMailmanに投稿を行った場合、送信は問題なく行われるが、"自分宛に配信されたメール"と"自分が送ったメール"は同一のMessage-IDを持つ。

そのため、Mailmanから送信されたメッセージは、Gmailの受信トレイをスキップして、そのままアーカイブされる(自分が送ったメールが自分へと配信されていないように見える現象が起こる)

Gmail ヘルプ

これはMailmanに限った話ではなく、送信元のMessage-IDを保持するポリシーのメーリングリストシステム全般に起こりうる問題となる。

MailmanのMLではMessage-IDを書き換えるか否かについて、散々に議論された結果、書き換えを行わないという方針となっている。将来的に方針が変更される可能性があるかもしれないが、少なくとも現状ではシステム側・あるいは運用面で対応する必要がある。

運用で対応する場合は「Gmailからの投稿については、送信者へ配送されません」とアナウンスを行えば良いだけなのだが…、新規ではなくリプレース(Majordomoなど)の場合、混乱が起こる可能性がある。

オリジナルのソースに手を加えるリスクを取るか、運用面での手間を取るかはケースバイケースだが、今回の解説では上記の問題に対応した+jバージョンをtarballからインストールすることで、システム側での対応を行った。

実際にGmailアカウントから投稿を行うと、自分が送信したメッセージがちゃんと受信トレイに表示されると思う。

(ヽ´ω`) < ここまでが初期設定

以上でMailmanのインストール部分については完了。

このままの状態で使い続けられるような環境ならば良いんだけど、殆どの場合はそうじゃないはず。

先ほど例でも上げたとおり

  • 投稿の返信先を送信者ではなく、メーリングリストにしたい
  • 返信時の「Re:」の付く場所を変更したい
  • Subjectに自動的に付与される文字列を変更したい
  • WebUIがあるからメールコマンドを無効化したい

など、いろいろな要望があるかと予想されるので、カスタマイズの方法や、運用面でのトラブルシュート、ログの見かたなどを書いていく予定。

(ヽ´ω`) < インストール手順のページは山ほどあるから、どちらかというと、そっちのほうがメインコンテンツですかね。