2015年8月5日水曜日

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
#





2015年7月20日月曜日

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



2015年7月18日土曜日

ログに特定の文字列が出力されたらメールで通知するには(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



2015年7月8日水曜日

ubuntuでインストール画面がまともに表示されなかったら

2020/04/03追記: コメントを頂いていたので返信をつけました。


また、イントール画面が欠けた場合の回避策としてより手軽な方法として
Windowsキーのあるキーボードをお使いの方であれば、そのWindowsキーを
押しながらインストール画面をドラックすれば欠けた部分を表示させることが
できるので、こちらのほうをお勧めします。
(参考URL)https://kledgeb.blogspot.com/2018/04/ubuntu-1804-96-ubuntu.html



(自分のところではVMware環境に限ってですが)ubuntuをインストールする時に画面の解像度が”640 x 480”に設定されてしまい、ディスクのパーティショニングするところで設定項目が見えない事象が発生しました。

以前にも「Fedora20 インストール画面がまともに表示されなかったら」という記事を書きましたが、それと同様の事象です。


回避策

(参考URL)https://wiki.ubuntulinux.jp/UbuntuTips/Others/BootOptions

Fedora20の時と同じくインストーラーにオプションを渡すことによって回避可能です。
以下、その手順です。


1.インストール開始直後の下記の画面でESCキーを押します。



2.「Ubuntuをインストール」を選択後、「F6 その他のオプション」を選択します。
 ※F6キーを押します。
















3.起動オプションとポップアップメニューが表示されます。
 ※ポップアップメニューはESCキーを押してキャンセルします。



4.起動オプションにフレームバッファの解像度を追記します。
 ※1番最後の”--"の後に追記します。
 ※今回は1024x768の解像度にしたかったので、”vga=791"と指定しています。















(備考)
フレームバッファの解像度がわからない場合、”vga=1024x768”のようにわざと誤った指定をすると下記のようなメニューに進む事ができるので、そこで指定したいモードを選択しても良いかもしれません。














結果、以下のように設定項目全般が見れるようになりました。












2015年7月1日水曜日

rsyslog 圧縮した状態でログを出力するには

今回は、保存されたログを後から加工(gzipなどで圧縮)するのではなく、rsyslog単体でログを出力すると同時に圧縮もしてみよう!という内容です。
※評価は、CentOS6.6(x86_64) + rsyslog-8.10.0で行っています



設定例


以下、ファシリティがmailのログを圧縮した状態で出力する例です。

template(name="for_postfix"
         type="string"
         string="/var/log/postfix/%$year%%$month%%$day%.log.gz"
)

if \
        $syslogfacility-text == "mail" \
then {
        action(
                type="omfile"
                zipLevel="1"
                dynaFile="for_postfix"
        )
        stop
}

ドキュメントにも書いてありますが、zipLevelで指定する数字が大きくなると圧縮率も高く(良く)なりますが、それに伴ってCPUの使用率も高くなるので、本番環境で設定する場合はそのあたりを十分確認(検証)したうえで設定をしてください



ログの確認方法


設定例どおりにログが出力されると以下のようになります。
# ls -l /var/log/postfix/
total 4
-rw-r--r-- 1 root root 157 Jun 30 23:43 20150630.log.gz
#
# file /var/log/postfix/20150630.log.gz
/var/log/postfix/20150630.log.gz: gzip compressed data, from Unix, max speed
#

ログは圧縮されている状態なので、zcatやzlessで確認します。
またtailに相当するコマンドはないかさがしたら、そのままずばりのztailコマンドが存在し、tailと同じ操作でログを確認する事ができました。

  • ztailの配布元
http://emysoutlet.com/linux/ztail/index.html


2015年3月12日木曜日

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

今回は、rsyslogをswatchのように使ってみようという内容です。
※評価は、CentOS6.6(x86_64) + rsyslog-8.8.0で行っています


以下に、rsyslogの比較的新しいフォーマットでの記述方法と昔ながらの記述方法の2種類を記載します。
⇒ログに'network connection error' あるいは'authentication failures'の文字列が出力されたら、メールでの通知を想定した例です



RainerScript styleフォーマットでの記述例


module(load="ommail")
template(name="mailSubject"
         type="string"
         string="Error on %hostname%"
)
template(name="mailBody"
         type="string"
         string="RSYSLOG Alert\r\nmsg='%msg%'"
)

if \
        ( $msg contains 'network connection error' ) or \
        ( $msg contains 'authentication failures' ) \
then {
        action(
          type="ommail"
          server="localhost"
          port="25"
          mailfrom="alert@rsyslog.example.com"
          mailto="user01@rsyslog.example.com"
          subject.template="mailSubject"
          template="mailBody"
          body.enable="on"
          #action.execonlyonceeveryinterval="3600"
        )
}
※コメントアウトしているaction.execonlyonceeveryintervalパラメータは、メールの通知間隔を調整するのに使います。監視している文字列がログに大量に出力された時に、メールがバーストするのを防ぐ為に利用します。
⇒上記の記述をそのまま有効にした場合、1度メールを送信したら同じメールを送信できるのは1時間(3600秒)後になります



Legacyフォーマットでの記述例


$ModLoad ommail
$template mailSubject,"Error on %hostname%"
$template mailBody,"RSYSLOG Alert\r\nmsg='%msg%'"
$ActionMailSMTPServer localhost
$ActionMailFrom alert@rsyslog.example.com
$ActionMailTo user01@rsyslog.example.com
$ActionMailSubject mailSubject
#$ActionExecOnlyOnceEveryInterval 3600
if \
        ( $msg contains 'network connection error' ) or \
        ( $msg contains 'authentication failures' ) \
then :ommail:;mailBody
※コメントアウトしている部分は、先のaction.execonlyonceeveryintervalパラメータと同じ目的で利用します。



動作検証

Puttyなどの端末を2つ立ち上げておき、

  • 1つはメールログをtail、
  • もう一つで以下のようにloggerコマンドを実行 (⇒私の環境では/var/log/messagesに出力されました)

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

# logger network connection error


実際に届いたメールはこんな感じになります。




2015年2月7日土曜日

rsyslog プロパティを操作する


今回は、rsyslogでテンプレートを定義する時に利用するプロパティについてです。
※評価は、CentOS6.6(x86_64) + rsyslog-8.7.0で行っています



利用できるプロパティには、hostnameやfromhostなどがあり、
 (参考)http://www.rsyslog.com/doc/v8-stable/configuration/properties.html

プロパティの書式は以下のようになっていています。
 (参考)http://www.rsyslog.com/doc/v8-stable/configuration/property_replacer.html
%property:fromChar:toChar:options%

通常は、propertyの部分だけを利用することが多いと思いますが、他の部分を操作することにより、ログの出力を色々と変化させる事ができます。

以下、2例ほどピックアップしてみます。


1.自動的に作成されるディレクトリを大文字とする

例えば、/var/log/<ホスト名>/<日付>.logのようにログを出力する際、ホスト名で作成されるディレクトリ部分を大文字にするには以下のようにuppercaseオプションを付与します。

$template   DEFAULT,  "/var/log/%FROMHOST:::uppercase%/$YEAR%%$MONTH%%$DAY%.log"
※逆に小文字にしたい場合は、lowercaseオプションを付与します


2.ログの必要な箇所だけ抽出する

fromCharとtoCharを指定すれば、シスログのどこからどこまでを抽出するかといった事が指定できます。
例えば、冗長な部分をカットした上で、RFC3339フォーマットっぽくログを出力させたい場合、

 (もともとの出力)
 2015-02-07T23:23:11.485286+09:00 rsyslog crond[10005]: (CRON) INFO (@reboot ・・・

 (冗長な部分をカットした出力)
 2015-02-07 23:23:11 rsyslog crond[10005]: (CRON) INFO (@reboot ・・・

以下のようなテンプレートを作成します(改行されてますが、1行で記述します)。
→先頭から10文字目までと、先頭から数えて12文字目から19文字目までを指定
$template RFC3339like, "%timestamp::10:date-rfc3339% %timestamp:12:19:date-rfc3339% %hostname% %syslogtag%%msg%\n"






2015年1月12日月曜日

rsyslog + MySQL 特定ホストだけMySQLへの出力を停止するには No.2

少し前に「rsyslog + MySQL 特定ホストだけMySQLへの出力を停止するには」という記事を書いているのですが、実現手段としてもう一つ追加します。
※評価は、CentOS6.6 + rsyslogのver8.6.0で行っています



ログを受信するポート + rulesetで除外する方法


リモートホスト側で、ログを転送するポートが自由に変更(例えばTCPの5140ポートなどに)できる場合には、以下のように設定することで、テンプレートSTOPSQLとして指定した先にのみログを出力し、その他のファイルやMySQLへの出力を止める事ができます。


input(type="imtcp" port="5140" ruleset="stopsql")

$template STOPSQL, "/var/log/%fromhost%/%$year%%$month%%$day%.log"

ruleset(name="stopsql"){
     action(type="omfile" dynaFile="STOPSQL")
}


(備考)
※詳細は以下のページで確認してください。
http://www.rsyslog.com/doc/v8-stable/concepts/multi_ruleset.html?highlight=ruleset

設定次第で、特定のホストのログだけを特別扱いするといった事が、より簡単に実現できると思います。

2015年1月6日火曜日

ソースの中のmanをインストール前に参照するには

ソースの中に含まれるmanをインストール前の事前確認として参照したい時ってありませんか?

そんな時の対応方法を2例ほど。
 →カレントディレクトリでpostfixのソースを展開後、anvil(8)を参照する例


1.manコマンドを使って参照
$ man postfix-2.12-20141228/man/man8/anvil.8

2.lessコマンドを使って参照
$ less -is postfix-2.12-20141228/man/man8/anvil.8

(備考)
より詳細な内容は、man(1)のDESCRIPTIONやENVIRONMENTなどで確認してください。

2015年1月4日日曜日

CentOS(RHEL)6 クラッシュダンプ用のメモリ割り当てを無効にする


クラッシュダンプを取得する必要がない + kexec-toolsのパッケージを導入していない(kdumpの機能を有効にしていない)にもかかわらず、クラッシュダンプ用にメモリの割り当て(消費)だけはされてしまうという状況を回避しようというのが今回の内容です。
※評価は、CentOS6.6(x86_64)でメモリ2GBを搭載したマシンで行っています


grub.confのkernel行にある”crashkernel=auto”の記述を削除する方法

(注意)
CentOS(RHEL)6系では、新しいkernelをインストールすると、必ず”crashkernel=auto”が付与されるようになっているので、新しいkernelをインストールした場合はその都度、削除をする必要があります
 ⇒ rpm -q --scripts kernel-<version> とするとその付与する処理が確認できます


/etc/init/kexec-disable.confを修正する方法

ファイルの中で”crashkernel=auto"をgrepしているのですが、/proc/cmdlineには実際に割り当てられたメモリの容量が入ってくるので、修正をしないと機能しません。
具体的には以下のように修正するか、その行自体を削除してしまっても良いと思います。

# diff -u /etc/init/kexec-disable.conf.orig /etc/init/kexec-disable.conf
--- /etc/init/kexec-disable.conf.orig     2015-01-02 23:02:11.067185577 +0900
+++ /etc/init/kexec-disable.conf  2015-01-02 23:06:03.607481618 +0900
@@ -8,7 +8,7 @@
 script
        if [ ! -x /sbin/kexec ] || ! chkconfig kdump 2>/dev/null ; then
-               grep -q "crashkernel=auto" /proc/cmdline && \
+               grep -q "crashkernel" /proc/cmdline && \
                echo -n "0" > /sys/kernel/kexec_crash_size 2>/dev/null
        fi
        exit 0
#

これで以下の条件にマッチすると、メモリの割り当てが無効になります。
・kexec-toolsパッケージがインストールされていない
・kexec-toolsパッケージがインストールされているが、自動起動がonになっていない