CentOS6.x 最新のpostfixとdovecotをRPMで導入する

2018/01/08追記：　dovecot.orgにてタイムリーにdovecotの最新パッケージが提供されるようになりました。
　　　　　　　　　「Dovecot community repositoriesが公開されました」を参照してください

---

以前に、CentOS6.4で最新DovecotをRPMで導入するという記事を書いていますが、2016年5月現在では新しいバージョンへの追随はしていないようです。

自分の場合、最近、より最新バージョンのRPMを準備する別手段としてGhettoForgeリポジトリを使う事がわりと多いので、今回はそれについてまとめてみます。

※2016年5月現在、postfixはバージョン3.1.0、dovecotはバージョン2.2.23が導入可能です

リポジトリの導入

以下のコマンドを実行します。

結果、複数のリポジトリ[gf/gf-plus/pf-testing]が利用可能になります。
※詳細はUsageのページで確認をしてください

＃rpm -ivh http://mirror.symnds.com/distributions/gf/el/6/gf/x86_64/gf-release-6-10.gf.el6.noarch.rpm

postfix3.1.0のインストール

postfix3.1.0はpf-plusリポジトリに存在するので、以下のようにインストールします。
※ OSインストール時にデフォルトでバージョン2.6.xがインストールされているはずなので、そのままだとconflictsのエラーが出てしまいます。その場合は一旦バージョン2.6.xをアンインストールする必要があります。

(# rpm -e --nodeps postfix)   <-★conflictsのエラーが出る場合実施
# yum --enablerepo=gf-plus install postfix3

dovecot2.2.23のインストール

dovecot2.2.23はgf-testingリポジトリに存在するので、以下のようにインストールします。
※将来的には、gf-testingリポジトリからgf-plusリポジトリに移行されると思うので、その際は"--enablerepo=gf-plus"と指定を変更してください

# yum --enablerepo=gf-testing install dovecot22

その他

1.　GhettoForgeリポジトリを使いやすくする為にエイリアスを登録する

パッケージのインストールやアップデートの度に”--enablerepo=ｘｘｘｘ”と入力するのは面倒なので、自分の場合は、~/.bashrcに以下の内容でエイリアスとして登録しています。
これで、myum installやmyum updateのように入力した時だけ、GhettoForgeリポジトリを利用するようにしています。

alias myum='yum --enablerepo=gf-plus,pf-testing'

2.　GhettoForgeリポジトリからpostfixとdovecot以外のパッケージが導入されないようにする

これはGhettoForgeのサイトにも書いてある内容ですが、GhettoForgeリポジトリにはpostfixやdovecot以外にも多数のパッケージが用意されています。postfixとdovecot以外の他のパッケージが意図せず導入されないように、利用するパッケージを限定しておきます。


具体的には、/etc/yum.repos.d/gf.repoファイル内の[gf-plus]リポジトリと[gf-testing]リポジトリのそれぞれにincludepkgs行を追記します。

[gf-plus]
name=Ghettoforge packages that will overwrite core distro packages.
mirrorlist=http://mirrorlist.ghettoforge.org/el/6/plus/$basearch/mirrorlist
# Please read http://ghettoforge.org/index.php/Usage *before* enabling this repository!
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-gf.el6
failovermethod=priority
includepkgs=postfix* dovecot*


[gf-testing]
name=GhettoForge packages that are currently untested.
mirrorlist=http://mirrorlist.ghettoforge.org/el/6/testing/$basearch/mirrorlist
# This repo may contain packages that overwrite core distro packages.  Please
# read http://ghettoforge.org/index.php/Usage before enabling this repository.
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-gf.el6
failovermethod=priority
includepkgs=postfix* dovecot*

作業ミスを減らすために

今回はいつもと趣向をかえて、作業ミスを減らす為に自分が必ずする初期設定について書こうと思います。

（たいした事ではありませんが、視覚に訴えるものを3つほど紹介します。）

※以下、基本的にベースはRedhat系として記述します

1．ファイルとディレクトリなどを見分けやすく

lsコマンド実行時にファイルなのかディレクトリなのか識別しやすくする為に、”ls -F”や”ls -l”とオプションを付けて実行すると思います。ただ毎回オプションをつけて実行するのも面倒なので、手短にlsと入力すれば”ls -F”の出力結果が返ってくるようにしています。

その際にどの作業環境（コンソールやその他仮想端末を問わず）・どのユーザでも統一された状態で実行されるように、システム全体に効くエイリアス（alias）として登録しています。

具体的には、/etc/profile.d/colorls.sh　ファイル内で以下の記述部分を変更します。

(変更前）
alias ls='ls --color=tty' 2>/dev/null

（変更後）
alias ls='ls -F --color=tty' 2>/dev/null

※変更後、ログインし直すか、source /etc/profile.d/colorls.sh とする事で変更が適用されます

2．vimの色分けを有効にする

※この内容を試すにはvim-enhancedパッケージが導入されている必要があります

設定ファイル類をvimで編集するとある程度syntaxにそって色分けがされ、見通しが良くなると思います（単純な対となる記号の記述もれなどsyntaxがおかしいと色のつき方が変になるので、すぐに何かがおかしいと気づくはずです）。

ただ、設定ファイルを編集するケースの多いrootユーザだと色分けされずに白黒のまんまなので？と思った事はありませんか？
※何かしら理由があるとは思うのですが、調べてません...

前置きが長くなりましたが、具体的には/etc/profile.d/vim.shでその設定がされているので、以下の記述を残して他の記述は全てコメントアウトします。

これで、どのユーザ・どの端末でも同じようにsyntaxに沿って色分けがされるようになります。

alias vi >/dev/null 2>&1 || alias vi=vim

※変更後、ログインし直すか、source /etc/profile.d/vim.sh とする事で変更が適用されます

3．rootユーザのプロンプトに色を付ける

なにかというと、rootユーザになったらプロンプトの部分に色をつけて、rootで作業をしているよ！！という事を意識するようにしています。

具体的には、以下の内容を~/.bashrcに記述しています。
こうすることでプロンプトが赤くなります。

export PS1="\[$(tput bold)$(tput setaf 1 2)\][\u@\h \W]# \[$(tput sgr0)\]"

CentOS6（RHEL6） 起動するtty（仮想コンソール）を調整する

今回はタイトルの通り、CentOS6（RHEL6）では初期に6つ起動するtty(仮想コンソール）を調整する方法についてです。
※普段Puttyなどでリモートから作業をするなら、コンソールを使って作業する事も稀でしょうから、
　使わないものはメモリの消費を抑える意味でも起動しないように調整しましょう。

ttyの起動数を減らす設定

CentOS6(RHEL6)では、/etc/sysconfig/initファイル内のACTIVE_CONSOLESの箇所を編集します。
※以下では、tty3～tty6までを停止しています。

（変更前)
ACTIVE_CONSOLES=/dev/tty[1-6]

（変更後）
ACTIVE_CONSOLES=/dev/tty[1-2]

設定の適用方法

2パターンあるので、お好きなほうで適用してください。

1.　再起動をする
　これで起動時に/etc/sysconfig/initファイルを読み込んで/dev/tty1と/dev/tty2だけあがっている状態になります。

2.　以下のコマンドを実行する
　※停止する仮想コンソール分、実行します
　※こちらは再起動は必要ありません

# initctl stop tty TTY=/dev/tty3
# initctl stop tty TTY=/dev/tty4
# initctl stop tty TTY=/dev/tty5
# initctl stop tty TTY=/dev/tty6

Dovecot Enterpriseについて（2016年1月現在）

2018/01/08追記：いつのまにかリポジトリにアクセスできなくなったので、問い合わせをしました。
　　　　　　　　　以下のような返信をもらいました。
　　　　　　　　　要するに一般ユーザーには、同エディションは提供されないようです。

We have done some maintenance for expired accountsbecause we no longer have webshop and we don't provide dovecot-eerepository access without valid support contract with us.

Next year we disable all accounts without active support contract withus but start providing Dovecot Communition Edition packages for free. Wesend information about this change later.

---

2013年7月14日に「Dovecot Enterprise Editionについて」という記事を書きましたが、

今回はタイトルの通りDevecot　Enterpriseのその後についてです。



・今はそもそも「Dovecot Pro」と呼ぶようです

・リポジトリにアクセスするためのユーザ名とパスワードを入手する方法が「Contact US」だけになったようです
　→ 過去にWebから購入したライセンスはそのまま継続して利用できるようです


・Dovecot Enterprise Editionを入手するためのリポジトリのURLsが、変更されています
　→　http://software.open-xchange.com/products/dovecot/doc/Dovecot-EE-repository-and-object-storage-installation-manual_v1.9.pdf

Postfwd キャッシュの取り扱い

postfwdはルールセットにマッチしたものをキャッシュとして保持し、以降、保持期間が過ぎるまでキャッシュを利用して応答します。
今回は、そのキャッシュについてまとめてみます。

※評価は、CentOS6.6（x86_64) + Postfwd2 v1.35で行っています
※また、以下のようなドメイン名の入力ミスにエラーをかえすルールセットを作って行っています

id=WRONG_DOMAINS
        recipient_domain = (gmal.com|gmaile.com)
        action = REJECT Isn't it gmail.com?

キャッシュの保持期間

これは、Postfwdの起動時の引数として指定する"--cache"の値で決まります。

※キャッシュに関するオプションは結構あるので、"postfwd2 -m"と実行し、Cache:の箇所を確認してみてください。

キャッシュの内容確認

”--dumpcache”オプションで確認する事ができます。
以下、出力例です（変な改行が入って見にくいですが、"%request_cache ->"から次の"%request_cache ->"のところまでが1行です）。

# postfwd2 --dumpcache
%request_cache -> %192.168.233.1;unknown;mail.example.com;mail.example.com;SMTP;RCPT;user01@gmal.com;gmal.com;user01;smtpd_access_policy;1.233.168.192;unknown;user01@mail.example.com;mail.example.com;user01;mail.example.com;mail.example.com;mail.example.com;mail.example.com;postfwd2 1.35; -> @action -> 'REJECT Isn't an address gmail.com?'
%request_cache -> %192.168.233.1;unknown;mail.example.com;mail.example.com;SMTP;RCPT;user01@gmal.com;gmal.com;user01;smtpd_access_policy;1.233.168.192;unknown;user01@mail.example.com;mail.example.com;user01;mail.example.com;mail.example.com;mail.example.com;mail.example.com;postfwd2 1.35; -> @hit    -> '3'
%request_cache -> %192.168.233.1;unknown;mail.example.com;mail.example.com;SMTP;RCPT;user01@gmal.com;gmal.com;user01;smtpd_access_policy;1.233.168.192;unknown;user01@mail.example.com;mail.example.com;user01;mail.example.com;mail.example.com;mail.example.com;mail.example.com;postfwd2 1.35; -> @hits   -> 'WRONG_DOMAINS'
%request_cache -> %192.168.233.1;unknown;mail.example.com;mail.example.com;SMTP;RCPT;user01@gmal.com;gmal.com;user01;smtpd_access_policy;1.233.168.192;unknown;user01@mail.example.com;mail.example.com;user01;mail.example.com;mail.example.com;mail.example.com;mail.example.com;postfwd2 1.35; -> @id     -> 'WRONG_DOMAINS'
%request_cache -> %192.168.233.1;unknown;mail.example.com;mail.example.com;SMTP;RCPT;user01@gmal.com;gmal.com;user01;smtpd_access_policy;1.233.168.192;unknown;user01@mail.example.com;mail.example.com;user01;mail.example.com;mail.example.com;mail.example.com;mail.example.com;postfwd2 1.35; -> @ttl    -> '600'
%request_cache -> %192.168.233.1;unknown;mail.example.com;mail.example.com;SMTP;RCPT;user01@gmal.com;gmal.com;user01;smtpd_access_policy;1.233.168.192;unknown;user01@mail.example.com;mail.example.com;user01;mail.example.com;mail.example.com;mail.example.com;mail.example.com;postfwd2 1.35; -> @until  -> '1438783060.04902'

※各行のお尻の部分だけに注目すると内容を把握しやすいと思います。

@action -> 'REJECT Isn't an address gmail.com?'
@hit    -> '3'
@hits   -> 'WRONG_DOMAINS'
@id     -> 'WRONG_DOMAINS'
@ttl    -> '600'
@until  -> '1438783060.04902'

キャッシュのクリア

基本的にpostfwdの再起動をすればキャッシュはクリアされますが、全てのキャッシュが対象になってしまいます。

そうではなく、間違ってキャッシュしてしまった一部のキャッシュだけ削除する場合は以下のように実施します。

書式は以下のようになります。

# postfwd2 --delcache <item>

この<item>が意外と分かりにくいのですが、"--dumpcache"で出力される以下の青字部分を指定します。

%request_cache ->  %192.168.233.1;unknown;mail.example.com;mail.example.com;SMTP;RCPT;user01@gmal.com;gmal.com;user01;smtpd_access_policy;1.233.168.192;unknown;user01@mail.example.com;mail.example.com;user01;mail.example.com;mail.example.com;mail.example.com;mail.example.com;postfwd2 1.35; -> @until  -> '1438783708.62979'

以下、実行例です。

# postfwd2 --delcache="  %192.168.233.1;unknown;mail.example.com;mail.example.com;SMTP;RCPT;user01@gmal.com;gmal.com;user01;smtpd_access_policy;1.233.168.192;unknown;user01@mail.example.com;mail.example.com;user01;mail.example.com;mail.example.com;mail.example.com;mail.example.com;postfwd2 1.35;"

request cache item '192.168.233.1;unknown;mail.example.com;mail.example.com;SMTP;RCPT;user01@gmal.com;gmal.com;user01;smtpd_access_policy;1.233.168.192;unknown;user01@mail.example.com;mail.example.com;user01;mail.example.com;mail.example.com;mail.example.com;mail.example.com;postfwd2 1.35;' removed
#

S3QL S3互換ストレージが正常にアンマウントできない場合

今回は、S3QLでマウントするストレージに”S3互換ストレージ”を指定した時に遭遇したエラーについて。

具体的には、S3QLでS3互換ストレージをマウントし、データを書き込み、アンマウントしたところ下記のようなエラーが出力されて、その後マウントできない状況になりました。
※マウントする前に、fsck.s3qlをかけても同様のエラーが出力されてしまいます

＜アンマウント時のログから抜粋＞

2015-07-20 11:33:59.949 16110:MainThread s3ql.mount.main: FUSE main loop terminated.
2015-07-20 11:33:59.954 16110:MainThread s3ql.mount.unmount: Unmounting file system...
2015-07-20 11:34:03.042 16110:MainThread s3ql.mount.main: Dumping metadata...
2015-07-20 11:34:03.042 16110:MainThread s3ql.metadata.dump_metadata: ..objects..
2015-07-20 11:34:03.044 16110:MainThread s3ql.metadata.dump_metadata: ..blocks..
2015-07-20 11:34:03.045 16110:MainThread s3ql.metadata.dump_metadata: ..inodes..
2015-07-20 11:34:03.046 16110:MainThread s3ql.metadata.dump_metadata: ..inode_blocks..
2015-07-20 11:34:03.046 16110:MainThread s3ql.metadata.dump_metadata: ..symlink_targets..
2015-07-20 11:34:03.047 16110:MainThread s3ql.metadata.dump_metadata: ..names..
2015-07-20 11:34:03.048 16110:MainThread s3ql.metadata.dump_metadata: ..contents..
2015-07-20 11:34:03.049 16110:MainThread s3ql.metadata.dump_metadata: ..ext_attributes..
2015-07-20 11:34:03.050 16110:MainThread s3ql.mount.main: Compressing and uploading metadata...
2015-07-20 11:34:03.105 16110:MainThread s3ql.mount.main: Wrote 321 bytes of compressed metadata.
2015-07-20 11:34:03.105 16110:MainThread s3ql.mount.main: Cycling metadata backups...
2015-07-20 11:34:03.105 16110:MainThread s3ql.metadata.cycle_metadata: Backing up old metadata...
2015-07-20 11:34:03.331 16110:MainThread s3ql.backends.s3c.copy: Unexpected server reply to copy operation:
200 OK
Server: Riak CS
ETag: "5df94930a7549cfcd6acab482c9bae94"
Date: Wed, 08 Jul 2015 02:34:03 +0000
Content-Type: application/xml
Content-Length: 175

解決策を探していたところ以下の記述を見つけました。

＜ソースに含まれるChanges.txtより＞

2014-11-09, S3QL 2.12
  * The s3c backend has a new 'dumb-copy' option. If this option
    is enabled, copy operations are assumed to have succeeded
    as soon as the server returns a '200 OK' status, without
    checking the contents of the response body.

＜http://www.rath.org/s3ql-docs/backends.html　のS3 compatibleの項目より＞

dumb-copy

If this option is specified, S3QL assumes that a COPY request to the storage server has succeeded as soon as the server returns a 200 OK status. The S3 COPY API specifies that the storage server may still return an error in the request body (see the copy proposal for the rationale), so this option should only be used if you are certain that your storage server only returns 200 OK when the copy operation has been completely and successfully carried out. Using this option may be neccessary if your storage server does not return a valid response body for a succesfull copy operation.

ということで最終的には、下記のようにmount.s3qlでマウント時に、バックエンドオプションをプラスする事で解決できました。

# mount.s3ql --allow-other --backend-options=dumb-copy \
> s3c://<hosstname or エンドポイント名など>/<backetname>/ /home/vmail

ログに特定の文字列が出力されたらメールで通知するには（fluentd編）

先日、「ログに特定の文字列が出力されたらメールで通知するには（rsyslog編）」という記事を書きましたが、※ほぼ※同じ事を”fluentd”を使って実現してみましょうというのが今回の内容です。

違いは下記のようになるので、環境（状況）にあわせて使いわけると良いと思います。

• rsyslogの場合は、1回でも特定の文字列が出力されたら通知が実施されます（2回目以降の通知はある程度抑止できます）。

• fluentdの場合は、決められた計測時間内に特定文言が決められた回数出力されたらその都度、通知を実施します。　　⇒ 例）10 秒の間に、特定文言が2回出力したらメールで通知（次の10秒でも、特定文言が2回出力されたらまた通知）

※評価は、CentOS6.6(x86_64) + fluentd v0.12.7(gemによる導入）で行っています

fluentdプラグインの導入

※fluetndそのもの導入に関しての説明は割愛させていただきますので、このあたりを参考に導入してください。

今回の目的を達成するのに必要な以下のプラグインを導入します。

・fluent-plugin-grepcounter
・fluent-plugin-mail

fluentdの設定

今回は、以下の条件でメール通知をする設定としました。

・/var/log/messagesに
・単位時間10秒の間に
・”WARN”の文字列が2回以上出力

＜/etc/fluent/fluent.confの設定例＞

<source>
  type tail
  format syslog
  path /var/log/messages
  tag syslog.messages
  pos_file /var/log/fluent/pos_file
</source>

# 特定文言がログに出力されるのをカウントする部分
<match syslog.messages>
  type grepcounter
  count_interval 10
  input_key message
  regexp "WARN"
  threshold 2
  add_tag_prefix warn.count
</match>

# メール通知をする部分
<match warn.count.syslog.messages>
    type mail
    host localhost
    port 25
    from "warn@fluetd.example.com"
    to "user01@fluentd.example.com"
    subject "[URGENT] WARN logging"
    message Total WARN  count: %s\n\nPlease check your logs
    message_out_keys count
</match>

※※各パラメータの意味は、プラグインのREADME.mdで確認してください
<fluent-plugin-grepcounter>
　https://github.com/sonots/fluent-plugin-grepcounter
<fluent-plugin-mail>
　https://github.com/u-ichi/fluent-plugin-mail

※※私の環境では、以下でも確認できました

<fluent-plugin-grepcounter>

　/usr/local/rvm/gems/ruby-2.2.0/gems/fluent-plugin-grepcounter-0.5.5/README.md

<fluent-plugin-mail>
　/usr/local/rvm/gems/ruby-2.2.0/gems/fluent-plugin-mail-0.1.1/README.md

動作検証

fluetndを起動後、Puttyなどの端末を2つ立ち上げて、

• 1つは以下のようにloggerコマンドを実行（10秒の間に2回以上実施）
• もう1つは、メールログと/var/log/messagesをtail

する事で動作を確認する事ができます。

＃logger WARN

これで、今回設定した”単位時間10秒”に”2回”以上”WARN”の文字列が出力されたら1通ずつメール通知されるようになったと思います。

(参照URL）

http://docs.fluentd.org/articles/splunk-like-grep-and-alert-email