以下、man tarを抜粋

       --newer-mtime DATE
              like --newer, but with a DATE

例えばこのコマンドを使って、2012/01/01以後に出力されたログファイルだけを対象にバックアップを取得するには以下を実行すればいいわけです。

$ tar cvfz /var/tmp/backup.tar.gz --newer-mtime 2012-01-01 /var/log

$ man 5 crontab
...
「 第 6」フィールド (行の残りの部分) には実行されるコマンドを指定する。その行のコマンド部 (改行文字ま
たは % 文字まで) が /bin/sh (またはその crontab ファイルの SHELL 環境変数で指定されたシェル) によって
実 行される。コマンド中にパーセント記号 (%) がバックスラッシュ (\) によってエスケープされずに置かれて
いると、改行文字に置き換えられ、最初に現れた % 以降の全てのデータは標準入力としてコマンドに送られる。

覚えておきましょう。

参照ページ: http://www.courier-mta.org/maildropfilter.html

変数展開

Variable substitution
Variable substitution is performed on text literals that's surrounded by double quotation marks. The "$" character, followed by a variable name, is replaced by that variable's contents.

MAILBOX="$HOME/Mailbox"

要するに、ダブルクォートで囲むと$で始まる変数をmaildrop上で展開します。普通ですね。

変数の環境変数への反映

maildropでは、変数を定義すると、環境変数にもセットします。ので、外部コマンド実行時にmaildroprc上で定義した環境変数がそのまま使えますとのことです。

All internal variables are exported back as environment variables when maildrop runs an external command. Changes to internal variables, made by the filter file, are reflected in the exported environment.

これは意外と盲点でしたね。

コメントアウトを使う(デフォルト)

$ shopt -s interactive_comments
$ echo #asdf#asdf

コメントアウトを無視

$ shopt -u interactive_comments
$ echo #asdf#asdf
#asdf#asdf

参考(shopt)

$ shopt
cdable_vars     off
cdspell         off
checkhash       off
checkwinsize    on
cmdhist         on
dotglob         off
execfail        off
expand_aliases  on
extdebug        off
extglob         off
extquote        on
failglob        off
force_fignore   on
gnu_errfmt      off
histappend      off
histreedit      off
histverify      off
hostcomplete    on
huponexit       off
interactive_comments    on
lithist         off
login_shell     on
mailwarn        off
no_empty_cmd_completion off
nocaseglob      off
nocasematch     off
nullglob        off
progcomp        on
promptvars      on
restricted_shell        off
shift_verbose   off
sourcepath      on
xpg_echo        off

はじめに、mailmanにはML購読ユーザにメールが一定期間届かない場合、自動退会する機能がついていますが、その処理はユーザからのバウンスメッセージを元に動作します。

「ユーザからのバウンスメッセージを元に動作する」と一口に書けばそれまでですが、インターネットでのバウンスメッセージには様々な形式があり、それぞれのバウンスメッセージを正しく解析するのは容易ではありません。sendmail/qmail/postfix/yahoo/exchange等様々がMTAが応答するバウンスメッセージはばらばらですから。

で、mailmanがこれら雑多なバウンスメッセージをどうやって判定しているかというと、MTAが出す個別のバウンスメッセージにそれぞれ対応しているようです。

実際の処理を見てみましょう。

これらバウンスメッセージの処理はBounceRunnerというmailmanへのバウンスメッセージを解析するデーモンプログラムで処理されています。

BounceRunnerではバウンスメールを解析し、ループ等の検出を行った後に、それぞれのMTAに対応したバウンスメッセージの処理にディスパッチしています。

- Mailman/Queue/BounceRunner.py

    227         # Try VERP detection first, since it's quick and easy
    228         addrs = verp_bounce(mlist, msg)
    229         if addrs:
    230             # We have an address, but check if the message is non-fatal.
    231             if BouncerAPI.ScanMessages(mlist, msg) is BouncerAPI.Stop:
    232                 return
    233         else:
    234             # See if this was a probe message.
    235             token = verp_probe(mlist, msg)
    236             if token:
    237                 self._probe_bounce(mlist, token)
    238                 return
    239             # That didn't give us anything useful, so try the old fashion
    240             # bounce matching modules.
    241             addrs = BouncerAPI.ScanMessages(mlist, msg)
    242             if addrs is BouncerAPI.Stop:
    243                 # This is a recognized, non-fatal notice. Ignore it.
    244                 return

この231/241行目に出てくるBouncerAPI.ScanMessages()というメソッドがポイントです。
このメソッドは、mailmanへのバウンスメッセージかどうかをMTA毎に解析します。(実際にはバウンスメッセージに含まれているバウンス元ユーザを抽出する処理を行っています)

- Mailman/Bouncers/BouncerAPI.py

     61 # msg must be a mimetools.Message
     62 def ScanMessages(mlist, msg):
     63     for module in BOUNCE_PIPELINE:
     64         modname = 'Mailman.Bouncers.' + module
     65         __import__(modname)
     66         addrs = sys.modules[modname].process(msg)
     67         if addrs:
     68             # Return addrs even if it is Stop. BounceRunner needs this info.
     69             return addrs
     70     return []

63行目-69行目でMTA毎の個別処理についてループしていますが、このループ一覧は以下になります。

- Mailman/Bouncers/BouncerAPI.py

     39 BOUNCE_PIPELINE = [
     40     'DSN',
     41     'Qmail',
     42     'Postfix',
     43     'Yahoo',
     44     'Caiwireless',
     45     'Exchange',
     46     'Exim',
     47     'Netscape',
     48     'Compuserve',
     49     'Microsoft',
     50     'GroupWise',
     51     'SMTP32',
     52     'SimpleMatch',
     53     'SimpleWarning',
     54     'Yale',
     55     'LLNL',
     56     'AOL',
     57     ]

これを見る限り、DSN(Delivery Status Notifycation)から始まり、qmail->postfix->yahoo …と個別に判定を加えているようです。

試しにDSNを見てみましょう。PGをざっと見る限り、マルチパートで且つ、DSNの書式に則った応答の場合は、バウンスメッセージからバウンス応答したユーザ情報を抜き出す作りになっているようです。
- Mailman/Bouncers/DSN.py

     64             for header in ('original-recipient', 'final-recipient'):
     65                 for k, v in msgblock.get_params([], header):
     66                     if k.lower() == 'rfc822':
     67                         foundp = True
     68                     else:
     69                         params.append(k)
     70                 if foundp:
     71                     # Note that params should already be unquoted.
     72                     addrs.extend(params)
     73                     break
     74                 else:
     75                     # MAS: This is a kludge, but SMTP-GATEWAY01.intra.home.dk
     76                     # has a final-recipient with an angle-addr and no
     77                     # address-type parameter at all. Non-compliant, but ...
     78                     for param in params:
     79                         if param.startswith('<') and param.endswith('>'):
     80                             addrs.append(param[1:-1])

MTA毎に個別の処理を書いてはいますが、本当に個別となる部分だけを抽出して書いているので、かなりきれいなプログラムだと思いました。すごいな、mailman。

リサイズ前

[root@host1 ~]# df -h
Filesystem            Size  Used Avail Use% マウント位置
/dev/mapper/vg_host1-lv_root
                       34G  5.0G   27G  16% /
tmpfs                 1.9G   88K  1.9G   1% /dev/shm
/dev/sda1             485M   48M  412M  11% /boot
/dev/sdb               99G   86G  7.6G  92% /data

リサイズ中

100GBを200GBに拡張しました。

[root@host1 ~]# resize2fs /dev/sdb
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/sdb is mounted on /data; on-line resizing required
old desc_blocks = 7, new_desc_blocks = 13
Performing an on-line resize of /dev/sdb to 52428800 (4k) blocks.
The filesystem on /dev/sdb is now 52428800 blocks long.

拡張中はだんだん容量が増えていきます。

[user1@host1 backup]$ df -h
Filesystem            Size  Used Avail Use% マウント位置
/dev/mapper/vg_host1-lv_root
                       34G  5.0G   27G  16% /
tmpfs                 1.9G   88K  1.9G   1% /dev/shm
/dev/sda1             485M   48M  412M  11% /boot
/dev/sdb              153G   86G   59G  60% /data

簡単でオンラインに拡張できるので、すばらしいですね。ただ拡張中はI/O waitが100%になるので、実際の運用ではタイミングを見計らわないと痛い目に遭いそうだと言うことはわかりました。

ProFTPdではFTPクライアントからPASVコマンドが送出された際に、クライアントに返却するポート番号を特定のレンジから選択する「PassivePorts」という設定項目があります。コレを使うことでクライアントに返却するポートを49152-65534に絞ることも出来るというもの。

ただし、設定したポート範囲でポートオープン出来ない場合は、Kernelでポート選択をしてもらった上でログに書き出すとのこと。実用性を考慮すればまぁこうなりますか・・と思った次第です。

「Unable to allocate memory for transaction detail」

何だ?これ。と思ってしらべていたら、Oracleのサイトに以下の情報が。

Berkeley DB occasionally returns the error: "Unable to allocate  memory for transaction detail". What does that mean?This error means the maximum number of active  transactions configured for Berkeley DB has been reached. The Berkeley  DB environment should be configured to support more active transactions.  When all of the memory available in the database environment for  transactions is in use, calls to being a transaction will fail until  some active transactions complete. By default, the database environment  is configured to support at least 20 active transactions.

For more information see the "<a href="http://www.oracle.com/technology/documentation/berkeley-db/db/programmer_reference/txn_config.html">Configuring  transactions</a>" section of the Berkeley DB Reference Guide.

BerkeleyDBに対して設定されたActiveトランザクション数の最大値に達したとのこと。参照の試験しかしていないのにおかしいな・・・

とりあえずDB_CONFIGファイルのset_lg_regionmax, set_lg_bsizeを倍にしたら回避できた。

#set_lg_regionmax 262144
#set_lg_bsize 2097152
set_lg_regionmax 524288
set_lg_bsize 4194304

参照だけでもトランザクションを使うのでしょうかね。

• Apache JMeterで 負荷試験をしよう！

で、負荷をかける場合にはそのサーバの限界性能がどこかを探るケースが存在しますが、クライアント側のスペック不足やシナリオの作成方法が原因で負荷をかけきれないというケースがあります。スペック不足はともかくとして、シナリオ作成の方法がまずいことで計測結果が不十分になることはかっこわるいので、私が気がついた対処方法をまとめます。

ループはループコントローラで書け!

負荷をかける場合に、ユーザ1 – ユーザ10000迄のデータに連続してアクセスしたいケースがあったとしましょう。JMeterでこれを実装するには「While Controller」と「ループコントローラ」を利用する方法があると思います。

While Controllerを利用した方法)

ループコントローラを利用した方法)

While ControllerでJavascriptを利用して変数評価を行う場合、非常に負荷が高くなるようで、ループコントローラと比較して数十分の1程度しか負荷がかけられなくなった事もあります。書き方は要注意ですね。

While Controller + Javascriptでループは回すなって事ですね。

計測時にリアルタイムでリスナーの統計レポート、結果をツリー表示、グラフ表示等は使うな!

JMeterでは各種リスナーが充実していて、エラー率・スループットが一目でわかる統計レポート・グラフ表示機能等が存在します。

しかしこれらの機能を負荷計測と同時に使用すると、これらの処理自体に負荷がかかる模様です。結果十分な負荷をかけられないという事も。

対策は、リスナーの「シンプルデータライタ」を利用することです。シンプルデータライタは計測時にログ(jtl)をとることだけ行いますので、負荷はあまりかかりません。

統計レポート・結果をツリー表示・グラフ表示で見たい場合は計測後にこれらリスナを登録し、計測ログ(jtl)を読み込ませればいいんです。これで計測時には十分な負荷をかけることが出来、結果も後で参照出来ると。

計測時にはリスナーの「シンプルデータライタ」を利用しろ！グラフ表示等は後で読み込ませて結果を確認しろ！という事ですね。

JMeterを使いこなすにはまだまだノウハウが必要ですね。勉強になります。

さあそ の先へ、OpenLDAPパフォーマンスチューニング

これは、便利。早速参考にさせて頂きます。

ところで、LDAPの負荷をかけるツールには私の知る限り二種類あります。

• SLAMD
• Apache JMeter の LDAP Extended Request/LDAPリクエスト

どっちがいいんですかね。SLAMD使ったこと無いからよくわからんな・・・またいつか調べましょう。