DigitalOceanのネットワーク周りの情報やTIPSをまとめてみた。グローバルIPを変更したいんだけどIPを変えたい時はDropletを削除・再作成するといいよ、というポストを見つけた。モデレータが回答しているので、コントロールパネルでの機能としては用意されていないっぽい。帯域制御とかしてるの?普通の使い方ならしていないとのこと。NICなので1Gbpsが上限。いえそこまでいけるわけ無いよねと。ports.帯域保証については言及なしなので、機能として用意されてないっぽい。1Tの転送量を超えたらどうなるの?Outboundトラヒックに対しては、$0.02/GBの転送量が加算される。転送量使い切ったらアクション起こすとかの機能は無いの?下記のポストを見る限り、用意されていないっぽい。(モデレータが記事の案内をしている。DigitalOceanこのポストに簡単なスクリプトが投稿されている。Pastebin.comvnstatコマンドで当月の通信量を確認して、999Gを超えていたらshutdownコマンドを発行するという、単純明快なスクリプト。コレをcronで1日1回実行と書かれているが、バーストトラヒックが予測不可能な場合は、もっと細かく時間を区切ったほうがいいだろう。実際に使うときにはshutdownコマンドの代わりにサービスを停止したり、トラヒックを抑える処理を行うほうが良いと思う。ロードバランサ配下であれば、グループメンバーから外させるとか。ネットワークに限った話しでなく、支払い全体ということであれば、メールの通知サービスが用意されている。DigitalOcean任意の金額を超えたらメールで警告を送ってくれる。警告を送るだけでその後のアクションはユーザ自身に任される。LowEndTalk2013年の話だが、ニューヨークリージョンの物理サーバは1Gbpsでコアネットワークに接続されていて、そこからインターネットへは冗長化された10Gbps回線で接続されているとのこと。上位ISPはCogentとLevel3。公式のHPにも1Gbps、10Gbps接続の記述があるので、そこは変わってなさそう。速度が安定しない先ほど書いたトピックにも報告があるが、同一リージョンでも速度差が発生することがあるっぽい。理由については色々推測されているが、とりあえずDropletを削除・作成して新しいIPを取得することで、改善したケースもあるとのこと。推測されている)その他の対処方法についても、先のトピックに詳しい。使っていて他に気づいたことがあったらまた第2段ってことで書いていきます。そもそもVirtIOってなんなのよ?下記のページによると、KVMやQEMUで採用されている、I/O周りのドライバの準仮想化ソフトらしい。VirtioVirtIOを使用しない環境(完全仮想化)では、ハイパーバイザーによってI/O周りのドライバが完全にエミュレーションされる。ハイパーバイザーが実際のハードウェアの挙動を再現する形になるので、それなりに処理コストが大きくなる。VirtIOを使用すると、VM上ではNICやディスクコントローラが仮想化されたものであると認識された上で、専用のドライバを経由してハイパーバイザーで処理される。そのドライバはハイパーバイザーの動作に最適化されたものなので、完全仮想化環境に比べて、パフォーマンスが向上する。ここでの完全・準仮想化について、あくまでI/O周りのドライバに限定した話で、OS自体の仮想化方式については関係ない。いうより、完全仮想化されたOSで、I/Oドライバのみ準仮想化させパフォーマンスを向上させる、というお話。基本的にはOnでOKDigitalOceanの中の人も、基本的にはパフォーマンスが上がるからOnでいいよー、とのこと。DigitalOceanRedhatもKVMでVirtIOを有効化することでパフォーマンスが上がると解説している。バージョンがベアメタルベースのシステムと同様の動作をすることが予想されます。実際のDiskベンチマークではスコアが落ちているケースもある。$NUM_CPU_JOBSを渡しているので、コンパイル時のスレッド数はコア数+1になると考えると、マルチスレッド系の処理が少し弱くなるっぽい。この現象がDigitalOcean特有のものなのか、KVM全般的なものなのかは不明だが、ディスクアクセスが多いアプリケーションを使用する場合は、念の為にテストを行ったほうが良いかと思われる。VirtIOを有効化することによるデメリットは?マルチスレッドプロセスのディスク処理が遅くなる可能性については上で述べた。他には完全仮想化ではなくなるので、アプリケーションによっては動作の一部に影響が出るかもしれない。いえ、ドライバレベルでゴリゴリ書いてあるようなアプリケーションなんてそうそう無いだろうし、そんなものをVPSで動かすシチュエーションもあまり想像できないので、一般的な環境では"無い"。...と言ってしまうと問題ありかもしれないのだが、DigitalOceanの中の人は言っちゃってるんですよね。VirtIOが正しく有効化されているか確認したいdfコマンドの出力で/dev/vdaがあればOKっぽい。'enabled'さくらのVPSでも/dev/vdaあったから、KVM使ってるところはほとんど有効化推奨って感じなんですかね。ネットワークについて前回の記事でFSCTでは3つの役割のPCが必要という事を解説した。*****複数台のPCが存在し、テスト対象はWindowsファイル共有サービスなので、当然3つの役割を担当するPCはネットワークに接続されている必要がある。ここでテストの敷居が多少高くなり、サーバとクライアントのPCにはデータ通信(実際の負荷)用のネットワークと、テストをコントロールするためのネットワーク、2つのNICが必要となる。物理・仮想を問わず、通常のファイルサーバやミドル~ハイエンドのNASであれば、NICが2つ以上最初からついていたり、増設は簡単だと思うが、ローエンドのNASの場合はどうするか。そもそもFSCTではそういった製品のテストを想定していないと思われる。添付の説明文書では、テスト用ネットワークとして4つの形態を例に上げている。Architecture"の"Networking"を参照していただきたい。Basic基本的なスタイル。サーバと各クライアントはNICを2つ持ち、1つを負荷生成用に使用し、もう一方をテストのコントロールに割り当てる。テストではない環境ではクライアントのNICは1つだけとなる。通常のオフィスなどで最も一般的な形態と思われる。Segmented2台以上のクライアントを別々のLANセグメントに配置することで、負荷を分散する。サーバはLANセグメントの数だけNICが必要となる。1つ重要なことが書いてあって、1Gbpsの回線あたり、4,000ユーザをまかなうことができるとある。これはhpのPDF文章でも、"FSCTの経験則"として記載されている。http://h50146.www5.hp.com/products/storage/whitepaper/pdfs/4AA3-8726jpn.pdf4000以上のユーザがいる場合は、LANセグメントとNICを分割することで、効果的に使用状況にも大きく左右されると思うが、参考として覚えておくと良い。Sharedサーバと各クライアントは3つ以上のNICをを持ち、2つ以上のNICを負荷生成用に使用する。2012とSMB3.0の組み合わせで、SMBマルチチャネルという機能が追加されたらしい。BlogsSegmentedの場合、クライアント通信を行うのはそのLANセグメントに属する1つのNICだけだが、Sharedの形態でSMBマルチチャネルが有効な場合は複数のNICが使われるっぽい。ベースでコントロールするため、この時点では送信元や宛先に関するヘッダー情報は持っていません。このため、宛先などは一切考えず、到達できるすべてのパスを用いてラウンドロビン的に送ろうとします。上記ページの図を見ても、複数のLANセグメント(別のサブネット)の通信をまとめてファイル転送が行われている。いった疑問だが、Windowsファイル共有に限った話ではなく、Windowsネットワーク全般の話で、同一セグメントでの複数IP付与は想定してないらしい。思われるかもしれないが、NICチーミングはあくまでもL2/3でのロードバランシングなので、単一の相手との通信ではNICのワイヤスピード以上が出ることはない。あるパスでエラーが発生しても、その他のパスを使用して転送が行われるため、サービスの可用性も向上する。connection.SMBマルチチャネルの設定はデフォルトでOnになっていて、複数パスが存在する場合、自動的に構成が行われるので、特に管理者は難しい設定を行う必要はない。必要がないだけで、経路の制御などを行いたい場合は、ちゃんとそのための方法が用意されている。Teaming名前の通り、サーバ側のNICをチーミング構成にすることで負荷分散を行う。実際に負荷が分散されるかは、チーミングモードの設定と、運用環境に依る。チーミングモードについては、以下のページに詳しい。R2であれば、動的モードにしておけば問題ないだろう。どのネットワーク形態がいいの?FSCTの経験則から、1GbpsのNICが搭載されていれば、4000ユーザまではBasicでも問題が無いとのこと。Sharedの形態でSMBマルチチャネルが有効であれば、パフォーマンスと可用性が向上するので理想的。Teamingが現実的だろうか。Windowsファイル共有のパフォーマンスを測定するWindowsのファイル共有機能を提供する製品はいっぱいあるのだが、どの製品のどのランクのモノを選んでいいのかがわからない。パフォーマンスチューニングをしたのだが、どの程度の効果があるのかを測定したい。そんな時には負荷テストを実施すると思うが、そんな時の助けになるのがこのツール。Tool(FSCT)Microsoftから提供されているWindowsのファイル共有機能に特化した計測ツール。Center有名なのかそうじゃないのかよくわからなくて、Googleで検索しても日本語ページはほとんど引っかからず、hpのファイルサーバパフォーマンスに関するPDF文章で1件。http://h50146.www5.hp.com/products/storage/whitepaper/pdfs/4AA3-8726jpn.pdf英語のページを含めてもそんなに情報ソースが多く無い。使い方のソースになりそうなのが、Technetのページと本体に添付されている説明文章のみ。2008でMicrosoftの社員が作成したと思われる、プレゼン資料ぐらいか。http://www.snia.org/sites/default/files2/sdc_archives/2008_presentations/monday/JoseBarreto_CIFS_SMB_FSCT.pdf資料が少ないから調べるの大変そうだなー、と思っていたら本体添付の説明文章がかなり細かく書いてあるので、意外に楽だった。FSCTの特徴ディスクパフォーマンスを測定するだけなら他にもいくつもツールが有るが、FSCTは以下の特徴を持っている。FSCT"より)実際のWindowsとWin32アプリケーションの挙動をシミュレートする他のDiskストレスツールと比べて最も特徴的な点。一般的なDiskストレスツールはひたすらファイルの作成や削除、コピーなどを繰り返し続ける。(複数の物理クライアントからの操作や、ファイルサイズの大小変更等の機能もあるが)当然のことながら、このタイプのテストで発生する負荷は、実際にユーザが操作する際の挙動とはかけ離れている。それに対してFSCTでは、Windowsでのファイル操作(コマンドライン・エクスプローラーからのファイル操作、Wordでのファイルオープン・セーブ・クローズ等)をシミュレートすることで、実際にユーザがWindowsを操作している時の挙動と同じような負荷をかける事ができる。前項で実際のユーザの操作をシミュレートすると説明したが、実際にどのような操作が行われるかはWorkloadsと呼ばれるシナリオに沿って定義される。どのようなサイズのファイルを使って、どういう操作を行うのか。その操作の時間あたりの頻度は。それらを記述したXMLとテキストファイルの集合がWorkloadsの本体となる。FSCTでは"HomeFolders"という名前のWorkloadsが提供されている。これはユーザのホームディレクトリがファイルサーバに存在する場合を想定したシナリオとなっている。FSCTで提供されているWorkloadsは"HomeFolders"だけだが、例えば大きいファイルしか読み書きしないファイルの読み込みだけで書き込みをしないファイルのコピーしか行わないというそれぞれのケースに合わせてWorkloadsを作成することで、自分の環境にマッチした系祖国を行うことができる。無理FSCTでは1台のクライアントPC内に複数のユーザを作成し、それぞれのユーザからのリクエストをシミュレートすることができる。ファイルサーバの同時接続数の限界を測定するのに役に立つ。詳細なレポート機能FSCTでのテスト結果はテキストファイルで出力される。このファイルの中にはスループットレイテンシネットワーク帯域OSのパフォーマンスカウンター(サーバ/クライアント両方)等が含まれる。Windows(ETW)のトレースデータとやらも出力可能とのこと。ストレステストの場合、サーバ側の限界かと思っていたら、リクエストを送信するクライアントの限界だったというオチがあるので両方のデータが取得できるのは非常に便利。216528こんな感じで、上記の出力から察するにこのサーバの限界ユーザ数は10000~11000ぐらいと推測することができる。最大ユーザ数ユーザ増数を指定することができる。1000でテストが行われたことがわかる。100として、条件を徐々に細かくしていくことで限界点を詳細に探ることができる。Warning!!添付の説明文章にも特徴のすぐ後に書いてあるのだが、FSCTで行われるテストではボリュームのフォーマットが行われる。データが消える可能性がある。loss.可能性というかフォーマットされたら確実に消えると思うのだが、兎に角、FSCTによるテストは導入時か移行時のみとし、現用の環境では行わないこと。FSCTではADドメイン(あるいはWorkgroup)のパスワードを、クリアテキストでネットワーク上に流すため、可能な限り専用のネットワーク内で行うことをオススメする。3つの登場人物FSCTでは最低限3つの役割を演じるPCが必要となる。Controller(コントローラ)テスト全体を制御し、得られたデータを蓄積していくためのPC。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ファイル共有サービス)でのスループット・アベイラビリティを計測することに主眼をおいているのではないかと。OSである必要がある。DC(ドメインコントローラ)AD環境でテストを行う場合は、当然ADのDCが必要となる。FSCTでは非AD環境のWorkgroupでもテストを行えるため、必須ではない。OSの場合はユーザの一括作成・削除のためにAD環境とDCが必要となる。ここまで概要FSCTの特徴と3つの登場人物ができたところで一旦区切り。次はこの3つの登場人物を接続するためのネットワークについて説明し、実際にテストを行なっていく。config_listコマンドの役割bin/config_listコマンドでは、コンソールからリストの各種設定を変更できる。システム管理者がコマンドの実行を行う事を想定されているようで、パスワード等による認証は不要。単一のリストだけの設定変更であれば、WebUIからのほうが手軽だが、運用形態の変化によるmm_cfg.pyの変更などが発生した場合、複数のリストに対して一括して処理を行うことができる。面倒なことに、config_listコマンドでは、予め変更したい設定内容を記述したファイルを別個に用意してやらないといけない。このファイルはPythonのスクリプトそのもので、config.pck内の変更したい変数への代入文を記載する。2ここで注意したいのが、このファイルに記載されている変数名がmm_cfg.pyでの名前と違う(WebUIやconfig.pckファイルのダンプでの変数名と同じ)であること。これまでの記事で何度も繰り返しているが、mm_cfg.pyはあくまでもテンプレートであり、実際のリスト毎の設定はリスト作成時にconfig.pckファイルとして出力される。今ここで変更しようとしているのはconfig.pckなので、config.pckの変数名を記述する。実際に入力となる設定変更用のファイルを書く前に、設定を行う変数名を調べておく必要がある。config.pck内で使用されている変数名は以下の2通りの方法で確認ができる。WebUIからの確認WebUIの各設定項目に太字で記載されている、"◯◯◯の詳細"というリンク文字列の"◯◯◯"が対応する変数名となる。処理対象のリストが1つだけであれば、変数名を確認したこの画面から、そのまま変更してしまったほうが早い。<config.pckファイルの場所>を実行することで、config.pckの中身をテキストで確認することができる。1,(以下省略)ここでは各行の:より左側の部分、accept_these_nonmembersやacceptable_aliasesが変数名となる。́ω`)ほとんどの場合はprefixとしてDEFAULT_が付いているかどうかなので、なんとなくはわかるかと。変数名がわかったら、それに対する代入文を記述したPythonファイルを作成する。値を1行ずつ書いて行く。複数の値を取りうる変数で、値は"[]"で囲まれる。典型的な例としては、リストの管理者で、これは変数名ownerで設定される。'take@bar.jp'],WebUI上で表示は以下の通りとなる。WebUIでの設定時は、指示通りテキストボックスに改行区切りで値を入れていく。config_listコマンドで設定する場合、入力ファイルを以下のように作成する。'take@bar.jp']のように記述してはいけない。days()の関数が使用できる。Offの関係)これまたDefaults.pyの最上部に以下の定義がある。Falseはそれぞれ同じ意味になるように定義されている。Falseは0と同値となる。Yesの代わりに1を使用したり、Offの代わりにnoを使うこともできる。tryでTrueとFalseの名前を確認しているのは、Pythonの実装系によって定義されていない可能性を考慮しているものと思われる。実際にやってみる以上の内容を元に、実際にファイルの作成からコマンドの実行までを行う。'admin2@foo.net']3と4の値については、Defautls.pyに値の意味が記載されている。1設定内容を記述したファイルができたので、これをリストに適用する。<リスト名>初めて設定した時は、WebUIやdumpdbコマンドで変更が正しく適用されているかを確認したほうが良い。全てのリストに対して処理を行うさて、ようやく本題。単一のリストの設定を変更するだけであれば、わざわざ変数名を探してファイルを作って...という面倒な手順をふまずに、WebUIで変更を行ったほうが良い。前振りをしてまで、config_listの使い方を説明したのは、このコマンドを使用し全てのリスト(あるいは特定の複数)に対して、処理を行うケースを想定してのこと。config_listコマンドに渡すリスト名のパラメータに、ワイルドカードが使えれば楽なのだが、残念ながらそうはなっていない。いうことで、以下の様な単純なスクリプトを作ってぶん回す。$MAILMAN_PATH/lists/external-*`単純なスクリプトなので、これをベースに目的に合わせて作りなおすと吉。withlistってコマンドが全リスト対象のオプションもあって便利そうなんだけど、コレじゃダメなの?bin/withlistコマンドはPythonを使える人向けに、Mailman操作のプログラムインターフェースを提供するものなので、既に他の人が作成したスクリプトで設定を行うのには便利だけど、そうじゃないケースでは使いにくいかと。運用計画はしっかりとというわけで、config_listコマンドの使用方法はそこまで難しくはない。変更を行うときに、単一のファイルで設定を完結できないのは少し面倒くさい。可能な限りこの作業を繰り返さないために、Mailmanの構築時にしっかりと運用計画とmm_cfg.pyの内容を作成するのが良いです。インストールの段階で説明したとおり、Mailmanの設定はMailman/mm_cfg.pyがMailman/Defaults.pyのデフォルト設定を上書きする形で行われる。それでは、Mailmanに関する全ての設定がこの2つのファイルだけで行われているかというと然にあらず。実はMailmanの設定には「全体設定」と「リスト毎の設定」がある。各リストのデフォルト設定はDefaults.pyとmm_cfg.pyで設定した値、つまりシステム管理者が設定した値となるが、多くの設定に関しては、リストの管理者が変更可能である。この変更はリストの管理者がWebUIから行うことができるが、リスト管理者のメールアドレスリストから配送されるメールのSubjectに付与するPrefixメンバー登録時のWelcomeメッセージの内容のようなリスト固有のものもあれば、メンバー以外からメールを受信した際の挙動(配送、破棄、保留)アーカイブ化処理の有無エラーメールの処理方法などと、Mailmanのコアな部分の挙動についても制御が可能となっている。「リスト毎の設定」はlists/<リスト名>/config.pckというファイルに保存される。この拡張子pckのファイルはPickleファイルと言い、Pythonに標準で添付されているオブジェクトシリアライズのためのフォーマットとなる。バイナリファイルなので、中身を見たい場合にはbin/dumpdbコマンドを使用する。config.pckそれぞれの関係をまとめると以下のようになる。設定内容の移譲について上記の図を見てわかるとおり、config.pckはリスト作成時に作成されるため、リスト作成後にmm_cfg.pyの内容を変更しても、その内容は既存のリストには反映されない。既存のリストへ設定を反映させるには、個別にbin/config_listコマンドで設定を流しこんでやる必要がある。(この方法については後述する)ApacheやPostfixなどの一般的なサーバアプリケーションでは、設定ファイルを書き換えてサーバをリロードすれば設定が反映されるが、Mailmanではここが特殊でハマりやすい。Defaults.pyとmm_cfg.pyはテンプレートで、設定ファイルはconfig.pckのみと覚えておけば、設定を変更するには、当然設定ファイルであるconfig.pckを操作しないといけない、となる。「固有設定」と「個別設定」についてconfig.pckファイルの中身、リスト毎の設定には「固有設定」と「個別設定」がある。それぞれの区別は以下の通り。リストの名前や管理者のメールアドレスなどの、そのリスト自身の独立性を表す設定。リスト作成時にinputとして渡す。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に馴染みのない管理者にはとっつきにくい。Apacheの連携ソフトウェアの設定を行った。長い手順となったが、今回はMailman自身の設定を行っていく。以下の手順を行い、Mailmanが正常に起動するまでもっていく。ここでは、個別のカスタマイズについては触れない。設定項目があまりにも多いため、別のエントリで逆引き形式で解説を行う。mm_cfg.pyの設定Mailmanでは、あらゆるシステムのデフォルト設定値がMailman/Defaults.pyというファイルに記載されている。値の形式で設定を入れているだけなので、読んでいく分にはあまり問題がないと思う。各変数名(設定項目)がどういう働きをするのかも、このファイルに記載されているので、このファイルを参照すればどのような設定が行えるかがわかるようになっている。デフォルトではMailmanから配送されたメールの返信先は、送信者のアドレスとなっているが、これをメーリングリストのアドレスに変更したい、という場合Defaults.pyのDEFAULT_REPLY_GOES_TO_LISTの値を0から1に変更する、のではなく同じディレクトリ(Mailman/)のmm_cfg.pyというファイルに、設定を記述する。1これはシステムの正常性を保つのに非常に便利な話で、Defaults.pyに記載されているデフォルト値は変更されないので、不都合が発生して、その原因が不明な場合はmm_cfg.pyの内容を削除してしまえば、元の状態に戻すことができる。本来であれば、ここでメーリングリストの基本的な設定を記述してくことになるのだが、まずは最低限の記載のみを行う。連携するMTAの名前を指定ここではPostfixを使用するので、値にはPostfixを指定。他にはMailman/MTA/ディレクトリ以下のクラスの名前が使用可能とのことだが...ManualとPostfixしか無い。完全にPostfixとの連携が前提なんですかね。WebUIからアクセスする際のFQDNMailmanが提供するWebUIのURL内の、ホスト名部分を指定する。ここではhttp://mailman-ui.tsugihagi.net/mailman/というURLで提供することを想定。URL内の斜体の部分が対象の値となる。各メーリングリストのアドレスがhogehoge@ml.tsugihagi.netとなるとして、斜体の部分。'tsugihagi.net'となる。add_virtualhostの呼び出しDEFAULT_URL_HOSTとDEFAULT_EMAIL_HOSTの値を変更した時には、必ずこのメソッドを呼び出す必要がある。ここはMailmanをバーチャルホストで運用した場合の話もからんでくるのだが、とりあえずおまじない的に覚えておく。mm_cfg.pyについて補足しておくと、このファイルの内容がそのまま、各メーリングリストの設定として扱われるわけではない。このファイルの内容を読み取って、各メーリングリストの設定内容がconfig/<メーリングリスト名/config.pckというファイルに書き出される。この辺りの細かい話は、メーリングリストのカスタマイズに関連して、別エントリで解説を行う。下記のコマンドでaliasesファイルを作成する。このファイルはメーリングリストの作成・削除を行う度に更新されるので、ここでは問題なく作成できるかをだけを確認する。aliases.dbと2つのファイルが作成されている事を確認しておく。list')が必要となる。パスワードリマインダー等は、このメーリングリストのアドレスから届くことになる。他にも色々なところで使われる...っぽいのだが、あんまり見たことがない。このメーリングリストはデフォルトではmailmanという名前となる。(もしもこの名前が気に喰わない場合は、mm_cfg.pyでMAILMAN_SITE_LISTという名前の変数を設定することで変更が可能)メーリングリストの作成は、bin/newlistコマンドを使用する。このコマンドの引数は以下の通り。sOme_PA$$W0RD上記コマンドで、mailman@ml.tsugihagi.netというメーリングリストが作成された。コマンド実行時に、エンターを押すと管理者にメールを送信した旨のメッセージが表示されるが、実際にはMailmanのサービスはまだ実行されていないので、送信は行われない。実際にmailmanというメーリングリストが作成されたことを、システム上で確認してみる。lists/ディレクトリにmailmanというディレクトリが存在しているか。mailman次に先ほどgenaliasesで作成されたdata/aliasesファイルにエントリが追加されているか。mailmanこの2点で正常にメーリングリストが作成されたどうかを判別できる。password'と表記されている。このパスワードはMailmanに関する全ての操作を行うためのパスワードで、Linuxシステムでのrootパスワードと、ほぼ同じとなる。以下のコマンドで作成する。動作を確認これでようやく設定は完了。実際にMailmanの動作を確認する。その前にMailmanのサービスが起動していないので起動してやる。CentOS6で使用できるSysVinit用のサービス起動スクリプトが、script/mailmanにあるので、それを/etc/init.d/にコピーして起動する。現在の状態で、システムにはmailman@ml.tsugihagi.netというメーリングリストが1つだけ存在するので、そこにユーザを追加して、投稿が配送されるかを確認する。今回はサーバ側の解説がメインなので、この辺りの操作は、実際の運用で作成された手順書等を参考にしてもらいたい。運用」でググると山ほど手順書が引っかかる。検索Gmailからの投稿確認Gmailでは同一のMessage-IDを持つメールを重複メールとして扱う、という仕様がある。Message-IDはメールの送信時に決定されるが、GmailからMailmanに投稿を行った場合、送信は問題なく行われるが、"自分宛に配信されたメール"と"自分が送ったメール"は同一のMessage-IDを持つ。ヘルプこれはMailmanに限った話ではなく、送信元のMessage-IDを保持するポリシーのメーリングリストシステム全般に起こりうる問題となる。MailmanのMLではMessage-IDを書き換えるか否かについて、散々に議論された結果、書き換えを行わないという方針となっている。将来的に方針が変更される可能性があるかもしれないが、少なくとも現状ではシステム側・あるいは運用面で対応する必要がある。運用で対応する場合は「Gmailからの投稿については、送信者へ配送されません」とアナウンスを行えば良いだけなのだが...、新規ではなくリプレース(Majordomoなど)の場合、混乱が起こる可能性がある。オリジナルのソースに手を加えるリスクを取るか、運用面での手間を取るかはケースバイケースだが、今回の解説では上記の問題に対応した+jバージョンをtarballからインストールすることで、システム側での対応を行った。実際にGmailアカウントから投稿を行うと、自分が送信したメッセージがちゃんと受信トレイに表示されると思う。以上でMailmanのインストール部分については完了。このままの状態で使い続けられるような環境ならば良いんだけど、殆どの場合はそうじゃないはず。先ほど例でも上げたとおり投稿の返信先を送信者ではなく、メーリングリストにしたい返信時の「Re:」の付く場所を変更したいSubjectに自動的に付与される文字列を変更したいWebUIがあるからメールコマンドを無効化したいなど、いろいろな要望があるかと予想されるので、カスタマイズの方法や、運用面でのトラブルシュート、ログの見かたなどを書いていく予定。インストール手順のページは山ほどあるから、どちらかというと、そっちのほうがメインコンテンツですかね。読者になるスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。